The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Хостинговая компания Hetzner уведомила клиентов о обнаружени..., opennews (ok), 07-Июн-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


19. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +1 +/
Сообщение от жопка3 (?), 07-Июн-13, 10:50 
http://0xfeedface.org/sites/default/files/2013%20Libhij...
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

30. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от Аноним (-), 07-Июн-13, 12:03 
> http://0xfeedface.org/sites/default/files/2013%20Libhij...

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

1) А что, ALSR там до сих пор не сделали что гражданин ищет ELF хидер по фиксированному адресу?

2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM этот номер не работает в силу технических особенностей :P].

3) Я не понял, а бсдшники что, до сих пор позволяют кому попало фигачить ptrace() вообще без ограничениий? В лине вон уже доперли что тут порыты некислые грабли и теперь на трассировку во всех культурных дистах по дефолту есть ограничения, в общем случае без проблем трейсить и дебажить может только рут. Остальное ... остальное надо явно разрешать, на свой страх и риск, скомандовав кернелу, что опять же может только рут. Продакшн серверам отладка от юзера не упала, так что -1 потенциально проблемная фича.

Ответить | Правка | Наверх | Cообщить модератору

60. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от vle (ok), 07-Июн-13, 13:43 
>> http://0xfeedface.org/sites/default/files/2013%20Libhij...
> Ага, неуловимых бсдшников оказывается вполне можно вполне красиво вздрючивать. Впрочем
> опсанные техники прменимы не только к *bsd.
> 1) А что, ALSR там до сих пор не сделали что гражданин
> ищет ELF хидер по фиксированному адресу?

В NetBSD ASLR, ты даже абревиатуру толком не знаешь, с 2004-ого года.
PIE тогда же. В OpenBSD  еще раньше.

> 2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM
> этот номер не работает в силу технических особенностей :P].

Это каких, например?

> 3) Я не понял, а бсдшники что, до сих пор позволяют кому
> попало фигачить ptrace() вообще без ограничениий?

Нет. В  NetBSD с помощью kauth(9) ptrace можно вообще запретить.
Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
даже от root-а. Плюс есть ограничения при разных security levels.

http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
http://wiki.netbsd.org/kernel_secure_levels/

Ответить | Правка | Наверх | Cообщить модератору

68. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  –1 +/
Сообщение от Аноним (-), 07-Июн-13, 14:01 

>[оверквотинг удален]
>> 2) Он что, изобрел довольно известный прикол класса ret2libc? [Кстати на ARM
>> этот номер не работает в силу технических особенностей :P].
> Это каких, например?
>> 3) Я не понял, а бсдшники что, до сих пор позволяют кому
>> попало фигачить ptrace() вообще без ограничениий?
> Нет. В  NetBSD с помощью kauth(9) ptrace можно вообще запретить.
> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
> даже от root-а. Плюс есть ограничения при разных security levels.
> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://wiki.netbsd.org/kernel_secure_levels/

Так всё-таки есть в BSD рандомизация.Встречал статейку Криса Касперски, где он
рассказывал о том, что с ней возятся в linux и win, в unix она с древнейших времён, а
в BSD с этим плохо.В NetBSD её нет вообще в free она не вменяема, только в OpenBSD есть,
но и там почти отключена по соображениям производительности.

Ответить | Правка | Наверх | Cообщить модератору

73. "Хостинговая компания Hetzner уведомила клиентов о..."  +1 +/
Сообщение от arisu (ok), 07-Июн-13, 14:13 
> Встречал статейку Криса Касперски

зачем ты такую херню читаешь?

Ответить | Правка | Наверх | Cообщить модератору

75. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от vle (ok), 07-Июн-13, 14:23 
>[оверквотинг удален]
>> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
>> даже от root-а. Плюс есть ограничения при разных security levels.
>> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
>> http://wiki.netbsd.org/kernel_secure_levels/
> Так всё-таки есть в BSD рандомизация.Встречал статейку Криса Касперски, где он
> рассказывал о том, что с ней возятся в linux и win, в
> unix она с древнейших времён, а
> в BSD с этим плохо.В NetBSD её нет вообще в free она
> не вменяема, только в OpenBSD есть,
> но и там почти отключена по соображениям производительности.

Гражданин хороший, ты несешь полный бред, абсолютно проитивоположный
действительности. Крис Касперски -- дебил, ты нашел кого читать.
Начнем с того, что рандомизация рандомизации рознь.
Тебе рандомизацию чего подать? ASLR/PIC? Она совершенно точно есть
в NetBSD и OpenBSD, во FreeBSD AFAIK нет, пусть меня поправят.
ASLR/PIC в OpenBSD таки включен по умолчанию, как в ключен по умолчанию
теперь уже в некоторых дистрибутивах Линупса,
в NetBSD он рыключен, ASLR включается sysctl, а PIE можно добиться
перекомпилированием системы, по умолчанию экзешники скомпилены без PIC.
То же касается pkgsrc -- все как у upstream-а, включен PIC -- будет,
нет -- досвидос.
Рандомизация pid при форках в OpenBSD AFAIK есть и по умолчанию включена.
Исторически в UNIX-ах никакой рандомизации как раз не было, посколько
не было position independent code до появления ELF. По этой же причине
ASLR нет в винде, там PIC нет ввиду убогово coff, адреса загрузки dll
определяются в момент компиляции.

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

77. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от Аноним (-), 07-Июн-13, 14:29 
> а PIE можно добиться перекомпилированием системы, по умолчанию
> экзешники скомпилены без PIC.

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

Ответить | Правка | Наверх | Cообщить модератору

83. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от vle (ok), 07-Июн-13, 15:17 
>> а PIE можно добиться перекомпилированием системы, по умолчанию
>> экзешники скомпилены без PIC.
> Все вы в этом. Такие вещи должны быть по дефолту.

Я с тобой согласен, но есть/были ТЕХНИЧЕСКИЕ причины, почему это выключено.
http://mail-index.netbsd.org/tech-security/2011/12/05/msg000...
В каком это сейчас статусе я не в курсе.

> Т.к. уповать на то что рядовой эксплуатационщик будет доктором
> наук - не приходится, отнюдь.

В отличие от Линукса NetBSD собирается с любыми опциями на любой
UNIX-like системе кроссово одной командой. Сборка системы
не требует докторской степени.

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

Ваше мнение очень важно для нас.

Ответить | Правка | Наверх | Cообщить модератору

90. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от Аноним (-), 07-Июн-13, 19:26 
> Я с тобой согласен, но есть/были ТЕХНИЧЕСКИЕ причины, почему это выключено.
> http://mail-index.netbsd.org/tech-security/2011/12/05/msg000...

Как это назвать? "Broken and Late, Ltd".

> В каком это сейчас статусе я не в курсе.

Если честно - я вообще не понял такое решение. Называя вещи своими именами, на серверах сейчас царит х86_64, у которого регистровый файл относительно нормальный и relative-адресация есть, по поводу чего PIC для него вообще не должен являть собой никаких проблем. Я конечно не занимался хардкорными бенчами, но особого падения скорости от PIC не заметил нигде так сходу. Тем более что чисто-локальные программы, не имеющие дел с внешним миром с ним можно и не собирать. Всякая околоэмбедовка - у ARM и MIPS все нормально с регистрами. В честь чего этот огород про архитектуры с куцым набором регистров?

> В отличие от Линукса NetBSD собирается с любыми опциями на любой
> UNIX-like системе кроссово одной командой.

Если честно - I don't care. Для вас это достоинство. Для меня - бесполезный артефакт. Я все-равно буду иметь дело с системой из-под нее самой. Потому что это right way of doing things на мое нескромное мнение.

> Сборка системы не требует докторской степени.

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

> Ваше мнение очень важно для нас.

А по бздам это заметно. Собственно, поэтому ими и пользуется горстка маргиналов. Остальные нашли себе более удобные и менее геморные системы. Благо бзды не единственные в мире, к счастью.

Ответить | Правка | Наверх | Cообщить модератору

143. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  –1 +/
Сообщение от linux must _RIP_ (?), 08-Июн-13, 18:24 

> Если честно - I don't care. Для вас это достоинство. Для меня
> - бесполезный артефакт. Я все-равно буду иметь дело с системой из-под
> нее самой. Потому что это right way of doing things на
> мое нескромное мнение.

Расскажите как там у linux с крос компиляцией? и почему redhat запрещает это делать - тоже расскажите (не поставляет пакеты и объявляет не поддерживаемым это).

Ответить | Правка | Наверх | Cообщить модератору

155. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от Аноним (-), 09-Июн-13, 00:33 
> Расскажите как там у linux с крос компиляцией?

Нормально. Я вот только что образ openwrt под мипс с x86_64 хоста себе зафигачил. Вполне себе кросскомпиляция. Как видите, все прекрасно работает. Там где это реально надо. Хотя можно и демонстративно истекать словесным поносом на форуме, тоже вариант.

> и почему redhat запрещает это делать
> - тоже расскажите (не поставляет пакеты и объявляет не поддерживаемым это).

Так у них и спросите. Могу предположить что их данный сценарий использования не интересует (они на эмбеддовку не метят в данный момент) и поэтому они не собираются кому-то что-то гарантировать на этот счет.

Ответить | Правка | Наверх | Cообщить модератору

76. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от Аноним (-), 07-Июн-13, 14:27 
> В NetBSD ASLR, ты даже абревиатуру толком не знаешь, с 2004-ого года.

Уел, бaстард. Я знаю что это и нафига, так что нефиг тут так нагло троллить.

> PIE тогда же. В OpenBSD  еще раньше.

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

> Это каких, например?

Там при переполнении проблематично скормить какие-то осмысленные аргументы вызываемой функции когда возврат делается. ARMовское ABI предполагает в общем случае передачу параметров в регистрах а не стеке (у ARM в отличие от x86 их довольно много). Если при атаке на стек в случае x86 можно и параметры переписать, то в ARM их надо в регистры впихнуть. А это вообще не адрес в памяти, над записью в регистры у атакующего нет прямого контроля. Это делает возврат в функцию с каким-то осмысленным результатом не то что совсем невозможным, но труднореализуемым и не гарантированным.

В лучшем случае, особо продвинутые хакеры умудряются нащупать последовательности кода которые можно подергать так чтобы ничего не испортилось + в конечном итоге в регистрах все-таки образовалось то что было надо. В этом случае ret2libc и тому подобное даже может прокатить. Однако это весьма трудоемко и наличие такого кода - из разряда "уж как повезет". Все это сильно задирает планку для этого класса атак на ARM. Такая вот маленькая интимная особенность ARM ABI, оказавшаяся недружественной к хакерам любящим дерг кода путем возврата на него.

>> попало фигачить ptrace() вообще без ограничениий?
> Нет. В  NetBSD с помощью kauth(9) ptrace можно вообще запретить.

В большинстве культурных дистров линя нынче трассирование процессов юзерем по дефолту вообще откушено (слишком уж много потенциальных проблем) и надо вообще явно разрешать юзеру трейсить свои процессы (что может сделать только рут, записав соотв. значение в файлик ядерного интерфейса). По дефолту трейсить может только рут. Что спасает от массы грабель. Как видите, у пингвиноидов настройки даже пожестче.

> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
> даже от root-а. Плюс есть ограничения при разных security levels.

Если вы хотели этим попонтоваться, LXC пожалуй попродвинутее будет с его виртуализацией неймспейсов всех мастей и прочая. Оно вообще ближе к независимым окружениям.

> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
> http://wiki.netbsd.org/kernel_secure_levels/

Ну ок, я должен признать что наезжать на вообще всех бсдшников за пофигизм в секурити - не очень правильно, некоторые все-таки не такие уж и пофигисты в вопросе. Тем не менее, я не вижу что из перечисленного было лучше чем в пингвине, откуда сделаны масштабные выводы о бОльшей защищенности. Пингвины популярны, так что их долбят довольно много. Поэтому от наиболее очевидных типовых напастей они защитились вполне на уровне.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

81. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  +/
Сообщение от vle (ok), 07-Июн-13, 15:13 
>> Это каких, например?
> Там при переполнении проблематично скормить какие-то осмысленные аргументы вызываемой
> функции когда возврат делается. ARMовское ABI предполагает в общем случае передачу
> параметров в регистрах а не стеке

Ok, спасибо. Я гляну на досуге, что там и как. С АРМ-ами дел не имею обычно.

>>> попало фигачить ptrace() вообще без ограничениий?
>> Нет. В  NetBSD с помощью kauth(9) ptrace можно вообще запретить.
> В большинстве культурных дистров линя нынче трассирование
> процессов юзерем по дефолту вообще
> откушено

Культурные дистры -- это какие? В Debian и RHEL я этого не наблюдаю.

>> Кроме того, по умолчанию запрещено трейсить процессы из chroot-а,
>> даже от root-а. Плюс есть ограничения при разных security levels.
> Если вы хотели этим попонтоваться

Нет. Попонтоваться -- это не ко мне. Я говорю о том, что кое-что сделано
в этом плане и в BSD тоже. Диалог должен быть познавательным для обеих сторон.
За писькомером не ко мне. И да, я в курсе и про lxc и про cgroups и про openvz.

>> http://netbsd.gw.com/cgi-bin/man-cgi?security++NetBSD-current
>> http://wiki.netbsd.org/kernel_secure_levels/
> Ну ок, я должен признать что наезжать на вообще всех бсдшников за
> пофигизм в секурити - не очень правильно, некоторые все-таки не такие
> уж и пофигисты в вопросе.

Прекрасно. Культурный диалог состоялся.

> Тем не менее, я не вижу
> что из перечисленного было лучше чем в пингвине, откуда сделаны масштабные
> выводы о бОльшей защищенности.

Я не утверждал, что в *BSD что-то лучше или хуже или лучше, чем в Линупсе.
Это твои фантазии ;-) Я лишь указал на документацию.

> Поэтому от наиболее очевидных типовых напастей они защитились вполне на уровне.

Я думаю, лучший в отрасли -- grsecurity, откуда собственно
многое в NetBSD и пришло. Но grsecurity в мире Линукса -- такая
же маргинальщина, как NetBSD для типичного Линукс-админа.
AFAIK его нет нигде кроме одного профиля Gentoo.

Ответить | Правка | Наверх | Cообщить модератору

87. "Хостинговая компания Hetzner уведомила клиентов о обнаружени..."  –1 +/
Сообщение от тупойвордфильтр (ok), 07-Июн-13, 18:47 
> Ok, спасибо. Я гляну на досуге, что там и как. С АРМ-ами дел не имею обычно.

На это дело можно найти энное количество материала у тех кто интересуется подобными трюками, есть минимум несколко более-менее похожих описаний как хакеры борятся (ну или по крайней мере пытаются) с подобной напастью. Обычно это достаточно замороченные фокусы с попытками сначала дергать какие-то фрагменты кода которые сделают что-то полезное и только потом удастся сделать возврат. Все это тот еще брейнфак и работоспособность такой атаки - очень зависит от внешних факторов, как то найдется ли в атакуемой программе вообще удобный для этого код. Приходит в голову что кроме PIE программам было бы некисло еще и трансформации кода делать, чтобы это дело еще больше усложнить :)

> Культурные дистры -- это какие? В Debian и RHEL я этого не наблюдаю.

На данный момент так делает даже обычная ширпотрeбная убунта и те кто на ней базируются, так что если кто отпускает тормоз медленнее чем они - вообще позор и стыдоба им. Вызовы типа ptrace() считались потенциальным источником проблем и нежелательных действий черт знает сколько времени. В ядре есть механизмы для этого.

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

Ну окей, я признал что наезд на "вообще все BSD" все-таки не очень удачный маневр.

> За писькомером не ко мне. И да, я в курсе и про lxc и про cgroups и про openvz.

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

> Прекрасно. Культурный диалог состоялся.

Ну во всяком случае лучше чем кидания какашками без аргументов.

> Это твои фантазии ;-) Я лишь указал на документацию.

А в чем пойнт? А указывал какой-то соседний гражданин.

> Я думаю, лучший в отрасли -- grsecurity,

По общей степени параноидальности в ее "классическом" виде - пожалуй. Хотя лично мне видится более перспективной рaспилoвка окружений на виртуалки по принципу "1 загoн на сервис". Ну в общем "жизнь после эры чрута". С точки зрения атакующего - ломать такое достаточно неудобно, опять же. Не то чтобы совсем невозможно, но опять же планка поднимается и ущерб минимизируется. Плюс контейнеры "по 1 на сервис" можно при желании довольно дотошно мониторить и отлавливать аномалии по каким-нибудь простым критериям типа "запустились утилиты, хотя httpd в приницпе не должен использовать ls" или "ой, а чего это у нас тут кто-то дергает ptrace()? У нас дебагера тут вообще нет!". Нечто такое сделали на codepad.org - там сначала фильтр сисколов, потом виртуалка. И да, там можно вполне себе севый код пинать. Лично мне вообще не удалось особо поразвлекаться - большинство интересных сисколов зарубается фильтром.

> откуда собственно многое в NetBSD и пришло. Но grsecurity в мире Линукса -- такая
> же мaргинальщина, как NetBSD для типичного Линукс-админа.

Зато в каждом линуксном ядре идет система контейнеров и виртуализатор в комплекте. Совершенно нахаляву и даже без лишних усилий - обычно в дистрах эти фичи ядра включены при сборке.

> AFAIK его нет нигде кроме одного профиля Gentoo.

Потому что действительно довольно маргинальная штука. Мне при нужде минимизировать урон от хакеров (защищать дырявый или пробэкдоренный сервис от самого себя будем считать делом тухлым) - проще просто на виртуалки или хотя-бы контейнеры распилить. Так чтобы проблемный сервис сидел в своей песочнице. Если уж его поимели - так поимели. А рут в контейнере/виртуалке мало что и кому дает. Там кроме проблемного сервиса который один фиг раздолбали и не должно ничего быть. Это просто если подумать "а как сделать так чтобы хакеры всерьез чертыхались при попытке серьезно долбить всю инфраструктуру".

p.s. я так и не понял - вот чего я тут ругательного сказал, что б-дский вордфильтр возбух?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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