Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Szivárgó kulcsok

2011.06.01. 17:15 | buherator | 7 komment

Athos hívta fel a figyelmem a pam_env és pam_mail modulok egy igen érdekes, információszivárgást okozó hibájára, amely bizonyos esetekben a DSA kulcsot privát változóit is kellemetlenül érintheti.

A probléma gyökere az, hogy az említett modulok nem dobják el a privilégiumaikat a bejelentkező felhasználók fájljainak olvasása előtt. Peter van Dijk erre alapozva egy igen ötletes támadással állt elő:

Az ssh-keygennel generált kulcsok általában base64 kódolással kerülnek tárolásra. A base64 karakterláncok bizonyos esetekben '==' -re végződhetnek. Amennyiben a ~/.pam_environment fájlt szimbolikus linkként hozzuk létre a rendszer egy másik felhasználójának privát DSA kulcsára, úgy a következő bejelentkezéskor a PAM modulok root szintű jogosultságának köszönhetően a titkos kulcsfájl tartalma olvasódik fel, a kulcs utolsó sora pedig mint környezeti változó kerül regisztrálásra a bejelentkező felhasználó kontextusában. 

Ez az utolsó sor általában a titkos paraméter jelentős részét, 160 bitből 128-at tartalmaz, a maradék a publikus kulcs felhasználásával, brute-force módszerrel hamar megkapható.

A módszert korlátozza, hogy csak az esetek mintegy 10%-ában áll elő olyan kulcs, melynek kódolt formája '=='-re végződik és nem számmal kezdődik, így elfogadható környezeti változóként, ezen kívül nyilvánvalóan nem megyünk sokra, ha a kulcs jelszóval védett.

A nagyobb disztribúciók javították a hibát, frissítsétek a pam_modules csomagot!

+++

Lazán kapcsolódó téma, hogy két finn kutató időzítésen alapuló támadást talált az OpenSSL ECDSA implementációjában. A papírt sajnos még nem sikerült elolvasnom, ezért hálás lennék, ha valaki felhomályosítana engem és a Nagyérdeműt a támadás részleteiről!

Címkék: bug pam dsa

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Tyra3l 2011.06.01. 17:39:19

utolso linknel rossz az url, ez kellene oda (vagy direktben a pdf)
eprint.iacr.org/2011/232

Tyrael

buherator · http://buhera.blog.hu 2011.06.01. 17:44:56

@Tyra3l: Megviccelt a blogmotor, javítva, köszi!

EQ · http://rycon.hu 2011.06.01. 17:59:00

nice, ötletes a dolog nagyon :)
kis kritika: tudományos körökben a paper megfelelője cikk és nem papír.

buherator · http://buhera.blog.hu 2011.06.01. 18:02:05

@EQ: Az én köreimben meg papír ;)

Aron bacsi 2011.06.02. 09:21:19

Kemény... Úgy tűnik, hogy mostanában kezdik el használni a DSA-t és ECDSA-t, mert egyre több érdekességet hallunk az implementációs hibákról (ld. Sony PS3 ECDSA-ja is).

Jelszó (rejtjelezés) nélküli privát kulcsokat max. akkor szoktunk mi is csak használni, ha a háttérben, interakció nélkül vminek egyik gépről be kell SSH-znia a másikra (pl. cronba rakott backup SCP-zése). A jelszót nem lehet paraméterben átadni, ezért ilyen esetekre valóban csak a (jelszó nélküli) kliens kulcsos megoldás marad. És, ezek szerint az is már csak RSA esetében jó...

buherator · http://buhera.blog.hu 2011.06.02. 09:24:57

@Aron bacsi: Ez azért túlzás. Ha frissíted az implementációt, nincsen baj a DSA-val.