Seis, Intel – palataan kesällä!

Reading Time: < 1 minute

Yksi ikävimmistä tavoista aloittaa päivä on huomata, että oma kone ei toimi.

Näillä ohjeilla pistät Intelin mikrokoodi epävakaat jakelut toistaiseksi paussille, apt-pohjaisissa Linuxeissa kuten Ubuntussa.

(Microsoft-laitteille tietoiskua Microsoftin sivulta)

Jos pääsiäisen 2018 tienoilla yhtäkkiä Ubuntu-tietokoneenesi tuntuu “hajoavan”, esimerkiksi näyttämällä kernel panic, tarkista ensin onko kyseessä vain huono ohjelmistopäivitys. Saatat selvitä turhan uuden laitteen ostamiselta, ja kaikelta muulta rumbalta mikä siihen monesti liittyy.

TL;DR: Jos haluat estää mikrokoodipäivityksen

  1. Avaa shelli
  2. sudo apt-mark hold intel-microcode
  3. Tarkista, että meni perille.
  4. Seuraa uutisia seuraavan 3-6 kk aikana aika-ajoin
  5. Kun intel-microcode paketti on alkanut stabiloitua ja kaatumisuutisia ei kuulu, voit ottaa päivitykset käyttöön:
    sudo apt-mark unhold intel-microcode

Tarkista hold ajamalla vielä yksi komento

Helppo tarkistaa, menikö hold perille:

$ apt-mark showhold
intel-microcode

Muista tarkistella aika ajoin miten asia kehittyy. Nyt toistaiseksi, jos pidät muuten koneesi tietoturvallisena, eli Linuxissasi ei ole potentiaalisesti tuntemattomia käyttäjiä sisällä, en näkisi ongelmatilanteen estämiseksi mikrokoodipäivitysten lykkäämistä huonona ideana.

Tasapainottelua: teoreettinen ongelma vai kaatunut kone?

Käsittääkseni kotikäytössä koko Meltdown-ongelma on varsin pieni. Meltdown sallii sivukanavaa pitkin tapahtuvan tiedon lukemisen; käytännössä monen käyttäjän servereissä kernelin muistisuojaus pettää, koska modernien prosessorien cachet ja predictive branching sallii käytännössä prosessille tilaisuuden vakoilla limittäin tapahtuvan laskennan tuloksia niiden jättämien jälkien (“sivuvaikutusten”) perusteella.

Mitä ohjelmistopäivitykset oikein ovat?

Reading Time: 5 minutes

Käyttöjärjestelmä on yhtä turvallinen kuin sen päällä ajettavien ohjelmien tietoturva. Jotakuinkin näin ajattelen, käytännössä.

Ohjelmistopäivityksiä tulee yleensä vain oikeastaan kahdesta syystä: kehitys tai korjaus.

  • ohjelmaa on kehitetty: uusia ominaisuuksia, jo olemassaolevia parannettu
  • bugi korjataan: se voi olla harmiton, tai liittyä tietoturvaan

Usein automaattisissa ohjelmistopäivityksissä tulee molempia laatuja. Bugit ovat luonteeltaan sellaisia, että niitä havaitaan ajan kuluessa, ja kun käyttäjät huomaavat ohjelman käytön aikana jotain epänormaalia. Bugien “lopullista määrää” on teoriassakin mahdoton ennustaa; siksi ei voida sanoa, että ohjelma olisi koskaan täydellinen.

Etenkin älypuhelinten sovellusten päivitys on muuttunut varsin kivaksi käyttäjän kannalta. Itse tunnen lähinnä iOS (Applen puhelinten) toiminnan, ja koskaan sen kanssa ohjelmistopäivityksestä ei ole tullut mitenkään kynnyskysymystä.

Miksi ohjelmistopäivityksistä pitäisi tietää?

Ongelmallisimpia “koneita” ovat itse asiassa ne, joissa käyttäjällä ei ole mitään hajua, mikä on ohjelmisto, ja mitä tietoturvasta huolehtimatta jättäminen voi merkitä.

Tilanne, jossa tietokoneen annetaan olla niinkuin se on, ja pelätään asetusten muuttamista, on itse asiassa aika yleinen. Vaikka olen tehnyt käytännössä modernien (moniajavien, Windows- ja Linux käyttöjärjestelmien) parissa töitä ja harrastusta 20 vuotta, ajoittain huomaan itsekin nojautuvani tai ainakin toivovani voida valita passiivisen sivustakatselun. Tietotekniikkaa ja ohjelmistopäivityksiä voisi kuvata näin: ne ovat tosi kivoja, niin kauan kuin kaikki toimii kitkatta. Kun ongelmia tulee, selvittelytyöstä voi muodostua yllättävän pitkä ja mutkikas juttu.

Siksi – jotta nuo taustalla vaikuttavat asiat – valaistuisivat ja päivityksiin liittyvät pelot hälvenisivät, käyn hieman läpi myös tietotuvan ja ohjelmistojen päivitysten perusteita.

Tietoturva on “seksikäs” aihe mutta tavattoman tylsää tietyllä tapaa. Se on sellainen extra, jota useinkaan ei jaksaisi hoitaa käytännössä.

Olen ehkä siinä mielessä hieman poikkeus, että ihastuin tietoturvan periaatteisiin ja teoriaan koulun kautta. Silti, myönnän, että esimerkiksi pari kertaa viikossa aina 2 tuntia kerralla kuluttava podcast aihepiiristä on joskus puuduttavaa kuunnella. En voi aivan varauksetta suositella siis Steve Gibsonin ja Leo Laporten Security Now! -podcastia, vaikka se onkin alansa parhaita (jos haluat tarkkaa analyysiä erilaisista ajankohtaisista tietoturvaongelmia, paina ihmeessä Subscribe tuolle podcastille!). Se ei vain ole sellainen, joka kattaisi perustarpeita, vaan menee tosi syvälle asioiden taustoihin.

Itse asiassa: nyt käännyn teihin päin. Mikä on paras ja nasevin tietoturvauutispläjäys, joka antaisi myös käytännön ohjeet asioiden hoitamiselle? Kuunteletko tai katseletko säännöllisesti jotain tiettyä podcastia, vlogia tai vastaavaa? Laita kommentteihin!

Käyttäjänähän meitä kiinnostaa vain varsinaisten hommien tekeminen, eli se että tietokoneella saadaan aikaiseksi se, mitä alunperinkin alettiin tekemään.

Tietoturvaa vaivaa myös se, että asiasta puhutaan usein hyvin teknisin termein. Suomenkielistä, selkeää ja riittävän ytimekästä tietoa on myös aika vaikea saada – etenkin jos haluaa sitä riittävän nopeasti tietoturvaongelmien noustua.

Käyttis + softa + minä = kokonaisuus

Käyttöjärjestelmä (Windows tai Linux, Mac) on mikä on, mutta jos sen päällä olevat ohjelmat vuotavat ja bugittavat, “alla olevalla” turvalla ei ole merkitystä. Siksi käyttäjän itse tekemät päivitykset ja ennenkaikkea ymmärrys tietoturvasta on tärkeässä roolissa.

Kauan aikaa sitten, tarkoittaen 1980-lukua, käyttöjärjestelmissä ei ollut oikeastaan varsinaisesti mitään tietoturvaa. Ne oli ohjelmoitu olettaen, että ulkopuolisten ihmisten olisi hyvin vaikea päästä koneelle; Internetiä ei vielä ollut kotikäytössä.

Myös senaikaiset ohjelmistot eivät sisältäneet tarkoituksellisia heikkouksia, ja virukset ja muut haittaohjelmat olivat vasta tulossa 1990-luvulla.

Mikä “ohjelmisto” oikeastaan on?

Ohjelmisto (‘software’) on tietokoneen kannalta (näkökulmasta) kasa bittejä, jotka on tallennettu tiedostoon. Ennen ohjelman ajoa käyttöjärjestelmä lukee tiedoston muistiin, ja alkaa syöttää komentoja prosessorille. Ohjelma on siis aiemmin valmistettu ja käyttäjälle kopioitu, tiettyä järjestystä noudattava erityinen tiedosto.

Jos kirjoitat muistioon pienen pala tekstiä, se ei ole tietokoneohjelma. Jos tällaisen tiedoston yrittäisi syöttää prosessorille, saisit virheilmoituksen: prosessori ei tunnista komentoja mielekkääksi.

Joskus muinoin ohjelmat saattoivat olla niinkin pieniä kuin 5-10 tavua (eli lyhyitä, mitattuna komentojen määrällä). Lyhin ohjelma on periaatteessa 1 tavun mittainen, mikäli prosessorissa on sellainen komento, jonka tallennus vie vain 1 tavun muistia. Käytännössä ohjelmat ovat satojen tuhansien tai miljoonien tavujen mittaisia. Koon voit tarkistaa näin:

Ohjelmistotiedoston sanotaan olevan “executable”: ajettava eli ajokelpoinen. Vastakohtana ajokelpoisille tiedostoille ovat erilaiset data-tiedostot, jotka sisältävät ohjelmien käyttämää tietoa.

Kaikki ohjelmat koostuvat hyvin samanlaisista peruspalikoista: komennoista, joilla voidaan siirrellä tietoa keskusmuistissa. Tietoa voidaan verrata, kopioida, poistaa, ja näitä voidaan tehdä “loogisten ehtojen” voimin. Matemaattisesti operaatiot ovat

Automaattiset päivitykset

Aika usein nykyään käyttöjärjestelmä päivittää itsensä automaattisesti, eli ajastetusti ja “täydellisesti” (kaikkien osien suhteen). Tämä itsessään on ollut kenties eräs käytännön tietoturvan suurimmista edistysaskeleista. Hyvä niin!

Mutta, 3 syytä miksi automaattiset päivitykset eivät ole ratkaisu kaikkiin tietoturvaongelmiin:

  1. ajan kanssa kilpajuoksu
  2. automaatiikka on pois päältä
  3. joskus automatiikka ei sovellu (eli aiheuttaa enemmän ongelmia)

Ajan kanssa kilpajuoksu

Yksittäinen tietoturvauhka johtuu teknisesti “reiästä”, eli bugista ohjelmassa. Bugi on olemassa riippumatta siitä, onko sitä havaittu tai ei. Bugi on siis ohjelmakoodin logiikassa sellainen kombinaatio, joka on haitallista jos sitä käytetään tietoisesti (tai tahattakin). Esimerkkinä voisi heittää, että ohjelman on tarkoitus aina tarkistaa pääkäyttäjän salasana, ennenkuin se antaa tehdä tiettyjä toimintoja. Ohjelmaa on myöhemmin paranneltu, koodia kirjoitettu. Tuolloin koodaajalta on unohtunut lisätä tämä tarkistus. Ohjelmaan jää nyt bugi, jossa tietyssä erikoistapauksessa salasanaa ei tarkisteta, vaan normaali käyttäjä voi “luvatta” tehdä asian jonka pitäisi olla sallittu vain tunnistauneelle pääkäyttäjälle.

Mutta todennäköisyys, että joku oikeasti käyttäisi tuota ongelmallista bugia hyväksi, on aika pieni, jos reiän olemassaolosta ei ole tietoa. Tietoturvaan liittyvän bugin raportointi ja julkituonti on siis kaksiteräinen miekka. Samantien kun bugista tulee julkinen, alkaa myös mahdollisesti sen hyödyntäminen luvattomiin tarkoituksiin. Mutta raportointi saa liikkeelle prosessin, jossa yleensä joku kirjoittaa korjauspalasen (“patch”) – tälläinen tapahtuu yleensä 1-14 päivässä ja voimme käyttäjinä hyväksyä ohjelmistopäivityksen, jonka jälkeen ohjelma on turvallinen tämän bugin osalta.

Tietoturvahaavoittuvuuksista puhuttaessa, termi “responsible disclosure tarkoittaa sitä, että reiän ensimmäiseksi havainnut taho pyrkii tuomaan turvallisesti tiedon vain niiden (oletetusti “hyvien”) piiriin, jotka voivat korjata vian ennenkuin suuri yleisö saa siitä tietää. Etumatka voi olla merkittävä ja erittäin tärkeä, ja vähentää uhkan aiheuttamaa vahinkoa.

2. automaattiset ohjelmistopäivitykset tarkoituksella pois päältä

Aina siis automatiikka ei ole passé. Käytännössä tällaisia syitä, miksi käyttäjät estävät automaattipäivitykset, on joko että se häiritsee työntekoa, tai että esimerkiksi ohjelmistokehittäjänä itse haluaa kontrolloida tarkemmin mikä ohjelma muuttuu, ja milloin.

Keskinäinen riippuvuus ja “dependency hell”

Päivitysten kenties kaikkein arkaluonteisin puoli on, että ne saattavat aiheuttaa myös ongelmia. Tämä johtuu ohjelmistojen keskinäisestä riippuvuudesta.

Riippuvuudessa kysymys on: Jos tietokoneella on N kpl eri ohjelmistoa asennettuna, mitkä versiot kustakin pitää olla, jotta ne toimivat keskenään yhteen? Tarkemmin sanottuna yleensä kyse ei ole “kokonaisista sovelluksista”, vaan jaetuista ohjelmistokirjastoista. Kirjastoja asennetaan siksi, että ohjelmistokehitys helpottuu. Mutta tämä luo (tai; ainakin loi ennen) keskinäisriippuvuuden ja joskus myös noidankehän, jossa oli vaikea saada sopivia palasia paikalleen kokonaisuuden toimivuuden kannalta.

Käytännössä tuosta tulee matemaattisesti “N:n tekijän tulo”, eli kertolasku jossa on monta termiä. 3 ohjelmalla ja 5 versiolla jokaisesta saataisiin testijoukoksi 5*5*5 = 125 eri kombinaatiota. Todellisuudessa versioita on huomattavasti enemmän, samoin sovellusohjelmia. Käytännössä PC-koneella voisi kuvitella olevan 20 sovellusohjelmaa, ja niistä tarjolla ainakin tuo 5 versiota. 5^20 on aika tähtitieteellinen luku.

No totta puhuen nykyään – itse asiassa jo kauan aikaa sitten – tästä “dep hell” ongelmasta on päästy aika nerokkaalla mekanismilla yli: pidetään jokaisella ohjelmalle oma virtuaalinen kirjastonsa; eli jokainen voi kuvitella elävänsä omassa kopperossa, jossa käyttöjärjestelmä tarjoaa sopivat versiot.

Tosin dep hell toistuu eri muodoissa uudestaan. Eli pyörä keksitään myös uudestaan vuodesta toiseen, riippuen mistä ohjelmistoekosysteemistä ja käyttöjärjestelmästä puhutaan. Ratkaisumalli on olemassa, mutta sen käytännön sovelluksen rakentaminen on siis “work in progress”..

Edes täysin automaattisessa järjestelmässä kaikkien kombinaatioiden testaaminen ei olisi välttämättä kovin nopeata, saati käsin. Toinen iso ongelma todellisessa tilanteessa on, että kaikki operaatiot eivät välttämättä ole “peruttavissa” helposti. Toisinsanoen jos testataan A1.0 ja B1.0, jonka todetaan aiheuttavan ongelmia, ja haluttaisiin palata alkuperäiseen tilanteeseen jossa koneella ei ole kumpaistakaan ohjelmaa, voi olla niin että tuohon on vaikea päästä.

Käytännössä usein päädytään siihen, että kokeillaan toimisiko kaikista ohjelmista  viimeisimmät (tuoreimmat versiot). Onneksi sovellusohjelmien kohdalla “itsenäisyys” ts. riippumattomuus on lisääntynyt. Ohjelmat eivät ole usein enää niin

Riippuvuus on monimutkainen asia, usein niin monimutkainen, että lopulta päädytään vain takaisin aivan yksinkertaiseen määritelmään. Usein toimivuuden testaajana on me, käyttäjät. Ideaalitilanteessa ohjelmistot voisivat olla itseäänkorjaavia (self-healing) ja mukautua erilaisiin tilanteisiin, mutta tietoteknisesti kyseessä on vielä suhteellisen kaukainen unelma.

Seuraavassa osassa: ohjelmistopäivitykset Linuxissa (aptitude), ja semantic versioning esittely. Ehkä. Ainakin tuo aptitude!

Kriittinen Intel AMT haavoittuvuus (etähallinta)

Reading Time: 2 minutes

Haavoittuvuuden tunniste

Sisäisesti Intel kutsuu bugia “INTEL-SA-00075”. Kansainvälisesti se on tunnettu nimellä CVE-2017-5689

Millainen bugi on kyseessä?

Huonosti toteutettu osa Intel AMT -etähallintajärjestelmässä, joka kohdistuu pääkäyttäjän salasanan tarkistukseen, tekee järjestelmän käytännössä täysin turvattomaksi: salasanaksi riittää pelkkä tyhjä (“ei mitään”). Tämä koskee tietokoneita, joissa on jokin alla olevaista Intelin AMT firmwaren versio:

  • 6.x
  • 7.x
  • 8.x
  • 9.x
  • 10.x
  • 11.0
  • 11.5
  • 11.6

Jos hyökkääjä pääsee samaan sisäverkkoon, missä tietokone sijaitsee, hän voi ottaa yhteyttä pieneen AMT:n sisäiseen web-serveriin, ja avata täydet oikeudet antavan etäyhteyden. Tämän myötä hyökkääjä omistaa koneen käytännössä täysin, loogisella tasolla: hyökkääjä voi asentaa ja poistaa ohjelmia, päättää mitä koodia ajetaan ennen koneen käyttöjärjestelmän käynnistymistä; jne. Hyökkääjä voi myös asentaa esimerkiksi uusia etähallintatyökaluja (takaovia, rootkittejä).

Pieni virhe firmware-koodissa: suuri vaikutus

AMT-ongelman ydin on kooditasolla yhdessä merkkijonon sisältöä vertaavassa
komennossa. Merkkijonoa verrataan C-kielen ‘strncmp’ funktiota vastaavalla rakenteella. Koodi ottaa 3 parametria: kaksi merkkijonoa, ja kokonaisluvun. Ohjelmoija on valinnut väärin kolmannen parametrin, jolloin verrattavien merkkien määrä otetaankin yritteen pituudesta, ei oikean asetetun salasanan pituudesta.

Kyseinen kohta koodissa vertaa sisäänkirjautuvan käyttäjän antamaa salasanaehdotetta oikeaan, tunnettuun salasanaan. Kokonaisluvun tehtävänä on rajoittaa vertailun pituutta: toisinsanoen jos esimerkiksi N=2, verrataan vain 2 ensimmäistä merkkiä, riippumatta olisiko oikea salasana pidempi.

Tällä on kahdenlaisia vaikutuksia:

  • vakavampi vaikutus on, että myös tyhjä salasanayrite päästää sisään
  • sivuvaikutuksena saatta olla, että oikean asetetun salasanan vahvuus heikkenee sanakirjahyökkäys-tyyppisissä skenarioissa

Mikäli hyökkääjä on havainnut, että kohdejärjestelmässä on AMT-haavoittuvuus, hän voi suoraan käyttää helpointa mahdollista hyökkäysmenetelmää, eli tyhjää salasanaa.

Mikäli hyökkääjä turvautuu sanakirjahyökkäyksiin, ja hyökkääjä ei tiedä AMT-haavoittuvuuden mahdollistamassa helposta tyhjästä salasanasta, silloin hyökkäykseen käytetty aika voi alentua jos hyökkääjän arvausalgoritmi suosii tai sisältää myös lyhyitä yritteitä. Esimerkiksi oikean salasanan ollessa monimutkainen ‘tj5_a#tksPqasc’, niin yrite ‘t’, ‘tj’, ‘tj5’, kaikki menisivät läpi. Tällöin arvausaika voi olla hyvin pieni, eli monimutkaisenkin salasanan voima heikkenee merkittävästi AMT:n myötä. Rainbow-algoritmeja kannattaisi toisin sanoen muokata siten, että ne käyvät ensin läpi tällaiset helpot hedelmät. Voi olla, että niin ne jo tekevätkin?