TL; ДР. Во оваа статија, ги истражуваме шемите за стврднување што функционираат надвор од кутијата на пет популарни дистрибуции на Linux. За секој, ја зедовме стандардната конфигурација на кернелот, ги вчитавме сите пакети и ги анализиравме безбедносните шеми во приложените бинарни датотеки. Разгледани дистрибуции се OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 и 7, како и Ubuntu 14.04, 12.04 и 18.04 LTS.

Резултатите потврдуваат дека дури и основните шеми како што се редење канаринци и кодот независен од позицијата сè уште не се усвоени од сите. Ситуацијата е уште полоша за компајлерите кога станува збор за заштита од ранливости, како што е судирот на стек, кој се најде во центарот на вниманието во јануари по објавувањето информации за системските пропусти. Но, не е сè толку безнадежно. Значителен број бинарни датотеки имплементираат основни методи за заштита, а нивниот број расте од верзија до верзија.

Прегледот покажа дека најголемиот број заштитни методи се имплементирани во Ubuntu 18.04 на нивоа на оперативен систем и апликации, по што следи Debian 9. Од друга страна, OpenSUSE 12.4, CentOS 7 и RHEL 7 исто така имплементираат основни заштитни шеми и заштита од судир на стек се користи уште пошироко со многу погуст сет на стандардни пакети.

Вовед

Тешко е да се обезбеди висококвалитетен софтвер. И покрај огромниот број напредни алатки за анализа на статички код и динамична анализа на време на траење, како и значителен напредок во развојот на компајлери и програмски јазици, современиот софтвер сè уште страда од ранливости кои постојано се експлоатираат од напаѓачите. Ситуацијата е уште полоша во екосистемите кои вклучуваат наследен код. Во такви случаи, не само што се соочуваме со вечниот проблем на пронаоѓање на можни грешки што може да се искористат, туку сме ограничени и со строги рамки за компатибилност наназад, кои честопати бараат од нас да зачуваме ограничен, или уште полошо, ранлив или багичен код.

Тука стапуваат во игра методите за заштита или зацврстување на програмите. Не можеме да спречиме некои видови грешки, но можеме да го отежнеме животот на напаѓачот и делумно да го решиме проблемот со спречување или спречување експлоатација овие грешки. Таквата заштита се користи во сите современи оперативни системи, но методите се разликуваат многу по сложеност, ефикасност и перформанси: од канаринци и ASLR до целосна заштита CFI и ROP. Во оваа статија, ќе разгледаме кои методи за заштита се користат во најпопуларните дистрибуции на Linux во стандардната конфигурација, а исто така ќе ги испитаме својствата на бинарните датотеки што се дистрибуираат преку системите за управување со пакети на секоја дистрибуција.

CVE и безбедност

Сите сме виделе написи со наслови како „Најранливите апликации на годината“ или „Најранливите оперативни системи“. Обично тие обезбедуваат статистика за вкупниот број на записи за ранливости како CVE (Заедничка ранливост и изложеност), добиени од Национална база на податоци за ранливост (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-стандардно
# 1 SMP сре 5 декември 06:00:48 UTC 2018 (63a8d29)

Debian 9 (истегнување)
4.9.0-8-амд64
# 1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
# 1 SMP вто 15 јануари 17:07:28 UTC 2019 г

CentOS 7
3.10.0-957.5.1.el7.x86_64
# 1 SMP петок 1 февруари 14:54:57 UTC 2019 година

Red Hat Enterprise Linux Server 6.10 (Сантијаго)
2.6.32-754.9.1.el6.x86_64
# 1 SMP сре 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 четврток 15 ноември 17:36:42 UTC 2018 година

Ubuntu 14.04 (Доверлив Тахр)
4.4.0-140-генерички

#166~14.04.1-Ubuntu SMP саб, 17 ноември 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0-1026-gcp
#27~16.04.1-Ubuntu SMP петок 7 декември 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0-1026-gcp
#27-Ubuntu SMP четврток 6 декември 18:27:01 UTC 2018

Табела 1

Анализа

Ајде да ја проучиме стандардната конфигурација на кернелот, како и својствата на пакетите достапни преку менаџерот на пакети на секоја дистрибуција надвор од кутијата. Така, ние ги разгледуваме само пакетите од стандардните огледала на секоја дистрибуција, игнорирајќи ги пакетите од нестабилните складишта (како што се огледалата за „тестирање“ на Debian) и пакетите од трети страни (како што се пакетите Nvidia од стандардните огледала). Дополнително, не ги разгледуваме прилагодените компилации на кернелот или безбедносните појачани конфигурации.

Анализа на конфигурација на кернелот

Применивме скрипта за анализа врз основа на бесплатна проверка на kconfig. Да ги погледнеме параметрите за заштита надвор од кутијата на именуваните дистрибуции и да ги споредиме со листата од Основен проект за самоодбрана (КСПП). За секоја опција за конфигурација, Табела 2 ја опишува саканата поставка: полето за избор е за дистрибуции кои се во согласност со препораките на KSSP (видете го следново за објаснување на термините). тука; Во идните написи ќе објасниме колку од овие безбедносни методи настанале и како да се хакира систем во нивно отсуство).

Во принцип, новите кернели имаат построги поставки надвор од кутијата. На пример, CentOS 6.10 и RHEL 6.10 на кернелот 2.6.32 немаат повеќето критични карактеристики имплементирани во поновите кернели како што се SMAP, строги RWX дозволи, рандомизација на адреси или заштита од copy2usr. Треба да се забележи дека многу од опциите за конфигурација во табелата не се достапни во постарите верзии на кернелот и не се применливи во реалноста - ова сè уште е означено во табелата како недостаток на соодветна заштита. Исто така, ако опцијата за конфигурација не е присутна во дадена верзија, а безбедноста бара таа опција да биде оневозможена, ова се смета за разумна конфигурација.

Друга точка што треба да се земе предвид при толкувањето на резултатите: некои конфигурации на кернелот што ја зголемуваат површината на нападот може да се користат и за безбедност. Таквите примери вклучуваат uprobes и kprobes, кернел модули и BPF/eBPF. Наша препорака е да се користат горенаведените механизми за да се обезбеди вистинска заштита, бидејќи тие се нетривијални за користење и нивната експлоатација претпоставува дека злонамерните актери веќе имаат воспоставено упориште во системот. Но, ако овие опции се овозможени, администраторот на системот мора активно да следи за злоупотреба.

Гледајќи понатаму во записите во Табела 2, гледаме дека модерните кернели обезбедуваат неколку опции за заштита од експлоатација на пропусти како што се истекување на информации и прелевање на стек/купи. Сепак, забележуваме дека дури и најновите популарни дистрибуции сè уште немаат имплементирано посложена заштита (на пример, со закрпи гробезбедност) или модерна заштита од напади за повторна употреба на код (на пр. комбинација на рандомизација со шеми како R^X за код). За да бидат работите уште полоши, дури и овие понапредни одбрани не штитат од целиот опсег на напади. Затоа, од клучно значење е системските администратори да ги надополнуваат паметните конфигурации со решенија кои нудат откривање и спречување на експлоатација за време на траење.

Анализа на апликации

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

дистрибуции

Вкупно, преземавме 361 пакети за сите дистрибуции, извлекувајќи само пакети од стандардните ретровизори. Ги игнориравме пакетите без извршни ELF, како што се извори, фонтови итн. По филтрирањето, останаа 556 пакети, кои содржат вкупно 129 бинарни датотеки. Дистрибуцијата на пакети и датотеки низ дистрибуциите е прикажана на сл. 569.

Сл. 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. XNUMX.

Сл. 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

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

• Позиција независно извршно (PIE): Покажува дали текстуалниот дел од програмата може да се премести во меморијата за да се постигне рандомизација ако ASLR е овозможен во кернелот.
• Заштитено со оџак: дали се овозможени канаринците со оџак да се заштитат од напади од судир на оџак.
• Fortify Source: дали небезбедните функции (на пример, strcpy) се заменуваат со нивните побезбедни колеги, а повиците проверени при извршување се заменуваат со нивните непроверени колеги (на пример, memcpy наместо __memcpy_chk).
• Преместувања само за читање (RELRO): Дали записите во табелата за преместување се означени само за читање ако се активираат пред да започне извршувањето.
• Непосредно врзување: дали поврзувачот за време на траење ги дозволува сите потези пред да започне извршувањето на програмата (ова е еквивалентно на целосен RELRO).

Дали горенаведените механизми се доволни? За жал не. Постојат познати начини да се заобиколат сите горенаведени одбрани, но колку е поцврста одбраната, толку е поголема лентата за напаѓачот. На пример, RELRO бајпас методи потешко е да се примени ако PIE и непосредно врзување се во сила. Слично на тоа, целосниот ASLR бара дополнителна работа за да се создаде работна експлоатација. Сепак, софистицираните напаѓачи се веќе подготвени да ги исполнат таквите заштити: нивното отсуство во суштина ќе го забрза хакирањето. Затоа е од суштинско значење овие мерки да се сметаат за неопходни минимум.

Сакавме да проучиме колку бинарни датотеки во предметните дистрибуции се заштитени со овие и три други методи:

• Неизвршен бит (NX) го спречува извршувањето во кој било регион што не треба да може да се изврши, како што е купот на стек итн.
• RPATH/RUNPATH ја означува патеката на извршување што ја користи динамичкиот вчитувач за да најде соодветни библиотеки. Првиот е задолжително за секој модерен систем: неговото отсуство им овозможува на напаѓачите произволно да го запишат товарот во меморијата и да го извршат како што е. За втората, неточните конфигурации на патеката за извршување помагаат во воведувањето на несигурен код што може да доведе до голем број проблеми (на пр. ескалација на привилегииИ други проблеми).
• Заштитата од судир на стек обезбедува заштита од напади што предизвикуваат оџакот да се преклопува со другите области на меморијата (како што е купот). Со оглед на неодамнешните злоупотреби системски ранливости на судир на куп, сметавме дека е соодветно да го вклучиме овој механизам во нашата база на податоци.

Значи, без понатамошно одложување, да се спуштиме на бројките. Табелите 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 (популарен пакет за апликации забрзани со графички процесор како што се рамки за машинско учење), и 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, забележуваме големи подобрувања во имплементацијата на stack canaries и RELRO од верзиите 6 до 7, но во просек CentOS има имплементирани повеќе функции од RHEL. Генерално, сите дистрибуции треба да обрнат посебно внимание на заштитата на PIE, која, со исклучок на Debian 9 и Ubuntu 18.04, се имплементира во помалку од 10% од бинарните датотеки во нашата база на податоци.

Конечно, треба да се забележи дека иако истражувањето го спроведовме рачно, има многу достапни безбедносни алатки (на пр. Линис, Тигар, Хабл), кои вршат анализа и помагаат да се избегнат небезбедни конфигурации. За жал, дури и силната заштита во разумни конфигурации не гарантира отсуство на експлоатирања. Затоа ние цврсто веруваме дека е од витално значење да се обезбеди доверливо следење и спречување на напади во реално време, фокусирајќи се на моделите на експлоатација и нивно спречување.

Извор: www.habr.com