Обнаружена очередная local root уязвимость в ядре Linux 3.8

И ты наивно думаешь, что это сарказм, мой юный друг.

Все таки не совсем понятно, почему это должен быть хомяк. Чем не подходит /tmp или /var/cache? правда они могут быть на tmpfs, но тоже ведь не везде.

бложик какой-нить с низкой посещаемостью влезет. Не больше.

А откуда уверенность что на шареде за эти деньги дадут больше?

Потом вроде как договорились уже что всякие бложики это целевая аудитория шаредов.

Собственно, из исходник видно, что идея состоит в том, чтобы создать чрут, создать новое пространство, стать в нем локальным рутом и поставить в нем suid на файл, а затем выполнить этот файл из основной системы. Поскольку в чруте работают только хардлинки, надо этот чрут делать в любой директории на одной файловой системе с /lib Честно говоря, почему вместо хардлинков не использовать копирование из /lib, тоже не совсем понятно.

Все таки не совсем понятно, почему это должен быть хомяк. Чем не подходит /tmp или /var/cache?

потому-что в HOME вегда может писать простой юзер, и HOME всегда на HDD. (ну почти всегда). А вот в /var/cache например на моём десктопе писать юзеру нельзя. В TMP можно, но он часто в памяти. Потому эксплоиты рассчитывают на HOME, хотя реально дыру можно эксплуатировать и где-то не там.

А откуда уверенность что на шареде за эти деньги дадут больше?

обычно шаред дешевле. Был. Давно не интересовался, ибо не нужен.

Честно говоря, почему вместо хардлинков не использовать копирование из /lib, тоже не совсем понятно.

тогда ты получишь ещё одного рута в chroot'е. А тебе нужен рут в основной системе, т.е. в основном /lib'е.

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

ну логично предположить, что уязвимость недавно вышедшего 3.8 с любовью перенесли в 3.9 которое ещё тока rc2, не?

тогда ты получишь ещё одного рута в chroot'е

chroot не удержит root'а.

ну логично предположить, что уязвимость недавно вышедшего 3.8 с любовью перенесли в 3.9 которое ещё тока rc2, не?

В 3.9 уязвимость запатчили раньше, чем в 3.8

chroot не удержит root'а.

собственно в этом и уязвимость.

тогда ты получишь ещё одного рута в chroot'е. А тебе нужен рут в основной системе, т.е. в основном /lib'е.

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

Да ни разу. Пространства имен, это сверхлегкий механизм контейнеров, наподобие того, что в openvz. Рут в них вполне нормален.

Чрут в эксплойте используется только для удобства, чтобы LD_LIBRARY_PATH не переназначать, он по всему видно, необязателен.

у меня в памяти очевидно.

И такая тенденция не есть хорошо. В /tmp принято скидывать различные временные проекты и результаты рендеринга а когда этот каталог принудительно перенесут в память то покупать 128Гб оперативы?

мы про openshift говорили

Меня всегда так умиляют люди. Ты правда думаешь я на это как-то отреагирую? Если слился то так и скажи. Страшно не не знать, а упорствовать в своём невежестве и переходить на личности.

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

Ответь на простые вопросы:

я не знаю

я, если честно, так и не понял сути вашего спора. Что ты доказать пытался?

он приводит вот такие аргументы:

Hacked HostGator Sites Distribute IE Exploit

уязвимости вида:

Successful exploitation of this vulnerability requires that the Apache Piped Log Configuration is used (disabled by default).

и вот такие шедевры:

Mysql у них, подозреваю, тоже shared, а в нём 100500 дыр находили: http://secunia.com/community/advisories/search/?search=mysql

впрочем, те кто юзают selinux защищены неплохо

abftw (или его клон) спокойно обходил selinux.

Даже в 256 метров влезают и мускул, и апач и nginx (у меня такое чудо крутится) и с панелью управления (firstvds.ru, например).

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

эта минимум вторая.

Чем не подходит /tmp или /var/cache?

подходят

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

glibc что ли? да, интересно было.

как админ может выставлять наличие мускула на хосте как уязвимость.

Все юзеры пользуются одной базой. Поэтому когда возникают дырки типа такой злоумышленники могут упереть базу/поменять пароли/сделать админский вход на сайт итп: http://seclists.org/oss-sec/2012/q2/493

аа, вспомнил про этот забавный случай, прошу прощения.
https://rdot.org/forum/showthread.php?t=2218

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

ну я это собственно и имел ввиду, какая-то кривизна namespace.

И такая тенденция не есть хорошо. В /tmp принято скидывать различные временные проекты и результаты рендеринга а когда этот каталог принудительно перенесут в память то покупать 128Гб оперативы?

ох… Я не понимаю, про что ты вообще пишешь?

/tmp This directory contains temporary files which may be deleted with no notice, such as by a regular job or at system boot up.

он приводит вот такие аргументы:

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

уязвимость в получении рута.

из чрута выйти рутом можно было во все времена, это не баг, а фича.

ты вот много нафлудил, а знаниями не обладаешь. нехорошо это.

ох… Я не понимаю, про что ты вообще пишешь?

/tmp This directory contains temporary files which may be deleted with no notice, such as by a regular job or at system boot up.

глупый потому что, вот и не понимаешь. представь, что какая-нибудь проф. софтина наделает временных файлов на гигабайты (у аудио/видео софта это случается сплошь и рядом).

ох… Я не понимаю, про что ты вообще пишешь?

Некоторые редакторы по традиции при работе создают файлы в /tmp и наконец просто удобно рендерить туда видео. После нескольких перезагрузок всё невостребованное само почикается.

технически можно, практически - нет (я про крупных хостеров, с миллионами сайтов, а не локалхосты)

все там можно — есть xen-хостинги к примеру

но все равно — линуксовое ядро жиреет, и чем дальше, тем больше превращается в говновинду

а что еще ожидать от этого троечника торвальдса?! неужели правильного дизайна сетевой подсистемы?!

каков должен быть правильный дизайн:

1. libudp4, libtcpip4, libnat4, libsctp4, ... libupd6, libtcpip6, libsctp6, ... работающие в *пространстве пользователя*

2. со стороны ядра только *минимальная* поддержка, грубо говоря сводящаяся к *запретить* (и возможно к *перекинуть в другой канал*); это необходимо, скажем, для создания безопасных *локальных* сеток

т.е. ядро имеет понятие о ip-адресе интерфейса, дает минимальные средства управления того, что видно снаружи (скажем, выставить ip адрес), но основное, чем оно занимается — это (почти не глядя) перекидывает пакетики от скажем libtcpip4 на реальную железку либо к другому процессу (для логгинга скажем); при этом оно совершенно не интересуется содержимым пакета, за исключением *отдельных* полей пакета по *отдельным* смещениям — и это только для того, чтобы не выпустить в сеть пакет, скажем, с forged source IP address (и то, это отключаемо, т.к. м.б. нужно не всегда), от процесса с юзер-идом, которому запрещено лазить в сеть, пакет с неизвестным ядру протоколом (если у юзера нет таких привелегий) и т.п.

ядро *не делает* никаких выделений памяти, созданий хэш-массивов-по-ip-адресам, таблиц-mac-адресов и всего прочего, что может выжрать память и представляет хоть как-то сложную задачу

смещения отдельных полей в пакетах — это практически все, что нужно знать ядру, и таким образом оно становится непробиваемо (из сети) — т.е. рут исключен; кроме того, вполне возможно, юзеры для надежности захотят пускать libtcpip4 отдельным процессом, тогда взломщик вообще получает ровно то, что взломал — т.е. неперсистентный доступ в сеть (не сохраняющийся при перезапуске процесса)

бонусом идет профит по удобному тюнингу ip-стека под каждый процесс и легкому написанию своих кастомных протоколов; удобство учета ресурсов (просветите — можно ли сейчас ограничить *полный* размер памяти, занимаемый пакетами, лежащие в backlog-очереди интфейса, в зависимости от юзера, которому эти пакеты предназначены? а в зависимости от процесса, которому эти пакеты пришли? или же «защищенный» (бугага) линукс предоставляет каждому юзеру отличную возможность задосить тачку, выжрав всю память backlog-ом?)

интересует мнение собравшихся, в т.ч. tailgunner, true_admin, imul

глупый потому что, вот и не понимаешь. представь, что какая-нибудь проф. софтина наделает временных файлов на гигабайты (у аудио/видео софта это случается сплошь и рядом).

значит этой софтине нужен особый $TMP. Не вижу проблемы.

Некоторые редакторы по традиции при работе создают файлы в /tmp и наконец просто удобно рендерить туда видео. После нескольких перезагрузок всё невостребованное само почикается.

если этого не хочешь, есть

/var/tmp Like /tmp, this directory holds temporary files stored for an unspecified duration.

RTFM

т.е. ядро имеет понятие о ip-адресе интерфейса

Что за полумеры? Почему не Ethernet-интерфейс?

юзеры для надежности захотят пускать libtcpip4 отдельным процессом

Ты так говоришь, будто в твоей схеме у них есть выбор.

Ну а вообще, ты изобрел микроядро.

Это надо Эндрю кастовать. Он спец в микроядрах.

Что за полумеры? Почему не Ethernet-интерфейс?

ты читаешь что я пишу?

я УЖЕ объяснил почему — потому что для создания защищенной локалки может потребоваться не выпускать пакеты с forged source IP address, к примеру

Ты так говоришь, будто в твоей схеие у них есть выбор.

бугага! как будто сейчас у юзеров есть выбор, какие привилегии получит взломщик сетевого стека!

а в моей схеме действительно выбор есть

Ну а вообще, ты изобрел микроядро.

драйверы могут по-прежнему быть в ядре, так что это не микроядро

более того, все это похоже МОЖНО реализовать в линуксе, если оторвать ему сетевой стек

(но действительно, идея почерпнута из одного околомикроядерного пейпера, правда там она была несколько другой)

Это надо Эндрю кастовать. Он спец в микроядрах.

как я уже сказал, это не(совсем) микроядро

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

ну и насчет backlog-а — я тоже спрашиваю

Почему не Ethernet-интерфейс?

ты читаешь что я пишу?

Да. А ты думаешь над тем, что пишу я?

потому что для создания защищенной локалки может потребоваться не выпускать пакеты с forged source IP address, к примеру

И почему этим должно заниматься ядро, а не libip4.so?

а в моей схеме действительно выбор есть

Нету. Ибо:

www_linux_org_ru> ядро *не делает* никаких [...] таблиц-mac-адресов

драйверы могут по-прежнему быть в ядре, так что это не микроядро

У Mach драйвера в ядре, так что нерелевантно (у Hurd вроде тоже)).

все это похоже МОЖНО реализовать в линуксе

Можно, не вопрос. Идея библиотечного вертикально интегрированного стека всплывает периодически (там, конечно, более разумная архитектура, но тем не менее).

и так же — учитывает ли OOM-killer размер очереди в backlog-e?

Ты про ограничения полосы для конкретного пользователя? Надо посмотреть в ядре сейчас, что сделано на cgroup. Но, есть чудесный патч grsec.

как я уже сказал, это не(совсем) микроядро

А что?

И почему этим должно заниматься ядро, а не libip4.so?

facepalm.jpg

потому, что:

1. libip4.so в простанстве пользователя можеть героически пасть жертвой расстрела памяти

2. libip4.so может быть взломано, и необходимо, чтобы дальше в локалку взломщик пройти не смог

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

1. в чем там большая разумность?

2. ссылки

а в моей схеме действительно выбор есть

Нету. Ибо:

ядро *не делает* никаких [...] таблиц-mac-адресов

и где проблема?

Ты про ограничения полосы для конкретного пользователя? Надо посмотреть в ядре сейчас, что сделано на cgroup. Но, есть чудесный патч grsec.

нет, я про ограничение оперативной памяти, занимаемой backlog-ом

потому, что:

1. libip4.so в простанстве пользователя можеть героически пасть жертвой расстрела памяти

Ичо?

2. libip4.so может быть взломано, и необходимо, чтобы дальше в локалку взломщик пройти не смог

Почему тебя не волнует взлом libarp? libtcpip4?

ядро *не делает* никаких [...] таблиц-mac-адресов

и где проблема?

А давай ты расскажешь, как будет в твоей схеме резольвиться IP-адрес.

Сейчас не готов тебе что-то ответить. Надо смотреть как сейчас дела с tc и iptables. У меня в голове сильно неактуальные знания.

Я про то, что 3.8 — одно из самых проблемных ядер из ветки 3.х

libip4.so в простанстве пользователя можеть героически пасть жертвой расстрела памяти

Ичо?

и начнет хреначить левые пакеты; если ядро это обнаружит, то тут явный профит (можно сдампить память и перезапусить аппликуху или саму libip4.so, если она отдельным процессом)

а еще память libip4.so может быть похерена в результате взлома скажем веб-аппликухи, и опять профит в *минимальной* проверке со стороны ядра

Почему тебя не волнует взлом libarp? libtcpip4?

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

А давай ты расскажешь, как будет в твоей схеме резольвиться IP-адрес.

резольвиться в mac-адрес? зависит от системы; если скажем через arp, то очевидно через libarp

и начнет хреначить

И то же самое для всех остальных протоколов, но их поддержку ты в ядро не выносишь. Почему?

Почему тебя не волнует взлом libarp? libtcpip4?

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

См. выше.

резольвиться в mac-адрес?

Да.

если скажем через arp, то очевидно через libarp

Это не ответ. Где располагается libarp? Где располагаются ее кэши?

Ты копипастишь или переводишь?

И то же самое для всех остальных протоколов, но их поддержку ты в ядро не выносишь. Почему?

(фейспальм.джпг) я вынес в ядро ЧАСТИЧНУЮ ВАЛИДАЦИЮ (или верификацию) пакетов, а не поддержку протоколов

Это не ответ. Где располагается libarp? Где располагаются ее кэши?

в юзерспейсе конечно, но, согласен, тут надо подумать — есть разные варианты

самый простой и быстрый — сделать *локально* что-то типа ipv6, где афайк mac является частью адреса — т.е. вместе с каждым сисколлом к ядру «послать ip4 пакет» добавлять «по моим сведениям, вот его mac-адрес»; тут, понятно, *само* ядро не сможет полностью валидировать, но на это можно забить — так как по крайней мере ip-адрес отправителя левых пакетов будет честный (это уже гарантируется ядром), так что получатель не-туда-посланного-пакета сможет узнать, кто это там хулиганит с arp

можно чуть замедлить процесс путем обращения ядра к юзерспейсному arp-серверу, если нужно *такое* arp-security

update: можно подумать на тему: как выкладывать таблицу в разделяемом сегменте памяти, так что бы замедление было ничтожно