Eudora-sähköpostiohjelmistossa vakava haavoittuvuus

Kun pomo hengittää niskaa, projektin aikataulut kusevat ja koodin piti olla valmista jo kuukausia aikaisemmin, ei ole jostain syystä aikaa miettiä ja tehdä sellaisia asioita kuin virheentarkistus. Ikävää, mutta todellisuutta kun kaikki pitää tehdä entistä halvemmalla ja nopeammin, vaikka ohjelmien koko tuntuu kasvavan potenssissa.

Jos kiinnostusta riittää, niin tässä olisi yksi hyvä dokumentti aiheesta:

http://www.cs.fit.edu/~tr/cs-2002-12.pdf

Nykyään puskurien ylivuodot ovat tapetilla yksinkertaisesti siitä syystä, että ne ovat tietyllä tavalla yleisesti käytettyjen prosessori- ja käyttöjärjestelmäratkaisujen suhteen universaaleja, niitä on paljon ja ne mahdollistavat tiettyjen sellaisten jippojen suorittamisen, mitä ei monia muita tietoturva-aukkoja hyödyntämällä pääse suorittamaan. Ohjelmistoissa, joista "perinteisiä" puskuriylivuotoja on vaikea löytää, on "siirrytty" uusien ongelmien (kuten uusien kokonaislukuylivuotojen) etsimiseen niin ohjelmistojen kehittäjien kuin kräkkereidenkin keskuudessa.

Ylivuotoja ja niiden haittoja voidaan torjua olennaisesti kolmella tavalla: ohjelmointimetodiikalla, jossa vältetään ylivuotojen kirjoittamista; työkaluilla, jotka estävät ylivuotojen syntymisen; sekä työkaluilla, jotka rajoittavat ylivuodon vaikutusten eskaloitumista.

Ohjelmointimetodiikan osaltakin voidaan puhua sekä tietystä ymmärryksestä ja asenteesta (ohjelmoija ymmärtää, mikä on osoitin, mikä on muistialue ja mikä on muistivaraus sekä yrittää pitää nämä reunaehdot mielessään ohjelmoidessaan; pyritään siihen, että ohjelmoija suunnittelee ja toteuttaa ratkaisun huolellisesti nimenomaan laatua silmällä pitäen; pyritään siihen, että useampi ohjelmoija todella lukee koodin läpi ja pyrkii nimenomaan etsimään siitä virheitä tai varmistumaan sen oikeellisuudesta) että mekaanisemmista työkaluista (C:ssä esim. konventio käyttää OpenBSD:ssä kehitettyjä strl-funktioita: http://www.courtesan.com/todd/papers/strlcpy.html tai muuten kirjoittaa koodinsa tietyllä hyvänä pidetyllä tavalla). Tällä alueella useimmissa ohjelmointiympäristöissä on parantamisen varaa syistä, joita en lähde tässä erittelemään (ja ehkäpä en jopa niitä täysin osaisikaan eritellä :-): käytännössä ohjelmoija usein miettii vain hänen kannaltaan mukavimman tavan ratkaista jokin ongelma ja pitää sitä valmiina heti, kun se näyttää toimivan jossain esimerkkitapauksessa.

Työkaluiksi, joilla pyritään estämään ylivuotojen syntyminen, voidaan lukea kaikenlaisia: "mekaaninen" blackbox-testaus (jonka kritiikkiä esitetään mm. "Writing Solid Code"-klassikossa) ja koodia analysoivat työkalut; ehkä ohjelmointikieletkin, joissa pointterit eivät näy käyttäjille. Näillä ratkaisuilla on omat heikot puolensa; yhteisinä heikkouksina voidaan pitää mm. (ensinnäkin) sitä, että ne ovat mekaanisen ja "pinnoitusmaisen" luonteensa vuoksi epätäydellisiä, mutta että ne (toisekseen ja tästä johtuen) luovat silti usein väärää turvallisuudentunnetta. Jos ohjelmoija alkaa luottaa tällaisiin työkaluihin jonkinlaisena laadun takeena, hän luultavasti keskittyy entistäkin vähemmän huolelliseen suunnittelu- ja toteutustyöhön laadun näkökulmasta. Blackbox-testauksessa ei voida käytännössä käydä läpi kaikkia mahdollisia käyttötilanteita; koodia analysoivat työkalut eivät käytännössä koskaan ole täydellisiä (käytännössä lähes kaikissa kääntäjissäkin on varoituksia, jotka on mahdollista kytkeä päälle, mutta jotka silti mahdollistavat ohjelmointivirheet, kts. esim. http://sektori.com/uutiset/5130/linux-ytimeen#k567... ); kaikki kielet itse käyttävät jollain tapaa pointtereita, ja niiden virtuaalikonetoteutuksista löytyy bugeja (jotka voivat siten olla paljon fataalimpia kuin yksittäiset bugit yksittäisissä ohjelmissa), ja lisäksi niillä toteutetuissa ohjelmissa voi olla bugeja, jotka faktisesti vastaavat "buffer overflow":ta mutta käytännössä vain näkyvät vähän eri tavalla ja aiheuttavat erilaisia ongelmia. (Javassa esim. NullPointerException ja ArrayOutOfBoundsException; vastaavia ongelmia silloin, kun tällaisiakaan ei synny, on se, että esim. jokin merkkijono vain "näkymättömästi" lyhenee ilman, että siitä käyttäjälle ilmoitetaan.)

Viimeisenä listassa pitäisin niitä retroaktiivisia työkaluja, joilla pyritään estämään overflow'n vaikutusten eskaloituminen. Tällaisia ovat esim. kääntäjän tarkistukset (jotka voidaan kiertää; kts. esim. http://www.phrack.org/show.php?p=56&a=5 ) sekä muistinhallinnan tarkastukset (jotka voidaan kiertää; kts. esim. http://secinf.net/info/unix/stack.txt ; ftp://ftp.netsys.com/pub/archives/linux_lpr.c ; http://www.nextgenss.com/papers/defeating-w2k3-sta... ). Kaikki nämä ratkaisut ovat ensinnäkin ainakin yksin ja itsessään riittämättömiä ja ne voidaan kiertää, ja ne voivat aiheuttaa samanlaista väärää turvallisuudentunnetta kuin ylempänä tarkistustyökalut. Toisekseen ne vain ehkäisevät buffer overflow'n avulla suoritettavan injektiohyökkäyksen: ne eivät korjaa bugeja (vaikka jotkut ratkaisut voivat auttaa niiden löytämisessä, koska ne virhetilanteissa kohdistavat huomion oikeaan bugiin), ne eivät ehkäise muunlaisia hyökkäyksiä (esim. DoS hyökkäys palvelimeen, joka segfaulttaa tietyssä tilanteessa), eivätkä ne ehkäise muita ongelmatiloja kuin hyökkäyksiä.

Toisin sanoen sekä toinen että kolmas kategoria ovat selkeästi retroaktiivisia toimintamalleja: ne pyrkivät minimoimaan vahinkoa, eivät estämään sitä. Ohjelmissa on niistä huolimatta muita turva-aukkoja ja ohjelmien laatu on niistä huolimatta yhä heikkoa. Yleisesti ottaen voidaan sanoa, että mikä tahansa "tietoturva-aukko" on bugi myös siinä mielessä, että se voi aiheuttaa vahinkoa silloinkin, kun sitä ei aktiivisesti yritetä hyödyntää, vaikka usein pienemmässä mittakaavassa (mutta ei välttämättä vähemmän tuhoisin seurauksin, jos se yksi vahinko sattuu kriittisessä tilanteessa). Käänteisesti keskittyminen laatuun ja oikeellisuuteen (tai "virheettömyyteen") vähentää automaattisesti myös tietoturva-aukkoja.

Kaiken kaikkiaan kuvattuja metodeja kannattaa yleensä kaikkia käyttää, jos se on mahdollista. Yksi tapa ei joko ihmisen tai koneen heikkoudesta johtuen vielä poista kaikkia ongelmia, mutta yhdessä nämä tavat vaikeuttavat todella merkittävissä määrin tietoturvanäkökulmasta hyökkääjän mahdollisuuksia saada aikaan vahinkoa tai oikeudetonta hyötyä. Jos ohjelmakoodiin on alun perin kirjoitettu 10 bugia per 1000 riviä vs. 100 per 1000 riviä, jos tarkistustyökalut löytävät näistä 9 ennen kuin bugit päätyvät ajoon versus 0 löydettyä bugia ("if it compilers, it's perfect!"), ja jos erilaiset mekaaniset työkalut saavat aikaan sen, että hyökkääjän pitäisi saada kierrettyä kääntäjän manipulointi ja stackin suojaus vs. yksinkertainen shellcode-injektio, ja ihmetellä chrootissa uidina 65534 ilman shelliä tai kääntäjää vs. uidina 0 /-nodessa, uskallettaneen arvioida, että järjestelmän tietoturvaa on kohennettu huomattavasti.

Voi koodata, eikä ole mikään amerikantemppukaan. Mutta kun projektit paisuvat ja koodia on kymmeniä tuhansia rivejä, on ymmärrettävää, että jossain tapahtuu joku virhe. On olemassa myös erilaisia kirjastoja, joita käyttämällä moisista ongelmista päästään eroon. Lisäksi ainakin OpenBSD käyttöjärjestelmässä on ns. non-executable stack, joka estää vihamielisen koodin suorituksen, kun stackissa olevat puskurit vuotavat yli (paljon ohjelmointitermejä, joilla hämään lukijaa).

Itse C:tä koodanneena ymmärrän, että puskurin ylivuotovirhe on helppo tehdä, mutta pienellä harjoittelulla sitä osaa välttää. Jotkut kielet taas mahdollistavat kaikenmaailman toimintoja, joiden pitäisi automaattisesti korjata tällaisia. Kuulemma ovat toimiviakin, mutta silti näitä ongelmia vain esiintyy...

Lisäksi on myös olemassa ohjelmia, jotka tarkastavat koodin ja varoittavat mahdollisista ylivuodoista sekä muista mahdollisista bugeista. Voisikin Eudoran kehittäjätiimille suositella jotain tällaista :)

Reply-to -kenttä ei näy kaikissa e-mail -clienteissa. Ei voida olettaa, että ennen reply to all -napin painamista kävisi aina tutkailemassa e-mailin headereita, jotka on ainakin MS:n tuotteissa piilotettu hyvin käyttäjältä.