В системной библиотеке 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
прелесть-то какая.и букавки интересные какие приведены, которые не смогли;( ASLR, PIE, NX
> прелесть-то какая.Прелестная, угу -- но в альте год как исправлено: http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm...
>> прелесть-то какая.
> Прелестная, угу -- но в альте год как исправлено: http://git.altlinux.org/gears/g/glibc.git?p=glibc.git;a=comm..."без указания на то, что исправленная ошибка имеет отношение к серьёзным проблемам с безопасностью", да?
+++Альт -- как Федора!
>>> прелесть-то какая.
>> Прелестная, угу -- но в альте год как исправлено:
> "без указания на то, что исправленная ошибка имеет отношение
> к серьёзным проблемам с безопасностью", да?Ровно потому, что на момент исправления это не было известно.
> +++Альт -- как Федора!
Не, в альте возможно скопировать (захардлинкать, если в терминах реализации) пакет из одного репозитория в другой при наличии необходимости (в данном случае ldv@ её озвучил как "испытываю непреодолимое желание обновить glibc", кажется) и прошедшей проверке на бинарную совместимость. В федоре, насколько понимаю, такие обновления в любом разе порождают новую сущность.
На самом деле раздули из мухи слона ("Опасность! Опасность! apache, nginx и все сервисы уязвимы!"). Если полностью прочесть оригинальный пост, то, очевидно, что это скорее exim опять "повезло". А вот Solar Designer респект за аудит исходного кода.
Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю>
> Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю>Эк ты glibc-то сурово. </и нет это функция _не экзима>
>> Малоиспользуемые и ненужные функции из популярной блоатвари оказались бекдорами. </дежавю></дежавю>
> Эк ты glibc-то сурово. </и нет это функция _не экзима>Правдоруб</khule>. Дали повод.
> прелесть-то какая.и букавки интересные какие приведены, которые не смогли;( ASLR, PIE, NXНедолго кисо злорадствовало :) http://www.opennet.me/opennews/art.shtml?num=41561
> Уязвимость не проявляется в дистрибутивах, построенных на основе свежих версий Glibc, например, в последних версиях Fedora и Ubuntu.Ох уж эти минное поля!
Совсем не то, что нормальные, стабильные, безопасные дистрибутивы.
Это Вы про BSD Unix?
Осталось только найти этот мифический BSD Unix. А что, хоть один BSD смог сертифицироваться как Unix? Или это "поди туда, не знаю куда, возьми то не знаю что"?А так то спецам по безопасности из фрибзды сервера сломал троянец помнится. А какой-нибудь опенок - как бункер на километровой глубине. Т.е. годится только для сильно некотрых целей.
> Осталось только найти этот мифический BSD Unix. А что, хоть один BSD
> смог сертифицироваться как Unix?МакОС кажется с 10-й версии 100% Unix Compatible. Ядро там вроде как BSD или почти BSD, как и некоторые остальные компоненты. Так что вопрос только в желании и наличии денег...
Ядро не BSD
> МакОС кажется с 10-й версии 100% Unix Compatible. Ядро там вроде как BSD или почти BSD, как и некоторые остальные компоненты. Так что вопрос только в желании и наличии денег...///---https://ru.wikipedia.org/wiki/OS_X
OS X значительно отличается от предыдущих, «классических» версий Mac OS. Основа системы — POSIX-совместимая операционная система Darwin, являющаяся свободным программным обеспечением. Её ядром является XNU, в котором используется микроядро Mach и стандартные сервисы BSD.
---///
> программным обеспечением. Её ядром является XNU, в котором используется микроядро Mach
> и стандартные сервисы BSD.В результате получился некий самопальный гибрид. Который как таковой и не микроядро и не бзда. А то что у бздюков кода надергали - так на это вы, подстилочки, и нужны.
Лолка. У мамы своей спроси, что такое подстилка.
> Лолка. У мамы своей спроси, что такое подстилка.Что такое? У проприерасовского холуя взыграла гордость и он решил доказать всему миру что он целый коврик, а не какая-то там подстилка?!
а у раба RMS - взыграла обида что кто-то более свободен чем он?
> а у раба RMS - взыграла обида что кто-то более свободен чем он?А ну бы его нафиг - свободу поработительствовать, западлостроительствовать и делать окружаюшим гадости.
> А то что у бздюков кода надергали -
> так на это вы, подстилочки, и нужны.А красно-шляпников уже что, победили? Больше не пытаются надуть сообщество напрямую?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, попутно удаляя комментарии из своего кода и уж конечно же запрещяет тупо распечатать исходники и высылать их по первому требованию почтой :)
Кстати, где собственно, улучшения ядра для линукс-серверов от гугла? А так же супербский-гугл-ФС, опять же, для линукс-серверов? Или гуглу можно ставить ДЖеПаЛ-Фанатов в любую позу -- ведь он такой сильный и нежный =)
> А красно-шляпников уже что, победили?Не знаю кого там кто победил, но GPLнутый код из линя бздельники уже накопипастили и при случае за это получат по щщам, вероятно.
> И с busybox-ами ну никогда никаких проблем не было, да
Чрезмерно наглых паразитов полезно иногда дустом посыпать. С точки зрения благополучия экосистемы в целом.
> индусов очень помогло сообществу!!
Ну вон подстилочки-освободители уж который год пыжатся "освободить". Но воз и ныне там - BSD-licensed альтернативы в глубокой зaднице и ими никто не пользуется даже несмотря на свободу жлобствовать. Да и бзды нынче применяет полтора недобитых проприераса, остальные дружно свинтили на пингвин. А просто потому что так возни меньше.
> запрещяет тупо распечатать исходники и высылать их по первому требованию почтой :)
Не уверен что это считается за исходники. GPL требует предоставить все инструменты для пересборки. Ну ок, если вы мне продемонстрируете пересборку программы из этого - я буду считать это за исходники.
> улучшения ядра для линукс-серверов от гугла?
$ git log | grep -i "@google.com" | wc -l
16019Ну вот как-то так. Это примерно на 3.19-rc6, @google.com - используется только сотрудниками гугла. Подсчет конечно топорный, но в любом случае, 16К хитов вы там сами колупайте на предмет того для серверов это было или для чего там еще :)
> Или гуглу можно ставить ДЖеПаЛ-Фанатов в любую позу
Да вот помнится даже когда был ведроид 3, сорцы жали на все. Но сорцы ядра выдавали...
> но 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
Вангую, что и всего остального вы не скоро дождетесь =)
> Пруфцы будут?Всему свое время. Вы или сами найдете пруфы "по хорошему", потратив свое время и проявив компетенцию (тогда я так и быть покажу, ибо историю не перепишешь). Или при случае вляпаются проприерасы. Это уже обещает забавным зрелищем :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 совпадений...
> время и проявив компетенцию (тогда я так и быть покажу, ибоУх ты, помнить тот случай с опененком и отмазками Тео оказывается верх компетенции?! Не делайте мне смешно =)
> Ох, камон, продолжайте в том же духе - минимум компетенции, максимум ЧСВ.
Отличная аргуметнация! Продолжайте в том же духе!
> А для тугих - прямым текстом: 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.Для тупых поясню -- гугл вообще не обязан предоставить сырцы. Т.е зарабатывать мильярды и не отдавать фанатам ничего взамен =)
> Ух ты, помнить тот случай с опененком и отмазками Тео оказывается верх
> компетенции?! Не делайте мне смешно =)В данном случае, компетенция - это разбираться в том что вы копипи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 :). А какие они там самописные либы на своих серверах используют - вот натурально, их собственное дело.
Ты читать умеешь? http://www.webcitation.org/6187NYSIz
MacOS X сертифицирована как UNIX'3
> А так то спецам по безопасности из фрибзды сервера сломал троянец помнитсяНе у спецов, а у разработчика, не безопасности/базы с ведром (т.е собственно самой бзди), а портов , не сломал сервак бзди, а "всего лишь" спер ссх-ключ -- а так да, все верно.
> Это Вы про BSD Unix?
>> безопасныеНет, это точно не про BSD. Во фре, например, буквально вчера прикрыли фееричный локальный рут (CVE-2014-8612).
Конкретнее: http://svnweb.freebsd.org/base?view=revision&sortby=date&rev...
Когда открывают уязвимости, которым не подвержены старые версии, вы почему-то тут не кукарекаете.
Если подвержены только новые версии, то а) уязвимость существовала недолго (шанс, что о ней знали и успешно эксплуатировали минимален) б) она уже закрыта т к мы вообще о ней услышали в новостях.
ASLR, PIE, NX - костыли. Их внедрение - глупость. Хороший спец их обходит на раз. ASLR for Windows вообще черт знает что! Явно маркетологи трудились...
> ASLR, PIE, NX - костыли. Их внедрение - глупость. Хороший спец их
> обходит на раз. ASLR for Windows вообще черт знает что! Явно
> маркетологи трудились...Замки и двери - глупость. Хороший специалист справляется даже с хорошим замком и крепкой дерью.
Врядли ASLR, NX, PIE можно сравнивать с основным замком и тем более дверями. Под дверями понимаю сам код и от его качества зависит - откроют дверь или нет. ASLR, NX, PIE - затрудняет, но нисколько не препятствует процессу. Защита от "дурака".
Ну так замки и двери тоже "защита от дypaка". Рота автоматчиков охраняет объект намного эффективнее.
Это так. Если у вас что-то есть и это кому то известно и очень нужно - ограбят. А вот рота автоматчиков будет куда более сдерживающим фактором. Суть в соотношении прилагаемых усилий с конечным результатом. Так же вытекает следующий фактор - защита информации от третьих лиц. Потому "умолчали" об этом баге, но кто то все-таки страдает недержанием и слил ее, подставив при этом много народа. Изоляция и разграничение прав доступа - хорошее, рабочее решение. Любая защита разбиваеться об единственный факт: предупреждён — значит, вооружён.
> Потому "умолчали" об этом баге, но кто то все-таки страдает недержанием
> и слил ее, подставив при этом много народа.Если народ считает себя святее апстрима - ну наверное они должны свою крутизну делом доказывать, патча баги не хуже оного. А если с этим вышли обсиратушки - так может стоило взять у апстрима более свежую версию, раз сами патчить не умеют?
Предполагаю, что проблема а широте охвата уязвимости. Уязвимость с 2000 года! Как много машин по прежнему функционируют на устаревшем оборудовании? Огромный парк машин! Я бы отнес подобную информацию к разряду очень опасной. Ее разглашение несет больше вреда чем пользы. Но нашелся же "герой"! И благодаря ему количество ботнетов резко возрастет.
> Ее разглашение несет больше вреда чем пользы.Наоборот, разглашение при наличии патча НЕОБХОДИМО иначе куча хомячков сидящих на Ынтерпрайз дистрах останутся под строгим наблюдением АНБ и прочих.
> Но нашелся же "герой"! И благодаря ему количество ботнетов резко возрастет.
НЕОБХОДИМО обновится! Так и те кто внёс уязвимость ею перестанут пользоватся и кто только узнал не воспользуются.
> дистрах останутся под строгим наблюдением АНБ и прочих.Для начала какое-нибудь кардерье скупит на черном рынке дырку и ненавязчиво соберет все кредитки хомячков в пределах планеты Земля. А потом еще перепродадут хомячков, которые не только ценный мех но и ценный бандвиз и вычислительный ресурс всяким ддосерам и спамерам.
Если дырка есть - о ней рано или поздно узнают. И буде лучше если юзеры и майнтайнеры будут не самыми последними кто узнал о дыре.
> Но нашелся же "герой"!И шо теперь, замочите эту француженку?
Жаль что подобные действия нельзя квалифицировать как халатность. Так же в свое время поступил и Google с Microsoft. Подлость. А страдают, как известно, остальные.
Пользователи Microsoft должны страдать. Что они выбрали - на то и имеют право.
Кто то выбирает Linux, а кто то Windows. Нельзя однозначно сказать, что Linux - хорошо, а Windows - однозначно плохо. У каждой свой кусок пирога. Своя ниша. Что до Google и слива дыр. Должна же существовать хоть какая то этика!
> же существовать хоть какая то этика!Действительно. За год вполне можно либу обновить. А если кто полез патчить круче апстрима и облажался - окей, халатность граничащая с преступной. Или вот микрософт. Ну вот только не надо врать что 3 месяца для конторы с такими ресурсами - недостаточно. Ну ладно б там ныл какой-нибудь единичный разработчики. Но тут не пройдет. Это халатная работа, спустя рукава.
Должна же быть минимальная этика и культура патчинга дыр вместо махрового пофигизма?!
Ты бы про этику ещё местным детям рассказал.
> много машин по прежнему функционируют на устаревшем оборудовании?Древность оборудования мало мешает обновлению этой либы самой по себе. Ну разве что какой-то лошпед купил огороженное (полу)проприетарное барахло и должен за это пострадать, как полагается по законам жанра.
> Огромный парк машин!
Проблемы негров шерифа не волнуют. За столько времени наверное можно уже было и заапдейтиться.
> Я бы отнес подобную информацию к разряду очень опасной. Ее разглашение
> несет больше вреда чем пользы. Но нашелся же "герой"! И благодаря
> ему количество ботнетов резко возрастет.Булшит. Если дыра есть, на черном рынке сплойты летать будут так и сяк. А тут глядишь обладатели антиков начнут шевелиться на предмет патчинга.
Мои слова - личное мнение. Можно сказать - догадка. Не являюсь экспертом в области безопасности или программистом. Не стоит принимать их за истину.
> 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 против него предпримутся ответные действия.
> 1. Всё что исполняется на процессоре не должно изменятся, а всё что изменяется не должно исполнятся!
> Использование ASLR и PIE добавляет рандомизацию в определённые частиДля пых-пых скриптов не работает? Не работает!
Есть легаси-софт, который не может в ASLR/NX? Есть конечно!
Значит -- все это фигня и ненужна!!
> Для пых-пых скриптов не работает? Не работает!А твой пых-пых такой кому нужен?
> Есть легаси-софт, который не может в ASLR/NX? Есть конечно!
Есть разрабы которые упорто выделяют память RWX
и не хотят писать правильные проги:
выделяющие память только R-X или RW-> Значит -- все это фигня и ненужна!!
Не нужны криворукие програмисты!!!
> Есть легаси-софт, который не может в ASLRЭтот вопрос тоже решается сменой програмистов, на тех которые умеют писать позиционно независимый код!
В прочем всё не так печально. Почти все обычно используемые проги, сервера и десктопа нормально работают и с NX и с ASLR. Замеченные исключения это начальные версии кодеков использующие see инструкции и тому подобное... Потом с програмистами разговаривают и они преимущественно фиксят.
Исключением есть Ынтерпрайз софт, без доступа к исходникам, и програмистами которым "за это не платят".
> В прочем всё не так печально. Почти все обычно используемые проги, сервера
> и десктопа нормально работают и с NX и с ASLR.Дело в том, что достаточно одной такой либы-костыля в вирт.-аддр. пространстве процесса ;).
Хотя самый прикол был пару лет назад, когда вышла очередная заметка о том, что принудительно-загружаемые либы всяких (довльно известных) анти-вирей и "огнестен" в окнах все еще "не умеют" в аслр/nx и, соответственно сводят на нет все преимущества этих технологий.
> том, что принудительно-загружаемые либы всяких (довльно известных) анти-вирей и
> "огнестен" в окнах все еще "не умеют" в аслр/nx и, соответственно сводят
> на нет все преимущества этих технологий.Насколько я понимаю, все либы билдуются как position-independent, просто потому что нет никаких гарантий что дефолтные адреса под которые сбилдован файл вообще будут свободны на момент загрузки либы. Как либа может мешать ALSR в свете этого факта?
> все либы билдуются как 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" признак позиционно независимых бинарей. А у тебя в дистре статически собраны...
Чтобы поддерживать 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.И в скольких дистрах это всё уже реализовано?
> Чтобы поддерживать ALSR они должны специально собиратся -fPIC или -fPIE и линковатся -pie:Так динамическую либу проблематично собрать НЕ как позиционно независимый код. Потому что когда загружается программа - совсем не факт что дефолтные адреса на которые образ либы изначально собран вообще будут свободными. Поэтому IIRC все динамические либы подразумевают что их можно перемещать в другие адреса.
> Кроме того надо PAX ядро которое собственно и осуществит рандомизацию.
ALSR уже довольно много где реализован.
> И в скольких дистрах это всё уже реализовано?
ALSR и NX - довольно много где. И прочие fortify source'ы, relro/bind now и что там еще.
Даже у слоупочных дебианщиков ну и убунтуев - скрипт hardening-check сто лет как есть. И не для красоты, заметим.
> Даже у слоупочных дебианщиков ну и убунтуев - скрипт hardening-check сто лет как есть. И не для красоты, заметим.Дебианщики и paxtest написали...
Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой и дебом эти проекты очень мало пересекаются.
> Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой
> и дебом эти проекты очень мало пересекаются.Кроме одной "мелочи" - все сетевые сервисы как-то так собираются нынче с наработками debian hardening'а.
>> Но paxtest и hardening-check относятся к Адамантикс и Hardened Debian... С убунтой
>> и дебом эти проекты очень мало пересекаются.
> Кроме одной "мелочи" - все сетевые сервисы как-то так собираются нынче с
> наработками debian hardening'а.Это они на будущие, без PAX ядра смысла в pie нет.
Мне кажется что в данном случае должен бы защитить -fstack-protector и -fstack-protector-all оно же оносится к переполнению кучи? Жаль протестить не могу у меня давно 2.19
Вот интересный проект http://levee.epfl.ch/ способный устранить данный клас уязвимостей. Или не писать больше на C/C++...
> Насколько я понимаю, все либы билдуются как position-independent, просто потому что нет
> никаких гарантий что дефолтные адреса под которые сбилдован файл вообще будут
> свободны на момент загрузки либы. Как либа может мешать ALSR в
> свете этого факта?Ну как, как - легаси, вестимо ;)
Насколько я помню, нужен флэг "поддержки" аслр -- иначе по дефольту либа будет грузится в указанный ImgageBase (легаси). А так как либы грузятся достаточно рано (при старте процесса и ДО отработки ImportAddressTable - на этот момент загруженны (вплоть до семерочки было так, восьмерочку не тыкал) по дефолту ntdll и kernel32.dll, может еще 1-2 либы), т.е считай, что адрес этой либы не меняется.
> А так как либы грузятся достаточно раноимелись в виду либы антивирей и огнестен.
> будет грузится в указанный ImgageBase (легаси).Для начала - либа никогда не может надеяться на то что ее в Base вгрузят. Потому что никто не гарантирует что layout адресного пространства процесса на момент вгрузки либы будет содержать эти адреса свободными. Поэтому насколько я помнб, все либы собираются как position-independent. Чтобы при такой ситуации иметь возможность перенести либу в другие адреса. По поводу чего вопрос сводится в основном к желанию loader'а либы сделать рандомизацию, как я понимаю.
> А так как либы грузятся достаточно рано (при старте процесса и ДО отработки
> ImportAddressTable -На минутку, либы можно еще и явно вгружать и импортировать из них функции.
> на этот момент загруженны (вплоть до семерочки было так, восьмерочку не тыкал)
> по дефолту ntdll и kernel32.dll, может еще 1-2 либы), т.е считай,
> что адрес этой либы не меняется.Нет, ну я понимаю что микрософт может лохануться даже в этом. Но не все же такие упыри.
А так, ну вот например:
libc-2.19.so:
Position Independent Executable: yes
>> будет грузится в указанный 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.
> Там кстати и насчет сабжа есть:Тьфу, "сабж" -- это в соседний тред (clamav)
> Я в общем-то не спорю (хотя видел либы с выпилинными реалоками -Если утонченно извращаться - возможны фокусы поинтереснее. Вон например сабжевую либу можно запустить как исполняемый файл. Либа расскажет что это такое, какой версии, etc. Т.е. оно одновременно и либа и executable. Требует немного утонченного шаманства на уровне линкера (но чем-то таким настоящие системщики и отличаются от сброда).
Релокейшны из либы выпилить технически, конечно, можно. Но это чревато тем что при попытке вгрузки либы лыжи встанут на асфальт и либу вообще не удастся вгрузить. Если адреса заняты а релокаций нет - что остается? Правильно: срубить загрузку либы с ошибкой.
А так - у винды в работе с либами вообще есть несколько веселых заскоков, живущих с незапамятных времен. Путем некоторых относительно честных манипуляций (только системные вызовы, никаких руткитов и суперпривилегий) можно слепить например стелс-процесс который напрочь не видно в манагерах задач, но который выполняется.
> была либа, обработанная "противо-крякерской-защитой")
Всякие пакеры и протекторы делают загрузку кода в память сами, перехватывая инициативу на себя. Что они при этом и как делают с кодом - это очень отдельный вопрос. Могут делать что угодно. В том числе - взять релокации где-то сбоку, в кастомном формате и самолично их обсчитать, например. Если не лениво кодить свой сильно кастомный лоадер и обработку кода - это все возможно. При этом "нет релокаций" лишь с точки зрения того кто ожидал их в дефолтном месте найти, а на самом деле есть, но где их брать и как применять - пакер/протектор сам разбирается.
> Т.е да:
>> вопрос сводится в основном к желанию loader'а либы сделать рандомизациюИменно. И если микрософтушка это не сделал - это к ним вопросы, имхо.
> помню) одно время даже екзешники такие выдавали - т.е с нужными реалокми.
Да вроде почти все компилеры по дефолту выдают исполняемые файлы с релокейшнами. В случае EXE их можно срезать. Тогда исполняемый файл разумеется будет по фиксированным адресам.
> Да, можно -- но для "суперсекурных" дополнений антивирей желательно загрузить
> либу как можно раньше, что бы значит контроль был и все такоеДля этого есть всякие указания лоадеру ОС сделать прелоад либы. В *никс-образных через переменную окружения LD_PRELOAD, в винде - через какое-то тошнилово с реестром.
> (я честно не понял, зачем нужно грузить либу, если все равно добавляются
> хуки в ядро)Фиг знает. Может чтобы сложнее было синхронно и незаметно везде вынести антивиря отовсюду, до того как он заметит что что-то идет не так?
> Ну или SetWindowsHookEx.Ну это все круто, но меня анатомия виндов нынче не очень интересует.
> которой можно менять опции -- т.е "forcing aslr" и все
> в таком духе. А вот "хай-секюрити-софт" -- как раз наоборот :)Насколько я помню - форсирование ALSR везде может привести к тому что часть программ запускаться не будет (как раз поди те где какой-то умник релоки срезал).
[заскипано]
Как я уже сказал, интимные особенности виндов мне малоинтересны.
Я разве спрашивал как оно работает? Более-менее понимаю суть работы данных механизмов.
Bypassing PaX ASLR protection.
> Bypassing PaX ASLR protection.PaX и ASLR очень мощные и нужные средства защиты. Они защищают в большинстве случаев и по этому должны использоватся. Но также надо понимать что большинство это НЕ ВСЕ....
Да, с либой печально вышло, на glibc жалобы были давно и разного плана есть альтернативы: http://www.musl-libc.org/
Вот пример мини дистрибутива реализующий всё выше сказаное: http://alpinelinux.org/about/
> Да, с либой печально вышло, на glibc жалобы были давно и разного
> плана есть альтернативы: http://www.musl-libc.org/Замена, блин. Так то uclibc сто лет есть. В мелочевке всякой используется. Но он не стопроцентная замена. Как и этот урезок.
уже вышло для Centos.http://lists.centos.org/pipermail/centos-announce/2015-Janua...
> Атака затруднена в серверных программах, которые используют в gethostbyname() для обратной проверки данных DNS, а также в привилегированных suid-утилитах, в которых вызов getaddrinfo() применяется только при сбое выполнения inet_aton().Переведите, пожалуйста.
Отголоски дырявых последних двух лет (2013-2014) дают о себе знать даже сейчас.
Ага, особенно эта уязвимость с 2000 года.
> Ага, особенно эта уязвимость с 2000 года.
>> При этом проблема была устранена в мае 2013 года [...]
И? Ты поехавший, ты в курсе?
Что-то мне подсказывает, что это касается ~100% эмбедовки. /дальше следуют ~100кБ ненормативной лексики/
> Что-то мне подсказывает, что это касается ~100% эмбедовки. /дальше следуют ~100кБ ненормативной
> лексики/Там обычно другой libc.
uclibc
> uclibcА кроме всего прочего удакам выпускающим прошивки пора выбросить свой окаменелый инструментарий на помойку. А то до сих пор находятся упыри которые какое-нибудь ядро 2.6.32 отгрузить ухитряются, собраное gcc 4.3 и весь остальной софт - из той же эпохи мезозоя. Але, производители! Хватит пополнять ботнеты своим замшелым крапом.
Да вы еще оптимист с 4.3. Под контроллеры MOXA сейчас ничем новее 3.4 не соберешь (и то gcc надо ручками собирать). А так они до сих пор тулчейн 2.95 предлагают с древним uclibc.
> Да вы еще оптимист с 4.3.Нечто такое было в прошивке какой-то китайчины. Видимо из вендырского sdk.
> Под контроллеры MOXA сейчас ничем
> новее 3.4 не соберешь (и то gcc надо ручками собирать). А
> так они до сих пор тулчейн 2.95 предлагают с древним uclibc.Зато в следуюший раз у покупателей есть резон требовать более нормальную поддержку и иметь дело с теми кто ее обеспечивает.
> Что-то мне подсказывает, что это касается ~100% эмбедовки.Во первых, в эмбедовке glibc используют редко. Во вторых, если кто считает что он особо привилегированный и его обновления не касаются - ну пусть и получает тогда участие в ботнете.
интересно, маршрутизаторы часто пользуют glibc?
Слава Ктулху - нет.
Ну вообще-то, не факт, что в uClibc нет уязвимостей ещё не обнаруженных.
Для debian squeeze интересно когда выпустят.
> Для debian squeeze интересно когда выпустят.Весной
>> Для debian squeeze интересно когда выпустят.
> ВеснойВсмысле debian squeeze выпустят весной, а патч для для него не нужен, в нём уже новая glibc без уязвимости.
>>> Для debian squeeze интересно когда выпустят.
>> Весной
> Всмысле debian squeeze выпустят весной, а патч для для него не нужен,
> в нём уже новая glibc без уязвимости.Милейший, Вы перепутали вот-вот,но ещё не выпущенный, jessie с oldstable-lts squeeze.
> Для 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 собираются
> 2/ официальные - да, https://lists.debian.org/debian-lts/2015/01/msg00043.html собираютсяПоправочка: уже, https://lists.debian.org/debian-lts-announce/2015/01/msg0001...
>Примечательно, что проблема присутствует в коде Glibc начиная с версии 2.2, выпущенной в ноябре 2000 года.что-то уровня многолетнего бага в WMF в винде