Forum Debian Users Gang

bobycob napisał(-a):

Jacek, BGP wspiera używanie haseł do autoryzacji, ale w praktyce nie jest często używane nawet w dużych (polskich) punktach wymiany ruchu. Są to najczęściej połączenia p2p między routerami do których dostęp mają tylko administratorzy danych routerów. Przy czym standardem jest odpowiednie filtrowanie tras rozgłaszanych na konkretnych połączeniach.
Więc autoryzacja jako taka nie ma tu większego znaczenia.

Co w niczym nie zmienia faktu, że obok DNS, BGP jest najłatwiejszym  celem dla hakerów, którzy chcą puścić ruch do konkretnego segmentu sieci jakąś inną trasą, przez ingerencje w tablice routingu.

Właśnie tak raz cały ruch na FB poszedł przez routery w Chinach.
Po tym incydencie FB wprowadził obowiązkowy SSL.
To nie ten poniższy sznurek, ale jakiś podobny alarm: http://niebezpiecznik.pl/post/do-facebooka-przez-chiny/

Łącznie było podobnych historii wykorzystujących słabości protokołu BGP dosyć dużo.

To weź popraw konfigurację serwerów BGP Facebooka, bo w największej takiej aferze właśnie FB miał zhakowane.

Ja z resztą myślę, że nie tyle "błąd ludzki" co zasada, póki działa, lepiej nie ruszać, dodajmy do tego np brak wsparcia ze strony producenta dla 10 letnich routerów (aktualizacja OS) - bo to się po prostu nie opłaca, czy tygodniowy lub nawet miesięczny obsuw w załataniu dziury w sofcie routera, i gotowe.
Możesz to też nazywać błędem ludzkim, ale ciekaw jestem, kto mając Cisco za 100 tysi jako BGP, sprawdza codziennie strony hakerskie, żeby wiedzieć, czy ktoś nie znalazł w nim dziury, i w razie czego odpina router od sieci czekając kilka dni czy tygodni na aktualizację softu.

Znam jeden router  BGP, który nie był wyłączany od ponad 4 lat, ile w tym czasie się na niego sposobów znalazło, boję się myśleć.
Routery raczej nie mają takiego magicznego mechanizmu, żeby sobie wymieniać cały OS razem z kernelem bez restartu urządzenia.

Ile dziur się znalazło w Linuxie i FreeBSD przez ostatnie 4 latka, w kernelach i sterownikach, czy choćby ważnej bibliotece, np OpenSSL?
OpenBSD też miał kilka ważnych aktualizacji bezpieczeństwa za ten czas.
Z czego powstają OS-y do routerów, wszyscy mniej więcej wiemy.

W Gentusiu za ten czas 2 krytyczne dziury miała biblioteka  Glibc.....
Krytycznych dziur w kernelach i sterownikach nie próbuję nawet liczyć.

Ostatnio edytowany przez Jacekalex (2014-04-11 11:55:54)

remi napisał(-a):

Witam serdecznie. Ciekawy wpis odnośnie problemu zamieścił na swoim blogu pan Bruce Schneier (https://www.schneier.com/). Można przeczytać, bardzo trafne, krótkie podsumowanie: "(...) On the scale of 1 to 10, this is an 11". Klucze użytkowników, klucze prywatne SSL, cokolwiek - jest podatne na ten katastrofalny błąd w OpenSSL. Na blogu, znajduje się również odnośnik do strony Heartbleed test (więcej: heartbleed.com), która - w założeniu - sprawdzić ma podatność danego hosta, czy serwera w odniesieniu do informacji zawartych w zgłoszeniu CVE-2014-0160 (będącego oficjalnym odniesieniem do tego błędu).

Pozdrawiam.

dobrze, że mój bank nie jest podatny na to. ufff. sprawdzałem też 3 dni temu i było okej.

Jacek demonizujesz problem. Router BGP jest urządzeniem świadczącym specyficzną usługę a nie mydło i powidło. Jeżeli wychodzi w nim problem to jest on najczęściej po stronie usługi która i tak powinna mieć dostęp zewnętrzny zablokowany. W przypadku Facebook raczej nie ma co poprawiać, nie mają większego wpływu na manipulacje trasami routingu w głębi sieci. Ewentualnie Administrator może sobie zadzwonić wymienić uprzejmości z administratorem routerów TGF. :)

Ostatnio edytowany przez bobycob (2014-04-11 15:15:43)

menel napisał(-a):

tor jak na razie nie do użytku
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160

Wszystko zależy od tego co nim przesyłasz i przed kim chcesz to ukryć... Nie każdy korzystający z Tora popełnia jakieś przestępstwa przez niego, czy to naprawdę trzeba wyjaśniać? Jeśli mamy taką sytuację, że ktoś chce wejść na stronę https w clearnecie przez Tora to nie wiem dlaczego używanie Tora miałoby być dla niego bardziej niebezpieczne niż wejście na nią bezpośrednio - nawet jeśli Tor byłby w 100% monitorowany (chociaż nie uważam, że tak jest).

Co do błędu:
1. Dane od klienta przez serwer nie powinny być uznawane za bezpieczne źródło informacji.
2. Rozszerzenie Heartbeat wymaga, że w celu przedłużenia połączenia szyfrowanego, które nie było od jakiegoś czasu używane, co jakiś klient ma wysłać dane, a serwer ma te dane odesłać. Dane te są wysyłane w postaci struktury, która ma m.in. liczbę, którą klient informuje serwer jak dużo danych przesyła.
Jest sobie bufor, który jest w pamięci zaalokowany na tyle bajtów, na ile zadeklarował klient w połączeniu w tej strukturze danych. Tutaj nie ma błedu, więc najwyraźniej gdzieć jest sprawdzenie wielkości. Ten bufor ma być odesłany z serwera do klienta z danymi. W kodzie OpenSSL z odebranej struktury dane są kopiowane nowo zaalokowanego bufora. W OpenSSL ilość kopiowanych danych jest zdefiniowana przez zmienną odebraną od klienta... Jeśli klient wyśle niewiele danych, np. 1 bajt i jednocześnie wyśle informacje o tym, że wysłał tych danych więcej to wtedy pamięć kopiowana będzie oczywiście najpierw zaalokowanym buforem, ale potem pamięć kopiowana będzie już zza tego bufora. Za buforem kryją się inne dane m. in. może tam być klucz prywatny, więc kopiując dane można właśnie skopiować klucz prywatny.
W OpenBSD za pomocą standardowej funkcji przydzielającej pamięć zmienne są umieszczane w pamięci losowo, a pomiędzy buforami jest przerwa - niezaalokowana pamięć. Próba odczytania czy zapisu niezaalokowanej pamięci kończy się w OpenBSD ubiciem programu. Programiści OpenSSL jednak stworzyli własną funkcję przydzielającą pamięć i dlatego bufor nie jest od reszty odgrodzony niezaalokowaną pamięcią...

Ostatnio edytowany przez uzytkownikubunt (2014-04-11 18:43:29)

menel napisał(-a):

oczywiście mówię o użyciu tora jak ktoś chce zachować pełną anonimowość, jest to teraz niebezpieczne po prostu...

Nie każdy korzystający z Tora popełnia jakieś przestępstwa przez niego, czy to naprawdę trzeba wyjaśniać

Wiesz niektórzy są po prostu "zmuszeni" do używania tora i wcale nie popełniają przestępstw czy to trzeba wyjaśniać ? A ujawnienie ich tożsamości może nieść za sobą poważne konsekwencje np. ludzie w Chinach, przeciwnicy reżimów w krajach totalitarnych itp itd...

Mało tego śmiem sądzić, że jeżeli agendy wiedziały o dziurce (a jestem w 90% pewny, że to ich sprawka) z pewnością jednym z ich głównych zainteresowań był tor..I nie jest on już niestety w żadnym wypadku bezpieczny...

Musiałyby masowo i regularnie przeprowadzać atak Heartbleed na wiele węzłów sieci Tor by coś zdziałać. Z jednej strony atak trudno wykryć, ale z drugiej strony gdyby przeprowadzać go na tak masową skalę?

dobrze, że mój bank nie jest podatny na to. ufff. sprawdzałem też 3 dni temu i było okej.

Właśnie, mnie to zastanawia, czemu banki nie są na to podatne. Wyobrażacie sobie, co to by było gdyby były podatne, apokalipsa. xD

Nie podano jaki.

w telewizji nie podano...
https://bank.gb24.pl/

podobno jeszcze mbank wiesz możliwe, że było więcej (a żaden porządny portal czy tym bardziej tv nie oskarży banku bez jednoznacznych dowodów, bo wiadomo jak to się skończy... Nie trudno się domyślić, że żaden z dziurawych banków się nie przyznał, expresowo załatał dziurę i zatuszował sprawę...ja i tak zmieniłem hasło dla świętego spokoju w swoim...

pS w telewizji mówią to co chcesz usłyszeć niestety..

Ostatnio edytowany przez menel (2014-04-11 19:57:08)

enether napisał(-a):

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?

Z tego co wiem to tak.

apka1 z jakimiś danymi

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* gcc secret.c -o secret */

/* dane naszej appki */
typedef struct {
    int secretnum;
    char *password;
} secret_t;

/* inicjalizacja tych danych */
static void secret_init(secret_t *s) {
    s->password = strdup("Haslo");
    s->secretnum = 12345;
}

/* do czyszczenia po sobie */
static void secret_free(secret_t *s) {
    free(s->password);
    s->password = NULL;
}

/* pokazuje adresy w pamieci naszych danych */
static void secret_addr(secret_t *s) {
    printf("struktura: %p\n",s);
    printf("secret num: %p\n",&s->secretnum);
    printf("password: %p\n",&s->password);
}

int main(void) {
    /* dane na stosie */
    secret_t onstack;
    secret_init(&onstack);

    /* dane na stercie */
    secret_t *onheap = malloc(sizeof(secret_t));
    secret_init(onheap);

    /* pokazujemy addresy */
    secret_addr(&onstack);
    printf("=====STERTA:=====\n");
    secret_addr(onheap);

    getchar();
    /* sprzatamy po sobie pamiec */
    secret_free(&onstack);
    secret_free(onheap);
    free(onheap);
    return 0;
}

appka2 ,która na podstawie adresu próbuje to odczytac

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* gcc getsecret.c -o getsecret */

typedef struct {
    int secretnum;
    char *password;
} secret_t;

static void secret_get(secret_t *s) {
    printf("%s\n",s->password);
    printf("%d\n",s->secretnum);
}

int main(void) {
    /* int z danego adresu */
    printf("podaj adres secretnuma\n");
    int *iptr;
    scanf("%p",&iptr);
    printf("%d\n",*iptr);

    /* cala strukturka z danego adresu */
    /*
    secret_t *sptr;
    while(scanf("%p",&sptr)==1)
        secret_get(sptr);
    */
    return 0;
}

(uruchamiane z valgrindem). Nie czytałem tego całego, ale jak napisali własnego malloca i tam ta dziura to to śmierdzi na odległość.

dominbik napisał(-a):

Nie czytałem tego całego, ale jak napisali własnego malloca i tam ta dziura to to śmierdzi na odległość.

To znaczy w ich mallocu nie ma błędu (przynajmniej nie biorą one udziału w tym ataku), ale nie ma też on zabezpieczeń (które jednak nie są wymagane przez chociażby standard C, według standardu trzeba pisać poprawnie). Natomiast w kodzie popełniono standardowy błąd przy operacji memcpy i bez tych zabezpieczęń kończy się to wysłaniem kawałka pamięci.
Wydaje mi się, że takie własne implementacje zarządzania pamięci w dużych projektach często są tworzone. Zwiększają wydajność. Na pewno Firefox taką ma taki, w tamtym roku implementacja nazywała się jemalloc. Można było wyłączyć podczas kompilacji dodając do .mozconfig linię ac_add_options --disable-jemalloc ale czy wtedy pamięć była zarządzana normalnie? Tego nie wiem.

gindek napisał(-a):

menel napisał(-a):

tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...

Ty w to wierzysz? serio?

Zdecydowali się na stworzenie furtki to tak...

Jak mowi stare powiedzenie kazdy duzy projekt w C zaczyna sie od napisania managera pamieci oraz loggera ;-).
Dlaczego się używa czegos wiecej niz malloc ?

A no z wielu powodów, np. performance, debuggowania czy po prostu wygoda.
Zeby być bardziej konkretnym:
1. performance - malloc + free są wolne, jezeli masz duzo danych do allokowania ktore moga byc umieszczone w podobnej strukturze a chcesz zeby program dzialal szybko, mozesz "na poczatku" przy starcie allokowac N elementów, umiescic je w jakims kontenerze a potem kozystac w miare potrzeby. Oczywiscie z tego wynika ze one stale zajmuja pamięc.
2. debuggowanie - przydatne sa wlasne allokatory bo pozwala ci kontrolowac ilosc zaalokowanej pamieci, oraz informowac kiedy ktorys blok nie zostal zwolniony, pomaga to wyłapywac memory leak, ktore de facto sa trudne do wylapania (widzialem tez takie zastosowanie z file descriptors).
3. wygoda - czasem objekt / struktura posiada zagniezdzone wskazniki/pola kktore tez musza byc allokowane, wtedy zamiast uzywac bloku "malloc" wrzucasz to do funkcji, wlasnego allokatora, ktory wykonuje ta operacje.

Nie ma wygodnego szblonu kiedy stosowac swoje allokatory kiedy nie, kiedy uzywac danych statycznych w stablicach a kiedy nie. Zawsze jest to kwestia wyboru programisty w zaleznosci od zadanego problemu.





Co do samego banku ktory byl podatny, w dniu publickacji ... mbank byl podatny :-). No ale połatali się.

Patrzac w druga strone claudflare chwali sie ze nie byli podatni "w dniu premiery" bo mieli cynk wczesniej :-).

Tylko, że takie alokatory są niebezpieczne. Deweloperzy OpenSSL powinni szczególnie uważać, bo na bezpieczeństwie ich kodu opiera się bezpieczeństwo dużej części Internetu. Spadek wydajności? W przypadku OpenSSL powinno powiedzieć się trudno i wydać trochę więcej na sprzęt. W przypadku debugowania - też da się znaleźć memory leak za pomocą odpowiedniego oprogramowania np. Valgrind, do LLVMa też jest jakieś narzędzie.

Ted Unangst napisał(-a):

But it’s absolutely infuriating when developers of security sensitive software are actively thwarting those efforts by using the world’s most exploitable allocation policy and then not even testing that one can disable it.

Sean Cassidy napisał(-a):

I'm a fan of C. It was my first programming language and it was the first language I felt comfortable using professionally. But I see its limitations more clearly now than I have ever before.

Between this and the GnuTLS bug, I think that we need to do three things:

    Pay money for security audits of critical security infrastructure like OpenSSL
    Write lots of unit and integration tests for these libraries
    Start writing alternatives in safer languages

Given how difficult it is to write safe C, I don't see any other options. I would donate to this effort. Would you?