RAND_bytes het in OpenVPN misluk: biblioteekfout of ontbrekende nodus

RAND_bytes() failed is ’n stelling oor een plaaslike primitief, nie oor die rekening, die vooraf gedeelde sleutel of die afgeleë poort nie. Twee baie verskillende foute lewer dieselfde reël en laat verskillende spore agter. Die een is ’n kriptografiese backend wat weier om grepe uit te stuur; die ander is ’n proses wat nie die entropiebron bereik waarvoor sy kode gebou is nie. Om hulle te skei verg een lees van die fouttou en een blik op die lêerstelsel-sig van die ingeperkte proses, en daardie kontrole hoort voor enigiets onder /dev geskep word.

Wat die terugkeerwaarde onderskei

Die gedokumenteerde kontrak skei drie uitkomste, nie twee nie: 1 vir sukses, -1 wanneer die gelaaide RAND-metode die versoek nie ondersteun nie, en 0 vir ander foute, met die verduideliking in die fouttou gelaat. Die RAND_bytes-verwysing voeg ’n punt by wat maklik oorgesien word: die standaardgenerator saai hom op ondersteunde platforms uit die bedryfstelsel, en wanneer daardie saaiing misluk, bly dit in ’n fouttoestand eerder as om voorspelbare grepe terug te gee.

Net een van daardie getalle beskryf die omgewing. ’n -1 is ’n kwessie van bou, verskaffer of funksionaliteit, omdat die kode iets gevra het wat die aktiewe implementering nie bied nie. ’n 0 met ’n klag oor saaiing is ’n omgewingskwessie, omdat die generator glad nie entropie kon bekom nie. Die getal alleen sê nooit watter een nie, en die funksienaam ook nie.

Wanneer ’n versteekte toestelnodus die werklike oorsaak is

’n Ingesperde diens sien ’n ander boom as die dop waarin jy tik. Chroot-jails, houerbeelde en geharde eenheidlêers bied gereeld ’n /dev met minder nodusse as dié van die gasheer. As die falende implementering /dev/urandom per padnaam oopmaak, is daardie verskil genoeg om die opstart te breek terwyl die gasheer self heeltemal gesond lyk. ’n Toestel wat buite die jail bestaan, bewys niks oor wat die ingeperkte proses mag oopmaak nie.

Nie elke ewekansige koppelvlak het egter ’n pad nodig nie. Die Linux-stelseloproep getrandom aanvaar geen lêernaam en geen lêerhandle nie, en sy handboekbladsy merk op dat dié eienskap juis nuttig is waar ’n chroot toestelpade wegsteek.

Die verduideliking van die ontbrekende nodus is dus ’n hipotese oor een tak van die kode, nie ’n reël oor ewekansige getalle in die algemeen nie. Dit hou wanneer die bewyse ’n pad noem, en dit is giswerk wanneer die bewyse iets anders noem.

Lees eers die fouttou, dan die prosessig

Die vinnigste manier om die vraag te besleg is om te lees wat die biblioteek reeds aangeteken het, en dan direk na die sig binne die jail te kyk. Begin met die OpenSSL-bou wat die diens werklik gelaai het, want verskafferstapels verskil tussen hoofweergawes en tussen verspreidings. Vra dan vir systemd watter proses loop en watter beperkings daarop geld. Eers wanneer albei feite op die tafel is, is dit die moeite werd om die nodusse te lys wat daardie proses kan sien.

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

Voer daardie lesings teen dieselfde proses uit, nie teen die dop wat toevallig oop is nie. Om die gasheer se /dev met die sig van ’n onverwante proses te vergelyk, is hoe die verkeerde afhanklikheid twee keer herstel word.

Voeg die afhanklikheid eers by wanneer jy dit kan benoem

Wanneer die bewyse wel ’n pad noem, is die herstelling klein: maak daardie een pad binne die jail beskikbaar en laat alles anders met rus. ’n Bind-mount van die enkele nodus is gewoonlik genoeg, en mknod met die standaard majeur- en mineurnommers van die nodus lewer dieselfde resultaat op installasies waar montering nie ’n opsie is nie. Om die sandput te verbreed, toegang tot elke karaktertoestel te gee of PrivateDevices af te skakel, ruil ’n gerigte regstelling vir ’n permanente sekuriteitsregressie.

’n Entropie-daemon is nie ’n plaasvervanger vir daardie herstelling nie. Pakkette soos haveged verander hoe die kernpoel gevoed word; hulle kan nie ’n padnaam skep wat ’n ingeperkte proses mag oopmaak nie. Om een te installeer kan ’n gesondheidsgraaf beter laat lyk terwyl die oopoproep steeds misluk. Hou die twee probleme apart, anders word die volgende fout weer aan die verkeerde laag toegeskryf.

Kontroleer die generator en die tonnel afsonderlik

’n Herbegin is die enigste toets wat dieselfde konfigurasie, dieselfde eenheidlêer en dieselfde inperking hergebruik wat die fout veroorsaak het. Voer dit uit en lees dan die nuutste joernaalinskrywings eerder as ’n steekproef uit ’n vroeëre opstart.

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

Soek twee afsonderlike dinge in daardie uitset: die boodskap oor die ewekansige bron wat verdwyn, en die tonnel wat sy gewone opstartmylpaal bereik. ’n Generator wat weer werk verwyder een plaaslike fout en sê niks oor bedieneridentiteit, geloofsbriewe of roetering nie. Toets dit met dieselfde kliëntkonfigurasie wat vantevore gefaal het, sodat die resultaat vergelykbaar is en nie net beter nie.