Jak vzniká "záplata"

Autor: Vítek Karas, Senior Software Development Engineer, Microsoft

Kolem nedávné opravy chyby v Internet Exploreru se vedou rozsáhlé diskuze. Někteří si stěžují, že to Microsoftu trvalo moc dlouho chybu opravit, někteří chválí Microsoft za rychlou reakci. Zde je alespoň částečné rozkrytí toho, co všechno se musí stát, aby nová záplata spatřila světlo světa.

Zjištění potenciální zranitelnosti
Existuje mnoho kanálů, kterými se Microsoft může dozvědět o případné zranitelnosti v některém z našich produktů. Většinu chyb najde Microsoft sám, o některých se dozví od partnerů nebo bezpečnostích výzkumníků tzv. "white hats" a v nejhorším připadě se objeví veřejný útok na danou chybu ("zero day attack"). Jen pro zajímavost, Microsoft zaměstnává celkem početnou skupinu hackerů, kteří se snaží heknout vše, co vyjde z MS kuchyňky. Všechny tyto připady, kdy je potencionálně ohrožena bezpečnost zákazníků, jsou od začátku zpracovávány ve specielním týmu Microsoft Security Response Center (MSRC) a tento tým je zodpovědný za celý proces od reportu chyby až po uvedení aktualizace.

Tato skupina určí (ve spolupráci s produktovým týmem) jak závažná je daná chyba a tím i jak brzo je nutné vydat záplatu. Vždy se jedná o zvažování zda je důležitější opravit chybu co nejdříve a nebo je možné strávit více času na kvalitě opravy a nalezení podobných problémů v jiných komponentách.

Vytváření záplaty
Prvním krokem je zjistit, zda existuje podobný problém i v jiné oblasti. Produktový tým se snaží v kódu najít podobný problém jak přímou revizí zdrojového kódu, tak testováním podobných scénářů. Cílem je opravit pokud možno všechny chyby najednou, aby zákazníci nemuseli instalovat několik záplat po sobě a zároveň zde nebyl dán prostor případným dalším útočníkům, kteří by na vydanou záplatu použili tzv. reverse-engineering.

Zároveň s vytvářením opravy, se MSRC pokouší najít možné způsoby, jak ochránit zákazníky dříve, než bude k dispozici záplata. Výsledkem tohoto zkoumání bývá sada doporučení zákazníkům a zároveň seznam napadnutelných konfigurací. Viz například tabulka opatření v tomto postu.

Jakmile je zjištěno, kde všude se daná chyba nachází, vytvoření vlastní opravy je obvykle velmi rychlé (v mnoha případech se jedná o hodiny, nebo jednotky dní). Opravu vždy vytváří produktový tým (skupina, která vlastní danou komponentu) a tato prochází prvním testováním uvnitř tohoto týmu. Zároveň se vytvoří vlastní záplata obsahující tuto opravu. Pro zajímavost, pro každou verzi a platformu OS je potřeba vytvořit záplatu zvlášť (až 30 různých).

Testování opravy
Fáze testování je ta část, která trvá ze všeho nejdéle. MSRC nepovolí zveřejnění opravy dokud nesplňuje velmi přísná kritéria, která zajišťují, aby oprava nezpůsobila nechtěné změny v chování daného produktu. Testování oprav do některých komponent se účastní mnoho různých produktových skupin. Například oprava v Internet Explorer, který je součástí několika verzí operačních systémů a je podporován ve 26 jazycích, je samozřejmě mnohem náročnější, než testování opravy v komponentě, která nemá tolik závislostí.

Testování významné opravy může vyžadovat i několik stovek lidí pracujích po několik týdnů. Testuje se vlastní oprava, komponenty, které na opraveném kódu zavisí a naopak komponenty, na kterých zavisí opravovaný kód. Ověřuje se kompatibilita aplikací, funkčnost instalátoru a další uživatelské scénáře. Při testování je potřeba ověřit funkčnost opravy na všech možných konfiguracích a verzích operačních systému a aplikací, kterou danou komponentu používají. Často je nutné vytvořit nové testy pro lepší pokrytí dané oblasti.

Ohlášení a vydání opravy
Jakmile je vše připraveno, MSRC vydá takzvaný „Security Bulletin“, článek informující o chybě a její opravě, a záplata s opravou je zpřístupněna na internetu. Zároveň je oprava přidána do systému Windows Update a automaticky distribuována na počítače zákazníků.

Security Bulletin obsahuje informace o dané chybě a stupni nebezpečí, které hrozí zákazníkům. Dále jsou zde uvedeny postupy, kterými může zákazník zabránit dané chybě, nebo alespoň snížit její závažnost. Tyto informace jsou důležité pro zákazníky při jejich rozhodování, jak rychle je potřeba danou opravu nainstalovat a jak velké je riziko oddalování instalace.

Méně závažné opravy jsou vydávány ve větších celcích každé druhé úterý v měsíci. Tento proces byl zaveden Microsoftem v roce 2003 jako reakce na žádosti zákazníků. Cílem je, aby se zákazníci mohli na opravy připravit a upravit procesy vedoucí k nasazení těchto záplat uvnitř jejich organizací. Zákazníci často potřebují ověřit, že instalace dané opravy nenaruší chod jimy použivaných aplikací a tak je vhodné, aby mohli ověřit několik oprav najednou než je nasadí do produkčního prostředí.

Závěrem
Jak MSRC, tak produktový tým, se po vydání opravy snaží zabránit, aby podobná situace nastala někdy v budoucnu. Často je stejný typ útoku vyzkoušen na ostatních komponentách, či produktech. Zjišťuje se, proč se daná chyba vůbec v kódu objevila a jak systémově zabránit dalším podobným chybám. Viditelným výsledkem těchto snah je Security Development Lifecycle (SDL). Je to sada pravidel a nástrojů, které dodržuje každá produktová skupina v Microsoftu. Cílem tohoto procesu je zbránit vzniku bezpečnostních problému již při vytváření produktu a jeho testování, tedy dlouho předtím, než se produkt dostane k zákazníkovi.

Pokud vás dané téma zaujalo doporučuji následující odkazy (v angličtině):

https://blogs.technet.com/msrc/archive/2007/04/03/an-inside-look-into-building-and-releasing-ms07-017.aspx - popis opravy jedné bezpečností chyby v Internet Exploreru.

https://www.microsoft.com/security/msrc/managing_vulnerabilities.mspx - Všeobecný popis postupu MSRC při opravách bezpečnostích chyb.

https://www.microsoft.com/technet/security/bulletin/revsbwp.mspx - článek o zavedení „záplatování každé druhé úterý v měsíci“.

https://msdn.microsoft.com/en-us/security/cc448177.aspx - Security Development Lifecycle a jak je možné podobný postup využít i pro váš produkt.