Jaderné noviny – 18. 1. 2018: Přehled několika svobodných fuzzovacích nástrojů

12. 2. 2018 | Redakce | Jaderné noviny | 3810×

Stav vydání jádra. Analýza procesu zavádění Linuxu. Citáty týdne: Kees Cook a Thomas Gleixner. Přehled několika svobodných fuzzovacích nástrojů.

Stav vydání jádra

Současné vývojové jádro je 4.15-rc8, vydané 14. ledna. Tento kandidát na vydání obsahuje krom jiného mechanismus „retpoline“ zamýšlený ke zmírnění druhé varianty zranitelnosti Spectre. Testování této změny ale bude těžké, protože vyžaduje verzi GCC, kterou skoro nikdo nemá. Podrobnosti naleznete v tomto článku. „Stále doufám, že půjde o poslední -rc, i přes všechen ten frmol s Meltdown a Spectre. Ale nezbývá než počkat. Záleží na tom, jestli příští týden nedojde k nějakým velkým překvapením.“

Stabilní aktualizace: 4.14.14, 4.9.77, 4.4.112 a 3.18.92 byly vydány 17. ledna.

Analýza procesu zavádění Linuxu (opensource.com)

Alison Chaiken se na webu opensource.com podrobně zabývá tím, jak probíhá zavádění Linuxu. „Slouží firmware v rané fázi zavádění k ještě něčemu jinému než spuštění chybami zapleveleného spywaru? Úkolem zavaděče je zpřístupnit čerstvě zapnutému procesoru prostředky, které potřebuje ke spuštění univerzálního operačního systému, jako je Linux. Při zapnutí není k dispozici nejen virtuální paměť, ale ani DRAM, dokud nedojde k zapnutí příslušného řadiče.“

Citáty týdne

KASLR byl vždy pochybný v případě lokálních útoků. Při čistě vzdálených útocích je stále užitečný. A při posouvání výzkumu kupředu se zdá být docela užitečný. ;)

—Kees Cook

Upřímně řečeno, posledních 10 dní bylo ještě horších než celá práce na PTI, a to kvůli nedostatku dokumentace, 12 rozdílných názorech od 8 lidí (proč to smrdí právničinou?) a úžasnému množství nedopečených a horkou jehlou narychlo spíchnutých hoven.

Prosím, zastavme to a vraťme se teď do normálu.

—Thomas Gleixner

Přehled několika svobodných fuzzovacích nástrojů

A survey of some free fuzzing tools. J. B. Crawford. 17. ledna 2018

Řada technik v oblasti softwarové bezpečnosti je komplikovaná a vyžaduje hluboké porozumění vnitřnímu fungování počítače a testovaného softwaru. Některé techniky jsou naopak koncepčně jednoduché a nevyžadují znalost příslušného softwaru. Dobrým příkladem je fuzzing: testování programu širokou paletou nesmyslných vstupů a sledování, zda se děje něco neobvyklého či zajímavého, třeba jestli program spadne. Ačkoli se to může zdát nesofistikované, fuzzing je velmi užitečný při hledání problémů s analýzou a zpracováním vstupů, které často stojí na začátku bezpečnostních zranitelností.

Mnoho běžných druhů bezpečnostních zranitelností se objeví ve chvíli, kdy se něco pokazí při zpracování vstupů, příkladem budiž klasické přetečení vyrovnávací paměti. Zajímavé je tím, že se zprvu jeví jako nestabilita. Pokud je vstup na vyrovnávací paměť příliš dlouhý, program se pravděpodobně bude chovat nestandardně a selže. Při pečlivém návrhu příliš dlouhého vstupu je možné tuto chybu proměnit ve spuštění libovolného kódu. Cílem fuzzingu je najít situace, ve kterých program selže v důsledku neobvyklého vstupu. Opravy těchto chyb činí software stabilnějším a zároveň se tím zavírají vrátka bezpečnostním problémům, které by jinak mohly nastat.

Fuzzovací nástroje

V praxi fungují fuzzovací nástroje tak, že generují soubory, text a další druhy vstupů, které mají nejrůznější neobvyklé vlastnosti, přičemž jednoduchým příkladem je právě nadměrná délka. Software je pak automaticky testován se všemi těmito vstupy a všechna abnormální ukončení jsou zaznamenána k pozdější analýze. Jakákoli selhání představují v nejlepším případě malou chybu a v nejhorším případě vážnou zranitelnost.

Jeden z nejznámějších fuzzovacích nástrojů je humorně nazvaný american fuzzy lop, zkráceně AFL. Tento nástroj využívá instrukce zkompilované do testovaného programu, aby se odhalilo, kolik větví provádění kódu se v programu s daným vstupem použije, a poté použije genetický algoritmus k návrhu vstupu, který vede k maximálnímu pokrytí. To zajistí, že testování pokryje i ty nejřídčeji používané větve v provádění kódu, které obsahují zranitelnosti nejčastěji.

Jednou z nejsilnějších stránek AFL je snadné zprovoznění, protože AFL může používat své vlastní algoritmy, a tak běžet bez dozoru. Po přeložení programu s testovacími instrukcemi stačí dodat AFL příkaz k vyvolání programu a vzorový vstupní soubor. AFL zkouší modifikovat vzorový vstup, aby našel minimální přijatelný vstup programu, a poté vynalézá výrazně složitější vstupy, aby zjistil co nejvíce větví provádění programu.

AFL disponuje sadou pravidel používaných ke generování různých vstupů pro testování. Nejjednodušší je změna jednotlivých bitů na vstupu. Ve složitějším případě může použít soubor se slovníkem, na základě kterého složí řetězce klíčových slov, které dávají v testovaném programu smysl. Konečně, testovací data AFL nemusí být dočasná. Testovací vstupy, které AFL navrhne, je možné uložit k použití s jinými testovacími a auditními nástroji.

Další populární open-source fuzzer je honggfuzz, který se v mnoha ohledech podobá AFL, ale s tím důležitým rozdílem, že může používat funkce zabudované do procesorů, jako jsou jednotka řízení výkonu a mechanismus Intel Procesor Trace, k detekování různých větví provádění testovaného programu. Tyto funkce činí honggfuzz lepší volbou při testování softwaru, který nemůže být znovu sestaven ze zdrojových kódů za účelem přidání testovacích instrukcí. Za zmínku stojí také libFuzzer, poměrně nový nástroj, který je distribuován se Clang a těsně integrován s dalšími testovacími funkcemi LLVM.

Aby byl proces efektivnější, je fuzzing často doplněn jinými testovacími nástroji jako například Sanitizers od Google. Možná nejdůležitější částí této kolekce je Adress Sanitizer neboli ASan. ASan je zabudován do spustitelného souboru a poté detekuje a hlásí běžné problémy s adresováním paměti, včetně přetečení vyrovnávací paměti a použití po uvolnění (use-after-free). K dispozici je také ThreadSanitizer, který detekuje určitě podmínky souběhu, a MemorySanitizer, který detekuje použití neinicializované paměti. Tyto druhy nástrojů tvoří spolu s fuzzerem perfektní kombinaci, protože mohou detekovat problémy vyvolané vstupem při fuzzingu, i když tyto chyby nevedou přímo k pádu.

Fuzzing je v současnosti nejlepší praxí při vyhodnocování stability a bezpečnosti nového softwaru, ale řada balíků open-source softwaru pochází z doby, kdy fuzzing ještě běžný nebyl.

OSS-Fuzz

Společnost Google koncem roku 2016 spustila projekt OSS-Fuzz, aby rozšířila automatický fuzzing jako nejlepší praxi při vývoji open source. Vývojáři musejí sestavit nezbytnou testovací infrastrukturu, poskytnout vstupní body pro spuštění fuzzeru a jednoduchý automatizovaný proces sestavování. Poté mohou svůj projekt předložit k zařazení do OSS-Fuzz. Jakmile je přijat, systém Google ClusterFuzz na projektu provede rozsáhlý fuzzing s vícero nástroji.

Veškerá zjištěná selhání se zaznamenají ve vyhrazeném nástroji pro sledování problémů, aby se zabránilo předčasnému odhalení potenciálních bezpečnostních problémů a správci projektu jsou upozorněni o nálezu. Jakmile je oznámena oprava problému, ClusterFuzz automaticky ověří, zda oprava funguje.

OSS-Fuzz nezklamal. První oznámení projektu zahrnovalo nově zjištěné přetečení zásobníku haldy v knihovně vykreslování písem FreeType, která je široce používána na různých platformách. Dne 8. května 2017 Google oznámil, že OSS-Fuzz identifikoval přes tisíc chyb s 264 možnými bezpečnostními zranitelnostmi. Projekt dodnes zaznamenal více než 3500 opravených nálezů.

Chyby zjištěné pomocí fuzzingu jsou nejčastěji v softwaru, který čte složité vstupní formáty a zpracovává je ve více krocích, zvláště když toto zpracování zahrnuje manipulaci se spoustou paměti a matematiky. Existuje pouze několik typů softwaru, které tomuto popisu odpovídají lépe než video, zvukové či obrazové kodeky, takže není překvapením, že zjištění OSS-Fuzz jsou soustředěna v multimediálním softwaru, jako je FFmpeg. Dalším stěžejním zdrojem nálezů je LibreOffice, ve kterém OSS-Fuzz našel 90 potvrzených chyb.

Chyby při manipulaci se vstupy, které byly nalezeny díky fuzzingu, bývají nejzávažnější v případě softwaru, který často zpracovává nedůvěryhodné vstupy. Kryptografická knihovna GnuTLS se často používá k zabezpečení síťové komunikace, což je typický příklad nezabezpečeného vstupu. Od jejího zařazení do OSS-Fuzz bylo nalezeno již 41 chyb. V OpenSSL byly tři chyby a jedna, která vyústila v CVE 2017-3735.

Za ještě působivější než portfolio nalezených chyb se dá považovat zásluha OSS-Fuzz na zavedení automatizace na vysoké úrovni do fuzzingu open-source projektů. Možnost automatického testování na infrastruktuře Googlu usnadňuje open-source projektům zavádění testování tohoto druhu. OSS-Fuzz je dnes stále ve verzi beta, ale pokrývá asi 110 projektů a aktivně se zapojuje stále více dalších.

Projekt Fuzzing

Open-source přispěvatel Hanno Böck zvolil jiný přístup k posilování bezpečnosti open source skrze fuzzing. Byl frustrovaný tím, co viděl v mnoha open-source projektech:

Pokud teď sáhnete po nahodilém linuxovém nástroji, který provádí zpracování souborů, a použijete na něj fuzzing, je docela pravděpodobné, že téměř okamžitě narazíte na nějaké segfaulty. To je celkem bezútěšný stav.

Následně spustil Fuzzing Project. Kromě toho, že zpřístupňuje nové návody k fuzzingu, provádí fuzzing na několika populárních open-source balíčcích a hlásí výsledky zpět do těchto projektů. Závěry jsou také prezentovány v podobě jednoduchých reportů, které ukazují, jak dobře si projekty během fuzzingu vedly.

Některé z nejzajímavějších nálezů projektu Fuzzing jsou ty, které byly nahlášeny správcům testovaného projektu, ale nebyly vyřešeny. Například běžný archivační nástroj cpio obsahuje zjevnou chybu při zápisu mimo příslušný rozsah, která představuje potenciální hrozbu, ale projekt GNU pcio se nyní téměř nevyvíjí a chyba nebyla vyřešena. Kalkulačky bc a dc z projektu GNU jsou v podobné situaci.

Co je podstatnější, projekt Fuzzing vedl k opravám a třem přiřazeným číslům CVE v knihovně pro kódování mezinárodních názvů domén libidn, půl tuctu chyb v knihovně pro vykreslování PDF Poppler a problémům spojeným s analýzou souborů v OpenSSH. Vícero chyb bylo nalezeno a opraveno nástroj file, což je zvláště důležitá oblast pro testování bezpečnosti, protože uživatelé Linuxu pravděpodobně spustí file na jakýchkoli neobvyklých datech, na která narazí.

Práce na stabilitě a bezpečnosti

Na první pohled to vypadá, že fuzzing slouží hlavně jako nástroj pro testování stability okrajových případů, nalezení pádů v extrémně abnormálních situacích. Nicméně mnoho významných bezpečnostních zranitelností je nejprve objeveno jako drobné chyby. U softwaru, který je stabilnější, je méně pravděpodobné, že se dostane do výjimečných situací, pro které nebyl navržen a testován, což přímo vede ke zlepšení bezpečnosti.

       

Komentáře