The OpenNET Project / Index page

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

Оценка безопасности различных дистрибутивов Linux

13.09.2010 09:45

Лаборатория компании MWR Infosecurity провела сравнительный анализ дистрибутивов Linux с точки зрения информационной безопасности. Результаты исследования изложены в статьях "Анализ безопасности кода, выполняемого в адресном пространстве пользователя (userspace)" и "Анализ безопасности кода ядра".

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

Различные дистрибутивы по-разному находят компромисс между защищенностью и производительностью/поддержкой кода программного обеспечения. В статье сравнивается пять популярных дистрибутивов актуальных версий: Debian 5.0.4, Fedora 13, OpenSUSE 11.2, Ubuntu 10.04 и Gentoo (не перекомпилированная стабильная Hardened-ветка дистрибутива, Stage 3). По мнению авторов статьи, первые четыре из перечисленных дистрибутивов лидируют по количеству инсталляций, а Hardened-версия Gentoo выбрана как демонстрация дистрибутива, который включает в себя практически все известные методы защиты кода.

Сравнение проводилось в виртуальной среде KVM и с включенным NX-битом (защита от выполнения в сегменте данных) на процессоре Intel в 32-разрядном режиме. Сравнение выполнялось при помощи модифицированного скрипта checksec.sh. В тестах выполнялась проверка процессов в графической (X11) пользовательской сессии, организованной через ssh (в сессии присутствовал sshd) и работающего web-браузара Mozilla Firefox. Стоит отметить, что количество процессов, инициированных графической сессии может существенно отличаться в различных дистрибутивах, например, от 34 в Gentoo до 96 - в сессии Ubuntu.

Выполнялось сравнение следующих методов:

  • RELRO - защищает структуры исполняемого ELF-файла (изменение которых позволяет взломщику изменить ход выполнения программы) путем модификации секций PLT (Procedure Linking Table) или GOT (Global Offset Table) ELF-файла. При полном RELRO, вся таблица GOT перед началом исполнения в памяти помечается доступной только для чтения и таким образом предотвращает свою модификацию потенциальным злоумышленником. Частичный режим RELRO защищает только PLT. Кроме того, оба метода реорганизуют структуры данных ELF таким образом, что упомянутые таблицы помещаются перед остальными структурами данных ELF, что затрудняет для атакующего кода возможность расширения GOT и PLT.

    Так как RELRO требует, чтобы все связи исполняемого кода были разрешены до начала его работы, это может привести к заметному ухудшению производительности при старте программ, которые требуют для работы большого количества разделяемых библиотек (shared libraries).

    Тесты показали, что Debian и Fedora практически не используют RELRO, частичный режим RELRO реализован для всех процессов в SuSE и Ubuntu (для наиболее критичных, как dbus-daemon используется полный RELRO). В Gentoo - напротив для всех процессов реализован полный RELRO, за исключением Xorg-сервера, собранного с частичном RELRO.

  • Stack Smashing Protection (SSP) - защита от разрушения стека, называемая еще канареечной проверкой (канарейки в угольных шахтах в Англии до появления химических анализаторов воздуха использовались как индикаторы метана, до того как смесь становилась взрывоопасной - прим. пер). Эта защита базируется на помещении в стек маленьких меток - случайных чисел, генерируемых при старте программы, которые проверяются при работе со стеком, обычно при завершении работы функции. Вредоносный код переполнения буфера обычно помещается в стек и, таким образом, разрушает метки. Работа механизмов SSP обнаруживает разрушение и аварийно завершает взломанный процесс.

    Тесты показали, что SSP интенсивно используется Fedora, SuSE и Ubuntu - около 80% процессов используют эту защиту, а Debian и Gentoo - почти не используют (10%).

  • FORTIFY_SOURCE - свойство компилятора, который автоматически подменяет незащищенные от переполнения буфера библиотечные функции их защищенным эквивалентом, таким образом пытаясь защитить код от уязвимости, связанной с переполнением стека. Подробнобное описание FORTIFY_SOURCE можно получить здесь и здесь.

    Тесты показали интенсивное использование FORTIFY_SOURCE во всех сравниваемых дистрибутивах, кроме Debian данный метод применяется для порядка 80% процессов, а в Hardened Gentoo - для почти 90%.

  • PIC/PIE (Position Independent Code/Executable) - исполняемый позиционно-независимый код. Возможность предсказания где какие области памяти находятся в адресном пространстве процесса безусловно является подспорьем для взломщика. Несмотря на свойства операционных систем по случайному размещению пользовательского кода в памяти, большинство пользовательских программ продолжают загружаться и выполняться с предопределенного адреса виртуальной памяти процесса, так как не скомпилированы с опцией PIE. Напротив, использование PIE позволяет операционной системе загружать секции исполняемого кода в память произвольным образом, что существенно усложняет взлом. Понятно, что в 64-битных системах эта возможности обеспечивается лучше, чем в 32-битных - благодаря бóльшему по размеру виртуальному адресному пространству процесса.

    В исследуемых инсталляциях Gentoo показал использование PIE для 100% работающих процессов, в то время как в остальных рассматриваемых дистрибутивах процент был много меньше - от 8% в Debian до 21% в SUSE. Из остальных дистрибутивов стоит отметить, что только в Ubuntu, с данной опцией был собран браузер Firefox, который безусловно можно причислить к потенциально часто атакуемым.

Описанные выше методы применимы к процессам, работающим в пользовательском адресном пространстве Linux (userspace), и работа большинства из них невозможна без соответствующей поддержки ядра Linux. Представленное далее сравнение затрагивает только возможности ядра для обеспечения рассмотренных методов защиты пользовательского кода (а иногда относится к аспектам функционирования самого ядра) и не касается механизмов SELinux, Grsecurity RBAC и AppArmor.

Безопасность ядра имеет очень большое значение, так как возможность выполнения даже незначительно вредоностного кода в режиме ядра может сделать бесполезной всю систему безопасности userspace, описанную выше. Тестирование проводилось на тех же дистрибутивах - Debian (версия ядра 2.6.26-2-686), Fedora (2.6.33.6-147.fc13.i686), Gentoo (2.6.32-hardened-r9), OpenSuse (2.6.31.12-0.2-default) и Ubuntu (2.6.32-23-generic). Рассматривались параметры:

  • mmap_min_addr (/proc/sys/vm/mmap_min_addr) - минимальный адрес виртуальной памяти userspace, который может быть назначен пользовательской программе. Может иметь определенный смысл в контексте безопасности, когда код злоумышленника может спровоцировать разыменование NULL-указателя в коде ядра. Минимальным адресом указывается ненулевое значение так как по нулевому адресу может быть помещен предварительно подготовленный исполняемый код, который может быть теоретически выполнен.

    Все тестируемые дистрибутивы устанавливают значение данного параметра в 4096 или 65536. Во втором случае система делает невозможным выполнение программы в первых 64Kb виртуальной памяти. Заметим, что значение 4096 также усложняет доступ к нулевой странице, но не делает его невозможным. Также следует отметить, что не все пользовательские программы работают корректно при невозможности доступа к первым 64Kb виртуальной памяти (напирмер, wine требует установки mmap_min_addr в 0).

  • randomize_va_space (/proc/sys/kernel/randomize_va_space) - указывает на то, какие секции пользовательских программ при старте могут получать случайные адреса: значение 0 отключает эту возможность, "1" - дает возможность случайно распределять адреса для стека, VDSO (Virtual Dynamically-linked Shared Object, linux-gate.so - разделяемой библиотеки предоставляющей таблицу системных вызовов) и адресов для работы вызова mmap(). Значение randomize_va_space также предполагает случайное распределение выполняемых секций пользовательских процессов и разделяемых библиотек, скомпилированных в режиме PIC/PIE. Значение "2", дополнительно к предыдущему выделяет случайный виртуальный адрес для "кучи" (process heap).

    Для всех тестируемых дистрибутивов значение randomize_va_space установлено в "2", однако замечено, что в Debian начальный адрес "кучи" постоянен для всех процессов, т.е поведение системы согласуется с установкой randomize_va_space в "1".

  • paxtest - набор программных средств, разработанное Питером Буссером (Peter Busser) и Брэдом Шпенглером (Brad Spengler) для тестирования различных механизмов защиты памяти. Суть метода в попытке выполнить случайный код различными способами в различных областях памяти с использованием различных техник. Результаты проверки представлены в следующей таблице:
  Debian Fedora Gentoo OpenSuse Ubuntu
Executable anonymous mapping Vulnerable Killed Killed Vulnerable Killed
Executable bss Vulnerable Killed Killed Vulnerable Killed
Executable data Vulnerable Killed Killed Vulnerable Killed
Executable heap Vulnerable Killed Killed Vulnerable Killed
Executable stack Vulnerable Killed Killed Vulnerable Killed
Executable shared library bss Vulnerable Vulnerable Killed Vulnerable Vulnerable
Executable shared library data Vulnerable Vulnerable Killed Vulnerable Vulnerable
Executable anonymous mapping (mprotect) Vulnerable Vulnerable Killed Vulnerable Vulnerable
Executable bss (mprotect) Vulnerable Killed Killed Vulnerable Vulnerable
Executable data (mprotect) Vulnerable Killed Killed Vulnerable Vulnerable
Executable heap (mprotect) Vulnerable Killed Killed Vulnerable Vulnerable
Executable stack (mprotect) Vulnerable Vulnerable Killed Vulnerable Vulnerable
Executable shared library bss (mprotect) Vulnerable Vulnerable Killed Vulnerable Vulnerable
Executable shared library data (mprotect) Vulnerable Vulnerable Killed Vulnerable Vulnerable
Writable text segments Vulnerable Vulnerable Killed Vulnerable Vulnerable
Return to function (strcpy) Vulnerable Vulnerable Vulnerable Vulnerable Vulnerable
Return to function (memcpy) Vulnerable Vulnerable Vulnerable Vulnerable Vulnerable
Return to function (strcpy, PIE) Vulnerable Vulnerable Vulnerable Vulnerable Vulnerable
Return to function (memcpy, PIE) Vulnerable Vulnerable Vulnerable Vulnerable Vulnerable

Как видно из результатов тестов, ядра всех тестируемых дистрибутивов подвержены уязвимостям типа "return-to-function", позволяющим вредоносному коду использовать корректные системные функции в своих целях. Атаки такого типа достаточно сложно отличить от "легального" кода. Лучшая защищенность может быть достигнута с использованием 64-битного адресного пространства, так как согласно данной публикации 32-битное адресное пространство может быть просто просканировано вредоносным кодом для поиска искомого значения данных.

Следует отметить, что кроме Hardened Gentoo с патчем от Grsecurity, ядра других дистрибутивов в большей или меньшей степени подвержены атакам, в частности, Debian и OpenSuSE не предоставляют дополнительной защиты, в соответствии с paxtest. При этом в Fedora и Ubuntu не дают возможности записывать данные в определенные области памяти с последующем выполнением этих данных. Ядро Fedora даже выдержало тесты с сегментами памяти данных, в которые была попытка записи кода с последующим его выполнением. Однако у всех, кроме Hardened Gentoo, ядер сегмент с выполнимым кодом программы (text) оказался доступным для записи. Это делается намеренно, когда код программы или разделяемой библиотеки не является позиционно независимым и может потребоваться его легальное перемещение (загрузчиком, во время выполнения). Другой пример, когда требуется перемещение кода, это так называемые функции-трамплины - вложенные функции, генерируемые gcc. Подробнее о таких функциях написано в документации на gcc - здесь и здесь.

Еще один результат paxtest касается случайного распределения объектов в адресном пространстве процесса:

  Debian Fedora Gentoo OpenSuse Ubuntu
Anonymous mapping randomisation test 9 bits 12 bits 17 bits 12 bits 12 bits
Heap randomisation test (ET_EXEC) No randomisation 14 bits 23 bits No randomisation 13 bits
Heap randomisation test (PIE) 12 bits 18 bits 23 bits 12 bits 14 bits
Main executable randomisation (ET_EXEC) No randomisation No randomisation 15 bits No randomisation No randomisation
Main executable randomisation (PIE) 12 bits 12 bits 15 bits 12 bits 12 bits
Shared library randomisation test 10 bits 3 bits 17 bits 10 bits 12 bits
Stack randomisation test (SEGMEXEC) 10 bits 19 bits 23 bits 19 bits 19 bits
Stack randomisation test (PAGEEXEC) 10 bits 19 bits 23 bits 19 bits 19 bits

paxtest по разному выполняет проверку для обычного и PIC/PIE-кода. Правила случайного распределения памяти основаны на количестве битов, используемых для вычисления случайного адреса, например 16-битное значение дает 2^16=65536 вариантов, и в среднем на поиск искомого адреса злоумышленнику нужно будет сделать 32К переборов. Из тестов видно, что ядра всех, кроме Hardened Gentoo предлагают примерно одинаковую степень энтропии в вычислении случайного адреса. Исключение тут делается в ядре Fedora с 3bit entropy для разделяемых библиотек с позиционно-независимым кодом.

Главный вывод из написанного состоит в том, что ни один из рассмотренных дистрибутивов, кроме, пожалуй, Hardened Gentoo, не уделяет должного внимания безопасности.

  1. Главная ссылка к новости (http://labs.mwrinfosecurity.co...)
Автор новости: vr13
Тип: Интересно / Обобщение
Короткая ссылка: https://opennet.ru/27938-security
Ключевые слова: security, linux
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (66) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, prapor (??), 11:43, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Хм. Надо потестить на эту тему RHEL с включенным SELinux. Интересно, как оно себя покажет.
     
     
  • 2.7, аноним (?), 12:21, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Действительно странно.
    Всё-таки RHEL/CentOS используются гораздо чаще, чем Hardened Gentoo, а по плюшкам безопасности находятся на том же уровне, если не выше.

    Наверное, авторы просто не хотели рекламировать отдельно взятую фирму.

     
     
  • 3.9, Аноним (-), 12:33, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >Действительно странно.
    >Всё-таки RHEL/CentOS используются гораздо чаще, чем Hardened Gentoo, а по плюшкам безопасности
    >находятся на том же уровне, если не выше.

    Ситуацию с RHEL/CentOS неплохо отражает Fedora. Так как в Fedora дополнительно обкатываются некоторые экспериментальные вещи, которых еще нет в RHEL/CentOS, то Fedora 13 заведомо содержит больше связанных с безопасностью функций.

     
     
  • 4.23, аноним (?), 14:02, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Ситуацию с RHEL/CentOS неплохо отражает Fedora.

    Нет. Fedora - обычный десктопный дистр, там нет кучи параноидальных защит, характерных для промышленных дистрибутивов.
    Просто потому, что они усложняют жизнь простым юзерам и часто приводят к замедлению скорости работы.

     
     
  • 5.55, Michael Shigorin (ok), 23:17, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > там нет кучи параноидальных защит, характерных для промышленных дистрибутивов.

    Можно примерчик?

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

    Когда это особо кого беспокоило в rawhide/fedora...

     
  • 4.24, prapor (??), 14:02, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Но ситуация таки отличается Вот пример из RHEL 6 beta 2 примерно та же 12-13 ф... большой текст свёрнут, показать
     
     
  • 5.32, stranger (??), 15:35, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Но ситуация таки отличается. Вот пример из RHEL 6 beta 2 (примерно
    >та же 12-13 федора):
    >2.6.32-44.2.el6.x86_64 #1 SMP Wed Jul 21 12:48:32 EDT 2010 x86_64 x86_64 x86_64
    >GNU/Linux

    А что помешало включить enforcing перед проверкой? Было бы интересно посмотреть на результаты со включенным SELinux.


     
     
  • 6.37, prapor (??), 17:34, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да результат не сильно отличился.
    2.6.32-44.2.el6.x86_64 #1 SMP Wed Jul 21 12:48:32 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

    Executable anonymous mapping             : Killed
    Executable bss                           : Killed
    Executable data                          : Killed
    Executable heap                          : Killed
    Executable stack                         : Killed
    Executable shared library bss            : Killed
    Executable shared library data           : Killed
    Executable anonymous mapping (mprotect)  : Vulnerable
    Executable bss (mprotect)                : Vulnerable
    Executable data (mprotect)               : Vulnerable
    Executable heap (mprotect)               : Killed
    Executable stack (mprotect)              : Vulnerable
    Executable shared library bss (mprotect) : Vulnerable
    Executable shared library data (mprotect): Vulnerable
    Writable text segments                   : Vulnerable
    Anonymous mapping randomisation test     : 28 bits (guessed)
    Heap randomisation test (ET_EXEC)        : 14 bits (guessed)
    Heap randomisation test (PIE)            : 28 bits (guessed)
    Main executable randomisation (ET_EXEC)  : No randomisation
    Main executable randomisation (PIE)      : 28 bits (guessed)
    Shared library randomisation test        : No randomisation
    Stack randomisation test (SEGMEXEC)      : 28 bits (guessed)
    Stack randomisation test (PAGEEXEC)      : 28 bits (guessed)
    Return to function (strcpy)              : paxtest: return address contains a NULL byte.
    Return to function (memcpy)              : Vulnerable
    Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
    Return to function (memcpy, PIE)         : Vulnerable

    Но в общем таки можно его силами прикрыться.

     
  • 5.48, solardiz (ok), 06:01, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но ситуация таки отличается. Вот пример из RHEL 6 beta 2 (примерно та же 12-13 федора):
    > 2.6.32-44.2.el6.x86_64 #1 SMP Wed Jul 21 12:48:32 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

    Это не сравнение Fedora vs. RHEL. Это сравнение i686 vs. x86_64 - разумеется, результаты будут разными, хотя бы потому что размер адресного пространства отличается. А если запустить 32-битную сборку paxtest на x86_64 ядре (с CONFIG_IA32_EMULATION) - получится еще один набор результатов, не совпадающий ни с одним из двух "простых".

     
     
  • 6.58, prapor (??), 00:58, 15/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну нету у меня i686, нету. И проверять негде.
     
  • 3.52, i (??), 11:01, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на том же уровне? не смешите, ещё раз перечитайте статью и сравните какие механизмы где используются.
     

  • 1.2, Аноним (-), 11:50, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    А, где *BSD системы?
     
     
  • 2.13, BirdGovorun (??), 12:53, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А, где *BSD системы?

    Причем здесь *BSD системы, в заголовке написано,
    Оценка безопасности различных дистрибутивов Linux

     

  • 1.3, Аноним (-), 11:57, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >напирмер, wine требует установки mmap_min_addr в 0

    Wine уже давно такого не требует.

     
     
  • 2.5, RapteR (ok), 12:12, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Етерсофтовский требует
     
     
  • 3.41, log (ok), 19:38, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не видел, чтобы требовал. Только рекомендации от ребят с Etersoft в мануале встречал.
    На практике -wine@etersoft ни разу не требовал установить vm.mmap_min_addr = 0.
     
  • 2.25, Зенитар (?), 14:36, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Этого требуют 16-битные программы для Windows 3.1
     

  • 1.4, daevy (ok), 12:10, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Hardened-версия Gentoo выбрана как демонстрация дистрибутива, который включает >в себя практически все известные методы защиты кода.

    ради демонстрации, NetSecL надо было еще затестить.

    > SSP ... Gentoo - почти не используют (10%).

    wtf?!? по дефолту все собирается с pie и ssp. они там gcc-nossp использовали чтоли??

     
     
  • 2.18, Daemontux (ok), 13:25, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> SSP ... Gentoo - почти не используют (10%).
    >wtf?!? по дефолту все собирается с pie и ssp. они там gcc-nossp использовали чтоли??

    тоже удивило.

    Либо они чего то не так сделали, либо боялись, что владельци др дистров лопнут от завести

     
  • 2.19, upyx (ok), 13:27, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем?
    Как я понял, SSP дает возможность определить изменения в выполняемом коде, в то время как RELRO не позволяет их произвести. Бишь, при использовании RELRO, SSP уже излишен.
     
     
  • 3.21, daevy (ok), 13:47, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    однако

    media ~ # wget -q http://www.debian-administration.org/articles/76/test-ssp.c
    media ~ # gcc-3.4.6 -fstack-protector -o test-ssp test-ssp.c
    media ~ # ./checksec.sh --file test-ssp
    RELRO           STACK CANARY      NX            PIE                     FILE
    Full RELRO      No canary found   NX enabled    PIE enabled             test-ssp
    media ~ # ./test-ssp 'perl -e 'print "x"x1234''
    Hello xxxxxxx....
    *** stack smashing detected ***: test-ssp - terminated
    test-ssp: stack smashing attack in function foo - terminated
    Report to http://bugs.gentoo.org/
    Убито

    наличие canary кагбэ нет, но ssp работает. пипес =)

     
     
  • 4.42, pavlinux (ok), 21:27, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >однако
    >
    >media ~ # wget -q http://www.debian-administration.org/articles/76/test-ssp.c
    >media ~ # gcc-3.4.6 -fstack-protector

    Гы, гы, гы, ... в GCC 3.4.6 этот флаг есть, но он не работает.

     
     
  • 5.50, daevy (ok), 08:26, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    остается явно прописать в make.conf сфлаги -fforce-addr -fstack-protector
     
     
  • 6.54, pavlinux (ok), 16:38, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >остается явно прописать в make.conf сфлаги -fforce-addr -fstack-protector

    -fstack-protector -fstack-protector-all -DFORTYFY_SOURCE=2 \
    -fPIE -fpie -fPIC -fpic -s -fvisibility=protected \
    -Wformat-security -W -Wall -Wextra -Wformat=2 -Werror

    :)

    ---

    А -fforce-* вроде уже отменили. Не?!

     
  • 3.22, daevy (ok), 13:54, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А зачем?
    >Как я понял, SSP дает возможность определить изменения в выполняемом коде, в
    >то время как RELRO не позволяет их произвести. Бишь, при использовании
    >RELRO, SSP уже излишен.

    да, так и есть, но при RELRO в некоторых случаях снижается общая производительность.
    при использовании ssp вобще было бы неплохо вести лог при обнаружении изменений стека))

     
  • 3.33, solardiz (ok), 15:57, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Как я понял, SSP дает возможность определить изменения в выполняемом коде, в то время как RELRO не позволяет их произвести. Бишь, при использовании RELRO, SSP уже излишен.

    Нет, это неправильное понимание.

     
     
  • 4.34, daevy (ok), 16:10, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тогда в чем магия? relro защищает структуры бинарников, а ssp защищает стек с которым работают бинарники, получается так..
     

  • 1.6, daevy (ok), 12:19, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    trapkit реально вещь))) musthave.
     
  • 1.8, estet (??), 12:25, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    openbsd 4.7:

    ~/tmp/paxtest-0.9.9$ ./paxtest kiddie
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
    Released under the GNU Public Licence version 2 or later

    Writing output to paxtest.log
    It may take a while for the tests to complete
    Test results:
    PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
    Released under the GNU Public Licence version 2 or later

    Mode: kiddie
    OpenBSD 4.7 GENERIC.MP#130 amd64

    Executable anonymous mapping             : Killed
    Executable bss                           : Killed
    Executable data                          : Killed
    Executable heap                          : Killed
    Executable stack                         : Killed
    Executable anonymous mapping (mprotect)  : Vulnerable
    Executable bss (mprotect)                : Vulnerable
    Executable data (mprotect)               : Vulnerable
    Executable heap (mprotect)               : Vulnerable
    Executable shared library bss (mprotect) : Vulnerable
    Executable shared library data (mprotect): Vulnerable
    Executable stack (mprotect)              : Vulnerable
    Anonymous mapping randomisation test     : 16 bits (guessed)
    Heap randomisation test (ET_EXEC)        : 21 bits (guessed)
    Main executable randomisation (ET_EXEC)  : No randomisation
    Shared library randomisation test        : 16 bits (guessed)
    Stack randomisation test (SEGMEXEC)      : 15 bits (guessed)
    Stack randomisation test (PAGEEXEC)      : 14 bits (guessed)
    Return to function (strcpy)              : paxtest: return address contains a NULL byte.
    Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
    Return to function (memcpy)              : Vulnerable
    Return to function (memcpy, PIE)         : Vulnerable
    Executable shared library bss            : Killed
    Executable shared library data           : Killed
    Writable text segments                   : Vulnerable

    ~/tmp/paxtest-0.9.9$

     
     
  • 2.28, slepnoga (??), 14:58, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >[оверквотинг удален]
    > : Vulnerable
    >Executable shared library bss        
    >   : Killed
    >Executable shared library data        
    >  : Killed
    >Writable text segments          
    >         : Vulnerable
    >
    >
    >~/tmp/paxtest-0.9.9$

    там же  только трамполине, и тот ископаемый.  Ну и трассировка, которая нафик не работает

     

  • 1.10, Аноним (-), 12:36, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Где рейтинг дистрибутивов по всем тестам?
     
     
  • 2.16, solardiz (ok), 13:12, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Где рейтинг дистрибутивов по всем тестам?

    Думаю, такой рейтинг по тестам составить нельзя, либо же способ его составления будет субъективным - т.е. мы получим рейтинг по мнению составителей. Лучше уж по сумме голосов N-го количества экспертов, а результаты этих и ряда других "тестов" можно максимально объективно предоставить экспертам.

     

  • 1.11, gunlinux (ok), 12:46, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Господа, в принципе ожидаемая картина, но хотелось бы большее количество систем, мне было бы интересно посмотреть на archlinux, и slackware.
     
     
  • 2.15, Аноним (-), 12:57, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А чего там смотреть? KISS же.
    Как соберешь/настроишь - так и будет.
     
     
  • 3.17, mma (?), 13:17, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А чего там смотреть? KISS же.
    >Как соберешь/настроишь - так и будет.

    ну да. тулчейн не забудте только соответсвующий собрать:)

     

  • 1.12, Аноним (-), 12:49, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Это - в качестве примера, о чем нужно писать новости.
    А то:
    "- Убунта сменила тему по умолчанию!"
    "- Вах, вах, срочно на главную! И выделить, выделить не забудьте!"
     
  • 1.14, solardiz (ok), 12:54, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    Это полезная проверка/публикация, и в целом все так и есть, но вывод не столь прост. Упомянутые не-Gentoo дистрибутивы уделяют немало внимания безопасности в других областях, причем более затратных для них, чем просто "подмена" опций сборки программ и подмена ядра. Кстати, кажется, у Debian тоже раздается hardened ядро - просто его почему-то не включили в это исследование.

    Критериев сравнения дистрибутивов по безопасности может быть гораздо больше, чем просто hardening от выполнения произвольного кода (чисто своего или сконструированного из имеющегося) в предположении наличия соответствующей уязвимости и способа до нее добраться (attack vector). Конечно, это предположение верное, но количество таких сочетаний (уязвимости и способа) для разных дистрибутивов (и вариантов их установки/настройки) будет отличаться, а также будет отличаться скорость исправления уязвимостей после их публикации (а зачастую и до публикации).

    К тому же, PIE все-таки имеет ненулевую цену по производительности. Например, в http://d-sbd.alioth.debian.org/www/?page=pax_pie приводится оценка в 5.8% для одного из вариантов сборки под 32-битный x86. В приведенном исследовании речь шла как раз о 32-бит. (На x86-64, по информации с той же ссылки, замедления почти нет.)

    grsecurity/PaX - это, предположим, хорошо, но кто и на каком основании в такой компании как Red Hat или Novell возьмет на себя ответственность за большой объем не-upstream изменений в ядро, которые аудиту толком не подвергнешь (кто пробовал этот код читать, тот знает почему)? "Я пил пиво с авторами на таком-то con'е и теперь готов поручиться" - что скажут на это клиенты?

    Возможно, ситуация была бы иной если бы когда PaX только начал появляться, к нему был бы интерес со стороны mainstream, но это тогда было нереально, как и к моему non-exec stack patch несколькими годами ранее. А несколькими годами позже аудит и включение PaX уже было нереальным по причине объема и сложности кода (вернее, нетривиальности причин, стоявших за на вид простыми изменениями кода), разрабатывавшегося в одиночку. (Возможно, если бы автор попытался вежливо, "самопожертвенно", но целенаправленно и активно давать в upstream отдельные патчи для отдельных вещей, как это, например, стали делать OpenVZ, результат был бы во многом иным. Но я понимаю, что в целом это неблагодарное занятие.) Появился exec-shield, который этих недостатков не имел, но обеспечивал менее полную защиту (частично из здравых соображений, таких как отсутствие замедления и сложных изменений кода), что мы здесь и видим.

     
  • 1.26, XoRe (ok), 14:41, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Gentoo рулит =)
    Но, справедливости ради, стоит сказать, что hardened - это не дефолтное ядро в Gentoo.
    В портежах Gentoo вообще есть несколько ядер на выбор.
    Gentoo, Vanilla, Hardened, Tux.
    Поэтому сравнивать ядра общего назначения с hardened ядром - несколько некорректно.
    У бинарных дистрибутивов так же можно устанавливать разные ядра.
    Поэтому разработчики бинарных дистрибутивов вполне могут добавить в свои репозитории hardened версии ядер.
    Кстати, возможно, данное исследование сподвигнет их на это =)
     
     
  • 2.29, slepnoga (??), 15:01, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/

    >Поэтому разработчики бинарных дистрибутивов вполне могут добавить в свои репозитории hardened версии
    >ядер.
    >Кстати, возможно, данное исследование сподвигнет их на это =)

    Угу, не забудь пересобрать всю репку.
    Как человек, написавший не одну сотню ебилдов для генты (в том числе для hardened), могу сказать что на этом пути тебя ждет много чудных открытий.
    Степень осилянства автотулзов разрабами федоры/дебиан уже вошла в поговорку ::)

     
     
  • 3.56, Michael Shigorin (ok), 23:31, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Угу, не забудь пересобрать всю репку.

    С какого перепугу?

    >Как человек, написавший не одну сотню ебилдов для генты (в том числе
    >для hardened), могу сказать что на этом пути тебя ждет много
    >чудных открытий.

    Как человек, собравший не одну сотню пакетов для альта, в т.ч. времён ow-патча и компании -- вежливо интересуюсь: с патчоматиком каким не перепутали случайно?

     
  • 2.46, yurii (??), 01:07, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Но, справедливости ради, стоит сказать, что hardened - это не дефолтное ядро в Gentoo.
    > В портежах Gentoo вообще есть несколько ядер на выбор.
    > Gentoo, Vanilla, Hardened, Tux.
    > Поэтому сравнивать ядра общего назначения с hardened ядром - несколько некорректно.
    > У бинарных дистрибутивов так же можно устанавливать разные ядра.
    > Поэтому разработчики бинарных дистрибутивов вполне могут добавить в свои репозитории > > hardened версии ядер.
    > Кстати, возможно, данное исследование сподвигнет их на это =)

    вполне корректно.
    читай новость так:
    сравнение дистрибутивов с найболее харденед опциями поставляемые\доступные "искаропки" или через подключения дополнительного __официального__ и __стабильного__ репозирория.

    просто у бинарных дистрибутивов зачастую нет такого фулл-харденед\нефулл-харденед сборка.
    каждый следует своей секурити-полиси исходя из тех или иных трейдоффов.

     
     
  • 3.57, XoRe (ok), 00:55, 15/09/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >вполне корректно.
    >читай новость так:
    >сравнение дистрибутивов с найболее харденед опциями поставляемые\доступные "искаропки"

    Gentoo и "искаропки"... - взаимоисключающие понятия)
    Он вообще не вписывается в список бинарных дистрибов.
    Я могу лишь предположить, что на примере Gentoo, авторы сравнения хотели указать дистростроителям, как можно защитить систему.

    >просто у бинарных дистрибутивов зачастую нет такого фулл-харденед\нефулл-харденед сборка.
    >каждый следует своей секурити-полиси исходя из тех или иных трейдоффов.

    Вот на то, чтобы такая сборка появилась, возможно и расчет авторов статьи)

     
     
  • 4.59, yurii (??), 10:20, 15/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Gentoo и "искаропки"... - взаимоисключающие понятия)

    ничего не взаимоисключающие.
    я сказал: сравнение дистрибутивов с найболее харденед __опциями__ поставляемые\доступные "искаропки" ( чит. харденед опции включённые поумолчанию).
    ты выбрал харденед тулчейн. скомпилировал с дефолтными настройками(PIC-PIE\неPIС-PIE,SSP\не-SSP,ASLR\не-ASLR). получил результат. вот и сравнили результат.

    > Он вообще не вписывается в список бинарных дистрибов.

    а я не говорил что генту - бинарный дистрибутив

     
     
  • 5.67, XoRe (ok), 12:20, 18/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Gentoo и "искаропки"... - взаимоисключающие понятия)
    >
    >ничего не взаимоисключающие.

    А где тогда можно скачать генту, который не надо компилировать, и который рыботал бы "из коробки"?
    Я про современную версию генту.

    >> Он вообще не вписывается в список бинарных дистрибов.
    >
    >а я не говорил что генту - бинарный дистрибутив

    И я не говорил.
    И тестировщики тоже, наверное, не говорили.
    Тогда вопрос - напуркуа сравнивать бинарные дистры с компилируемым дистром?
    Это как сравнивать машины только с завода с машиной, прошедшей тюнинг.

     
  • 3.68, Frank (??), 12:41, 21/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > просто у бинарных дистрибутивов зачастую нет такого фулл-харденед\нефулл-харденед сборка

    Вы неправы.
    ~# apt-cache show harden
    Package: harden
    Priority: extra
    Section: universe/admin
    ...
    Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
    Original-Maintainer: Ola Lundqvist <opal@debian.org>
    ...
    Depends: harden-environment, harden-servers, debconf (>= 1.2.0)
    Recommends: harden-tools
    Suggests: sudo, harden-clients, harden-nids, harden-remoteaudit, harden-surveillance, harden-doc
    ...
    Description: Makes your system hardened
    This package is intended to help the administrator to improve the security
    of the system, or at least make the host less susceptible.
    .
    NOTE! This package will not make your system uncrackable, and it is not
    intended to do so. Making your system secure involves a LOT more than just
    installing a package. You are recommended to read at least some documents
    in addition to installing this package.
    .
    There is a LOT of information available on making your system more secure.
    A good place to start is with the harden-doc package or at
    http://www.debian.org/doc/manuals/securing-debian-howto/

    так что...

     

  • 1.30, slepnoga (??), 15:06, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    И вообще то это довольно странные товарищи - сравнивают теплое с мягким.
    Как я  понимаю  , ни в одном дистре не быи включены штатные защиты или не выполнены рекомендаации девов дистров.
    Ну и в добавок - сравнение рхела  и харденед генты будет неккоректным, ибо 2-е в своей полной ипостаси ( с включением MAC ) требует ручной настройки ( и достройки) каждой машины, в отличие  от selinux
     
     
  • 2.44, pavlinux (ok), 21:49, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Как я  понимаю  , ни в одном дистре не быи включены штатные защиты или
    > не выполнены рекомендаации девов дистров.

    Все троллишь...
    Xorg у всех работает от рута ? Да! да! да!....
    Так воть, видимо забыли про дырень, именуемую vmsplice?!
    Ломались все, даже пентагоновские и АНБэшно-ФБРно-ЦРУвские.

     
     
  • 3.49, slepnoga (??), 06:42, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Как я  понимаю  , ни в одном дистре не быи включены штатные защиты или
    >> не выполнены рекомендаации девов дистров.
    >
    >Все троллишь...
    >Xorg у всех работает от рута ? Да! да! да!....
    >Так воть, видимо забыли про дырень, именуемую vmsplice?!
    >Ломались все, даже пентагоновские и АНБэшно-ФБРно-ЦРУвские.
    >
    >

    А вот фигу, как раз хреденед и не был подвержен

     
     
  • 4.53, i (??), 14:18, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    совершенно верно, помню сам проверял. От PAX-a мессага приходила тока.
     

  • 1.31, iZEN (ok), 15:18, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Вывод? Ada рулит!
     
  • 1.35, Иван Иванович Иванов (?), 16:59, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    > Главный вывод из написанного состоит в том, что ни один из рассмотренных дистрибутивов, кроме, пожалуй, Hardened Gentoo, не уделяет должного внимания безопасности.

    Или то, что автор - слишком разогнался.

    1) К сожалению, _все_ приведенные здесь защиты не спасают от дыр в ядре - а они, увы, случаются, регулярно.

    2) Наличие одного только лишь включенного SeLinux достаточно, чтобы предотвратить 95% дыр.

     
     
  • 2.39, prapor (??), 17:41, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кстати, простой пример Вот результаты на Debian Sid свежий апдейт с Enforcing... большой текст свёрнут, показать
     

  • 1.36, Аноним (-), 17:25, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    у Debian надо ставить highmem ядро, только тогда будут использоваться NX бит, это же PAE
     
  • 1.43, pavlinux (ok), 21:39, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    /usr/lib64/xorg/modules/drivers/nvidia_drv.so:

    No RELRO        No canary found   NX enabled    Dynamic Shared Object

    Nvidia рулит!  :)

     
  • 1.45, pavlinux (ok), 22:01, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Тока опять ни хрена не ясна цель!

    Если враг получил рута, это пипец,
    и никаких модификации секций PLT (Procedure Linking Table) или
    GOT (Global Offset Table) ELF-файла, и прочего подделывать не нужно.

    -----

    > Вредоносный код переполнения буфера обычно помещается в стек
    > и, таким образом, разрушает метки.
    > Работа механизмов SSP обнаруживает разрушение
    > и аварийно завершает взломанный процесс.

    То есть, если этих меток нет, процесс будет спокойно работать дальше, а не прибьется.

    Вопрос: Какой от них толк?

     
     
  • 2.47, yurii (??), 01:12, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    >> Вредоносный код переполнения буфера обычно помещается в стек
    >> и, таким образом, разрушает метки.
    >> Работа механизмов SSP обнаруживает разрушение
    >> и аварийно завершает взломанный процесс.
    >
    >То есть, если этих меток нет, процесс будет спокойно работать дальше, а
    >не прибьется.
    >
    >Вопрос: Какой от них толк?

    да много причин могут быть. я не силён в истории GCC, но вариантов может быть как минимум 2:
    1) не завершенная фича
    2) временно убранная фича ( изза проблем при сборке или ломает чего то там )
    3) gcc собран без етой опции


     
  • 2.51, daevy (ok), 09:29, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Вопрос: Какой от них толк?

    так толк как раз в том чтобы они были))) чтобы запалить какието манипуляции со стеком

    а если злодей получил таки рута, процесс должен быть ограничен рамками grsec\selinux (т.е. RBAC)


     

  • 1.60, Харон (?), 12:06, 15/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а я другой вывод сделал - Харденед Генту работает медленнее всех из-за суровых настроек безопасности :)
     
  • 1.61, Аноним (-), 07:33, 16/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Слакварь забыли :(
     
  • 1.62, FreeDoS (?), 13:22, 16/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Народ, разговор об Hardened Gentoo в данном отчете не ведется.
    Стоит хотя бы посмотреть на то, что SSP не нашли. В харденед спек для gcc содержит уже SSP, PIC и PIE, если вы конечно сами не выбрали другой (спек т.е.).

    Еще, мне кажется, стоит обратить внимание, что gentoo - это метадистрибутив. И ставить рядом с Fedora, Debian и т.д. не совсем верно. Пример выше говорит именно об этом. Из Gentoo можно собрать разные по сути дистрибутивы: хошь серверный, хош дектопный, хош мегазащищенный (hardened) с SSP, PIE/PIC, grsec+PaX или SELinux и т.д.

    Из Gentoo можно собрать действительно мощьный и защищенный дистрибутив.

     
     
  • 2.65, pavlinux (ok), 16:13, 17/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Из Gentoo можно собрать действительно мощьный и защищенный дистрибутив.

    Ага :) - http://www.opennet.ru/opennews/art.shtml?num=27979

     
     
  • 3.69, i (??), 14:14, 26/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    чего ага, не заработало ведь без system.map
     
     
  • 4.70, pavlinux (ok), 19:52, 26/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >чего ага, не заработало ведь без system.map

    Добрайо утры, пофиксили уже все что тока можно...

     
     
  • 5.71, i (??), 22:44, 26/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    так я тогда на старом ядре проверял, щас то конечно пофиксили.
     
     
  • 6.72, pavlinux (ok), 23:55, 26/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >так я тогда на старом ядре проверял, щас то конечно пофиксили.

    чуть фантазии и добавить

        for (uint64_t i=0; i < ~0; i++)

    через минуту всё получится.

     
  • 2.66, xoomer (?), 03:20, 18/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Но я ещё так с ним и не разобрался... :)
    Надо садится, да и учить его. :)
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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