RAND_bytes neizdevās OpenVPN: bibliotēkas kļūda vai trūkstošs mezgls

RAND_bytes() failed ir apgalvojums par vienu lokālu primitīvu, nevis par kontu, iepriekš kopīgu atslēgu vai attālo portu. Divas ļoti atšķirīgas kļūmes rada to pašu rindu un atstāj atšķirīgas pēdas. Viena ir kriptogrāfisks aizmugurs, kas atsakās izdot baitus; otra ir process, kas neaizsniedz entropijas avotu, kuram tā kods tika būvēts. Lai tos atdalītu, vajadzīga viena kļūdu rindas lasīšana un viens skatiens uz ieslodzītā procesa failu sistēmas skatu, un šai pārbaudei jābūt pirms visa, kas tiek radīts zem /dev.

Ko atšķir atgrieztā vērtība

Dokumentētais līgums atšķir trīs iznākumus, nevis divus: 1 panākumiem, -1 kad ielādētā RAND metode neatbalsta pieprasījumu, un 0 citām kļūmēm, skaidrojumu atstājot kļūdu rindā. RAND_bytes atsauce pievieno punktu, ko viegli palaist garām: noklusējuma ģenerators iesējas no operētājsistēmas atbalstītajās platformās, un, kad šī iesēšana neizdodas, tas paliek kļūdas stāvoklī, nevis atgriež paredzamus baitus.

Tikai viens no šiem skaitļiem raksturo vidi. -1 ir būvēšanas, piegādātāja vai funkcijas jautājums, jo kods prasīja kaut ko, ko aktīvā implementācija nepiedāvā. 0 ar sēšanas sūdzību ir vides jautājums, jo ģenerators vispār nevarēja iegūt entropiju. Skaitlis pats par sevi nekad nepasaka, kurš no abiem, un arī funkcijas nosaukums to nepasaka.

Kad paslēpts ierīces mezgls ir īstais cēlonis

Ierobežots pakalpojums redz citu koku nekā čaula, kurā jūs rakstāt. Chroot cietumi, konteineru attēli un rūdītas unit datnes regulāri uzrāda /dev ar mazāk mezglu nekā saimniekdatora. Ja neizdevusies implementācija atver /dev/urandom pēc ceļa nosaukuma, šī atšķirība ir pietiekama, lai salauztu palaišanu, kamēr pats saimniekdators izskatās pilnīgi vesels. Ierīce, kas pastāv ārpus cietuma, neko nepierāda par to, ko ieslodzītajam procesam ir atļauts atvērt.

Tomēr ne katrai nejaušajai saskarnei vajag ceļu. Linux sistēmas izsaukums getrandom nepieņem ne faila nosaukumu, ne faila deskriptoru, un tā rokasgrāmatas lapa norāda, ka šī īpašība ir noderīga tieši tur, kur chroot slēpj ierīču ceļus.

Tātad trūkstošā mezgla skaidrojums ir hipotēze par vienu koda zaru, nevis vispārīgs noteikums par nejaušiem skaitļiem. Tas pastāv, kad pierādījumi nosauc ceļu, un tas ir minējums, kad pierādījumi nosauc ko citu.

Vispirms izlasiet kļūdu rindu, tad procesa skatu

Ātrākais veids, kā atrisināt jautājumu, ir izlasīt to, ko bibliotēka jau ir ierakstījusi, un pēc tam tieši apskatīt skatu cietuma iekšienē. Sāciet ar OpenSSL būvi, ko pakalpojums faktiski ielādēja, jo piegādātāju steki atšķiras starp galvenajām versijām un starp distribūcijām. Pēc tam pajautājiet systemd, kurš process darbojas un kādi ierobežojumi tam piemērojami. Tikai tad, kad abi fakti ir uz galda, ir vērts uzskaitīt mezglus, ko šis process redz.

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

Veiciet šos lasījumus tajā pašā procesā, nevis čaulā, kas nejauši ir atvērta. Saimniekdatora /dev salīdzināšana ar nesaistīta procesa skatu ir veids, kā nepareizā atkarība tiek salabota divreiz.

Pievienojiet atkarību tikai tad, kad varat to nosaukt

Kad pierādījumi patiešām nosauc ceļu, labojums ir mazs: padariet šo vienu ceļu pieejamu cietuma iekšienē un atstājiet pārējo mierā. Viena mezgla bind montējums parasti ir pietiekams, un mknod ar mezgla standarta major un minor numuriem dod tādu pašu rezultātu instalācijās, kur montēšana nav iespēja. Smilškastes paplašināšana, piekļuves došana katrai rakstzīmju ierīcei vai PrivateDevices izslēgšana apmaina mērķētu labojumu pret pastāvīgu drošības regresiju.

Entropijas dēmons šo labojumu neaizstāj. Paketes kā haveged maina to, kā tiek barots kodola baseins; tās nevar izveidot ceļu, ko ieslodzītajam procesam ir atļauts atvērt. Vienas instalēšana var uzlabot veselības grafiku, kamēr atvēršanas izsaukums joprojām neizdodas. Turiet abas problēmas atsevišķi, citādi nākamā kļūme atkal tiks piedēvēta nepareizajam slānim.

Pārbaudiet ģeneratoru un tuneli atsevišķi

Restartēšana ir vienīgais tests, kas atkārtoti izmanto to pašu konfigurāciju, to pašu unit datni un to pašu izolāciju, kas izraisīja kļūmi. Palaidiet to un pēc tam lasiet jaunākos žurnāla ierakstus, nevis paraugu no iepriekšējas palaišanas.

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

Meklējiet šajā izvadē divas atsevišķas lietas: paziņojuma par nejaušo avotu pazušanu un tuneļa sasniegto parasto palaišanas atzīmi. Ģenerators, kas atkal darbojas, novērš vienu lokālu kļūmi un neko nepasaka par servera identitāti, akreditācijas datiem vai maršrutēšanu. Pārbaudiet to ar to pašu klienta konfigurāciju, kas iepriekš neizdevās, lai rezultāts būtu salīdzināms, nevis tikai labāks.