mboost-dp1
unknown
[ironi]
Fantastisk! Kan det virkelig lade sig gøre at lave en virus der targeter et 64bit OS? Det var da helt vildt!
[/ironi]
Hvad folk dog ikke gør for 15. minutes of fame.
Fantastisk! Kan det virkelig lade sig gøre at lave en virus der targeter et 64bit OS? Det var da helt vildt!
[/ironi]
Hvad folk dog ikke gør for 15. minutes of fame.
#4 Det mest overraskende er vel nok at folk troede at det der "NX" burde klare det.
Nej NX kan ikke beskytte dig mod virus. Den vil i nogen tilfælde kunne beskytte dig mod orme. Orme og virus har forskellige smitteveje. En orm smitter gennem fejl i software, f.eks. bufferoverløb, der udgør et sikkerhedshul. En virus smitter ved at folk selv kører kode fra usikre kilder.
Nej NX kan ikke beskytte dig mod virus. Den vil i nogen tilfælde kunne beskytte dig mod orme. Orme og virus har forskellige smitteveje. En orm smitter gennem fejl i software, f.eks. bufferoverløb, der udgør et sikkerhedshul. En virus smitter ved at folk selv kører kode fra usikre kilder.
"Wee, #1!"
Ja, måtte jo komme før eller senere...
Jeg kan heller ikke se den store nyhed i det, da 64 bit windows kan eksekvere langt de fleste 32-bit vira ligeså "godt" som Windows 32bit kan.
Dog har jeg personligt ikke haft held med mit anti-virus-program på Windows 64 bit (Athlon), da den ikke vil installere 32-bit-programmer som services. Det er vist kun McAfee som nogenlunde understøtter 64-bit arkitekturen, men da jeg ikke støtter dem, er der et problem, hehe.
Ja, måtte jo komme før eller senere...
Jeg kan heller ikke se den store nyhed i det, da 64 bit windows kan eksekvere langt de fleste 32-bit vira ligeså "godt" som Windows 32bit kan.
Dog har jeg personligt ikke haft held med mit anti-virus-program på Windows 64 bit (Athlon), da den ikke vil installere 32-bit-programmer som services. Det er vist kun McAfee som nogenlunde understøtter 64-bit arkitekturen, men da jeg ikke støtter dem, er der et problem, hehe.
Er det ikke lidt noget skummelt assembler kode? Sidst jeg legende med den slags var assembler sproget CPU specifikt og gik uden om operativ systemet. Grunden til at den ikke kan ramme andet end Windows er vel at den er pakket ind i en PE fil. Jeg vil slet ikke udelukke at jeg tager fejl, den slags low-level ting var aldrig min stærke side.
Jeg mener nu at der for et par år siden var en virus der kunne inficere både Windows, Linux og andre, fordi den var skrevet i x86 assembler.
Jeg mener nu at der for et par år siden var en virus der kunne inficere både Windows, Linux og andre, fordi den var skrevet i x86 assembler.
#9 Jeg mener nu at der for et par år siden var en virus der kunne inficere både Windows, Linux og andre, fordi den var skrevet i x86 assembler.
Der er i hvert fald noget du har misforstået. Det er rigtigt, at hvis man brugte DOS eller et andet OS på samme niveau, så kunne man gå udenom operativsystemet. Det har i øvrigt ikke noget med sproget at gøre, du kunne lige så vel gøre det i C eller måske ligefrem pascal. Det kan godt være du får brug for nogle bitesmå stumper assembler kode, men det er ikke nødvendigt at skrive det hele i assembler.
Men på et moderne OS som f.eks. Linux, der kan du ikke gå udenom OS. Og det er ligegyldigt hvilket sprog du skriver i. En boot virus kan sagtens inficere en harddisk, hvor Linux er installeret. En boot virus ville så typisk allocere 1KB RAM til sig selv og så lægge sig mellem DOS og BIOS, sådan at den løbende kunne inficere alle de floppydiske man brugte.
Men hvis du starter Linux op på en maskine hvor der ligger en bootvirus i RAM, vil den sandsynligvis holde op med at virke i samme øjeblik Linux starter. For Linux sætter nemlig BIOS fuldstændigt ud af spillet og dermed vil en boot virus typisk også holde op med at fungere.
I teorien er det muligt at lave en virus, som overlever i RAM, selvom du indlæser Linux. Men jeg har aldrig hørt om nogen, der har gjort det i praksis.
Hvad angår hybridviruser, der kan angribe flere platforme, så er de vist også stadig kun teori.
Der er i hvert fald noget du har misforstået. Det er rigtigt, at hvis man brugte DOS eller et andet OS på samme niveau, så kunne man gå udenom operativsystemet. Det har i øvrigt ikke noget med sproget at gøre, du kunne lige så vel gøre det i C eller måske ligefrem pascal. Det kan godt være du får brug for nogle bitesmå stumper assembler kode, men det er ikke nødvendigt at skrive det hele i assembler.
Men på et moderne OS som f.eks. Linux, der kan du ikke gå udenom OS. Og det er ligegyldigt hvilket sprog du skriver i. En boot virus kan sagtens inficere en harddisk, hvor Linux er installeret. En boot virus ville så typisk allocere 1KB RAM til sig selv og så lægge sig mellem DOS og BIOS, sådan at den løbende kunne inficere alle de floppydiske man brugte.
Men hvis du starter Linux op på en maskine hvor der ligger en bootvirus i RAM, vil den sandsynligvis holde op med at virke i samme øjeblik Linux starter. For Linux sætter nemlig BIOS fuldstændigt ud af spillet og dermed vil en boot virus typisk også holde op med at fungere.
I teorien er det muligt at lave en virus, som overlever i RAM, selvom du indlæser Linux. Men jeg har aldrig hørt om nogen, der har gjort det i praksis.
Hvad angår hybridviruser, der kan angribe flere platforme, så er de vist også stadig kun teori.
NX bliver nu også herligt når det kommer til. Men jeg ser nu mere værdi i teknologien på Linux end på Windows, da man jo på Linux kan bruge den til at nægte ekserkvering af software der ligger udenfor en standard path, Windows har ikke rigtigt nogen standard path, alt software spiller sit eget spil.
Og udover at lave 'ikke-ekserkver' regler, kan jeg ikke se hvad NX skal bruges til.
Og udover at lave 'ikke-ekserkver' regler, kan jeg ikke se hvad NX skal bruges til.
#12 kan bruge den til at nægte ekserkvering af software der ligger udenfor en standard path
Du har da overhovedet ikke forstået hvad NX går ud på. Men så må jeg jo prøve at forklare det.
Når vi snakker om execute rettigheder på filer, så har Linux allerede mange muligheder. Der kræves ikke nogen særlig hardware support for det. Du kan med en standard Linux kerne angive, hvilke filsystemer, der må køres executables fra. Hvis /tmp og /home er seperate filsystemer kunne du f.eks. mounte de to filsystemer med en noexec option. Og det vil virke selv på en 486. Man kunne måske enda mounte /var med noexec, men jeg er ikke sikker på, om det ville give nogen problemer.
Når vi begynder at se på processers adresserum er det en helt anden problemstilling. Der er stadig de samme tre navne, der bruges: read, write og execute rettigheder. Men betydningen er ikke helt den samme. Desuden er man begrænset til de muligheder hardwaren stiller til rådighed i page table formatet.
Adresserummet består af memory mappede filer, og anonyme mappings. Og hvor execute på en fil betyder, at du må kører programmet betyder execute på en hukommelsesside, at CPUen må afvikle kode fra siden. Men ikke alle kombinantioner af rettigheder til en side giver mening, og nogle af dem der giver mening er ikke understøttet af alt hardware.
Det giver f.eks. ikke ret meget mening at mappe en side med write eller execute rettigheder uden samtidig at have read. Faktisk tror jeg det ville blive lidt vanskeligt at lave hardware der understøttede det. På den anden side giver det glimrende mening at lave en programfil med kun execute rettigheder og ingen read. Når du kører programmet vil det blive mappet ind i adresserummet med både read og execute, men det er kun programmet selv, der kan læse disse mappings, så brugeren får stadig ikke mulighed for at læse siderne.
På nogle maskiner kan kode fra en side udføres, hvis man blot har læseadgang til siden. Det vil sige at hvis du beder kernen om at sætte den ene, så får du dem begge. Det er som sådan ikke noget sikkerhedshul, men det gør det nemmere at udnytte et evt. sikkerhedshul fundet et andet sted. Derfor er NX interessant.
Det vil sige, at hvis du ikke har brug for at udføre kode fra en given side, så kan den mappes med NX og dermed forhindre udførelse af kode fra den givne side. Programmer fortæller allerede nu kernen, om de har brug for at udføre kode fra en side. Men kernen kan pga. begrænsninger i hardwaren ikke implementere det på alle arkitekturer.
Et program hvor ingen side har både write og execute rettigheder vil gøre det svært at udnytte overløb. Du ville være nødt til at overskrive data, så den eksisterende kode udfører systemkald, der kan hjælpe dig. Det er langt vanskeligere end hvis du bare kunne injekte noget kode.
Nogen der tør gætte på, hvornår vi ser et proof of concept exploit, der udnytter et bufferoverløb i et program uden en eneste write+execute side?
Håber det hjalp bare en lille smule på forståelsen. Ellers må du spørge, så skal jeg prøve om jeg kan gøre det bedre. :-)
Du har da overhovedet ikke forstået hvad NX går ud på. Men så må jeg jo prøve at forklare det.
Når vi snakker om execute rettigheder på filer, så har Linux allerede mange muligheder. Der kræves ikke nogen særlig hardware support for det. Du kan med en standard Linux kerne angive, hvilke filsystemer, der må køres executables fra. Hvis /tmp og /home er seperate filsystemer kunne du f.eks. mounte de to filsystemer med en noexec option. Og det vil virke selv på en 486. Man kunne måske enda mounte /var med noexec, men jeg er ikke sikker på, om det ville give nogen problemer.
Når vi begynder at se på processers adresserum er det en helt anden problemstilling. Der er stadig de samme tre navne, der bruges: read, write og execute rettigheder. Men betydningen er ikke helt den samme. Desuden er man begrænset til de muligheder hardwaren stiller til rådighed i page table formatet.
Adresserummet består af memory mappede filer, og anonyme mappings. Og hvor execute på en fil betyder, at du må kører programmet betyder execute på en hukommelsesside, at CPUen må afvikle kode fra siden. Men ikke alle kombinantioner af rettigheder til en side giver mening, og nogle af dem der giver mening er ikke understøttet af alt hardware.
Det giver f.eks. ikke ret meget mening at mappe en side med write eller execute rettigheder uden samtidig at have read. Faktisk tror jeg det ville blive lidt vanskeligt at lave hardware der understøttede det. På den anden side giver det glimrende mening at lave en programfil med kun execute rettigheder og ingen read. Når du kører programmet vil det blive mappet ind i adresserummet med både read og execute, men det er kun programmet selv, der kan læse disse mappings, så brugeren får stadig ikke mulighed for at læse siderne.
På nogle maskiner kan kode fra en side udføres, hvis man blot har læseadgang til siden. Det vil sige at hvis du beder kernen om at sætte den ene, så får du dem begge. Det er som sådan ikke noget sikkerhedshul, men det gør det nemmere at udnytte et evt. sikkerhedshul fundet et andet sted. Derfor er NX interessant.
Det vil sige, at hvis du ikke har brug for at udføre kode fra en given side, så kan den mappes med NX og dermed forhindre udførelse af kode fra den givne side. Programmer fortæller allerede nu kernen, om de har brug for at udføre kode fra en side. Men kernen kan pga. begrænsninger i hardwaren ikke implementere det på alle arkitekturer.
Et program hvor ingen side har både write og execute rettigheder vil gøre det svært at udnytte overløb. Du ville være nødt til at overskrive data, så den eksisterende kode udfører systemkald, der kan hjælpe dig. Det er langt vanskeligere end hvis du bare kunne injekte noget kode.
Nogen der tør gætte på, hvornår vi ser et proof of concept exploit, der udnytter et bufferoverløb i et program uden en eneste write+execute side?
Håber det hjalp bare en lille smule på forståelsen. Ellers må du spørge, så skal jeg prøve om jeg kan gøre det bedre. :-)
#14 Jeg har lige et par komentarer til den artikel.
Når Linux og Solaris har understøttet denne feature i årevis skyldes det nok primært, at de har kørt på hardware, der havde den. Windows kører ikke på så mange forskellige platforme som Linux, jeg ved ikke om nogen af de platforme Windows har kørt på har denne feature.
Men der skam ikke noget nyt i denne feature. Så vidt jeg ved fandtes den allerede på andre platforme, da Intel introducerede paging på 386'eren.
Artiklen fortsætter med at snakke om Java compilere. Det må være en fejl, det er Java VM, der i nogen implementationer bruger JIT compilering. Der står i artiklen, at de skal skrives om. I praksis bliver der højst tale om mindre ændringer.
På Linux burde alt eksisterende software fungere uden ændringer efter introduktionen af NX. Men i praksis har der været fejl i noget software som gjorde, at der skulle rettes nogle småfejl hist og her for at det fortsat ville virke.
På Windows kan situationen godt være en anden. Hvis hele APIen til at håndtere NX biten er ny, kan gamle programmer naturligvis ikke have brugt den korrekt. Men jeg ved intet om Windows API.
Artiklen får det til at lyde som om forsøg på at afvikle kode fra nonexecutable pages får Windows til at gå ned. Jeg ved ikke om det er sandt, men i så fald ville det gøre Windows mere ustabilt end det er i dag. Det er kun det ene program, der skal lukkes ned, og den slags skal håndteres som enhver anden exception. Segmentation fault (core dumped)
Når Linux og Solaris har understøttet denne feature i årevis skyldes det nok primært, at de har kørt på hardware, der havde den. Windows kører ikke på så mange forskellige platforme som Linux, jeg ved ikke om nogen af de platforme Windows har kørt på har denne feature.
Men der skam ikke noget nyt i denne feature. Så vidt jeg ved fandtes den allerede på andre platforme, da Intel introducerede paging på 386'eren.
Artiklen fortsætter med at snakke om Java compilere. Det må være en fejl, det er Java VM, der i nogen implementationer bruger JIT compilering. Der står i artiklen, at de skal skrives om. I praksis bliver der højst tale om mindre ændringer.
På Linux burde alt eksisterende software fungere uden ændringer efter introduktionen af NX. Men i praksis har der været fejl i noget software som gjorde, at der skulle rettes nogle småfejl hist og her for at det fortsat ville virke.
På Windows kan situationen godt være en anden. Hvis hele APIen til at håndtere NX biten er ny, kan gamle programmer naturligvis ikke have brugt den korrekt. Men jeg ved intet om Windows API.
Artiklen får det til at lyde som om forsøg på at afvikle kode fra nonexecutable pages får Windows til at gå ned. Jeg ved ikke om det er sandt, men i så fald ville det gøre Windows mere ustabilt end det er i dag. Det er kun det ene program, der skal lukkes ned, og den slags skal håndteres som enhver anden exception. Segmentation fault (core dumped)
#13
I stand corrected...
Jeg er fuldt klar over at featuren findes på kerne niveau under Linux, spekulationen lå i om man kunne bruge NX til at blokere for ekserkveringer der ikke direkte er implementeret på kerne niveau.
But...I still stand corrected...
Hvis jeg kan opsummere din pointe, så betyder det at det eneste nye for linux/unix styresystemet, er at man kan implementere NX via. CPU'en (på X86 cpu'er med NX support), istedet for på kerne niveau.
I stand corrected...
Jeg er fuldt klar over at featuren findes på kerne niveau under Linux, spekulationen lå i om man kunne bruge NX til at blokere for ekserkveringer der ikke direkte er implementeret på kerne niveau.
But...I still stand corrected...
Hvis jeg kan opsummere din pointe, så betyder det at det eneste nye for linux/unix styresystemet, er at man kan implementere NX via. CPU'en (på X86 cpu'er med NX support), istedet for på kerne niveau.
#7 Jeg mente det i samme måde som personen jeg skrev det til. Altså at det for folk overhovedet var overraskende.
Jeg ved godt at NX mere eller mindre kun arbejder ved begrænse den adgang programmet har. Hvilket så også betyder som du også er inde på og forklarer i langt større detalje kun vil modvirke buffer overflow exploits.
Men umiddelbart behøver den ikke at hedde orm bare fordi det er buffer overflow, selvom det er ret underligt at bruge software til det, fordi så er det buffer overflow jo alligevel ligegyldigt hvis brugeren selv kører programmet.
Jeg ved godt at NX mere eller mindre kun arbejder ved begrænse den adgang programmet har. Hvilket så også betyder som du også er inde på og forklarer i langt større detalje kun vil modvirke buffer overflow exploits.
Men umiddelbart behøver den ikke at hedde orm bare fordi det er buffer overflow, selvom det er ret underligt at bruge software til det, fordi så er det buffer overflow jo alligevel ligegyldigt hvis brugeren selv kører programmet.
#16 så betyder det at det eneste nye for linux/unix styresystemet, er at man kan implementere NX via. CPU'en (på X86 cpu'er med NX support), istedet for på kerne niveau.
OK, jeg prøver igen. Der er to forskellige no execute indstillinger. Den du efterlyste er på fil niveau og har eksisteret i Linux i lang tid, fordi den ikke kræver hardware understøttelse. Den anden er på page niveau og kræver hardware support, og har derfor ikke været implementeret på alle arkitekturer.
Det vil sige at hvor vi hidtil har haft APIen for begge slags noexecute, så er det kun den ene, der har været implementeret.
#17 Men umiddelbart behøver den ikke at hedde orm bare fordi det er buffer overflow
Vil du lige forklare, hvad du mener forskellen på en orm og en virus er? (Ellers tror ikke jeg har en chance for at forstå dit indlæg)
OK, jeg prøver igen. Der er to forskellige no execute indstillinger. Den du efterlyste er på fil niveau og har eksisteret i Linux i lang tid, fordi den ikke kræver hardware understøttelse. Den anden er på page niveau og kræver hardware support, og har derfor ikke været implementeret på alle arkitekturer.
Det vil sige at hvor vi hidtil har haft APIen for begge slags noexecute, så er det kun den ene, der har været implementeret.
#17 Men umiddelbart behøver den ikke at hedde orm bare fordi det er buffer overflow
Vil du lige forklare, hvad du mener forskellen på en orm og en virus er? (Ellers tror ikke jeg har en chance for at forstå dit indlæg)
Hmm - jeg tror sgu at jeg vil være ham, der koder den *sidste* virus. Måske jeg også kan få en nyhed: "Den sidste virus til Novell er opdaget" :)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund