Znamy wyniki pierwszej analizy kodu źródłowego i binarnego TrueCrypta

dodał 15 kwietnia 2014 o 06:30 w kategorii Krypto  z tagami:
Znamy wyniki pierwszej analizy kodu źródłowego i binarnego TrueCrypta

Czy używanie TrueCrypta jest bezpiecznie? Czy są w nim ukryte tylne furtki zainstalowane przez NSA, CIA, MOSAD, KGB czy kto wie jeszcze czyje? Czy czarne, szare i białe kapelusze mogą spać spokojnie? Dziś już jesteśmy bliżej odpowiedzi na to pytanie.

Właśnie ukazał się raport z pierwszego etapu analizy kodu źródłowego TrueCrypta, pomysłu zapoczątkowanego w październiku 2013. Pomijając zbędne budowanie napięcia przez kilka akapitów które nawet Alfred Hitchcock uważałby za nudne – ogłaszamy wszem i wobec: JEST DOBRZE.

Co udało się sprawdzić?

Na pierwszy rzut audytorzy wzięli dwa elementy: bootloader TrueCrypta oraz sterowniki pod Windows. Oprócz przeglądnięcia kodu i sposobu budowy oprogramowania dokonali oni również fuzzingu (testowanie poprzez wprowadzanie zarówno poprawnych jak i błędnych i nieoczekiwanych danych lub parametrów). Etap ten był bardzo ważny ze względu na to, że system Windows jest jedynym obsługującym i wspierającym pełne szyfrowanie dysku w TrueCrypcie oraz to, że kod który był audytowany, jest tym samym który udostępniany jest w skompilowanych plikach binarnych. Testy przeprowadzane były na udostępnianych plikach binarnych, a nie na ręcznie kompilowanej wersji.

Jakie błędy wyszły?

Mimo wielu uwag co do samej jakości kodu (w szczególności jakości (oraz braku) komentarzy), zanotowano w sumie tylko 11 błędów, z czego cztery z nich określone były jako średnio ważne, cztery o niskiej wartości i trzy informacyjne, mające jednak częściowy wpływ na całość bezpieczeństwa aplikacji.

Odnalezione błędy w TrueCrypt

Wśród błędów o średnim znaczeniu, znalazł się np. błąd związany z zapisaniem do pliku wymiany wrażliwych informacji (w tym informacji o kluczu), w sytuacji, gdy atakujący doprowadzi do zapełnienia pamięci operacyjnej systemu ofiary (oczywiście problem ten opisany jest w dokumentacji technicznej, gdzie należy albo wyłączyć wspomniany plik wymiany, albo przechowywać go również na zaszyfrowanej partycji). Na podobnym problemie bazuje inny błąd o tym samym znaczeniu, a jego wyeliminowanie możliwe jest poprzez zastosowanie zamiast funkcji memset() funkcji burn(), dzięki czemu można uniknąć przesunięcia nieużywanych już danych z pamięci do pliku wymiany.

Kolejnym błędem o średnim znaczeniu, był tzw. atak złej pokojówki, gdzie poprzez modyfikację kodu bootloadera możliwe jest zmuszenie go do zapisania hasła w momencie wpisywania go przez użytkownika. Problem ten związany jest głównie z kiepską jakością kodu, o której piszemy w kolejnej części.

Wskazany został również problem związany z weryfikacją nagłówka wolumenu. Obecnie zamiast zastosowania dostępnych funkcji umożliwiających weryfikację integralności oraz autentyczności zaszyfrowanych danych (HMAC), stosowany jest dosyć słaby algorytm CRC32 (na podstawie deszyfrowania czterech pierwszych bajtów zawierających słowo „TRUE”, oraz sumy kontrolnej ostatnich 256 bajtów sprawdzana jest zgodność tych danych z danymi zawartymi w 8 bajcie zaszyfrowanych danych).

Przejrzystość kodu

Audytorzy zwrócili uwagę, że o ile sama aplikacja nie posiada większych problemów, o tyle, jakość kodu, jego przejrzystość jak i sposób komentowania nie spełniają ogólnie przyjętych standardów bezpieczeństwa. W tym wypadku nie powoduje to występowania problemów, ale przywołując przypadek nginx, warto zwracać szczególną uwagę na przedziały w jakich operują zmienne, choćby po to by uniknąć błędów przepełnienia bufora.

Przykład niepoprawnego kodu

Co dalej?

To jeszcze nie koniec prac. W kolejnej części audytu analizie zostaną poddane błędy związane z samym szyfrowaniem. Weryfikację przejdą sposoby implementacji funkcji szyfrujących dane, poprawności wykorzystania dostępnych algorytmów oraz podatności na znane metody i ścieżki deszyfrowania danych, o czym z przyjemnością napiszemy ponownie. Niech Bruce Schneier będzie z wami!