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

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

"Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
Сообщение от opennews (ok) on 27-Янв-15, 21:25
В системной библиотеке Glibc выявлена (http://openwall.com/lists/oss-security/2015/01/27/9) критическая уязвимость (CVE-2015-0235 (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235)), которая может использоваться для организации выполнения кода в системе и проявляется при обработке специально оформленных данных в функциях gethostbyname() и gethostbyname2(), которые используются во многих программах для преобразования имени хоста в IP-адрес. Для демонстрации уязвимости подготовлен рабочий прототип эксплоита, позволяющий организовать удалённое выполнение кода на почтовом сервере Exim, обойдя все доступные механизмы дополнительной защиты (ASLR, PIE, NX) на 32- и 64-разрядных системах. Проблема вызвана переполнением буфера в функции __nss_hostname_digits_dots(), используемой в  gethostbyname() и gethostbyname2(). Несмотря на то, что вызовы gethostbyname() и gethostbyname2() устарели, они продолжают применяться для преобразования имени хоста во многих актуальных приложениях, в том числе в серверных программах и привилегированных suid-утилитах. По степени опасности уязвимость, которая получила кодовое имя GHOST, сравнима с уязвимостями в Bash (http://www.opennet.me/opennews/art.shtml?num=40667) и OpenSSL (http://www.opennet.me/opennews/art.shtml?num=39518). Примечательно, что проблема присутствует в коде Glibc начиная с версии  2.2, выпущенной в ноябре 2000 года. При этом проблема была устранена (https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d...) в мае 2013 года без указания на то, что исправленная ошибка имеет отношение к серьёзным проблемам с безопасностью.  Glibc 2.18 и более новые выпуски не подвержены уязвимости. Уязвимость не проявляется в дистрибутивах, построенных на основе свежих версий Glibc, например, в последних версиях Fedora и Ubuntu. При этом, уязвимости подвержены длительно поддерживаемые промышленные дистрибутивы, которые требуют незамедлительного обновления. В частности, проблема проявляется в  Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 10.04 & 12.04, SUSE  Linux Enterprise 11. В настоящее время обновление уже выпущено для Ubuntu 10.04/12.04 (http://www.ubuntu.com/usn/usn-2485-1/), Debian 7 (https://lists.debian.org/debian-security-announce/2015/msg00...) и RHEL 7,6, (https://rhn.redhat.com/errata/RHSA-2015-0092.html)5 (https://rhn.redhat.com/errata/RHSA-2015-0090.html). На стадии подготовки обновления для  SUSE (http://lists.suse.com/pipermail/sle-security-updates/2015-Ja...) и CentOS (http://lists.centos.org/pipermail/centos-announce/2015-Janua...). URL: http://openwall.com/lists/oss-security/2015/01/27/9 Новость: http://www.opennet.me/opennews/art.shtml?num=41549
Ответить | Правка | Cообщить модератору

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

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

3. "Критическая уязвимость в Glibc, которая может привести к уда..."	–8 +/–
Сообщение от тигар (ok) on 27-Янв-15, 21:28
прелесть-то какая.и букавки интересные какие приведены, которые не смогли;( ASLR, PIE, NX
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	87. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
	Сообщение от Michael Shigorin (ok) on 28-Янв-15, 16:46
	> прелесть-то какая. Прелестная, угу -- но в альте год как исправлено: http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	95. "Критическая уязвимость в Glibc, которая может привести к уда..."	+3 +/–
	Сообщение от Andrey Mitrofanov on 28-Янв-15, 17:40
	>> прелесть-то какая. > Прелестная, угу -- но в альте год как исправлено: http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm... "без указания на то, что исправленная ошибка имеет отношение к серьёзным проблемам с безопасностью", да? +++Альт -- как Федора!
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	148. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Michael Shigorin (ok) on 31-Янв-15, 23:02
	>>> прелесть-то какая. >> Прелестная, угу -- но в альте год как исправлено: > "без указания на то, что исправленная ошибка имеет отношение > к серьёзным проблемам с безопасностью", да? Ровно потому, что на момент исправления это не было известно. > +++Альт -- как Федора! Не, в альте возможно скопировать (захардлинкать, если в терминах реализации) пакет из одного репозитория в другой при наличии необходимости (в данном случае ldv@ её озвучил как "испытываю непреодолимое желание обновить glibc", кажется) и прошедшей проверке на бинарную совместимость.  В федоре, насколько понимаю, такие обновления в любом разе порождают новую сущность.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	101. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от crypt (ok) on 28-Янв-15, 20:51
	На самом деле раздули из мухи слона ("Опасность! Опасность! apache, nginx и все сервисы уязвимы!"). Если полностью прочесть оригинальный пост, то, очевидно, что это скорее exim опять "повезло". А вот Solar Designer респект за аудит исходного кода.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	103. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от EHLO on 28-Янв-15, 22:19
	Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю>
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	115. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Andrey Mitrofanov on 29-Янв-15, 09:36
	> Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю> Эк ты glibc-то сурово. </и нет это функция _не экзима>
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	127. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от EHLO on 29-Янв-15, 12:03
	>> Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю> > Эк ты glibc-то сурово. </и нет это функция _не экзима> Правдоруб</khule>. Дали повод.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	122. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 11:16
	> прелесть-то какая.и букавки интересные какие приведены, которые не смогли;( ASLR, PIE, NX Недолго кисо злорадствовало :) http://www.opennet.me/opennews/art.shtml?num=41561
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

18. "Критическая уязвимость в Glibc, которая может привести к уда..."	–6 +/–
Сообщение от Аноним (??) on 27-Янв-15, 22:45
> Уязвимость не проявляется в дистрибутивах, построенных на основе свежих версий Glibc, например, в последних версиях Fedora и Ubuntu. Ох уж эти минное поля! Совсем не то, что нормальные, стабильные, безопасные дистрибутивы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от nbrk on 27-Янв-15, 23:56
	Это Вы про BSD Unix?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Критическая уязвимость в Glibc, которая может привести к уда..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 00:07
	Осталось только найти этот мифический BSD Unix. А что, хоть один BSD смог сертифицироваться как Unix? Или это "поди туда, не знаю куда, возьми то не знаю что"? А так то спецам по безопасности из фрибзды сервера сломал троянец помнится. А какой-нибудь опенок - как бункер на километровой глубине. Т.е. годится только для сильно некотрых целей.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	52. "Критическая уязвимость в Glibc, которая может привести к уда..."	–5 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 09:41
	> Осталось только найти этот мифический BSD Unix. А что, хоть один BSD > смог сертифицироваться как Unix? МакОС кажется с 10-й версии 100% Unix Compatible. Ядро там вроде как BSD или почти BSD, как и некоторые остальные компоненты. Так что вопрос только в желании и наличии денег...
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	54. "Критическая уязвимость в Glibc, которая может привести к уда..."	+4 +/–
	Сообщение от ДяДя on 28-Янв-15, 10:26
	Ядро не BSD
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	55. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
	Сообщение от iZEN (ok) on 28-Янв-15, 10:28
	> МакОС кажется с 10-й версии 100% Unix Compatible. Ядро там вроде как BSD или почти BSD, как и некоторые остальные компоненты. Так что вопрос только в желании и наличии денег... ///---https://ru.wikipedia.org/wiki/OS_X OS X значительно отличается от предыдущих, «классических» версий Mac OS. Основа системы — POSIX-совместимая операционная система Darwin, являющаяся свободным программным обеспечением. Её ядром является XNU, в котором используется микроядро Mach и стандартные сервисы BSD. ---///
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	104. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 06:25
	> программным обеспечением. Её ядром является XNU, в котором используется микроядро Mach > и стандартные сервисы BSD. В результате получился некий самопальный гибрид. Который как таковой и не микроядро и не бзда. А то что у бздюков кода надергали - так на это вы, подстилочки, и нужны.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	120. "Критическая уязвимость в Glibc, которая может привести к уда..."	–3 +/–
	Сообщение от Гость (??) on 29-Янв-15, 10:16
	Лолка. У мамы своей спроси, что такое подстилка.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	123. "Критическая уязвимость в Glibc, которая может привести к уда..."	+4 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 11:18
	> Лолка. У мамы своей спроси, что такое подстилка. Что такое? У проприерасовского холуя взыграла гордость и он решил доказать всему миру что он целый коврик, а не какая-то там подстилка?!
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	125. "Критическая уязвимость в Glibc, которая может привести к уда..."	–3 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 11:34
	а у раба RMS - взыграла обида что кто-то более свободен чем он?
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	135. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 18:16
	> а у раба RMS - взыграла обида что кто-то более свободен чем он? А ну бы его нафиг - свободу поработительствовать, западлостроительствовать и делать окружаюшим гадости.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	134. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аннаним on 29-Янв-15, 17:10
	> А то что у бздюков кода надергали - > так на это вы, подстилочки, и нужны. А красно-шляпников уже что, победили? Больше не пытаются надуть сообщество напрямую?http://www.itworld.com/article/2748700/open-source-tools/red... http://lwn.net/Articles/430098/ И с busybox-ами ну никогда никаких проблем не было, да --http://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits =). А уж сколько инноваций оттуда (а так же от производителей всяких телевизоров, холодильников и NASов) пришло -- вообще не счесть, творения и допил на скорую руку силами 3,5 студентов^W индусов очень помогло сообществу!! Так же, кроме отменного качества кода, ЖПЛ предписывает все втыкать в нормальную репу на нормальный сервак, а не сливать все в 7z, попутно удаляя комментарии из своего кода и уж конечно же запрещяет тупо распечатать исходники и высылать их по первому требованию почтой :) Кстати, где собственно, улучшения ядра для линукс-серверов от гугла? А так же супербский-гугл-ФС, опять же, для линукс-серверов? Или гуглу можно ставить ДЖеПаЛ-Фанатов в любую позу -- ведь он такой сильный и нежный =)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	136. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 18:28
	> А красно-шляпников уже что, победили? Не знаю кого там кто победил, но GPLнутый код из линя бздельники уже накопипастили и при случае за это получат по щщам, вероятно. > И с busybox-ами ну никогда никаких проблем не было, да Чрезмерно наглых паразитов полезно иногда дустом посыпать. С точки зрения благополучия экосистемы в целом. > индусов очень помогло сообществу!! Ну вон подстилочки-освободители уж который год пыжатся "освободить". Но воз и ныне там - BSD-licensed альтернативы в глубокой зaднице и ими никто не пользуется даже несмотря на свободу жлобствовать. Да и бзды нынче применяет полтора недобитых проприераса, остальные дружно свинтили на пингвин. А просто потому что так возни меньше. > запрещяет тупо распечатать исходники и высылать их по первому требованию почтой :) Не уверен что это считается за исходники. GPL требует предоставить все инструменты для пересборки. Ну ок, если вы мне продемонстрируете пересборку программы из этого - я буду считать это за исходники. > улучшения ядра для линукс-серверов от гугла? $ git log | grep -i "@google.com" | wc -l 16019 Ну вот как-то так. Это примерно на 3.19-rc6, @google.com - используется только сотрудниками гугла. Подсчет конечно топорный, но в любом случае, 16К хитов вы там сами колупайте на предмет того для серверов это было или для чего там еще :) > Или гуглу можно ставить ДЖеПаЛ-Фанатов в любую позу Да вот помнится даже когда был ведроид 3, сорцы жали на все. Но сорцы ядра выдавали...
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	138. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аннаним on 29-Янв-15, 21:19
	>  но GPLнутый код из линя бздельники уже накопипастили Пруфцы будут? Или опять -- наглые бдуны содрали принцип загрузги кмс-драйверов, которые Ынтель в свое время пропихнул в Xorg и ведро линукса (и пилит до сих пор) -- причем всех несогласных оттуда[Xorg] быстренько вытурили и объявили запил коммуны^W "нормально работающего" Ксорга. Который так никто и не довел до ума (xspy 97го года как работал, так и работает, xsecurity тихонько умер, так и не родившись), зато вынудили всех "неЪ"-ОСников  запиливать интерфейсы линукса =) >> индусов очень помогло сообществу!! > Ну вон подстилочки-освободители уж который год пыжатся "освободить". > ... > А просто потому что так возни меньше. Т.е. по сабжу сказать нечего -- все ясно. Значит делать с помощью ЖПЛ кода миллиарды и фактически ничего не отдавать обратно -- нормально. Главное -- правильная идеология! > Не уверен что это считается за исходники. GPL требует предоставить все инструменты для пересборки Ну, вообще, ограничение только одно -- код должен быть "machine-readable". Т.е в принципе экзотика типа дискет и кассет должна прокатить :). Ну и сам код не обязательно открывать для ВСЕХ: http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePos... http://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedB... https://www.gnu.org/philosophy/selling.html >You can charge nothing, a penny, a dollar, or a billion dollars. It's up to you, and the marketplace, so don't complain to us if >nobody wants to pay a billion dollars for a copy. >The one exception is in the case where binaries are distributed without the corresponding complete source code. т.е код обязаны предоставить только тем, кому продают или отдают бинарники. > Подсчет конечно топорный, но в любом случае, 16К хитов вы Так где гугл-ФС, а?  http://en.wikipedia.org/wiki/Google_File_System Вангую, что и всего остального вы не скоро дождетесь =)
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	142. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 30-Янв-15, 22:34
	> Пруфцы будут? Всему свое время. Вы или сами найдете пруфы "по хорошему", потратив свое время и проявив компетенцию (тогда я так и быть покажу, ибо историю не перепишешь). Или при случае вляпаются проприерасы. Это уже обещает забавным зрелищем :P. > Или опять -- наглые бдуны содрали принцип загрузги кмс-драйверов, которые > Ынтель в свое время пропихнул в Xorg и ведро линукса Ох, камон, продолжайте в том же духе - минимум компетенции, максимум ЧСВ. А для тугих - прямым текстом: DRM+KMS - мощный бэкэнд. От иксов оно не зависит, так что чего ради так много buzz про xorg я не понимаю. Для лично меня xorg наименее интересная часть всего этого процесса. DDX драйвер для ускорения 2D в иксах тоже этим бэкэндом пользоваться может, но это так, до кучи. Основные улучшения - были отнюдь не там. > (и пилит до сих пор) -- причем всех несогласных оттуда[Xorg] быстренько вытурили И замечательно. Получился нормальный мощный и современный бэкэнд для графики к которому авторы всяких там MESA, DDX и прочая интерфейсятся и это более-менее отражает их пожелания. > тихонько умер, так и не родившись), зато вынудили всех > "неЪ"-ОСников  запиливать интерфейсы линукса =) И это правильно. Если кто не понял - линуксоиды собрали себе годный графический бэкэнд, к которому можно интерфейсить хоть там что. Хоть DDX драйвер иксов, хоть MESA, хоть что там еще (некоторые программы например умеют интерфейситься к этому напрямую). Я нахожу это логичным и фичастым, более-менее соответствующим современным реалиям (в плане устройства железа) и способным пользоваться фичами железа в его разных инкарнациях. От дубового контроллера дисплея до числокрушилки без видеовыхода, сплевывающей зарендереное исключительно в буфер в памяти :). Это должно быть сделано как-то именно вот так. И хорошо что нытиков "и так же работает" послали в пешее эротическое. Раз вам ничего улучшать не надо - ну вот и пользуйтесь иксами и драйверами десятилетней давности! А те кто пишет новые дрова - не подписывались плясать по старому. Вон амдшники ускорение иксов через 3D запилили. А вы там рассказывайте про то как вам 3D не надо, если хотите... > Значит делать с помощью ЖПЛ кода миллиарды и фактически ничего не отдавать Я не знаю про кого это. Кто сделал миллиарды на GPL и ничего не отдал? Покажите этих позорников. > Главное -- правильная идеология! Главное - результат. И если он таков что о вас вытирают ноги, вы таки коврики для ног. > Ну, вообще, ограничение только одно -- код должен быть "machine-readable". Т.е в > принципе экзотика типа дискет и кассет должна прокатить :). Большинству людей в здравом уме не хочется проверять какого мнения на этот счет судьи будут и поэтому они предпочитают не выеживаться. А кто сильно непонятливый - порой таки получает по сусалам в судах. Автор бизибокса подтвердит ;). > сам код не обязательно открывать для ВСЕХ: Ну естественно, его надо показать только тем кто получил бинарь. По поводу чего многие вендыри предпочли по хорошему выкладывать GPL tarball заранее. От суда и репутация подмокает, да и решения зачастую выходят не в пользу тех кто решил поиграть с авторским правом в кошки-мышки. > т.е код обязаны предоставить только тем, кому продают или отдают бинарники. Спасибо, Капитан. > Так где гугл-ФС, а?  http://en.wikipedia.org/wiki/Google_File_System Для тyпых там написано: Unlike most other file systems, GFS is not implemented in the kernel of an operating system, but is instead provided as a userspace library. В каком месте некие кастомные юзермодовые компоненты - часть линуха вообще? Это некий гугловый самопис, не имеющий непосредственного отношения к Linux. > Вангую, что и всего остального вы не скоро дождетесь =) Попробуйте git log | grep "@google.com" на гите линевого ядра - вот тогда и узнаете кто и что дождется :). Я насчитал over 9000 и даже over 16 000 совпадений...
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	144. "Критическая уязвимость в Glibc, которая может привести к уда..."	–3 +/–
	Сообщение от Аннаним on 31-Янв-15, 01:29
	> время и проявив компетенцию (тогда я так и быть покажу, ибо Ух ты, помнить тот случай с опененком и отмазками Тео оказывается верх компетенции?! Не делайте мне смешно =) > Ох, камон, продолжайте в том же духе - минимум компетенции, максимум ЧСВ. Отличная аргуметнация! Продолжайте в том же духе! > А для тугих - прямым текстом: DRM+KMS - мощный бэкэнд. От иксов > оно не зависит, Для танкистов -- причем тут бэкэнд? Взялись пилить xorg, но толком не допилили -- но зато есть другой, мощный бэкэнд, да! А xspy как работал, так и работает. Оно ведь нинужна фиксить!! > xorg я не понимаю. Для лично меня xorg наименее интересная часть > всего этого процесса. Мултисешн, запуск окошек под разными юзверями и т.д.  без костылей -- вам не нужно. Окай. > И замечательно. Получился нормальный мощный и современный бэкэнд для графики к которому т.е недопиленный хорг -- замечательно o_O > И это правильно. Если кто не понял - линуксоиды собрали себе годный > графический бэкэнд, Угу, угу. Годный по принципу " и так же работает". > Раз > вам ничего улучшать не надо - ну вот и пользуйтесь иксами > и драйверами десятилетней давности! ВЫ -- это кто o_O? Причем тут улучшения и десятилетняя давность? Или -- кто о чем, а вшивий о бане? Т.е xorg позорно слили, но теперь это вроде и не слив, а улучшения и вообще -- все остальные вообще ничего не хотели делать!!! >. А вы там рассказывайте про то как вам 3D не > надо, если хотите... Пруфцы будут? Или опять "я вкурил^W прочел между строк!!!" > Я не знаю про кого это. Кто сделал миллиарды на GPL и > ничего не отдал? Покажите этих позорников. всякие роутеры и другие железки, не? > Главное - результат. И если он таков что о вас вытирают ноги, > вы таки коврики для ног. Тогда вам на винфак -- или вы всерьез считаете 1% на десктопе отличным результатом? Хотя да, с такими недоделанными иксами какой уж десктоп. > Большинству людей в здравом уме не хочется проверять какого мнения на этот Причем здесь люди в здравом уме? Тут будет важнее мнение грамотных юристов. > сильно непонятливый - порой таки получает по сусалам в судах. Автор > бизибокса подтвердит ;). Ога, ну совсем никакой разницы -- вообще не отдавать код и отдавать его немного "нетрадиционным" способом. Еще раз -- "machine readable". >> т.е код обязаны предоставить только тем, кому продают или отдают бинарники. > Спасибо, Капитан. Пожалуйста. Т.е вы всерьез думаете, что это защитит ЖПЛный код от проприерастов? Подумайте еще немного, потратив свое время и проявив компетенцию -- намекну: можно составить договор насчет дальнейшего использования сырцов  =). > Для тyпых там написано: > Unlike most other file systems, GFS is not implemented in the kernel > of an operating system, but is instead provided as a userspace > library. Для тупых поясню -- гугл вообще не обязан предоставить сырцы. Т.е зарабатывать мильярды и не отдавать фанатам ничего взамен =)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	150. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 01-Фев-15, 10:00
	> Ух ты, помнить тот случай с опененком и отмазками Тео оказывается верх > компетенции?! Не делайте мне смешно =) В данном случае, компетенция - это разбираться в том что вы копипи3дите, хотя-бы в объеме при котором вы потом не залетите (по линии GPL, и вообще). А втyпую скопировать из пингвина сотни кода не глядя - это сильно, чуваки! > Отличная аргуметнация! Продолжайте в том же духе! А мне то что? Я не копирую у других сотни кода не глядя, поэтому и в суд меня не поволокут. А вот некоторым урок с AT&T видимо был не в прок. > Для танкистов -- причем тут бэкэнд? При том что главным было это. А то что в xorg драйвера стали "ответкой" для этого интерфейса - ну, логично. Оно для этого и делалось, чтобы более высокоуровневый юзермод этим потом пользовался. > Взялись пилить xorg, но толком не допилили -- но зато есть другой, > мощный бэкэнд, да! А xspy как работал, так и работает. Оно ведь нинужна фиксить!! Если честно - мне вообще пофиг на xorg и что с ним случится. Со своей стороны я бы предпочел чтобы xorg стал deprecated в пользу чего-то более соответствующего современным реалиям. К чему все и идет (вяленд, мир). Чинить там по крупному что-то - это из разряда "выкрасить и выбросить". > Мултисешн, запуск окошек под разными юзверями и т.д.  без костылей -- вам не нужно. Окай. Насколько я понимаю, у пингвинов есть планы делать все это совершенно иначе. Но да, лично мне это не особо нужно. То что нужно лично мне (e.g. запуск числокрушилок юзающих GPU под другим юзерем) уже давно сделали в лучшем виде. Только там иксы вообще не при делах. А так - иксы настолько сложные и там столько грабель что я не думаю что можно сделать сколь-нибудь безопасную мультиюзерность в одном процессе. Там рутовые права то у процесса отобрать пытаются черти-сколько и для этого надо немало костылей. > т.е недопиленный хорг -- замечательно o_O ИМХО он просто должен умереть. > Угу, угу. Годный по принципу " и так же работает". Годный - потому что соответствует фактическим реалиям в устройстве железяк, особенно после реализации render nodes и расщепления "видеокарт" на "контроллеры дисплея" и "числокрушилки". И способный обслужить пожелания юзерей. Будь то ускоренный вывод hi-res видео, OpenGL во все поля, вычисления на GPU и прочая. >> и драйверами десятилетней давности! > ВЫ -- это кто o_O? Причем тут улучшения и десятилетняя давность? Вы - это тех кого то что было устраивало и кто считал что ничего менять не надо. Ну вот и пользуйтесь старыми драйверами. А то что разработчики дров дружно выбрали новые интерфейсы, лучше соответствующие современным реалиям и упрощающие их жизню - так это их право. > Т.е xorg позорно слили, На мое мнение - он свое много лет назад отлетал, совершенно не соответствуя современным реалиям в плане устройства железа и того как люди графикой по факту пользуются. Вся новейшая история xorg - это попытки его прокостылить для того чтобы хоть немного соответствовал фактическим реалиям. Судя по всему это понимают все причастные и как я понимаю - очень хотят выпихнуть этот код в deprecated. Куда и дорога, имхо. > вообще -- все остальные вообще ничего не хотели делать!!! Всех остальных "все устраивало", невзирая на позорное состояние графической подсистемы. >>. А вы там рассказывайте про то как вам 3D не надо, если хотите... > Пруфцы будут? Или опять "я вкурил^W прочел между строк!!!" Пруфцы на что? То что AMD решили для новых GPU на основе GCN вообще не будут делать "обычное" 2D ускорение, решив вместо этого оформить все это как частный случай 3D, путем использования Glamor? Ну вон в фридесктопной вике например для GCNов честно написано NA для EXA, на форониксе это в свое время обсуждалось 2-3 года назад, etc. Там же можно найти аргументы разработчиков почему они сделали именно так. Или вам какой-то другой пруф чего-то еще надо было? > всякие роутеры и другие железки, не? Там, конечно, не идеально. Но! Многие производители SoC и Wi-Fi в последнее время как-то так осознали, что их подходы в пингвине совсем не велкам и в долговременном плане ни к чему хорошему не ведут. И построились под нормальные методики разаботки линуха. Как минимум Атерос/Квалкомм, Броадком и (недавно) Марвелл сделали выводы и ... теперь пишут свои драйвера прямо под майнлайн линуха. Да и SoC в майнлайне неплохо поддерживаться стали. А еще допинали squashfs, допилили под себя u-boot (он тоже GPL, если что). Вообще, лень и экономия победили. И раз уж всяко выкладывать GPL tarball - ну и бутлоадер тогда нехай GPLный будет, там фич дофига. Поэтому куча железяк ушли на GPLный бутлоадер. А потому что умеет кучу всего и легко изогнуть под свои нужды. Так что сказать что никто ничего с этого не получил - криво. Таки получили. А лично мне так еще и просто приятно получить буклетик с распечатанной GPL в комплекте с новым роутером, попутно рассказывающий где взять сорц. И это уже давно перестало быть чем-то диковинным :-). > Тогда вам на винфак -- У меня винды нет, ну и фачиться с ней я не могу по этой причине :). > или вы всерьез считаете 1% на десктопе отличным результатом? Я считаю что мир не кончается на одних только десктопах. И да, я считаю что приведение графики в чувство - одно из актуальных направлений деятельности в лине. Чтобы не ограничиваться парой процентов и на десктопе в том числе. А то не комильфо когда всякие гуглы, которым надо нормальные UI/UX - колхозят всякие местечковые surface flinger'ы, популярно показав иксам что они думают про столь жуткий крап. > Хотя да, с такими недоделанными иксами какой уж десктоп. Да вы не сцыте, пофиксят. Правда, фикс имхо будет подразумевать еще и отправку иксов на свалку истории. И я думаю на этом пути я еще услышу ваше кипешевание :). > Причем здесь люди в здравом уме? Тут будет важнее мнение грамотных юристов. При том что мало кто в здравом уме хочет лишний раз пинаться в суде да еще в достаточно невкусном контексте подмачивающем репутацию компании. > Еще раз -- "machine readable". Ну вот если я не могу прочесть код на ваших материалах, он для меня не есть machine readable и я не буду считать условия лицензии выполнеными. Что чревато вызовом в суд по довольно невкусному топику. Нет, бывают конторы которые максимально усложняют процесс, по типу микротиков. Но у них и репутация за это портится соответствующе. Ну и свои подходы развивают только они. Чем это заканчивается - думаю понятно :). > Пожалуйста. Т.е вы всерьез думаете, что это защитит ЖПЛный код от проприерастов? Т.е. я всерьез вижу что GPLный код нынче выкладывает толпа контор. От особо паскудных на 100% защититься конечно сложно, но у большинства контор вообще нет самоцели давиться жабой за каждый байт. Достаточно сделать это неудобным и чреватым - и они этого делать не будут. А в целом GPL в результате создает намного более комфортный климат во всей своей экосистеме. Не вижу ничего хорошего в взаимодействии с жлобьем и кидалами. > можно составить договор насчет дальнейшего использования сырцов  =). Нельзя. GPL запрещает добавляь дополнительные ограничения. Это если к вопросу о компетенции. Все чего так можно получить - нарваться на termination лицензии у того кто это требование навесил. Ну и тогда он по законам о авторских правах вообще пират, который сорец упер не имея на этого прав, поскольку лицензия от его же действий и накрылась медным тазом, в момент когда такой договор был составлен. Ну а что надо делать с нарушителями копирайта - Фемиде уже показали копирасы :-). Нормальные юристы в отличие от форумных аналитиков типа вас лицензии все-таки читают и поэтому в курсе всего этого. Вот и не хотят пинаться в суде лишний раз с результатом который совсем не факт что в их пользу будет (попасть в случае проигрыша в мясорубку законов о авторских правах - удовольствия довольно мало). > Для тупых поясню -- гугл вообще не обязан предоставить сырцы. Весьма зависит от. Если распостраняют бинари - то обязаны. Ну как с андроидом 3.0, где зажали все, кроме как раз ядер, патамучта гладиолус^W GPL :). А какие они там самописные либы на своих серверах используют - вот натурально, их собственное дело.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	149. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
	Сообщение от Яблоковод on 01-Фев-15, 06:24
	Ты читать умеешь? http://www.webcitation.org/6187NYSIz MacOS X сертифицирована как UNIX'3
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	129. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от anonymice on 29-Янв-15, 13:18
	> А так то спецам по безопасности из фрибзды сервера сломал троянец помнится Не у спецов, а у разработчика, не безопасности/базы с ведром (т.е собственно самой бзди), а портов , не сломал сервак бзди, а "всего лишь" спер ссх-ключ -- а так да, все верно.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	84. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 14:56
	> Это Вы про BSD Unix? >> безопасные Нет, это точно не про BSD. Во фре, например, буквально вчера прикрыли фееричный локальный рут (CVE-2014-8612).
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	85. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от iZEN (ok) on 28-Янв-15, 15:20
	Конкретнее: http://svnweb.freebsd.org/base?view=revision&sortby=date&rev...
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	44. "Критическая уязвимость в Glibc, которая может привести к уда..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 07:23
	Когда открывают уязвимости, которым не подвержены старые версии, вы почему-то тут не кукарекаете.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	66. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 11:32
	Если подвержены только новые версии, то а) уязвимость существовала недолго (шанс, что о ней знали и успешно эксплуатировали минимален) б) она уже закрыта т к мы вообще о ней услышали в новостях.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

19. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
Сообщение от Аноним (??) on 27-Янв-15, 22:50
ASLR, PIE, NX - костыли. Их внедрение - глупость. Хороший спец их обходит на раз. ASLR for Windows вообще черт знает что! Явно маркетологи трудились...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 00:08
	> ASLR, PIE, NX - костыли. Их внедрение - глупость. Хороший спец их > обходит на раз. ASLR for Windows вообще черт знает что! Явно > маркетологи трудились... Замки и двери - глупость. Хороший специалист справляется даже с хорошим замком и крепкой дерью.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	26. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 00:24
	Врядли ASLR, NX, PIE можно сравнивать с основным замком и тем более дверями. Под дверями понимаю сам код и от его качества зависит - откроют дверь или нет. ASLR, NX, PIE - затрудняет, но нисколько не препятствует процессу. Защита от "дурака".
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	28. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 00:50
	Ну так замки и двери тоже "защита от дypaка". Рота автоматчиков охраняет объект намного эффективнее.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	29. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 01:11
	Это так. Если у вас что-то есть и это кому то известно и очень нужно - ограбят. А вот рота автоматчиков будет куда более сдерживающим фактором. Суть в соотношении прилагаемых усилий с конечным результатом. Так же вытекает следующий фактор - защита информации от третьих лиц. Потому "умолчали" об этом баге, но кто то все-таки страдает недержанием и слил ее, подставив при этом много народа. Изоляция и разграничение прав доступа - хорошее, рабочее решение. Любая защита разбиваеться об единственный факт: предупреждён — значит, вооружён.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	47. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 07:45
	> Потому "умолчали" об этом баге, но кто то все-таки страдает недержанием > и слил ее, подставив при этом много народа. Если народ считает себя святее апстрима - ну наверное они должны свою крутизну делом доказывать, патча баги не хуже оного. А если с этим вышли обсиратушки - так может стоило взять у апстрима более свежую версию, раз сами патчить не умеют?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	51. "Критическая уязвимость в Glibc, которая может привести к уда..."	–4 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 08:59
	Предполагаю, что проблема а широте охвата уязвимости. Уязвимость с 2000 года! Как много машин по прежнему функционируют на устаревшем оборудовании? Огромный парк машин! Я бы отнес подобную информацию к разряду очень опасной. Ее разглашение несет больше вреда чем пользы. Но нашелся же "герой"! И благодаря ему количество ботнетов резко возрастет.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	57. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 10:43
	> Ее разглашение несет больше вреда чем пользы. Наоборот, разглашение при наличии патча НЕОБХОДИМО иначе куча хомячков сидящих на Ынтерпрайз дистрах останутся под строгим наблюдением АНБ и прочих. > Но нашелся же "герой"! И благодаря ему количество ботнетов резко возрастет. НЕОБХОДИМО обновится! Так и те кто внёс уязвимость ею перестанут пользоватся и кто только узнал не воспользуются.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	114. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:13
	> дистрах останутся под строгим наблюдением АНБ и прочих. Для начала какое-нибудь кардерье скупит на черном рынке дырку и ненавязчиво соберет все кредитки хомячков в пределах планеты Земля. А потом еще перепродадут хомячков, которые не только ценный мех но и ценный бандвиз и вычислительный ресурс всяким ддосерам и спамерам. Если дырка есть - о ней рано или поздно узнают. И буде лучше если юзеры и майнтайнеры будут не самыми последними кто узнал о дыре.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	91. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Michael Shigorin (ok) on 28-Янв-15, 16:59
	> Но нашелся же "герой"! И шо теперь, замочите эту француженку?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	98. "Критическая уязвимость в Glibc, которая может привести к уда..."	–3 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 18:59
	Жаль что подобные действия нельзя квалифицировать как халатность. Так же в свое время поступил и Google с Microsoft. Подлость. А страдают, как известно, остальные.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	100. "Критическая уязвимость в Glibc, которая может привести к уда..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 20:48
	Пользователи Microsoft должны страдать. Что они выбрали - на то и имеют право.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	102. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 21:29
	Кто то выбирает Linux, а кто то Windows. Нельзя однозначно сказать, что Linux - хорошо, а Windows - однозначно плохо. У каждой свой кусок пирога. Своя ниша. Что до Google и слива дыр. Должна же существовать хоть какая то этика!
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	113. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:09
	> же существовать хоть какая то этика! Действительно. За год вполне можно либу обновить. А если кто полез патчить круче апстрима и облажался - окей, халатность граничащая с преступной. Или вот микрософт. Ну вот только не надо врать что 3 месяца для конторы с такими ресурсами - недостаточно. Ну ладно б там ныл какой-нибудь единичный разработчики. Но тут не пройдет. Это халатная работа, спустя рукава. Должна же быть минимальная этика и культура патчинга дыр вместо махрового пофигизма?!
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	121. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
	Сообщение от Гость (??) on 29-Янв-15, 10:25
	Ты бы про этику ещё местным детям рассказал.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	109. "Критическая уязвимость в Glibc, которая может привести к уда..."	+2 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 08:59
	> много машин по прежнему функционируют на устаревшем оборудовании? Древность оборудования мало мешает обновлению этой либы самой по себе. Ну разве что какой-то лошпед купил огороженное (полу)проприетарное барахло и должен за это пострадать, как полагается по законам жанра. > Огромный парк машин! Проблемы негров шерифа не волнуют. За столько времени наверное можно уже было и заапдейтиться. > Я бы отнес подобную информацию к разряду очень опасной. Ее разглашение > несет больше вреда чем пользы. Но нашелся же "герой"! И благодаря > ему количество ботнетов резко возрастет. Булшит. Если дыра есть, на черном рынке сплойты летать будут так и сяк. А тут глядишь обладатели антиков начнут шевелиться на предмет патчинга.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	27. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 00:32
	Мои слова - личное мнение. Можно сказать - догадка. Не являюсь экспертом в области безопасности или программистом. Не стоит принимать их за истину.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	60. "Критическая уязвимость в Glibc, которая может привести к уда..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 11:10
	> ASLR, PIE, NX - костыли. Их внедрение - глупость. Хороший спец их > обходит на раз. ASLR for Windows вообще черт знает что! Явно > маркетологи трудились... Ты абсолютно ничего не понимаешь в этих технологиях! По поводу NX: Основное правило безопасности любой ОС гласит: 1. Всё что исполняется на процессоре не должно изменятся, а всё что изменяется не должно исполнятся! Ввиду наличия NX инструкции в процессорах alpha, avr32, ia64, parisc, sparc, sparc64, x86_64, x86 есть возможность постранично выделять пямять процессором и устаналивать необходимые разрешения БЕЗ УТРАТЫ ПРОИЗВОДИТЕЛЬНОСТИ! По поводу ASLR (Address Space Layout Randomization), PIE (Позиционно независимые исполняемые файлы, динамично связные): Это относится как к ядру ОС так и пользовательским прогаммам. Многие техники взлома основаны на знании определённого адреса в атакуемой программе. Использование ASLR и PIE добавляет рандомизацию в определённые части программы и таким образом, в большинстве случаев, атакующему приходится их угадывать! Если не угадал то с помощью grsecurity или openwall против него предпримутся ответные действия.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	88. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от anonymuse on 28-Янв-15, 16:53
	> 1. Всё что исполняется на процессоре не должно изменятся, а всё что изменяется не должно исполнятся! > Использование ASLR и PIE добавляет рандомизацию в определённые части Для пых-пых скриптов не работает? Не работает! Есть легаси-софт, который не может в ASLR/NX? Есть конечно! Значит -- все это фигня и ненужна!!
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	92. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 17:25
	> Для пых-пых скриптов не работает? Не работает! А твой пых-пых такой кому нужен? > Есть легаси-софт, который не может в ASLR/NX? Есть конечно! Есть разрабы которые упорто выделяют память RWX и не хотят писать правильные проги: выделяющие память только R-X или RW- > Значит -- все это фигня и ненужна!! Не нужны криворукие програмисты!!!
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	93. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 17:36
	> Есть легаси-софт, который не может в ASLR Этот вопрос тоже решается сменой програмистов, на тех которые умеют писать позиционно независимый код! В прочем всё не так печально. Почти все обычно используемые проги, сервера и десктопа нормально работают и с NX и с ASLR. Замеченные исключения это начальные версии кодеков использующие see инструкции и тому подобное... Потом с програмистами разговаривают и они преимущественно фиксят. Исключением есть Ынтерпрайз софт, без доступа к исходникам, и програмистами которым "за это не платят".
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	96. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от anonymuse on 28-Янв-15, 18:21
	> В прочем всё не так печально. Почти все обычно используемые проги, сервера > и десктопа нормально работают и с NX и с ASLR. Дело в том, что достаточно одной такой либы-костыля в вирт.-аддр. пространстве процесса ;). Хотя самый прикол был пару лет назад, когда вышла очередная заметка о том, что принудительно-загружаемые либы всяких (довльно известных) анти-вирей и "огнестен" в окнах все еще "не умеют" в аслр/nx и, соответственно сводят на нет все преимущества этих технологий.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	112. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:07
	> том, что принудительно-загружаемые либы всяких (довльно известных) анти-вирей и > "огнестен" в окнах все еще "не умеют" в аслр/nx и, соответственно сводят > на нет все преимущества этих технологий. Насколько я понимаю, все либы билдуются как position-independent, просто потому что нет никаких гарантий что дефолтные адреса под которые сбилдован файл вообще будут свободны на момент загрузки либы. Как либа может мешать ALSR в свете этого факта?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	131. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 16:07
	> все либы билдуются как position-independent У меня да, ибо я их собрал с gcc pie: $ file /lib/libc-2.19.so /lib/libc-2.19.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped $ scanelf /lib/libc-2.19.so TYPE   FILE ET_DYN /lib/libc-2.19.so Видишь "dynamically linked (uses shared libs)" и "ET_DYN" признак позиционно независимых бинарей. А у тебя в дистре статически собраны...
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	133. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 16:43
	Чтобы поддерживать ALSR они должны специально собиратся -fPIC или -fPIE и линковатся -pie: http://d-sbd.alioth.debian.org/www/?page=pax_pie https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Positi... Кроме того надо PAX ядро которое собственно и осуществит рандомизацию. А ещё надо систему которая отреагирует както на "крах вызваный эксплоитом" grsecurity или openwall. И в скольких дистрах это всё уже реализовано?
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	137. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 18:41
	> Чтобы поддерживать ALSR они должны специально собиратся -fPIC или -fPIE и линковатся -pie: Так динамическую либу проблематично собрать НЕ как позиционно независимый код. Потому что когда загружается программа - совсем не факт что дефолтные адреса на которые образ либы изначально собран вообще будут свободными. Поэтому IIRC все динамические либы подразумевают что их можно перемещать в другие адреса. > Кроме того надо PAX ядро которое собственно и осуществит рандомизацию. ALSR уже довольно много где реализован. > И в скольких дистрах это всё уже реализовано? ALSR и NX - довольно много где. И прочие fortify source'ы, relro/bind now и что там еще. Даже у слоупочных дебианщиков ну и убунтуев - скрипт hardening-check сто лет как есть. И не для красоты, заметим.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	147. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 31-Янв-15, 10:26
	> Даже у слоупочных дебианщиков ну и убунтуев - скрипт hardening-check сто лет как есть. И не для красоты, заметим. Дебианщики и paxtest написали... Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой и дебом эти проекты очень мало пересекаются.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	151. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 01-Фев-15, 10:16
	> Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой > и дебом эти проекты очень мало пересекаются. Кроме одной "мелочи" - все сетевые сервисы как-то так собираются нынче с наработками debian hardening'а.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	153. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 09:49
	>> Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой >> и дебом эти проекты очень мало пересекаются. > Кроме одной "мелочи" - все сетевые сервисы как-то так собираются нынче с > наработками debian hardening'а. Это они на будущие, без PAX ядра смысла в pie нет. Мне кажется что в данном случае должен бы защитить -fstack-protector и -fstack-protector-all оно же оносится к переполнению кучи? Жаль протестить не могу у меня давно 2.19 Вот интересный проект http://levee.epfl.ch/ способный устранить данный клас уязвимостей. Или не писать больше на C/C++...
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	139. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аннаним on 29-Янв-15, 21:42
	> Насколько я понимаю, все либы билдуются как position-independent, просто потому что нет > никаких гарантий что дефолтные адреса под которые сбилдован файл вообще будут > свободны на момент загрузки либы. Как либа может мешать ALSR в > свете этого факта? Ну как, как - легаси, вестимо ;) Насколько я помню, нужен флэг "поддержки" аслр -- иначе по дефольту либа будет грузится в указанный ImgageBase (легаси). А так как либы грузятся достаточно рано (при старте процесса и ДО отработки ImportAddressTable - на этот момент загруженны (вплоть до семерочки было так, восьмерочку не тыкал) по дефолту ntdll и kernel32.dll, может еще 1-2 либы), т.е считай, что адрес этой либы не меняется.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	140. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аннаним on 29-Янв-15, 21:44
	> А так как либы грузятся достаточно рано имелись в виду либы антивирей и огнестен.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	143. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 30-Янв-15, 22:46
	> будет грузится в указанный ImgageBase (легаси). Для начала - либа никогда не может надеяться на то что ее в Base вгрузят. Потому что никто не гарантирует что layout адресного пространства процесса на момент вгрузки либы будет содержать эти адреса свободными. Поэтому насколько я помнб, все либы собираются как position-independent. Чтобы при такой ситуации иметь возможность перенести либу в другие адреса. По поводу чего вопрос сводится в основном к желанию loader'а либы сделать рандомизацию, как я понимаю. > А так как либы грузятся достаточно рано (при старте процесса и ДО отработки > ImportAddressTable - На минутку, либы можно еще и явно вгружать и импортировать из них функции. > на этот момент загруженны (вплоть до семерочки было так, восьмерочку не тыкал) > по дефолту ntdll и kernel32.dll, может еще 1-2 либы), т.е считай, > что адрес этой либы не меняется. Нет, ну я понимаю что микрософт может лохануться даже в этом. Но не все же такие упыри. А так, ну вот например: libc-2.19.so: Position Independent Executable: yes
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	145. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аннаним on 31-Янв-15, 03:37
	>> будет грузится в указанный ImgageBase (легаси). > Для начала - либа никогда не может надеяться на то что ее > в Base вгрузят. Потому что никто не гарантирует что layout адресного Я в общем-то не спорю (хотя видел либы с выпилинными реалоками - т.е какие то спецы игрались с флэгами компилятора или, возможно, это была либа, обработанная "противо-крякерской-защитой") Т.е да: > вопрос сводится в основном к желанию loader'а либы сделать рандомизацию -- > Поэтому насколько я помнб, все либы собираются как position-independent. Чтобы при > такой ситуации иметь возможность перенести либу в другие адреса. Не только либы -- борлэнд-компиляторы (делфи 5 и 7, Си++ точно не помню) одно время даже екзешники такие выдавали - т.е с нужными реалокми. > На минутку, либы можно еще и явно вгружать и импортировать из них > функции. Да, можно -- но для "суперсекурных" дополнений антивирей желательно загрузить либу как можно раньше, что бы значит контроль был и все такое (я честно не понял, зачем нужно грузить либу, если все равно добавляются хуки в ядро) Там довольно много штатных средств -- тот же comodo грузил свою дллку через AppInit http://support.microsoft.com/KB/197571 > The AppInit DLLs are loaded by using the LoadLibrary() > function during the DLL_PROCESS_ATTACH process of User32.dll. Ну или SetWindowsHookEx. > Нет, ну я понимаю что микрософт может лохануться даже в этом. Но > не все же такие упыри. Вот как раз МС не лоханулись -- у них даже утилита есть, которой можно менять опции  -- т.е "forcing aslr" и все в таком духе. А вот "хай-секюрити-софт" -- как раз наоборот :) http://www.slideshare.net/JoxeanKoret/breaking-av-software-3... (ну или https://www.google.de/search?q=breaking+av+software+pdf ) см. 34 >Some libraries of the core of some AV engines >are not ASLR enabled.Even in “major” AV engines... > >...there are non ASLR enabled modules. > >...there are RWX pages at fixed addresses. >...they disable DEP. 38 (Panda) >Some libraries of the core of some AV engines >are not ASLR enabled.Even in “major” AV engines... > >...there are non ASLR enabled modules. > >...there are RWX pages at fixed addresses. > >...they disable DEP. 48 >And, also, one can write an exploit targeting >Panda Global Protection users for any program. >Why? Because the product injects 3 libraries >without ASLR enabled in all processes. Yes. 54 >Most libraries and binaries in Forticlient doesn't >have ASLR enabled. 56 (Каспер) >Libraries avzkrnl.dll and module vlns.kdl, a >vulnerability scanner (LOL), are not ASLR >enabled. >One can write a reliable exploit for Kaspersky >AV without any real effort. 60(BKAV) >They don't have ASLR enabled for their services... Там кстати и насчет сабжа есть: https://bugzilla.clamav.net/show_bug.cgi?id=10650 Хотя в целом сабж очень таки не плох ;) >[оверквотинг удален] > >Ran for about 2 weeks. > >Only 1 DOS (found manually) >1 infinite loop with a >malformed PE. >Asked to remain silent until >a public patch is published. > >Honestly, I was very  surprised.
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	146. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аннаним on 31-Янв-15, 04:05
	> Там кстати и насчет сабжа есть: Тьфу, "сабж" -- это в соседний тред (clamav)
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	152. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 01-Фев-15, 11:07
	> Я в общем-то не спорю (хотя видел либы с выпилинными реалоками - Если утонченно извращаться - возможны фокусы поинтереснее. Вон например сабжевую либу можно запустить как исполняемый файл. Либа расскажет что это такое, какой версии, etc. Т.е. оно одновременно и либа и executable. Требует немного утонченного шаманства на уровне линкера (но чем-то таким настоящие системщики и отличаются от сброда). Релокейшны из либы выпилить технически, конечно, можно. Но это чревато тем что при попытке вгрузки либы лыжи встанут на асфальт и либу вообще не удастся вгрузить. Если адреса заняты а релокаций нет - что остается? Правильно: срубить загрузку либы с ошибкой. А так - у винды в работе с либами вообще есть несколько веселых заскоков, живущих с незапамятных времен. Путем некоторых относительно честных манипуляций (только системные вызовы, никаких руткитов и суперпривилегий) можно слепить например стелс-процесс который напрочь не видно в манагерах задач, но который выполняется. > была либа, обработанная "противо-крякерской-защитой") Всякие пакеры и протекторы делают загрузку кода в память сами, перехватывая инициативу на себя. Что они при этом и как делают с кодом - это очень отдельный вопрос. Могут делать что угодно. В том числе - взять релокации где-то сбоку, в кастомном формате и самолично их обсчитать, например. Если не лениво кодить свой сильно кастомный лоадер и обработку кода - это все возможно. При этом "нет релокаций" лишь с точки зрения того кто ожидал их в дефолтном месте найти, а на самом деле есть, но где их брать и как применять - пакер/протектор сам разбирается. > Т.е да: >> вопрос сводится в основном к желанию loader'а либы сделать рандомизацию Именно. И если микрософтушка это не сделал - это к ним вопросы, имхо. > помню) одно время даже екзешники такие выдавали - т.е с нужными реалокми. Да вроде почти все компилеры по дефолту выдают исполняемые файлы с релокейшнами. В случае EXE их можно срезать. Тогда исполняемый файл разумеется будет по фиксированным адресам. > Да, можно -- но для "суперсекурных" дополнений антивирей желательно загрузить > либу как можно раньше, что бы значит контроль был и все такое Для этого есть всякие указания лоадеру ОС сделать прелоад либы. В *никс-образных через переменную окружения LD_PRELOAD, в винде - через какое-то тошнилово с реестром. > (я честно не понял, зачем нужно грузить либу, если все равно добавляются > хуки в ядро) Фиг знает. Может чтобы сложнее было синхронно и незаметно везде вынести антивиря отовсюду, до того как он заметит что что-то идет не так? > Ну или SetWindowsHookEx. Ну это все круто, но меня анатомия виндов нынче не очень интересует. > которой можно менять опции  -- т.е "forcing aslr" и все > в таком духе. А вот "хай-секюрити-софт" -- как раз наоборот :) Насколько я помню - форсирование ALSR везде может привести к тому что часть программ запускаться не будет (как раз поди те где какой-то умник релоки срезал). [заскипано] Как я уже сказал, интимные особенности виндов мне малоинтересны.
	Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

	97. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 28-Янв-15, 18:49
	Я разве спрашивал как оно работает? Более-менее понимаю суть работы данных механизмов. Bypassing PaX ASLR protection.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	108. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 08:58
	> Bypassing PaX ASLR protection. PaX и ASLR очень мощные и нужные средства защиты. Они защищают в большинстве случаев и по этому должны использоватся. Но также надо понимать что большинство это НЕ ВСЕ.... Да, с либой печально вышло, на glibc жалобы были давно и разного плана есть альтернативы: http://www.musl-libc.org/ Вот пример мини дистрибутива реализующий всё выше сказаное: http://alpinelinux.org/about/
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	124. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 11:22
	> Да, с либой печально вышло, на glibc жалобы были давно и разного > плана есть альтернативы: http://www.musl-libc.org/ Замена, блин. Так то uclibc сто лет есть. В мелочевке всякой используется. Но он не стопроцентная замена. Как и этот урезок.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

43. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
Сообщение от suberjin on 28-Янв-15, 06:59
уже вышло для Centos. http://lists.centos.org/pipermail/centos-announce/2015-Janua...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

49. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
Сообщение от Аноним (??) on 28-Янв-15, 07:56
> Атака затруднена в серверных программах, которые используют в gethostbyname() для обратной проверки данных DNS, а также в привилегированных suid-утилитах, в которых вызов getaddrinfo() применяется только при сбое выполнения inet_aton(). Переведите, пожалуйста.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
Сообщение от Xaionaro (ok) on 28-Янв-15, 08:02
Отголоски дырявых последних двух лет (2013-2014) дают о себе знать даже сейчас.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	56. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от pkdr (ok) on 28-Янв-15, 10:35
	Ага, особенно эта уязвимость с 2000 года.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	105. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Xaionaro (ok) on 29-Янв-15, 08:09
	> Ага, особенно эта уязвимость с 2000 года. >> При этом проблема была устранена в мае 2013 года [...]
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	116. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:44
	И? Ты поехавший, ты в курсе?
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

78. "Критическая уязвимость в Glibc, которая может привести к уда..."	–2 +/–
Сообщение от PnDx (ok) on 28-Янв-15, 13:33
Что-то мне подсказывает, что это касается ~100% эмбедовки. /дальше следуют ~100кБ ненормативной лексики/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	83. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от EHLO on 28-Янв-15, 14:54
	> Что-то мне подсказывает, что это касается ~100% эмбедовки. /дальше следуют ~100кБ ненормативной > лексики/ Там обычно другой libc.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	89. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от playnet (ok) on 28-Янв-15, 16:53
	uclibc
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	111. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:04
	> uclibc А кроме всего прочего удакам выпускающим прошивки пора выбросить свой окаменелый инструментарий на помойку. А то до сих пор находятся упыри которые какое-нибудь ядро 2.6.32 отгрузить ухитряются, собраное gcc 4.3 и весь остальной софт - из той же эпохи мезозоя. Але, производители! Хватит пополнять ботнеты своим замшелым крапом.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	126. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Владимир (??) on 29-Янв-15, 11:36
	Да вы еще оптимист с 4.3. Под контроллеры MOXA  сейчас ничем новее 3.4 не соберешь (и то gcc надо ручками собирать). А так они до сих пор тулчейн 2.95 предлагают с древним uclibc.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	128. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 12:22
	> Да вы еще оптимист с 4.3. Нечто такое было в прошивке какой-то китайчины. Видимо из вендырского sdk. > Под контроллеры MOXA  сейчас ничем > новее 3.4 не соберешь (и то gcc надо ручками собирать). А > так они до сих пор тулчейн 2.95 предлагают с древним uclibc. Зато в следуюший раз у покупателей есть резон требовать более нормальную поддержку и иметь дело с теми кто ее обеспечивает.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	110. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 09:02
	> Что-то мне подсказывает, что это касается ~100% эмбедовки. Во первых, в эмбедовке glibc используют редко. Во вторых, если кто считает что он особо привилегированный и его обновления не касаются - ну пусть и получает тогда участие в ботнете.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

86. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
Сообщение от MPEG LA (ok) on 28-Янв-15, 15:46
интересно, маршрутизаторы часто пользуют glibc?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	94. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-15, 17:38
	Слава Ктулху - нет.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	130. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
	Сообщение от Аноним (??) on 29-Янв-15, 13:26
	Ну вообще-то, не факт, что в uClibc нет уязвимостей ещё не обнаруженных.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

99. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
Сообщение от Аноним (??) on 28-Янв-15, 19:45
Для debian squeeze интересно когда выпустят.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	106. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 08:45
	> Для debian squeeze интересно когда выпустят. Весной
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	107. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Аноним (??) on 29-Янв-15, 08:46
	>> Для debian squeeze интересно когда выпустят. > Весной Всмысле debian squeeze выпустят весной, а патч для для него не нужен, в нём уже новая glibc без уязвимости.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	118. "Критическая уязвимость в Glibc, которая может привести к уда..."	+/–
	Сообщение от Andrey Mitrofanov on 29-Янв-15, 09:54
	>>> Для debian squeeze интересно когда выпустят. >> Весной > Всмысле debian squeeze выпустят весной, а патч для для него не нужен, > в нём уже новая glibc без уязвимости. Милейший, Вы перепутали вот-вот,но ещё не выпущенный, jessie с oldstable-lts squeeze.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	117. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 29-Янв-15, 09:53
	> Для debian squeeze интересно когда выпустят. Для squeeze никогда, а для squeeze-lts: 1/ неофициальные пакеты https://lists.debian.org/debian-lts/2015/01/msg00037.html - позавчера 2/ официальные - да, https://lists.debian.org/debian-lts/2015/01/msg00043.html собираются
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	119. "Критическая уязвимость в Glibc, которая может привести к уда..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 29-Янв-15, 09:58
	> 2/ официальные - да, https://lists.debian.org/debian-lts/2015/01/msg00043.html собираются Поправочка: уже, https://lists.debian.org/debian-lts-announce/2015/01/msg0001...
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

141. "Критическая уязвимость в Glibc, которая может привести к уда..."	–1 +/–
Сообщение от anonchik on 30-Янв-15, 11:31
>Примечательно, что проблема присутствует в коде Glibc начиная с версии 2.2, выпущенной в ноябре 2000 года. что-то уровня многолетнего бага в WMF в винде
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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