TL;DR. В тази статия разглеждаме схеми за защита (hardening schemes), които влизат в готов вид в пет популярни дистрибуции на Linux. За всяка от тях взехме конфигурацията на ядрото по подразбиране, заредихме всички пакети и анализирахме схемите за защита в вложените бинарни файлове. Обсъждат се дистрибуции OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 и 7, както и Ubuntu 14.04, 12.04 и 18.04 LTS.

Резултатите потвърдиха, че дори основните схеми, като стекови канарейки и независим от позицията код, все още не се използват от всички. Ситуацията е още по-лоша при компилаторите, що се отнася до защитата от уязвимости, като например сблъсъка на стека (stack clash), които станаха централна тема през януари след публикуването на информация за уязвимостите в systemd. Но не всичко е толкова безнадеждно. В значителна част от бинарниците са реализирани основни методи за защита, а техният брой нараства с всяка версия.

Проверка показа, че най-много методи за защита са реализирани в Ubuntu 18.04 на ниво ОС и приложения, следвани от Debian 9. От друга страна, в OpenSUSE 12.4, CentOS 7 и RHEL 7 също са реализирани основни схеми за защита, а защитата от сблъсък на стека се прилага още по-широко при значително по-плътен набор от пакети по подразбиране.

Въведение

Трудно е да се осигури високо качество на софтуера. Въпреки огромното количество напреднали инструменти за статичен анализ на кода и динамичен анализ при изпълнение, както и значителния напредък в разработването на компилатори и програмни езици, съвременният софтуер все още страда от уязвимости, които постоянно се експлоатират от злонамерени лица. Ситуацията е още по-лоша в екосистеми, които включват остарял код. В такива случаи не само че се сблъскваме с вечния проблем за откриването на възможни експлоатирани грешки, но и сме ограничени от строги рамки за обратно съвместимост, които често изискват запазване на ограничен, а още по-лошо — уязвим или с бъгове код.

Тук влизат в игра методите за защита или усилване на софтуера (hardening). Някои видове грешки не можем да предотвратим, но можем да направим живота на злонамерените лица по-труден и частично да решим проблема, предотвратявайки или затруднявайки експлоатация тези грешки. Тази защита се използва във всички съвременни ОС, но методите значително се различават по сложност, ефективност и производителност: от стекирани канарчета (stack canaries) и ASLR до пълноценна защита CFI и ROP. В тази статия ще разгледаме какви методи за защита се прилагат в най-популярните дистрибуции на Linux в конфигурацията по подразбиране, както и ще проучим свойствата на бинарните файлове, разпространявани чрез системите за управление на пакети на всеки дистрибутив.

CVE и сигурност

Всички ние сме виждали статии с заглавия като „Най-уязвимите приложения на годината“ или „Най-уязвимите операционни системи“. Обикновено там се дават статистики за общия брой записи за уязвимости от тип CVE (Common Vulnerability and Exposures), получени от Националната база данни за уязвимости (NVD) от NIST и други източници. Впоследствие тези приложения или ОС се класират по брой CVE. За съжаление, макар че CVE са много полезни за проследяване на проблеми и информиране на доставчици и потребители, те не дават много информация за реалната сигурност на софтуера.

За пример, нека разгледаме общия брой CVE за последните четири години за ядрото на Linux и петте най-популярни сървърни дистрибуции, а именно Ubuntu, Debian, Red Hat Enterprise Linux и OpenSUSE.

Фиг. 1

Какво ни показва тази графика? Означава ли по-голямото количество CVE, че един дистрибутив е по-уязвим от друг? Отговорът е не. Например, в тази статия ще видите, че в Debian са реализирани по-строги механизми за защита в сравнение, да речем, с OpenSUSE или RedHat Linux, и все пак Debian има повече CVE. Въпреки това те не непременно сочат за отслабена сигурност: дори наличието на CVE не означава, че уязвимостта може да бъде експлоатирана. Оценките за сериозност дават представа за вероятността да се използва уязвимостта, но в крайна сметка експлоатируемостта в значителна степен зависи от защитата, присъстваща в засегнатите системи, както и от ресурсите и възможностите на злоумышленниците. Освен това, отсъствието на отчети CVE не казва нищо за други незадължени или неизвестни незарегистрированных или неизвестных уязвимостите. Разликата в CVE може да се обясни не с качеството на софтуера, а с други фактори, включително ресурси, които са отделени за тестване или размер на потребителската база. В нашия пример, по-голямото количество CVE за Debian може просто да показва, че Debian предоставя повече софтуерни пакети.

Разбира се, системата CVE предоставя полезна информация, която позволява създаването на съответни защити. Колкото по-добре разбираме причините за провалите в програмите, толкова по-лесно можем да определим възможните начини за експлоатация и да разработим съответните механизми. за открития и реагиране. На рис. 2 са показани категориите уязвимости за всички дистрибуции за последните четири години (източник). Очевидно е, че повечето CVE попадат в следните категории: отказ на обслужване (DoS), изпълнение на код, препълване, повреждане на паметта, изтичане (екзфилтрация) на информация и ескалация на привилегии. Въпреки че много CVE са отчетени няколко пъти в различни категории, като цяло същите проблеми остават годишно. В следващата част на статията ще оценим употребата на различни схеми на защита за предотвратяване на експлоатацията на посочените уязвимости.

Рис. 2

Задачи

В тази статия имаме намерение да отговорим на следните въпроси:

• Каква е сигурността на различните дистрибуции на Linux? Какви защитни механизми съществуват в ядрото и приложението на потребителското пространство?
• Как се е променило приемането на механизми за защита за различните дистрибуции през времето?
• Какви са средните зависимости на пакети и библиотеки за всяка дистрибуция?
• Какви защити са реализирани за всеки бинарен файл?

Избор на дистрибуции

Оказва се, че е трудно да се намери точна статистика за инсталации на дистрибуции, тъй като в повечето случаи броят на тегленията не показва броя на реалните инсталации. Въпреки това, Unix вариантите съставляват мнозинството от сървърните системи (на уеб сървъри 69.2%, според на статистиката W3techs и други източници), и тяхната дял постоянно нараства. Така че, за нашето изследване, ние се фокусирахме на дистрибуции, достъпни от кутията на платформата Google Cloud. В частност, избрахме следните ОС:

Дистрибуция/версия
Ядро
Сборка

OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)

Debian 9 (stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Fri Feb 1 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wed Nov 21 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic

#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018

Таблица 1

Анализ

Ние ще разгледаме конфигурацията на ядрото по подразбиране, както и свойствата на пакетите, достъпни чрез пакетния мениджър на всяко дистрибуция от самото начало. Така ще се фокусираме само върху пакетите от подразбиращите се огледала на всяка дистрибуция, игнорирайки пакетите от нестабилни хранилища (например огледалата ‘testing’ в Debian) и пакети от трети страни (например NVIDIA пакети от стандартни огледала). Освен това, няма да разглеждаме потребителски компилации на ядра или конфигурации с повишена защита.

Анализ на конфигурацията на ядрото

Използвахме скрипт за анализ, базиран на свободния чекер kconfig. Разглеждаме параметрите за защита от самото начало при избраните дистрибуции и ги сравняваме с списъка от Проекта за самозащита на ядрото (KSPP). За всеки параметър на конфигурацията, таблица 2 описва желаната настройка: маркировката е поставена за дистрибуции, които отговарят на препоръките на KSSP (обяснение на термини ще бъде предоставено тук; в бъдещи статии ще разкажем как много от тези методи за защита са се появили и как да се хакне системата в тяхно отсъствие).

Общото впечатление е, че в новите ядра настройките по подразбиране са по-строги. Например, CentOS 6.10 и RHEL 6.10 с ядро 2.6.32 нямат повечето критични функции, реализирани в новите ядра, като SMAP, строги разрешения RWX, адресна рандомизация или защита copy2usr. Следва да се отбележи, че много от вариантите на конфигурацията в таблицата не са налични в по-старите версии на ядрото и не са приложими в действителност — в таблицата това все пак е отбелязано като липса на адекватна защита. По аналогичен начин, ако параметърът на конфигурацията не е наличен в тази версия, а за сигурността е необходимо да се деактивира, това се счита за разумна конфигурация.

Друг момент при интерпретацията на резултатите: някои конфигурации на ядрото, които увеличават повърхността на атаката, могат същевременно да се използват за сигурност. Такива примери включват uprobes и kprobes, модули на ядрото и BPF/eBPF. Нашата препоръка е да използвате посочените механизми за осигуряване на реална защита, тъй като те не са тривиални за използване, а тяхната експлоатация предполага, че злонамерени субекти вече са се укрили в системата. Но ако тези опции са включени, системният администратор трябва активно да наблюдава за злоупотреби.

Изследвайки по-нататък записките от таблица 2, виждаме, че съвременните ядра предоставят няколко опции за защита от експлоатация на такива уязвимости, като изтичане на информация и преливане на стек/куча. Въпреки това, забелязваме, че дори най-новите популярни дистрибуции все още не са реализирали по-сложна защита (например с пачове grsecurity) или съвременна защита от атаки с повторно използване на код (например, комбинация от рандомизация с R^X схеми за код). Още по-лошо, дори тези по-напреднали средства за защита не защитават от пълния спектър от атаки. Следователно, е изключително важно за системните администратори да допълват разумните конфигурации с решения, предлагащи откритие и предотвратяване на експлойти в реално време.

Анализ на приложения

Не е изненадващо, че различните дистрибуции имат различни характеристики на пакетите, параметри за компилация, зависимости на библиотеките и т.н. Разлики съществуват дори при родствени дистрибуции и пакети с малък брой зависимости (например, coreutils в Ubuntu или Debian). За да оценим разликите, изтеглихме всички налични пакети, извлякохме съдържанието им и анализирахме бинарните файлове и зависимостите. За всеки пакет проследявахме другите пакети, от които зависи, и за всеки бинарник проследявахме зависимостите му. В тази секция накратко ще изложим заключенията.

Дистрибуции

Общо сме изтеглили 361 556 пакета за всички дистрибуции, извличайки само пакети от основните огледала. Игнорирахме пакети без изпълними ELF файлове, като сорс кодове, шрифтове и т.н. След филтрирането останаха 129 569 пакета, съдържащи общо 584 457 бинарни файла. Разпределението на пакетите и файловете по дистрибуции е показано на рис. 3.

Рис. 3

Можем да забележим, че колкото по-съвременен е дистрибутивът, толкова повече пакети и бинарни файлове съдържа, което е логично. В същото време пакети от Ubuntu и Debian включват значително повече бинарни файлове (както изпълними, така и динамични модули и библиотеки) в сравнение с CentOS, SUSE и RHEL, което потенциално влияе на повърхността на атака на Ubuntu и Debian (трябва да се отбележи, че цифрите отразяват всички бинарници на всички версии на пакета, т.е. някои файлове се анализират няколко пъти). Това е особено важно, като се вземат предвид зависимостите между пакетите. По този начин, уязвимост в бинарник на един пакет може да повлияе на много части от екосистемата, както уязвима библиотека може да повлияе на всички бинарни файлове, които я импортират. Като отправна точка, нека погледнем разпределението на броя зависимости по пакетите в различни ОС:

Рис. 4

Почти във всички дистрибуции 60% от пакетите имат минимум по 10 зависимости. Освен това, при някои пакети броят на зависимостите е значително по-висок (над 100). Същото важи и за обратните зависимости на пакетите: каквото и да се очаква, няколко пакета се използват от много други пакети в дистрибуцията, поради което уязвимостите в тези малко на брой имат висок риск. Като пример в следващата таблица са изброени 20 пакета с максимално количество обратни зависимости в SLES, Centos 7, Debian 9 и Ubuntu 18.04 (в всяка клетка е посочен пакетът и броят на обратните зависимости).

Таблица 3

Интересен факт. Въпреки че всички анализирани ОС са изградени за архитектура x86_64, а при повечето пакети архитектурата е определена като x86_64 и x86, пакети често съдържат бинарни файлове за други архитектури, както е показано на рис. 5.

Рис. 5

В следващата секция ще задълбочим анализа на характеристиките на прегледаните бинарници.

Статистика за защита на бинарните файлове

Като абсолютен минимум, трябва да се изучи основният набор от варианти за защита на наличните бинарни файлове. Няколко дистрибуции на Linux се предлагат с скриптове, които извършват такива проверки. Например, в Debian/Ubuntu има такъв скрипт. Ето пример за неговата работа:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

Скриптът проверява пет функции за защита:

• Position Independent Executable (PIE): указва дали може да се премести текстовият раздел на програмата в паметта, за да се постигне рандомизация, ако ASLR е включен в ядрото.
• Stack Protected: включени ли са стекови канарейки за защита от атаки на сблъсък на стека.
• Fortify Source: заменят ли се небезопасните функции (например, strcpy) с техните по-безопасни аналози, а проверяваните при изпълнение извиквания - с техните небезопасни аналози (например, memcpy вместо __memcpy_chk).
• Read-only relocations (RELRO): маркирани ли са записите на таблицата за преместване като „само за четене“, ако те заработят преди началото на изпълнението.
• Immediate binding (незабавна привързаност): разрешава ли компилаторът на средата за изпълнение всички премествания преди началото на изпълнението на програмата (това е еквивалентно на пълно RELRO).

Достатъчни ли са горепосочените механизми? За съжаление, не. Известни са начините за заобикаляне на всички горепосочени защити, но колкото по-строга е защитата, толкова по-висока е летвата за атакуващия. Например, методите за заобикаляне на RELRO са по-трудни за прилагане, ако действат PIE и незабавна привързаност. Подобно, пълният ASLR изисква допълнителна работа за създаване на работещ експлойт. Въпреки това, изтънчените злонамерени лица вече са готови да се срещнат с такива защити: тяхното отсъствие по същество ускорява хакването. Затова е изключително важно тези мерки да се разглеждат като необходими. минимум.

Искахме да проучим колко много бинарни файлове в разглежданите дистрибуции са защитени с тези, както и с още три метода:

• Неизпълняемият бит (NX) предотвратява изпълнението в всяка област, която не трябва да бъде изпълняема, например в стека и т.н.
• RPATH/RUNPATH определя пътя за изпълнение, използван от динамичния загрузчик за търсене на подходящи библиотеки. Първият е задължителен за всяка съвременна система: отсъствието му позволява на нападателите произволно да записват полезен товар в паметта и да го изпълняват както е. За второто, неправилните конфигурации на пътя на изпълнението спомагат за въвеждането на ненадежден код, който може да доведе до редица проблеми (например, ескалация на привилегиите, а също така други проблеми).
• Защитата от стекове на сблъсъци осигурява защита срещу атаки, които принуждават стека да се наложи върху други области на паметта (например, върху купчина). С оглед на скорошните експлойти, които злоупотребяват с уязвимостите на купчината в systemd, решихме, че е уместно да включим този механизъм в нашия набор от данни.

Така че, без повече церемонии, да преминем към цифрите. Таблици 4 и 5 съдържат извадка от анализа на изпълними файлове и библиотеки на различни дистрибуции, съответно.

• Както може да се забележи, защитата NX е реализирана навсякъде, с редки изключения. По-специално, може да се отбележи по-ниското й използване в дистрибуции на Ubuntu и Debian в сравнение с CentOS, RHEL и OpenSUSE.
• Стековите канарейки отсъстват на много места, особено в дистрибуции с остарели ядра. Някакъв напредък се наблюдава в последните дистрибуции на CentOS, RHEL, Debian и Ubuntu.
• С изключение на Debian и Ubuntu 18.04, в повечето дистрибуции има лоша поддръжка на PIE.
• Защитата от сблъсъци на стека е слабо реализирана в OpenSUSE, CentOS 7 и RHEL 7 и практически отсъства в останалите.
• Всички дистрибуции с модерни ядра имат известна поддръжка за RELRO, като водещ е Ubuntu 18.04, а на второ място е Debian.

Както вече бе споменато, метриките в тази таблица са средни за всички версии на бинарния файл. Ако се погледне само последните версии на файловете, цифрите ще бъдат различни (например, вижте напредъка на Debian с внедряването на PIE). Освен това, повечето дистрибуции обикновено проверяват защитата само на няколко функции в бинарния код при изчисляване на статистиката, а в нашия анализ е посочен истинският процент на укрепените функции. Поради това, ако в бинарния файл са защитени 5 от 50 функции, ще му укажем оценка 0,1, което съответства на 10% укрепени функции.

Таблица 4. Характеристики на защитата за изпълними файлове, показани на рис. 3 (реализация на съответните функции в проценти от общия брой изпълними файлове)

Таблица 5. Характеристики защита за библиотеките, показани на рис. 3 (реализация на съответните функции в проценти от общия брой библиотеки)

Има ли напредък? Определено: това личи в статистиката за отделни дистрибуции (например, Debian), а също и от представените по-горе таблици. Като пример на рис. 6 е показано внедряването на защитни механизми в три последователни дистрибуции на Ubuntu LTS 5 (пропуснахме статистиката за защита от сблъсъка на стека). Забелязваме, че от версия на версия все повече файлове поддържат стекови канарчета, а също така все повече бинарни файлове се предоставят с пълна защита RELRO.

Рис. 6

За съжаление, серия от изпълними файлове в различни дистрибуции все още не притежават нито една от посочените по-горе защити. Например, при Ubuntu 18.04 може да се забележи бинарният файл ngetty (заместител на getty), както и обвивките mksh и lksh, интерпретаторът picolisp, пакетите nvidia-cuda-toolkit (популярен пакет за приложения с GPU-ускорение, такива като фреймворци за машинно обучение) и klibc-utils. По аналогия, бинарният файл mandos-client (административен инструмент, който позволява автоматично рестартиране на машини с криптирани файлови системи), а също и rsh-redone-client (повторна реализация на rsh и rlogin) се доставят без защита NX, въпреки че имат права SUID :(. Освен това, в няколко SUID-бинарника липсва основна защита, като например стекови канарки (например, бинарния файл Xorg.wrap от пакета Xorg).

Резюме и заключителни бележки

В тази статия изтъкваме няколко свойства на сигурността на съвременните дистрибуции на Linux. Анализът показва, че в последната дистрибуция на Ubuntu LTS (18.04) се реализира средно най-силната защита на ниво ОС и приложения сред дистрибуциите с относително нови ядра, като Ubuntu 14.04, 12.04 и Debian 9. Обаче разгледаните дистрибуции CentOS, RHEL и OpenSUSE в нашия набор от данни по подразбиране предлагат по-плътен набор от пакети, а в последните версии (CentOS и RHEL) имат по-висок процент на реализация на защита срещу сблъсък на стека в сравнение с конкурентите на базата на Debian (Debian и Ubuntu). Сравнявайки версиите CentOS и RedHat, наблюдаваме значителни подобрения в внедряването на стекови канарки и RELRO от версии 6 до 7, но средно в CentOS е реализирано повече функции, отколкото в RHEL. Като цяло, всички дистрибуции трябва да обърнат особено внимание на защитата PIE, която, с изключение на Debian 9 и Ubuntu 18.04, е реализирана в по-малко от 10% от бинарните файлове в нашия набор от данни.

Накрая, трябва да отбележим: макар че проведохме изследването ръчно, съществуват множество инструменти за сигурност (например, Lynis, Tiger, Hubble), които извършват анализ и помагат да се избегнат небезопасни конфигурации. За съжаление, дори силната защита в разумни конфигурации не гарантира отсъствие на експлойти. Ето защо сме убедени, че е от жизненоважно значение да се осигури надежден мониторинг и предотвратяване на атаки в реално време, съсредоточавайки се върху модели на експлоатация и предотвратявайки ги.

Източник: habr.com