Forum Debian Users Gang

A ja bym powiedział, że nawet najlepszym się zdarza ;)

serwer DUG'a stoi na Gentoo

Nie ma co się dziwić :) Nie ma systemów idealnych . Błąd naprawiony. Nie ma co się martwić.

[OT]Mówcie co chcecie, ale niektóre komentarze z "dobreprogramy.pl" są wręcz żałosne. Mam tu na myśli - "  upadek mitu o bezpieczeństwie Linuksa "
Ciekawe, ile osób, które skomentowały te newsy tak naprawdę wiedzą na czym polegała luka :( [/OT]

[quote=Bodzio]serwer DUG'a stoi na Gentoo[/quote]
To wiem i wcale nie mam nic przeciwko.  :)

[quote=Piotr3ks]Błąd naprawiony. Nie ma co się martwić.[/quote]
Ten błąd był naprawiany kilka razy i nie tylko  Linuksa on dotyczy. Problem istnieje dalej włączając w to inne systemy niż Debiano-pochodne, jeżeli skopiowano na nie dane zabezpieczone kluczami wygenerowanymi przez Debiana.

[b]0.9.8c-4etch1[/b] czy mam rozumieć że w tej paczce błąd jest naprawiony?? A co do komentarzy to nigdy nie czytam, szkoda się denerwować, wolę poczytać artykuł, ocenić po swojemu albo i nie oceniać ;) A wpadki zdarzają się każdemu nawet zawodowcy miewają kontuzję. Trudno było minęło. Najwyżej cały świat stanie w płomieniach i może wreszcie wypuszczą nas z Matrix'a :D:D

[b]Co tak naprawdę się stało[/b].

Wszyscy (oświeceni) znają dobrodziejstwo, jakim jest valgrind. Pozwala on odkryć, gdzie w programie lub bibliotece występują odwołania do niezainicjowanej pamięci, wycieki pamięci, podwójne uwolnienia, itp. Biblioteka openssl miała taką piękną cechę, że kopiowała w pewnym momencie do bufora, w którym zbiera entropię do generowania kluczy czy certyfikatów, cały szereg bajtów z niezainicjowanej pamięci. I to było dobre - mimo iż w normalnych warunkach używanie danych z niezainicjowanej pamięci może skończyć się jedynie kaszaną, tutaj akurat powiększało pulę entropii. No i jaki był tego efekt? Valgrind krzyczał. Valgrind krzyczał i krzyczał, że używane są wartości z niezainicjowanych zmiennych. Tak długo krzyczał, że pewien deweloper Debiana postanowił zakomentować linijkę kodu, która kopiowała całkiem ładne losowe ciągi do puli entropii. To było bezbolesne i nieszkodliwe, no i uciszyło valgrinda (entropia pochodziła też z kilku innych źródeł, między innymi typ procesora/endiannes/architektura/itp, getpid(), było też chyba jedno inne, bardzo ważne źródło, na temat którego wiem jednak niewiele). I właśnie problem pojawił się w momencie, gdy opiekun paczki zakomentował drugą, identyczną linijkę kodu, leżącą paręset linijek dalej. Czasem tak jest, człowiek się rozpędzi i próbuje robić coś odrobinkę na wyrost... I oto efekt: owo drugie, nieszkodliwe odwołanie do funkcji kopiującej bufor było tym, które wrzucało do puli najwięcej użytecznej entropii. Po usunięciu owego wywołania, jedynym faktycznym źródłem pozostało... getpid().

Teraz łatwo sobie policzyć, że w praktyce oznaczało to, iż openssl w Debianie, od września 2006 był w stanie wygenerować co najwyżej 32768 (czyli 2**15) unikalnych kluczy. Co więcej, można było banalnie prosto wszystkie te klucze odtworzyć (wystarczyło dostarczyć bibliotece własną wersję getpid()). Co jeszcze więcej, prawdopodobnie faktycznie wygenerowanych, będących w użyciu kluczy jest jeszcze mniej, gdyż debiany mają to do siebie, że przypisują pidy sekwencyjnie - powstaje proces 412, powstaje proces 413, powstaje proces 414, umiera proces 412, powstaje proces 415... To oznacza, że z dużym prawdopodobieństwem wystarczy mieć tylko pierwszych kilkaset, góra parę tysięcy kluczy, by móc już próbować odszyfrowywać sesje SSH lub próbować się logować. Ponadto proces generujący klucz dla maszyny też zazwyczaj powstaje dość wcześnie po starcie systemu (nie powiem teraz dokładnie gdzie i kiedy, ale bodajże jest to podczas instalacji serwera SSH).

Żeby użyć analogii z rzeczywistego świata: to tak, jakby w całym mieście, do wszystkich zamków, pasował zawsze jeden z ledwie kilkunastu kluczy. To, że te klucze były wytwarzane na jednym tylko osiedlu, lub na jednej ulicy, niewiele zmienia dla reszty mieszkańców - wszyscy, którzy dostali owe felerne klucze, muszą wymienić zamki :P

a teraz najlepsze: jak to się ma do zielonych użytkowników?:)Jak sie domyslacie-nie bardzo rozumiem co czytam...

[quote=qluk]Po pierwsze to aby wykorzystac ten blad to trzeba by miec chalupe sprzety, zeby wygenerowac przewidywane klusze w czasie mozliwym do ich uzycia. Po drugie zazwycaj mamy pare kluczy :P[/quote]
Po trzecie kto uzywa Debiana na srodowisku produkcyjnym? :P
Jak juz to: Solaris, AIX, HP-UX, BSD. Linux to na domowe serwerki ew. male rodzime firemki ;)
Tak wiec "dziura" co najmniej nie szkodliwa dla szarego usera.

oczywiście nie macie pojęcia o zagrożeniu.

> trzeba by miec chalupe sprzety, zeby wygenerowac przewidywane klusze

te klucze już zostały dawno wygenerowane. na 31 xeonach zajęło to kilka godzin. latają po sieci. kto pogoogla, ten je sobie znajdzie. jeden 10mb tarball.

co można NA PRZYKŁAD zrobić mając te klucze:

- zalogować się na inną maszynę (NIE MUSI TO BYĆ DEBIAN, WYSTARCZY ŻE UŻYWA KLUCZY WYGENEROWANYCH NA DEBIANIE). sourceforge.net zdaje się że nadal nie zbanowało owych 32768 kluczy i możliwe że właśnie ktoś włamuje się jako maintainer jakiegoś projektu i wrzuca eksplojta do czyjegoś repo SVN. owa luka w debianie BARDZIEJ NIŻ JAKAKOLWIEK INNA dotyczy WSZYSTKIEGO co szyfrowane, a dotykało debiana.

- odszyfrować przechwyconą wcześniej sesję SSH, w której ktoś łączył się do skrzynki z Debianem. jeśli więc np. logowałeś się do maszyny z Debianem via ssh, i z niej logowałeś się do maszyny z np. gentoo, ktoś, kto nagrał twoją sesję może np. zdobyć hasło ZARÓWNO do skrzynki z debkiem jak i gentoo.

> wykryta na parę dni, godzin przed opublikowanie patcha

> Po trzecie kto uzywa Debiana na srodowisku produkcyjnym?

BŁĄD NIE DOTYCZY WYŁĄCZNIE DEBIANA! Dotyczy tak samo gentoo, *BSD, AIXa, a nawet windowsa (jeśli ktoś łączył się do tegoż przez ssh, używając keylogin z kluczem wygenerowanym na debianie). W chwili opublikowania patcha Debian jest jak na razie JEDYNYM systemem który ma ową lukę w miarę załataną.

> Po drugie zazwycaj mamy pare kluczy :P

Tak, w jedną stronę klucz umożliwia zalogowanie się do skrzynki, na której keylogin ustawił jakiś debianowiec (NIEZALEŻNIE jaki system ta skrzynka używa), w drugą stronę umożliwia odszyfrowanie DOWOLNEJ sesji SSH (tej bardziej newralgicznej połowy - tej wpisywanej z klawiatury przy terminalu) połączonej do Debiana między wrześniem 2006 a majem 2008.

Przeraża mnie, że na tym forum [b]chyba mało kto w pełni rozumie zagrożenie[/b].

[quote=debianus_userus]Po trzecie kto uzywa Debiana na srodowisku produkcyjnym? :P
Jak juz to: Solaris, AIX, HP-UX, BSD. Linux to na domowe serwerki ew. male rodzime firemki ;)[/quote]
gwaratuje Ci ze uzywa, np w zestawie Solaris - file serwery, Linux (Debian, Ubuntu, ...) - wszystko inne (i nie jest to spowodowane finansami)

harry666t, bo jak admin jest debilem i zdaje sie na samo ssh to jego problem, robiąc to odpowiedzialnie stawia sie odpowiedni tunel na parze kluczy generowanych dwoma roznymi srodowiskami, a doiero w nim SSH.
A racja nie musi to byc debian, ba anwet nie musza to byc klucze wygenerowane na debianie(!), ale z tego konkretnego pakietu. Nie robimy tutaj dysputy technicznej o algorytmie dzialania wiec uzylem pewnych uproszczeń. Patrzac teoretycznie to luka w bezpieczenstwie jest klawiatura, uzywajac odpowiedniego nadajnika jestes w stanie zdalnie wpisywac tekst (potwierdozne na labach :P).
Racja ze ten blad jest duzym zagrozeniam, ale czy ktos np MITMowal jakies placzenia ssh w 2007 i je zapisywal zeby teraz w 2008 mogl je rozszyfrowac? Juz predzej by z palca wpisal poprawny klucz, niz przewidzial taka sytuacje :)

debianus_userus, jak to solaris nie nadaje sie na file servery? A macierze sanowskie?

Wniosek jest taki, że brak odpowiednich procedur spowodowal powstanie potencjalnego niebezpieczeństwa. Dla tego dyskusje o tym nie powinny byc toczone o zagrezeniu jakie to wprowadzilo bo ono jest jasne, ale o tym jka zapobiec podobnym sytucja.

---

bns, hehe Dilber wymiata :D
Minio, wiem do czego zmierzasz i zgadzam sie z tym ze nawet jesli dev Debianowy chce sam tez latac sobie to powinni miec jakis rodzaj kontrolowania  przed wdrozeniem na szersza skale.