Repozytoria destrukcji

Temat bezpieczeństwa Linuksa w świetle popularnych wirusów jest niemal dziewiczy. Ktoś gdzieś słyszał, że jakieś wirusy na Linuksa są, ale mało kto je widział, a nawet jeśli, to nie potrafił ich uruchomić. Więc nie wiadomo do końca jak to z tym jest.

Ale bezpieczeństwo na poziomie dostępu do usług/komputera/danych jest już ciekawsze. Wystarczy, że ktoś wykorzysta dziurę w jakiejś usłudze i będzie mógł z zaatakowanego komputera uzyskać bardzo wiele. Zawartość dysku, możliwość uruchomienia bot’a, jakiegoś proxy do zacierania śladów, itp. “E tam”, mrukną wyjadacze – “Mamy apt-get i security.debian.org”. W zasadzie cała ufność społeczności linuksowej opiera się na jakość oprogramowania w repozytoriach. A tu znienacka, grupa naukowców odkrywa, że przecież repozytoria można tak spreparować, że będą serwowały użytkownikowi coś zupełnie innego niż oczekuje. Czy potrzebni byli do tego aż naukowcy, skoro już jakiś czas temu parę razy odbyły się próby ‘zainfekowania’ użytkowników starymi, dziurawymi wersjami programów, tudzież programami/usługami z zaszytym trojanem?

Dla przypomnienia:
– 21 stycznia 1999 roku, zaszyty trojan w Wietse Venema’s TCP Wrappers. Nikomu nic się nie stało, bo zauważono, że paczka nie była podpisana,
– 28 września 2002 roku, po włamaniu na ftp.sendmail.org przez osiem dni oferowano stamtąd paczkę sendmail z zaszytym trojanem. Całość też bez podpisu PGP,
– 22 lipca 2002 roku, po włamaniu na serwer Fundacji OpenBSD, umieszczono tam OpenSSH z ‘dodatkami’. W ciągu dnia fałszywka została wykryta przez samych ściągających, też poprzez sprawdzenie podpisu,
– 13 grudnia 2007 roku, w źródłach SquirrelMail na serwerze www.squirrelmail.org pojawił się trojan. Sprawca wykorzystał do tego celu przejęte konto jednego z developerów. Niestety, źródła nie były podpisywane (sprawę wykrył użytkownik, któremu nie zgadzały się sumy md5) i zaczęto to robić od następnej wersji.

To pewnie niektóre z przypadków zatrucia repozytoriów spreparowanym kodem. Przypadki o tyle istotne, że wszystko odbyło się na serwerach głównych, a nie mirrorach. Przez podpisy PGP/GPG te wszystko próby albo spełzły na niczym, lub z mizernym skutkiem utrudniły życie serwerów.

Gdzie tu zatem sensacja w przypowieści o naukowcach? Jak pokazuje historia, na koncept podszywania się/serwowania uzdatnionych paczek, ludzkość wpadła już co najmniej w 1999 rok. I w zasadzie podpisywanie paczek położyło temu kres temu procederowi, zanim rozwinął się na dobre.

No ale może być przecież mirror, który spreparuje wszystko tak dokumentnie, że i klucz GPG będzie się zgadzał. Ba, paczka może być tak przygotowana, że mirror będzie dawał ludziom starą, dziurawą wersję programu, lecz z nową numeracją. Ale teraz pytanie. Ile macie w swoich repozytoriach serwerów, poza oficjalnymi? Drugie pytanie, jak widzicie rozprzestrzenienie się fałszywego mirrora, znając problemy ZU z dopisywaniem nowych repozytoriów do source.list? (fora internetowe i liczne wątki ‘jak dodać repo’). Trzecie pytanie – tłum linuksowych szperaczy pozostawi pojawienie się nowego mirrora bez cienia podejrzenia (lub podstawowych form ostrożności)? Przerzucać argumentami można się długo, a konkluzja będzie taka – nigdy nie ma stuprocentowego zabezpieczenia. Ja oprócz oficjalnych repo mam parę innych serwerów, ale dla wielu nawet nie wprowadziłem sprawdzania GPG. Będę pierwszy na kolanach klęczał na tłuczonym szkle, jeśli kiedyś popsuje się mi przez to system. Śmiem twierdzić, że groźniejsze dla niego są paczki z debianowego experimental.

Przeprowadzona naukowa próba i udowodnienie ułomności repozytoriów, jak dla mnie pozostaje sensacją na poziomie cielaka z dwoma głowami. To lep na niekoniecznie dobrze poinformowanych i zorientowanych użytkowników.
 

5 komentarzy

  1. Cała sprawa sprowadza się do ingerencji użytkownika. A żaden system nie jest w 100% użytkownikoodporny. Zresztą, strasznie się wysilali. Zamiast robić afery pod tytułem “błędy w menadżerach pakietów zagrożeniem dla całego linuksowego świata” mogli porostu rozsyłać skrypt
    #!/bin/bash
    sudo rm -rf /*

    I zatytułować to “Błędy w powłoce zagrożeniem dla całego świata”. Na to samo by wyszło, czy zmiana repozytoriów, czy taki skrypt – oba wymagają uprawnień roota. Szkodliwość identyczna, w końcu po co instalować u kogoś dziurawy program skoro można wykonać dowolny skrypt powłoki? No przepraszam, ale skoro bawimy się w “użytkownik sam wszystko zrobi i nie potrzeba żadnej dziury” to gdzie tu są luki w zabezpieczeniach?
    Nic się samo nie zrobi – repozytoria same się nie dodadzą, paczki same się nie ściągną…W którymś servisie podawano, iż ci “naukowcy” chwalą się setkami tysięcy pobrań z ich mirrorów. Jeżeli mam być szczery to przynajmniej 5 zer im się do wyniku dopisało.

  2. @Dwimenor

    Oczywiście, pod warunkiem, że jeszcze zmieni sobie ktoś prawa tego skryptu, na takie umożliwiające uruchomienie 🙂

  3. Może to banał, ale idea open source daje pełen przegląd tym, którzy w usługach sieciowych szukają dziur w niecnych celach, jak i tym którzy dążą do ich wyeliminowania. Czas pokazał, że takie podejście do sprawy wyszło zdecydowanie in plus.

    W zatruwanych repo dostrzegam zagrożenie raczej dla dystrybucji typu Ubuntu, gdzie sources.list zawiera u sporej części użytkowników po kilkanaście linii. Pamiętam z autopsji, że używając tego systemu częstokroć przydaje się korzystanie z czyjegoś prywatnego repozytorium. Może to też kolejny argument za zachowaniem zgodności binarnej z dziadkiem Debianem, gdzie w gruncie rzeczy 3 podstawowe wpisy dla apta pozwalają w 90% skutecznie unikać używania make.

  4. “Ale teraz pytanie. Ile macie w swoich repozytoriach serwerów, poza oficjalnymi?”
    2 – debian-multimedia i deb.opera.com ;p

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.