Názory k článku
Objevena zneužitelná díra v protokolu SSH
-
anonymní"Vedci" objevili starou belu.Je lepe odkazat na detaily primo od projektu http://www.openssh.com/txt/cbc.adv i s kratkou myslenkou o "vedcich".A kdo pouziva starsi verze ve kterych jsou zname chyby,tak je proste a jednoduse osel.
-
Jan Pechanec (neregistrovaný)Ne tak uplne. OpenSSH v posledni verzi u CBC modu navic docita data do maximalni velikosti paketu, cimz tomu brani uplne. Toto reseni na druhou stranu ztizi hledani problemu, ktere drive zpusobovalo chybu typu "bad MAC" (driver, NAT, firewall, switch, ...). To o cem mluvim je tady:
http://anoncvs.mindrot.org/index.cgi/openssh/packet.c?r1=1.160&r2=1.161 -
Sten (neregistrovaný)
Debian neplánuje backportovat „opravu“, protože nejde o skutečnou opravu, ale jen změnu konfigurace, viz Debian bug #506115
Doporučené je v sshd_config dát např.
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc -
Jan Pechanec (neregistrovaný)Oni skutecne objevili neco noveho, a ten paper co vyse uvedene advisory diskutuje, to neni.
Ten novy problem diskutovany minuly rok spociva v tom, ze se temi 4-mi bajty, co chci jako utocnik odsifrovat, strefim do povoleneho rozsahu velikosti paketu, a pak generuju data az do te doby, co druha strana udela zaverecny MAC check a posle mi disconnect. Vim, kolik dat jsem vygeneroval nez jsem dostal disconnect a tim vim, do jakeho cisla se ty 4 bajty vlastne odsifrovaly. To ze se to objevuje ted je mozna tim, ze to predvedli na nejake konferenci, ktera mela byt prave tento mesic.
V praxi je to mozne zneuzit jen u pripojeni, kde se nezadava heslo. Uzivatel bude asi tezko ochotny zadat heslo prumerne 2^17-krat s tim, ze mu spojeni nekdy v prubehu selze nebo se zavesi; coz je okamzity vysledek nezdareneho utoku.
