Nekdo by mohl argumentovat - a co MS08-067? Chyba MS08-067 sice umoznovala vzdalene spustit kod, ale jen pokud byly do internetu vystrceny porty, ktere tam nemaji co delat. Tohle (https://news.ycombinator.com/item?id=7576389) je trochu jine kafe…
No tohle je na urovni exploitu v prohlizeci, ktere jsou (bohuzel) bezne. Utocnik musi dosahnout toho, ze obet navstivi kompromitovany web…
Prijde mi, ze na tuto knihovnu "nejakeho Jendy" bylo spolehano zejmena proto, ze to pouzivaji vsichni, tak to musi byt ok. http://permalink.gmane.org/gmane.comp.security.cryptography.randombit/3341: "Overall, I would say that yes, OpenSSL is a huge mess for application
developers. In that sense, it's very bad. On the other hand, it's the
most thoroughly reviewed open source crypto implementation, and hasn't
had very many security bugs found in the library per se. " Toto ("most thoroughly reviewed open source crypto implementation") byla asi jen dobra vira…
Jinak by tohle nezustalo 2 roky nepovsimnute:
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
// hodnotu promenne payload kontroluje utocnik
Moc by som sa netesil ak MS este nema zadne vratka tak ich urcite dostane. Preco? Sloboda nieco stoji a na vychode je taka krajina kde ludia citaju azbuku, a maju jadrove hlavice. Je mozne ze za tyzden uz bude tako krajina susedit zo Slovenskom. Putina by nesledoval len blazon.
Len tak som si stiahol openSSL zdrojaky ci su naozaj take necitatelne. Pre kratkost casu som si vybral kod AES. Dalo by sa mu vytknut ze je tam malo komentarov a ze mena premennych su striktne dvojznakove niekedy doplnene cislom (napr. rk[5] = rk[1] ^ rk[4]; ). Ale myslim ze je ten kod pochopitelny.
Chápu vaše znepokojení z pozvolna nastávajícího souseda, ale už jste zjistil co to znamená to doplnění číslem? ;-) Jedna z mých oblíbených funkcí "doplňování číslem" v C je že to je v podstatě jen makro - takže se a[b] převádí na *(a+b), takže a[b] je to samé co b[a] neboli by se ten příklad dal přepsat na rk[5] = 1[rk] ^ 4[rk]; a to teprve vypadá zajímavě! :-)
Aj si za tym „a ze mena premennych su striktne dvojznakove niekedy doplnene cislom“ stojim, daval som tam priklad na dvojznakove rk[ 7] = rk[ 1] ^ rk[ 6];
Pridavam priklad na dvojznakove doplnene cislom tp1 = rk[j]; A pre upresnenie myslim "tp1".
Ked vtipkujeme na temu hranic CR tak pridam este taky smiesny dodatok. Nejaky rusky oddiel zabludi prejde hranice SR sporadicky odpor rozdrti a po tych 14 dnoch 96.8% slovakov bude suhlasit v referende s pripojenim k Rusku :-)
Ono to je este trosku zlozitejsie, rk je definovne ako pointer.
u32 *rk;
U32k je definovane ako pole
static const u32 rcon[] = {
0x01000000, 0x02000000, 0x04000000, 0x08000000,
0x10000000, 0x20000000, 0x40000000, 0x80000000,
0x1B000000, 0x36000000, /* for 128-bit blocks, Rijndael never uses more than 10 rcon values */
je to v subore openssl-1.0.1g\crypto\aes\aes_core.c
Trosku AES poznam ale naozaj neviem co je rk. Mohlo by to byt roundkey ?
Stiahnutie openssl mi trvalo 10 sekund a rozbalenie 5 sekund. To je malinka strata casu, kazdy sa moze presvedcit sam ci to je necitatelne.
Suhlasim ze tato chyba je tragedia, tak by sa mala komunita poucit a hladat chyby. Lebo inak hrozi MS SSL kde mozeme len hadat co je vnutri.
Tak samotny AES sa neda naprogramovat nejak extra zle. Co takto ho ale pouzit v nejakom blokovom mode, napriklad GCM. To az potom zacina sranda s (ne)dokumentaciou a digitalna archeologia, ze ako to vlastne autori OpenSSL mysleli.
Este vacsia sranda nastava, ked clovek chce implementovat nejaky blokovy mod, ktory aktualne nie je v kniznici podporovany, alebo je implementovany ciastocne a nie je exportovany navonok. Vzhladom na (ne)dokumentaciu, je to prakticky nadludsky vykon. Dodnes si pamatam na tie 4 levely makier, ktore nerobia nic ine, iba obfuskuju miesto, kde su niektore exportovane funkcie implementovane.
Autora toho "OpenSSL is written by monkeys" uplne chapem a mam takmer identicku skusenost...