» »

LibreSSL za zdaj še nevaren

LibreSSL za zdaj še nevaren

Ars Technica - LibreSSL, ki je nastal iz OpenSSL s čiščenjem kode in odstranjevanjem nepotrebnih funkcionalnosti, je prilezel do verzije 2.0.0, ki pa je imenu navkljub še vedno nedokončana. Toda pokazalo se je, da je odstranjevanje funkcionalnosti OpenSSL dvorezen meč, saj je LibreSSL v trenutni verziji v nekaterih pogledih nevarnejši od predhodnika.

Težave tičijo v generatorju psevdonaključnih števil (PRNG), ki je pri šifriranju izjemno pomemben. Algoritem Dual EC DRBG za tvorjenje psevdonaključnih števil je na primer imel ranljivost, ki jo je NSA izkoriščala za prisluškovanje. Pregled kode LibreSSL je pokazal, da ima ta pomanjkljiv PRNG.

Zgodi se namreč lahko, da začne PRNG vračati ista naključna števila. To se lahko primeri, kadar ima več inačic procesa v Linuxu isto številko PID. Linux sicer vedno poskrbi, da ima starševski proces drugačen PID od procesa, ki ga je skloniral (fork), a lahko se zgodi, da imata bolj oddaljena (starševi starši itn.) procesa enak 16-biten PID. Običajno se to zgodi sila redko, a je vseeno to detajl, na katerega robusten algoritem ne bi smel biti občutljiv. OpenSSL ni, ker v vsakem primeru spremeni seme za PRN, LibreSSL pa tega ne stori, zato je občutljiv.

Druga težava je poganjanje LibreSSL v izoliranem načinu s spremenjenim korenskim direktorijem (chroot jail). V tem primeru LibreSSL ne bo mogel klicati generatorja psevdonaključnih števil v /dev/urandom, zato bo poiskal alternative, ki pa so slabe, sploh ko bo sysctl odstranjen. Uporabil bo PID, datum, pomnilniške naslove in podobne vire entropije, ki so zelo slabi in predvidljivi. Tudi OpenSSL ne more klicati /dev/urandom, a dvigne zastavico z napako, za katero lahko programer preverja, medtem ko LibreSSL tega ne stori in začne uporabljati zanič entropijo.

To kaže, da prepis in čiščenje kode OpenSSL v LibreSSL ni enostaven problem. Res je postal OpenSSL tako glomazen in nepregleden, da nihče ni več točno vedel, kaj počne vsaka vrstica kode. A ravno ob takih ugotovitvah se izkaže, da je lahko brisanje nekaterih rutin tudi dvorezen meč. LibreSSL 2.0.0 je še vedno preizkusna različica in ni namenjena uporabi v kritičnih okoljih, zato ji ranljivosti ne smemo preveč zameriti. Je pa vsekakor prav, da si jih pogledamo.

17 komentarjev

Isotropic ::

kaksna ranljivost je v dual_ec_dbrg?
pomnimo, kaj je bilo s tisto domnevno ranljivostjo DES - v resnici je bila boljsa zascita, nsa je pa imela druge načine razbijanja (dandanes ima pa VPN in exploite v OS).
oz. je dokazano, da je v d_ec_dbrg dejanska ranljivost?

Zgodovina sprememb…

black ice ::

To se lahko primeri, kadar ima več inačic procesa v Linuxu isto številko PID. Linux sicer vedno poskrbi, da ima starševski proces drugačen PID od procesa, ki ga je skloniral (fork), a lahko se zgodi, da imata bolj oddaljena (starševi starši itn.) procesa enak 16-biten PID.

:O
Mislil sem da so PIDi _vedno_ različni.

Mandi ::

cen1 ::

LibreSSL 2.0.0 je še vedno preizkusna različica in ni namenjena uporabi v kritičnih okoljih


Je treba še kaj dodat? Portable verzija je stara šele kak teden.. pustimo času čas da folk z OpenBSDja zadeve lepo porihta.

MrStein ::

black ice je izjavil:


Mislil sem da so PIDi _vedno_ različni.

Je res čudno napisano.
Čez čas se sicer PID-i reciklirajo.
Da bi istočasno obstajala dva procesa z istim PID pa je res čudno.

Počakajmo, da kaki guru razjasni...
Teštiram če delaž - umlaut dela: ä ?

Poldi112 ::

A niso pri OpenBDS razlagali, da je PRNG stvar os-a in da se Open oz. libressl nima kaj s tem ukvarjati?
-------------------------------------------------
Nočem foto avatarja. Hočem risan avatar.
-------------------------------------------------

Brane22 ::

V bistvu so to pričakovane malenkosti.

verjetno ni nihče računal na to,d a bo kaz zagrabil Libre 5 minut po splavitvi in naredil konec glavobolom.

A pomaga že, če je koda pregledna in se po njej da iskati napake.

Mavrik ::

Poldi112 je izjavil:

A niso pri OpenBDS razlagali, da je PRNG stvar os-a in da se Open oz. libressl nima kaj s tem ukvarjati?


Jap... in ranljivost seveda pride s tega da ima Linux (za razliko od *BSDjev, kjer te ranljivosti ni) polomljen "/dev/urandom".
The truth is rarely pure and never simple.

chironex ::

Poldi112 je izjavil:

A niso pri OpenBDS razlagali, da je PRNG stvar os-a in da se Open oz. libressl nima kaj s tem ukvarjati?


Zajemanje entropije je stvar OSa. Random generator bi lahko potencialno bil tudi ampak se mi zdi da zaradi vecih moznih izbir OSi tega ne morejo ponujat. Lovljenje pidov je pa čista neumnost, mogoce kot en eden izvor entropije, tako da se mi zdi ta "nevarnost" hudo pretirana (v kolikor ni prevajalec prevedel samo del članka), kakor tudi clanek sam.

Jokaero ::

kr švoh prevod in ne gre za "več napak" temveč eno samo

postopek napada/zelo neverjetne situacije pa gre pribl tako
...
1.) uporabnik uporablja chroot jail brez dostopa do /dev/urandom
2.) uprablja libressl in napadalec MORA pridobit te enkriptirane podatke (proces recimo dobi pid 100)
3.)forka proces (dobi recimo pid 101)
4.) forka se enkrat (proces dobi pid 100 ker ocetovega ne mores dobit "dedkovega" pa lahko)
5.) zaradi istega pida in onemogocenosti /dev/urandoma libressl ne reseeda prngja
6.) attacker pridobi podatke s pomocjo zajetih podatkov v tocki 2 (isti kljuc).

edina napaka v libre ssl in kolikor vem je ze patchana je ne-reseedanje v primeru da nima dostopa do /dev/urandom IN procesa z istim pidom (oba pogoja morata biti izpolnjena)

Jokaero ::

iz arstechnice Update: A few hours after this article was published, OpenBSD founder Theo de Raadt emailed Ars and wrote: "It is way overblown. This will never happen in real code." The vulnerability, cataloged as CVE-2014-2970, already has been patched, with modified code located here.

avister ::

Hmm, zanimivo. To bi teoretično lahko pomenilo, da bi z enim zamahom lahko ubil dve muhi, mogoče celo sedem. Še več, ena bi bila v času, ko si jo usekal pri sosedu.


MrStein je izjavil:

black ice je izjavil:


Mislil sem da so PIDi _vedno_ različni.

Je res čudno napisano.
Čez čas se sicer PID-i reciklirajo.
Da bi istočasno obstajala dva procesa z istim PID pa je res čudno.

Počakajmo, da kaki guru razjasni...

avister ::

Jokaero ::

ni glih res ..clone() je clone, fork() je fork ...to se (lahko) zgodi pri forku (oz tu je bila prijavljena napaka)

sicer pa pise v orig clanku lepo

"The failure results in cases where the same 16-bit PID is used to designate two or more processes. Linux ensures that a process can never have the same ID as the child process it spawned, but it remains possible for a process to have the same PID as its grandparent process. The condition appears to be an edge case, but it's one that may be possible if the Linux fork_rand program forks enough times to produce identical PIDs."

Zgodovina sprememb…

  • spremenil: Jokaero ()

BigWhale ::

Ja, na prilizno zasedeni masini na kateri laufa nekaj tisoc procesov se mora ta fork zgoditi vec kot 60.000 krat, da prides do istega PIDa.

:)

avister ::

Zanimivo, nisem vedel, da teoretično lahko vnučki dobijo id od dedija.

Jokaero je izjavil:

ni glih res ..clone() je clone, fork() je fork ...to se (lahko) zgodi pri forku (oz tu je bila prijavljena napaka)

sicer pa pise v orig clanku lepo

"The failure results in cases where the same 16-bit PID is used to designate two or more processes. Linux ensures that a process can never have the same ID as the child process it spawned, but it remains possible for a process to have the same PID as its grandparent process. The condition appears to be an edge case, but it's one that may be possible if the Linux fork_rand program forks enough times to produce identical PIDs."

AndrejO ::

BigWhale je izjavil:

Ja, na prilizno zasedeni masini na kateri laufa nekaj tisoc procesov se mora ta fork zgoditi vec kot 60.000 krat, da prides do istega PIDa.

:)

Otrok ne more dobiti PID svojega starša, ker v trenutku fork()-a obstajata oba procesa, ki si seveda ne moreta deliti PID. Za starega starša je to "recikliranje" seveda možno, saj lahko stari starš preneha še preden starš naredi fork() svojega otroka.

Tam, kjer se PID izbere naključno (OpenBSD, FreeBSD kern.randompid=1) lahko seveda pride do naključne podvojitve neodvisno od ostalih stvari na sistemu. Tam pa, kjer se PID izbere sekvenčno (Linux), pa je verjetnost takšnega dogodka vezana na zunanje dejavnika, ki so že sami po sebi signal, da se dogaja nekaj čudnega. Npr. če je tabela procesov že zelo polna (kar je že samo po sebi nevarno za stabilnost sistema) ali pa se procesi zelo hitro fork()-ajo (v tempu 10.000/s ali več, kar ima tudi opazne negativne posledice na delovanje sistema).

Kar je potrebno še vedeti, je tudi to, da sekvenca dveh zaporednih fork() klicev ni nič nenavadnega, saj je to običajen način kako se bo proces samostojno preselil v ozadje (deamonize - razlog je v "odklopu" od terminala oz. setsid() klicu). Kar je seveda nekaj, kar se tipično uporablja za strežniške procese, ki se jih pogosto tudi zapre v chroot() ječo.

Ooops.

Zgodovina sprememb…

  • spremenil: AndrejO ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Iz OpenSSL tudi BoringSSL

Oddelek: Novice / Varnost
154837 (3160) Looooooka
»

Dodatni razvijalci in pregled kode OpenSSL-a

Oddelek: Novice / Varnost
307371 (5133) MrStein
»

Del OpenSSL bo postal LibreSSL

Oddelek: Novice / Varnost
164753 (3310) LightBit

Več podobnih tem