LINUX.ORG.RU
ФорумTalks

[kernel.org]Работу Git будет восстановлена без shell-доступа


0

1

Один из администраторов инфраструктуры kernel.org опубликовал в списке рассылки разработчиков ядра Linux уведомление, в котором рассказал о статусе восстановления серверов после взлома и работе, проделанной для увеличения безопасности. Kernel.org недоступен уже почти месяц. Столь длительный срок связан с тем, что разработчики были заняты детальным аудитом и полной переработкой архитектуры аутентификации и организации доступа во всех публично доступных сервисах kernel.org.

Возобновить работу сайта в первозданном виде, переустановив операционную систему и восстановив данных из резервной копии, можно было за несколько часов, но такой шаг не устраивал, так как инцидент показал принципиальные недоработки в организации доступа, которые рано или поздно могли привести к повторному взлому. В частности, наличие shell-аккаунтов у 448 разработчиков потенциально делали каждого из них мишенью для атакующих. В случае перехвата SSH-ключей у одного из этих разработчиков, под удар становилась вся инфраструктура. Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.

По сообщению администраторов, работа kernel.org будет частично восстановлена в ближайшие дни. В первую очередь в строй будут введены сервисы, связанные с обеспечением работы с Git-репозиториями. Наиболее важные Git-деревья будут доступны уже в начале недели, остальные Git-деревья планируется ввести в строй в начале октября. На восстановление работы всех остальных сервисов потребуется дополнительное время. После возрождения kernel.org будет существенно изменен метод доступа к Git: у разработчиков больше не будет доступа к системной оболочке (shell), а все Git-репозитории kernel.org будут функционировать в системе под одним системным пользователем. Работа с Git-репозиториями будет организована поверх HTTP, но для доступа к репозиторию по прежнему будут использоваться SSH-ключи. Нынешние SSH-ключи отменены, а новые будут сгенерированы и отправлены разработчикам в ближайшее время.

Для разделения прав доступа разработчиков к различным частям Git-репозитория будет задействовано расширение Gitolite, поддерживающее отдельную базу виртуальных пользователей, не имеющих системных аккаунтов. Дополнительно, Gitolite позволит реализовать более гибкие полномочия: возможность доступа только для чтения или разрешение записи, в привязке к отдельным веткам, директориям, файлам или даже тегам, а также отдельные права на слияние, создание и удаление веток и тегов. Автор Gitolite считает свой проект абсолютно безопасным и готов выплатить тысячу долларов тому, кто сможет найти в нём уязвимость. Недостатком новой платформы являются невозможность запуска скриптов разработчиков на сервере, например, перестанут работать интегрируемые с Git индивидуальные обработчики, написанные на shell. Подобные обработчики потребуется переписать с учетом особенностей Gitolite.

Источник

Ответ на: комментарий от DarkV

shell-аккаунтов не будет, разграничение прав будет осуществляться на уровне Git с помощью Gitolite.

daemonpnz
() автор топика

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

Решето.

Deleted
()

> Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.

Т.о. создатели линукса официально признали свою систему решетом...

Igron
()

Переехали на Gitolite? Всё правильно сделали.

Gitosis, я так понимаю, всё? Он кому-то ещё нужен?

ChALkeR
()
Ответ на: комментарий от Igron

Просто там же куча софта, которую можно ломать. Не один линукс. Да, множество из сотен программ с доступом к бинарникам и ФС, и с битами SUID на некоторых файлах - это решето.

Deleted
()
Ответ на: комментарий от Deleted

Просто там же куча софта, которую можно ломать. Не один линукс. Да, множество из сотен программ с доступом к бинарникам и ФС, и с битами SUID на некоторых файлах - это решето.

Имеются ввиду стандартные coreutils/util-linux, или ещё что-то?

pv4
()

> Нынешние SSH-ключи отменены, а новые будут сгенерированы и отправлены разработчикам в ближайшее время.

Это как? Приватные ключи сгенерирует дядя Вася и по почте пришлет разработчикам что-ли?

Deleted
()
Ответ на: комментарий от Deleted

Бумажной почтой в конвертах с защитой от просвечивания.

pimiento
()

>Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.

Что и требовалось доказать.

Othniel
()
Ответ на: комментарий от pv4

Они + сам гит + соотв. серверный софт.

Deleted
()
Ответ на: комментарий от daemonpnz

> имея шелл доступ можно, использую дыры в любом используемом на сервере ПО, получить рут и так далее

Подскажи, как используя дырку в ircd (запущенном от пользователя ircd) получить рута?

Igron
()
Ответ на: комментарий от Igron

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

daemonpnz
() автор топика
Ответ на: комментарий от Deleted

Честный дядя Вася отправит ключ не глядя :)

GotF
()
Ответ на: комментарий от Igron

>> имея шелл доступ можно, использую дыры в любом используемом на сервере ПО, получить рут и так далее

Подскажи, как используя дырку в ircd (запущенном от пользователя ircd) получить рута?

Получить шелл, дальше спросить на kernel.org

tailgunner
()

Сплошной профит от слома!

Вы прикиньте, сколько они трафика сэкономили, прикрываясь сломом хакеров.

Bad_ptr ☕☕
()
Ответ на: комментарий от daemonpnz

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

Перефразирую.

Подскажи, как используя дырку в apache (запущенном от пользователя apache) получить рута?

Igron
()

>Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.

Linux — решето.

thrall
()
Ответ на: комментарий от Igron
root     18544  0.6  0.1 238780 10504 ?        Ss   16:03   0:00 /usr/sbin/httpd -k start
http     18547  0.0  0.0 238780  5768 ?        S    16:03   0:00  \_ /usr/sbin/httpd -k start
http     18548  0.0  0.0 238780  5768 ?        S    16:03   0:00  \_ /usr/sbin/httpd -k start
http     18549  0.0  0.0 238780  5768 ?        S    16:03   0:00  \_ /usr/sbin/httpd -k start
http     18550  0.0  0.0 238780  5768 ?        S    16:03   0:00  \_ /usr/sbin/httpd -k start
http     18551  0.0  0.0 238780  5768 ?        S    16:03   0:00  \_ /usr/sbin/httpd -k start

ломаешь первый процесс.

sergej
()

Скорее бы уже багзилла заработала. Есть что туда написать.

DreamDragon
()
Ответ на: комментарий от daemonpnz

> использую дыры в любом используемом на сервере ПО
О, расскажи чем тебе поможет получение прав аккаунта apache, например. Ломать можно двумя способами, — через баги ядра и через баги рутованный suid софта. Что на сервере делает последний, — совершенно непонятно. А за баги ядра ответственны именно разработчики Linux.

Elemir
()
Ответ на: комментарий от Elemir

О, да ты ещё и эксперт-аналитик по безопасности. :D На все руки от скуки товарищ.

daemonpnz
() автор топика
Ответ на: комментарий от Elemir

Гугли про эксплоийты для юзверских программ без suid бита, которые позволяют поднимать уровень привилегий до root'а.

daemonpnz
() автор топика
Ответ на: комментарий от Deleted

>Просто там же куча софта, которую можно ломать.

Что именно сломали в этот раз, они, конечно же, не выяснили?

gentoo_root
()
Ответ на: комментарий от Elemir

Да, да, продолжай нас образовывать, эксперт-аналитик.

daemonpnz
() автор топика

Как показала практика, при наличии неограниченного доступа к shell, получение root-привилегий - дело времени.

4.2

xtraeft
()
Ответ на: комментарий от daemonpnz

Гугли про эксплоийты для юзверских программ без suid бита, которые позволяют поднимать уровень привилегий до root'а.

бред сивой кобылы

xtraeft
()
Ответ на: комментарий от daemonpnz

ну так приведи пример эксплойта для юзерской программы без suid, который поднимет тебя до рута

xtraeft
()
Ответ на: комментарий от daemonpnz

В эмуляторе Qemu и построенном на его основе пакете qemu-kvm найдены две уязвимости, позволяющие локальному пользователю гостевой и базовой системы повысить свои привилегии. Первая уязвимость вызвана переполнением буфера в модуле VirtIO, которое можно эксплуатировать путем отправки специально оформленного virtqueue-запроса. Вторая проблема связана с некорректным сбором привилегий (групп) при запуске приложения под другим пользователем при помощи опции "-runas". Исправление пока доступно в виде патча;

daemonpnz
() автор топика
Ответ на: комментарий от xtraeft

Будь не серваках kernel.org qemu и kvm, то их могли бы сломать из под обычного shell-аккаунта имеющего доступ к qemu. Так что давай рассказывай дальше про 4.2. А мы тебя внимательно послушаем.

daemonpnz
() автор топика
Ответ на: комментарий от daemonpnz

немного перефразирую:

Как показала практика, при наличии неограниченного доступа к shell и недостаточной внимательности администратора сервера, получение root-привилегий - дело времени.

все таки жду пример эксплойта для юзерской программы без suid, который поднимет тебя до рута

xtraeft
()
Ответ на: комментарий от xtraeft

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

daemonpnz
() автор топика
Ответ на: комментарий от daemonpnz

Unprivileged guest user could use this flaw to crash the guest (denial of service) or, possibly, escalate their privileges on the host.

Читать до просветления.

daemonpnz
() автор топика
Ответ на: комментарий от xtraeft

> все таки жду пример эксплойта для юзерской программы без suid, который поднимет тебя до рута

был такой эксплоит год назад на x86_64, я тогда три рута отмутил ;)

stevejobs
()
Ответ на: комментарий от xtraeft

думаю, если у кого-то есть рабочий эксплоит, с тобой/нами он не поделится, слишком много бабла можно на этом срубить

stevejobs
()
Ответ на: комментарий от stevejobs

думаю, если у кого-то есть рабочий эксплоит,

к чему?

xtraeft
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.