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
#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
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
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
Informacje debugowania
| Time (s) | Query |
|---|---|
| 0.00009 | SET CHARSET latin2 |
| 0.00004 | SET NAMES latin2 |
| 0.00085 | 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='3.145.81.252' WHERE u.id=1 |
| 0.00072 | UPDATE punbb_online SET logged=1732195058 WHERE ident='3.145.81.252' |
| 0.00044 | SELECT * FROM punbb_online WHERE logged<1732194758 |
| 0.00045 | 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.00332 | 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.00079 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25583 |
| Total query time: 0.00675 s | |