Muistatko Heartbleedin? Jos uskot tämän päivän hypeä, Shellshock on samaa luokkaa ja yhtä mahtavalla nimellä, vaikkakin vailla siistiä logoa (jonkun näiden haavoittuvuuksien markkinointiosastolla on päästävä asiaan). Vakavasti puhuen sillä on kuitenkin potentiaalia olla iso juttu, ja kuten tein Heartbleedin kohdalla, halusin koota jotain lopullista sekä itselleni, jotta pääsisin käsiksi tilanteeseen, että muille, jotta he voisivat erottaa hypetyksen todellisesta taustalla olevasta riskistä.
Tilanteen luomiseksi jaan hieman sisältöä Robert Grahamin blogikirjoituksesta, jossa hän on analysoinut tätä asiaa erinomaisesti. Kuvittele tällainen HTTP-pyyntö:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Joka, kun se lähetetään useisiin haavoittuviin IP-osoitteisiin, johtaa seuraavaan tulokseen:
Lyhyesti sanottuna Robert on juuri järjestänyt joukon ulkoisia koneita pingaamaan häntä yksinkertaisesti lähettämällä huolellisesti laaditun pyynnön verkon kautta. Todella huolestuttavaa on se, että hän on käytännössä saanut nämä koneet lähettämään mielivaltaisen komennon (vaikkakin melko hyvänlaatuisen ping-komennon), ja tämä avaa koko maailman erittäin vakavia mahdollisuuksia. Minäpä selitän.
Mikä on Bash ja miksi tarvitsemme sitä?
Jätä tämä väliin, jos se on vanha uutinen, mutta konteksti on tärkeä niille, jotka eivät tunne Bashia, joten luodaan perusymmärrys. Bash on *nix shell eli toisin sanoen tulkki, jonka avulla voit orkestroida komentoja Unix- ja Linux-järjestelmissä, tyypillisesti muodostamalla yhteyden SSH:n tai Telnetin kautta. Se voi toimia myös verkkopalvelimen CGI-skriptien jäsentäjänä, kuten Apachessa tyypillisesti. Se on ollut käytössä 80-luvun loppupuolelta lähtien, jolloin se kehittyi aikaisemmista komentotulkkitoteutuksista (nimi on peräisin Bourne-komentotulkista), ja se on erittäin suosittu. Unix-versioille on olemassa muitakin komentotulkkeja, mutta Bash on kuitenkin oletuskomentotulkki Linuxissa ja Mac OS X:ssä, jotka ovat ilmeisesti erittäin yleisiä käyttöjärjestelmiä. Tämä on merkittävä tekijä siinä, miksi tämä riski on niin merkittävä – Bashin yleisyys – ja sitä kuvaillaan ”yhdeksi eniten asennetuista apuohjelmista kaikissa Linux-järjestelmissä”.
Voit saada käsityksen Bashin jalanjäljestä, kun katsot viimeisimpiä Netcraftin verkkopalvelintilastoja:
Kun puolet verkosta käyttää Apachea (joka tyypillisesti löytyy Linuxista), se on merkittävä osa hyvin, hyvin suuresta kakusta. Samassa Netcraftin artikkelissa kerrotaan, että olemme juuri ylittäneet miljardin verkkosivuston rajan, ja vaikka monet niistä käyttävät samoja isäntiä, se on silti suuri määrä Bash-asennuksia. Ai niin – tämäkin on vain web-palvelimia, älä unohda, että on olemassa kasa muita Linuxia käyttäviä palvelimia, ja palaamme hieman myöhemmin myös muihin laitteisiin, joissa Bash on käytössä.
Bashia voidaan käyttää monenlaisiin tyypillisiin hallinnollisiin toimintoihin, kaikkeen verkkosivujen konfiguroinnista aina laitteen upotetun ohjelmiston, kuten web-kameran, ohjaamiseen. Luonnollisesti näitä toimintoja ei ole tarkoitettu kaikille avoimiksi, ja teoriassa kyse on todennetuista käyttäjistä, jotka suorittavat komentoja, joiden suorittamiseen heillä on lupa. Teoriassa.
Mikä on vika?
Aloitan CVE:llä NIST-haavoittuvuustietokannasta, koska se antaa hyvän käsityksen vakavuudesta (korostus minun):
GNU Bash through 4.3 käsittelee funktiomäärittelyjen jälkeisiä merkkijonoja ympäristömuuttujien arvoissa, mikä mahdollistaa etähyökkääjille mielivaltaisen koodin suorittamisen muokatun ympäristön kautta, kuten on osoitettu vektoreissa, jotka liittyvät OpenSSH sshd:n ForceCommand-ominaisuuteen, Apache HTTP-palvelimen mod_cgi- ja mod_cgid-moduuleihin, määrittelemättömien DHCP-asiakkaiden suorittamiin skripteihin ja muihin tilanteisiin, joissa ympäristön asettaminen tapahtuu Bashin suorittamiseen nähden etuoikeusrajan yli.
He jatkavat arvioimalla sen vakavuuden ”10:ksi 10:stä” eli toisin sanoen niin pahaksi kuin mahdollista. Tätä pahentaa se, että hyökkäys on helppo toteuttaa (pääsyn monimutkaisuus on vähäinen) ja ehkä merkittävintä on se, että Bashia hyödynnettäessä CGI-skriptien kautta ei tarvita todennusta. Yllä oleva yhteenveto on kuitenkin hieman monimutkainen, joten kiteytetään se bugin mekaniikkaan.
Riski keskittyy kykyyn määritellä mielivaltaisesti ympäristömuuttujia Bash-kuoressa, jotka määrittelevät funktion määritelmän. Ongelmat alkavat, kun Bash jatkaa komentotulkkikomentojen käsittelyä funktiomäärittelyn jälkeen, mikä johtaa siihen, mitä me luokittelisimme ”koodin injektiohyökkäykseksi”. Katsotaanpa Robertin esimerkkiä uudelleen ja otetaan vain tämä rivi:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Funktion määritelmä on () { :; }; ja komentotulkin komento on ping-lauseke ja sen jälkeiset parametrit. Kun tätä käsitellään Bash-komentotulkin yhteydessä, mielivaltainen komento suoritetaan. Verkkokontekstissa tämä tarkoittaisi CGI-skriptin kaltaisen mekanismin kautta, eikä välttämättä myöskään pyyntöotsikkona. Kannattaa tutustua seclists.orgin neuvontaan, jossa kerrotaan yksityiskohtaisemmin muun muassa, että polku ja kyselymerkkijono voivat olla mahdollisia hyökkäyksen vektoreita.
Yksi keino lieventää tätä hyökkäysvektoria on tietysti yksinkertaisesti poistaa käytöstä kaikki CGI-toiminnot, jotka kutsuvat komentotulkkia, ja jotkut suosittelevatkin tätä. Monissa tapauksissa tämä tulee kuitenkin olemaan vakavasti rikkova muutos, ja vähintäänkin sellainen, joka vaatii laajaa testausta sen varmistamiseksi, ettei se aiheuta välittömiä ongelmia verkkosivustolla, mitä se monissa tapauksissa tekee.
Yllä oleva HTTP-todistus on yksinkertainen mutta tehokas, vaikkakin vain yksi toteutus yleisen protokollan kautta. Kun heität mukaan Telnetin ja SSH:n ja ilmeisesti jopa DHCP:n, laajuus kasvaa dramaattisesti, joten tässä ei missään nimessä puhuta vain web-sovelluspalvelimien hyväksikäytöstä. (Ilmeisesti riski on olemassa vain SSH:n post-authissa, mutta näin varhaisessa vaiheessa julkisuutta tulemme väistämättä näkemään vielä muita hyökkäysvektoreita.)
On myös muistettava, että potentiaalisen vahingon laajuus ulottuu paljon pidemmälle kuin mielivaltaisen osoitteen pingaaminen, kuten Robertin esimerkissä, joka on vain siisti pieni todiste siitä, että hän voi orkestroida koneen antamaan shell-komennon. Kysymys kuuluu seuraavasti:
Mitkä ovat mahdolliset seuraukset?
Mahdollisuudet ovat valtavat – komentotulkin saaminen laatikolle on aina ollut suuri voitto hyökkääjälle, koska se tarjoaa hyökkääjälle mahdollisuuden hallita kohdeympäristöä. Pääsy sisäisiin tietoihin, ympäristön uudelleenkonfigurointi, oman haitallisen koodin julkaiseminen jne. Se on lähes rajaton ja helposti automatisoitavissa. Jo nyt on olemassa monia, monia esimerkkejä hyväksikäyttökohteista, jotka voitaisiin helposti laukaista suurta määrää koneita vastaan.
Potentiaalit ovat valitettavasti melko laajat, kun kyse on mielivaltaisen koodin suorittamisesta komentotulkilla jopa puolessa internetin verkkosivustoista. Yksi ilmeisistä (ja erityisen ilkeistä) on sisäisten tiedostojen dumppaaminen julkisesti haettavaksi. Salasanatiedostot ja konfigurointitiedostot, joissa on tunnistetiedot, ovat ilmeisimpiä, mutta ne voitaisiin ajateltavissa olevan laajentaa mihin tahansa muihin järjestelmässä oleviin tiedostoihin.
Samoin samaa lähestymistapaa voitaisiin soveltaa tiedostojen kirjoittamiseen järjestelmään. Tämä on mahdollisesti helpoin koskaan näkemämme verkkosivustojen turmelemisvektori, puhumattakaan erittäin helposta tavasta levittää haittaohjelmia
Vai entäpä tämä: yksi sana, jonka näen jatkuvasti paljon, on ”mato”:
Kun puhumme madosta haittaohjelmakontekstissa, puhumme itseään monistavasta hyökkäyksestä, jossa haitallinen toimija luo koodia, joka kykenee levittäytymään kohteisiin. Näimme esimerkiksi erittäin tehokkaan toteutuksen tästä Samy’s MySpace XSS Wormissa, jossa huolellisesti laadittu JavaScript onnistui ”tartuttamaan” miljoonan uhrin sivut alle päivässä.
Huolta Shellshockin kohdalla aiheuttaa se, että tämänkaltainen hyökkäys voi monistua hälyttävällä vauhdilla, erityisesti alkuvaiheessa, kun suurin osa koneista on vielä vaarassa. Teoriassa tämä voisi tapahtua siten, että saastunut kone etsii muita kohteita ja levittää hyökkäystä niihin. Tämä ei suinkaan rajoittuisi vain julkisiin koneisiin; jos tämä saadaan yrityksen palomuurin taakse, taivas on rajana.
Tämän hyödyntämiseksi työskennellään parhaillaan. Tämä tekee näistä ensimmäisistä päivistä niin mielenkiintoisia, kun kilpavarustelu niiden välillä, jotka pyrkivät korjaamaan ja niiden välillä, jotka pyrkivät hyökkäämään, kiihtyy.
Mihin Bash-versioihin tämä vaikuttaa?
Otsikoissa sanotaan, että kaikkeen 4.3:een asti eli toisin sanoen noin 25 vuoden Bash-versioihin. Kun otetaan huomioon, että kaikki vertaavat tätä Heartbleediin, kannattaa ottaa huomioon, että OpenSSL:n vaikuttavat versiot kattoivat vain kaksi vuotta, mikä on pisara meressä verrattuna Shellshockiin. Kyllä, ihmiset päivittävät versioita, mutta he eivät tee sitä johdonmukaisesti, ja olipa asia miten tahansa, Shellshockin kohdalla riskialttiiden koneiden laajuus on huomattavasti suurempi kuin Heartbleedin kohdalla.
Riski voi kuitenkin ulottua myös 4.3:n ulkopuolelle. Jo nyt näemme raportteja siitä, että korjaukset eivät ole täysin tehokkaita, ja kun otetaan huomioon nopeus, jolla niitä levitetään, se ei ole kovin yllättävää. Tämä on sellainen asia, jota sen vaikutuspiirissä olevat haluavat pitää hyvin tarkkaan silmällä, eikä vain ”paikata ja unohtaa”.
Milloin kuulimme siitä ensimmäisen kerran ja kuinka kauan olemme olleet vaarassa?
Ensimmäinen maininta, jonka löysin julkisuudesta, oli tämä hyvin lyhyt yhteenveto seclists.org-sivustolla, joka ilmestyi keskiviikkona noin kello 14:00 GMT (noin keskiyöllä tänä aamuna Australian itäisessä päässä asuville meistä). Yksityiskohtaiset tiedot tulivat aiemmin mainitsemassani tiedotteessa tuntia myöhemmin, joten keskiviikkona keskipäivän iltapäivällä Euroopassa tai aamulla Yhdysvalloissa. Se on vielä hyvin tuore uutinen, jossa on kaikki tavanomaiset lehdistöspekulaatiot ja Chicken Little -ennustukset; on liian aikaista havaita laajamittaista hyväksikäyttöä luonnossa, mutta sekin voi tapahtua hyvin pian, jos riski elää potentiaalinsa mukaisesti.
Kierrä taaksepäin sen jälkeen, mitä on julkistettu julkisesti, ja bugin löysi ilmeisesti viime viikolla Isossa-Britanniassa työskentelevä ”Unix/Linux-, verkko- ja telekommunikaatio-asiantuntija”, Stéphane Chazelas. Tästä huolimatta Akamain viestissä bugista puhutaan, että se on ollut olemassa ”pitkän aikaa” ja tietysti haavoittuvia Bash-versioita on ollut jo kaksi ja puoli vuosikymmentä. Kysymys, kuten Heartbleedin kohdalla, on se, olivatko pahantahtoiset toimijat tietoisia tästä jo aiemmin ja käyttivätkö he sitä aktiivisesti hyväkseen.
Vaikuttaako tämä meidän ”tavaroihimme”?
Tässä kohtaa asia muuttuu mielenkiintoiseksi – meillä on paljon ”tavaroita”, jotka mahdollisesti käyttävät Bashia. Kun käytän tätä termiä, viittaan tietysti ”esineiden internetiin” (Internet of Things, IoT), joka tarkoittaa sitä, että IP-osoite ja langaton sovitin lisätään yhä useammin kaikkeen ruokailuvälineistämme ovilukkoihin ja valopalloihin.
Monissa IoT-laitteissa käytetään sulautettuja Linux-jakeluja, joissa on Bash. Näillä samoilla laitteilla on jo osoitettu olevan vakavia tietoturva-aukkoja muilla alueilla, esimerkiksi LIFX-valopallojen havaittiin vain pari kuukautta sitten vuotavan wlan-tunnuksia. Vaikka kyseessä ei ole Shellshockin kaltainen Bash-haavoittuvuus, se osoittaa meille, että liittämällä laitteemme toisiinsa astumme täysin uuteen haavoittuvuuksien maailmaan paikoissa, jotka eivät ole koskaan aiemmin olleet vaarassa.
Muutos: Muutamat ihmiset ovat viitanneet Ash-ohjelmaa käyttävän BusyBoxin yleistymiseen mobiililaitteissa. Tätä käyttävillä laitteilla ei näytä olevan Shellshock-riskiä. Vaikeus kuluttajan kannalta on se, että hän ei tiedä, mitä hänen laitteissaan pyörii, ja tämä koskee myös perinteisempiä ”asioita” kuten reitittimiä. Tämän bugin pitkä historia tarkoittaa, että meillä on yli parin vuosikymmenen ajan laitteita, jotka ovat käyneet läpi erilaisia sulautettujen käyttöjärjestelmien eri kehitysvaiheita, ja meillä on nyt hyvin monipuolinen maisema koneita ja Shellshockeja, jotka kattavat pitkän ajanjakson.
Tämä tuo mukanaan monia uusia haasteita; kuka esimerkiksi ajattelee aktiivisesti, että heidän pitäisi säännöllisesti paikata hehkulamppujaan? Mieti myös niiden laitteiden pitkäikäisyyttä, joissa nämä ohjelmistot esiintyvät, ja sitä, ylläpidetäänkö niitä todella aktiivisesti. Parin vuoden takaisissa haavoittuvissa Trendnetin kameroissa niitä on epäilemättä vielä valtava määrä verkossa, koska korjaamisen kannalta ne ovat aika lailla ”aseta ja unohda” -ehdotus. Itse asiassa tuossa tapauksessa on olemassa kokonainen Twitter-tili, joka on omistettu lähettämään kuvia, joita se on ottanut haavoittuvien versioiden pahaa-aavistamattomista omistajista. Kyseessä on suuri ongelma, johon ei ole helppoja ratkaisuja, ja se tulee pysymään kanssamme hyvin pitkään.
Mutta Bash-kuoriaisia on myös monissa tavallisemmissa laitteissa, esimerkiksi kotireitittimissämme, jotka ovat yleensä yhteydessä internetiin. Muistatko, milloin viimeksi korjasit reitittimesi firmwarea? Okei, jos luet tätä, niin ehkä olet sellainen tekninen henkilö, joka todella korjaa reitittimensä, mutta asetu keskivertokuluttajan asemaan ja kysy itseltäsi uudestaan. Aivan.
Kaikki laitteemme käyttävät Microsoftin pinoa, olemmeko vaarassa?
Lyhyt vastaus ”ei”, pitkä vastaus ”kyllä”. Tartun ensimmäiseksi helppoon – Bashia ei löydy natiivisti Windowsista ja vaikka Bash-toteutuksia Windowsille on olemassa, se ei todellakaan ole yleinen eikä sitä löydy kuluttajien PC:stä. Ei ole myöskään selvää, ovatko win-bashin kaltaiset tuotteet ylipäätään alttiita Shellshockille.
Pidempi vastaus on, että vaikka toimitaankin pääasiassa Microsoft-keskeisessä ympäristössä, se ei tarkoita, etteikö Bash olisi käynnissä koneilla, jotka palvelevat muita erillisiä tarkoituksia tässä ympäristössä. Kun kirjoitin Heartbleedistä, viittasin Nick Craverin postaukseen Stack Overflow’n siirtymisestä kohti SSL:ää ja viittasin tähän kaavioon heidän infrastruktuuristaan:
Microsoftin sovelluspinon edessä istuu muita kuin Microsoft-komponentteja, komponentteja, joiden läpi liikenteen on kuljettava, ennen kuin se saapuu web-palvelimille. Nämä ovat myös komponentteja, joilla voi olla korotettuja oikeuksia palomuurin takana – mikä on vaikutus, jos Shellshockia hyödynnetään niissä? Se voi olla merkittävää, ja tätä tarkoitan tässä: Shellshockilla on potentiaalia vaikuttaa muuhunkin omaisuuteen kuin vain riskialttiisiin Bash-toteutuksiin, kun se on olemassa laajemmassa ekosysteemissä, jossa on muitakin koneita.
Olen järjestelmän ylläpitäjä – mitä voin tehdä?
Ensiksikin riskin havaitseminen on vähäpätöinen tehtävä, koska se on niin helposti toistettavissa oleva riski. The Register ehdottaa hyvin yksinkertaista testiä, joka on vain tämän komennon suorittaminen komentotulkissasi:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Saat ”busted” echo’d takaisin ulos ja olet onnistuneesti hyödyntänyt bugia.
Tietenkin etusijalla on riskialttiiden järjestelmien paikkaaminen, ja paikkaus tarkoittaa lähinnä sitä, että mitään koodia ei voi suorittaa Bash-funktion lopun jälkeen. Linux-jakelijat, kuten Red Hat, julkaisevat ohjeita riskien paikkaamiseen, joten tartu niihin ensisijaisesti.
Väistämättä tulemme näkemään määritelmiä myös tunkeutumisen havaitsemisjärjestelmille, ja varmasti on olemassa yhteisiä malleja, joita kannattaa etsiä. Tämä voi hyvinkin osoittautua monien organisaatioiden kannalta hyväksi lähitulevaisuuden toteutustavaksi, erityisesti silloin, kun voi olla raskaita testausvaatimuksia ennen korjausten käyttöönottoa riskialttiissa järjestelmissä. Qualysin tavoitteena on saada määritelmä, joka havaitsee hyökkäyksen melko nopeasti, ja väistämättä myös muut IDS-palveluntarjoajat työskentelevät tämän parissa vuorokauden ympäri.
Muita jyrkempiä vaihtoehtoja ovat muun muassa Bashin korvaaminen vaihtoehtoisella komentosarjatoteutuksella tai riskialttiiden järjestelmien eristäminen, millä molemmilla voi olla kauaskantoisia seurauksia, ja ne tuskin ovat päätöksiä, joita tehdään kevyesti. Mutta se tulee luultavasti olemaan tämän bugin luonne monille ihmisille – vaikeita päätöksiä, joilla voi olla konkreettisia liiketoimintavaikutuksia, jotta vältettäisiin mahdollisesti paljon merkittävämmät seuraukset.
Toinen kysymys, joka tulee nyt usein esiin, on kysymys siitä, onko Shellshockia jo hyödynnetty jossakin ympäristössä. Tätä voi olla vaikea määrittää, jos hyökkäysvektoreista ei ole lokitietoja (usein niitä ei ole, jos ne siirretään HTTP-pyynnön otsikon tai POST-rungon kautta), mutta on todennäköisempää, että ne saadaan kiinni kuin Heartbleedin tapauksessa, kun täydellistä pcapsia lukuun ottamatta heartbeat-hyötykuormia ei normaalisti olisi kirjattu mihinkään. Mutta silti, yleisin vastaus kysymykseen ”hyökättiinkö meihin Shellshockin kautta” tulee olemaan tämä:
valitettavasti tämä ei ole ”Ei, meillä on todisteita siitä, että kompromisseja ei ollut”; pikemminkin ”meillä ei ole todisteita, jotka kattavat tämän haavoittuvuuden elinkaaren”. Epäilemme, että monilla ei ole – ja tämä jättää järjestelmien omistajat epämiellyttävään tilanteeseen, jossa he eivät tiedä, mitä kompromisseja on voinut tapahtua, jos niitä on tapahtunut.
Aloitetaan spekulointi siitä, oliko NSA mukana tässä…
Olen kuluttaja – mitä voin tehdä?
Se riippuu. Shellshock vaikuttaa Mac-tietokoneisiin, joten jos käytät OS X:ää, tässä vaiheessa näyttää siltä, että se on vaarassa, mikä on toisaalta huono asia OS X:n yleisyyden vuoksi, mutta toisaalta se on helposti (ja toivottavasti nopeasti) korjattavissa melko hyvin hyväksi todetun päivitysmekanismin vuoksi (eli Apple voi työntää päivityksiä koneelle etänä).
Jos käytät Macia, riski on helppo testata, kuten tässä Stack Exchange -vastauksessa on kuvattu:
Testi on helppo, vaikkakin epäilen, että keskiverto Mac-käyttäjä tuskin uskaltaa astua läpi ehdotetun korjauksen, joka edellyttää Bashin uudelleenkompilointia.
Suurempi huolenaihe ovat laitteet, joissa ei ole helppoa korjauspolkua, kuten esimerkiksi reititin. Loppujen lopuksi tämä tulee olemaan todella vaikea pähkinä murtaa, jos ei tarkista valmistajan verkkosivuilta päivitettyä firmwarea. Usein Internet-palveluntarjoajien tarjoamat reitittimet on lukittu, jotta kuluttajat eivät voi muuttaa satunnaisesti konfiguraatiota tai laiteohjelmistoa, eikä aina ole etäpäivityspolkua, jonka he voivat käynnistää. Kun tähän yhdistetään vielä valtava määrä erilaisia laitteita ja ikäryhmiä, tämä voi olla erityisen hankalaa. Keskivertokuluttaja ei tietenkään myöskään mielellään tee sitä itse.
Lyhyesti sanottuna neuvo kuluttajille on tämä: seuratkaa tietoturvapäivityksiä, erityisesti OS X:n osalta. Pitäkää myös silmällä kaikkia neuvoja, joita saatte Internet-palveluntarjoajaltanne tai muilta sulautettuja ohjelmistoja käyttävien laitteidenne toimittajilta. Ole varovainen sähköpostiviesteissä, joissa pyydetään tietoja tai kehotetaan käyttämään ohjelmistoja – tällaisia tapahtumia seuraa usein phishing-hyökkäyksiä, joissa hyödynnetään kuluttajien pelkoja. Tällä hetkellä huijaukset saavat ihmiset laittamaan iPhonensa mikroaaltouuniin, joten älä luule hetkeäkään, etteivät he ajaisi satunnaista ohjelmistoa, joka lähetetään heille sähköpostitse Shellshockin ”korjauksena”!
Yhteenveto
Emmekään ole vielä edes aloittaneet tämän haavoittuvuuden laajuuden hahmottamista. Heartbleediin tehdään tietenkin paljon vertailuja, ja siitä opimme monia asioita. Yksi niistä on se, että kesti jonkin aikaa tajuta, missä määrin olimme riippuvaisia OpenSSL:stä. Toinen on se, että se oli hyvin pitkäkestoinen – vielä kuukausia sen jälkeen, kun se iski, satojatuhansia tunnettuja isäntäkoneita oli edelleen haavoittuvaisia.
Mutta Heartbleed-vertailu ei ole oikeudenmukainen – tämä on potentiaalisesti paljon pahempi. Heartbleed mahdollisti etäkäytön pieneen tietomäärään asianomaisten koneiden muistissa. Shellshock mahdollistaa mielivaltaisten komentojen etäkoodin syötön ennen auktorisointia, mikä on potentiaalisesti paljon kauheampaa. Tässä suhteessa minun on oltava samaa mieltä Robertin kanssa:
Se on vielä hyvin, hyvin alkuvaiheessa – tätä kirjoittaessani on kulunut vasta puoli päivää siitä, kun se tuli ensimmäisen kerran ilmoille – ja epäilen, että toistaiseksi olemme vasta raapaisemassa pintaa siitä, mitä on vielä tulossa.
Security