V dnešním světě agilního vývoje softwaru a rychlých cyklů vydávání nových verzí vývojáři při práci stále více spoléhají na knihovny a komponenty třetích stran. Protože mnoho z těchto knihoven pochází z dlouhodobých open source projektů, vývojáři často předpokládají, že jde o dobře napsaný bezchybný kód. Ale mnohdy se mýlí.
Hlavní záplatovací úsilí vyvolané chybami, jako Heartbleed (krvácení srdce), Shellshock či Poodle z poslední doby, slouží jako ukázky důsledků kritických chyb zabezpečení v kódu třetí strany. Chybami postižený software běžící na serverech, ve stolních počítačích, mobilních zařízeních a hardwarových řešeních ovlivňuje miliony spotřebitelů a firem.
Tyto vysoce medializované chyby zabezpečení však nebyly ojedinělými incidenty. Podobné chyby byly zjištěné v knihovnách, jako OpenSSL, LibTIFF, libpng, OpenJPEG, FFmpeg, Libav a bezpočtu dalších, a našly si během let cestu do tisíců produktů.
Jedním z důvodů, proč tyto chyby skončí v hotových produktech, je víra vývojářů, že jimi použitý kód třetích stran je bezpečný, protože ho už použilo mnoho lidí.
Mýtus nevýznamných chyb
„Existuje mýtus, že je open source software bezpečnější, protože ho může každý zkontrolovat a více očí zajistí, že zůstanou jen nevýznamné chyby,“ připomíná Jake Kouns, ředitel zabezpečení informací ve společnosti Risk Based Security, která se specializuje na sledování chyb zabezpečení.
„Skutečností je, že zatímco všichni mohou zkoumat kód, nedělají to a odpovědnost za kvalitu je zpožděná. Vývojáři a firmy používající knihovny třetích stran nevyhradí vlastní prostředky na testování bezpečnosti kódu někoho jiného. Ať už je to dobře nebo špatně, všichni si myslí, že chyby v zabezpečení najde někdo jiný a že publikovaný kód je bezpečný,“ dodává Kouns.
Skutečností je, že mnoho open source projektů, a to i ty, které produkují kód rozhodující pro internetovou infrastrukturu, je často špatně financovaných, potýkají se s nedostatkem lidských zdrojů a nemají ani zdaleka dostatek prostředků na zaplacení profesionálních auditů kódu nebo pracovní lidské síly, která by se zapojila do masivního přepisování starého kódu.
OpenSSL je významným příkladem takového případu, ale není zdaleka jediný. Poté, co došlo k oznámení kritické chyby Heartbleed v dubnu loňského roku, vyšlo najevo, že projekt OpenSSL měl jen jednoho vývojáře pracujícího na plný úvazek a že projekt byl primárně financovaný jako zakázková práce, kterou dělali ostatní členové týmu ve svém volném čase pro společnosti s potřebou expertizy SSL/TLS.
Vývojáři OpenBSD kritizovali OpenSSL za používání starého kódu pro platformy, o které se zajímá málo lidí, a rozhodli se udělat „fork“ projektu a vytvořit čistší verzi knihovny s názvem LibreSSL.
Chyby v open source knihovnách jsou často důsledkem jednoho nebo více z následujících důvodů: starý kód nebo nízká zralost kódu, nedostatečný audit a nedostatečné „fuze“ testování (procesem hledání chyb zabezpečení automatickým zadáváním neočekávaného vstupu do aplikací) a příliš málo udržovatelů, uvádí Carsten Eiram, ředitel výzkumu společnosti Risk Based Security.
„Vidíme, že mnoho chyb zabezpečení v těchto knihovnách výzkumníci najdou jen spuštěním nejnovějších fuzzerů, takže je to často něco, co mohli udržovatelé či společnosti používající uvedené knihovny udělat sami. Dodavatelé softwaru rychle implementují knihovny do svých produktů, ale jen zřídka předtím udělají audit, nebo dokonce fuzz, ani nepomáhají v jejich údržbě,“ podotýká Eiram.
Je to všechno marketing
Chyby zabezpečení typu Heartbleed zvedly zájem mezi vývojáři softwaru a správci systémů částečně z důvodu velké pozornosti, jaké se chybám dostalo v médiích. Někteří dodavatelé stále nacházejí produkty ovlivněné těmito chybami a vydávají pro ně opravy – tedy řadu měsíců po jejich prvním oznámení...
Tento příspěvek vyšel v Security Worldu 1/2015. Oproti této on-line verzi je výrazně obsáhlejší a přináší další poznatky a tipy, které lze využít v praxi u vás ve firmě.
Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.