Secure boot kikapcsolás milyen kockázatokat hordoz?

Security-all

Minap ki akartam dobni az ubuntut (17.10) a laptopomról, hogy Debiant vagy FreeBSD-t tegyek fel helyette.
Természetesen(?) egyik sem volt hajlandó felmenni a secure boot miatt.

Tudatlanként inkább visszatértem Ubuntu LTS-re, mert nem mertem kikapcsolni a SB-t.
Feltéve, hogy megbízom a kiválasztott rendszerek készítőiben és csak saját repo-ból és általam megbízhatónak tartott forrásokból telepítek szoftvert, milyen rizikói lehetnek a SB hiányának egy kizárólag UEFI-s gépen?

Amíg be van kapcsolva, nem telepíthetek aláírás nélküli kernelt, sem kernel modult.
Elvben.
Gyakorlatban... csak egy példa: VirtualBox használ saját kernel modult. Ubuntu alatt csak akkor tudom felrakni bekapcsolt SB mellett, ha telepítek saját kulcsot és a frissen generált modulokat aláírom. LinuxMint is telepíthető, de ott már nem kell aláírnom ezeket a modulokat. Ha jól értettem, a kernel már dönthet úgy, hogy aláíratlan modulokat is elfogad, és a Mint kernele így van konfigurálva. (tévedés joga fenntartva!)
Ha ez valóban így van, akkor én úgy gondolom, a SB csak a kernel betöltéséig bír jelentőséggel, utána már a kernelre bízzák, hogy mit csinál, így _talán_ nem akkora veszteség a kikapcsolása.

De ez csak a saját, hiányos ismereteimre alapozott elképzelés.
Mi a valóság?
Google nem nagyon segített.

  • 5485 megtekintés

( zrubi v | 2018. 01. 22., h – 11:06 )

Ha ez valóban így van, akkor én úgy gondolom, a SB csak a kernel betöltéséig bír jelentőséggel, utána már a kernelre bízzák, hogy mit csinál, így _talán_ nem akkora veszteség a kikapcsolása.

Így van.

Ennek a fícsörnek egy zárt forrású, 3rd party cégtől származó OS (kernel) esetében lehet jelentősége, mert így csak az ő általuk aláírt kerneleket fogja a géped bootolni.

Nyílt forrás esetén (Linux) a profitorientált cégek "megoldották", tehát Ubuntu, RedHat, (más?) is tud aláírni.

Kissebb disztrók ezt nem tudják/akarják megoldani (= kifizetni), mivel itt is, mint a HTTPS tanúsítvánmyok esetén, neked mint felhasználónak az aláíró tanúsítványok kiadójában is feltétel nélkül meg KELL bíznod. (a hardver, az OS, és BIOS/UEFI gyáróján kívül)

Saját kerneled esetében meg nyilván nincs értelme egy külső (profitorientált) cégtől "engedélyt" kérni, hogy saját kerneledet használd a saját vasadon. :)

Ilyen esetben is lehet használni magát a Secure Boot fícsört, csak saját kulcsokat kell telepíteni a BIOS/UEFI-be, (a többit meg törölni a p*csába) és ezzel aláírni a saját kerneleidet...

--
zrubi.hu

Köszi.
Amitől én kicsit tartok: ezt az egészet azért találták ki, mert az EFI önmagában is sérülékenyebb, mint a BIOS volt, mivel ha jól tudom, át lehet írni bizonyos részeit akár reboot nélkül is.
Mi van, ha begyűjtök valami malware-t, ami erre szakosodott és betelepszik az EFI-be, gyakorlatilag eltávolíthatatlanul?
Ezt elvben nem tudja megakadályozni a SB?
(Ha ennek nem pontosan 0 az esélye, az számomra máris rizikótényező. :) )

a Secure Boot semmilyen kompromitációt nem tud megakadályozni. Csak jelezni tudja ha szerinte már történt ilyesmi.

Ha az EFI/BIOS vírusos lesz, akkor onnantól biztosan nem bízhatsz meg benne. -> firmware update, és/vagy hardver csere. - de ez már a Secure Boot-tól teljesen független téma.

--
zrubi.hu

( zither | 2018. 01. 22., h – 11:49 )

A secure boot legfontosabb feladata, hogy meggyőződjön arról, hogy a kernel, amit betölt, az eredeti, módosítatlan állapotban van, nem kompromittálódott. Ezért kerül aláírásra a kernel, mivel ez a digitális aláírás, aminek sértetlenségével ezt ellenőrizni tudja. Ha a kernel aláírása nem stimmel, akkor nem indítja el a kernelt. A kernel elindítása után már nem okoz semmit a secure boot, mivel az alap kernel indítása után már az adott OS felelőssége, hogy meggyőződjön a további futtatandő kódok hitelességéről. Ennek megfelelően minden modern OS-ben van védelem arra, hogy csak megbízható sértetlen kódokat töltsön be kernel szintre (általában kernel modulokkal, windows alatt eszköz illesztőkkel kell ezt megtenni). Jellemzően ezt ugyan úgy digitális aláírásokkal teszik meg, csak egy jóval szélesebb körben (az UEFI-nek elég tudnia az OS gyártókról, a kernelnek tudnia kell - az egyebként nagyobb számosságú - hardver gyártókról). Az OS-ekben ez a fajta védelem egyébként régebben megjelent, mint az UEFI. A secure boot tehát felfogható az OS-ek ezen védelmének kiterjesztésére, amely így már az alap kernelt is lefedi.

Ez azt jelenti, hogy az SB csak azt tudja biztosítani, hogy a betöltődő alap kernel nem esett át jogosulatlan változtatáson a kiadás óta. (A kiadó az, aki aláírja a kernelt). Ha kikapcsolod, akkor ezt az alap kernelre vonatkozó extra OS védelmet veszíted csak. A kernel modulok/illesztők védelme továbbra is megmarad (már ha nem kapcsolod azt is ki az OS-ben).

Egyébként itt egy leírás a SecureBoot/Linux viselkedésről, ha még nem olvastad volna: http://www.rodsbooks.com/efi-bootloaders/secureboot.html

Zavard össze a világot: mosolyogj hétfőn.

( zrubi v | 2018. 01. 22., h – 14:13 )

Egyébként ez az egész Secure Boot legtöbb Linux disztribúció esetében pusztán parasztvakítás.
Ugyanis általában azt csinálják, hogy betesznek egy aláírt boot loadert (grub) ugyanis az EFI ezt tölti be, nem direktben a kernelt. Ez pedig - mivel ő is csak egy boot loader, olyan kernelt indít amilyet csak akar. Ehhez már a SB-nak semmi köze és beleszólása nincsen.

Szóval, visszatérve az eredeti kérdésedre: nagyon nagyon nagy valószínűséggel semmilyen hátrányt nem szenvedsz a kikapcsolásával.

Sőt, megkockáztatom, hogy mivel nem is igazán tudod mi ellen "véd", így eddig is csak hamis biztonságérzetet adott ;) - ha egyátalán bármit is adott.

--
zrubi.hu

Megnézem zither linkjét, utána lehet, hogy többet értek a dologból.

Előrebocsájtom, nem vitatkozni akarok, csak leírom amit tapasztaltam: gyártottam egy pendrive-ot, amiről bootolni tudtam (volna, elvileg :D) különböző ISO-kat. Grub felment, Ubuntu szépen bootol róla, Debian visszaszólt, hogy nincs aláírva. Kipróbáltam "szólóban", úgy sem -> OK, ez tényleg nem megy. De... volt ott egy OpenSuSE vagy Fedora is. Na az önmagában, az ISO-t dd-vel pendrive-ra kirakva bootolt, ebben a felállásban nem, arra hivatkozott, hogy a kernel nincs aláírva. (ha elég, hogy a grub van aláírva, akkor miért nem ment ez utóbbi, ha a grubnak aláírtnak kell lennie, de mégsincs, akkor az ubuntu miért ment?)

Azzal viszont vitatkoznék, hogy hamis biztonságérzet. Windows-on a víruskereső vagy linuxon az rkhunter sem tudom, hogy konkrétan mi ellen véd, nem is hiszem, hogy 100%-os védelmet nyújt, de van amit megfog, már az is több, mintha nem lenne... ;)

Konkrétumok:
Ahogy kezdődött:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/…

Én még anno a fenti cikk idejében próbáltam ki. Akkor az aláírt grub bármit betöltött, amit csak kértem tőle.

Jelenleg:
https://wiki.ubuntu.com/UEFI/SecureBoot/Testing
https://wiki.debian.org/SecureBoot#Secure_Boot_General_Information
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…

TLDR;
Nem a grub-ot írják alá a "nagyok" hanem egy köztes 1st stage boot loadert: shim.
Ez tölti be az aláírt grub-ot, ami meg betölt akármit - ami valid kulccsal alá van írva.
(az, hogy hogyan kell saját kulcsot "feltölteni" a RedHat-os írás tartalmazza)

Tehát, akinek root joga van a gépen, az tud telepíteni bármilyen kulcsot, és az ezzel aláírt kernelt/boot loadert a shim be fogja tölteni.

(Az, hogy a boot során feltűnik-e a felhasználónak, hogy lett egy új local kulcs, és az épp betölteni készülődő kernel mivel van aláírva, azt nem tudom.)

--
zrubi.hu

Rebootnál (legalábbis az én gépem) elég feltűnően jelzi, hogy új kulcsot akar telepíteni és még akkor is jóvá kell hagynom, különben ignorálja.
Szóval ez a rész nem annyira triviális a rosszfiúk számára.

(igen, az a grubos dolog hülyeség volt részemről, valóban nem a grub van aláírva)

Akármilyen boot loadert nem szokás aláírni. Gyakorlatilag (ha nem magadnak csinálod), csak olyan boot loadert szokás aláírni, amelyek maguk is fenn tudják tartani a megbízhatóság és sértetlenség ellenőrzését.
Igazából az egész secure bootra úgy kell tekinteni, mint az OS-ekben régóta meglévő aláírás ellenőrzés kiterjesztése, amely lehetővé teszi, hogy az alapkernel sértetlenségéről is megyőződjön a rendszer, ne csak az illesztők/kernel modulok essenek át ellenőrzésen.

Mondjuk az más kérdés, hogy a tömeges támadások egyre kevésbé foglakoznak a preboot fertőzésekkel, köszönhetően a különböző védelmi mechanizmusoknak. Tény, hogy a techika arany korát a boot vírusok képviselik, amiket a 2000 környékén megjelenő bioszokban jelenlévő boot sector védelem elég jól kikapált.
Meg az is elég jól befolyásolja a trendeket, hogy a desktopot támadó hekkerek számára két legfontosabb értéket - a gépidőt és az adatokat - hatékonyan elérhetik az OS kompromitálása nélkül is (ami a védelmi techikáknak köszönhetően manapság elég nehéz).

Titkosított partició használata esetén viszont erősen ajánlott a secure boot használata, mivel ez az egyetlen lehetőséged, hogy megőrizd a titkosított patíciót feloldó kód sértetlenségét. (Elég gyorsan felül lehet csapni a sima fat partición lévő alapkernelt egy olyan változattal, amely elmenti valahová a feloldáshoz használt jelszavat.) Az megint más kéréds, hogy érdemes lenne a firmwarek irányába is valamilyen biztonsági réteget behozni, mivel jelenleg azok a leggyengébb pontok ebben a rendszerben.

Zavard össze a világot: mosolyogj hétfőn.