Wieści ze świata OpenSource: 23 – 29 października 2013 r.

Dzisiejszy numer Poniedzielnika powstał przy współudziale paranoi.
Chciałbym też podziękować ionashowi za nieustępliwość w poprawianiu moich grafomańskich popisów.

Odrobina paranoi jest zdrowa, o ile jest dawkowana według zaleceń lekarza lub farmaceuty.

Otwarcie kodu źródłowego gwarantuje, że w danym oprogramowaniu nie ma żadnej tylnej furtki. Prawda? Nie do końca. Kilka tygodni temu (w Poniedzielniku nr 101) opisywałem, jak to celowo uszkodzone algorytmy generowania liczb losowych mogą wpłynąć na bezpieczeństwo systemu. Znany jest też fakt rozpowszechniania wraz ze źródłami Linuksa fragmentów kodu i binarnego firmware’u, które są celowo zaciemnione. Wiemy też, że amerykańska NSA celowo wprowadzała błędy w oprogramowaniu, aby móc wypełniać swoje zadania. Czy zaczynasz nerwowo spoglądać na swoje pudło z krzemem? Może czas pomyśleć o zaszyfrowaniu katalogu domowego? Właśnie ściągasz TrueCrypta i…

W tym momencie powinieneś usłyszeć szept, dobiegający gdzieś z głębi twej podświadomości. Do twojej jaźni dociera cichutki, stłumiony przez warstwy zdrowego rozsądku głosik. „Ty bęcwale, ściągasz przecież binarkę. Skąd wiesz, że do jej skompilowania nie użyto spreparowanych źródeł?” To bardzo dobre pytanie. Nie wiesz i nie jesteś w stanie tego sprawdzić. Oczywiście możesz skompilować TrueCrypta ze źródeł („O ile źródła nie zostały odpowiednio »doprawione«. Znasz C, aby przeprowadzić ich audyt?”), ale ile osób może z ręką na sercu powiedzieć, że to zrobiło? Większość poprzestaje na wersjach binarnych, rozpowszechnianych przez truecrypt.org. A teraz najciekawsza część. Tak samo jak zwykły śmiertelnik nie jest w stanie potwierdzić autentyczności, tak samo deweloperom TrueCrypta jest bardzo ciężko udowodnić, iż binarna wersja jest „czysta”. Kompilacja programu z kodu źródłowego do kodu maszynowego jest procesem bardzo złożonym. Te same źródła kompilowane na różnych maszynach dadzą różne pliki wynikowe. Niesamowicie trudno jest odtworzyć proces kompilacji tak, aby w jego wyniku uzyskać identyczne pliki.

Czy da się potwierdzić, że udostępnione milionom ludzi binaria rzeczywiście nie zostały spreparowane? Jest to bardzo trudne, ale wykonalne. Dowiódł tego Xavier de Carné de Carnavalet. Udało mu się odtworzyć i udokumentować proces kompilacji TrueCrypta. Wymagało to instalacji identycznego środowiska kompilatora, z uwzględnieniem jedynie poprawek i uaktualnień dostępnych w dniu kompilacji. Jakakolwiek nowsza łatka powodowała ogromne zmiany w pliku wynikowym.

W efekcie udało się skompilować binarki TrueCrypta bardzo przypominające te oficjalne, zaś wszelkie różnice można było logicznie wytłumaczyć. Jakie to różnice? Na przykład data kompilacji zapisywana jest przez kompilator do pliku wynikowego. Pliki różniły się też tym, że oficjalna wersja binarna jest podpisana cyfrowo, czego nie da się powtórzyć w warunkach laboratoryjnych (gdyby się dało, idea podpisu cyfrowego straciłaby sens). Pliki różniły się też nadawanym przez kompilator każdemu z nich numerem GUID (Globally Unique Identifier – identyfikator globalnie unikatowy). Nawet taka – zdawałoby się – drobnostka, jak położenie katalogów ze źródłami programu w systemie plików, wpływa na ostateczny kształt pliku wynikowego. Każda z tych zmian, często licząca jedynie kilka bajtów, powodowała rozbieżności w sumach kontrolnych. Po wyeliminowaniu tych wszystkich różnic generowane w czasie kompilacji i zapisywane do pliku sumy kontrolne zaczęły się zgadzać.

Aby weryfikacja była pełna, poddano jeszcze obie wersje (tę dostępną na truecrypt.org i tę skompilowaną przez Xaviera) deasemblacji (odtworzeniu źródeł z pliku binarnego). W jej wyniku otrzymano pliki o zawartości identycznej co do pojedynczego bajta. To ostatecznie dowodzi, że oficjalny instalator TrueCrypta jest w istocie kompilowany z publicznie dostępnych źródeł.

„Ale nie dowodzi to tak naprawdę niczego. Do procesu kompilacji używano narzędzi dostarczanych przez Microsoft. Nie wiadomo, czy nie dodają one do generowanych plików tylnej furtki. Eksperyment Xaviera de Carné de Carnavaleta dowodzi jedynie, że obie wersje są identyczne i działają tak samo. Nie udało się jak na razie potwierdzić, czy nie zostały spreparowane w czasie kompilacji.”

Właśnie dlatego ruszyła inicjatywa „Is TrueCrypt Audited Yet?” („Czy TrueCrypt poddano już audytowi?”), której celem jest zbiórka funduszy na pełny audyt kodu źródłowego TrueCrypta, wypłacanie nagród za znalezione błędy i tylne furtki, opłacenie prawników mających przeanalizować licencję (TrueCrypt używa własnej licencji, uznawanej przez społeczność Wolnego i Otwartego Oprogramowania za niezgodną z jej ideałami) oraz stworzenie łatwego do odwzorowania, pewnego i powtarzalnego procesu kompilacji. Pozostaje jeszcze kwestia zaufania do zamkniętego kompilatora Microsoftu („I do Windowsa. I do RSA. I do assemblera NASM. I przede wszystkim do anonimowych autorów TrueCrypta. Skąd wiecie, że NSA nie napisało TrueCrypta, aby stworzyć fałszywe poczucie bezpieczeństwa?”).

TrueCrypt to niejedyny projekt, który zmagał się z udowodnieniem, że rozpowszechniane binaria nie są spreparowane. Przed podobnym wyzwaniem stanęli deweloperzy projektów Tor i BitCoin. Oni jednak poradzili sobie inaczej. W obu przypadkach chodziło o stworzenie takiego procesu kompilacji, który dawałby identyczne pliki wynikowe, niezależnie od platformy. Efektem tych prac jest Gitian – mniej lub bardziej zjadliwe dla przeciętnego Kowalskiego narzędzie (oraz zestaw skryptów), pozwalające uzyskać taki własnie efekt.

BitCoin (anonimowa waluta) i Tor (anonimowe surfowanie w internecie) są pewne niemal pod każdym względem (poza błędami w kodzie) – być może niedługo i TrueCrypt dołączy do tego grona.

Źródła:
Is TrueCrypt Audited Yet?
How I compiled TrueCrypt 7.1a for Win32 and matched the official binaries – Xavier de Carné de Carnavalet
TOR – Deterministic Build (Część 1, Część 2)

W skrócie

Nowa wersja ffmpeg, oznaczona numerem 2.1, oferuje wsparcie dla serwera dźwięku Pulseaudio, możliwośc kodowania w formacie h.265, obsługę metadanych w plikach jpeg oraz wiele, wiele więcej.

Cichaczem na serwerach zagościła Cinelerra w wersji 4.5. Jest to mało znany, acz niegdyś całkiem popularny, otwartoźródłowy edytor wideo. Może warto dać mu ponownie szansę?

Rozwojowa wersja GIMP-a (2.9.1) powoduje u swoich użytkowników „szczękospad”. W końcu możliwa jest praca z precyzją 16 lub 32 bitów na kanał. Nowy GIMP coraz śmielej poczyna sobie także z bibliotekami GEGL, wykorzystującymi do obróbki obrazu możliwości wielordzeniowych procesorów oraz moc drzemiącą w kartach graficznych.