OpenSSL 0.9.8zb, 1.0.0n a 1.0.1i

Byly vydány verze 0.9.8zb, 1.0.0n a 1.0.1i kryptografické knihovny OpenSSL. Opraveno je hned 9 bezpečnostních chyb (CVE-2014-3505, CVE-2014-3506, CVE-2014-3507, CVE-2014-3508, CVE-2014-3509, CVE-2014-3510, CVE-2014-3511, CVE-2014-3512 a CVE-2014-5139).

7.8.2014 01:59 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[hermelin]

Koukam ze openssl bylo (je) deravy jako reseto. Ale je dobre ze se na to ted vrhli a snazi se to napravit. Nicmene si myslim ze u takove knihovny mel byt ohled na bezpecnost-bezchybnost kodu maximalni uz od sameho pocatku vyvoje.

[vaLin]

Od samého počátku to půjde hodně ztuha. Nikdo to nezná, nikdo o tom nic neví, programují to nezřídka nezkušení lidé či dokonce jednotlivec bez jakékoliv finanční podpory. Začátky jsou nejtěžší...

[lertimir]

No buď jste mladý nebo jste se v době vzniku openSSL o bezpečnost moc nezajímal. Jen pro připomenutí. 90 léta byly silně pod exportním embargem USA na krypto. Jediné, co se oficiálně dalo pořídit v česku byl DES s 40 bitovým klíčem (ano pouze 40 bitový klíč tedy naprosto k ničemu) a RSA s 512 bity. V západní Evropě to bylo trochu lepší, ale ne o moc (přesně si už nepamatuji co měli dovoleno). Nicméně algoritmy byly známy. zvláště po vyjítí Schneierovy Applied Cryptography a Menezesovy Handbook of Applied Cryptography to bylo v těch knížkách jako na talíři. A proto se zřejmě 4 původní autoři OpenSSL rozhodli: "My to těm amíkům ukážeme." a začali psát otevřenou knihovnu. Jak to bylo na začátku viz way back machine. Na začátku o "bezpečnost kódu" nešlo, spíše o to, rozumně rychle vyrobit použitelné volné silné crypto.

[Heron]

Na začátku o "bezpečnost kódu" nešlo

A to je právě to. Když ještě časopis Chip za něco stál (ročníky menší než 2000), tak tam vycházely seriály od jednoduché kódování až po kryptografii včetně detailního popisu algoritmu Rijndael, který tehdy zrovna vyhrál soutěž NISTu o AES (Advanced Encryption Standard -- dnes se zaměňuje AES a konkrétní šifra). Ty kódy byly tak přehledné, že jej mohl studovat ale hlavně implementovat i středoškolák (pochopitelně bez znalosti příslušné matematiky). Potom se na vysoké učí RSA v programu do 20 řádků zdrojového kódu.

Když se ale podíváte téměř na jakýkoliv kryptografický program, tak ten zdrojový kód mnohem více připomíná soutěž o maximální obfuskaci.

Přitom se to evidentně dá dělat jak funkčně, tak i čitelně (což je základ pro audit) a tím i s důrazem na bezpečnost.

[Filip Jirsák]

To, že jde něco naprogramovat jednoduše, ještě neznamená, že ta jednoduchá verze bude bezpečná a efektivní. Něco, co může vypadat jako obfuskace, může být ve skutečnosti například snaha udržet tajný materiál v paměti na jednom místě, po minimální nutnou dobu a např. tak, aby se paměť neodswapovala na disk. Nebo jde o využití rychlých instrukcí procesoru, pokud jsou k dispozici. Nicméně souhlasím s tím, že takhle se zdaleka nedá vysvětlit vše, co se v kryptografických programech nalézá. Např. pokaždé, když musím pracovat s tzv. objektovým Java Crypto API, si vzpomenu na bonmot "opravdový programátor dokáže ve Fortranu programovat v libovolném jazyce".

[lertimir]

Jenže hlavně šlo o rychlost implementace. A zase zvláště v době, kdy žádná podpora crypto v HW nebyla, a ten procesor v roce 98 měl nějakých cca 600 MIPS. Takže utlačit implementaci, aby měla nějaký rozumný průtok dat nebylo jednoduché.

[Filip Jirsák]

Popíráte sám sebe. Pokud vývojáři trávili spoustu času optimalizací kódu na rychlost běhu, rozhodně nemohlo být tím hlavním co nejrychleji to implementovat.

[potato]

V tomto případě: rychlost implementace == jak rychle daná implementace algoritmu poběží. Nikoli jak rychle algoritmus implementuji.

[lertimir]

Možná se nevyjadřuji srozumitelně. Nevím jak Vy, ale mě se nikdy nepodařilo významně "optimalizovat kód". Ať už jsem programoval ve zmíněném Fortranu na matfyzu nějaké parciální rovnice či konečné prvky nebo později věci v C-čku. Buď jsem problém "viděl" jak ho zpracovávat optimálně, tedy měl vědomí z jakých počátečních datových struktur začít, jaké mít mezilehlé datové struktury a v jakých datových strukturách mít výstup, a jaké operace mezi jednotlivými kroky mít, a pak to běhalo rychle, nebo jsem to neviděl, udělal výpočet podle formálního popisu a bylo to výkonově strašné.

Už jen ta modulární matematika, kterou je třeba pro RSA a DH, vyžaduje desítky hacků, aby to bylo rozumně rychlé, mnoho mezivýsledků se vyplatí si na chvíli zapamatovat, protože při výpočtu budou ještě potřeba a musely by se spočíst znovu.

Troufám si odhadnout, že autoři postupovali obdobně. Rozmysleli si algoritmus a jeho efektivní implementaci včetně výkonových hacků, napsali ho jen s nezbytnou dokumentací a šli dále. Už to, že si napsali vlastní alokační modul na paměť, což je výkonnostní hack jako hrom, protože standardní alokace od systémů byla pomalá naznačuje, že to nač mysleli byla efektivita, ne bezpečnost a srozumitelnost kódu.

Z hlediska vývoje se stačí podívat na changelog. Začali v den před štědrým dnem 98 s verzí 0.9.1c. V průběhu roku 2000 byli na verzi 0.9.6. A když se člověk podívá do chnagelogu, tak v podstatě "měli hotovo". Ve smyslu implementace SSL norem k uvedenému datu. Další vývoj je v podstatě implementace nových rysů, které se postupně do norem dostávaly, odstraňování CVS a nějaké čištění. Crypto je z principu vývojově "pomalé", není to něco jako UI. Než se nějaká technika akceptuje jako bezpečná uplyne dost času a rozhodně, teď je to zcela jiný způsob práce než to hektické období vzniku openSSL, kdy bylo třeba naprogramovat rychle a efektivně dost základních algoritmů.

[Filip Jirsák]

Ano, ale tím vyvracíte to, že záměrem bylo co nejrychleji poskytnout implementaci nezatíženou USA zákony. Pokud by tohle bylo záměrem, neřeší nějakou vlastní alokaci paměti a ty spousty dalších hacků, ale naprogramují to přímočaře a dříve, i když by výsledný kód byl pomalejší. Tady to naopak vypadá, že byla snaha optimalizovat všechno a prakticky za jakoukoli cenu. Kód občas optimalizuju a snad vždy je to na úkor čitelnosti programu. Při běžném psaní samozřejmě vybírám vhodné datové struktury a vhodné algoritmy, to je jakási základní optimalizace. Ale někdy se ukáže, že to nestačí, že je potřeba optimalizovat dál, ale pak už se to ubírá tou cestu, že se srozumitelnost kódu vymění za rychlost výsledného programu. Klasickým příkladem je třeba paralelní zpracování – napsat něco sekvenčně a celé to obalit jedním velkým zámkem je nejjednodušší (třeba Big Kernel Lock), složitější je zamykat jen minimální nutnou část (najednou se přehledný kód, který přímočaře něco provádí, rozseká na spoustu krátkých sekvencí obalených zamykáním), a nejsložitější je upravit kód tak, aby nepoužíval sdílené zdroje nebo aby jich bylo minimum (pak musíte obětovat třeba i dekompozici, protože volající musí na tuhle hru přistoupit a používat dříve sdílený objekt takovým způsobem, aby se vyhnul soupeření o sdílené zdroje).

[Heron]

neřeší nějakou vlastní alokaci paměti

Tohle bylo spíše způsobeno tím, že chtěli dělat implementace pro x různých platforem (mě překvapilo, že openssl je i pro dos), takže s nějakou obecnou dobrou alokací paměti v těch platformách nešlo počítat.

[lertimir]

Ano, ale tím vyvracíte to, že záměrem bylo co nejrychleji poskytnout implementaci nezatíženou USA zákony. Pokud by tohle bylo záměrem, neřeší nějakou vlastní alokaci paměti a ty spousty dalších hacků, ale naprogramují to přímočaře a dříve, i když by výsledný kód byl pomalejší.

Myslím, že si nerozumíme. Hned v té první poznámce jsem psal "rozumně rychle vyrobit použitelné volné silné crypto". Tu optimalizaci jsem měl zahrnutu ve slově použitelné. Crypto má bohužel (bohudík) tu vlastnost, že přímočará implementace může být klidně pomalejší v poměru 10^5, nebo 10^6. Což ji změní na nepoužitelnou. Bez optimalizace od základních myšlenek se s tím pracovat nedá. Asi před 15 lety jsem psal rutinu na čtení LZW komprimovaného TIFFu. Což je trochu podobná matika jako crypto. První pokus, přímočaré naprogramování algoritmu bylo tak pomalé, že bylo nepoužitelné, rychlost nižší než 10^4 proti rychlosti LZW dekomprese zipu. Trvalo mi asi 14 dní než jsem pochopil, jak to napsat lépe a i když to bylo pořád asi 8 krát pomalejší, bylo to už použitelné.

Na druhou stranu je to v podstatě jedno. Buďme rádi, že openSSL máme.

[Filip Jirsák]

Nemyslím si, že by ten typ optimalizací, který popisujete, znepřehledňoval kód takovým způsobem, jaký se vidí u kryptografických knihoven. Ta vaše dekomprese LZW byla nejspíš jedna oddělená komponenta, která v sobě ty optimalizace zapouzdřovala, ale z venku to mělo nějaké rozumné rozhraní a zbytek snad byl čitelný kód. U OpenSSL poznáte, že jde o kryptografickou knihovnu, už když se podíváte na parsování argumentů programu... Ano, buďme rádi, že OpenSSL máme. Že by se u projektů jako OpenSSL mělo dbát na maximální bezpečnost hned od začátku, to věděl každý, ale zároveň si (skoro) každý myslel, že by se o to měl starat někdo jiný. Takže nakonec můžeme být za ten průšvih rádi, aspoň se našlo dost lidí, kteří naznali, že samo se to neudělá.

[Heron]

Nevím jak Vy, ale mě se nikdy nepodařilo významně "optimalizovat kód". Ať už jsem programoval ve zmíněném Fortranu na matfyzu nějaké parciální rovnice či konečné prvky nebo později věci v C-čku. Buď jsem problém "viděl" jak ho zpracovávat optimálně, tedy měl vědomí z jakých počátečních datových struktur začít, jaké mít mezilehlé datové struktury a v jakých datových strukturách mít výstup, a jaké operace mezi jednotlivými kroky mít, a pak to běhalo rychle, nebo jsem to neviděl, udělal výpočet podle formálního popisu a bylo to výkonově strašné.

Přesně tak.

Mnoho lidí si vykládá špatně ono Knuthovské "optimalizace je kořenem všeho zla" a myslí si, že když místo správné datové struktury dají prostě nějakou libovolnou a místo správného algoritmu dají prostě nějaký vyhovující, že postupují přesně podle pravidla o předčasné optimalizaci. Tak to ale není. Programátor by měl vědět, jaký je rozdíl mezi O(a^n) a O(1) a měl by vědět, jaké složitosti mají které funkce. To není optimalizace, to je prostě známka toho, že vím co dělám.

Skutečná optimalizace není vůbec o tom, že vyměním jeden algoritmus za jiný (pokud ho tam nějaké prase na počátku použilo) nebo že změním datové struktury. Skutečná optimalizace nutně vyžaduje zcela jiný pohled na problém. Přičemž je snaha některé kroky zcela eliminovat.

Aneb nejrychlejší instrukce je ta, kterou vůbec nevolám.