mboost-dp1
Microsoft Corporation
Men hvis man ikke bruger Safari, skulle der vel ikke være noget problem?
Og hvor mange sidder egentlig på Safari på en Windows maskine?
Og hvor mange sidder egentlig på Safari på en Windows maskine?
der er fordele og ulemper ved BSOD :P
http://ffnerdity.files.wordpress.com/2011/11/bsod_...
http://ffnerdity.files.wordpress.com/2011/11/bsod_...
Kommer Safari ikke automatisk på hvis man i en brandert smider iTunes på sin maskine og ikke får unchecked et eller andet flueben?
Men ok, behøver jo ikke bruge det selv om det er installeret... præcis som iTunes. (Kan også blot være ved Quicktime, som jeg heller ikke vil installere)
Men ok, behøver jo ikke bruge det selv om det er installeret... præcis som iTunes. (Kan også blot være ved Quicktime, som jeg heller ikke vil installere)
Ahh, kom lige i tanke om at næsten uanset hvad du smider på din windoze, så kommer den forbandede Bonjour service med (Som jo har haft sine egne sårbarheder) og i det hele taget ikke har en skid at gøre på min maskine.
#8 Safari bliver bashet, fordi det en et notorisk gennemhullet browser. I hvert fald på PC. Når der så tilmed er en browser Apple fik sneget ind af bagvejen på mange brugere, så er det helt af helvede til at de lader sådan noget, som dette, sig gøre.
Og så ikke et ord om Apples tese: "Vores produkter er fri for sikkerhedsfejl, modsat Microsofts".
#11 Jeg kender kun en enkelt eller to mac-brugere der bruger Safari - og jeg har immervæk, efterhånden, en del omkring mig der bruger Mac. Men det er jo selvfølgelig forskelligt fra omgangskreds til omgangskreds. Hos mig, som ikke er nørdede venner allesammen, bliver Firefox primært brugt.
Og så ikke et ord om Apples tese: "Vores produkter er fri for sikkerhedsfejl, modsat Microsofts".
#11 Jeg kender kun en enkelt eller to mac-brugere der bruger Safari - og jeg har immervæk, efterhånden, en del omkring mig der bruger Mac. Men det er jo selvfølgelig forskelligt fra omgangskreds til omgangskreds. Hos mig, som ikke er nørdede venner allesammen, bliver Firefox primært brugt.
Hald (8) skrev:Sjovt nok er det et hul i Windows, og stadig basher folk Safari for det.. hehe..
Muligvis fordi Safari er eneste årsag til svagheden kan udnyttes. :)
Silver Mane (6) skrev:#5 Jo, Æble er rimelig glad for at smide den i nakken på en.
Hmm. Er der pålagt frit browservalg på Apples produkter? Får man også et fancy browservalg, eller har man bare en standardbrowser der, præcis som IE, kan hente en anden?
bjerh og drhouse>>
NEJ- safari har INTET galt gjort, på ingen måde, det er en regnefejl i en del af AERO temaet i windows kernellen.
Det virker TILFÆLDIGTVIS ikke med samme integer i IE, fordi der er en ANDEN css fejl der kicker ind først.
Men et tilsvarende tal kan findes i IE, det er bare et spørgsmål om tid.
Det kan teoretisk også udnyttes i ting som java, flash etc.
NEJ- safari har INTET galt gjort, på ingen måde, det er en regnefejl i en del af AERO temaet i windows kernellen.
Det virker TILFÆLDIGTVIS ikke med samme integer i IE, fordi der er en ANDEN css fejl der kicker ind først.
Men et tilsvarende tal kan findes i IE, det er bare et spørgsmål om tid.
Det kan teoretisk også udnyttes i ting som java, flash etc.
-N- (16) skrev:Så er det altså stadig apples fejl at windows går ned.
NEJ! Det er det på ingen måde, apple bruger bare en windows komponent på den helt korrekte måde......det er 100% en windows fejl!
cryo (11) skrev:Mon ikke de fleste Mac-brugere bruger Safari? Det er mit indtryk. Jeg bruger den også på Windows, på arbejdet, men det er nok lidt sjældnere.
Jeg tror faktisk at ret mange også bruge Chrome - det er min fornemmelse fra de macfora jeg benytter.
Jeg sidder på mac men bruger absolut mest Chrome.
-N- (16) skrev:#8 øhh?!? Der var vist en macboi der læste hvad han gerne ville :-D
Fejlen kan potentielt udnyttes til ondsindet kode.
Så er det altså stadig apples fejl at windows går ned.
øhhh: The security flaw stems from an error in the win32k.sys kernel-mode driver, a common source for critical Windows vulnerabilities.
Ud over det er det så også slamkode i safari.
Man kan så undres at et program har rettigheder og tilgang til kernen, og dermed kan forårsage systemfejl. Læs mellem linierne (arkitekturfejl)
darkwulf (22) skrev:Ud over det er det så også slamkode i safari.
Hvad i alverden forestiller du dig at safari kunne have gjort anderledes?
Man kan så undres at et program har rettigheder og tilgang til kernen, og dermed kan forårsage systemfejl. Læs mellem linierne (arkitekturfejl)
Man kan ikke have et operativ system der ikke giver adgang til kernellen.......det er altså sådan at computere fungerer.
Hvordan vil du ellers f.eks. læse en fil?
Det eneste man kan uden at "have adgang til kernen" er at læse og skrive til ram og lave udregninger derpå.
Det er interessant om nogen kunne dokumentere om det er Windows eller Safari der fejler her.
Jeg troede heller ikke at programmer måtte have adgang til kernelen.
Jeg troede heller ikke at programmer måtte have adgang til kernelen.
#26 Læs linket i #10
http://pastebin.com/XTWnLF3p
http://pastebin.com/XTWnLF3p
The bug happens due to a NineGrid request coming through GdiDrawStream sent on behalf of the UX Theme DLL which handles Windows Themes starting in XP and later.
darkwulf (25) skrev:Min ven #23
API!
Programmer skal ikke have adgang til kernen, men kun til services der laver kaldene til driverne og kernen.
og det er også PRÆCIST sådan at det sker....safari kalder uxtheme.dll der kalder GdiDrawStream.
Fuldstændigt efter bogen!
Præcist samme opbygning som alle andre store operativ systemer- så hvad går din kritik helt konkret ud på?
Hvis du fjerner Safari vil der stadig være en bug i Windows. Hvis ikke Microsoft retter den bug, så vil der før eller siden blive fundet andre applikationer, der kan fremprovokere den.Silver Mane (1) skrev:Men hvis man ikke bruger Safari, skulle der vel ikke være noget problem?
Det er åbenlyst at der er en bug i Windows. Om der også er en bug i Safari er ikke helt så åbenlyst. Når en webside kan få et operativsystem til at gå ned, så er det mest sandsynlige at der er bugs i både browseren og operativsystemet, og hvis blot den ene af de to bugs bliver rettet vil operativsystemet ikke gå ned.Hald (8) skrev:Sjovt nok er det et hul i Windows, og stadig basher folk Safari for det
Hvis en bug i browseren får den til at lave ugyldige kald til operativsystemet og en bug i operativsystemet betyder at det går ned ved sådan et ugyldigt kald, så kan symptomet fjernes ved at rette en af de to bugs.
Retter man buggen i browseren vil det ikke længere lave ugyldige kald, og intet går ned. Men der er stadig en alvorlig bug i operativsystemet.
Retter man buggen i operativsystemet vil det ikke længere gå ned, men derimod give en fejl til browseren, når den laver et ugyldigt kald. Denne fejl kunne nemt få browseren til at gå ned. I så fald er der stadig fejl i browseren, men i det mindste er det kun browseren og ikke hele OS, der går ned.
Men så vidt jeg kan vurdere ud fra linket i #10 er der i det konkrete tilfælde udelukkende tale om en fejl i operativsystemet. Det er tilsyneladende et fuldstændigt gyldigt kald fra browseren, der får operativsystemet til at gå ned.
Er der stadig nogen der synes at det er en god idé at lave grafik i kernen?Mamad (moveax1ret) (15) skrev:NEJ- safari har INTET galt gjort, på ingen måde, det er en regnefejl i en del af AERO temaet i windows kernellen.
Hvis en applikation kan få operativsystemet til at gå ned, så er det en bug i operativsystemet. Den bug skal under alle omstændigheder rettes. Når den pågældende bug i operativsystemet er rettet bliver det lidt nemmere at finde ud af, om der også er en bug i applikationen.ufomekaniker (26) skrev:Det er interessant om nogen kunne dokumentere om det er Windows eller Safari der fejler her.
kasperd (30) skrev:Er der stadig nogen der synes at det er en god idé at lave grafik i kernen?
Microkernels FTW?
Nu er der jo egentlig ikke "noget galt" i at gøre det, bare der ikke er nogen vulnerabilities.
Lige så er der heller ikke "noget galt" i at indlæse en filsystem-driver i kernel-space, fremfor at bruge et user-space FS, hvis driveren ellers er "skrevet ordentligt".
Min pointe: Med mindre man vil det monolitiske kernel design til livs, kan jeg ikke se noget principielt forkert i at implementere grafikrenderingen i kernel-space, i et OS der er 100% grafisk.
GUI'en i Windows er selvfølgelig mere kompleks end f.eks. VT100 emuleringen i *nix, så der er meget større risiko for fejl, men en af grundstrategierne for Windows har jo længe været, at det ikke længere skal være en shell som er bygget ovenpå DOS.
Ok, man burde nok have implementeret theming i user-space, og lavet en meget simpel (og robust) implementering som fallback i kernel-space, i tilfælde af at Aero segfaulter.
TLDR:
- Simpel grafikrendering i kernel-space er i orden.
- Theming, avanceret grafik m.m. burde ske i user-space.
Resten af dit indlæg kan jeg sagtens tilslutte mig. Men lige netop den ene sammenligning er dog helt hen i vejret.tachylatus (31) skrev:en af grundstrategierne for Windows har jo længe været, at det ikke længere skal være en shell som er bygget ovenpå DOS.
Grafisk versus tekst baseret brugerflade er da en ganske ubetydelig detaljer i forhold til alle de andre forskelle, der er på DOS og Windows.
Windows versioner til og med Windows ME var ganske rigtigt kun shells ovenpå DOS. Men at de implementerede en grafisk brugerflade ovenpå DOS som ikke havde nogen grafik support i sig selv var det absolut mindste problem med de Windows versioner.
De langt mere alvorlige problemer var at DOS ingen form for protection havde, og applikationer dermed kørte med adgang til alt. Desuden havde DOS ikke support for multitasking. At Windows kunne multitaske ovenpå DOS var en betydelig bedrift, men det betyder ikke at resultatet var godt. Det havde været bedre at droppe DOS helt og lave et rigtigt OS direkte på hardwaren. Det er til dels også det de har gjort med Windows NT (som dog først blev populært da navnet blev ændret til Windows 2000 og siden Windows XP).
Det har du selvfølgelig fuldstændigt ret i, min kommentar var lidt for simplificeret på det punkt.tachylatus (31) skrev:- Simpel grafikrendering i kernel-space er i orden.
- Theming, avanceret grafik m.m. burde ske i user-space.
At lægge alt grafik i user mode betyder at user mode skal have low level adgang til hardwaren. Det er næsten lige så slemt som at lægge hele grafiksystemet ned i kernen. Den måde XFree86 og Xorg tilgår hardwaren på er ikke pæn, dog vil fejl i X sjældent få computeren til at gå ned, man kan næsten altid logge ind via ssh og fejlfinde og nogen gange få grafiksystemet tilbage til en funktionel stand uden at genstarte computeren.
Så både Windows og Xorg har den samme monolit, som burde have været opdelt. At det ene system har denne monolit i kernen og det andet i user mode ændrer ikke på at det er en monolit som burde være opdelt.
Et simpelt robust low level system og et mere avanceret high level system bygget ovenpå med passende separering af de to er en mere tiltalende idé.
Low level systemet skal ikke nødvendigvis ned i kernen. At køre det i user mode med adgang til hardwaren er nok stadig en fordel. Det skal bare være to forskellige processer der håndterer low level og high level delen af grafikken.
En mikro kerne er nok vejen frem, men man skal dog overveje designet omhyggeligt for at bevare nogle af fordelene fra den monolitiske kerne.
Når hver tråd kan skifte mellem user mode og kerne mode og udføre de nødvendige operationer i kerne mode gør det designet simplere. Et mikro kerne design kræver at ethvert kontrolflow skal gennem flere kontekster. Måske skulle det være muligt for en enkelt tråd at bevæge sig gennem alle disse kontekster.
En mikro kerne der gør op med idéen om at kontekst og tråde er så tæt forbundet er måske vejen frem.
Hvis jeg tager Linux som eksempel (fordi det er det jeg kender bedst), så har man en kerne kontekst og et antal user mode kontekster. Hver tråd er knyttet til en user mode kontekst og kan aldrig afvikle i nogen anden user mode kontekst. En user mode kontekst og de tilhørende tråde kaldes under et for en process.
Er der nogen som har lavet et OS hvor tråde og user mode kontekster er mere ortogonale, og det er muligt for en tråd at skifte mellem forskellige user mode kontekster?
De4_Kia (34) skrev:At bruge Safari, er lige så hjernedød en ide, som at bruge noget som helst andet fra Apple. De folk der bruger Safari er selv skyld i det. Så tommel op for lav hjerne aktivt hos dem der bruger noget som helst fra Apple.
For det meste enig. Jeg havde bare valgt at bruge lidt pænere ord.
For lige at slå fast:
Safari er den browser med langt de fleste sikkerhedshuller. Sikkerhedsmæssigt er den noget af det værste slamkodning der nogensinde er forekommet i computersoftwarens historie. Se nu bare hvor få minutter der gik før den blev hacked til Pwn2Own hvor en browser som Chrome endnu står fuldstændig ubesejret selv om Google satte 20.000$ på højkant. Ingen af hackerne så meget som forsøgte at knække Chrome... (Jeg ved nogen har påstået at de har formået at hacke den efterfølgende, men ikke har ville fremsætte beviser. Så er troværdigheden ligesom røget under frysepunktet, ikke? In short: Klammeste publicity stunt siden Apples "leaked" iPhone 4.)
Brug nu bare for helvede Chrome så vi kan sørge for Internettet ikke får flere botnets at slåsse med fordi folk bruger pis-browsere der ikke kan beskytte imod alskens malware.
Tak.
ShamblerDK (36) skrev:For lige at slå fast:
Safari er den browser med langt de fleste sikkerhedshuller. Sikkerhedsmæssigt er den noget af det værste slamkodning der nogensinde er forekommet i computersoftwarens historie.
Brug nu bare for helvede Chrome
Ser man på Secunias oversigt så har Chrome de seneste 12 mdr. haft 247 sårbarheder mens Safari har haft 147. På den baggrund vil det direkte være at skyde sig i foden at bruge Chrome.
Mere sikker er Firefox og helt i top ligger IE - men de kan så ikke vise PDF og derfor skal fejlene i Adobe Reader lægges til.
Resultatet med brug af tal fra Secunia er derefter... Safari til mac er den mest sikre browser, mens Chrome (alle platforme) er den mest usikre.
caffery (38) skrev:Det er derfor safari altid er den browser der blir hacket først/hurtigst til diverse hacker konferencer....mens chrome altid er den browser der står tilbage...uhacket :)
Pwn2Own fungerer på den måde at du hacker det udstyr du vinder... og ja - til lige netop den konkurrence er det sjovt nok altid Apples udstyr der bliver hacket først... gæt selv hvorfor :-D
Nå, men antallet af sikkerhedsadvarsler er fortsat 30% højere på Chrome.
nubus (39) skrev:Pwn2Own fungerer på den måde at du hacker det udstyr du vinder... og ja - til lige netop den konkurrence er det sjovt nok altid Apples udstyr der bliver hacket først... gæt selv hvorfor :-D
Ja, for man kan slet ikke få en Apple-computer for de $20.000 man vandt ved at hacke Chrome?
Skal vi ikke bare kalde dit argument invalidt?
Det kan lige så vel afspejle hvor meget åbenhed der er om sikkerhedsproblemer som det kan afspejle hvor mange sikkerhedsproblemer der findes.nubus (39) skrev:antallet af sikkerhedsadvarsler er fortsat 30% højere på Chrome.
Hvis de fleste sikkerhedsproblemer findes af udviklerne selv, så er det muligt at sende et stort antal rettelser ud i hver opdatering uden at afsløre præcist hvor mange sikkerhedshuller der blev lukket.
At vurdere programmet sikkerhed, ud fra at tælle fejl, viser bare hvor *lidt* man ved om IT sikkerhed.
http://krebsonsecurity.com/2010/11/why-counting-flaws-is-flawed/
Et program der har 2 fejl som gør det muligt at få programmet til at gå ned (men ikke køre vilkårligt kode / skaffe informationer om systemet) - skulle være mere "usikkert" end et program som de sidste 3 år har haft en fejl som gør det muligt for en tredjepart at køre vilkårligt kode? Nej vel.
Nogle folk rapportere også en fejl i et modul som én fejl, hvor andre rapportere det som 10 forskellige (sådan nogle "gentagene" fejl, skal man tælle fra)
Hvor meget adgang får man ved fejlen? 15 fejl i Chrome, men hvor man stadig *INTET* kan gøre pga den indbyggede sandbox vs 1 fejl i Safari hvor man får FULD ADGANG. - Hvad er farligst?
Og hvor lang tid tager det at rette fejlen? (e.g sikkerheds hullet "ZDI-CAN-1184" blev rapporteret til Apple for 150 dage siden).
Ontopic: Et program skal self. aldrig kunne få hele systemet til at gå ned. (Men: Safari = usikker slamkode)
http://krebsonsecurity.com/2010/11/why-counting-flaws-is-flawed/
Et program der har 2 fejl som gør det muligt at få programmet til at gå ned (men ikke køre vilkårligt kode / skaffe informationer om systemet) - skulle være mere "usikkert" end et program som de sidste 3 år har haft en fejl som gør det muligt for en tredjepart at køre vilkårligt kode? Nej vel.
Nogle folk rapportere også en fejl i et modul som én fejl, hvor andre rapportere det som 10 forskellige (sådan nogle "gentagene" fejl, skal man tælle fra)
Hvor meget adgang får man ved fejlen? 15 fejl i Chrome, men hvor man stadig *INTET* kan gøre pga den indbyggede sandbox vs 1 fejl i Safari hvor man får FULD ADGANG. - Hvad er farligst?
Og hvor lang tid tager det at rette fejlen? (e.g sikkerheds hullet "ZDI-CAN-1184" blev rapporteret til Apple for 150 dage siden).
Ontopic: Et program skal self. aldrig kunne få hele systemet til at gå ned. (Men: Safari = usikker slamkode)
trylleklovn (44) skrev:ITT: Apple haters, der forsøger at fjerne fokus fra en bug i windows.
There we go.
Jakob Jakobsen (40) skrev:Ja, for man kan slet ikke få en Apple-computer for de $20.000 man vandt ved at hacke Chrome?
Man fik 20.000 USD og den laptop man arbejdede på - både for Chrome og Safari. Google betaler dog for fejl, mens alle andre er af den overbevisning at fejl er noget man rapporterer gratis.
Desuden... Apple har sat priserne ned på deres hardware :-D En IIfx kostede 20.800 USD (justeret for inflation)... deres nuværende modeller er lidt billigere (indtil du skal skifte batteri på dem - hvilket koster 2000,-!).
kasperd (42) skrev:Det kan lige så vel afspejle hvor meget åbenhed der er om sikkerhedsproblemer som det kan afspejle hvor mange sikkerhedsproblemer der findes..
Både Safari og Chrome bygger grundlæggende på det samme open source projekt... og Safaris JavaScript engine er også bygget på open source - tror du selv Apple kan gemme fejlene i så massiv grad? Apple committer jo koden tilbage.
Nicolai (43) skrev:At vurdere programmet sikkerhed, ud fra at tælle fejl, viser bare hvor *lidt* man ved om IT sikkerhed.
Det behøver du ikke et link for at fortælle. Det er alene en indikator. Ang. fejl i Chrome - sikkerheden i den er også blevet brudt trods alle Googles sandbox systemer.
Nicolai (43) skrev:Ontopic: Et program skal self. aldrig kunne få hele systemet til at gå ned. (Men: Safari = usikker slamkode)
Det er fandme ikke ontopic. Det er onFlame. Medmindre du selv bidrager til WebKit (jeg gør) eller har sat dig ind i koden, så synes jeg sådan set du skal holde kæft - og gerne hurtigt. Slamkode... hrmpf!
#44 - Xorpiz/pewbe... en lang tråd og det første I kan ryste op med er et personangreb. Det er jo som at se de to gamle mænd i Muppet Show. En glædelig jul til jer :-)
nubus (46) skrev:#44 - Xorpiz/pewbe... en lang tråd og det første I kan ryste op med er et personangreb. Det er jo som at se de to gamle mænd i Muppet Show. En glædelig jul til jer :-)
Jeg troede at et personangreb kræver at jeg skriver noget nedsættende om dig?
nubus (46) skrev:#44 - Xorpiz/pewbe... en lang tråd og det første I kan ryste op med er et personangreb. Det er jo som at se de to gamle mænd i Muppet Show. En glædelig jul til jer :-)
Intet personangreb over det. Jeg skrev jo blot, at du trollede som sædvanlig. Hvis du føler dig angrebet, så beklager jeg da, siden det nu er den 24. december og alt det der.
Spørgsmål: Hvordan er det lige potentielt farlig kode bliver kørt når win7 går i blå? Hvornår sker det? Under bluescreenen/memory dump? efter reboot eller hvad?
Jeg kan ikke få det til at blive et reelt "sikkerhedshul" i mit hovedet. Hvordan skulle denne bug anvendes praktisk som en vej ind? Er det ikke 'højst' kun et link til en side som crasher dit system?
-"Secunia mener"... hvad? de gætter, gør de.
Jeg kan ikke få det til at blive et reelt "sikkerhedshul" i mit hovedet. Hvordan skulle denne bug anvendes praktisk som en vej ind? Er det ikke 'højst' kun et link til en side som crasher dit system?
-"Secunia mener"... hvad? de gætter, gør de.
#49
Nu bliver jeg selv nødt til at gætte lidt, da jeg ikke har værktøjer til at lave en dyberegående analyse.
De kan få en funktion til at skrive til en stack eller heap, uden for det reserverede område.
Hvis det er stacken(det tror jeg) kan det for eksempel være noget i denne retning:
void paintSomething(int* pixelsYToshow)
{
int[50] pixelsy;
memcpy( &pixelsy,pixelsYToshow,sizeof(int)*255);
etc.
}
og paintSomething bliver så kaldt med et array større end 50.
lad os for nemhedens skyld så sige at bufferen er på 5 istedet for 50.
Så kan man på en eller anden måde få den funktion til at blive kaldt med et array på over 5 i størrelse.
Windows har så lavet et memory layout der har reserveret plads til 5 integers, men der kommer 50 ind.
det kan for eksempelsel se ca. sådan her ud:
[Data fra en anden funktion]
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00467701 = Dette er så adressen på den funktion der kaldte funktionen med fejlen, når at funktionen er færdig hopper cpuen tilbage til denne addresse. Inden at en funktion bliver kaldt bliver returneringsaddressen pushed på stacken ved det mest brugte assembly layout.
Hvis at man så kan bede den funktion om at tegne pixels værdier der memory layout mæssigt svarer til x86 opcodes kan man plante eksekverbar kode i den pixelsbuffer.
Men vi skal også kunne køre det......
Fordi at vi kun allokerer 5 pladser til integers, men beder windows om at kopiere op til 255 kan vi overskride den allokerede grænse.
Så træder vi ind på den plads hvor at return værdien ligger(00467701 ) i eksemplet.
Hvis vi der får skrevet at den skal hoppe antallet af integers der er reserveret * størrelsen af en integer -5 vil den istedet for at hoppe tilbage til den kaldende funktion hoppe tilbage til de pixelværdier vi har sendt, og der tilfældigvis også kan køres som x86 opcodes. Derved kan vi ved at bede funktionen om at tegne noget helt specifikt få den til at køre det assembly kode vi beder den om på system niveau(adgang til at ændre i kernel ram).
Den exploit der er ude nu crasher bare, fordi det ikke er lykkedes noget at plante eksekverbar kode i den buffer endnu...
Men altså, denne writeup er MEGET simplificeret, og der kan være mange andre ting der spiller ind f.eks. DEP, det kan vi tage en anden gang :)
Håber bare det kan give dig en ide om hvordan man kan have en exploit der crasher et system, men ikke endnu have en exploit der giver adgang til at køre vilkårlig kode :)
Nu bliver jeg selv nødt til at gætte lidt, da jeg ikke har værktøjer til at lave en dyberegående analyse.
De kan få en funktion til at skrive til en stack eller heap, uden for det reserverede område.
Hvis det er stacken(det tror jeg) kan det for eksempel være noget i denne retning:
void paintSomething(int* pixelsYToshow)
{
int[50] pixelsy;
memcpy( &pixelsy,pixelsYToshow,sizeof(int)*255);
etc.
}
og paintSomething bliver så kaldt med et array større end 50.
lad os for nemhedens skyld så sige at bufferen er på 5 istedet for 50.
Så kan man på en eller anden måde få den funktion til at blive kaldt med et array på over 5 i størrelse.
Windows har så lavet et memory layout der har reserveret plads til 5 integers, men der kommer 50 ind.
det kan for eksempelsel se ca. sådan her ud:
[Data fra en anden funktion]
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00000000 =reserveret hukommelse til pixelsne
00467701 = Dette er så adressen på den funktion der kaldte funktionen med fejlen, når at funktionen er færdig hopper cpuen tilbage til denne addresse. Inden at en funktion bliver kaldt bliver returneringsaddressen pushed på stacken ved det mest brugte assembly layout.
Hvis at man så kan bede den funktion om at tegne pixels værdier der memory layout mæssigt svarer til x86 opcodes kan man plante eksekverbar kode i den pixelsbuffer.
Men vi skal også kunne køre det......
Fordi at vi kun allokerer 5 pladser til integers, men beder windows om at kopiere op til 255 kan vi overskride den allokerede grænse.
Så træder vi ind på den plads hvor at return værdien ligger(00467701 ) i eksemplet.
Hvis vi der får skrevet at den skal hoppe antallet af integers der er reserveret * størrelsen af en integer -5 vil den istedet for at hoppe tilbage til den kaldende funktion hoppe tilbage til de pixelværdier vi har sendt, og der tilfældigvis også kan køres som x86 opcodes. Derved kan vi ved at bede funktionen om at tegne noget helt specifikt få den til at køre det assembly kode vi beder den om på system niveau(adgang til at ændre i kernel ram).
Den exploit der er ude nu crasher bare, fordi det ikke er lykkedes noget at plante eksekverbar kode i den buffer endnu...
Men altså, denne writeup er MEGET simplificeret, og der kan være mange andre ting der spiller ind f.eks. DEP, det kan vi tage en anden gang :)
Håber bare det kan give dig en ide om hvordan man kan have en exploit der crasher et system, men ikke endnu have en exploit der giver adgang til at køre vilkårlig kode :)
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