Dziury w OpenSSL ciąg dalszy.
14 maja, 2008
Okazuje się, że działania developera Debiana były słuszne - przeanalizował kod, odkrył wykorzystanie niezainicjalizowanych obszarów pamięci jako źródła losowych danych (nie są/nie muszą być losowe), chciał to naprawić. W tym celu skontaktował się z developerami OpenSSL, potwierdzili oni błąd i sposób naprawy. Rzecz w tym, że uzgadniał zmianę w jednej funkcji, a tymczasem poprawił podobny kod w dwóch funkcjach. I teraz powstaje dylemat: czy faktycznie popełnił błąd źle oceniając działanie drugiej funkcji, czy może jednak w OpenSSL, w wersji oryginalnej, nadal w jednym z miejsc polega się na niezainicjalizowanej pamięci jako źródle losowych danych (co jest lepszą metodą, niż to, co wprowadził, ale nadal dalekie jest od ideału)? Mam przeczucie, że czeka nas niebawem jeszcze jedna wymiana kluczy, tym razem na wszystkich systemach...
Jest sens o tym (losach dziury w OpenSSL) pisać na techbloga? Z jednej strony mam świadomość, że jeśli kogoś to interesuje, to pewnie subskrybuje stosowne feedy (z których dowie się więcej), z drugiej wiem, ilu ludzi nie zdaje sobie sprawy z sytuacji (dość powszechna była opinia "zaktualizuję pakiet i po problemie").
Gratulacje! Dotarłeś do końca wpisu. Parę linii niżej są gwiazdki, gdzie możesz go ocenić. Zrób to!
Dodaj komentarz Trackback URI RSS komentarzy
1.
amag napisał(a):
14 maja 2008, 09:59:50
Pomysł z wykorzystaniem niezainicjowanych miejsc w pamięci jest IMO niezbyt trafiony. Teoretycznie ktoś mógłby sobie napisać łatę na jądro, która podczas zwalniania zasobów czyściła (nadpisywała) poprzednio zaalokowany obszar pamięci i dbała o to by żadne śmieci nie znajdowały się poza obszarem używanym. Co wtedy? Nie znam konkretnej implementacji funkcji w OpenSSl ale myślę, że w tym momencie padnie aspekt losowości. Zastanawiam się także co robią wirtualne maszyny poustawiane na dynamiczny przydział pamięci dla swoich hostów- czyszczą pamięć komputera matki przed przypisaniem jej do swojego dziecka? Nie posiadam takich informacji ale potencjalnie może to być istotny błąd.
Jestem za tym byś tego typu wpisy umieszczał ze względu na to, że subskrybuje feedy ale w czytniku w domu, a nie w pracy więc o takich wypadkach dowiaduję się jak znajdę czas wieczorem.
2.
Jajcuś napisał(a):
14 maja 2008, 10:59:43
Przecież openssl wykorzystuje do generowania losowych danych nie tylko tej niezainicjowanej pamięci. Jeśli ktoś security traktuje poważnie, to karmi openssl odpowiednim źródłem danych losowych (np. sprzętowym generatorem, a jak brak, to chociażby kernelowym /dev/random) i to, czego openssl użyło jeszcze, nie ma najmniejszego znaczenia.
To, czy niezainicjowany fragment pamięci jest dobrym źródłem losowości ma znaczenie tylko wtedy, gdy zawiodą inne źródła (nawet /dev/urandom). Ale w takim systemie i tak można zapomnieć o kryptograficznie bezpiecznym generatorze liczb losowych.
3.
ike napisał(a):
14 maja 2008, 12:42:11
Bzdura tam słuszne. Popełnił błąd. Deweloperzy openssl też nie „potwierdzili” sposobu naprawy. Oczywiście brak odpowiedniej dokumentacji w kodzie openssl mógł mieć pewien wpływ na „poprawki”, ale nie wiadomo. Kurt chciał dobrze – wyszło źle. Dobrze w ogóle, że ktoś zwrócił na to uwagę. NSA pewnie od dwóch lat czyta nasze szyfrowane połączenia…
4.
rozie napisał(a):
14 maja 2008, 13:27:11
Czyje czyte, tego czyta. Jak ktoś ma ciągłość kluczy z Sarge zachowaną, to jest OK ;). Chyba, że były inne poprawki w tym temacie – niby mniej krytyczne, ale rzutujące na siłę generowanego klucza. Tak czy inaczej, wygląda, że Debian dorobił się mechanizmu sprawdzania kluczy pod kątem błędnych (ssh-vulnkey). I być może sprawdzanie tego typu błędów będzie w standardzie już... Oby.
5.
ike napisał(a):
14 maja 2008, 13:29:20
Nie ma błędnych kluczy. Semantyczne nadużycie.
6.
rozie napisał(a):
14 maja 2008, 13:30:33
Tu: błędny = słaby kryptograficznie. Ale oczywiście masz rację. A ja już nie klikam więcej na szybko. ;)
7.
Pomiędzy bitami napisał(a):
31 grudnia 2010, 09:26:40
Niebezpieczny świat.
Ostatnie wydarzenia coraz bardziej skłaniają mnie do - paranoicznego, przyznaję - wniosku, że żadne dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie. O ile tylko komuś będzie za[...]
8.
Pomiędzy bitami napisał(a):
09 kwietnia 2014, 08:20:40
Dziura w OpenSSL, o jakiej się nie śniło.
No bo jak inaczej nazwać błąd, który pozwala na zdalny dostęp do pamięci podatnej maszyny? Co prawda tylko 64kB i tylko związanej z procesem korzystającym z biblioteki zawierającej błąd, ale biorąc pod uwagę, do czego OpenSSL służ[...]