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 също са внедрени основни схеми за защита, а защитата от stack clash се прилага още по-широко с много по-гъст набор от пакети по подразбиране.

Въведение

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

Тук влизат в действие методите за защита или усилване на софтуера (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 пакети от стандартните огледала). Освен това, няма да разглеждаме потребителски компилации на ядрото или конфигурации с повишена сигурност.

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

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

Като цяло, новите ядра имат по-строги настройки по подразбиране. Например, при 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:
 Позиционно независимо изпълнимо: да
 Защитен стек: да
 Функции Fortify Source: не, намерени са само небезопасни функции!
 Записи само за четене: да
 Непосредствено свързване: да

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

• Позиционно независимо изпълнимо (PIE): указва дали текстовият раздел на програмата може да бъде преместен в паметта, за да се постигне рандомизация, ако в ядрото е включен ASLR.
• Защитен стек: включени ли са стекови канарейки за защита от атаки срещу сблъсък на стека.
• Fortify Source: заменят ли се небезопасните функции (например, strcpy) с техните по-безопасни алтернативи, а проверките в реално време с техните непроверявани аналози (например, memcpy вместо __memcpy_chk).
• Записи само за четене (RELRO): означават ли записите в таблицата за преместване, че са маркирани като 'само за четене', ако са активирани преди началото на изпълнението.
• Непосредствено свързване: позволява ли средата на компоновщика да разреши всички преместивания преди началото на изпълнението на програмата (това е еквивалентно на пълно 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