forum.opennet.ru

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

Оглавление

В Glibc обнаружена серьезная уязвимость, opennews (ok), 19-Окт-10, (0) [смотреть все]

Оу, как страшно , KERNEL_PANIC (ok), 15:03 , 19-Окт-10, (1) –4 //

Покажи свой IP и ты узнаешь как страшно , вернее ты и не заметишь как всё закон, follow_me (?), 15:37 , 19-Окт-10, (7) –1 //

Я не замечу У меня фря и зфс, и такие глупости как один раздел под все файлы я , arcade (ok), 15:40 , 19-Окт-10, (10) //

Epic, epic, epic fail Hint 1 может быть, вам следует для начала научиться отли, User294 (ok), 15:48 , 19-Окт-10, (13) +16
Бага, к сожалению, не в ядре, а в glibc Что до FreeBSD, то по наличию мер предо, paxuser (?), 15:54 , 19-Окт-10, (14) –10

Обоснуете Или так, ваше личное мнение , butcher (ok), 16:15 , 19-Окт-10, (22) +3

Конечно обосную Во FreeBSD не ни аналогов W X, ни ASLR, ни PIE, даже возмоность, paxuser (?), 16:40 , 19-Окт-10, (33) +6

W X - технология, основанная на Х-бит Если так, то она есть - ею можно пользов, BigHo (?), 23:07 , 19-Окт-10, (100) +4

Не обязательно именно на аппаратный бит Суть именно в принципе 171 либо запис, PereresusNeVlezaetBuggy (ok), 00:06 , 20-Окт-10, (104) +2

В смысле тот, который nX AMD Xd INTEL Как его не назови, а суть одна Без его, BigHo (?), 01:03 , 20-Окт-10, (111)

gt оверквотинг удален Тут и возникает дилемма позволять использовать потенциа, PereresusNeVlezaetBuggy (ok), 01:42 , 20-Окт-10, (112)

Вот только в PaX почему-то такой дилеммы не вознает Этот рейс кондишен связан, paxuser (?), 02:19 , 20-Окт-10, (118) –2
Не в курсе был про такое поведение OpenBSD Видимо серьезный тон задает фон катег, BigHo (?), 03:19 , 20-Окт-10, (120)

Существует как минимум две альтернативных, архитектурно-зависимых реализаций W X, paxuser (?), 02:06 , 20-Окт-10, (114)

Аппаратная защита надежнее программной Одно дело если проц на уровне железа exc, User294 (ok), 17:21 , 20-Окт-10, (159)

Вы бы хоть с предметом ознакомились сначала Ну хотя бы в Википедию заглянули, е, PereresusNeVlezaetBuggy (ok), 17:38 , 20-Окт-10, (161)

И правда, про возможность поюзать CS чтобы сделать изоляцию я все-таки пробаклан, User294 (ok), 20:04 , 20-Окт-10, (166)

В защищённом режиме 8212 да, CS и SS нельзя произвольно менять Думаю, в рассы, PereresusNeVlezaetBuggy (ok), 21:08 , 20-Окт-10, (169)
Там в одних тестах на синтетике оверхед был до 36 В других хоть и тестировалис, paxuser (ok), 21:22 , 20-Окт-10, (170)

Зависит от того, что имеется ввиду под программной и под аппаратной защитой Сов, paxuser (?), 17:41 , 20-Окт-10, (163)

Все бы ничего, но в таковых средах, типа Java NET PHP whatever почему-то на, User294 (ok), 19:46 , 20-Окт-10, (165)

Java NET PHP - это разве маргинальные языки платформы Это угодные индустрии ко, paxuser (ok), 20:44 , 20-Окт-10, (168)

Возможно, в последних версиях FreeBSD действительно появился аналог W X, но я об, paxuser (?), 00:17 , 20-Окт-10, (106) +1

Про то и речь Только с уточнением результата - для AMD64 нормально работает В с, BigHo (?), 02:35 , 20-Окт-10, (119)

gt оверквотинг удален Да нет там никаких принципиальных различий, разница по с, paxuser (?), 03:58 , 20-Окт-10, (121) +2

s Реализация UDEREF вкратце описана Реализация UDEREF для amd64 вкратце описана , paxuser (?), 04:00 , 20-Окт-10, (122)
Более внятное описание USERCOPY из хелпа к конфигу By saying Y here the kernel w, paxuser (?), 04:19 , 20-Окт-10, (123)
Позвольте Вас дополнить и поправить Slo-Tech Could you please describe in few w, taaroa (ok), 13:14 , 24-Окт-10, (196)

Не совсем так Из интервью с самим pipacs I talked to a few friends about it an, paxuser (ok), 22:19 , 24-Окт-10, (197)

Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы Раньше - Fre, paxuser (?), 00:22 , 20-Окт-10, (107)

Ух ты, кажется я впервые в жизни вижу вменяемого пользователя Генту, способного , User294 (ok), 20:30 , 20-Окт-10, (167) –1

Что-то вы тут фантазируете ни по одному из пунктов не согласен 1 Да фряха значи, mma (?), 16:16 , 19-Окт-10, (23) –3

Она не только локальным подвержена - пользовательские процессы наиболее подверже, paxuser (?), 16:46 , 19-Окт-10, (37) +1

всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои при, тигар (ok), 16:54 , 19-Окт-10, (39) +1

Нет, не об этом речь Но если взломщик заполучил права обычного пользователя и з, paxuser (?), 16:59 , 19-Окт-10, (41) +1

дак а fbsd причем или в линаксах еще где-то между вышеописанными шагами чтение, тигар (ok), 17:02 , 19-Окт-10, (43) +1

В линуксе реализованы механизмы, затрудняющие и или предотвращающие экслпуатацию, paxuser (?), 17:12 , 19-Окт-10, (45)

Для ясности безопасность ванильного линукса лично я оцениваю очень низко там п, paxuser (?), 17:18 , 19-Окт-10, (46) +1
я пытаюсь понять зачем Вы пишете наборы фраз то PaX и Grsecurity то Она не тол, тигар (ok), 17:20 , 19-Окт-10, (48)

Нет, вы просто хамите и либо не желаете понять, либо не обладаете даже базовым п, paxuser (?), 17:26 , 19-Окт-10, (53)
знаете меня больше практика интересует Есть примеры Где посмотреть статисти, тигар (ok), 17:45 , 19-Окт-10, (58) +1
Вас не практика интересует, а некие примеры и статистика, которые в реальном мир, paxuser (?), 19:07 , 19-Окт-10, (73)
Все так и имеет место быть, и тем ни менее, в линухах рута получают чаще, чем во, Добрый Аноним (?), 21:25 , 19-Окт-10, (87) –1
Чаще или нет - меня, например, вообще не интересует Меня интересует, есть ли сп, paxuser (?), 22:30 , 19-Окт-10, (95)
Ну да, когда куча детей сует свой код в ядро, действительно защищаться нужно, пр, Добрый Аноним (?), 11:41 , 20-Окт-10, (130)
Еще один горе-аналитик Как обычно - с ТУПЫМИ ошибками Позор Интересно, а горе-, User294 (ok), 22:43 , 19-Окт-10, (98) +1
На этот счёт есть разные мнения http archives neohapsis com archives dailydav, paxuser (?), 23:15 , 19-Окт-10, (102)
юзер обиделся забавно можно, с этим кто-то спорит В линуксе, сейчас, дыры нах, Добрый Аноним (?), 11:46 , 20-Окт-10, (131)
Только в отличие от винды, у линукса уже есть стабильная, проверенная временем р, paxuser (?), 14:28 , 20-Окт-10, (141)
Вы же в курсе, что в винде тоже постоянно изобретают ловушки для своего кода , , Добрый Аноним (?), 14:41 , 20-Окт-10, (147)
Да, и я даже в курсе, у кого они списывают свои ловушки , а также почему у них , paxuser (?), 16:44 , 20-Окт-10, (155)
Хе, а вы мне уже начинаете нравиться , Добрый Аноним (?), 17:25 , 20-Окт-10, (160)
Обиделся На кого Я всего лишь не понимаю зачем надо выступать с горе-аналитик, User294 (ok), 15:41 , 20-Окт-10, (149)
Был бы я не добрый сегодня, я бы поругался конечно , но коли я уж добрый, опущ, Добрый Аноним (?), 16:36 , 20-Окт-10, (152)
Я немного вмешаюсь, простите Спам чаще валится с десктопов, потому что их горазд, paxuser (?), 17:15 , 20-Окт-10, (157)
s их гораздо меньше их гораздо больше , paxuser (?), 17:21 , 20-Окт-10, (158)
0xFF Зарегались бы вы, а Тогда вы смогли бы исправлять такое путем редакт, User294 (ok), 18:41 , 20-Окт-10, (164)
сразу видно высказывание человека, к-ый вообще не шарит в безопасности вам выш, blah (?), 01:01 , 20-Окт-10, (110)
погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши голо, тигар (ok), 22:12 , 19-Окт-10, (92)
Нет, вы поняли неправильно, вернее, вы занимаетесь казуистикой, наигранно делая , paxuser (?), 23:08 , 19-Окт-10, (101)
Вы сами то верите в то что понаписали И какие же это пользовательские процесс, Аноним (62), 18:20 , 19-Окт-10, (62)
Не верю, а знаю Любые, которые обрабатывают данные из внешних, потенциально опас, paxuser (?), 19:14 , 19-Окт-10, (75) +1
Yet another EPIC FAIL , User294 (ok), 21:10 , 19-Окт-10, (86)
Приведите статистику по дырам для Linux и FreeBSD для начала Быть может все эти, kshetragia (ok), 08:10 , 20-Окт-10, (125)
На статистику по дырам ориентироваться бессмысленно, т к в первую очередь на , paxuser (?), 14:34 , 20-Окт-10, (142)
Я про это и говорю Зачем городить огород раньше времени, если по факту дырыли, kshetragia (ok), 04:28 , 21-Окт-10, (180)
Я не специалист по безопасности, но kern securelevel 2, mount to read only - , kshetragia (ok), 04:32 , 21-Окт-10, (181)
Озвучьте предложение на Full-Disclosure или DailyDave, оговорите достойное возна, paxuser (ok), 06:39 , 21-Окт-10, (183)
Вы говорите совершенно об обратном и вдобавок питаете иллюзии о чистоте кода, ко, paxuser (ok), 06:31 , 21-Окт-10, (182)

А как оценивалось качество кода По какой методике , User294 (ok), 16:37 , 19-Окт-10, (30)
Почему к сожалению Что до FreeBSD, давеча писали про http www opennet ru op, QuAzI (ok), 11:17 , 20-Окт-10, (129) +1

Потому что ядро и так дырявое дыркой больше, дыркой меньше Знаете, у меня , paxuser (?), 14:24 , 20-Окт-10, (140) –1

Почему на второй машине не проявилась на дырявом же ProFTPd Извините, вы выше о, QuAzI (ok), 16:38 , 20-Окт-10, (153)

А я откуда знаю Но уж точно не потому, что между креслом и монитором находитесь, paxuser (?), 16:57 , 20-Окт-10, (156) +1

Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что именно Вы самый , QuAzI (ok), 23:00 , 20-Окт-10, (171) –2

Как ламер позорный, позволю себе всё же заметить, что тов paxuser 8212 дейст, PereresusNeVlezaetBuggy (ok), 23:51 , 20-Окт-10, (172)

Пардон Человек тут на пол темы расписал, как хорош PaX и патчи для linux на осн, QuAzI (ok), 01:10 , 21-Окт-10, (176)

Не пардон Вы до сих пор считаете, что я что-то расписывал в категориях хорошо-п, paxuser (ok), 01:31 , 21-Окт-10, (178)
А ничего что Grsecurity основан на PaX Это всё равно что написать PaX вместе с, QuAzI (ok), 08:27 , 21-Окт-10, (184)
зеваю Очередная несусветная глупость, уже даже почти немного смешная Логики п, paxuser (ok), 09:14 , 21-Окт-10, (186)

Где конкретно я хамил Это ваши фантазии и трусливая попытка прировнять надуманны, paxuser (ok), 00:17 , 21-Окт-10, (173)

А где конкретно я хамил, конкретно Вам до вашего треда о том что я хам У меня т, QuAzI (ok), 00:45 , 21-Окт-10, (174)

вы выше _орали_ про аппаратную реализацию, а аналоги использовать уже другой , paxuser (ok), 01:06 , 21-Окт-10, (175)
_орали_ - а как ещё назвать тучу постов выше _давайте, расхвалите мне её тут_- а, QuAzI (ok), 01:27 , 21-Окт-10, (177)
Высказывал мнение, аргументы, контраргументы, давал пояснения, повторял для особ, paxuser (ok), 01:51 , 21-Окт-10, (179)
Не похоже, ой не похоже , QuAzI (ok), 08:30 , 21-Окт-10, (185)
Ну вам виднее, конечно , paxuser (ok), 09:14 , 21-Окт-10, (187)
Можно немножко откровения Почему у Вас PaX даже в никнейме , QuAzI (ok), 16:21 , 21-Окт-10, (188)
Это скорее подпись, которая звучит проще, чем grsecuser или grsecurityuser, а су, paxuser (ok), 17:58 , 21-Окт-10, (189)

вот так, Аноним (-), 16:08 , 19-Окт-10, (19)
Сетка класса А 127 0 0 0 8, выбери любой из 16 777 214 айпишников , ы (?), 17:25 , 19-Окт-10, (51) –1
Твои пинги я действительно заметить не успею , Аноним2 (?), 19:41 , 19-Окт-10, (81)

LD_AUDIT ORIGIN exec proc self fd 3Inconsistency detected by ld so dl-op, V (??), 15:33 , 19-Окт-10, (5) +3 //

Аналогично, это в консольке, xterm просто закрылся может shell тоже имеет значе, h4tr3d (ok), 16:24 , 19-Окт-10, (25) //

Нет, перенаправь вывод ошибок в файл и увидишь то же самое, Rain (??), 16:40 , 19-Окт-10, (32) //

Можно просто шелл в шелле запустить Когда чайлдовый шелл помрет, вы вывалитесь , User294 (ok), 15:49 , 20-Окт-10, (151)

на шаге LD_AUDIT ORIGIN exec proc self fd 3 шелл упалдистр OpenSUSE 11 3, Аноним (-), 15:36 , 19-Окт-10, (6) +2 //

user0 homelinux uname -aLinux homelinux 2 6 35-ARCH шел упал аналогичн, killer1804 (??), 20:12 , 19-Окт-10, (83)

mkdir tmp exploit ln bin ping tmp exploit targetln создание жесткой ссылк, Egres (ok), 15:38 , 19-Окт-10, (8) //

и в логе такая штука tail -1 var log messagesOct 19 16 17 21 machine kernel , tallman (?), 17:24 , 19-Окт-10, (49)

Кстати, в Grsecurity по умолчанию включены запреты пользователям на создание хар, paxuser (?), 15:40 , 19-Окт-10, (9)
Исправления нет - как так , Аноним (-), 15:40 , 19-Окт-10, (11) //

Заголовок, обнаружена Вопросы , Andrey Mitrofanov (?), 16:36 , 19-Окт-10, (28)

В Gentoo у меня FEATURES sfperms , что ставит права go-r на все suid файлы Так , bircoph (?), 15:46 , 19-Окт-10, (12) //

У вас в Gentoo месяцами обновления безопасности не выпускаются - посмотрите хотя, paxuser (?), 15:57 , 19-Окт-10, (15) –2 //

emerge --sync по чаще делай, Аноним (-), 16:11 , 19-Окт-10, (20) +2 //

Между прочим, emerge --sync подвержен MitM-атакам Давно перешёл на emerge-webrs, paxuser (?), 16:20 , 19-Окт-10, (24)

Паранойя головного мозга во все поля , anonymous (??), 13:40 , 20-Окт-10, (136) –1

Блажен, кто верует, знание же преумножает скорбь , paxuser (?), 14:36 , 20-Окт-10, (143)

Я mysql не пользуюсь, так что меня это не волнует GLSA по критическим уязвимост, bircoph (?), 16:43 , 19-Окт-10, (34) //

О скорости выхода GLSA - это вы на gentoo-security расскажите, чтобы разработчи, paxuser (?), 16:49 , 19-Окт-10, (38)
Ну и аргументы , maxkit (ok), 19:18 , 19-Окт-10, (77)

на CentOS 5 сработало , Толстый (ok), 16:02 , 19-Окт-10, (16) +3
на третьем шаге уже не дает exec 3 tmp exploit target bash tmp exploit tar, Аноним (-), 16:03 , 19-Окт-10, (18) //

1, на двух гентах пытался, дома и на работе, Вова (?), 16:12 , 19-Окт-10, (21) +1 //

mkdir tmp exploit ln bin ping tmp exploit target , ozs (ok), 20:02 , 19-Окт-10, (82) +1 //

По умолчанию на Zenwalk 6 4 аналогично Если на bin ping рутом дать права на чте, Ytch (?), 22:37 , 19-Окт-10, (96)

Насквозь дырявое ядро, если при уязвимости в какой-нибудь библиотеке можно запол, svchost (ok), 16:29 , 19-Окт-10, (26) –2 //

Сильно не пинайте, но иногда такие мысли возникают В ХР необходимости не было по, Аноним (-), 16:38 , 19-Окт-10, (31)
вирусы типа kido отлично знают, в отличие от вас , name (??), 16:44 , 19-Окт-10, (35) +1
Господи, что вы там курите если не понимаете разницы между ядром и либой привиле, User294 (ok), 17:55 , 19-Окт-10, (59) +1
чтоб глупости в голову не лезли, нужно больше читать умных статей, например, htt, Зилибоба (ok), 18:41 , 19-Окт-10, (68) //

Server Error in technet Application Кажется, Вы запостили в этом URL е эксп, Пользователь Debian (?), 19:34 , 19-Окт-10, (79) //

точку в конце адреса убери, Аноним (-), 00:30 , 20-Окт-10, (108)
там точка в конце лишняя , Митра (?), 00:31 , 20-Окт-10, (109)

А это вообще лулзов пачка Более того - была еще фича предложить юзеру скача, User294 (ok), 22:26 , 19-Окт-10, (93) +1 //

ага, щаз читайте сводки уязвимостей не только с опеннета и будете знать что та , Добрый Аноним (?), 11:53 , 20-Окт-10, (133)

Во первых - была, а во вторых, пруф давайте , Зилибоба (ok), 13:42 , 20-Окт-10, (137)

Во первых не была , такие баги постоянно появляются от приложения к приложению , Добрый Аноним (?), 14:37 , 20-Окт-10, (144)

Не в лунухах , а в Debian Этот дистрибутив давно себя зарекомендовал , paxuser (?), 14:15 , 20-Окт-10, (139)

да какая разница главное, что это проблема не только вин система, как некоторые, Добрый Аноним (?), 14:40 , 20-Окт-10, (145)

Особенно порадовало отношение разработчиков glibc бага есть - ну есть, ну и на, Аноним (-), 16:31 , 19-Окт-10, (27) +3 //

линейкой по пальцам через интернеты , z (??), 16:45 , 19-Окт-10, (36)

Arch, при выполнении LD_AUDIT ORIGIN exec proc self fd 3 шелл просто падает, savant (ok), 16:37 , 19-Окт-10, (29)
В funtoo тоже suid бит для хардлинка не выставляется, поэтому не работает В deb, aNoN (?), 16:58 , 19-Окт-10, (40) //

Ога, с ассертом в libc , User294 (ok), 18:28 , 19-Окт-10, (63)
в Дебиане давно используется eglibc вместо классической libc, tamerlan311 (?), 18:34 , 19-Окт-10, (65) //

и несмотря на то, что eglibc всего лишь форк от glibc,в eglibc 2 11 2 экспло, Sylvia (ok), 18:46 , 19-Окт-10, (69)

mkdir tmp exploit ln bin ping tmp exploit target exec 3 tmp ex, Аноним (-), 17:01 , 19-Окт-10, (42) //

suid бинарник на который делается линк должен быть читаемымmode 4755 например, е, Sylvia (ok), 18:56 , 19-Окт-10, (71)

А презренные бубунты этот сплойт не пробирает Посему странно ждать исправлени, User294 (ok), 17:03 , 19-Окт-10, (44) //

с openSuSE аналогично - умирает шелл , Аноним (-), 17:30 , 19-Окт-10, (55)
Embedded GLIBC EGLIBC is a variant of the GNU C Library GLIBC that is design, anonymous (??), 17:31 , 19-Окт-10, (56) //

Спасибо, Кэп Но это не отменяет факта что приведенный эксплойт работает только , User294 (ok), 18:19 , 19-Окт-10, (61) //

Да, ошибаешься Тут дело не в glibc vs eglibc, а в опциях сборки -DNDEBUG убир, solardiz (ok), 17:41 , 20-Окт-10, (162) +1

LD_AUDIT ORIGIN exec proc fd 3bash proc 30974 fd 3 Permission denie, Аноним (-), 17:19 , 19-Окт-10, (47) //

а, нет, вру, дескриптор перепутал, assert срабатывает LD_AUDIT ORIGIN exec, Аноним (-), 17:25 , 19-Окт-10, (52)

ERROR ld so object ORIGIN cannot be loaded as audit interface cannot open , Аноним (-), 17:24 , 19-Окт-10, (50)
На Debian не работает Вывод RedHat дырявый - LD_AUDIT ORIGIN exec proc, прххффф (?), 17:30 , 19-Окт-10, (54) +2
в ubuntu 10 10 mkdir tmp exploit ln bin ping tmp exploit targetln создани, Аноним (-), 17:39 , 19-Окт-10, (57) //

жесткую ссылку можно сделать в пределах 1 устройства, у вас наверное tmp и bin, Sylvia (ok), 19:37 , 19-Окт-10, (80) //

у меня тоже ubuntu 10 10 tmp и bin на одном разделе то же самое выдает , val (??), 20:32 , 19-Окт-10, (84)

LD_AUDIT ORIGIN exec proc self fd 3Inconsistency detected by ld so dl-open, Vasily Pupkin (?), 18:34 , 19-Окт-10, (64)
В основной ссылке по новости есть второй метод атакиhttp seclists org fulldisc, Аноним2 (?), 18:35 , 19-Окт-10, (66) //

пробовали не работаетbash line 28 tmp exploit traget No such file or directo, Аноним (-), 18:53 , 19-Окт-10, (70) //

Что-то вы не то делаете видимо,но и у меня не получается Этокак раз способ для , Аноним2 (?), 19:15 , 19-Окт-10, (76) //

funtoo, glibc-2 11-r1Assertion failed, Аноним (-), 21:38 , 19-Окт-10, (88)
1 5559А что вот это 1 5559 , у меня пишет такая команда не найдена , ozs (ok), 21:55 , 19-Окт-10, (90)

Это Это - стопроцентный EPIC FAIL Хинт ввести выданные шеллом номер job , User294 (ok), 23:06 , 19-Окт-10, (99)

СпасибоОт этого никто не застрахован , ozs (ok), 02:11 , 20-Окт-10, (116)

1 5559 чей pid должен быть , ozs (ok), 02:17 , 20-Окт-10, (117)

sylvia evy var tmp pkill -n -t tty 124 sed s dev sleep-bash line, Sylvia (ok), 19:08 , 19-Окт-10, (74)
После выполнения pkill warning debug option nonsense unknown try LD_DEBUG he, AX (?), 19:21 , 19-Окт-10, (78)

У меня вообще ни на одной машине не получилось заэксплуатировать 1 У меня всё с, Vasily Pupkin (?), 18:41 , 19-Окт-10, (67)
Fedora12 получилось , Al1966 (?), 18:57 , 19-Окт-10, (72)
Вот, а кто-то мне тут рассказывал, что в линухах держать все на одном разделе мо, Добрый Аноним (?), 21:40 , 19-Окт-10, (89) +3
чето облом на 2й же команде ln bin ping tmp exploit targetln создание жесткой, i (??), 22:02 , 19-Окт-10, (91) +1
Опять этот SUID Ну и как всегда о сто и одном способе как получить линукс с , balex (??), 22:37 , 19-Окт-10, (97)
andrey evilhorse var run exploit ls -ld drwxrwxrwx 2 andrey andrey 4096 Окт , Аноним (-), 00:06 , 20-Окт-10, (103) //

если пофиксить права на bin ping Inconsistency detected by ld so dl-open c 23, Аноним (-), 00:13 , 20-Окт-10, (105)

тестовая система, собранна из исходников configure make make install, ни , Аноним (-), 01:48 , 20-Окт-10, (113)
CO5 i386 x86_64 - пашет на ураCO4 - не работаетНа CO5 мы уже собрали rpms patche, ifel (??), 02:08 , 20-Окт-10, (115)
мда, 2 ехплоита за один вечер, етот и http www exploit-db com exploits 15285 , d4r (?), 07:58 , 20-Окт-10, (124) //

user0 video_srv expl bin Linux kernel 2 6 30 RDS socket exploit , killer1804 (??), 08:35 , 20-Окт-10, (126) //

a out Linux kernel 2 6 30 RDS socket exploit by Dan Rosenberg R, Вова (?), 09:18 , 20-Окт-10, (127) //

ls -l bin pingесли для не юзера стоит r-x, эсплойт работает Мандривы, Федоры, , korrado (?), 09:44 , 20-Окт-10, (128)

в данной теме присутствуют два эксплойта, один скриптом вы о нём , другой прогр, Вова (?), 13:45 , 20-Окт-10, (138)

Что-то в Red Hat Enterprise Linux Server release 5 1 Tikanga работать не хотит, АнонимМ (?), 11:48 , 20-Окт-10, (132) //

Что-то у Вас в c file ошибка, а не работать не хочет Проверьте, что вставили в, ifel (??), 12:02 , 20-Окт-10, (134) //

Да правда ваша - работает , АнонимМ (?), 14:41 , 20-Окт-10, (146)

Умные люди давно следуют рекомендациям по безопасности например от NSA Открывае, TS (ok), 12:59 , 20-Окт-10, (135) +1
Ubuntu 10 04 moo moo LD_AUDIT ORIGIN exec proc self fd 3Inconsistency de, буба (?), 15:31 , 20-Окт-10, (148) //

CentOS 5 3 moo co53 LD_AUDIT ORIGIN exec proc self fd 3 root co53 , буба (?), 15:45 , 20-Окт-10, (150) //

После yum update glibc с версии 2 5 34 до 2 5 49 и пересборки эксплоит все-рав, буба (?), 16:42 , 20-Окт-10, (154) //

Сегодня вышел апдейт glibc, после которого LD_AUDIT ORIGIN exec proc self, буба (?), 18:41 , 21-Окт-10, (190)

I just can t create the link from bin ping to tmp exploit targetln creating h, Аноним (-), 20:26 , 21-Окт-10, (191)
Сегодня на grsecurity taviso kees we pwned you taviso check your mail , paxuser (ok), 00:18 , 22-Окт-10, (192) //

Да, второй раунд http lists openwall net full-disclosure 2010 10 22 15Исправл, solardiz (ok), 02:33 , 23-Окт-10, (193)

ln bin ping tmp exploit targetln создание жесткой ссылки tmp exploit target, Аноним (-), 06:07 , 23-Окт-10, (194) //

Для эксплуатации второй уязвимости хардлинки не нужны , paxuser (ok), 08:06 , 23-Окт-10, (195)

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

1. "В Glibc обнаружена серьезная уязвимость" –4 +/–

Сообщение от KERNEL_PANIC (ok), 19-Окт-10, 15:03

Оу, как страшно.

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

7. "В Glibc обнаружена серьезная уязвимость" –1 +/–

Сообщение от follow_me (?), 19-Окт-10, 15:37

Покажи свой IP  и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;)

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

10. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от arcade (ok), 19-Окт-10, 15:40

> Покажи свой IP  и ты узнаешь как страшно , вернее ты
> и не заметишь как всё закончится ;)
Я не замечу. У меня фря и зфс, и такие глупости как один раздел под все файлы я давно изжил. А в разделах в которые пользователь умеет писать нет suid файлов.
Хотя отношение разрабов не радует, давно такая бага в ядре и никто не зопатчил...

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

13. "В Glibc обнаружена серьезная уязвимость" +16 +/–

Сообщение от User294 (ok), 19-Окт-10, 15:48

> давно такая бага в ядре и никто не зопатчил...
Epic, epic, epic fail!
Hint #1: может быть, вам следует для начала научиться отличать ядро от glibc, а уже потом умничать начинать? :)
Hint #2: в природе, кстати,  есть более чем одна реализация libc. И ряд линухов пользуется ими. Потому что ядро и либцэ - "немного" разные вещи.

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

14. "В Glibc обнаружена серьезная уязвимость" –10 +/–

Сообщение от paxuser (?), 19-Окт-10, 15:54

Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD, то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и тем более от OpenBSD. Даже ванильный линукс дальше ушёл (но при этом качество кода ядра у него на уровне второй половины 90-ых - хуже, чем у любой из первой тройки *BSD).

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

22. "В Glibc обнаружена серьезная уязвимость" +3 +/–

Сообщение от butcher (ok), 19-Окт-10, 16:15

> Бага, к сожалению, не в ядре, а в glibc. Что до FreeBSD,
> то по наличию мер предотвращения эксплуатации уязвимостей она до сих пор
> находится на уровне года, эдак, 2001-го и отстаёт от NetBSD и
> тем более от OpenBSD.
Обоснуете? Или так, ваше личное мнение?

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

33. "В Glibc обнаружена серьезная уязвимость" +6 +/–

Сообщение от paxuser (?), 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 (?), 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), 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 (?), 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), 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 (?), 20-Окт-10, 02:19

> Тут и возникает дилемма: позволять использовать потенциально опасный, но как-то пашущий,
> код, или же принудить заменить его чем-то более безопасным, но не
> факт, что существующим... Не думаю, что тут есть простое универсальное решение.
Вот только в PaX почему-то такой дилеммы не вознает. ;)
> Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется
> обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных
> приложениях... :(
Этот рейс кондишен связан с уходом Provos'а и отсутствием других желающих реализовать lookaside-буфер в ядре, как в systrace для линукса. :)

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

120. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от BigHo (?), 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. Красивая задумка.

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

114. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 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. ;)
> последние детские илюзии! Тьфу на вас!" :)
Ваши слова всё сложнее воспринимать всерьёз.

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

159. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 20-Окт-10, 17:21

> Не обязательно именно на аппаратный бит.
Аппаратная защита надежнее программной. Одно дело если проц на уровне железа exception сразу по факту жахнет, и другое если софт программно отловит. Это и программно же надурить можно, и затратнее по ресурсам.
> Суть именно в принципе «либо запись, либо исполнение», конкретные
> реализации на разных платформах могут отличаться.
Но аппаратная как правило внушает больше доверия. Все-таки честная защита страниц памяти с различными атрибутами - одно, а ее программная эмуляция - совсем другое.
> в реальности паразитная нагрузка ниже,
А это как проверялось?
> работы осуществляется в рамках одной функции),
Звучит логично, кроме одного момента: а как определялось соотношение тех или иных операций?

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

161. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 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), 20-Окт-10, 20:04

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

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

169. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 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), 20-Окт-10, 21:22

> Думаю, в рассылках GCC можно поискать, я не заморачивался, так как не
> видел повода.
Там в одних тестах на синтетике оверхед был до 36%. В других хоть и тестировались реальные приложения и библиотеки, но в искусственных условиях, и оверхед был где-то в диапазоне 0.5-15%. В реальных условиях как правило всё упирается в IOOPS, PPS, CSPS и прочие страшные слова - хорошо помогает только оптимизация архитектуры, мультиплексирование, кэширование и более тщательный подход к выбору и настройке железа и ОС.

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

163. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 17:41

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

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

165. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 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), 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 (?), 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, поскольку мне с ней приходится более всего работать. Профессионалы
> знают недостатки тех систем, с которыми работают. Именно это их кормит.
> Хотел бы узнать, какими ОС вы занимаетесь?
Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач. И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно.

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

119. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от BigHo (?), 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 (?), 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 (?), 20-Окт-10, 04:00

s/Реализация UDEREF вкратце описана/Реализация UDEREF для amd64 вкратце описана/

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

123. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 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.

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

196. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от taaroa (ok), 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.

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

197. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 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 (?), 20-Окт-10, 00:22

> Хотел бы узнать, какими ОС вы занимаетесь?
Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы. Раньше - FreeBSD, OpenBSD и винда.

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

167. "В Glibc обнаружена серьезная уязвимость" –1 +/–

Сообщение от User294 (ok), 20-Окт-10, 20:30

> Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы.
Ух ты, кажется я впервые в жизни вижу вменяемого пользователя Генту, способного озвучить достаточно весомый аргумент в пользу своего выбора :).

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

23. "В Glibc обнаружена серьезная уязвимость" –3 +/–

Сообщение от mma (?), 19-Окт-10, 16:16

Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в основном как пакетогонялка, как дескто или интерактивные сервися ее мало
2)каковы критерии оценки качества кода ядер?

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

37. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от paxuser (?), 19-Окт-10, 16:46

> Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
> 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в
> основном как пакетогонялка, как дескто или интерактивные сервися ее мало
Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать универсальное применение, а не частные случаи.
> 2)каковы критерии оценки качества кода ядер?
Субъективно-эмпирические, с оглядкой на сложность кода с опубликованными уязвимостями (на сколько просто/сложно было не допустить ошибку, приведшую к уязвимости).

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

39. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от тигар (ok), 19-Окт-10, 16:54

>> Что-то вы тут фантазируете. ни по одному из пунктов не согласен.
>> 1)Да фряха значительно более подвержена локальным уязмимосятм но и и спользуется в
>> основном как пакетогонялка, как дескто или интерактивные сервися ее мало
> Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым
> атакам. О пакетогонялках расскажите, например, Сысоеву, и давайте будем рассматривать
> универсальное применение, а не частные случаи.
всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои привилегии до супер-пользователя, об этом же речь, да?

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

41. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от paxuser (?), 19-Окт-10, 16:59

> всеже хотелось бы увидеть пример при помощи которого я удаленно подниму свои
> привилегии до супер-пользователя, об этом же речь, да?
Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута получит, и руткит при желании повесит. Именно так они и работают.

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

43. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от тигар (ok), 19-Окт-10, 17:02

> Нет, не об этом речь. Но если взломщик заполучил права обычного пользователя
> и знает/умеет эксплуатировать неопубликованные уязвимости в ядре, то он и рута
> получит, и руткит при желании повесит. Именно так они и работают.
дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами "чтение молитв торвалцу" присутствует?

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

45. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 17:12

> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами
> "чтение молитв торвалцу" присутствует?
В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity - даже в большинстве) это позволяет свести более тяжкие последствия атак к DoS, а иногда и вовсе сделать атаку невозможной (как в случае с этой уязвимостью в glibc, например).

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

46. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от paxuser (?), 19-Окт-10, 17:18

Для ясности: безопасность ванильного линукса лично я оцениваю очень низко (там просто не реализовано почти никаких механизмов защиты от эксплуатации вечнодырявого ядра, а юзерспейс-защиты - эрзац даже тех, что есть в RHEL/CentOS, не говоря о PaX и Grsecurity), но тем не менее эксплуатация некоторых уязвимостей по сравнению с FreeBSD может быть значительно затруднена даже там.

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

48. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от тигар (ok), 19-Окт-10, 17:20

>> дак а fbsd причем? или в линаксах еще где-то между вышеописанными шагами
>> "чтение молитв торвалцу" присутствует?
> В линуксе реализованы механизмы, затрудняющие и/или предотвращающие экслпуатацию некоторых
> классов уязвимостей - в некоторых случаях (а с PaX и Grsecurity
> - даже в большинстве) это позволяет свести более тяжкие последствия атак
> к DoS, а иногда и вовсе сделать атаку невозможной (как в
> случае с этой уязвимостью в glibc, например).
я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и Grsecurity то
"Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым атакам" (она - fbsd, напомню на случай если Вы ошиблись с дозировкой и уже все забыли)
Вы можете внятно объяснить свои мысли как-то по другому? То что вы поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли, думаю.

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

53. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 17:26

> я пытаюсь понять зачем Вы пишете наборы фраз. то PaX и Grsecurity
Нет, вы просто хамите и либо не желаете понять, либо не обладаете даже базовым представлением.
> "Она не только локальным подвержена - пользовательские процессы наиболее подвержены удалённым
> атакам" (она - fbsd, напомню на случай если Вы ошиблись с
> дозировкой и уже все забыли)
FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity).
> Вы можете внятно объяснить свои мысли как-то по другому? То что вы
> поклоняетесь различным PaX, Grsecurity и прочим вещам уже давно все поняли,
> думаю.
Задавайте уточняющие вопросы - отвечу. Только без хамства, иначе отвечать не буду.

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

58. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от тигар (ok), 19-Окт-10, 17:45

> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации
> уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно
> с Hardened Gentoo (или другими системами на базе ядер с PaX
> и Grsecurity).
знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших утверждений?

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

73. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 19:07

> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших
> утверждений?
Вас не практика интересует, а некие примеры и статистика, которые в реальном мире никто не создаёт и не собирает, и на отсутствии которых можно сделать акцент, не так ли?
Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в т.ч. по именам) высказаться и/или дать материал к ознакомлению.

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

87. "В Glibc обнаружена серьезная уязвимость" –1 +/–

Сообщение от Добрый Аноним (?), 19-Окт-10, 21:25

>> знаете... меня больше практика интересует. Есть примеры? Где посмотреть статистику Ваших
>> утверждений?
> Вас не практика интересует, а некие примеры и статистика, которые в реальном
> мире никто не создаёт и не собирает, и на отсутствии которых
> можно сделать акцент, не так ли?
Все так и имеет место быть, и тем ни менее, в линухах рута получают чаще, чем во фрях и и линух не спасает ни одна защита, увы.

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

95. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 22:30

> Все так и имеет место быть, и тем ни менее, в линухах
> рута получают чаще, чем во фрях и и линух не спасает
> ни одна защита, увы.
Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть ли способы существенно, качественно усилить защиту ядра, и такие способы есть.

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

130. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Добрый Аноним (?), 20-Окт-10, 11:41

>> Все так и имеет место быть, и тем ни менее, в линухах
>> рута получают чаще, чем во фрях и и линух не спасает
>> ни одна защита, увы.
> Чаще или нет - меня, например, вообще не интересует. Меня интересует, есть
> ли способы существенно, качественно усилить защиту ядра, и такие способы есть.
Ну да, когда куча детей сует свой код в ядро, действительно защищаться нужно, причем защита может быть разная: а. не принимать код, б. городить огород из копий, дабы детский код не наподгадил. В линуксе выбирают второе. Все это конечно не говорит, о том, что, подстраховываться не нужно, но...

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

98. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от User294 (ok), 19-Окт-10, 22:43

> и тем ни менее,
Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор!
Интересно, а горе-аналитика не смущает что
1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти.
2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов должно быть больше. Чем больше система юзается, тем больше желающих ее поиметь.
3) Защиты - они разные бывают. Сильно разные. Ну вон ось от Рутковской - это тоже типа защита. Только там контейнеры - временные. Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное решение сможете изобразить? ;)

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

102. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 23:15

> Рутковской - это тоже типа защита.
На этот счёт есть разные мнения: http://archives.neohapsis.com/archives/dailydave/2010-q3/003...

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

131. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Добрый Аноним (?), 20-Окт-10, 11:46

> Еще один горе-аналитик. Как обычно - с ТУПЫМИ ошибками. Позор!
юзер обиделся :) забавно.
> 1) Если поискать про FreeBSD в новостях, можно тоже интересненького найти.
можно, с этим кто-то спорит?
> 2) Линух юзают побольше чем фрю как-то. Вроде логично что и взломов
> должно быть больше. Чем больше система юзается, тем больше желающих ее
> поиметь.
В линуксе, сейчас, дыры находят примерно с такой же частотой, как и в винде, следуя вашим же выводам, если линукс дорастет до винды, то рута там будут получать два раза в день, каждый раз через новые ошибки.
> 3) Защиты - они разные бывают. Сильно разные. Ну вон ось от
> Рутковской - это тоже типа защита. Только там контейнеры - временные.
> Ну раздолбали вы виртуалочку. А прога в оной доработала и контейнер
> убился. Вместе с вами и вашим доступом. Вы побыли рутом виртуалочки
> сколько-то минут. Ну, круто, ага. А на BSD такое же ультрапараноидальное
> решение сможете изобразить? ;)
А в миниксе надежность лучше, сможете изобразить так же?

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

141. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 14:28

> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и
> в винде, следуя вашим же выводам, если линукс дорастет до винды,
> то рута там будут получать два раза в день, каждый раз
> через новые ошибки.
Только в отличие от винды, у линукса уже есть стабильная, проверенная временем реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии событий,  откроется дорога во все дистрибутивы.

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

147. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Добрый Аноним (?), 20-Окт-10, 14:41

>> В линуксе, сейчас, дыры находят примерно с такой же частотой, как и
>> в винде, следуя вашим же выводам, если линукс дорастет до винды,
>> то рута там будут получать два раза в день, каждый раз
>> через новые ошибки.
> Только в отличие от винды, у линукса уже есть стабильная, проверенная временем
> реализация комплекснх механизмов защиты (PaX + Grsecurity), которой, при описанном развитии
> событий,  откроется дорога во все дистрибутивы.
Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для своего кода", только это не сильно помогает?

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

155. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 16:44

> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для
> своего кода", только это не сильно помогает?
Да, и я даже в курсе, у кого они списывают свои "ловушки", а также почему у них это плохо получается и почему хорошо получиться не может. ;)

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

160. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Добрый Аноним (?), 20-Окт-10, 17:25

>> Вы же в курсе, что в винде тоже постоянно изобретают "ловушки для
>> своего кода", только это не сильно помогает?
> Да, и я даже в курсе, у кого они списывают свои "ловушки",
> а также почему у них это плохо получается и почему хорошо
> получиться не может. ;)
Хе, а вы мне уже начинаете нравиться :)

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

149. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 20-Окт-10, 15:41

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

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

152. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Добрый Аноним (?), 20-Окт-10, 16:36

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

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

157. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 17:15

Я немного вмешаюсь, простите.
> намного больше. При том сервера - это очень интересные мишени. Мощные
> машины на толстых каналах с нефиговыми ресурсами. А не какие-то тормозные
> дслщики с глючным геймерским железом или там нетбуками вообще. А спам
> почему-то валится оптом именно с виндовых дслщиков. Ы?
Спам чаще валится с десктопов, потому что их гораздо меньше, чем серверов, они часто меняют айпишники (динамические) и наблюдают за ними гораздо мненее внимательно. Как правило в ДЦ вам заблокируют почтовые порты в первый же день после обнаружения потока спама, в свете чего даже полный контроль над сервером, неспособным рассылать спам и не содежращим ценной информации, не даёт взломщику практически ничего.
>> то рута там будут получать два раза в день, каждый раз через новые ошибки.
Я видел VPS-хостинги, где OpenVZ-ядра не обновляются от полугода до года (хотя бинарные обновления для них выходят регулярно и не требуют ручной установки). При этом в RBL адреса из их подсетей светятся не часто, т.к. спам просто блокируется по почтовым портам на телеком-оборудовании.
> Дык на линуксе нынче серверов стоит куда больше чем на винде. Почему
> их тогда не рутают по 2 раза на день? Предпочитая в
Да рутают их и по два, и по три раза в день. Хоть по тысячи, если эксплойт не нарушает консистентность структур и кода в ядре. Причина не только в качестве кода ядра, но и в нежелании добросовестно обслуживать серверы. Только пользы от этого коммерсантам от криминала чуть менее, чем никакой.
> основном гасить ламерье в винде сплойтами на древние непатченые версии флеша,
> абоб ридера и ишака. Как-то наблюдаемые факты не коррелируют с вашей
> теорией.
Вы сами себе ответили: десктопы взламывают чаще, потому что лёгких целей для атак там больше. Это дешевле и эффективнее.

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

158. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 17:21

s/их гораздо меньше/их гораздо больше/

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

164. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 20-Окт-10, 18:41

> s/их гораздо меньше/их гораздо больше/
[0xFF]: Зарегались бы вы, а? :) Тогда вы смогли бы исправлять такое путем редактирования комента вместо патча вторым коментом :) (для зареганых - коменты редактируемы 60 минут после написания). [/0xFF]

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

110. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от blah (?), 20-Окт-10, 01:01

сразу видно высказывание человека, к-ый вообще не шарит в безопасности...
вам выше расписали все фичи OpenBSD и Linux.
Фрю "реже" ломают потому что её инсталяций в разы меньше в мире, чем линукса.
Я был свидетелем 3 взломов линукс(в разных компаниях в разное время), причина банальна: пароль рута qwerty....

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

92. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от тигар (ok), 19-Окт-10, 22:12

> Однако если вас действительно интересует практика, поинтересуйтесь у практиков - у исследователей
> и пентестеров с мировыми именами. Для этого достаточно обратиться с вопросами
> в листы рассылки, вроде Full-Disclosure или bugtraq, и попросить подписчиков (в
> т.ч. по именам) высказаться и/или дать материал к ознакомлению.
погодите, если я понял правильно то Вы предлагаете мне самому доказать Ваши голословные утверждения. Я ведь правильно понял?
Напомню Ваше утверждение: "FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей к выполнению произвольного кода по сравнению с линуксом и особенно с Hardened Gentoo (или другими системами на базе ядер с PaX и Grsecurity)."
p.s. раз уж зашла речь о пентестерах.. Вы чем-то/кем-то можете представиться?;)

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

101. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 19-Окт-10, 23:08

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

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

62. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Аноним (62), 19-Окт-10, 18:20

> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены
> эксплуатации
Вы сами то верите в то что понаписали ???
И какие же это пользовательские процессы ??? WWW ?
Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки или фряха
Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки
Может в линухах и побольше средств для безопасности но так или иначе несмотря на то что код во FreeBSD хоть и похуже но на внешние воздействия из коробки более стойкая система

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

75. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от paxuser (?), 19-Окт-10, 19:14

>> FreeBSD не только подвержена локальным уязвимостям больше, чем тот же Hardened Gentoo
>> с полноценным набором механизмов защиты ядра, но и пользовательские процессы (сетевые
>> сервисы, клиентские приложения) во FreeBSD больше (чаще, быстрее, проще) подвержены
>> эксплуатации
> Вы сами то верите в то что понаписали ???
Не верю, а знаю.
> И какие же это пользовательские процессы ??? WWW ?
Любые, которые обрабатывают данные из внешних, потенциально опасных источников.
> Руки подтачите под FreeBSD а потом разглогольствуйте что безопаснее линух из коробки
> или фряха
Вы мне ещё похамите и поуказывайте - это придаст особый вес вашим словам.
> Я не говорю про всякие SeLinux/Jail я говорю именно система из коробки
И я говорю о системах из коробки. К примеру, CentOS - это что, по-вашему?
> Может в линухах и побольше средств для безопасности но так или иначе
Дело не в количестве, а в качестве и полноте. В ванильном ядре с количеством проблем нет, а вот качество и полнота оставляют желать намного лучшего.
> несмотря на то что код во FreeBSD хоть и похуже но
Код во FreeBSD, на мой взгляд, получше, о чём я уже сказал.
> на внешние воздействия из коробки более стойкая система
Это ничем не обоснованное утверждение.

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

86. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 19-Окт-10, 21:10

> Руки подтачите
Yet another *EPIC* FAIL!

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

125. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от kshetragia (ok), 20-Окт-10, 08:10

> во FreeBSD больше (чаще, быстрее, проще) подвержены эксплуатации уязвимостей
Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может все эти механизмы не так уж и нужны в настоящий момент.

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

142. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (?), 20-Окт-10, 14:34

> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может
> все эти механизмы не так уж и нужны в настоящий момент.
На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё влияет популярность данной ОС и желание отдельных людей и организаций заниматься поиском уязвимостей данной ОС. Есть другие ориентиры: типобезопасность языка, наличие в команде разработчиков активных экспертов по безопасности, влияние модели разработки на ситуацию с безопасностью, сама политика реагирования на инциденты, связанные с безопасностью и т.д. По этим параметрам ни FreeBSD, ни ванильный линукс ничем особо похвастаться не могут - скорее, наоборот. Но в отличие от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.

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

180. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от kshetragia (ok), 21-Окт-10, 04:28

>> Приведите статистику по дырам для Linux и FreeBSD для начала. Быть может
>> все эти механизмы не так уж и нужны в настоящий момент.
> На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё
> влияет популярность данной ОС и желание отдельных людей и организаций заниматься
> поиском уязвимостей данной ОС.
  Я про это и говорю. Зачем городить огород раньше времени, если по факту дыры
либо никто не ищет, либо они закрываются другими методами(например чистотой кода).
Все эти механизмы выглядят скорее костылями.
>Есть другие ориентиры: типобезопасность языка,
С этим хорошо пожалуй только в линейке модула/оберон(из тех о чем слышал я)
>наличие в команде разработчиков активных экспертов по безопасности,
имеются
> влияние модели разработки на ситуацию с безопасностью
  соборная модель выглядит предпочтительнее базарной с этой точки зрения.
> сама политика реагирования на инциденты, связанные с безопасностью и т.д.
  обычная политика. дыры латаются быстро, выпускается отдельный патч.
> По этим параметрам ни FreeBSD, ни ванильный линукс
> ничем особо похвастаться не могут - скорее, наоборот. Но в отличие
> от FreeBSD, у линукса есть сторонние активные эксперты-разработчики.
  Может. Модель разработки и институтские корни. Я больше доверяю экспертам от
науки.

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

181. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от kshetragia (ok), 21-Окт-10, 04:32

Я не специалист по безопасности, но..
kern.securelevel=2, mount / to read only - ломайте.

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

183. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 06:39

> kern.securelevel=2, mount / to read only - ломайте.
Озвучьте предложение на Full-Disclosure или DailyDave, оговорите достойное вознаграждение, и всё вам сломают. :)

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

182. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 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. Жаль, что об оберонах вы всего лишь слышали.

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

30. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от User294 (ok), 19-Окт-10, 16:37

А как оценивалось качество кода? По какой методике?

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

129. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от QuAzI (ok), 20-Окт-10, 11:17

Почему "к сожалению" ?
Что до FreeBSD, давеча писали про http://www.opennet.ru/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 применима?

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

140. "В Glibc обнаружена серьезная уязвимость" –1 +/–

Сообщение от paxuser (?), 20-Окт-10, 14:24

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

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

153. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 20-Окт-10, 16:38

>> Мне почему-то кажется что безопасность зависит в первую очередь от того
>> что между клавой и стулом.
>В первую очередь - совершенно согласен. На примере уязвимости в glob() это хорошо видно: >вот у вас ProFTPd и "бага проявилась". ;)
Почему на второй машине не проявилась на дырявом же ProFTPd ?
Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой темы разговор, ведь вы именно эту фичу тут хвалите, так давайте, расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или всё-таки нет?
В конце концов в первом же его описании написано: PaX напрямую не предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные, связанные с ним, ошибки разработчиков.
Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов, а затем их обновлять на миллионах машин.
> Какая именно "эта бага"?
Обсуждаемая разумеется.

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

156. "В Glibc обнаружена серьезная уязвимость" +1 +/–

Сообщение от paxuser (?), 20-Окт-10, 16:57

> Почему на второй машине не проявилась на дырявом же ProFTPd ?
А я откуда знаю? Но уж точно не потому, что между креслом и монитором находитесь вы.
> Извините, вы выше орали про аппаратную реализацию, а "аналоги" использовать уже другой
Не извиню. После "извините" вы продолжаете бессовестно хамить.
> темы разговор, ведь вы именно эту фичу тут хвалите, так давайте,
Я ничего не хвалю, я высказываю своё мнение и опровергаю бред, подобный тому, который вы здесь, не стесняясь своей глупости, пишете.
> расхвалите мне её тут. В частности, обсуждаемую уязвимость она отлавливает или
> всё-таки нет?
Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> В конце концов в первом же его описании написано: PaX напрямую не
> предотвращает переполнение буфера, а лишь пытается эффективно пресечь потенциальные,
> связанные с ним, ошибки разработчиков.
Пресечь не ошибки разработчиков, а попытки эксплуатации ошибок.
> Мне кажется вполне эффективно исправить одну глобальную либу, чем переписывать сотни дистрибутивов,
> а затем их обновлять на миллионах машин.
Вы либо вообще не понимаете, о чём говорите, либо выражаетесь настолько бессвязно, что понять вас невозможно.
>> Какая именно "эта бага"?
> Обсуждаемая разумеется.
Вами обсуждаемая или в новости? От баги в glibc, независимо от наличия у атакующего прав чтения экзешника с suid-битом, защищают ограничения на создание хардлинков, реализованные в Grsecurity. А бага в glob() не приводит к компрометации. К тому же в нормальных, а вернее, в нормальном фтп-сервере - vsftpd - она отсутствует.

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

171. "В Glibc обнаружена серьезная уязвимость" –2 +/–

Сообщение от QuAzI (ok), 20-Окт-10, 23:00

> Не извиню. После "извините" вы продолжаете бессовестно хамить.
Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули себе PaX и несут бред.
> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
Ну ну, вы ещё напишите что это фича такая и что её внедрять надо, а то мы тут бред несём, защищаться от этого хотим.
От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу в / делать (причём в линухе это тоже прописаня истина, если Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все остальные ftp-сервера ненормальными судя по вашей же цитате? А то что бага в glob() влияет не только на ftp-сервер вы вообще в курсе?

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

172. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 20-Окт-10, 23:51

>> Не извиню. После "извините" вы продолжаете бессовестно хамить.
> Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что
> именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая
> доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули
> себе PaX и несут бред.
Как ламер позорный, позволю себе всё же заметить, что тов. paxuser — действительно самый адекватный в этой ветке.
>> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> Ну ну, вы ещё напишите что это фича такая и что её
> внедрять надо, а то мы тут бред несём, защищаться от этого
> хотим.
Ну, по крайней мере вы сейчас действительно бред несёте, с этим спорить не буду.
> От баги в glibc можно защититься прочитав нормальный хендбук - нечего юзерспейсу
> в / делать (причём в линухе это тоже прописаня истина, если
> Вы не домохозяйка мигрирующая с винды).
Ну будет — в случае того же анонимного FTP — chroot в /home/ftp, что изменится? Вы смешны.
> Кроме vsftpd вы считаете все
> остальные ftp-сервера ненормальными судя по вашей же цитате?
Если все остальные сливают ему в данном аспекте, то — да, vsftpd будет самым нормальным.
> А то что бага в glob() влияет не только на ftp-сервер вы вообще в
> курсе?
Вы вообще дальше своего носа видеть умеете?

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

176. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 21-Окт-10, 01:10

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

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

178. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 01:31

> Пардон? Человек тут на пол темы расписал, как хорош PaX и патчи
> для linux на основе того же PaX, а потом сам же
Не пардон. Вы до сих пор считаете, что я что-то расписывал в категориях хорошо-плохо. И это ваши проблемы, ко мне претензии не по адресу.
> сказал что в принципе от конкретной уязвимости он не спасает. Почему
Опять категории: спасает-не спасает. Вам, таки пардон, сколько лет? Не стыдно так поверхностно и грубо мыслить?
PaX (особенно вместе с Grsecurity) часто "спасает" от компрометации, лишь в редких случаях "спасает" от DoS, но в основном он как раз сводит к DoS последствия от атак, которые в противном случае были бы более тяжкими: компрометация системы, повреждение и утечки данных.
> бы с ним не пофлеймить на эту тему, пока те кто
На имиджборды идите флеймить.
> шарит (без моей и его помощи) не поправят существующий код избавив
Без вашей уж точно.
> от уязвимости всех? Я прекрасно понимаю что человек не машина, но
Бла-бла-бла...
> проталкивать подпорки "чтобы хоть как-то не рассыпалось" вместо усиления средств разработки
> и отладки как-то грустно.
Морали надо было читать 40 лет назад Ричи и Томпсону, теперь - только плакать, колоться и есть кактус.

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

184. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 21-Окт-10, 08:27

> PaX (особенно вместе с Grsecurity)
А ничего что Grsecurity основан на PaX? Это всё равно что написать "PaX вместе с PaX это и есть PaX".
Вы так увлеклись этими двумя словами что уже просто не знаете куда их всунуть чтобы побольше?

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

186. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 09:14

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

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

173. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 00:17

>> Не извиню. После "извините" вы продолжаете бессовестно хамить.
> Неа, бессовестно хамите тут как раз Вы, но очень уж уверены что
Где конкретно я хамил?
> именно Вы самый умный, а все остальные (начиная с BSD-шников, заканчивая
> доброй половиной линуксовых дистрибутивов) просто ламеры позорные, раз ещё не всунули
> себе PaX и несут бред.
Это ваши фантазии и трусливая попытка прировнять надуманный снобизм к хамству, чтобы оправдать своё хамство.
>> Уязвимость в glob() - логическая и не приводит к компрометации. От чего защищать?
> Ну ну, вы ещё напишите что это фича такая и что её
> внедрять надо, а то мы тут бред несём, защищаться от этого
> хотим.
А зачем мне бред писать? Сами справляетесь.
> От баги в glibc можно защититься прочитав нормальный хендбук - нечего
Не всегда. Например, не на легковесном VPS.
> юзерспейсу
Очередная глупость.
> в / делать (причём в линухе это тоже прописаня истина, если
> Вы не домохозяйка мигрирующая с винды). Кроме vsftpd вы считаете все
> остальные ftp-сервера ненормальными судя по вашей же цитате? А то что
Да, все прочие, знакомые мне полнофункциональные фтп-серверы я считаю ненормальными (плохо спроектированными и написанными).
> бага в glob() влияет не только на ftp-сервер вы вообще в
> курсе?
Вы сами-то в курсе, где, на что и как она "влияет"?

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

174. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 21-Окт-10, 00:45

А где конкретно я хамил, конкретно Вам до вашего треда о том что я хам? У меня тоже такой своеобразный "надуманный снобизм", если это теперь так модно называть.
>> От баги в glibc можно защититься прочитав нормальный хендбук - нечего
>Не всегда. Например, не на легковесном VPS.
Удачная шутка на ночь глядя.
Если все так плохо спроектированы и написаны, напишите правильный ftp-сервер, раз вы видите "правильный" вариант. Вам потом спасибо скажут. Меня например vsftpd не устроил, да и не только меня судя по спискам компаний, чьи сервера были среди заявленных как уязвимые.

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

175. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 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), 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), 21-Окт-10, 01:51

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

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

185. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 21-Окт-10, 08:30

> Знаете, у меня тоже есть дела поважнее
Не похоже, ой не похоже.

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

187. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 09:14

>> Знаете, у меня тоже есть дела поважнее
> Не похоже, ой не похоже.
Ну вам виднее, конечно. :)

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

188. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от QuAzI (ok), 21-Окт-10, 16:21

Можно немножко откровения? Почему у Вас PaX даже в никнейме?

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

189. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от paxuser (ok), 21-Окт-10, 17:58

> Можно немножко откровения? Почему у Вас PaX даже в никнейме?
Это скорее подпись, которая звучит проще, чем grsecuser или grsecurityuser, а суть отражает примерно ту же, чтобы люди с толикой кругозора могли догадаться, что я пользуюсь тем, о чём говорю.

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

19. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Аноним (-), 19-Окт-10, 16:08

>позволяющая любому _локальному_ пользователю получить привилегии суперпользователя
вот так

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

51. "В Glibc обнаружена серьезная уязвимость" –1 +/–

Сообщение от ы (?), 19-Окт-10, 17:25

>Покажи свой IP  и ты узнаешь как страшно , вернее ты и не заметишь как всё закончится ;)
Сетка класса А: 127.0.0.0/8, выбери любой из 16'777'214 айпишников.

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

81. "В Glibc обнаружена серьезная уязвимость" +/–

Сообщение от Аноним2 (?), 19-Окт-10, 19:41

Твои пинги я действительно заметить не успею.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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


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


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


	120. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от BigHo (?), 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. Красивая задумка.
	Ответить \| Правка \| К родителю #112 \| Наверх \| Cообщить модератору


	114. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (?), 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. ;) > последние детские илюзии! Тьфу на вас!" :) Ваши слова всё сложнее воспринимать всерьёз.
	Ответить \| Правка \| К родителю #111 \| Наверх \| Cообщить модератору


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


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


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


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


	165. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от User294 (ok), 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), 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 (?), 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, поскольку мне с ней приходится более всего работать. Профессионалы > знают недостатки тех систем, с которыми работают. Именно это их кормит. > Хотел бы узнать, какими ОС вы занимаетесь? Профессионалы должны уметь подбирать инструмент, по совокупности качеств наиболее подходящий для решения конркетных задач. И по этому критерию, из-за априорных суждених о "ручниках" вне контекста задачи профессионала в вас узнать сложно.
	Ответить \| Правка \| К родителю #100 \| Наверх \| Cообщить модератору


	119. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от BigHo (?), 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 (?), 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 (?), 20-Окт-10, 04:00
	s/Реализация UDEREF вкратце описана/Реализация UDEREF для amd64 вкратце описана/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	123. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (?), 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.
	Ответить \| Правка \| К родителю #121 \| Наверх \| Cообщить модератору


	196. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от taaroa (ok), 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.
	Ответить \| Правка \| К родителю #121 \| Наверх \| Cообщить модератору


	197. "В Glibc обнаружена серьезная уязвимость"	+/–
	Сообщение от paxuser (ok), 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 (?), 20-Окт-10, 00:22
	> Хотел бы узнать, какими ОС вы занимаетесь? Сейчас - Hardened Gentoo и CentOS, очень редко другие дистрибутивы. Раньше - FreeBSD, OpenBSD и винда.
	Ответить \| Правка \| К родителю #100 \| Наверх \| Cообщить модератору