Różowy blog
Na typowym desktopie zwykle niezbędny jest flash, najlepiej ten od Adobe. W Debianie sprawę załatwia instalacja pakietu flashplugin-nonfree, który zajmuje się dostarczeniem flasha. Wszystko działało pięknie i bezbłędnie, aż do wczoraj. Przy okazji porządków w systemie ojca postanowiłem dokonać aktualizacji flasha i... pojawiły się problemy. Przy okazji przyjrzałem się bliżej narzędziom i znalazłem parę "śmiesznostek/żałostek".
Patrzę na to, co się dzieje po ogłoszeniu błędu ze słabymi kluczami i jestem przerażony. Próbkę mam znikomą, ale generalnie administratorzy nie przejmują się błędem zupełnie - albo robią upgrade samej paczki (w przypadku Debiana upgrade openssh jest o tyle dobry, że automatycznie wykrywa znane słabe klucze serwera), co nie rozwiązuje problemu, bo słabe klucze już są wygenerowane, albo czekają (nie wiem na co...). A tymczasem konsekwencje dotyczą nie tylko Debiana, ale i innych systemów z dostępem przez SSH, a liczba kluczy, które były generowane na dotkniętych błędem systemach Debiana to tylko 32767[1] dla każdej długości klucza (dla lepszego zobrazowania - trzyliterowe hasło składające się z samych liter daje podobne zabezpieczenie), a hasło na klucz niczego nie zmienia (bo wersja niezabezpieczona zawiera się w tych 32 tysiącach).
Problem nie dotyczy tylko Debiana, ale wszystkich systemów, na których użytkownicy Debiana mogli ustawić słaby klucz jako zaufany. No i tu pora na narzekanie - żaden administrator systemu (brak jakichkolwiek restrykcji w dostępie via SSH) na których dodałem swój słaby klucz nie zareagował - usunąłem klucze samodzielnie. Ilu użytkowników jeszcze dodało tam słabe klucze - nie wiem. Wiem, że aktualnie w Debianie pojawiło się narzędzie ssh-vulnkey, które po wywołaniu ssh-vulnkey -a sprawdza wszystkie standardowe lokalizacje (także authorized_keys użytkowników) w poszukiwaniu słabych kluczy - zachęcam do skorzystania z niego i przeportowania na inne systemy.
Tak czy inaczej wygląda na to, że ogólnie poziom bezpieczeństwa w IT drastycznie spadnie. Niebawem będzie w użyciu masa skompromitowanych systemów, słabych certyfikatów itd., a ten problem dotyczy nie tylko administratorów, ale wszystkich użytkowników komputerów.
[1] źródło
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...
W Debianie (i jego pochodnych) pojawił się paskudny błąd w pakiecie OpenSSL. Nie dotyczy to innych dystrybucji (chyba, że ktoś zaimportował klucze generowane na Debianie), oraz Sarge. Błąd w pakiecie OpenSSL powoduje, że generator liczb pseudolosowych jest przewidywalny. Zalecana jest aktualizacja pakietu i wygenerowanie wszystkich kluczy, które były generowane z użyciem OpenSSL od nowa. Zaleca się też uznanie kluczy DSA używanych na takich systemach za skompromitowane.
Źródło i więcej szczegółów: dsa-1571
"Firefox to spyware" tak pewnego razu na kanale #debian.pl w sieci IRCnet obwieściła nie znana mi osoba obwieścił Big_Brain. Potraktowałbym to luźno, ale rozmówca był konkretny i sensowny. Przy okazji trąbienia o rosnącej popularności Firefoksa i zaślepionego czy może raczej naiwnego podejścia do wolnego oprogramowania sprawa mi się przypomniała, więc pokrótce ją streszczę.
Jeśli ktoś ma udostępniony "na świat" serwer FTP na modemie Livebox, to niech się strzeże, bowiem odkryto lukę, która pozwala na pewno na zawieszenie serwera FTP, a być może także na zdalne wykonanie kodu.
Oto źródło tej informacji (plus szczegóły) , a tu exploit pozwalający sprawdzić czy nasz modem jest podatny.
PS. W sumie niby żaden news, bo na milw0rmie było od 1 marca. Ale że neostrada to popularna usługa, to im więcej osób wie, tym lepiej...
Domyślnie Java jest rozpowszechniana w wersji z ograniczoną siłą szyfrowania (zapewne niesławne ograniczenia dotyczące eksportu technologii krypograficznych z USA). Przeciętnemu użytkownikowi ciężko zauważyć różnicę, ale niedawno jeden z programów stwierdził, że hasło to może być do 8 znaków, albo muszę zdjąć limity w Javie.
Samo usunięcie ograniczeń polega na pobraniu ze strony Suna pliku zip z o nazwie Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 (tu: dla wersji 5.0 - jakoś do niej przywykłem, dla wersji 6.0 istnieje analogiczny plik) i rozpakowaniu go do stosownego katalogu, w przypadku Debiana i Javy zrobionej make-jpkg - do /usr/lib/j2re1.5-sun/lib/security/
Oczywiście nic nie stoi na przeszkodzie, by skorzystać z make-jpkg i zrobić paczkę z Javą, a następnie skorzystać z opisnego kiedyś sposobu i wprowadzić modyfikacje (tu: zmiana plików) w tejże paczce. Ponieważ tak jest elegancko i Debian way - polecam.
PS. Zamiast bawić się w samodzielne paczkowanie sunowskiej javy można skorzystać z pakietu sun-java5-jre i okolicznych znajndujących się w sekcji non-free oficjalnego repozytorium. Bez JCE, z tego, co widzę (i czasami bez update'ów od Suna, przynajmniej jakoś długo trzeba było czekać, ale jeśli nam to nie przeszkadza, to sposób dodania JCE jest analogiczny.
We wpisie o haśle dla screen mamy ładnie wyjaśnione jak założyć hasło dla aktualnego screena. Można jednak pójść o krok dalej i każdego uruchamianego screena zabezpieczać automatycznie hasłem (jednym, domyślnym).
W tym celu należy w .screenrc w katalogu domowym usera umieścić linijkę z zakodowanym hasłem:
# This is how one can set a reattach password: # password ODSJQf.4IJN7E # "1234"
Od tej chwili każdy nowouruchamiany screen będzie zabezpieczony hasłem.
Aby utworzyć zakodowane hasło naprościej użyć htpasswd:
htpasswd -n test
Podajemy hasło dwukrotnie, otrzymujemy ciąg w stylu
test:DgVb/mZOaJTVs
Od dwukropka mamy nasze zakodowane hasło, które umieszczamy w .screenrc.
PS. Oczywiście to tylko domyślne hasło, które zawsze można zmienić korzystając ze sposobu opisanego we wspomnianym linku
Natura nie znosi pustki, a ja nie znoszę, jak się procesor marnuje, więc po tym, jak po utracie paru m-cy obliczeń zrobiłem sobie przerwę z mprime, zacząłem bawić się w łamanie szyfru z drugiej wojny światowej, czyli odkodowywanie ostatnich czterech (obecnie trzech) nieznanych wiadomości kodowanych Enigmą. Projekt to M4 Project. Obliczeń nie ma zbyt wiele, myślę, że w parę tygodni projekt się skończy, szczególnie, że liczba uczestników gwałtownie rośnie. Dostępny klient na większość systemów operacyjnych.
Baaardzo fajna rzecz, ten knockd. W skrócie: po otrzymaniu określonej sekwencji określonych pakietów na określonych portach, wykonuje określoną akcję, w szczególności otwiera port na firewallu. I to działa nawet przy załączonym policy DROP na INPUT.
Chyba to postawię sobie tak porządnie skonfigurowane, bo wczoraj to tylko krótka zabawa była. W końcu dostęp do maszyny mam mieć tylko ja, a po co oglądać wpisy w logach, jak to się próbują logować na test, admin, guest itp.? ;-)
