16. toukokuuta 2022

  UEFIn tietoturva-ajattelun ongelmakohtia
  

UEFI-alkulatausjärjestelmän tietoturva perustuu ns. Secure Boot -toimintoon. Secure Boot tarkoittaa sitä, että tietokone suostuu ajamaan vain tietyllä sallitulla julkisella avaimella purettavan allekirjoitetun ohjelmabinäärin, esimerkiksi käyttöjärjestelmän alkulataajan. Sallitut avaimet tallennetaan UEFI-firmwaren sisältävälle ROM-piirille (johon vakiintuneesta nimestään huolimatta voi nykytietokoneissa myös kirjoittaa) tai CMOS-piirin datatauluihin. Ongelmana tämänkaltaisessa tietoturva-ajattelussa on, että mikään ei estä ring 0-tasolla toimivaa ohjelmaa muuttamasta noita avaimia.

Ilmeisesti hyvin moni ammatikseenkin näiden asioiden parissa työskentelevä ei enää oikein ymmärrä sitä, että firmwarepiiriltä muistiin ladattu ns. SETUP-ohjelma ei tee mitään sellaista, mitä mikä tahansa levyltä muistiin ladattu ohjelma ei pystyisi tekemään. Itsestäänselvästi (ainakin sen pitäisi olla itsestäänselvyys) koko SETUP-ohjelma voidaan aivan yhtä hyvin ladata muistiin firmwarepiirin sijasta vaikka levykkeeltä tai kiintolevyltä - muistiin ladattu koodi ei suorituksen aikana voi sitä tietää, millä tavalla se on tietokoneen muistiin joutunut. Ennen oli melko yleistä, että SETUP-ohjelma ei sijainnut firmwarepiirillä, vaan se käynnistettiin joko levykkeeltä tai kiintolevyllä olevalta piilo-osiolta.

Myös ROM-piirille kirjoittaminen, joka nykyemolevyillä on mahdollista, onnistuu muillakin ohjelmilla kuin emolevyvalmistajan virallisella firmwarepäivitysohjelmalla. Itse kirjoitusprosessi tapahtuu eri emolevyillä eri tavoilla ja kirjoittaminen vaatii emolevykohtaista koodia, mutta kyse ei ole varsinaisesti ylitsepääsemättömästä ongelmasta asiaan omistautuneelle hakkerille.

Tästä voidaan päätellä, että koko Secure Boot -toiminnallisuuden rampauttaminen onnistuu ohjelmallisesti. Käytännössä haittaohjelma voi vaikka käyttää hyväkseen jotain käyttöjärjestelmän privilege escalation -haavoittuvuutta tai huijata käyttäjän suorittamaan itsensä järjestelmänvalvojan oikeuksilla. Secure Boot ei siis tarjoa minkäänlaista suojaa rootkittejä kohtaan, vaikka se on juuri niitä vastaan kehitetty.

Ainoa oikeasti toimiva tapa suojata tietokoneen käynnistys on kirjoitussuojata firmware- ja CMOS-piirit fyysisesti esimerkiksi jumpperilla. Käynnistysjärjestyksen on oltava lukittu niin, ettei se voi vahingossa muuttua. Yksi toimiva tapa on esimerkiksi asettaa tietokone käynnistymään pelkästään levykkeeltä perinteistä bootsector-käynnistystapaa käyttäen. Levykkeellä on oltava fyysinen kirjoitussuojaus päällä. Levykkeeltä sitten ladataan alkulataaja, joka varmentaa kryptografisesti kiintolevyllä olevan varsinaisen käyttöjärjestelmän alkulataajan tai kernelin, lataa sen muistiin ja suorittaa sen. Levykkeen sijasta voi käyttää käynnistysmediana myös kerrankirjoitettavaa optista levyä. Fyysinen kirjoitussuojaus varmistaa, ettei käynnistyskoodia muuteta ohjelmallisesti minkään haittaohjelman toimesta.

Ammattilaistenkin ymmärrys näistä asioista on heikentynyt, ja epäilen sen johtuvan etenkin Microsoftin harjoittamasta käyttöjärjestelmien mystifioinnista. Nykyään valitettavasti moni userspace-ohjelmia työkseen tekevä ihminenkin pitää vähintään jonakin velhona sellaista henkilöä, joka kirjoittaa oman käyttöjärjestelmän. Olisi hyvä, jos alan kouluissa opeteltaisiin tekemään bootsector-boottaava ohjelma ainakin osana jotain kurssia. Ohjelman ei tarvitse olla monimutkainen, vaan periaatteena voisi olla vaikka kirjoittaa ensin jokin yksinkertainen käynnistyssektorille mahtuva koodinpätkä assemblyllä ja ladata sillä muistiin joku useamman sektorin kokoinen ohjelma, joka tehdään ainakin osittain C:llä kirjoitettuja moduuleja yhteen linkittämällä. Ohjelman ei tarvitse tehdä mitään järkevää, vaan pääasia on konkretisoida se, miten tietokoneen firmware lataa muistiin ensimmäisen käyttäjän ohjelman.


  Virheellisiä ratkaisuehdotuksia UEFIn tietoturvaongelmiin
  
Kuten ylempänä kirjoitin, ainoa oikeasti toimiva tapa toteuttaa loogisesti kestävä tietoturva on fyysisesti kirjoitussuojata käynnistysmediat ja niihin liittyvät tietueet. Jostain syystä nykyemolevyissä ei kuitenkaan enää fyysisiä kirjoitussuojausjumppereita ole, vaikka ennen ne olivat yleisiä varsinkin ammattikäyttöön tarkoitetussa laitteistossa. Sen sijaan korvaavaksi ratkaisuksi tarjotaan lisää kryptografista varmennusta.

Eräät tietokonevalmistajat ovat "suojanneet" firmwarepiirille kirjoitusprosessin erillisellä apupiirillä niin, ettei firmwarepiirille ole mahdollista kirjoittaa sellaista firmwarea, jota ei ole kryptografisesti allekirjoitettu emolevyn valmistajan toimesta. Tässä on kaksi merkittävää ongelmaa. Ensinnäkään tämä ei estä haittaohjelmaa muuttamasta CMOS-piirin tietueiden sisältöä. Toinen ja ehkä merkittävämpi ongelma on, että tällainen suojaus estää käyttäjää asentamasta tietokoneeseensa mukautettua firmwarea, kuten vapaan lähdekoodin Coreboottia. Tässä tapauksessa "suojaus" siis lähinnä rajoittaa tietokoneen omistajan vapauksia käyttää laitettaan haluamallaan tavalla.

Näissä kirjoitussuojauksen "korvaavissa" ratkaisuissa on huomattava se, että ne johtavat aina tietokoneen hallinnan siirtymiseen loppukäyttäjältä tietokoneen valmistajalle. Laitevalmistajat haluavat pitää itsellään kontrollin siitä, minkälaisia firmwarepäivityksiä tietokoneelle asennetaan. Jos tietokoneen firmware päivittää itse itsensä, saattaa päivitysprosessi asentaa automaattisesti järjestelmään esimerkiksi jonkin valtiollisen tahon käyttämän hyvin matalan tason takaportin.

Kryptografinen suojaus toimii tietoturvaa parantavasti vain, jos loppukäyttäjä voi itse päättää sallitut avaimet. Silloinkin suojaus lakkaa toimimasta ajan myötä suojauksessa käytetyn salausalgoritmin käydessä liian helpoksi murtaa, joten pelkän kryptografisen suojauksen varaan ei käynnistystietoturvaa voi laskea, vaikka avaimet olisivatkin käyttäjän omissa käsissä.

Yleinen argumentti fyysistä kirjoitussuojausta vastaan on, että se ei toimi, koska tyhmä kotikäyttäjä ei osaa ottaa kirjoitussuojausta pois firmwarepäivitystä varten. Voitaneen kuitenkin olettaa, että em. tyhmä kotikäyttäjä ei myöskään saa kirjoitussuojausta päälle, mikäli se vaatii tietokoneen avaamisen ja jumpperin asettamisen oikeaan asentoon. Tietokone voidaan siis toimittaa käyttäjälle kirjoitussuojaus pois päältä ja tietoturvasta välittävä edistynyt käyttäjä voi sitten halutessaan asettaa jumpperin kirjoitussuoja-asentoon. Asiasta ymmärtämätön peruskäyttäjä taas ei jumpperiin tule ikinä koskemaan ja tällöin kirjoitussuojaus pysyy hänen käytössään pois päältä.

Toinen yleinen argumentti fyysistä kirjoitussuojausta vastaan on, että se ei toimi yrityskäytössä, jossa päivitykset (myös firmware-) pitää voida automatisoida. Tässä on tiedostettava, että jos tietoturva halutaan ottaa vakavasti, niin tietoturvakriittisten asioiden muuttamisen pitää vaatia fyysinen pääsy tietokoneen luokse. Jos joku yritys haluaa ottaa tietoturvan vähemmän vakavasti, niin se voi sitten olla edellisessä kappaleessa mainitun tyhmän peruskäyttäjän tavoin käyttämättä sitä fyysistä kirjoitussuojausta. Tämäkään argumentti ei siis varsinaisesti toimi fyysistä kirjoitussuojajumpperia vastaan, koska se jumpperi ei pelkällä olemassaolollaan pakota ketään käyttämään fyysistä kirjoitussuojausta.

Yritysnäkökulma on muutenkin mielenkiintoinen, koska tämä koko ongelma on suurelta osin saatu aikaan niin, että IT-alan yrityksissä on yrityksen sisäisiä tietoturvakäytäntöjä, jotka usein sallivat vain tiettyjen työntekijöiden pääsyn palvelinten luokse. Useinkaan nämä tietokoneiden luokse pääsevät henkilöt eivät sitten ole samoja kuin he, joiden pitäisi hoitaa firmwarepäivitykset. Ongelmaa on sitten lähdetty ratkaisemaan kehittämällä tapoja tehdä etänä asiat, joiden tekemiseen tarvittiin aiemmin fyysinen pääsy tietokoneen luokse, kuten se firmwarepäivitys. Lopputuloksena sitten tietoturva on entistä huonompi, koska nyt kuka tahansa voikin tehdä muutoksia firmwareen, jos etäpäivitysjärjestelmästä löytyy sopiva tietoturva-aukko.