The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обнаружена локальная root-уязвимость, затрагивающая все Linux-ядра 2.6.x

18.08.2010 20:07

Раскрыта информация об обнаруженной месяц назад ошибке, присутствующей практически во всех Linux-ядрах серии 2.6.x, которая позволяет непривилегированному пользовательскому процессу, который имеет доступ к X-серверу (т.е. любому графическому приложению), безоговорочно получить привилегии суперпользователя, при этом, стоит отметить, что проведение атаки не затрагивает никакие ошибки X-сервера.

Другими словами, любое, имеющие уязвимости, непривилегированное графическое приложение в результате атаки может обойти все механизмы защиты безопасности Linux-ядра и скомпрометировать систему целиком. Атака может быть произведена даже из изолированного окружения системы безопасности SELinux, которая не спасает от данной уязвимости. Например, злоумышленник может воспользоваться уязвимостью в PDF-просмотрщике, запущенном в chroot или под контролем SELinux, и добившись от пользователя открытия специально оформленного документа, получить доступ к машине с правами суперпользователя. Ошибка, судя по всему, существует уже несколько лет практически во всех ядрах серии 2.6.x.

Суть атаки состоит в том, что графическое приложение искусственно практически полностью потребляет адресное пространство X-сервера с помощью расширения MIT-SHM, затем создаёт разделяемый сегмент памяти "S", то есть заставляя X-сервер использовать этот сегмент. Сегмент "S", однако, будет находиться близко над исполняемым стеком. Затем атакующий инструктирует X-сервер с тем, чтобы последний стал исполнять рекурсивную функцию, что приводит к расширению стека, а указатель стека смещается в сторону сегмента "S" на непродолжительный промежуток времени. После чего, атакующий осуществляет запись в область памяти "S", что приводит к замене смещения в стеке и позволяет выполнить произвольный код.

Без обновления ядра данную проблему можно решить несколькими способами. Во-первых, можно выключить поддержку MIT-SHM в X-сервере:



   Section "Extensions"
      Option "MIT-SHM" "disable"
   EndSection

Во-вторых, можно создать wrapper для запуска X-сервера с указанием RLIMIT_AS, что ограничит регион памяти, доступной для X-сервера и поможет избежать атаки. Однако, этот способ не является надёжным.

Данная проблема решена в выпущенных на днях обновлениях Linux-ядра 2.6.32.19, 2.6.34.4, 2.6.35.2, а также устранена в ядре RedHat Enterprise Linux. Примечательно, что данная уязвимость была исправлена молча, без акцентирования о критичности проблемы и без отметки об отношении исправления к безопасности в списке изменений. Более подробно об уязвимости можно прочитать в данном отчете (PDF, 100 Кб).

Дополнение: Оказывается, ещё в 2004 году разработчики из SUSE предложили патч для этой проблемы, но по неизвестным причинам он не был принят в ядро и вскоре про него забыли. SUSE Linux Enterprise 9/10/11 и openSUSE 11.1-11.3 не подвержены данной проблеме.

  1. Главная ссылка к новости (http://theinvisiblethings.blog...)
  2. OpenNews: Планы Ubuntu по выполнению X.Org с пониженными привилегиями
  3. OpenNews: Moblin 2.0 не будет использовать root привилегии для запуске X-сервера
  4. OpenNews: X-сервер скоро будет избавлен от кода, работающего с правами суперпользователя
  5. OpenNews: X-сервер научили работать без root-привилегий
Автор новости: Artem S. Tashkinov
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27658-security
Ключевые слова: security, Xorg
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (89) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, alexanderyt (??), 20:56, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Патч вроде для всех ванильных 2.6.х?
     
  • 1.11, аноним (?), 21:44, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    запуск иксов не из под рута назрел. и уже давно.
     
     
  • 2.30, goof.gooffy (ok), 00:01, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >запуск иксов не из под рута назрел. и уже давно.

    года два назад слыхал, что хотят сделать. Как оно сейчас?

     
     
  • 3.31, аноним (?), 00:11, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по прежнему. хотят сделать.
    при чем с опенсорсными дровами особо проблем не намечается, а вот с проприетарными не известно. нвидиа, да и амд, молчат.
     
     
  • 4.43, Zenitur (?), 03:52, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сделали. Вручную осуществить можно. Об этом была новость.
     
     
  • 5.53, аноним (?), 08:56, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это пока не назовешь словом "делали".
    попробуйте. особенно с проприетарной нвидиа.
     
     
  • 6.54, аноним (?), 09:06, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    /делали/сделали/
     
  • 6.57, mma (?), 09:46, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну так это проблемы нвидии что она драйвер под KMS  не переделывает, с открытыми дровами под KMS  нет никакой проблемы для запуска иксов без рута
     

  • 1.12, аноним (?), 21:46, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >устранена в ядре RedHat Enterprise Linux

    Это mrg-шное 2.6.24.

    В их родном 2.6.18, похоже, такая атака невозможна в принципе - оно напичкано патчами, обеспечивающими безопасное использование памяти.

     
     
  • 2.103, аноним (?), 06:06, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >В их родном 2.6.18, похоже, такая атака невозможна в принципе - оно
    >напичкано патчами, обеспечивающими безопасное использование памяти.

    А теперь расскажите, почему этих патчей не в ванилле.


     
     
  • 3.112, аноним (?), 11:45, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а это чево?
    >Данная проблема решена в выпущенных на днях обновлениях Linux-ядра 2.6.32.19, 2.6.34.4, 2.6.35.2

    у?

     
  • 3.114, konwin (ok), 12:53, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Спросите у авторов ванили.
     

  • 1.14, Аноним (-), 21:53, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +25 +/
    почему то возникла мысль что "данном отчет (PDF, 100 Кб)" как раз и есть "специально оформленный документ" )
     
  • 1.17, Анонима (?), 22:23, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Жесть. Вот как такие уязвимости находят? Случайность? Специальный анализ кода? - какого же уровня должен быть профессионализм у аудитора...
     
     
  • 2.18, Vitaly_loki (ok), 22:27, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну наверно такой же, как и у системщика, к-й пишет ядро :)
     
     
  • 3.20, Aesthetus Animus (ok), 22:30, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще, должен быть выше.
     
  • 3.26, Гость (?), 23:12, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Выше на порядок
     
     
  • 4.32, аноним (?), 00:14, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не особо.
    знание архитектуры и стресс-тесты. рекурсию на начальных курсах проходят.
    муторная и не творческая работа для большинства. вот и мало таких.
     
  • 2.19, Иван Иванович Иванов (?), 22:29, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Они что-то новое пишут (Qubes OS: qubes-os.org), неломаемое - стали аудит кода проводить, наткнулись на ошибку.
     
  • 2.35, User294 (ok), 02:36, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > какого же уровня должен быть профессионализм у аудитора..

    Для этого должен быть некий талант и довольно креативное мышление в контексте "а как бы этой программе потехничнее подгадить?"

     
  • 2.80, iZEN (ok), 16:20, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > какого же уровня должен быть профессионализм у аудитора...

    Вспомнилось: "Тролль восьмидесятого уровня".

     

  • 1.21, Anixx (?), 22:37, 18/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –26 +/
    Больше на Си программируйте, еще не такое будет...
     
     
  • 2.22, тигар (ok), 22:44, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +14 +/
    правильно, ядро линукса нужно писать на java\.NET. неистово плюсую
     
     
  • 3.23, Anixx (?), 22:52, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • –24 +/
    Ядро надо писать на любом языке без арифметики над указателями.
     
     
  • 4.24, Иван Иванович Иванов (?), 23:01, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как это спасёт от переполнения буфера ? Или всё безразмерно, безтипизированно сделать? Только вот тогда оно будет работать как черепаха.
     
     
  • 5.34, yantux (??), 01:47, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –6 +/
    попробуйте сделать переполнение буфера на паскале
     
     
  • 6.49, pazke (?), 07:44, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    попробуйте написать на паскале ядро ОС.

     
     
  • 7.52, Гость (?), 08:50, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А про Oberon вы не слышали?
     
     
  • 8.65, fr0ster (ok), 11:45, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Слышали, все больше и царство ему небесное ... текст свёрнут, показать
     
  • 7.72, Alek Aaz (?), 14:34, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ОС на паскале -> http://stimul.freepascal.ru/
     
  • 6.117, Frank (??), 14:34, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Проги, юзавшие модуль CRT, падали сами, без вмешательства юзера, на машинах быстрее 200-го пентюха... Помните?
     
     
  • 7.118, fr0ster (ok), 14:43, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Проги, юзавшие модуль CRT, падали сами, без вмешательства юзера, на машинах быстрее
    >200-го пентюха... Помните?

    Все же это несколько не то. Выполнить левый код это вроде не позволяло. Или я не прав?

     
  • 4.25, Michael Shigorin (ok), 23:08, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Пишите.  Будет готово, зовите к раздаче.
     
  • 4.27, аноним (?), 23:14, 18/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Без арифметики над указателями - это уже не языки.
     
     
  • 5.29, аноним (?), 00:00, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +8 +/
    дык и они не програмисты. нашли с кем спорить.
     
  • 5.74, Knuckles (ok), 14:46, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    супертолсто
     
     
  • 6.104, аноним (?), 06:07, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >супертолсто

    здесь ещё добавки попросят

     
     
  • 7.113, аноним (?), 11:48, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а нехрена тут писать "как это здорово писать вёдра на жабах и дотнетах" и "забудьте свой С".
    тусуйтесь где пользуются "вёдра на жабах и дотнетах"
     
     
  • 8.119, Knuckles (ok), 16:31, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У нас тут вроде как ИТ-форум, а не кружок фанатиков портабельных ассемблеров ... текст свёрнут, показать
     
     
  • 9.120, fr0ster (ok), 16:33, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Разницы нет, польза одинакова ... текст свёрнут, показать
     
  • 2.36, User294 (ok), 02:40, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Больше на Си программируйте, еще не такое будет...

    Ой. А вон в вебе - нет никаких указателей как правило. И что, ломать перестали? Ну да, щаз. Появилось еще 100500 новых видов багов. А хаксоры как имели всех так и дальше имеют. Плевав на отсутствие указателей почему-то. В общем сказки про то что все зло от указателей - несколько утомили, поскольку лажа (в том числе и эпичного масштаба) бывает и без них.

     
     
  • 3.47, Аноним (-), 05:53, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Веб ломают совершенно другими способами, которые не имеют никакого отношения к х... большой текст свёрнут, показать
     
     
  • 4.66, Аноним (-), 11:49, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Что касается ОС, то я ни на секунду не сомневаюсь, что время
    >ОС, подобных MS Singularity, неизбежно наступит. Хотите верьте, а хотите нет
    >;)

    Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно медленно... ибо костыли на костылях и костылями подпирают

     
     
  • 5.76, Аноним (-), 15:46, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно
    >медленно... ибо костыли на костылях и костылями подпирают

    Просто время таких вещей еще не пришло. Если Вы хорошо знакомы с историей вычислительной техники, то знаете, что такое там встречается сплошь и рядом. Насчет костылей - полная чушь, как раз наоборот, там все очень грамотно и четко организовано. Но производительность ПОКА оставляет желать лучшего.


     
     
  • 6.78, fr0ster (ok), 15:49, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Может и наступит, но работают всякие эти Сингулярити и им подобное безбожно
    >>медленно... ибо костыли на костылях и костылями подпирают
    >
    >Просто время таких вещей еще не пришло. Если Вы хорошо знакомы с

    Очень вероятно что время сингулярности и не придет, так как когда раскачается железо, начинают задумываться об экономии того же лепестричества.

    >историей вычислительной техники, то знаете, что такое там встречается сплошь и
    >рядом. Насчет костылей - полная чушь, как раз наоборот, там все
    >очень грамотно и четко организовано. Но производительность ПОКА оставляет желать лучшего.
    >

    Принцип Оккама уже отменили?

     
     
  • 7.84, Аноним (-), 18:43, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Очень вероятно что время сингулярности и не придет, так как когда раскачается железо, начинают задумываться об экономии того же лепестричества.

    Новые поколения процессоров с каждым годом все более и более производительны и все менее и менее прожорливы. Более того, не исключены и серьезные архитектурые изменения, в том числе - нацеленные на исполнение такого вот кода. Конторам, которые обрабатывают гигантские массивы важных данных, таки не жалко электричество для запуска ораклов и джав. Потому что надежность важнее.

    >Принцип Оккама уже отменили?

    Не нужно делать Оккама затычкой в каждой бочке.

     
     
  • 8.92, fr0ster (??), 21:13, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Что то на Марсе яблони так и не зацвели Есть гораздо более простые способы дост... текст свёрнут, показать
     
     
  • 9.99, Michael Shigorin (ok), 23:54, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это бы исключило экономику по крайней мере в текущем понимании ... текст свёрнут, показать
     
  • 9.102, Аноним (-), 05:20, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Оставьте метафоры и глупые аналогии для User294 Если Вы не видите устойчивых те... текст свёрнут, показать
     
     
  • 10.105, аноним (?), 06:09, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Пять процентов или сколько там ... текст свёрнут, показать
     
  • 10.109, fr0ster (ok), 08:43, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы оглянитесь, посмотрите что из большинства тенденций обычно выходит Хотя несп... большой текст свёрнут, показать
     
  • 4.94, User294 (ok), 21:48, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да ну А как же code injection или sql injection Попробуйте сделать SQL injecti... большой текст свёрнут, показать
     

  • 1.33, sashka_ua (?), 00:52, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не очень понятно почему пишется что это уязвимость ядра? Ведь уязвимость можно в данном контексте реализовать лишь с помощью запушенных X и графического приложения приложения.

    А патч, что написал Линус, решает проблему для приложений которые не умеют нормально управлять выделенной памятью.

     
     
  • 2.37, Аноним (-), 02:45, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ядро это позволяет.
     
  • 2.39, User294 (ok), 03:10, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Не очень понятно почему пишется что это уязвимость ядра?

    Потому что по идее в такой ситуации прога (иксы) должна бы быть убита с чем-то типа segmentation fault т.к. имела место быть невалидная ситуация: стек пересекся с посторонней областью памяти и был перезаписан. Так что при желании можно объявить уязвимостью, т.к. оно позволяет непривилегированному процессу за счет совместной лажи ядра и привилегированного процесса хряпнуть полные привилегии. Кстати фанатам SELinux очередной превед, ага.

     
     
  • 3.75, Knuckles (ok), 14:49, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати фанатам SELinux очередной превед, ага.

    Не радуйся, любимые тобой песочницы тоже не спасают.

     
     
  • 4.93, User294 (ok), 21:39, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сильно зависит от типа песочниц. Какомунить XEN дыры ядра линуха вообще до фени. Для остальных - it depends. В частности хотелось бы какие-то пруфлинки/примеры/whatever для:
    - KVM?
    - LXC?
    - OpenVZ?

    Чтобы пробивалась именно межконтейнерная изоляция.

     
     
  • 5.100, Michael Shigorin (ok), 23:58, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >- KVM?

    Сходу не припомню, AFAIR бывало, да и в этом разборе полётов намекают, что kvm не поможет.

    >- LXC?
    >- OpenVZ?

    Практически любой local kernel, который не спотыкается на их особенностях (в OpenVZ их добавляется достаточно много, т.к. команда занимается активным аудитом).

    >Чтобы пробивалась именно межконтейнерная изоляция.

    Это ещё не самое плохое.  Хуже, когда до HN.

     
  • 5.106, Аноним (-), 07:32, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати - тут вспоминалась атака через Vmware - когда через дырку взаимодействия с гипервизором ломали host.
    вы готовы дать гарантию что ошибок такого рода нету в kvm & lxc?

    а OpenVZ вобще ломается через любую дырку в ядре которая local root дает.. коих уже был вагон.

     
  • 3.83, i (??), 17:32, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что по идее в такой ситуации прога (иксы) должна бы быть убита с чем-то типа segmentation fault

    думаю с grsec & pax патчами так и будет.
    Есть у кого hardened-gentoo с X? как там эта уязвимость, работает?

     
     
  • 4.87, Аноним (-), 20:12, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не будет она убита. _НЕБУДЕТ_

    процессу тупо дадут расширить vma описывающую стек в область _физических_ адресов где находится data.
    а дальше привет семье.

     
     
  • 5.107, i (??), 08:36, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы проверяли? или предполагаете?
    Если выпустят рабочий эксплоит, обязательно проверю.
     
     
  • 6.121, Аноним (-), 17:14, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    прочитайте мои коментарии выше о роде бага.

    NX-bit ставится только на физические странички, тут же позволили логической структуре перемешать свои размеры таким образом что она стала указывать на чужие физические страницы.
    а убрать execute bit со стека не возможно (привет gcc и его трамплинам).

     
  • 2.41, XoRe (ok), 03:14, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Не очень понятно почему пишется что это уязвимость ядра? Ведь уязвимость можно
    >в данном контексте реализовать лишь с помощью запушенных X и графического
    >приложения приложения.

    Вообще да.
    Дырка у X-сервера (запущенного из-под рута).
    Отключается строчкой в конфиге X-сервера.
    А пишут об уязвимости ядра.


     
     
  • 3.60, Аноним (-), 10:21, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А пишут об уязвимости ядра.

    По вашему ситуация когда непривилегированный процесс может переписать область памяти другого привилегированного процесса - это не уязвимость ???

     
  • 3.64, Иван Иванович Иванов (?), 11:41, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Эта дыра в ядре. Точка.

    Почитайте PDF'ку.

    С помощью этой дыры можно потенциально взломать любой процесс, который принимает пользовательские данные. Например, в многопользовательской системе Алиса может заставить процесс Васи segfault'нуться или начать делать у Васи что хочет Алиса.

    Не знаете - молчите, за умного сойдёте.

     
  • 2.48, Аноним (-), 07:37, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ядро не должно выделять разные VMA области с пересекающимися границами.
    Даже и если это разный тип объектов.
    При корректном поведении ядра - на попытку приложения раздвинуть границы - ему обязаны вернуть ошибку, а тут ядро тупо говорит "да не вопрос"..

    Вот тебе батенька и качество написания ядра :) когда ошибка в одной из самых важных подсистем была не исправлена годами..

     
     
  • 3.55, Иван Иванович Иванов (?), 09:25, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще, ошибка найдена достаточно страшная, а имела она место быть ибо ядро считает VIRT неразмеченной памятью (по сути это так, а по факту в эту область и наср*ли) - хотя может я не совсем правильно всё понял.
     
     
  • 4.90, Аноним (-), 20:19, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Там все смешнее в linux kernel есть VMA - которые описывают в том числе и транс... большой текст свёрнут, показать
     
     
  • 5.110, Иван Иванович Иванов (?), 09:10, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Можно по-подробнее и на правильно русском языке? ;)

    Тяжело читать что вы написали.

     
     
  • 6.111, Аноним (-), 11:10, 20/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Можно по-подробнее и на правильно русском языке? ;)
    >
    >Тяжело читать что вы написали.

    Сори - но пересказывать работу 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.Development.Second.Edi

    а остальное сводиться к тому что некоторые сегменты aka vma - могут изменять свой размер, и не одна сволочь не проверяла их на пересечение с другими.

     
  • 2.42, XoRe (ok), 03:17, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну... дырка-то не серверная.
    Иксы на сервере (да ещё и используемые) стоят только у самых злобных буратинов=)
    А вообще, запостили когда: 18-Авг-10, 20:55 (MSK).
    Утром народ начнет обсуждать - там и посмотрим =)
     
     
  • 3.50, Аноним (-), 07:46, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Ну... дырка-то не серверная.
    >Иксы на сервере (да ещё и используемые) стоят только у самых злобных
    >буратинов=)
    >А вообще, запостили когда: 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.


     
  • 2.81, Michael Shigorin (ok), 16:33, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Не очень понятно почему пишется что это уязвимость ядра?

    Потому что позволяет из heap'а перелезть в stack -- между ними даже зазора не было (его и сделали).

    >Ведь уязвимость можно в данном контексте реализовать лишь с помощью запушенных X
    >и графического приложения приложения.

    Нет, просто это наиболее удобный вектор атаки.

    >А патч, что написал Линус, решает проблему для приложений которые не умеют
    >нормально управлять выделенной памятью.

    Когда не уверены, лучше поставить вопросительный знак или хоть "IMHO"...

    PS: я пока добавил гигабайтный лимит на адресное пространство в /etc/security/limits.conf в явном виде -- см. тж. getrlimit(2) и limits.conf(5), также нужен релогин:
    *    hard as 1024000

    Для i586 Джоанна советовала ограничить максимум 1200Mb, для x86_64 можно помножить на несколько.

     
     
  • 3.97, Аноним (-), 22:30, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/

    >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М :)

     
     
  • 4.101, Michael Shigorin (ok), 23:59, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А ничего что той же джаве надо значительно больше 1G address space? ;-)

    Вот и проверим разве что на jviewer ;-)

     

  • 1.44, Дмитрий (??), 04:42, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как быть с PaX ?

    цитата:
    Многие (но конечно далеко не все) ошибки разработчиков приводят к неправильному обращению их программ к памяти. Это предоставляет гипотетическую возможность заставить программу выполнять то, что она не должна делать по замыслу (например выдавать привилегированный шелл). Цель PaX — не нахождение и исправление подобных уязвимостей, а, скорее, предотвращение их использования атакующими приложениями. Последствия ошибок будут сведены к минимуму — выполнение программы будет попросту прервано, что с точки зрения PaX лучше, чем её скомпрометированный функционал.

    http://ru.wikipedia.org/wiki/PaX

     
     
  • 2.51, Аноним (-), 07:47, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален А что PaX данный механизм не защищает от того что о... большой текст свёрнут, показать
     
  • 2.82, Michael Shigorin (ok), 16:38, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А как быть с PaX ?

    А это почитайте концептуальные эээ... разборки с Брэдом в блоге по ссылке.  Стороны отличились в выпячивании своих подходов и забрасывании взаимных альтернатив.

     

  • 1.56, mma (?), 09:43, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То-то я думал, что это 2.6.35.2 следом так быстро вышло и changelog был мизерный, а тут вот оно что...
     
  • 1.67, oops (??), 12:51, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А расскажите неграмотному, плз, эту дыру можно закрыть каким-нибудь патчем (и если да, то как узнать для каких дистр. он уже вышел) или же нужно будет пересобирать новое ядро?
     
     
  • 2.85, Zenitur (?), 19:16, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На сайте linux.org.ru в такой же новости есть ссылка на патч. Если он не наложится, открой файлы, на которые накладывается патч, любимым текстовым редактором, и найди нужные строчки вручную. Затем make oldconfig; make all modules_install install - если ты манипулируешь с ядром дистрибутива.
     
     
  • 3.88, Аноним (-), 20:13, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >На сайте linux.org.ru в такой же новости есть ссылка на патч. Если
    >он не наложится, открой файлы, на которые накладывается патч, любимым текстовым
    >редактором, и найди нужные строчки вручную. Затем make oldconfig; make all
    >modules_install install - если ты манипулируешь с ядром дистрибутива.

    Все бы хорошо - но лучше сходить в багзилу RedHat и увидеть что там надо порядка 6 патчей наложить,
    и тот патч что налабал на коленке Линукс в конечном итоге выкинули и заменили более правильным решением.

     
  • 3.89, Иван Иванович Иванов (?), 20:14, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Надо же и тут есть ссылка на патч.

    Вы не подумали, что на ЛОРе новость опять перепечатали? Я умиляюсь.

     

  • 1.70, drurus (?), 14:00, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Читаем последний абзац со слова "Примечательно".
    мдя...
     
     
  • 2.71, oops (??), 14:05, 19/08/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а для других ядер?
    у меня, например, пока 2.6.31 стоит и древнее
     

  • 1.98, Аноним (-), 22:39, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    судя по коментариям с 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.
    >>>

    Кому-то такую клевую лавочку прикрыли..

     
  • 1.108, i (??), 08:39, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    рабочий эксплойт есть?
     
  • 1.123, nuclight (ok), 22:46, 28/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шедеврально. Линукс до сих пор допускает такие детские ляпы в архитектуре VM. И отношение к безопасности феерическое - закрыли молча и без пометки. Мдаа. *BSD себе такой халтуры не позволяет, ни там, ни там.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру