Az OpenBSD október 20-án közzétette a 8.0-s verziót, a projekt 61. kiadását. A beépített virtualizációs rendszer immár vendéggépenként akár 64 virtuális processzort kezel. Az amd64-es rendszermag virtuális címtere 4 GB-ról 512 GB-ra nőtt, szigorodott több hálózati szolgáltatás bemenetellenőrzése, az új rtrd pedig ellenőrzött útválasztási adatokkal tudja ellátni a routereket. Az OpenBSD 8.0 hivatalos kiadási jegyzéke
A kiadás az OpenBSD régóta követett megközelítését viszi tovább: a hibák javítása mellett a fejlesztők azt is korlátozzák, mit tehet egy program, ha hibás vagy rosszindulatúan összeállított adatot kap. A változások egy része az OpenBSD-t nem használó szervezeteknek is fontos, hiszen az OpenSSH és a LibreSSL más operációs rendszereken is elérhető.
Az üzemeltetők számára a telepítőkép csak a kiindulópont. Négy javítás már a megjelenés napján felkerült a 8.0 hibajegyzékébe, október 23-án pedig megérkezett az ötödik. Ezek többek között az IPsec működését, a kernel memóriabiztonságát és a rendszer tanúsítványkészletét érintik. Az OpenBSD 8.0 hibajavításai
Biztonságosabb archívumkibontás és szigorúbb hálózati feldolgozás
A pax archiválóprogram most már megakadályozza, hogy egy rosszindulatúan összeállított archívum kibontásakor fájlok kerüljenek a munkakönyvtáron kívülre. A DHCP-kiszolgálóban javították a hibásan formázott címadatok miatt előforduló összeomlásokat, valamint azt a problémát, amelynél DHCPINFORM üzenetekkel ki lehetett meríteni a rendelkezésre álló memóriát.
A httpd webkiszolgálóban bővültek a HTTP-fejlécek szűrésének lehetőségei. A relayd szigorúbb korlátokat alkalmaz a több részletben továbbított HTTP-adatok és az utánuk érkező záró fejlécek feldolgozására. Ezek a változások ugyanazt a gyakorlati problémát kezelik különböző helyeken: a külső fél által megválasztott bemenet ne határozhassa meg korlátlanul, hová írhat a program, vagy mennyi erőforrást használhat fel. Az OpenBSD 8.0 fejlesztési változásnaplója
A kézikönyvoldalakat feldolgozó segédprogramok jogosultságait is szűkítették. Egy dokumentum megjelenítéséhez szükséges műveletek köre jól behatárolható; ha a formázó hibás bemenettel találkozik, nem indokolt, hogy emiatt a rendszer más részeihez is hozzáférhessen. A kiadás változásnaplója
Hogyan korlátozza a károkat a pledge és az unveil?
A szigorítások mögötti elvet két, már korábban is használt OpenBSD-mechanizmus szemlélteti. A pledge segítségével egy alkalmazás megadhatja, hogy futásának hátralévő részében az operációs rendszer mely szolgáltatásaira van még szüksége. Ha ezután az engedélyezett körön kívüli műveletet kísérel meg, a rendszer általában leállítja a folyamatot. A program később tovább szűkítheti a lehetőségeit, de amiről már lemondott, azt nem kérheti vissza. A pledge(2) kézikönyvoldala
Az unveil a fájlrendszer elérhető részét szűkíti. A program megnevezi a szükséges elérési utakat és az ott engedélyezett műveleteket, majd lezárhatja a szabályokat a további módosítások előtt. Így például egy programnak lehet olvasási joga egy kijelölt könyvtárban anélkül, hogy a folyamat felhasználója számára egyébként elérhető összes többi fájlt is látná. Az unveil(2) kézikönyvoldala
Egyik mechanizmus sem javítja ki magát a programhibát. A hasznuk az, hogy sikeres kihasználás esetén kevesebb művelet és kevesebb fájl állhat a támadó rendelkezésére. Ehhez a fejlesztőnek megfelelő korlátokat kell választania, és azokat még a potenciálisan veszélyes feldolgozás előtt érvényesítenie kell.
Nagyobb kernelcímtér és szélesebb hardvertámogatás
Az amd64 architektúrán 4 GB-ról 512 GB-ra bővült a kernel virtuális címtere. Ez nem a telepített fizikai memória mennyiségét jelenti: a rendszermag számára rendelkezésre álló címtartomány lett nagyobb. Ennek egyik kézzelfogható eredménye, hogy 4 GB-nál nagyobb grafikus memóriaterületek is leképezhetők. A kiadás emellett véletlenszerűsíti a fizikai memóriához közvetlen hozzáférést biztosító leképezés helyét. Az OpenBSD 8.0 kernel- és grafikai változásai
Megjelent az Intel Arc A-sorozatú grafikus vezérlők támogatása, arm64-en elérhetővé vált a hibernálás, RISC-V-n pedig bővült a vektoros utasításkiterjesztés és a megszakításvezérlők támogatása. Az amd64-es és arm64-es rendszereken a hardveres AES-utasítások gyorsítják a titkosított lapozóterület kezelését. Egy korábbi platform viszont kikerült a támogatottak közül: a projekt megszüntette a Loongson-változat karbantartását, mert az már nem működik a Clang 22 fordítóval. A támogatott platformok változásai
Vendéggépenként akár 64 virtuális processzor
Az OpenBSD beépített virtualizációs rendszere már többprocesszoros vendéggépeket is futtat, virtuális gépenként legfeljebb 64 vCPU-val. A vendégek használhatják az x2APIC megszakításvezérlési módot, és változott a virtuális gépek tulajdonosának kezelése is. A betöltőben olyan hibákat javítottak, amelyek hibásan formázott ELF-fájl esetén a kijelölt memóriaterületen kívüli olvasáshoz vezethettek. A virtualizáció változásai
A több vCPU főként azoknál a feladatoknál jelent előrelépést, amelyek párhuzamosan is képesek dolgozni. A 64-es érték felső határ; az adott alkalmazás gyorsulását a gazdagép hardverén, a tényleges terheléssel érdemes megmérni.
OpenSSH 10.6: szigorúbb fájlátvitel és elkülönített hitelesítési próbálkozások
Az OpenSSH 10.6 szigorúbban ellenőrzi az SFTP-kiszolgálótól kapott elérési utakat. Ez a könyvtárak rekurzív átvitelénél különösen fontos: egy rosszindulatú kiszolgáló által visszaadott útvonal bizonyos esetekben a helyi célkönyvtáron kívülre irányíthatta az írást. Az új ellenőrzések ezt akadályozzák meg. Az OpenSSH 10.6 kiadási jegyzéke
A GSSAPI-hitelesítésnél az SSH-kiszolgáló már nem őrzi meg úgy egy sikertelen kísérlet hitelesítő adatait, hogy azok egy későbbi, sikeres bejelentkezés után hozzáférhetővé válhassanak. További módosítások gondoskodnak arról, hogy az egyik hitelesítési kísérlet állapota ne befolyásolja helytelenül a következőt.
A fejlesztők egy tömörítéshez kapcsolódó információszivárgási lehetőség mérséklésére letiltották az LZ77 szótáralapú kódolást. Ennek ára a gyengébb tömörítési arány lehet az SSH-tömörítést használó kapcsolatoknál. A parancssorban megadott távoli felhasználónevek ellenőrzése is szigorodott: a kliens elutasítja többek között a fordított perjelet (\) és a dollárjelet ($). Az ilyen karaktereket átadó automatizmusokat ezért frissítés előtt célszerű kipróbálni. Az OpenSSH biztonsági és kompatibilitási változásai
Az OpenSSH csapata a gyakoribb kiadások felé kíván elmozdulni. Indoklásuk szerint egyre több bejelentés érkezik AI-val támogatott sérülékenységkutatásból. Ha több kutató egymástól függetlenül is megtalálhatja ugyanazt a hibát, akkor olyan támadó is felfedezheti, aki nem jelenti azt a projektnek. Az OpenSSH fejlesztőinek indoklása
LibreSSL 4.4.0: változik a TLS-kulcscsere és a tanúsítványok ellenőrzése
Az OpenBSD 8.0-val érkező LibreSSL 4.4.0 a libtls könyvtáron keresztül létrehozott TLS 1.3-kapcsolatokhoz az X25519MLKEM768 hibrid kulcscserecsoportot részesíti előnyben. Ez a kapcsolat közös titkának létrehozását érinti; nem jelenti azt, hogy a kapcsolatban használt tanúsítványok aláírása is automatikusan posztkvantum-védelmet kap. A LibreSSL 4.4.0 kiadási jegyzéke
A biztonsági javítások között szerepel a tanúsítványokba ágyazott, rosszindulatúan kialakított névkorlátozások kezelése és a darabolt DTLS-kézfogási üzenetek által kiváltott túlzott memóriahasználat mérséklése. Javítottak egy OCSP-hibát is: meghatározott, a tanúsítvány állapotát igazoló válasz csatolását megkövetelő kliensbeállítás mellett megkerülhető volt annak ellenőrzése, hogy a válaszadó jogosult-e az adott tanúsítványról nyilatkozni.
A projekt eltávolította a tanúsítványkészletből az emSign ECC Root CA – G3 gyökértanúsítványt, mivel egyes alárendelt hitelesítésszolgáltatók gyenge kulcsokat használtak. A kompatibilitás fenntartásához nem kompromittált köztes tanúsítványokat vettek fel. Frissítés után ezért nemcsak a TLS-szolgáltatás elindulását érdemes ellenőrizni, hanem azokat a tényleges partnerkapcsolatokat is, amelyek egyedi bizalmi beállításokra vagy meghatározott tanúsítványláncra támaszkodnak. A LibreSSL tanúsítványkészletének változásai
A LibreSSL kiadási rendje az OpenBSD fejlesztési ciklusát követi. A stabil ágak a hozzájuk tartozó OpenBSD-ág megjelölésétől számítva egy évig kapnak frissítéseket. A LibreSSL kiadási és támogatási rendje
Új RPKI-szolgáltatás az ellenőrzött útválasztási adatokhoz
Az új rtrd az RPKI-to-Router protokoll 0-s, 1-es és 2-es verzióját támogató gyorsítótár-kiszolgáló. Feladata, hogy a routerek számára elérhetővé tegye az ellenőrzött útválasztási adatokat. Ezek alapján egy router például megvizsgálhatja, hogy az adott autonóm rendszer jogosult-e egy IP-címtartomány eredeteként megjelenni egy BGP-hirdetésben. Az rtrd(8) kézikönyvoldala
A kriptográfiai ellenőrzést továbbra is az rpki-client végzi. Letölti a tanúsítványokat és az aláírt objektumokat, ellenőrzi a hitelesítési láncokat és a visszavonási információkat, majd előállítja az érvényesített adatokat. Az eredményt az rtrd vezérlőcsatlakozójára is továbbíthatja. Így az adatok hitelességének ellenőrzése és a routerek kiszolgálása két külön feladat: az üzemeltető külön felügyelheti az ellenőrzés frissességét és a routerek kapcsolatát a gyorsítótárral. Az rpki-client(8) dokumentációja
Öt javítás, amelyet a 8.0 telepítésekor ellenőrizni kell
Az OpenBSD 8.0 hivatalos hibajegyzéke 2026. november 3-án az alábbi öt tételt tartalmazta. A projekt a PPP-hibát megbízhatósági, a másik négyet biztonsági javításként sorolta be.
| Javítás | Dátum | Érintettség és változás |
|---|---|---|
| 001 – PPP | október 20. | Minden architektúra. A ppp(4) egy határérték-számítási hiba miatt a kijelölt memóriaterületen kívülre írhatott. |
| 002 – NSD | október 20. | Minden architektúra. Az NSD névkiszolgáló 4.15.3-as kiadásából négy sérülékenység javítását ültették át az alaprendszerbe. |
| 003 – IPsec | október 20. | AES-GMAC használatakor távolról kiváltható túlcsordulás léphetett fel a kernel dinamikus memóriaterületén. Csak az AES-NI-t használó amd64-es és a kriptográfiai társprocesszorral rendelkező Octeon-rendszerek érintettek. Az AES-GCM nem érintett. |
| 004 – videóillesztő | október 20. | Minden architektúra. A video(4) több hibája felszabadítás utáni memóriahasználathoz és a kernel memóriájának sérüléséhez vezethetett. |
| 005 – tanúsítványok és időzónaadatok | október 23. | Minden architektúra. A javítás frissített /etc/ssl/cert.pem fájlt ad, valamint a tanúsítványkészlet és az időzóna-adatbázis karbantartására szolgáló dbupdate segédprogramot. |
A 005-ös javításnál külön figyelmet érdemelnek a helyi tanúsítványbeállítások. A projekt szerint a helyi kiegészítéseket az /etc/ssl/cert.local.pem fájlban kell elhelyezni; a dbupdate ezeket a frissített rendszerlista elé illeszti. Így nem kell a rendszer által frissített cert.pem közvetlen szerkesztésére hagyatkozni. Az 005-ös hibajavítás leírása
A projekt kriptográfiailag aláírt forráskódjavításokat ad ki. A syspatch teljes bináris frissítéseket biztosít amd64, i386 és arm64 rendszerekhez. Más architektúrákra csak az architektúrafüggetlen módosításokhoz készül bináris frissítés, ami ritka. Emiatt az érintett hardver és a hozzá elérhető telepítési mód ellenőrzése is része a javításnak. Az OpenBSD hivatalos frissítési lehetőségei
Frissítés 7.9-ről: mely beállításokat kell felülvizsgálni?
A hivatalos útmutató a 7.9 → 8.0 frissítést írja le. Az OpenBSD kiadásai között sorrendben kell haladni; régebbi telepítésről nem támogatott több verzió átugrása. Kritikus vagy fizikailag nehezen elérhető gépnél a projekt először azonos helyi rendszeren végzett próbát javasol. A frissítés előtt ellenőrizni kell a szabad lemezterületet is. Az OpenBSD 8.0 frissítési útmutatója
A felügyelet nélküli frissítés legegyszerűbb eszköze a sysupgrade. Az alaprendszer telepítése után a sysmerge segítségével rendezhetők a helyi és az új alapértelmezett konfiguráció közötti eltérések. A külön telepített csomagokat is frissíteni kell. Négy változás különösen indokolja az előzetes ellenőrzést:
- OpenBGPD: a
bgpdalapértelmezés szerint megköveteli a négybájtos autonómrendszer-számok támogatását. Régi BGP-partnereknél ellenőrizni kell ezt a képességet, különben a kapcsolat az új alapbeállítással nem feltétlenül áll fel. - Kea DHCP: a csomag a 2.4.2-es verzióról a 3.2-es ágra vált. A konfiguráció módosítást vagy átírást igényelhet, az adatfájlok pedig a
/var/lib/keahelyett a/var/db/keaalá kerülnek. A MySQL- és PostgreSQL-támogatás külön alcsomagba költözött. - Stalwart Mail: a 0.16-os verzióra áttéréshez teljes adatexport és visszaállítás szükséges. A konfiguráció, a naplók és az adatok helye is változik. Ehhez a levelezőszolgáltatáshoz külön migrációs és ellenőrzési ablakot érdemes tervezni.
- Firefox: az OpenBSD-csomag új házirendje alapértelmezés szerint letiltja az AI-funkciókat, köztük a helyben futó fordítást is. Akinek szüksége van rájuk, a Firefox beállításain belül az AI Controls részen ismét engedélyezheti őket.
A telepítés sikerét ezért azokon a szolgáltatásokon érdemes ellenőrizni, amelyekért a gép felel. Egy útválasztónál ez a BGP-kapcsolatok helyreállását, egy levelezőszervernél az adatok és a kézbesítés ellenőrzését, egy TLS-szolgáltatásnál a tényleges tanúsítványlánc próbáját jelenti. A 8.0-ra váltás akkor tekinthető befejezettnek, ha az alaprendszer és a csomagok frissültek, a szükséges migrációk lezajlottak, és az adott gépre vonatkozó hibajavításokat is alkalmazták. A kiadásspecifikus teendők teljes listája
Eredeti cím: OpenBSD 8.0 Released With Stronger Security Controls, Expanded Virtualisation and Updated Cryptography
