В пакете Dnsmasq (http://www.thekelleys.org.uk/dnsmasq/), объединяющем в себе кэширующий DNS прокси и DHCP сервер, обнаружено (http://www.coresecurity.com/content/dnsmasq-vulnerabilities) две уязвимости, позволяющие удаленному злоумышленнику добиться выполнения своего кода. Для проявления уязвимости Dnsmasq должен быть запущен с поддержкой TFTP-сервиса, которая по умолчанию не используется в сборке Dnsmasq из состава дистрибутивов OpenWRT и DD-WRT, на которых построено множество различных точек доступа и небольших маршрутизаторов. Уязвимости устранены в версии dnsmasq 2.50 (http://www.thekelleys.org.uk/dnsmasq/).
Компания Nokia объявила (http://qt.nokia.com/about/news/qt-patches-released-addressin...) о выпуске набора патчей исправлением проблем безопасности в библиотеке Qt версии 4.3.0 и выше. Проблема связана с ошибкой в реализации класса QSslCertificate и приводит к некорректному парсингу SAN (Subject Alternate Names) полей в сертификатах X.509, когда в эти...URL: http://www.coresecurity.com/content/dnsmasq-vulnerabilities
Новость: http://www.opennet.me/opennews/art.shtml?num=23245
у меня из реп обновились кеды до версии 4.3.1
но нигде ни слова об этом.
может с этими дырками связано...
Ну нет слов. Linux - это конечно хорошо, но неужели господа девелоперы не могут ужесточить проверки в разработки ядра и все такое. Блин, просто нет слов. :-(
Кутя как бы не только на линухе есть. Да и dnsmasq тоже. А ядро пропатченное уже приехало...
Нет, просто вопрос во времени жизни этой уязвимости. Во всяких нуль-дей она могла лежать несколько лет и машины можно было хачить просто на раз. Жесть. Хоть я и являюсь несколько лет пользователем, контрибъютером линукса и все-такое, но честно, вот в таких случаях хочется ругаться самыми некрасивыми словами. Это же действительно ж@па.
>Кутя как бы не только на линухе есть. Да и dnsmasq тоже.
>А ядро пропатченное уже приехало...Паранойя подсказывает мне, что опасность приближается со стороны автоматических систем установки обновлений. В последнее время прослеживаются тенденции в попытке организации распространения злонамеренного кода именно через обновления пакетов или новые версии программ. Вскрывшиеся попытки взлома инфраструктур известных проектов подтверждают эти подозрения. Один подкупленный, невнимательный или озлобленный человек в среде разработчиков и миллионы пользователей могут ничего не подозревая установить обновление с закладкой. Open source сообщество у всех на виду, организовать внедрение злонамеренного кода в легитимный продукт вполне реально, радует только то, что и обнружить это внедрение значительно проще. Но и пугает ненулевая верятность того, что могут и не обраружить вовремя. А была ли ошибка в openssl пакете Debian случайной ? Вообще, разбирая уязвимости, не так редко возникает впечатление, что некоторые из них созданы специально.
Вот несколько ссылок для размышления:
http://www.opennet.me/opennews/art.shtml?num=23208
http://www.opennet.me/opennews/art.shtml?num=22833
http://www.opennet.me/opennews/art.shtml?num=22511
http://www.opennet.me/opennews/art.shtml?num=22496
http://www.opennet.me/opennews/art.shtml?num=20818
http://www.opennet.me/opennews/art.shtml?num=20129
http://www.opennet.me/opennews/art.shtml?num=17510
http://www.opennet.me/opennews/art.shtml?num=16523
http://www.opennet.me/opennews/art.shtml?num=13138
http://www.opennet.me/opennews/art.shtml?num=11747
http://www.opennet.me/opennews/art.shtml?num=16952
http://www.opennet.me/opennews/art.shtml?num=15846
http://www.opennet.me/opennews/art.shtml?num=8298
http://www.opennet.me/opennews/art.shtml?num=7890
>В последнее время прослеживаются тенденции в попытке организации распространения
>злонамеренного кода именно через обновления пакетовВ общем то логично, ибо удобный канал для массового заражения. Но дело в том что системы обновления в принципе создавались с учетом таких возможностей и неплохо держатся против таких реалий. Взлом сервера - даже не полдела. А подписать пакеты правильным ключом? А вот к таковым ключам обычно относятся довольно щепетильно и прецедентов чтобы кто-то смог раздать свой правильно подписанный пакет правильным ключом я что-то не припоминаю.
> или новые версии программ.
Опять же в теории - возможно. На практике - в изменения между версий смотрят майнтайнеры и просто кучи любопытных. А какие-нибудь дебианщики еще и потормозят пару лет до интеграции новой версии апстрима, спортировав секурити фиксы в древнюю версию программы.В итоге стройной скоординированной атаки скорее всего не выйдет и вообще будет обнаружено быстрее чем хотелось бы хакерам, имхо.
>Вскрывшиеся попытки взлома инфраструктур известных проектов подтверждают эти подозрения.
По-моему, заранее было понятно что инфраструктуры известных проектов будут ломать - вкусные мишени. Можно рассматривать это как хороший признак - открытые проекты становятся популярны. И - да, им придется учиться с этим жить, а это подразумевает и пристальное внимание хакеров.
>Один подкупленный, невнимательный или озлобленный человек в среде разработчиков
>и миллионы пользователей могут ничего не подозревая установить обновление с закладкой.Не все так просто - коммиты обычно читает немало народа а бинарные пакеты подписаны. Посему закладка в сорцах апстрима имеет все шансы быть обнаруженной. Особенно какими-нибудь дебианщиками с их нудной и геморной практикой debdiff'ов, которая тем не менее, дает понимание что, где и нафига было изменено в новой версии.В бинарных обновлениях?Просто сломать сервера - не вариант, приватный ключ от этого у хакера не появится.Саботаж со стороны того у кого есть доступ к такому ключу?Возможен.Но оно такое у всех возможно - если вы не доверяете никому - не надо результатами их труда пользоваться.Вдруг они там мину подложили? :)
>Open source сообщество у всех на виду, организовать внедрение злонамеренного кода
>в легитимный продукт вполне реально,Только вот в силу открытости это как раз обычно весьма быстро обнаруживается. Я помню только 1 случай поимения через официальный сайт которое имело какой-то успех - мозильщики и вьетнамский перевод FF. Почему-то тем не менее это был виндовый инсталлер :)
> радует только то, что и обнружить это внедрение значительно проще. Но и пугает
>ненулевая верятность того, что могут и не обраружить вовремя.Жить вообще страшно - от этого умирают. Что предлагается? Я вижу несколько опций, и ни одна из них панацеей не является.
1) Можно самому стать майнтайнером и проверять все и вся лично за апстримами ну а по части управления версиями в системе будет некого винить кроме себя. Только вот голова вспухнет: трудозатраты нереальные в случае "боевых" систем на более-менее разлапистых конфигурациях. Самолично отслеживать жизнь кучи программ и все изменения в них и их проблемы - опухнуть можно.
2) Можно не ставить апдейты. Но тогда у вас будут известные дыры. И вас через них могут поиметь, собственно. Вариант для камикадзе которые боятся майнтайнеров больше чем хакеров.
3) Можно ставить апдейты, допустив что майнтайнеры и авторы все-таки не козлы а добавочные проверки изменений в процессе разными людьми сделают свое дело. Как правило это наиболее вменяемый вариант из всех. Можно включить режим параноика - проверять какие апдейты и нафига. Если повезет то это попроще 1) т.к. к какомунить debian stable их не так уж много.
>А была ли ошибка в openssl пакете Debian случайной ?Я так не считаю. Это - логичное следствие политики дебианщиков "мы - святее папы римского".В смысле, они себя считают правильнее чем апстрим.Но криптографический код - это не то что можно трогать своими руками просто так, не будучи экспертом в области криптографии.Криптография этого не прощает.И сделав казалось бы совсем безобидное изменение можно крепко порушить криптографический алгоритм.Поэтому писать и изменять криптографический код должны только те кто хорошо разбирается в криптографии и отдает себе отчет какие последствия его действия несут с точки зрения криптографии.Дебианщики забили на это правило.За что и поплатились - небольшой и казалось бы безобидный патч очень дорого обошелся с точки зрения криптографии.Те кто интересовался криптографией знают что совать лапы в криптографический код - чреватая затея в случае если вы вдруг не Шнайер.Ну а дебианщики наступили на те грабли на которые и должны были наступить.И это не случайность а закономерное следствие из политики "мы святее папы римского".
>Вообще, разбирая уязвимости, не так редко возникает впечатление,
>что некоторые из них созданы специально.В случае OpenSSL скорее похоже на то что некоторые не поняли что криптография ошибок не прощает но зато свою стандартную политику "мы святее папы римского aka наших апстримов" применить не забыли. Это IMHO не саботаж а обычное такое раздолбайство по части криптографии. Хотя результат в сумме и одинаковый, да.
>Вот несколько ссылок для размышления:Ссылки то полезные. Вы б еще сказали - что по вашему мнению стоит делать :)
Для лично себя я придумал примерно такой подход в случаях когда паранойя долбит: побить все виртуализацией на минимальные контейнеры по принципу 1 контейнер - один сервис, которые просто мониторить на изменения и аномальную активность. При этом отловить аномалии просто и в конечном итоге не так уж важно чем они вызваны - внутренним саботажем с бэкдором или внешним вторжением. Отловится и то и другое. Скажем поведение вебсервера - оно заведомо известно. И если вебсервер вдруг зачем-то юзанул системную утилиту, открыл левый порт, запустил странный процесс или сунулся в /etc/passwd например - значит не такой уж он и вебсервер каким кажется, а? :)
>А подписать пакеты правильным ключом? А вот к таковымПроще простого, собирают материал про какого-нибудь разработчика бывшего хиппи балующегося "травкой", приезжает дядька в погонах и говорит "будем заводить дело или как ?" Все, ключ в кармане, если вскроется - гнусные хакеры взломали сервер. А то и утюг поможет. Зачем взламывать когда есть человеческий фактор и социальная инженерия ?
>>А подписать пакеты правильным ключом? А вот к таковым
>
>Проще простого, собирают материал про какого-нибудь разработчика бывшего хиппи балующегося "травкой", приезжает
>дядька в погонах и говорит "будем заводить дело или как
>?" Все, ключ в кармане, если вскроется - гнусные хакеры взломали
>сервер. А то и утюг поможет. Зачем взламывать когда есть
>человеческий фактор и социальная инженерия ?Что б утюг ставить, надо знать с какой целью.
1. Явная цель - известна жертва, её софт, политика применения этого софта.
Пример, конкурент, юзающий opensource, RedHat, и постоянные апдейты.
2. Общая цель - сбор статистики, компромата, ....
Пример. ЦРУ, собирающая статистику по населению, пристрастия, политику, и т.п.,
для дальнейшего регулирования психикой населения, рождаемостью, длительностью жизни,
через ГМО продукты от фирм ВиммБильДан, Нестле, Mars LLC, Maggi, втираемые с шампунями,
вдуваемое с сигаретами.
Зачем устраивать терракты если население само всё это жрет,пьёт, курит.Хотите прикол, а может и нет.
Из всех знакомых у кого уже есть дети, девочки в 95% случаев, и только 3-ое!!! мальчиков.
Эти трое, из так называемых малообеспеченных семей, то есть не хрут сникерсы, моются
шампунями ромашка, зубной пастой "Мятная", едят гречку с котлетами, щи и капусты за 12 руб.А знакомых с детьми, сейчас посчитаю,.... около 25 (у 4 по двое девочек).
Родители 1977-1982 года рождения, самое активное население.
Может америкосы дебилы, а тыл на случай войны у нас будет хороший.
В связи с увеличением точности оружия, массовая передовая уже не нужна!Закрадывается мысль, может это наши спец службы такую х..ню творят.
И из расчёта подготовки населения, война должна начаться через 8-10 лет.А ещё, многие Историки говорят о цикличности истории, точнее спиралевидности.
В обратную сторону
1945-1941 - 2 Мир. Война.
1912-1916 - 1-я
1900-1905 - ипошки
1852-1857 - Крым (ну с турками раз в 100 лет повоевать это святое)
1812 - Кутузофф party, Borodino Open Air
1786-1792 - DJ Суворов feat. Ушаков & Потёмкин.а дальше вообще попа Чурки, Немцы, Татары, Поляки, Хохлы,
>Проще простого, собирают материал про какого-нибудь разработчика бывшего хиппи
>балующегося "травкой",И чего? Остальные будут на это все смотреть? Да они вой на полинтернета поднимут. Оно кому-то надо?
>Все, ключ в кармане, если вскроется - гнусные хакеры взломали сервер.
Попробуйте угадать через сколько это вскроется и какой резонанс вызовет? :).Какой-то почти научно фантастический сценарий. В дебияноподобных к тому же паливный и неудобный, потому что есть сорцы из которых делается пакет и все диффы как на ладони. Втихаря подпихнуть что-то в такой схеме и длительно оставаться незамеченным довольно проблематично. Например кто-то зафетчит сорцы и просечет несоответствие сорца бинарям или же левак в сорце (если там тоже бэкдор есть). И?
>не полдела. А подписать пакеты правильным ключом? А вот к таковым
>ключам обычно относятся довольно щепетильно и прецедентов чтобы кто-то смог раздать
>свой правильно подписанный пакет правильным ключом я что-то не припоминаю.То-то в прошлом году Fedora и Red Hat ключи меняли :-) Если утащили SSH-ключ, то и ключ для подписывания пакетов можно утащить.
>Опять же в теории - возможно. На практике - в изменения между
>версий смотрят майнтайнеры и просто кучи любопытных.Это скорее исключение из правил. Разработчики разные бывают, есть Google с двойным рецензированием кода и Postfix с очень жесткой проверкой патчей, а есть proftpd в который патчи раньше брали лишь бы собиралось. У мантейнеров тоже время не резиновое, оформили новую версию в пакет и за это спасибо, в код смотрят единицы, а тех кто аудитом занимается можно по пальцам пересчитать.
>По-моему, заранее было понятно что инфраструктуры известных проектов будут ломать - вкусные
>мишени. Можно рассматривать это как хороший признак - открытые проекты становятся
>популярны. И - да, им придется учиться с этим жить, а
>это подразумевает и пристальное внимание хакеров.Да, сейчас интерес у атакующих пока только спортивный, хуже будет когда корыстные мотивы появятся.
>Не все так просто - коммиты обычно читает немало народа
Это в идеале, реально - времени у многих разработчиков не хватает, а интерес посторонних носит непостоянный характер. К томуже легко разобраться можно если 10 строк коммит, а если 10 000 ?
>2) Можно не ставить апдейты. Но тогда у вас будут известные дыры.
Серьезных дыр не так много, обычно мелочь разная или требуются особые условия.
>Ссылки то полезные. Вы б еще сказали - что по вашему мнению
>стоит делать :)SELinux хороший шаг в правильную сторону, хотя мне лично подход AppArmor/Tomoyo более симпатичен. Упаковка критичных программ в chroot/виртуализированные контейнеры тоже вариант.
Некоторые мысли изложены на странице http://wiki.opennet.ru/SecurityTips
>То-то в прошлом году Fedora и Red Hat ключи меняли :-) Если
>утащили SSH-ключ, то и ключ для подписывания пакетов можно утащить.Вообще - в теории возможно возможно все. На практике некоторые вещи труднореализуемы а потому редки и\или маловероятны а в случае возникновения быстро устраняются. Выбор то в итоге какой? Если софт не апдейтить - однажды поимеют через найденные в старых версиях софта дыры. А если апдейтить - есть не нулевой риск что в сорцы апстрима, пакеты или там еще чего кто-то нехороший подложит бяку. Выбирая из двух зол - выбираем меньшее. Статистика взломов за столько лет вроде свидетельствует о том что выбор "апдейтить софт" (как минимум при современных реалиях) - в целом правильный.
А если рассуждать о том что в принципе может быть трындец - да, он может быть. Three Mile Island и Чернобыль тоже вон как оказалось - вполне возможны. Хотя и не должны бы были по идее случаться. Если уж люди могут в таких областях облажаться - то чего уж там про какие-то апдейтеры говорить.
>Это скорее исключение из правил. Разработчики разные бывают, есть Google с двойным
>рецензированием кодаО, спасибо что напомнили про гугл. Дело вот в чем: буквально на днях один знакомый "похвастался" что их нагрел хулиган-хакер, который в меру своей дури просто массово ломанул аккаунты юзеров, без особых причин. О хакеришке который не больно то и скрывался, им известно что он работает в гугле. А пострадавшие еще и юзали gmail, что вызывает некие нехорошие подозрения. Гуглу попробовали отрапортовать факт что у них в конторе работает такой вот нехороший тип. Реакция гугли? Ноль. В итоге перец с жидковатым мозгом и неуемной жаждой дестроя, очевидно, до сих пор работает в гугле.
P.S. кто там из особо храбрых хотел все свои данные гугле доверять?Подумайте о том что не все сотрудники гугля - кристально честные и ответственные личности ;)
P.P.S. детальной информации о взломе и логов у меня разумеется нет, так что кто хочет может считать это городскими легендами и т.п. если хочет. Тем не менее если кто в курсе как эффективно допинаться до гугли по таким вопросам - просветите, вдруг еще пригодится?
> и Postfix с очень жесткой проверкой патчей,
Я как бы люблю софт где на секурити не забивают. Но такого софта - не так уж много, одним постфиксом сыт не будешь. И кроме того - а кто будет проверять проверяющих? И какие гарантии что их намерения - благие? И что их не прессанули синхронно например чтобы они "не заметили" нечто, etc? По большому счету это ведь тоже никто гарантировать не может на 100%.
>а есть proftpd в который патчи раньше брали лишь бы собиралось.
Да, у всех разные подход к безопасности. А еще чем крупнее софт - тем больше вероятность что он с багами и дырами при прочих равных.
>У мантейнеров тоже время не резиновое, оформили новую версию в пакет и за
>это спасибо, в код смотрят единицы, а тех кто аудитом занимается
>можно по пальцам пересчитать.Тем не менее те же дебиянщики с их выносящей мозг политикой всенепременного оформления обновлений пакетов в виде debdiff'ов как я понимаю нацелены именно на это - понимать, с точностью до межверсионного диффа какие изменения vs прошлая версия вносятся в пакеты раздаваемые на боевые системы. Все-таки они местами не зря свое занудство про stability устраивают. Правда иногда оно же им и боком выходит.
>Да, сейчас интерес у атакующих пока только спортивный, хуже будет когда корыстные
>мотивы появятся.И это тоже. Но давайте посмотрим что получается если софт не обновлять? Рассмотрим второе зло из которого можно сделать выбор. За примерами далеко ходить не надо - есть же Windows! Который как раз печется только о обновлении себя самого. А о пакетизации софта и уж тем более обновлении оного - не печется вообще. Как раз то что надо примерно. Что получается? В *никсах у юзеров быстренько обновляется 1 мелкая либа (например zlib или libpng очень показательны). Штатными средствами системы и ее же майнтайнерами. И в итоге все как бы живы и здоровы. А что получается у тех у кого такой роскоши нет, т.е. в виндах и прочая? Правильно - они сидят с программами с древними либами. В клиническом случае (винды) еще и с приватными копиями оных, размазанными по миллиону разных дир а то и попросту влинкованными в бинари статически (чтобы ну совсем уж обуть юзера на возможность патчинга?).Наверняка хацкеры через этот нехитрый факт поимели и наверное даже до сих пор продолжают иметь немало машин (про эпичные дыры в zlib и libpng используемых в каждой второй программе еще не все забыли?).
Представляете себе сколько было и наверное до сих пор осталось юзеров с необновленным злибом как раз из-за того что никто не заморочился обновлением библиотек в системе "windows"? Хороший пример того что бывает если софт не апдейтить. И ведь оказаться от zlib сказав что оно дрянь - не вариант, правда? :)
>интерес посторонних носит непостоянный характер. К томуже легко разобраться можно если
>10 строк коммит, а если 10 000 ?Все так, но в конечном итоге - по моим наблюдениям опенсорц лучше справляется с данной напастью чем остальные. А не обновлять софт - не выход. Вот вы готовы например использовать старую zlib (или libpng) с багом позволяющим выполнение кода? А может вы готовы волевым усилием выбросить эти либы из системы как плохие? Или переписать с нуля? И что вас больше пугает - шансы что кто-то кто-то в теории с новой версией zlib вам левак может подсунуть? Или вполне практический риск того что вас могут ремотно древним эксплойтом огреть? Лично меня больше пугает что весь сетевой софт юзающий zlib если ее в такой ситуации не обновить - по сути сможет от неправильных хакерских данных код запустить. Поэтому я как-нибудь уж лучше обновлю zlib'у, допустив что ее авторы и майнтайнеры не уроды (а в случае сильных сомнений перепроверив наконец что там за патчи такие). А кто хочет - может наздоровье дожидаться в такой ситуации пока хаксоры снимутся с тормоза и додумаются запихнуть эксплойт в любые данные пожатые zlib-ом (коих везде навалом).
>Серьезных дыр не так много, обычно мелочь разная или требуются особые условия.
Это когда как. Я вот например эпичную дыру в zlib еще не забыл. И по моим наблюдениям - именно апдейты в этом случае и спасли народ от массовых взломов. А кто не проапдейтил эту либу или линканул ее статически - долго еще икали когда их эксплойтами огревали и было очень много красивых взломов всего и вся. Наверное некоторых особенно тормозливых (в виндах, etc) можно до сих пор при желании таким эксплойтом долбануть. Особенно если кто юзает древние программы на поддержку которых авторы уже забили.
Или вон дебианщики: облажавшись и осознав это они не забыли пофикшеную либу прислать. Было бы лучше если бы они положили дефектную либу в релиз а потом еще и никто бы не обновился и их нагрели радостные толпы хакеров? А так - еще и блеклисты слабых ключей через апдейтер приехали. Что несколько облегчило парирование проблемы и проверку систем. Хотя зуб на самовольный патчинг майнтайнерами кода касающегося криптографии - остался, да :E. Трогать код касающийся криптографии должни криптографы. Точка.
>SELinux хороший шаг в правильную сторону,
Идея хороша, но вот реализация... геморройный он не в меру: не дай боже шаг в сторону от стандартных шаблонных применений и мозг запросто взорвется. Это - плохо. Секурити должна быть юзабельной - иначе ее первым делом зарубят. Чтобы не мешала достижению более приоритетных чем гипотетическая оборона от хакеров задач, например.
>хотя мне лично подход AppArmor/Tomoyo более симпатичен.
Мне в общем то тоже.
>Упаковка критичных программ в chroot/виртуализированные контейнеры тоже вариант.
В случае минимальных виртуалок мониторить изменения проще (одна сложная задача разбивается на кучу простых и мелких, которые можно постепенно и независимо реализовать). И есть несколько фокусов которые могут испортить хакерам настроение. Например ограничение ресурсов не даст хакеру устроить эффективный DoS на ресурсы. Мониторить состояние виртуалки можно невидимыми (хакеру) процессами - с хоста (который вообще хакеру по сети не обязан быть доступен). Ну и там снапшот исправного состояния можно хранить, равно как сделать в автоматическом режиме снапшот расхаканного окружения и остановить его к такой-то фене до разбора полетов. И изоляция хорошая - обычно вообще никаких взаимодействий кроме явно и специально организованных + дележка ресурсов. При том если сломали скажем почтовик - сломали только почтовик. А www, ftp и прочие например могут работать в соседних контейнерах дальше. Минусом видится некая добавочная возня и оверхед по ресурсам. Chroot в этом плане - примерно как деревянный щит против стального: уровень изоляции сам по себе там немного не тот которого хотелось бы для похаканного окружения. Грубо говоря - идея появилась после смотрения на руткиты. Это (с точки зрения хакера) тоже что-то типа руткита. Только работает на благо админа а не во вред :)
>Некоторые мысли изложены на странице http://wiki.opennet.ru/SecurityTipsИногда почитываю...
pavel@amd64:/> mkdir /tmp/EXPLOIT && cd /tmp/EXPLOIT
pavel@amd64:/tmp/EXPLOIT> wget -с http://www.risesecurity.org/exploits/linux-sendpage.c
pavel@amd64:/tmp/EXPLOIT> gcc linux-sendpage.c -o linux-sendpage
pavel@amd64:/tmp/EXPLOIT> ./linux-sendpage
mmap: Permission denied:( Ниработат
попробуй так:
gcc -Wall -m64 -o linux-sendpage linux-sendpage.c
rus@home:/tmp/EXPLOIT$ ./linux-sendpage
sh-3.2$ mkdir /root/123
mkdir: невозможно создать каталог `/root/123': Отказано в доступе
sh-3.2$ id
uid=1000(rus) gid=1000(rus) группы=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),110(netdev),116(powerdev),117(fuse),1000(rus)И что с этим делать могут?
А у меня на Debian Stable почему-то работает :( В Debian до сих пор не обновили ядро?
>А у меня на Debian Stable почему-то работает :( В Debian до сих пор не обновили ядро?обсуждали ж уже - http://www.opennet.me/opennews/art.shtml?num=23014
обираешь пульсаудио и sudo sysctl vm.mmap_min_addr=65536 (штоб не 0 было)
Этот универсальный эксплоит теперь умеет ломиться не только через пульсаудио, но и через bluetooth инфраструктуру :) Но смысл не в этом, латать багу в ядре будут или нет?
sudo sysctl vm.mmap_min_addr=65536
Это воркэраунд всетаки...
>Этот универсальный эксплоит теперь умеет ломиться не только через пульсаудио, но и через bluetooth инфраструктуру :) Но смысл не в этом, латать багу в ядре будут или нет?вот даже и не знаю! :-D
у меня сей универсальный продукт выдаёт:
mmap: Permission denied
ведро от 16 августа. что обсуждаем сейчас, в сентябре - не понятно.