Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#26  2014-04-11 10:17:56

  mati75 - Psuj

mati75
Psuj
Skąd: default city
Zarejestrowany: 2010-03-14
Serwis

Re: Dziura w openssl

http://xkcd.com/1354/


[img]https://l0calh0st.pl/obrazki/userbar.png[/img]

Offline

 

#27  2014-04-11 10:36:49

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

[quote=bobycob]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.[/quote]
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.


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#28  2014-04-11 10:40:42

  bobycob - Członek z Ramienia

bobycob
Członek z Ramienia
Skąd: Wrocław
Zarejestrowany: 2007-08-15

Re: Dziura w openssl

Zerknij proszę jeszcze na poprzedni wpis w miedzy czasie go zmodyfikowałem.
BGP wcale nie jest łatwy do zaatakowania. Na pozór łatwym się wydaje. Jednak trzeba trafić najpierw bezpośrednio na któryś za ważnych węzłów, a router od byle kogo nie przyjmuje informacji o aktualizacjach tras. W praktyce jak chcesz coś nagle rozgłosić to jesteś bez szans. Jak trafisz na główny router z błędami w oprogramowaniu to może być realne dopiero.

Myślę, że największą słabością BGP jest podatność na błąd ludzki.

Ostatnio edytowany przez bobycob (2014-04-11 10:55:41)

Offline

 

#29  2014-04-11 11:51:44

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Dziura w openssl

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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#30  2014-04-11 12:36:29

  remi - amputować akrobatów

remi
amputować akrobatów
Zarejestrowany: 2011-05-27

Re: Dziura w openssl

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

Pozdrawiam.


[color=#5B5B5B][tt][b]Ł[/b][i]a[/i]m[/tt] [tt][b][i]Z[/b][/i]As[i]a[/i]d[b][/tt][tt]y[/tt][/b][b]![/b] w[i]Y[/i][b]j[/b][b]ą[/b]Tk[i][b]Ó[/b][/i][b]w[/b] [tt][i]j[/i][b]e[i]s[/i][/b]t[/tt] w[tt][b][/b]I[b][i]ę[/i][/b][/tt]c[b]e[i]j[/i][/b][/color].

Offline

 

#31  2014-04-11 13:28:00

  sysek - Użytkownik

sysek
Użytkownik
Skąd: Łorsoł
Zarejestrowany: 2010-06-28
Serwis

Re: Dziura w openssl

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

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


zakochałem się po uszy.

Offline

 

#32  2014-04-11 13:35:56

  yossarian - Szczawiożerca

yossarian
Szczawiożerca
Skąd: Shangri-La
Zarejestrowany: 2011-04-25

Re: Dziura w openssl

Ta strona z testem chyba nie jest do końca wiarygodna.

Offline

 

#33  2014-04-11 15:06:10

  bobycob - Członek z Ramienia

bobycob
Członek z Ramienia
Skąd: Wrocław
Zarejestrowany: 2007-08-15

Re: Dziura w openssl

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)

Offline

 

#34  2014-04-11 15:06:40

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

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

More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.Maybe we'll need to throw away our torproject SSL web cert and get a new one too.[/quote]
[b]Maybe[/b] we'll ? prędzej napisałbym [b]We will sure..[/b]...

Offline

 

#35  2014-04-11 18:06:36

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=menel]tor jak na razie nie do użytku
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160[/quote]
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)

Offline

 

#36  2014-04-11 18:29:46

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

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ć[/quote]
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 99% 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, teoretycznie może to nawet być początek jego końca a jak wiadomo tor zawsze był pryszczem na dupie agent typu NSA itp i zawsze agendy te dążyły do tego żeby mieć nad nim kontrolę......

Ostatnio edytowany przez menel (2014-04-11 18:47:49)

Offline

 

#37  2014-04-11 18:47:42

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=menel]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ć[/quote]
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...[/quote]
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ę?

Offline

 

#38  2014-04-11 18:51:24

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

Moim zdaniem wysoce prawdopodobne jest, że tor jest całkowicie spalony w tym momencie...

Offline

 

#39  2014-04-11 19:21:40

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Dziura w openssl

dobrze, że mój bank nie jest podatny na to. ufff. sprawdzałem też 3 dni temu i było okej.[/quote]
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

Offline

 

#40  2014-04-11 19:24:00

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=morfik]

dobrze, że mój bank nie jest podatny na to. ufff. sprawdzałem też 3 dni temu i było okej.[/quote]
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[/quote]
Jak słuchałem w TV to podobno jeden bank w Polsce był podatny, ale bardzo szybko załatano lukę po informacji o wykryciu. Nie podano jaki.

Offline

 

#41  2014-04-11 19:28:22

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

Nie podano jaki.[/quote]
w telewizji nie podano...
https://bank.gb24.pl/

Offline

 

#42  2014-04-11 19:35:39

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=menel]

Nie podano jaki.[/quote]
w telewizji nie podano...
https://bank.gb24.pl/[/quote]
W czasie tego programu, którego słuchałem nie podano. A że słuchałem w ostatnich 4 miesiącach TV i radia łącznie przez 8 minut to może coś przeoczyłem.

Offline

 

#43  2014-04-11 19:44:10

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

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)

Offline

 

#44  2014-04-11 20:07:24

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

Released version of LibreOffice 4.2.3 adds a security fix for the Heartbleed Bug (CVE-2014-0160).

Offline

 

#45  2014-04-11 21:28:44

  dominbik - Członek DUG

dominbik
Członek DUG
Zarejestrowany: 2011-07-25

Re: Dziura w openssl

[quote=enether]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?[/quote]
Z tego co wiem to tak.

apka1 z jakimiś danymi

Kod:

#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

Kod:

#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;
}

[url=http://img703.imageshack.us/img703/8264/0voc.png][img]http://img829.imageshack.us/img829/1507/9kpq.png[/img][/url]
(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ść.


[img]http://img34.imageshack.us/img34/5092/zw9m.png[/img] [img]http://img29.imageshack.us/img29/219/pibw.png[/img]

Offline

 

#46  2014-04-11 22:06:27

  menel - Użytkownik

menel
Użytkownik
Zarejestrowany: 2013-11-02

Re: Dziura w openssl

Pytanie kto? co? i ile? wyciągnął przez te dwa latka...

Offline

 

#47  2014-04-11 22:14:27

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=dominbik]Nie czytałem tego całego, ale jak napisali własnego malloca i tam ta dziura to to śmierdzi na odległość.[/quote]
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.

Offline

 

#48  2014-04-12 17:15:24

  gindek - Zubr, bydle na etacie.

gindek
Zubr, bydle na etacie.
Skąd: Z puszczy.
Zarejestrowany: 2008-12-08

Re: Dziura w openssl

[quote=menel]

tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...[/quote]
Ty w to wierzysz? serio?

Zdecydowali się na stworzenie furtki to tak...[/quote]
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 :-).

Ostatnio edytowany przez gindek (2014-04-12 17:16:34)


" Wojny przychodzą i odchodzą, a moi żołnierze są wieczni"


"Zbuduj mały, dziarski router z udostępnionych przez prowadzącego części od Kamaza?"

Offline

 

#49  2014-04-12 18:01:21

  uzytkownikubunt - Zbanowany

uzytkownikubunt
Zbanowany
Zarejestrowany: 2012-04-25

Re: Dziura w openssl

[quote=gindek][quote=menel]

tylko autorzy OpenSSL zdecydowali się na stworzenie własnych niestandardowych funkcji do zarządzania pamięcią...[/quote]
Ty w to wierzysz? serio?

Zdecydowali się na stworzenie furtki to tak...[/quote]
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 :-).[/quote]
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.

[quote=Ted Unangst]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.[/quote]
[quote=Sean Cassidy]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?[/quote]

Offline

 

#50  2014-04-12 22:06:52

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Dziura w openssl

Takie jeszcze coś mi wisi na rss, to wrzucam: https://www.youtube.com/watch?v=0VINVpBScyg -- 2h gadania o tej dziurze.

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
To nie jest tylko forum, to nasza mała ojczyzna ;-)

[ Generated in 0.012 seconds, 11 queries executed ]

Informacje debugowania

Time (s) Query
0.00010 SET CHARSET latin2
0.00007 SET NAMES latin2
0.00113 SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.97.9.170' WHERE u.id=1
0.00088 UPDATE punbb_online SET logged=1733665148 WHERE ident='18.97.9.170'
0.00046 SELECT * FROM punbb_online WHERE logged<1733664848
0.00077 SELECT topic_id FROM punbb_posts WHERE id=263000
0.00007 SELECT id FROM punbb_posts WHERE topic_id=25583 ORDER BY posted
0.00052 SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25583 AND t.moved_to IS NULL
0.00005 SELECT search_for, replace_with FROM punbb_censoring
0.00387 SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25583 ORDER BY p.id LIMIT 25,25
0.00080 UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25583
Total query time: 0.00872 s