Som väl är bekant släpper mjukvarutillverkare uppdateringar
(patchar) till sin programvara. Ibland är dessa uppgraderingar till
för att förbättra applikationens funktioner, men oftast för att
täppa igen säkerhetshål som har upptäckts. Dessa patchar är viktiga
att lägga på; till exempel skriver Riksrevisionen i en
utvärdering:
"Att kontinuerligt analysera och välja vad som bör installeras av
de patchar som tillhandahålls av leverantörerna är en viktig del i
att bibehålla säkerhetsnivån. Om denna del blir eftersatt så kommer
det på sikt att öka sårbarheten för kända attacker och
angreppssätt."
På senare tid har den kritiska tidsfaktorn mellan att
uppdateringen släpps och att sårbarheten den täpper till börjar
utnyttjas av hackare minskat. Detta beror på i huvudsak två saker:
den exakta orsaken till säkerhetshålen sprids (medvetet eller
omedvetet) av de som råkat upptäcka dem samt att de som är ute för
att skapa illvillig kod har blivit duktiga på så kallad ''''reverse
engineering''''.
''''Reverse engineering'''' eller bakåtkompilering, som man i
detta fall kan kalla det på svenska, innebär att den exekverbara
programkoden de-kompileras och blir läsbar assemblerkod (föklaring
av vad detta är finns sist i texten). Genom att jämföra den
kodversion som fanns innan det att uppdateringen installerades och
hur den ser ut efteråt går det att läsa ut exakt vilken typ av
felrättning som genomfördes i den aktuella patchen. Genom att hitta
denna exakta orsak går det relativt lätt att skriva ett program
(t.ex. ett virus eller trojan) som använder sig av detta hål.
När väl ett program som utnyttjar säkerhetshålet är skrivet är det
alltså bara en tidsfråga innan det börjar användas. Alla system som
inte hunnits bli uppdaterade ännu är då sårbara. Tidsfristen innan
en attack kan genomföras beror naturligtvis mycket på vilken typ av
sårbarhet som lagats i uppdateringen och motivationen hos de som
skapar koden. Enligt Sabre-Security hittade de den exakta
kodsekvensen som uppdaterades av en Micrsoftuppdatering på 20
minuter och skrev en skadlig kod som kunde användas mot oskyddade
systen på mindre än 10 timmar (källa: SecurityFocus.com,
2005-07-01).
Vad är det då den skadliga koden gör? Oftast handlar det
säkerhetshålet om buffertöverskrivningar, det vill säga att ett
program tar in ett argument vars storlek inte kontrolleras. Den
buffert som är skapad att ta hand om argumentet (ett tal, en sträng
eller någon annan typ av variabel) blir då full, samt att den
efterföljande koden i minnearean blir överskriden. Genom att skriva
över exekverbar kod med skräpdata av en viss längd kan man få
programmet att hoppa till att utföra helt andra intruktioner än de
avsedda. Detta kan helt enkelt krascha applikationen eller, ännu
värre, öppna för att installera trojaner.
Vad är då risken med att installera en patch så snart den är
tillgänglig? Det finns några saker som kan inträffa, varav jag
nämner två aktuella exempel här:
- Ytterligare fel i programvaran installeras, exempel på det är
vid installation av Windows Server 2003 SP1 slutar
MTU-uppdateringar till operativsystemet fungera (Microsoft KB
898060, maj 2005).
- Säkerhetsuppdateringarna rättar till felet, men på ett sådant
sätt att vissa program slutar fungera. Exempel på det är Windows XP
SP2 som hindrar anslutningar till loopbacksadresser som inte är
127.0.0.1 (Microsoft KB 884020, september 2004).
Att så snabbt som möjligt installera de säkerhetsuppdateringar som
släpps till operativsystem och program måste nog ändå anses som
viktigt. Men - och det är ett stort ''''''''men'''''''' - det är
några viktiga handgrepp som måste göras i samband med
uppdateringen:
- Läs igenom den dokumentation som följer med en uppdatering: Vad
gör patchen? Kan jag avinstallera den? Har andra installerat den
och fått problem?
- Om misstanke finns att en uppdatering kan störa ut andra
program, skapa då ett testsystem som är så likt det skarpa systemet
som möjligt och gör en testinstallation där först.
- Varje uppdatering måste bokföras i den dagbok som man som
drifttekniker ska ha. På detta sätt kan man snabbt se om ett visst
fel är spårbart till en viss uppdatering.
För att se vilka säkerhetspatchar som redan är installerade eller
som behöver installeras, finns det för de vanligaste
Microsoftprodukterna ett stödverktyg som heter Microsoft Base
Security Analyser (MBSA). För andra system, t.ex. Linux finns ofta
motsvarande uppdateringsapplikationer, så som YaST eller
Up2date.
De-kompilering eller bakåtkompilering:
- Den kod en programmerare skriver kallas för källkod och skrivs
oftast i ett så kallat hög-nivåspråk. Exempel på sådana är C, C++,
C#, Java med flera. Denna kod kan inte direkt exekveras av en
dator, utan kompileras först till asemblerkod som är ett mellansteg
mellan binärkod och källkoden. Assemblerkoden består av väldigt
enkla (atomära) instruktioner, till exempel: addera A med B,
placera resultatet i register C. Denna assemblerkod är oftast
optimerad av kompilatorerna för att passa den hårdvaruarkitektur
som programmet ska köra på (Intel, Mac eller Sun Sparc).
Assemblerkoden är i viss mån läsbar och det går att följa stegvis
hur ett program exekveras. Denna assemblerkod kompileras sedan till
ren binärkod som är körbar på en specifiv hårdvara.
Att de-kompilera innebär att man återskapar assemblerkoden ur
binärkoden. Det är dock oftast inte möjligt att skapa källkoden ur
assemblerkoden. Se vidare http://www.debugmode.com/dcompile/ för
mer information.
© 2005 Carl Ljungqvist, Certezza AB
