Forum Debian Users Gang

Było w CB dzisiaj rano.

A na społeczność możesz nie miauczeć, ciekawe, jak często szacowni producenci  routerów z VPN zapewniają łatki dla swoich systemów, na których chodzą miliony ich urządzeń.

Po ataku na serwery BGP, kiedy cały FB leciał przez Chiny, jakoś nie zauważyłem, żeby był dużo większy ruch w aktualizacjach softu na routery.

PS
Czy W BGP dalej używa się haseł hashowanych md5?

Pytam, bo sam podsłuch szyfrowania SSL na wiele się nie zda, jeśli ten szyfrowany sygnał nie leci przez infrastrukturę do podsłuchu, więc trzeba do tego zrobić jeden z dwóch ataków, albo włamanie na DNS, co łatwo wykryć i przeciwdziałać, albo włamanie na BGP, gdzie można zdecydować o przekierowaniu milionów pakietów przez inną część sieci, czego wielu ludzi nie zauważy w ogóle.
Bo niby kto pamięta, że pingi do banku, to 21,3 ms, i zacznie alarm, kiedy będą wynosić 134,7ms.

Ostatnio edytowany przez Jacekalex (2014-04-08 20:49:42)

Żadnego łatania paczkami z sida...

Od tego są poprawki na paczki w gałęzi security by z nich korzystać ;) I jak rano serwery łatałem już była poprawiona wersja dla Wheezy'ego.
https://www.debian.org/security/2014/dsa-2896

Tak przy okazji, znacie jakieś automatyczne skrypty, które bez specjalnego angażowania administratora, automatycznie wygenerują nowy
RootCA i certy dla poszczególnych usług?

Zamierzam sobie coś podobnego skołować albo wyrzeźbić, i zastanawiam się, czy użyć expecta, czy kombinować z perlem.

W standardowych openssl, ca.pl trzeba co chwila tłuc hasła, potwierdzać informacje, potem na jednej maszynie jest pół godziny pieprzenia.

[UWAGA]
Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL, żeby być pewnym bezpieczeństwa usług.
Skąd pewność, że cert prywatny nie wyciekł na starej wersji biblioteki? i nie fruwa gdzieś na necie?
[/UWAGA]

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-04-08 21:00:46)

E tam, ja nie miauczę. xD No ale 2 lata? xD

Ile kodu sam zweryfikowałas?

Ja nie umiem kodzić, więc to pytanie nie do mnie, tylko do tych co się w tym orientują, a ci jak jeden mąż mówią, że ktoś to weryfikuje. xD To jest największy problem open source i zarazem fałszywe poczucie bezpieczeństwa, że ktoś się doszuka, że ktoś znajdzie, problem w tym, że niewielu w ogóle sobie głowę tym zawraca, oczywiście z tych niezrzeszonych z danym projektem. I to jest fakt.

Nie wiem, czy ktoś zauważył, ze poza aktualizacją, trzeba by na nowo wygenerować wszystkie certy do serwerów używających biblioteki OpenSSL,

No skoro przez 2 lata można było sobie pozyskać taki cert z servera, to raczej trzeba wymienić. Póki co, to google i riseup zmienili do poczteksa i jabbera, przynajmniej tyle mi wyrzuciło jak n arazie.

Cześć. W sieci dostępny jest ciekawy plik, dokument z dn. 24.go lutego ilustrujący: "(..,) a vulnerability introduced to elliptic curve cryptographic protocols when implemented using a function of the OpenSSL cryptographic library". Artykuł - wraz ze szczegółowymi informacjami - stworzony przez Yuval Yarom oraz Naomi Benger, znajduje się pod adresem; http://eprint.iacr.org/2014/140 ("Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack").

http://article.gmane.org/gmane.os.openbsd.misc/211963
Theo de Raadt - założyciel i przewodniczący projektów OpenBSD i OpenSSH o luce w OpenSSL.
BTW OpenSSH, pomimo tego że korzystało z dziurawej wersji OpenSSL, jest odporne na atak Heartbleed. Niestety nie oznacza to, że wszystko programy korzystające z OpenSSL w OpenBSD są na niego odporne...

@menel
Jest hipoteza informatyczna, według której poprawiając kod - tworzysz kolejnego buga

Niemniej osobiście nie widzę problemu - HTTPS NIGDY nie był bezpieczny

Fervi

Ostatnio edytowany przez fervi (2014-04-10 20:39:52)

Abstrahując od tego czy jest to backdoor złych trzyliterowych agencji, błąd programistyczny czy działania jaszczurzych żydomasonów chciałem poinformować tych którzy jeszcze ni e zauważyli że nie tylko serwery są podatne ale i klienci którzy mieli pecha trafić na złośliwy serwer ;)

Swoją drogą, o ile się nie mylę i pamiętam dobrze to i owo o architekturze pamięci procesów w Linuxie to pamięć jądra jak i  każdego z procesów z osobna jest separowana, nawet na jądrze które ominęło błogosławieństwo grseca. Tak?

Technicznie w przypadku korzystania z 2 factor auth to posiadanie hasła to tylko połowa sukcesu.

Anyway... ktoś coś lepiej kojarzy w temacie architektury pamięci? Bo wybitnie nie mam dziś sił się przebijać przez tony opracowań naukowych.

@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-ope … eed-bug.html/  <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963

uzytkownikubunt napisał(-a):

@Jacekalex tutaj jest wszystko opisane:
http://blog.existentialize.com/diagnosis-of-the-ope … eed-bug.html/  <- serwer pokazuje błąd, ale cache Google'a ciągle trzyma stronę
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Zabezpieczenia grsecurity czy w OpenBSD powinny bez problemu wyłapać błąd w normalnym kodzie C, tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...
http://article.gmane.org/gmane.os.openbsd.misc/211963

Bzdury piszesz.

Grsecurity, a zwłaszcza zawarty w nim PAX dodaje solidnych mechanizmów obronnych, jak Mprotect czy Randustack, ale nie ingeruje w samo działanie aplikacji, jeśli aplikacja pod kontrolą wykonuje swoją robotę, to Grsec/Pax nie widzi nic groźnego.
Wszystkie zabezpieczenia typu Grsec/pax dotyczą działania exploitów atakujących aplikacje w przestrzeni pamięci RAM, ale nie ubezpiecza na wypadek celowego czy przypadkowego błędu w działaniu aplikacji, jak w przypadku biblioteki OpenSSL.

Takie rzeczy w przypadku OpenSSH i tuneli VPN potrafi wykrywać Snort przy pomocy specjalnych dekoderów, sprawdzających, jaka ilość danych nieszyfrowanych poprzedza nawiązanie szyfrowanego połączenia.

Natomiast twierdzenie, że większość  "dużych" serwerów chroni Grsec, czy jest tam OpenBSD, to ciężka naiwność, raczej mega pro systemy korporacyjne jak RHEL czy SUSE, gdzie takie ekstremalne zabezpieczenia "nie są potrzebne".

Tutaj nawet nie było senso-stricte backdoora, pozornie OpenSSL działał prawidłowo, tylko zamiast klucza publicznego wysyłał nieszyfrowanym strumieniem 65535 bitów danych, zawierających również klucz prywatny serwera.
Z punktu widzenia modułu Grsec czy systemu ACL to nie był błąd, tylko FEATURE aplikacji.

Fajnie byłoby wiedzieć, skąd w OpenSSL się taki FEATURE znalazł,
ale jak wiadomo, różne Mukhbaraty mają długie ręce.
To mogło być FBI czy NSA (amerykańskie),  rosyjskie FSB, Chińczycy, albo ktokolwiek inny.

Ostatnio edytowany przez Jacekalex (2014-04-11 02:14:49)

Przeczytałem, inna sprawa, czy w to wierzę.
Identyczny błąd może się powtórzyć np w SSH czy jakimś VPNie, może też w samej bibliotece OpenSSL wyleźć w innym miejscu, inaczej "zaimplementowaną" metodą.
Jak zajrzysz do reguł Snorta przeznaczonych do kontrolowania protokołu SSH, to tam zauważysz inspekcję liczby nieszyfrowanych danych wysyłanych przez serwer SSH przed rozpoczęciem szyfrowania transmisji.

To praktycznie jedyna metoda, aby w przyszłości tak pilnować, czy SSL nie wysyła więcej nieszyfrowanych danych, niż powinno.

Nawiasem pisząc, GnuTLS też ciągle łapie mniejsze lub większe wtopy z bezpieczeństwem, jak ostatnio z tą walidacją certyfikatu.

Ostatnio edytowany przez Jacekalex (2014-04-11 09:45:24)