RAND_bytes mislearre yn OpenVPN: biblioteekflater of ûntbrekkende node

RAND_bytes() failed is in útspraak oer ien lokale primityf, net oer it akkount, de foarôf dielde kaai of de ôfstâns-poarte. Twa hiel ferskillende flaters produsearje deselde rigel en litte ferskillende spoaren efter. De iene is in kryptografyske backend dy't wegert bytes út te jaan; de oare is in proses dat de entropieboarne net berikt dêr't syn koade foar boud is. Se skiede freget ien lêzing fan de flaterswachtrij en ien eachopslach op it bestânssysteembyld fan it opsletten proses, en dy kontrôle heart foar alles wat ûnder /dev oanmakke wurdt.

Wat de retuerwearde skiedt

It dokumintearre kontrakt skiedt trije útkomsten, net twa: 1 foar súkses, -1 as de laden RAND-metoade it fersyk net stipet, en 0 foar oare flaters, wylst de ferklearring yn de flaterswachtrij bliuwt. De RAND_bytes-referinsje foeget in punt ta dat maklik oersjoen wurdt: de standertgenerator initialisearret him op stipe platfoarms út it bestjoeringssysteem wei, en as dy initialisaasje mislearret, bliuwt er yn in flatertastân yn stee fan foarsisbere bytes werom te jaan.

Mar ien fan dy getallen beskriuwt de omjouwing. In -1 is in kwestje fan build, provider of funksjonaliteit, omdat de koade om wat frege dat de aktive ymplemintaasje net biedt. In 0 mei in klacht oer initialisaasje is in omjouwingskwestje, omdat de generator hielendal gjin entropie krije koe. It getal allinnich seit nea hokker fan de twa, en de funksjenamme ek net.

Wannear in ferburgen apparaatnode de echte oarsaak is

In beheinde tsjinst sjocht in oare beam as de shell dêr't jo yn type. Chroot-jails, kontenerbylden en ferhurde unitbestannen litte geregeld in /dev sjen mei minder nodes as dy fan de host. As de mislearjende ymplemintaasje /dev/urandom op paadnamme iepenet, is dat ferskil genôch om de opstart te brekken wylst de host sels folslein sûn liket. In apparaat dat bûten de jail bestiet, bewiist neat oer wat it opsletten proses iepenje mei.

Net elk willekeurich ynterface hat lykwols in paad nedich. De systeemoprop getrandom fan Linux akseptearret noch in bestânsnamme noch in bestânsdeskriptor, en syn mannepagina merkt op dat dy eigenskip krekt nuttich is dêr't in chroot apparaatpaden ferberget.

Dat de ferklearring fan de ûntbrekkende node is in hypoteze oer ien tûke fan de koade, net in regel oer willekeurige getallen yn it algemien. Se hâldt as it bewiis in paad neamt, en se is giswurk as it bewiis wat oars neamt.

Lês earst de flaterswachtrij, dan it prosesbyld

De fluchste manier om de fraach te besljochtsjen is te lêzen wat de biblioteek al fêstlein hat, en dan direkt it byld yn de jail te besjen. Begjin mei it OpenSSL-build dat de tsjinst eins laden hat, omdat providerstapels ferskille tusken haadferzjes en tusken distribúsjes. Freegje dêrnei systemd hokker proses rint en hokker beheiningen dêrfoar jilde. Pas as beide feiten op de tafel lizze, is it de muoite wurdich de nodes op te listjen dy't dat proses sjen kin.

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

Fier dy lêzingen út tsjin itselde proses, net tsjin de shell dy't tafallich iepenstiet. De /dev fan de host fergelykje mei it byld fan in net besibbe proses is hoe't de ferkearde ôfhinklikheid twa kear reparearre wurdt.

Foegje de ôfhinklikheid pas ta as jo har beneame kinne

As it bewiis wol in paad neamt, is de reparaasje lyts: meitsje dat iene paad beskikber yn de jail en lit al it oare gewurde. In bind-mount fan de inkele node is meast genôch, en mknod mei de standert major- en minornûmers fan de node jout itselde resultaat op ynstallaasjes dêr't mounten gjin opsje is. De sandbox ferbreedzje, tagong jaan ta elk tekenapparaat of PrivateDevices útskeakelje ruilet in rjochte korreksje foar in bliuwende feiligensregresje.

In entropi-demon ferfangt dy reparaasje net. Pakketten lykas haveged feroarje hoe't de kernelpool fiedt wurdt; se kinne gjin paadnamme meitsje dy't in opsletten proses iepenje mei. Ien ynstallearje kin in sûnensgrafyk better lykje litte wylst de open-oprop noch altyd mislearret. Hâld de twa problemen skieden, oars wurdt de folgjende flater wer oan de ferkearde laach taskreaun.

Kontrolearje de generator en de tunnel apart

In werstart is de iennige test dy't deselde konfiguraasje, itselde unitbestân en deselde beheining werbrûkt dy't de flater feroarsake hawwe. Fier him út en lês dan de nijste journalregels yn stee fan in stekproef út in eardere start.

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

Sjoch nei twa skieden dingen yn dy útfier: it berjocht oer de willekeurige boarne dat ferdwynt, en de tunnel dy't syn gewoane opstartmylpeal hellet. In generator dy't wer wurket hellet ien lokale flater fuort en seit neat oer serveridentiteit, oanmeldgegevens of routing. Test dat mei deselde klantkonfiguraasje dy't earder mislearre, sadat it resultaat fergelykber is en net allinnich better.