Раскрыта информация (http://theinvisiblethings.blogspot.com/2010/08/skeletons-hid...) об обнаруженной месяц назад ошибке, присутствующей практически во всех Linux-ядрах серии 2.6.x, которая позволяет (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240) непривилегированному пользовательскому процессу, который имеет доступ к X-серверу (т.е. любому графическому приложению), безоговорочно получить привилегии суперпользователя, при этом, стоит отметить, что проведение атаки не затрагивает никакие ошибки X-сервера.
Другими словами, любое, имеющие уязвимости, непривилегированное графическое приложение в результате атаки может обойти все механизмы защиты безопасности Linux-ядра и скомпрометировать систему целиком. Атака может быть произведена даже из изолированного окружения системы безопасности SELinux. Например, злоумышленник может воспользоваться уязвимостью в PDF-просмотрщике, запущенном в chroot или под контролем SELinux, и добившись от пользователя открыти...URL: http://theinvisiblethings.blogspot.com/2010/08/skeletons-hid...
Новость: http://www.opennet.ru/opennews/art.shtml?num=27658
Патч вроде для всех ванильных 2.6.х?
запуск иксов не из под рута назрел. и уже давно.
>запуск иксов не из под рута назрел. и уже давно.года два назад слыхал, что хотят сделать. Как оно сейчас?
по прежнему. хотят сделать.
при чем с опенсорсными дровами особо проблем не намечается, а вот с проприетарными не известно. нвидиа, да и амд, молчат.
Сделали. Вручную осуществить можно. Об этом была новость.
это пока не назовешь словом "делали".
попробуйте. особенно с проприетарной нвидиа.
/делали/сделали/
ну так это проблемы нвидии что она драйвер под KMS не переделывает, с открытыми дровами под KMS нет никакой проблемы для запуска иксов без рута
>устранена в ядре RedHat Enterprise LinuxЭто mrg-шное 2.6.24.
В их родном 2.6.18, похоже, такая атака невозможна в принципе - оно напичкано патчами, обеспечивающими безопасное использование памяти.
>В их родном 2.6.18, похоже, такая атака невозможна в принципе - оно
>напичкано патчами, обеспечивающими безопасное использование памяти.А теперь расскажите, почему этих патчей не в ванилле.
а это чево?
>Данная проблема решена в выпущенных на днях обновлениях Linux-ядра 2.6.32.19, 2.6.34.4, 2.6.35.2у?
Спросите у авторов ванили.
почему то возникла мысль что "данном отчет (PDF, 100 Кб)" как раз и есть "специально оформленный документ" )
Жесть. Вот как такие уязвимости находят? Случайность? Специальный анализ кода? - какого же уровня должен быть профессионализм у аудитора...
Ну наверно такой же, как и у системщика, к-й пишет ядро :)
Вообще, должен быть выше.
Выше на порядок
не особо.
знание архитектуры и стресс-тесты. рекурсию на начальных курсах проходят.
муторная и не творческая работа для большинства. вот и мало таких.
Они что-то новое пишут (Qubes OS: qubes-os.org), неломаемое - стали аудит кода проводить, наткнулись на ошибку.
> какого же уровня должен быть профессионализм у аудитора..Для этого должен быть некий талант и довольно креативное мышление в контексте "а как бы этой программе потехничнее подгадить?"
> какого же уровня должен быть профессионализм у аудитора...Вспомнилось: "Тролль восьмидесятого уровня".
Больше на Си программируйте, еще не такое будет...
правильно, ядро линукса нужно писать на java\.NET. неистово плюсую
Ядро надо писать на любом языке без арифметики над указателями.
Как это спасёт от переполнения буфера ? Или всё безразмерно, безтипизированно сделать? Только вот тогда оно будет работать как черепаха.
попробуйте сделать переполнение буфера на паскале
попробуйте написать на паскале ядро ОС.
А про Oberon вы не слышали?
Слышали, все больше "и царство ему небесное".
ОС на паскале -> http://stimul.freepascal.ru/
Проги, юзавшие модуль CRT, падали сами, без вмешательства юзера, на машинах быстрее 200-го пентюха... Помните?
>Проги, юзавшие модуль CRT, падали сами, без вмешательства юзера, на машинах быстрее
>200-го пентюха... Помните?Все же это несколько не то. Выполнить левый код это вроде не позволяло. Или я не прав?
Пишите. Будет готово, зовите к раздаче.
Без арифметики над указателями - это уже не языки.
дык и они не програмисты. нашли с кем спорить.
супертолсто
>супертолстоздесь ещё добавки попросят
а нехрена тут писать "как это здорово писать вёдра на жабах и дотнетах" и "забудьте свой С".
тусуйтесь где пользуются "вёдра на жабах и дотнетах"
>а нехрена тут писать...У нас тут вроде как ИТ-форум, а не кружок фанатиков портабельных ассемблеров.
>>а нехрена тут писать...
>
>У нас тут вроде как ИТ-форум, а не кружок фанатиков портабельных ассемблеров.
>Разницы нет, польза одинакова. :)
>Больше на Си программируйте, еще не такое будет...Ой. А вон в вебе - нет никаких указателей как правило. И что, ломать перестали? Ну да, щаз. Появилось еще 100500 новых видов багов. А хаксоры как имели всех так и дальше имеют. Плевав на отсутствие указателей почему-то. В общем сказки про то что все зло от указателей - несколько утомили, поскольку лажа (в том числе и эпичного масштаба) бывает и без них.
>Ой. А вон в вебе - нет никаких указателей как правило.И что, ломать перестали? Ну да, щазВеб ломают совершенно другими способами, которые не имеют никакого отношения к характеру и типам языков программирования. Ломают сейчас не веб-сервер, ломают сейчас скрипты и другую логику. Взлом там не затрагивает обычно веб-сервер (за редким исключением). Например, разработчик не обрабатывает данные из формы или запроса, прошляпил где-то SQL-injection, или допустил возможность проведения XSS, ну и в таком духе. Это все вещи довольно высокоуровневые, и до взломов с переполнениями буфера и шелл-кодами сейчас уже обычно не доходит. Но в свое время Cи-шная природа апача и IIS дала хацкерам много раздолья. Поэтому аргумент с современным вебом явно мимо кассы.
> В общем сказки про то что все зло от указателей - несколько утомили, поскольку лажа (в том числе и эпичного масштаба) бывает и без них.
Ну, не всё, конечно, но довольно много... Большинство удаленных эксплоитов на сетевые службы используют именно некорректную обработку буферов, их размеров, переполнение и т.д. И как показывает практика, каким бы не был опытным программист, рано или поздно он такой "подарочек" оставит, человек ведь не машина:)
Что касается ОС, то я ни на секунду не сомневаюсь, что время ОС, подобных MS Singularity, неизбежно наступит. Хотите верьте, а хотите нет ;)
>Что касается ОС, то я ни на секунду не сомневаюсь, что время
>ОС, подобных MS Singularity, неизбежно наступит. Хотите верьте, а хотите нет
>;)Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно медленно... ибо костыли на костылях и костылями подпирают
>Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно
>медленно... ибо костыли на костылях и костылями подпираютПросто время таких вещей еще не пришло. Если Вы хорошо знакомы с историей вычислительной техники, то знаете, что такое там встречается сплошь и рядом. Насчет костылей - полная чушь, как раз наоборот, там все очень грамотно и четко организовано. Но производительность ПОКА оставляет желать лучшего.
>>Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно
>>медленно... ибо костыли на костылях и костылями подпирают
>
>Просто время таких вещей еще не пришло. Если Вы хорошо знакомы сОчень вероятно что время сингулярности и не придет, так как когда раскачается железо, начинают задумываться об экономии того же лепестричества.
>историей вычислительной техники, то знаете, что такое там встречается сплошь и
>рядом. Насчет костылей - полная чушь, как раз наоборот, там все
>очень грамотно и четко организовано. Но производительность ПОКА оставляет желать лучшего.
>Принцип Оккама уже отменили?
>Очень вероятно что время сингулярности и не придет, так как когда раскачается железо, начинают задумываться об экономии того же лепестричества.Новые поколения процессоров с каждым годом все более и более производительны и все менее и менее прожорливы. Более того, не исключены и серьезные архитектурые изменения, в том числе - нацеленные на исполнение такого вот кода. Конторам, которые обрабатывают гигантские массивы важных данных, таки не жалко электричество для запуска ораклов и джав. Потому что надежность важнее.
>Принцип Оккама уже отменили?
Не нужно делать Оккама затычкой в каждой бочке.
>Новые поколения процессоров с каждым годом все более и более производительны и
>все менее и менее прожорливы. Более того, не исключены и серьезные
>архитектурые изменения, в том числе - нацеленные на исполнение такого вот
>кода. Конторам, которые обрабатывают гигантские массивы важных данных, таки не жалко
>электричество для запуска ораклов и джав. Потому что надежность важнее.Что то на Марсе яблони так и не зацвели. Есть гораздо более простые способы достижения надежности.
>>Принцип Оккама уже отменили?
>
>Не нужно делать Оккама затычкой в каждой бочке.А зря. В экономике первейший принцип. Все чего можно достичь более простым способом так и следует достигать.
>>Не нужно делать Оккама затычкой в каждой бочке.
>А зря. В экономике первейший принцип. Все чего можно достичь более простым
>способом так и следует достигать.Это бы исключило экономику (по крайней мере в текущем понимании).
>Что то на Марсе яблони так и не зацвели. Есть гораздо более простые способы достижения надежности.Оставьте метафоры и глупые аналогии для User294. Если Вы не видите устойчивых тенденций на рынке вычислительной техники, то это лично Ваша проблема.
>А зря. В экономике первейший принцип. Все чего можно достичь более простым способом так и следует достигать.Расскажите это Google с его андроидом. Если тупо следовать принципу Оккама, то андроид вообще не должен был никогда появиться и уж тем более не должен был захвать такую долю рынка.
>захвать такую долю рынкаПять процентов (или сколько там)?
>>Что то на Марсе яблони так и не зацвели. Есть гораздо более простые способы достижения надежности.
>
>Оставьте метафоры и глупые аналогии для User294. Если Вы не видите устойчивых
>тенденций на рынке вычислительной техники, то это лично Ваша проблема.Вы оглянитесь, посмотрите что из большинства тенденций обычно выходит.
Хотя неспособность видеть дальше собственного носа это ваша проблема.
Вперед, к победе гуглизма-андродизма :)>>А зря. В экономике первейший принцип. Все чего можно достичь более простым способом так и следует достигать.
>
>Расскажите это Google с его андроидом. Если тупо следовать принципу Оккама, то
>андроид вообще не должен был никогда появиться и уж тем более
>не должен был захвать такую долю рынка.Вот когда в магазине будет выбор фонов с гуглдроидом, тогда и расказывайте про долю рынка.
А то пока рынок захватили китайцы с поделиями на гуглодроиде 1.6. Приличного особо не вижу, чтобы использовать смартфон вообще. Мне, знаете ли, ехать, а не шашечки.
>Веб ломают совершенно другими способами, которые не имеют никакого
>отношения к характеру и типам языков программирования.Да ну? А как же code injection или sql injection? Попробуйте сделать SQL injection в базу вида key-value? :P Или php injection - в перл? :D Никакого отношения к языкам, говорите? :)
>Ломают сейчас не веб-сервер, ломают сейчас скрипты и другую логику.
А они, простите, не на языке программирования ли случайно написаны? :)
>Взлом там не затрагивает обычно веб-сервер (за редким исключением).
А это уж как повезет, случаи бывают разные.
>Например, разработчик не обрабатывает данные из формы или запроса, прошляпил
>где-то SQL-injection, или допустил возможность проведения XSS, ну и в таком духе.И что? Да, дыры стали иные. Но не пропали. :)
>Это все вещи довольно высокоуровневые, и до взломов с переполнениями
>буфера и шелл-кодами сейчас уже обычно не доходит.Сильное утешение, ага. Особенно если вам одной левой дропнут баз на ...цать гигз например.
>Но в свое время Cи-шная природа апача и IIS дала хацкерам много раздолья. Поэтому
>аргумент с современным вебом явно мимо кассы.Нет не мимо. Скажите, а какая мне как админу разница какая именно дырка, если результат одинаков - меня поимели и у меня геморрой. Объем гемора может меняться, да. Однако очень приличный гемор можно устроить и без кода. Еще вопрос что лучше для админов - угон всех аккаунтов вконтакта или какой-то там шеллкод. Систему можно переставить. А вот "переставить" миллионы угнанных аккаунтов может быть и немного опаньки.
>И как показывает практика, каким бы не был опытным программист, рано
>или поздно он такой "подарочек" оставит, человек ведь не машина:)Это и к вебу применимо.
>Что касается ОС, то я ни на секунду не сомневаюсь, что время
>ОС, подобных MS Singularity, неизбежно наступит.А может оно уже наступило, только в другом виде? Ну там гипервизоры, контейнеры, виртуальные машины, ... ? :) Кстати до того как уповать на манагед код - посмотрите сколько багов в дотнетах и явах находят :).Лично мне кажется что реальнее проаудитить мелкий гипервизор чем эти переростки. А оси типа сингулярити будут иметь уйму своих проблем. Вон нам пришествие микроядер еще с времен дебатов торвальдса и таненбаума обещают. А реально как максимум полумеры ака гибриды. Ну вон в нтях ядро - 6 мегов, реализует почти все что есть в винапи. Какое оно там нахрен микро такое?
>Хотите верьте, а хотите нет ;)
Время покажет.
Не очень понятно почему пишется что это уязвимость ядра? Ведь уязвимость можно в данном контексте реализовать лишь с помощью запушенных X и графического приложения приложения.А патч, что написал Линус, решает проблему для приложений которые не умеют нормально управлять выделенной памятью.
ядро это позволяет.
>Не очень понятно почему пишется что это уязвимость ядра?Потому что по идее в такой ситуации прога (иксы) должна бы быть убита с чем-то типа segmentation fault т.к. имела место быть невалидная ситуация: стек пересекся с посторонней областью памяти и был перезаписан. Так что при желании можно объявить уязвимостью, т.к. оно позволяет непривилегированному процессу за счет совместной лажи ядра и привилегированного процесса хряпнуть полные привилегии. Кстати фанатам SELinux очередной превед, ага.
>Кстати фанатам SELinux очередной превед, ага.Не радуйся, любимые тобой песочницы тоже не спасают.
Сильно зависит от типа песочниц. Какомунить XEN дыры ядра линуха вообще до фени. Для остальных - it depends. В частности хотелось бы какие-то пруфлинки/примеры/whatever для:
- KVM?
- LXC?
- OpenVZ?Чтобы пробивалась именно межконтейнерная изоляция.
>- KVM?Сходу не припомню, AFAIR бывало, да и в этом разборе полётов намекают, что kvm не поможет.
>- LXC?
>- OpenVZ?Практически любой local kernel, который не спотыкается на их особенностях (в OpenVZ их добавляется достаточно много, т.к. команда занимается активным аудитом).
>Чтобы пробивалась именно межконтейнерная изоляция.
Это ещё не самое плохое. Хуже, когда до HN.
Кстати - тут вспоминалась атака через Vmware - когда через дырку взаимодействия с гипервизором ломали host.
вы готовы дать гарантию что ошибок такого рода нету в kvm & lxc?а OpenVZ вобще ломается через любую дырку в ядре которая local root дает.. коих уже был вагон.
> Потому что по идее в такой ситуации прога (иксы) должна бы быть убита с чем-то типа segmentation faultдумаю с grsec & pax патчами так и будет.
Есть у кого hardened-gentoo с X? как там эта уязвимость, работает?
Не будет она убита. _НЕБУДЕТ_процессу тупо дадут расширить vma описывающую стек в область _физических_ адресов где находится data.
а дальше привет семье.
Вы проверяли? или предполагаете?
Если выпустят рабочий эксплоит, обязательно проверю.
прочитайте мои коментарии выше о роде бага.NX-bit ставится только на физические странички, тут же позволили логической структуре перемешать свои размеры таким образом что она стала указывать на чужие физические страницы.
а убрать execute bit со стека не возможно (привет gcc и его трамплинам).
>Не очень понятно почему пишется что это уязвимость ядра? Ведь уязвимость можно
>в данном контексте реализовать лишь с помощью запушенных X и графического
>приложения приложения.Вообще да.
Дырка у X-сервера (запущенного из-под рута).
Отключается строчкой в конфиге X-сервера.
А пишут об уязвимости ядра.
>А пишут об уязвимости ядра.По вашему ситуация когда непривилегированный процесс может переписать область памяти другого привилегированного процесса - это не уязвимость ???
Эта дыра в ядре. Точка.Почитайте PDF'ку.
С помощью этой дыры можно потенциально взломать любой процесс, который принимает пользовательские данные. Например, в многопользовательской системе Алиса может заставить процесс Васи segfault'нуться или начать делать у Васи что хочет Алиса.
Не знаете - молчите, за умного сойдёте.
ядро не должно выделять разные VMA области с пересекающимися границами.
Даже и если это разный тип объектов.
При корректном поведении ядра - на попытку приложения раздвинуть границы - ему обязаны вернуть ошибку, а тут ядро тупо говорит "да не вопрос"..Вот тебе батенька и качество написания ядра :) когда ошибка в одной из самых важных подсистем была не исправлена годами..
Вообще, ошибка найдена достаточно страшная, а имела она место быть ибо ядро считает VIRT неразмеченной памятью (по сути это так, а по факту в эту область и наср*ли) - хотя может я не совсем правильно всё понял.
>Вообще, ошибка найдена достаточно страшная, а имела она место быть ибо ядро
>считает VIRT неразмеченной памятью (по сути это так, а по факту
>в эту область и наср*ли) - хотя может я не совсем
>правильно всё понял.Там все смешнее. в linux kernel есть VMA - которые описывают в том числе и трансляцию virt->phys, ну там границы виртуальных пространств и тп - что бы не трахаться с этим на более высоком уровне.
Но так как размер стека приложения мы хотим дергать изначально маленьким (ээээй привет 10k thread project которые начали играться с thread stack) то мы раздвигаем его границы как хотим.
Тот же эфект получается когда sbrk() требует еще памяти приложению
_но_ stack & data - это разные VMA, с разными атрибутами и тп, и не одна сволочь (в 2.4 тоже) не проверяла что эти 2 элемента списка не имеют пересекающиеся границы :)
Так что бага похоже ооочень бородатая и скорее всего есть даже в 2.4.
Можно по-подробнее и на правильно русском языке? ;)Тяжело читать что вы написали.
>Можно по-подробнее и на правильно русском языке? ;)
>
>Тяжело читать что вы написали.Сори - но пересказывать работу linux VM - у мя желания нету.
описание struct vm_area_struct {} aka VMA - можно найти в
http://linuxgazette.net/112/krishnakumar.html
http://www.makelinux.net/ldd3/chp-15-sect-1.shtmlили - наиболее детальное.
http://linux-kernel-prog.net/Novell.Press-Linux.Kernel.Devel...а остальное сводиться к тому что некоторые сегменты aka vma - могут изменять свой размер, и не одна сволочь не проверяла их на пересечение с другими.
Ну... дырка-то не серверная.
Иксы на сервере (да ещё и используемые) стоят только у самых злобных буратинов=)
А вообще, запостили когда: 18-Авг-10, 20:55 (MSK).
Утром народ начнет обсуждать - там и посмотрим =)
>Ну... дырка-то не серверная.
>Иксы на сервере (да ещё и используемые) стоят только у самых злобных
>буратинов=)
>А вообще, запостили когда: 18-Авг-10, 20:55 (MSK).
>Утром народ начнет обсуждать - там и посмотрим =)На самом деле дырка и серверная тоже. Просто эксплуатация ее проще всего из под X-ов - ибо они запущены от рута.
Это не в иксах - а в ядре, которое для двух разных VMA (virtual memory area) допускает пересекающиеся границы.
А это черевато не только выполнением кода, но и чтением произвольных участков памяти и тп..
из фикса
+ * This is like a special single-page "expand_downwards()",
+ * except we must first make sure that 'address-PAGE_SIZE'
+ * doesn't hit another vma.
>Не очень понятно почему пишется что это уязвимость ядра?Потому что позволяет из heap'а перелезть в stack -- между ними даже зазора не было (его и сделали).
>Ведь уязвимость можно в данном контексте реализовать лишь с помощью запушенных X
>и графического приложения приложения.Нет, просто это наиболее удобный вектор атаки.
>А патч, что написал Линус, решает проблему для приложений которые не умеют
>нормально управлять выделенной памятью.Когда не уверены, лучше поставить вопросительный знак или хоть "IMHO"...
PS: я пока добавил гигабайтный лимит на адресное пространство в /etc/security/limits.conf в явном виде -- см. тж. getrlimit(2) и limits.conf(5), также нужен релогин:
* hard as 1024000Для i586 Джоанна советовала ограничить максимум 1200Mb, для x86_64 можно помножить на несколько.
>PS: я пока добавил гигабайтный лимит на адресное пространство в /etc/security/limits.conf в
>явном виде -- см. тж. getrlimit(2) и limits.conf(5), также нужен релогин:
>
>* hard as 1024000
>
>Для i586 Джоанна советовала ограничить максимум 1200Mb, для x86_64 можно помножить на
>несколько.RedHat борется что бы все больше адресного пространства было процессу (3/1 & 4/4 split их рук дело)
а тут выясняется что это все зло ;-)
А ничего что той же джаве надо значительно больше 1G address space ? ;-)
хотя реальных страничек она использует дай бог на 64-128М :)
>А ничего что той же джаве надо значительно больше 1G address space? ;-)Вот и проверим разве что на jviewer ;-)
А как быть с PaX ?цитата:
Многие (но конечно далеко не все) ошибки разработчиков приводят к неправильному обращению их программ к памяти. Это предоставляет гипотетическую возможность заставить программу выполнять то, что она не должна делать по замыслу (например выдавать привилегированный шелл). Цель PaX — не нахождение и исправление подобных уязвимостей, а, скорее, предотвращение их использования атакующими приложениями. Последствия ошибок будут сведены к минимуму — выполнение программы будет попросту прервано, что с точки зрения PaX лучше, чем её скомпрометированный функционал.
>[оверквотинг удален]
>цитата:
>Многие (но конечно далеко не все) ошибки разработчиков приводят к неправильному обращению
>их программ к памяти. Это предоставляет гипотетическую возможность заставить программу выполнять
>то, что она не должна делать по замыслу (например выдавать привилегированный
>шелл). Цель PaX — не нахождение и исправление подобных уязвимостей, а,
>скорее, предотвращение их использования атакующими приложениями. Последствия ошибок будут сведены к
>минимуму — выполнение программы будет попросту прервано, что с точки зрения
>PaX лучше, чем её скомпрометированный функционал.
>
>http://ru.wikipedia.org/wiki/PaXА что PaX ? :) данный механизм не защищает от того что один кусок виртуальной памяти окажется в области помеченой как execute :-)
>А как быть с PaX ?А это почитайте концептуальные эээ... разборки с Брэдом в блоге по ссылке. Стороны отличились в выпячивании своих подходов и забрасывании взаимных альтернатив.
То-то я думал, что это 2.6.35.2 следом так быстро вышло и changelog был мизерный, а тут вот оно что...
А расскажите неграмотному, плз, эту дыру можно закрыть каким-нибудь патчем (и если да, то как узнать для каких дистр. он уже вышел) или же нужно будет пересобирать новое ядро?
На сайте linux.org.ru в такой же новости есть ссылка на патч. Если он не наложится, открой файлы, на которые накладывается патч, любимым текстовым редактором, и найди нужные строчки вручную. Затем make oldconfig; make all modules_install install - если ты манипулируешь с ядром дистрибутива.
>На сайте linux.org.ru в такой же новости есть ссылка на патч. Если
>он не наложится, открой файлы, на которые накладывается патч, любимым текстовым
>редактором, и найди нужные строчки вручную. Затем make oldconfig; make all
>modules_install install - если ты манипулируешь с ядром дистрибутива.Все бы хорошо - но лучше сходить в багзилу RedHat и увидеть что там надо порядка 6 патчей наложить,
и тот патч что налабал на коленке Линукс в конечном итоге выкинули и заменили более правильным решением.
Надо же и тут есть ссылка на патч.Вы не подумали, что на ЛОРе новость опять перепечатали? Я умиляюсь.
Читаем последний абзац со слова "Примечательно".
мдя...
а для других ядер?
у меня, например, пока 2.6.31 стоит и древнее
судя по коментариям с LOR бага присуствует не только во всех 2.6 ядрах
но и в 2.4 ;)
Офигеть как долго можно было иметь линух во всех позах ;-)>>
As Marcus Meissner from the SUSE security team explained to heise Security, SUSE maintainer Andrea Arcangeli provided a fix for the problem in September 2004, but for unknown reasons this fix was not included in the Linux kernel. SUSE itself has the fix and SUSE Linux Enterprise 9, 10 and 11 as well as openSUSE 11.1 through 11.3 do not exhibit this vulnerability.
>>>Кому-то такую клевую лавочку прикрыли..
рабочий эксплойт есть?
Шедеврально. Линукс до сих пор допускает такие детские ляпы в архитектуре VM. И отношение к безопасности феерическое - закрыли молча и без пометки. Мдаа. *BSD себе такой халтуры не позволяет, ни там, ни там.