Grand Unified Boot Loader v2:sta eli GRUB2-käynnistyslataajasta on löytynyt vakava tietoturvaongelma. GRUB2-käynnistyslataajaa käytetään oletuksena lähes kaikissa merkittävissä Linux-jakeluissa, minkä lisäksi se on suosittu muun muassa useamman käyttöjärjestelmän kokoonpanoissa.
BootHole nimen saanut GRUBin konfiguraatiotiedostosta löytyvä puskurin ylivuotohaavoittuvuus antaa hyökkääjälle mahdollisuuden asentaa pysyviä ja hyvin piiloutuvia haittaohjelmia huolimatta Secure Boot -teknologiasta. Jos hyökkääjä saa ujutettua haittaohjelman mukaan, se voi vaihtaa käynnistyslataajan vihamieliseen versioon, mikä voi pahimmillaan antaa hyökkääjälle täyden hallinnan koko ladattavaan käytttöjärjestelmään. Haavoittuvuuden tunnistekoodi on CVE-2020-10713.
Secure Boot -teknologian on tarkoitus estää kaiken muun, kuin erikseen allekirjoitetun koodin ajaminen UEFIssa. Jotta jokaisen valmistajan ei tarvitsisi erikseen varmentaa kaikkia mahdollisia firmware-versioit, ajureita tai muita käynnistyksen yhteydessä ennen käyttöjärjestelmää ajettavia sovelluksia, käytetään yleisimmin koodin allekirjoittamiseen Microsoftin kolmansien osapuolten Certificate Authority -palvelua, jossa Microsoft varmistaa ja allekirjoittaa koodin. Tällöin OEM-valmistajille riittää Microsoftin 3rd Party UEFI CA -sertifikaatin hyväksyminen.
Käytännössä esimerkiksi Linux-jakeluiden kehittäjät lähettävät Microsoftille allekirjoitettavaksi ”shimmiksi” kutsutun pienoisohjelman, jonka kautta he pystyvät lataamaan haluamiaan ohjelmia ilman, että jokaista tarvitsisi allekirjoittaa erikseen. GRUB2:n haavoittuvuus mahdollistaa tämän kautta haitallisen koodin ajon ja jopa koko käynnistyslataajan vaihdon toiseen. GRUB2:n haavoittuvuuden hyödyntäminen vaatii korotetut oikeudet järjestelmään, mutta ei fyysistä tai paikallista pääsyä itse kokoonpanoon.
Haavoittuvuuden löytäneen Eclypsiumin artikkelissa mainitaan, että haavoittuvuus vaikuttaisi järjestelmiin, joissa käytetään Secure Bootia yhdessä Microsoftin 3rd Party UEFI CA:n kanssa riippumatta siitä, käytetäänkö niissä GRUB2:ta, mutta ainakin allekirjoittaneelle jäi epäselväksi, miten GRUB2:n haavoittuvuus voisi vaikuttaa järjestelmiin, joissa sitä ei käytetä.
Lähde: Eclypsium
Kutakuinkin kaikki Linux-distrot oletuksena.
Lukasin tuon tekstin ja ongelma on siis grubin käyttämä flex parseri jolla luetaan grub.cnf tiedosto. Kyseinen parseri tekee koodia joka olettaa ettei tietyissä tilanteissa heitetty fatal_error koskaan palaudu, mutta joka kuitenkin palautuu ja koodin suoritus jatkuu. Tästä aiheutuu overflow jota hyödyntämällä tosiaan kaikki nuo shimmit ja validoinnit ovat turhia. Niissä itsessään ei ole vikaa.
Ja tietenkin se oleellinen. Tämä vaatii rootin oikeudet kohdejärjestelmään. Rootin oikeuksilla voi tämän haavoittuvuuden kautta päästä vielä korkeammalle tasolle, eli sörkkimään allekirjoitettuja bootti binäärejä. Niihin ei edes rootilla pitäisi olla asiaa ilman secure bootin rikkoutumista.
aika kaukana kätevästä
Ei se tuo megamöhkö GRUB(2):kaan millään tasolla kätevä ole. Tai ehkä siinä että se on yleensä valmiina. Mutta ihan pätevä tuo systemd-boot on, 4/5 omista koneista boottaa sillä ja hyvin toimii. Yhdessä on vielä GRUB koska siinä ei ole UEFIa, mutta kunhan rauta vaihtuu niin tulee systemd-boot siihenkin.
IMHO otsikossa on selvästi virhettä: Haavoittuvaisuus joka vaatii root-oikeudet on kaikkea muuta kuin VAKAVA haavoittuvuus.
Haavoittuvuus, joka mahdollistaa koneen opwnaamisen verkosta ilman mitään oikeuksia koneella olisi VAKAVA haavoittuvuus.
Kai haavoittuvuus voidaan tulkita vakavaksi, kun sen rating on 8.2 eli "high" (toiseksi korkein) CVSS v3.0 asteikolla?
Jos root-oikeudet vaativalle haavoittuvuudelle jossain rankingissä annetaan tuollainen luokitus niin sitten niissä ranking-perusteissa on jotain pahasti vialla.
Joo systemd-boot on huomattavasti kevyempi ja yksinkertaisempi. Vakiona sitä vaan taitaa käyttää ainoastaan Pop_OS tällä hetkellä
Kyse ei ole pelkästään siitä kuinka helposti haavoittuvuutta voi hyödyntää, vaan myös sitä kuinka pahoja ongelmia se mahdollistaa. Tällä voi käytännössä kiertää kaikki mahdolliset suojaukset ja valvonnat. Se että vaatii rootin oikat, tekee siitä tietenkin vaikeasti hyödynnettävän. Mutta se että roottina voit piilottaa haittakoodia ja ohittaa perustavaa laatua olevat suojaukset ilman että kukaan huomaa… On se vakava. Kaikki käyttistason suojaukset kuitenkin perustuu siihen ettei tätä nyt murrettua tasoa ole murrettu.
Grub elää UEFI payloadina siinä missä mikä tahansa muukin EFI sovellus. Jos vuosituhannen alun GRUB ja LiLo aikoja muistelee niin metsään menee. Isoin ongelma vuodosta tulee firmoille koskapa tämä antaa eväät kiertää laitelukitukset ja ajaa allekirjoittamattomia käyttöjärjestelmäosioita.
Kyse on myös siitä, että tietoturva on menetetty täysin jo siinä vaiheessa kun haitake saa ne rootit, koska jo silloin se voi kiertää käytännössä kaikki mahdolliset suojaukset ja valvonnat. Käyttistason suojaukset perustuvat siihen, että rootteja ei jaella kenelle hyvänsä. Secure boot on vain yksi suojauskerros lisää, eikä edes mikään järin oleellinen, sen voi kytkeä biossista (uefista) pois eikä turvallisuus siitä pahemmin miksikään muutu. Se ei edes ole ollut järin kauaa Linuxeissa yleisessä käytössä mukanaan tuomien ongelmiensa takia, ja silti niiden turvataso oli silloinkin monta kertaluokkaa parempi kuin Windowsin secure bootin kanssa.
Vakavia hyökkäyksiä ovat ne, jotka mahdollistavat niiden roottien saamisen. Sen jälkeen siinä ei ole mitään uutta tai ihmeellistä, että aikaan saatua tuhoa rajoittaa lähinnä hyökkääjän mielikuvitus. Kyseisestä syystä tämä ei ole sen vakavampi hyökkäys kuin esim. se Ryzenfall kavereineen, jota myös huudeltiin tositositosivakavana reikänä.
Tuli mieleen sanoa, että EFISTUB taidetaan vaatia myös systemd-bootissa, mutta sillä ei nyt väliä.
Isompi ongelma on se, että ilman erikseen asennettua bootloaderia kaikki BIOSin käyttöliittymät eivät mahdollista kernelin komentorivin muokkaamista ennen kuin käyttis on bootattu. Esim. vianetsinnässä voisi olla kätevä editoida komentoriviä ja laittaa joku iommu=off tai vastaava sinne. Jos ei voi editoida, on hyvä olla BIOSissa jokin toimiva konfiguraatio varalla. Samoin entryjen lisääminen BIOSista käsin ei välttämättä onnistu. Näin ainakin kaikilla UEFI-koneilla, mitä itse olen testannut. Jossain yritysläppäreissä voi tehdä hiukan enemmän, mutta aika rajallisesti niissäkin.
Mitä uutisen aukkoon tulee, samanlaisia aukkoja voisi periaatteessa olla BIOS-koodissa. Kyse on vaan siitä, mihin se bootloaderin valikko on sijoitettu, BIOS ROMille vai levylle. Ellei tietoturvan kanssa tarvi foliohattuilla, systemd-boot on varsin kätevä normaalille käyttäjälle.
Secure bootin turvallisuudesta voi olla montaa mieltä, mutta idea kai olisi, että jos niin haluaa, sinne biosiin ei pääse ilman autentikointia poistamaan secure boottia ja koko boot-prosessi olisi lukittu ja varmennettu alusta loppuun. Oleellinen, jos tehdään jotain suojattua alustaa vaikka pelikoneeseen tai pankkikäyttöön jne.
Valitettavasti ihan nykypäivän GRUB2:sta on puhe, turha niitä muinaisGRUBeja ja Liloja esiin kaivaa.
Erityisesti EFI binaarina täysin tarpeeton tavallisiin käyttötarpeisiin. Ylipäätään raskas ja tarpeettoman monimutkainen, taipuu toki vaikka mihin mutta jos pitäisi saada vaan bootattua kone ilman kommervenkkejä niin ei paljoa lämmitä. Toki jos tykkää rakennella ihmeellisiä boottihimmeleitä tai muuten vaan harrastaa jätelava-SERriä niin ei niitä hyviä vaihtoehtoja paljoa ole.
Noiden bootloaderien kokoerot ovat melkoisia. GRUB2-paketti on tässä koneessa 32,8 MB, Syslinux 4,2 MB, rEFInd 4,3 MB ja systemd-boot 0,087 MB. Ellei tykkää rakennella monimutkaisia ketjulataus-himmeleitä ja verkkoboottia, GRUB2 on kyllä tarpeettoman raskas ihan harrastelijallekin. Olen itse suosinut systemd-bootia ja syslinuxia. Syslinux on kätevä, kun sama konffi toimii myös legacy-koneissa. Saa tehtyä vaikka boottaavan tikun, joka toimii suoraan ennen ja jälkeen 2009 koneissa.
Ei nyt ihan. Ennen osiotaulua on 446 tavua tilaa ja mikäli haluaa pysyä yhteensopivana Windowsin kanssa, sitäkään ei kaikkea voi käyttää.
Stage1-lataaja ainoastaan lataa seuraavan vaiheen levyltä muistiin ja hyppää seuraavan vaiheen koodiin. Vaihe ei paljon muuta tee. Siinä on tieto, miltä levyltä ladataan ja se selvittää levyn "geometrian" ja mistä kohtaa ladataan. Jos blokki on liian kaukana (>1024. sylinteri), voi tarvita lisäkoodia perus-BIOSin ohi. Lisäksi mukana on koodia virheen ilmoittamiseen jos jokin ei toimi. Stage1:ssä ei ole edes valikkoa.
Paino sanalla legacy ja hyvin riittää ketjulataamiseen. GPT kanssa homma menee ihan erilailla. Sinänsä rajusti aiheen ohi, kun uutinen liittyy allekirjoitettuihin levykuviin eikä niitä tukevia lataajia ole montaa.
Se stage 1 on hyvin pieni osa legacy grubbia. Jos sinulla on stage 1.5 tai 2, niin koko grub ei sinne MBR:ään mene. Tämä on se yleisin käyttötapa kuitenkin. Muussa tapauksessa jos ketjulataat jotain muuta, niin se MBR-osa on niin triviaali määrä koodia ja tekee aina saman asian, että en lähtisi sitä nimeämään oikein miksikään.
data-unfurl="true" data-result-id="64364" data-url="https://www.securityweek.com/red-hats-boothole-patches-cause-systems-hang" data-host="www.securityweek.com" data-pending="false">
class="link link--external fauxBlockLink-blockLink"
target="_blank"
rel="nofollow noopener"
data-proxy-href="">
Red Hat's BootHole Patches Cause Systems to Hang | SecurityWeek.Com
http://www.securityweek.com
Aika rohkea väite, kun kyseessä kuitenkin de-facto tietoturvaluokitus.
Juu jos oikein olen ymmärtänyt niin ei sillä systemd-boot palikallakaan mitään tee jos ei ole systemd ottamassa koppia seuraavassa vaiheessa.
Ei se näin mene. UEFI:ssä tilanne on melko erilainen, kun UEFI tarjoaa ison määrän palveluita toisin kuin BIOS. Systemd:ssä on bootctl erikseen konffaamiseen, mutta EFI-osioon tuleva palikka on se vajaa 90 kB. Lisäksi systemd-boot minusta vaatii että kerneliin on käännetty EFISTUB-tuki eli että kerneli osaisi bootata itse itsensä ilman valikkoakin. Jotkut toiset UEFI-bootloaderit eivät tätä vaadi. Joka tapauksessa systemd-bootin rooli on tässä olla varsin pieni välikappale. En ihan tarkkaan tiedä, mitä kaikkea sillä voi tehdä, kun omissa koneissa se on aika perusasetuksilla. Varsinaisen systemd initin lataaminen tapahtuu vasta kernelin lataamisen jälkeen. Joko initramfs:ltä tai initramfs:n ekan initin jälkeen root-osiolta tai jos ei initramfs:ää ole, niin silloin suoraan root-osiosta ekana inittinä.
"It is simple to configure but it can only start EFI executables such as the Linux kernel EFISTUB, UEFI Shell, GRUB, or the Windows Boot Manager.” tuolta:
data-unfurl="true" data-result-id="64373" data-url="https://wiki.archlinux.org/index.php/systemd-boot" data-host="wiki.archlinux.org" data-pending="false">
class="link link--external fauxBlockLink-blockLink"
target="_blank"
rel="nofollow noopener"
data-proxy-href="">
systemd-boot – ArchWiki
wiki.archlinux.org
Sellainen kuva minulle on noista tullut, että CVSS-asteikko ei ole kovin lineaarinen ja vakaville* haavoittuvuuksille annetaan yleensä luokitus 10/10. Hyvä vai huono systeemi, siitä voi varmaan olla montaa mieltä. Omasta mielestäni tuo on ihan looginen tapa.
* Sellaisille, joista sinäkin tuossa ylempänä mainitsit.
Onhan tuo haavoittuvuus sinänsä ihan vakavan kuuloinen, vaikka hyödyntäminen vaatiikin root-oikeuksien saamista. Aika hyvässä piilossa se haittakoodi olisi tuolla.
Onnistuisiko tällä siis asentaa Linux:sta tuonne bootloaderiin haittakoodi ja jos dual-boot windows niin saada myös se Windows siitä samasta bootloaderista saastutettua?
Näihin taisi tulla jo korjaus ainakin joillekin distroilla eli ongelma jo huomattavasti vähäisempi.
Raskas missä mielessä? En edes Core2 duolla huomannut mitään raskautta, puhumattakaan uusista prosessoreista.
Ongelma ei oikein avaudu ihmisille, koska koko hommastahan ei ole juuri mitään käytännön haittaa harrastajille. Enemmänkin hyötyä joissain tapauksissa.
Kärsijäksi joutuvat lähinnä yritykset, joilla on jonkinlainen tarve rajata laitteitten käyttöä.
MMan yllä tiivisti asian mainiosti.
Kannattaa lukea viesti läpi. Yksi bootloader on 87 kB ja toinen 32800 kB. Tekevät saman asian eli boottaavat koneen. Molemmissa on myös valikko. Aika monella peruskäyttäjällä tarpeet loppuvat tasan tarkkaan tähän. Nyt kun kyseessä on uutinen siitä, että softassa on tietoturva-aukkoja, arvaapa kumpaa on helpompi auditoida, 87 kilon vai 32800 kilon palikkaa?
Kommentoi uutista tai artikkelia foorumilla (Kommentointi sivuston puolella toistakseksi pois käytöstä)
Lähetä palautetta / raportoi kirjoitusvirheestä