Nedávno se ve full-disclosure mailing-listu objevila zpráva o heap-overflow zranitelnosti v parsování ASN.1 v OpenSSL. Zranitelnost je složena ze dvou částí:
- Při konverzi long -> int na x86_64 architektuře dochází k ořezání nejvyšších 32 bitů, výsledek se uloží do 32-bit integeru se znaménkem. Použitím DER-enkódovaného certifikátu, který má nějaký length-field s bitem 32 nastaveným, dojde k přetečení do záporných čísel.
- Funkce realloc() podle C99. standardu musí umět jak paměť alokovaného bloku zvětšit, tak zmenšit. Problém spočívá v tom, že obdobná funkce CRYPTO_realloc_clean() v OpenSSL nepodporuje zmenšení bloku. Pokud je nová délka alokovaného bloku menší než původní délka, část paměti za alokovaným bufferem se přepíše bajty navíc z původního bloku.
Kombinací obou chyb lze část paměti přepsat „speciálně formovaným“ certifikátem. Chybu je poměrně těžké zneužít, ale rozhodně to není nemožné. Týká se funkcí pojmenovaných d2i_*_bio a d2i_*_fp (a pár dalších pracujících s CMS a S/MIME).
Zatím probíhá šetření, který software používající OpenSSL je chybou ovlivněn. V tuto chvíli jsou chyby s největší pravděpodobností vyloučeny u:
- OpenSSH – používá vlastní kód pro parsování ASN.1
- Tor – používá in-memory d2i_* a PEM_* funkce, žádné z napadnutelných
- DNSSEC Validator – ASN.1 parsování se vůbec nepoužívá
- dslib – openssl se vůbec nepoužívá, ASN.1 parsování dělá pyasn1
- datovka – potenciálně zranitelná funkce OpenSSL.crypto.load_pkcs12 se nachází jen u načtení vašeho certifikátu z disku (tudíž dokud ho někdo nezmění, nic se nestane; navíc používá se jenom při přihlašovaní certifikátem)
- Knot DNS 1.0.3 – žádná zranitelná funkce se nevolá
- Firefox 11, Thunderbird 11.0.1 (komponenty NSS, NSPR a XulRunner) – Firefox i Thunderbird mají ale spoustu závislostí; je teoreticky možné, že jsem něco přehlédnul
- Apache 2.4.2, nginx 1.0.15 a 1.1.19, lighttpd 1.4.30 – používají některé ze zranitelných funkcí, ale jenom při čtení certifikátů z disku
Další pár očí pro kontrolu samozřejmě neuškodí. Statickou analýzou kódu jsem vytvořil call-graph a regexp, kterým lze ověřit, jestli nějaký kód volající funkce openssl používá potenciálně zranitelné funkce. Bugy jsou opraveny ve verzích openssl 1.0.1a, 1.0.0i or 0.9.8v. Jeden způsob, jak zmírnit dopad chyby v openssl (i budoucí), je použití stunnel v jail-u, ale má to některé další nevýhody jako těžší zpracování logů.
Další zajímavý fakt je, že tato konkrétní chyba (bez části o realloc()) byla publikována v roce 2006 v knize The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Zde je fotografie stránek se zmíněnou chybou (konverze long -> int). Nicméně to není první ani poslední „znovuobjevený“ bug v softwaru.
Ondrej Mikle
Jak by měla vypadat podpora IPv6
Před několika dny vyšel v IETF soupis požadavků pro podporu IPv6 v zařízeních (BCP 177 známé také jako RFC 6540). Cílem tohoto soupisu je vyřešit problém slepice nebo vejce pokud možno přirozenou cestou. Jak je zmíněno v první části, IPv6 je tu s námi už celkem dlouho, ale většina výrobců síťových zařízeních ho stále bere spíše jako volitelnou součást, než jako základní funkcionalitu. Tento přístup je nejvíce patrný v segmentu zařízení určených pro domácnosti. Zde se výměna hardware řeší až v okamžiku, kdy ten současný doslouží (tady nelze očekávat hromadný nákup nových modemů a routerů jen pro IPv6). Samotný dokument obsahuje pět doporučení, kterými by se měli výrobci řídit:
- nové implementace IP musí obsahovat podporu pro IPv6
- aktualizace stávajících implementací by měly podporovat IPv6
- podpora IPv6 musí být srovnatelná nebo lepší, než podpora IPv4
- nové a aktualizované implementace by měly podporovat souběh IPv4 a IPv6 (dualstack) a nesmí mít IPv4 jako podmínku pro svůj běh
- implementátorům se doporučuje aktualizovat software a hardware pro podporu IPv6, pokud je to možné.
Hlavně třetí bod je v současné době zanedbáván. I když se zařízení chlubí podporou IPv6, může nastat situace, kdy je například firewall funkční pouze pro IPv4 a pro IPv6 jsou k dispozici jen dvě záložky nastavení základních parametrů. Zajímavé bude také sledovat, jak se výrobci vypořádají s bodem čtyři, který znamená možnost běhu v IPv6 only síti (pokud máte pocit, že to vaše zařízení zvládne, můžete navštívit naši IPv6 laboratoř a vyzkoušet to v praxi). Ačkoliv poslední bod by nám měl dávat naději na lepší stav IPv6, uvidíme, jak to bude vypadat v praxi a zda výrobci vydají aktualizace s podporou IPv6 k již existujícím zařízením.
Zbývá jen doufat, že tyto doporučení vezmou výrobci za svá a na trhu se objeví dostatek domácích routerů a modemů s podporou IPv6. Odstranila by se tak jedna z překážek pro zavedení IPv6, případně by byla odstraněna v rámci přirozené výměny dosluhujících zařízení.
Petr Černohouz
Ohlédnutí za IETF 83
Jelikož jsem v předchozích dvou blogpostech o OpenID a WHOISu nalákal čtenáře na IETF 83, sluší se přinést nějaký report o tom, jak tato konference splnila očekávání. Dá se říct, že více než dostatečně.
Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.
Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.
Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.
Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.
A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.
Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.
Jaromír Talíř
Třeba nás čtou i na školách (ne snad povinně) – AKTUALIZOVÁNO
V rámci našich osvětových aktivit se snažíme objíždět české střední školy s prezentacemi o internetu a doménách, o DNS a DNSSEC, o mojeID, IDN nebo třeba IPv6. Před několika lety jsme v této souvislosti začali spolupracovat i s Jednotou školskych informatiků, z čehož se po čase zrodila možnost uspořádat takové školení i pro samotné kantory (dostali jsme na něj i akreditaci od MŠMT). První a druhý běh tohoto kurzu se uskutečnil před dvěma lety a na obou dohromady se sešlo ke 40 zájemců, tedy poměrně dost. A tak jsme ho letos oprášili a ve spolupráci s JSI vypsali jeho pokračování. Přeci jen, za dva roky se toho v mnohém dost změnilo.
Jednodenní vzdělávací (čti informativní) kurz pro učitele IT předmětů na gymnáziích, středních a vyšších odborných školách se uskuteční v naší akademii 14. června. Pásmo se bude skládat z přednášek o tom, jak funguje internet, jak je to s doménami a s přechodem na IPv6, co je DNS, DNSSEC, IDN nebo mojeID. Chybět nebude ani část o projektech, které v CZ.NIC pro školy a jejich návštěvníky připravujeme, nebo diskuse na závěr o tom, co by od nás pedagogové uvítali.
Tento kurz je pro pedagogy, a to zdarma. Doporučujeme proto přihlásit se co nejdříve, aby bylo ještě místo. V případě, že se utrhne lavina zájmu a my budeme zahlceni přihláškami (na to se v duchu těšíme :)), vypíšeme samozřejmě náhradní termín. Jestli nás tedy čtete i na školách a tato nabídka vám přijde zajímavá, neváhejte a přihlaste se. Čas máte do 14. května včetně. Pokud máte kolem sebe kolegy, které by to všechno kolem internetu mohlo zajímat, dejte jim vědět nebo je rovnou přihlaste.
A pro vás ostatním, kterým jsou už školní lavice malé. Měli byste o takové jednodenní posezení zájem? Dejte nám vědět v komentářích, jestli se máme myšlence zařadit takový kurz do naší nabídky dále věnovat. Přeci jen, do akademie jsou zvyklí chodit spíše odborníci s praxí. V tomto případě jde jednoznačně o kurz méně odborný.
Aktualizováno 12. dubna 2012:
Protože se tato nabídka setkala s dobrou odezvou, otevřeli jsme ještě jeden běh tohoto kurzu; ten je od dnešního dne vypsaný na 31. května. Pokud mě ale dosud někdo nepředběhl, na 14. června jsou ještě dvě nebo tři místa volná. Zájem účastníků nás velice těší.
Vilém Sládek
UnoDNS – začátek konce jednotného internetu?
Také jste byli naštvaní, když vám některá webová služba odmítla přístup s tím, že nejste ze „správného“ geografického regionu? Takovýto pohled nepotěší asi nikoho…
Zkoušeli jste různé proxy či VPN a zjistili, že reálně se nedají používat, protože jsou pomalé? Nedávno se objevila nová služba UnoDNS, která o sobě tvrdí, že problémy s proxy či VPN vyřešila a že Hulu, Netflix a další streamované služby či kanály vám poběží bez problémů. Dokonce i recenze služby to potvrzují.
Je tu ale jeden háček. Musíte si změnit nastavení DNS a začít používat servery UnoDNS. Ty filtrují dotazy do DNS pro domény podporovaných služeb a mění odpovědi. Běžná odpověď pro www.netflix.com:
www.netflix.com is an alias for wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com.
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.185.102
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.186.229
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.187.142
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.188.229
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.184.243
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.185.50
A stejná odpověď při použití UnoDNS:
www.netflix.com is an alias for wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.21.96.127
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.99.64
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.20.232.200
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.103.125
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.20.137.117
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.119.154
A právě tady je jádro možného problému. Co když nebudou filtrovány jen záznamy služeb pro streaming videa, ale i něco jiného? Ani bychom to nezjistili, protože kdo z nás si po několika týdnech vzpomene, že jsme změnili nastavení DNS kvůli poslední epizodě seriálu, kterou jsme chtěli vidět. Nejsme zde dokonce svědky konce doposud běžné praxe používání DNS našich ISP a začátku fragmentace na používání různých DNS poskytovaných někým jiným? Pokud ano, zřejmě nás čeká situace, kdy každý z nás uvidí „jiný Internet“ právě podle toho, jaké DNS servery používáme. Případně si budeme mezi těmito „různými Internety“ přepínat podle uvážení. Žádná lákavá představa ani v jednom případě …
PT
FREDovo dopoledne na ICANN 43
V souvislosti s posledním setkáním ICANN bychom chtěli ještě v krátkosti zmínit události, které v Kostarice potkaly náš registrační systém FRED.
Správci národních domén jsou v rámci ICANN seskupeni v organizaci ccNSO, a to proto, aby při prosazování svých zájmů mluvili pokud možno jedním hlasem. První den celé konference má tradičně tato organizace svůj „TechDay„, na kterém reprezentanti jednotlivých registrů ukazují produkty ze svých „kuchyní“; tady bychom mohli s trochou nadsázky říct, že první polovina dne patřila FREDovi. Shodou okolností totiž po sobě prezentovali technická řešení svých registrů nejprve Estonci, potom Kostaričani a nakonec zástupci Faerských ostrovů. Příjemné pro nás bylo zjištění, že nám FRED neudělal ani v jednom případě ostudu.
V průběhu týdne jsem měl ještě možnost prodiskutovat náš systém s ředitelem registru Rwandy. FREDa mají nasazeného v testovacím provozu a čekají na převedení domény .rw do jejich správy. Kolegové ze zmíněných registrů udělali FREDovi skutečně dobrou reklamu. Krátce po skončení konference se mi totiž ozval správce domény ostrovů Komoro (.km), že zvažují využití systému pro jejich technické řešení.
I s ohledem na tyto události zvažujeme uspořádat v rámci červnového setkání ICANN v Praze specializovaný workshop, kde by bylo možné seznámit potenciální zájemce o tento náš produkt podrobněji. To by FREDovi mohlo pomoci rozšířit se i do dalších destinací, které na automatizovanou správu domény teprve přecházejí.
Jaromír Talíř
333333 podepsaných domén a velká sázka o malé pivo
Nedávno překročil počet podepsaných domén v .cz magickou hranici 333 333, což je rozhodně důvod ke spokojenosti. Naše národní doména si v penetraci tohoto zabezpečení drží stále první příčku na světě. Skvělé je, že k těmto počtům nepřispívají pouze doménoví registrátoři, kteří automaticky podepisují všechny domény s jejich nameservery, ale že se připojují i firemní koncoví držitelé. Podívejme se třeba na média – iHNed.cz, Lidovky.cz, všechny servery Internet Info. Důležitý je i přístup státní správy a v tomto mi například naposledy udělal radost Český telekomunikační úřad, který nedávno podepsal obě své domény. A rozhodně je důležité, že začali validovat i velcí telekomunikační operátoři.
Nicméně naše prvenství už není tak suverénní jako dříve. Velmi silně se probudila země, která jako první DNSSEC implementovala, tedy Švédsko. Tamní registr velmi tlačí na své registrátory a ti už dokázali podepsat zhruba 180 tisíc domén. V poslední době to maličko spadlo, protože jeden registrátor migruje na novou technickou platformu, ale i tak mají téměř 150 tisíc.
Povzbuzen tímto úspěchem se mi nedávno ozval ředitel .SE, Dany Aerts (mimochodem ač spravuje švédskou doménu, je to původem Nizozemec) a navrhl mi, že se vsadíme o to, kdo bude mít do konce roku vyšší procento podepsaných domén. Kdo prohraje platí tomu druhému národní pivo. Pravda, nejsem velkým fanouškem švédských piv, ale na druhou stranu jsem soutěživý človek, takže jsem sázku přijal :-). Čili sázka je na světě, a tak se na vás správce, registrátory a všechny, co mohou něco udělat, obracím s prosbou: pojďte zavést DNSSEC a pomozte mi toto holandského Švéda pokořit!!! Kdo mi pomůže nejvíce, toho zvu na české pivo na oplátku zase já.
Ondřej Filip
Problém jménem DNSChanger a pár dobrých zpráv
Jak si možná vzpomenete, v únoru jsme na tomto blogu vydali článek informující o skutečnosti, že 8. března dojde k vypnutí sítě DNS serverů, využívaných trojským koněm s příznačným názvem DNSChanger. FBI, která momentálně tyto DNS servery provozuje, však mezitím dostala soudní příkaz k dalšímu prodloužení provozu těchto DNS serverů, tak, aby mělo co možná největší množství uživatelů kompromitovaných počítačů možnost tento zákeřný software odstranit. Nově stanovené datum je tedy 9. července 2012. Zde je pro technicky zdatnější uživatele video, které demonstruje, co DNSChanger v systému dělá.
Proč je tento trojský kůň tak nebezpečný? Po infikování počítače totiž změní DNS servery používané napadeným počítačem na své vlastní, které byly až do zásahu FBI ovládané tvůrci DNSChangeru. To znamená, že počítač oběti mohli například místo na adresu www.gmail.com přesměrovat na svůj vlastní server, kde pak mohli například získat přihlašovací údaje oběti. Lze předpokládat, že obětí těchto podvodů byli nejčastěji uživatelé internetového bankovnictví. Dále tento software stahuje do počítače další viry a trojské koně. Nejvíce zákeřná je však schopnost tohoto trojského koně změnit i nastavení některých routerů, používaných v domácnostech pro sdílení internetového připojení. Za tímto účelem zkouší známá defaultní jména a hesla pro různé routery. Pokud tedy máte na svém routeru defaultní jméno a heslo stačí jeden nakažený počítač, či návštěva někoho, kdo se s nakaženým počítačem do vaší sítě připojí a problém máte také. A je jedno, zda na svém PC používáte nejaktuálnější antivir, či jak obezřetně se na internetu chováte.
V současné době již nehrozí riziko přesměrování na podvodné servery. Avšak tento trojský kůň s velkou pravděpodobností indikuje další virovou nákazu vašeho počítače. Navíc, pokud dojde 9. července tohoto roku k definitivnímu vypnutí DNS serverů, které tento trojský kůň používá, přestane vám fungovat překlad doménových jmen na IP adresy. A nyní již další dobrá zpráva. Tento problém zaujal naše laboratoře a ty se rozhodly spustit českou verzi stránek, které umožňují detekovat, zda je váš počítač nakažen tímto nebezpečným trojským koněm. Proto neváhejte navštívit tuto stránku na adrese www.dns-ok.cz. Zde se dozvíte nejen zda je váš počítač, či router napaden, ale také, jakým způsobem se nejlépe této virové nákazy zbavit.
A perlička na konec. Pokud jste byli tímto virem napadeni a chcete pomoci FBI při vyšetřování, můžete se tímto formulářem přihlásit jako jedna z obětí.
Pavel Bašta