Látám, látáš, látáme...

Kde je zodpovědnost?
Chyba v programu zkrátka otevírá možnost totálního nekorektního přístupu nejen k této aplikaci, ale často i k jejím datům a/nebo k celému systému. Často umožňuje útočníkovi buď spustit předpřipravený škodlivý kód, nebo převzetí kontroly nad systémem.
Chyba v programu je využití stavu, kdy hacker uvažuje mimo tradiční rámec. Pokouší se najít/vyvolat situaci, která by za normálních okolností neměla nastat nebo by k ní neměl být důvod.
Zjednodušeně řečeno: pokud má nějaká proměnná mít délku osm znaků, hacker třeba zkoumá, co se stane, když ji zadá s deseti znaky. Správně (= bezpečně) napsaný program tuto vstupní hodnotu zkontroluje a odmítne, špatně napsaný provede pokus o zápis. To může mít různé důsledky: třeba přepsání dat v paměti za místem vyhrazeným pro onu osmimístnou proměnnou. Tím útočník získává přístup do míst, kam by ho mít neměl - a má napůl vyhráno. Toto je zjednodušený příklad velmi časté chyby buffer overflow (přetečení zásobníku), kdy se data dostanou mimo vyhrazenou oblast.
Přitom je zajímavé sledovat, jak se postupně měnil postoj k bezpečnostním aktualizacím a záplatám. (Podotýkáme, že nejde o nic nového pod sluncem a že záplaty na chyby v programech se vydávají od doby, co svět světem stojí - alespoň ten počítačový.) Výrobci se nejprve snažili existenci chyb popírat nebo ignorovat a opravovali je (v lepším případě) až s vydáním nové verze programu.
Situace se ale postupně stávala neudržitelnou, protože nešlo jen o stabilitu informačního systému a možnost korektní práce s ním, ale také o zajištění kontinuity práce (software, který tropí více škody než užitku, asi není tím pravým ořechovým, o co by zákazníci měli zájem) a o bezpečnost. Chyb v programech se obratně naučili využívat hackeři k svému prospěchu, a protože bezpečnostní technologie byly v plenkách, nebylo síly, která by je mohla zastavit.
Výrobci softwaru proto přišli s konceptem oprav chyb, čímž jednak vyšli vstříc potřebám zákazníků a jednak se zřekli zodpovědnosti (připustili chybu, vydali nástroj - a tím zodpovědnost přenesli na zákazníka). Postupem času se tak vyvinul celý obor řízení (procesu) záplatování (patch management), který studuje a řídí tuto oblast z hlediska časové náročnosti, potřeby lidských zdrojů, ekonomického přínosu apod.


Chyby, kam se podíváme
Chyby v počítačových programech jsou přitom jejich samozřejmou součástí - kdo někdy programoval, jistě to jen a jen potvrdí. Statistické ukazatele počtu chyb se rozcházejí: většinou se uvádí, že na tisíc řádků syrového (nevyzkoušeného) kódu připadá 5 až 20 chyb, ale třeba v knize Writing Secure Code autorů Michaela Howarda a Davida LeBlanca se uvádí průměrný počet padesáti chyb na tisíc řádků.
Přitom třeba operační systém Windows 3.11 měl cca tři miliony řádků programového kódu, Windows 95 už patnáct milionů a Windows 2000 kolem 35 milionů. Podobně měla typická instalace Linuxu v roce 1992 asi 170 tisíc řádků kódu, ale Red Hat Linux 7,1 z roku 2001 už měl třicet milionů řádků.
Drtivá většina chyb je nalezena a odstraněna při testování softwaru, ale určité procento přesto vždy zůstává i po vydání k veřejnému používání. Přitom právě proces bezpečného programování, hledání a nalézání chyb je pro vývoj každé aplikace klíčový, protože nejlepší problém je takový, který vůbec nenastane. V této souvislosti připomínáme iniciativu Trustworthy Computing společnosti Microsoft, kdy díky implementaci vzdělávacích a kontrolních mechanizmů došlo z dlouhodobého hlediska k poklesu počtu bezpečnostních problémů i jejich závažnosti.
Rozlišujeme několik druhů záplat:
n Záplata na zdrojový kód programu.
n Záplata kompilovaného binárního kódu.
n Náhrada kompletního souboru.
Záplata typicky obsahuje malou změnu, která má za cíl eliminovat jeden konkrétní problém. Bohužel to ale často není tak jednoduché, jak by se na první pohled mohlo zdát: drobná změna na straně jedné může přidat netušené problémy někde jinde. Porušuje se tak zásada všech informatiků na světě: "Když to funguje, tak se toho nedotýkej."
Pokud dochází k větším změnám, hovoříme o záplatách kumulativních nebo také o servisních balíčcích.


Životní cyklus zranitelnosti
Princip záplatování nejlépe pochopíme na sledování životního cyklu zranitelnosti. Ta nejprve musí být nějak vytvořena. Zpravidla ne-
úmyslně, ale jsou časté i případy, kdy k jejímu vzniku dochází záměrně - se zlým úmyslem buď někoho poškodit, nebo ji později zneužít ve svůj prospěch.
Platí zde přitom pravidlo: "Chyba, o které nikdo neví, jako by neexistovala." V počítačových programech zkrátka existuje ohromné množství chyb, které se při běžném provozu nikterak neprojevují a na které se tudíž nepřijde. A mnohé z nich zůstanou neodhalené i po podrobných analýzách hackery nebo bezpečnostními specialisty.
Takovéto chyby nás ale netrápí. Největší nebezpečí představují chyby, o kterých ví jen útočník (nebo by se také dalo říci: o kterých ví kdokoliv, jen ne my). Právě proto je zapotřebí mít kvalitně zpracovanou politiku patch managementu (viz dále).
Tím jsme se v životní fázi bezpečnostní chyby dostali do dalšího stadia, do stupně objevení. K němu může dojít buď náhodně (studiem neobvyklého chování systému), nebo záměrně (aktivním hledáním). Velmi přitom záleží na tom, kdo chybu objevil. Ideální je, když na ni přijde přímo výrobce - a v tichosti vydá záplatu (nebo opravu nenápadně přidá k jiné záplatě). Tímto vůbec neobhajujeme utajování chyb. Ale musíme si uvědomit, že chyba, o které útočníci neví, není zneužitelná. To je častý problém zveřejňování informací o chybách: na jedné straně tyto informace mohou posloužit (a primárně slouží) k dobrým účelům, ale bohužel také bývají zneužívány k útokům.
Po objevení následuje oprava chyby. Každá chyba je svým způsobem unikátní, proto vyžaduje určitý přístup. Stejně tak různí výrobci vyznávají různé politiky aplikace záplat - někdo vydává záplaty "jak to jde", jiný čas od času v pravidelných intervalech, jiný dává přednost vydávání celých nových verzí programu...
Po opravě následuje publikování záplaty. Pro mnoho výrobců přitom právě v tomto okamžiku práce končí, ale to je chyba! Proč? Protože pouhým publikováním záplaty nedochází k vlastnímu záplatování zranitelných systémů. Je zapotřebí mít vypracovaný celý systém varování postižených a implementace záplat.
Souběžně s životním cyklem zranitelnosti nastává někde po okamžiku odhalení i to, že dojde ke skriptování zranitelnosti. Jinými slovy: je vytvořený automatický kód, který tuto zranitelnost dokáže zneužít. Tímto úkonem dramaticky roste pravděpodobnost, že zranitelnost bude masově zneužívaná.
V závěrečné fázi životního cyklu zranitelnost odumírá, a to buď díky tomu, že většina systémů je proti ní ošetřena - nebo prostě proto, že systémy ji obsahující jsou technicky i morálně zastaralé. I kritická zranitelnost ve Windows 3.11 nebo Windows 95 nás asi dnes nechá zcela chladnými... Navíc s ošetřením všech systémů to často nebývá tak slavné a třeba po přeinstalování počítače či serveru se na některé aktualizace zapomíná, takže zranitelnost se periodicky vrací jako kostlivec ze skříně. Příkladem budiž třeba chyba MS01-033 umožňující šíření internetového červa CodeRed (poprvé zaznamenaný v červenci 2001): stále znovu a znovu se vyskytují na světě nezáplatované servery, které slouží k udržování tohoto kódu při životě...
Současné trendy v oblasti zranitelností jsou jednoznačné:
n Jejich počet roste. Rok od roku se objevuje čím dál tím více chyb pro čím dál tím větší počet platforem.
n Jsou zneužívány častěji. Stále větší počet útoků využívá ke svému vstupu do systému právě různých chyb, četnost zneužívání zranitelností tak roste.
n Jsou zneužívány rychleji. Výrobci i uživatelé mají čím dál tím méně času na podniknutí protiopatření, protože zranitelnosti jsou zneužívány stále rychleji.


Správné záplatování
Přístup "mám všechny záplaty, jsem tedy v bezpečí" svoji železnou logiku sice má, ale to ještě neznamená, že je správný. Důvodů je více.
Týdně se objevují stovky nových bezpečnostních problémů a čím dál tím více se šíří zero-day útoky (útoky nultého dne, kdy je zranitelnost zneužita bezprostředně po objevení, oznámení nebo vydání opravy - tedy v době, kdy prakticky žádné systémy nejsou chráněné). Obecně se zkracuje i doba mezi oznámením a zneužitím zranitelnosti, ale těžko se podaří pod určitou hranici zkrátit vydávání záplat (identifikace problému, programování, testování, distribuce). Z toho vyplývá jedna nepříjemná skutečnost: každý systém je nějaký čas nezáplatovaný.
Proto je zapotřebí počítat nejen se záplatami, ale i s tzv. workarounds (ošetřeními). Jedná se o různá jednoduchá opatření, s jejichž pomocí bývá možné problém eliminovat. Pokud se např. objeví zranitelnost v nějaké službě, je možné tuto službu dočasně vypnout nebo omezit - a tím ochránit systém před útokem. Pochopitelně, že je vždy zapotřebí hledat kompromis mezi zajištěním bezpečnosti na straně jedné a zajištěním kontinuity činnosti organizace na straně druhé. Nicméně většina chyb má ošetření takového charakteru, že se běžného provozu organizace nedotknou.
Ani se záplatami to není tak jednoduché, jak by se na první pohled mohlo zdát ("co nejdříve nainstaluj a pusť z hlavy"). Čím větší síť, tím větší mohou být dopady každého zásahu - včetně nepovedené aktualizace. Přestože se výrobci snaží záplaty co nejvíce testovat, přece jen jde při jejich vydávání o čas, takže jsou zkoušky redukované na nejnutnější možnou míru. Kromě toho největším testem jakékoliv aplikace je vždy až reálné prostředí, protože každý systém je unikátní kombinací hardwaru, softwaru, jejich nastavení, zvyklostí uživatelů i správců apod.
Dostáváme se tak k tzv. záplatovacímu paradoxu: "Bez záplaty je systém náchylný k problémům s bezpečností, s ní k problémům se stabilitou." Jinak by se také dalo říci, že proti sobě stojí hrozba průniku a hrozba chybné záplaty. Bohužel, záplata záplaty je ve světě ICT velmi častým jevem. Proto zvláště ve velkých systémech je dobré záplaty testovat na nějakém zkušebním prostředí - což jen dává vyniknout nutnosti instalovat výše zmíněná ošetření.
Platí zde přitom nepřímá úměrnost: zatímco pravděpodobnost zneužití neošetřené zranitelnosti v čase roste, pravděpodobnost problémů způsobených špatnou záplatou klesá (protože už ji stihlo otestovat více subjektů).
Ostatně i norma ISO/IEC 17799 zdůrazňu-
je, že: "Bezpečnost dosažitelná prostřednictvím technických prostředků je limitovaná a musí
být podpořena odpovídající řízením a procesy."
Na tomto místě se podívejme, jak záplatování řeší jednotliví světoví výrobci. Podotýkáme ovšem, že mezi bezpečnostními specialisty panuje v této oblasti obdivuhodná neshoda na tom, jakým způsobem by záplatování mělo probíhat, jak často, kdy je optimální čas na instalaci záplaty apod. Což jen svědčí o tom, jak složitá tato oblast je. A že ji není radno zjednodušovat.
Microsoft má své druhé úterky v měsíci, Oracle zase čtvrtletní vydávání aktualizací. Na pravidelný měsíční cyklus chce přistoupit také Adobe. Pravidelnost aktualizací je nesmírně příjemná pro administrátory, kteří si mohou naplánovat některé úkony, využití sítě apod. Navíc umožňuje snižovat počet záplat jejich kumulací do menšího počtu. Na straně druhé ale zde může být otazník z hlediska bezpečnosti: na záplatu se mnohdy čeká týdny nebo je naopak uvolňována ještě "syrová". Jak ale bylo uvedeno výše, v této oblasti nepanuje ohledně ideální koncepce shoda - pokud ji vůbec lze nalézt...
Jen pro zajímavost připomínáme "velký záplatovací den" - 12. červenec 2005, kdy své aktualizace vydaly zároveň společnosti Microsoft, Oracle, Adobe a Mozilla. Jejich produkty jsou přitom hojně používané, takže nutnost záplatování všech čtyř najednou nebyla nepravděpodobnou kombinací...


Problémy se záplatami
Prvním problémem se záplatami bývá nehomogenní prostředí. Dnes je zapotřebí aktualizovat nejen operační systém, ale i používané aplikace - prostě veškerý software. Třeba Microsoft má z hlediska záplatování velmi solidní řešení, které ale neumožňuje aktualizovat software třetích stran. Problémem pak bývá skutečnost, že v jedné síti je zapotřebí mít a spravovat několik záplatovacích politik a prostředí.
Kromě této nehomogenity může působit potíže i velké množství záplat: vydávání opravy pro každou nekritickou maličkost nebo právě záplaty od mnoha různých dodavatelů.
Výše jsme už zmínili nepredikovatelné chování záplaty. Jejím hlavním a jediným úkolem by mělo být odstranění zranitelnosti. Nic více a nic méně. Jenomže v praxi dochází jednak ke vzniku zranitelností nových, jednak k narušení stávajících vazeb a služeb. Zdánlivě nevinná úprava může mít v konkrétním systému dalekosáhlé důsledky.
Kromě toho je tu i problém v tom, že některé záplaty jsou konstruované tak, že na sebe navazují. Prostě úspěšná instalace určité záplaty vyžaduje, aby na software již dříve byla instalována záplata jiná. Nedej bože, když dochází k instalaci několika takovýchto záplat po sobě a některé vyžadují i restart... Tento problém mohou řešit třeba servisní balíčky nebo kumulativní záplaty.
Další v praxi častou potíží je obtížné získávání záplat - jak jsme již uvedli výše, pro mnohé výrobce vše končí vystavením záplaty na web. Netrápí je třeba to, že se uživatel záplaty o jejím vydání nedozví - nebo že krátkodobě vzroste provoz na serveru tak, že se záplata prostě nedá stáhnout. A to je špatné: zodpovědnost výrobce by měla končit až v okamžiku instalace záplaty na postižený systém. Mnozí argumentují, že další osud záplatování nemohou ovlivnit. To ale není pravda, protože příklady jiných dodavatelů svědčí o tom, že podobný systém vytvořit lze. Stačí jen chtít - a brát ohled na potřeby zákazníků (kteří by se měli věnovat své hlavní činnosti a nikoliv vynakládat nehorázné prostředky na zajištění záplatování).
Dalším problémem může být nelegální nebo neregistrovaný software. Třeba Oracle nebo Solaris vyžadují pro zpřístupnění záplat (de facto po opravení svých chyb) zakoupit nějakou formu podpory. Stejně tak nemají nelegální uživatelé především operačních systémů přístup k oficiálním záplatám, takže musí na internetu pokoutně využívat pochybné zdroje. Typickým příkladem nebezpečného softwaru může být servisní balíček SP3 pro Windows XP, který dosud Microsoft nevydal - ale který je na internetu k dispozici v desítkách podob (primárně slouží k zavirování postižených systémů).
V neposlední řadě musíme jako problém zmínit i skutečnost, že některé záplaty jsou velmi objemné. A pokud se týkají třeba koncových stanic, jejich distribuce může být zvláště v rozsáhlých systémech problém.


Několik slov závěrem
Záplatování není jednoduchý proces. Má-li být úspěšné a účinné, musí mít hlavu a patu. Ač mnoho skutečností ovlivnit nemůžeme, mnohé v našich rukách je: třeba výběr vhodného softwaru (operační systémy, aplikace, patch management...), nastavení politiky, další bariéry pro útočníky (systémy IDS a IPS apod.).
Pouze tak se totiž nedostaneme do stavu s nadsázkou označovaného "patch-and-pray". Záplatuj a modli se.


Historická exkurze

Pojem "patch management" se poprvé objevil na Usenetu v roce 1992, ale nešlo o nikterak novou činnost. Už v prehistorických dobách výpočetní techniky se totiž vydávaly opravy programů na děrných štítcích.
Historicky je doloženo, že v roce 1985 napsal jistý Larry Wall software pro automatické záplatování unixových systémů. To svědčí o faktu, že ho záplatování obtěžovalo a že nešlo o jednorázový úkon. V roce 1993 se objevilo první automatické záplatování vestavěné v operačních systémech. O čtyři roky později nechalo americké Ministerstvo energetiky vytvořit pro svoji potřebu automatický záplatovací systém, protože záplatování jen operačních systémů přestalo dostačovat.
V roce 2003 pak záplatování představovalo samostatné průmyslové odvětví s nevelkým, ale dramaticky rostoucím celosvětovým obratem osmdesáti miliónů dolarů.

Malý slovníček pojmů

Zranitelnost - slabina systému, která může být zneužita hrozbou.
Hrozba - podle IEC/ISO 13335-1 jde o "potenciální příčinu nechtěného/nežádoucího dopadu na systém nebo organizaci".
Exploit - proces nebo nástroj, jehož prostřednictvím je realizovaný útok na systém. Jinými slovy: jeho pomocí dochází k praktické realizaci hrozby.
Záplata (patch) - kus dat, použitý k aktualizaci softwarového produktu. Bezpečnostní záplata je změna aplikovaná s cílem odstranit slabinu popsanou ve zranitelnosti.


Pár zajímavých čísel
V roce 2006 uskutečnila společnost McAfee celoevropský průzkum týkající se zranitelností a jejich implementace. Z něj mimo jiné vyplynulo, že:

45 % organizací je přesvědčeno, že nikdy nemají sto procent záplat.
27 % organizací má politiku takovou, že je chráněno před nějakou chybou do 48 hodin po zveřejnění záplaty.
19 % přiznává, že ochrana před zranitelností jim zabere více než jeden týden od okamžiku zveřejnění.
36 % organizací není schopno dohledat, kolik a jakých záplat aplikovalo za posledních šest měsíců.
58 % organizací vůbec netuší, jaké náklady jsou s procesem záplatování v jejich případě spojené.
45 % nemá stanoveno priority v záplatování.
82 % je přesto spokojeno se stávajícím stavem záplatování ve své organizaci.


Řeč statistik

Podle statistik organizace CERT bylo v roce 2005 objeveno celkem 5 990 nových zranitelností, v roce 2006 už jich bylo 8 064 (což představuje meziroční nárůst o 35 procent). Podle statistik zpracovaných organizací Secunia bylo v roce 2005 jen 4 565 nových zranitelností, v roce 2006 jich bylo 5 128 (nárůst o 12 procent). Rozdíl v těchto číslech je daný použitím různých metodik, jejichž (ne)přesnost se pochopitelně dá napadnout. Nicméně těžko se bude napadat obecný trend: počty zranitelností rostou...