DLL-kirjastoista ja niiden lataamisesta - jatkotarinan osa III: "Viimeinen niitti"

Jatkotarinan ensimmäisessä osassa esiteltiin ongelma, eli mistä tässä kaikessa on oikein kysymys. Toisessa osassa pureuduttiin hieman puolustukseen eli tapoihin, jolla ongelman aiheuttamaa riskiä voidaan pienentää. Tämä kolmas ja viimeinen osa käsittelee tapoja, joilla sovelluksia voi muuttaa niin, että ongelmaan ei ko. sovellusten osalta törmätä.

Kerrataanpa taasen, ongelman ydin oli siis siinä, että sovelluksessa ladattiin DLL-kirjasto, mutta latauskutsussa ei määritetty sen polkua. Voisiko siis sovellusta muuttaa niin, että LoadLibrary-latauskutsussa määritetään DLL-kirjaston tarkka polku? Olisiko siitä hyötyä? Ehdottomasti. Jos kutsussa määritetään tarkka polku, DLL-kirjastoa yritetään ladata ko. polusta. Jos sitä ei määritetystä polusta löydy, haku päättyy siihen. Luonnollisesti sovelluksen on tällaisessa tapauksessa osattava käsitellä DLL-kirjaston puuttuminen ja esim. lopetettava itse itsensä tyylikkäästi, tiedot tallentaen.

Aina kuitenkaan tarkan polun määrittäminen ei ole mahdollista. Tällöin on muita mahdollisuuksia, esimerkiksi SetDllDirectory-funktion kutsuminen tyhjällä merkkijonolla (""). Tämä määrittää DLL-kirjastojen haussa käytettävän "nykyisen työhakemiston" hakemistoksi "", jolloin se on eri kuin sovelluksen "nykyinen työhakemisto", eikä hyökkääjän haluamaa DLL-kirjastoa luonnollisestikaan sieltä löydy.

Sovelluskehittäjän on hyvä olla tietoinen myös muutamasta muusta jutusta, esimerkiksi siitä, että LoadLibrary-kutsua ei kannata käyttää Windowsin version selvittämiseen tai että DLL-kirjastoja ei kannata hakea SearchPath-kutsun avulla. Kaikesta tästä ja monesta muusta asiasta löytyypi lisätietoja Security Research and Defense -blogin artikkelista, jonka lopusta löytyy hyvä kehittäjille suunnattu yhteenveto DOCX-muotoisena tiedostona otsikolla "Secure loading of libraries to prevent DLL preloading attacks - Guidance for software developers".

Että semmoisia tästä aiheesta. Jos lukijoille tuleepi kysymyksiä tai kommentteja mieleen, sana on vapaa ja kommenttialue avoinna. Näin lopputeksteinä muutama linkki hyödylliseen lisätietoon:

- Englanninkielinen Security Advisory 2269637 - https://www.microsoft.com/technet/security/advisory/2269637.mspx
- MSRC:n blogi - https://blogs.technet.com/b/msrc/archive/2010/08/21/microsoft-security-advisory-2269637-released.aspx
- Security Research and Defense -blogi - https://blogs.technet.com/b/srd/archive/2010/08/23/more-information-about-dll-preloading-remote-attack-vector.aspx ja https://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx
- David LeBlancin blogi - https://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspx ja https://blogs.msdn.com/b/david_leblanc/archive/2010/08/23/another-technique-for-fixing-dll-preloading-attacks.aspx
- KB-artikkeli 2264107 - https://support.microsoft.com/kb/2264107/en