Adobe lapper kritisk hul i Reader-programmet

Et udbredt sikkerhedshul i Adobe Reader lukkes med den seneste opdatering til produktet.

Et sikkerhedshul i et af verdens mest udbredte læseprogrammer til dokumenter på nettet står foran lukning. Det drejer sig om produktet Adobe Reader, der gennem længere tid har indeholdt et sikkerhedshul, der kunne udnyttes af hackere til at overtage kontrollen med brugerens maskine.

Hullet bliver ifølge it-sikkerhedsfirmaet CSIS lukket med den seneste opdatering til Adobe Reader, der har versionsnummer 8.1.2.

CSIS har kendskab til mindst et udnyttelsesprogram af sikkerhedshullet ? et såkaldt exploit, der er i omløb i hackerkredse og opfordrer it-ansvarlige og almindelige brugere til straks at opdatere deres Adobe Reader.

Sikkerhedshullet i Adobe Reader er ifølge CSIS et såkaldt stack overflow, som kan udløses med en særligt designet PDF-fil, som ved åbning udløser en korruption af hukommelsen og muliggør kørsel af vilkårlig kode med samme rettigheder som den aktuelle bruger.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

At programmer kører videre efter overløb af buffere, stakke eller lignende er tegn på dårligt design. Hvis programmørerne ikke selv kan finde ud af det, så brug en compiler, der selv indsætter de nødvendige køretidstests. Eller brug et sprog, hvor der ikke er begrænsede datastrukturer.

Hvorfor skal vi blive ved med at finde os i sikkerhedshuller, der skyldes brug af forældede programmeringsværktøjer eller -sprog, når det er så nemt at undgå?

Ikke dermed sagt, at man automatisk undgår sikkerhedshuller ved at undgå overløb. Men overløb er en tilstrækkelig hyppig kilde til sikkerhedshuller til, at det er rimeligt at gøre en indsats på dette område.

  • 0
  • 0
#2 Deleted User

"Hvorfor skal vi blive ved med at finde os i sikkerhedshuller, der skyldes brug af forældede programmeringsværktøjer eller -sprog, når det er så nemt at undgå?"

Ja, så enkelt kan det gøres!

Derudover, skal operativsystemet også skrives i et ordentligt sprog, og laves med en ordentlig compiler. Operativsystemets sikkerhed, er alfa og omega. Egentligt, bør operativsystemet tage ansvaret for den kode der udføres, ved at programmer ikke har lov at udføre hardwarenær CPU kode, men i stedet compileres til en bit-kode, der ikke på nogen måder arver noget fra hardware. Det betyder, at operativsystemets CPU driver oversætter effektiv til enhver type CPU, eller operativsystemet endog har mulighed for at oversætte til flere CPU'er, der har driver indstalleret. Andre typer hardware, såsom printer, klares også ved at indstallere en driver til enheden. Kræver programmet hardware, der ikke findes på computeren, er muligt at tilslutte en computer til et netværk med denne hardware, og omdirigere det.

Skal alle programmer oversættes til en bitkode, der har samme sikkerhed og hardwareuafhængighed som højniveau sprog, så vil det besværliggøres at lave compilere, der ikke gør deres arbejde ordentligt. Bitkoden, kan oversættes effektivt til CPU'en, uanset fabrikat, og indstruktionssæt. Og den kan paralleliseres automatisk af operativsystemet, afhængig af hvor advanceret den er, således et sekventielt program automatisk kan gøres parallelt ved analyse af bitkoden. Er koden parallel skrevet, har operativsystemet tilsvarende mulighed for, at enten realisere det på éen processor, eller et givent antal CPU'er, afhængig af dens hardware. Og softwaren vil altid fungere ens.

Operativsystemet, vil først på det tidspunkt kunne gøre det, som den er tiltænkt: At kunne udføre et program sikkert, og hurtigt, og ens uanset hardwaren.

I dag, lever operativsystemer ikke op til denne deffination. De kan end ikke udføre programmet.

  • 0
  • 0
Log ind eller Opret konto for at kommentere