Sicherheitsprobleme durch zwang auf 32-Bit Browser duch Pluginhersteller
-
Ja das ist wirklich ein problem. Duch das ignorieren der 64-Bit systeme durch die hersteller habe ich immer noch einen 32-bit browser, der höchstwahrscheinlich ohne ASLR oder nur mit einer sehr ineffizienten version davon läuft. Das vermilliardenfacht die chance, dass jemand durch einen buffer-overflow meinen browser übernimmt und irgendeinen shellcode(NX in 32-bit?) oder eine return-to-libc attacke ausführt.
Soetwas darf doch nicht sein. DUrch NX + ASLR auf 64-Bit ist doch die wahrscheinlichkeit*, dass ein bufferoverflow funktioniert geringer als die von einem blitz getroffen zu werden.
Die einzigen sicherheitsprobleme wären DoS oder social-engineering attacken. Aber nein die bösen hersteller wollen das ja wohl.
(falls es keine neuen arten von sicherheitslücken gibt(null pointer overflow oder so kam vor kurzem auf))*Angenommen der Speicher ist kleiner als 1 Petabyte(32-bit: wie bei canSecWest gesehen muss man nur genug speicher allozieren(um 1GB), damit die wahrscheinlichkeit bei 1/4 liegt).
So das war meine meckerei zu dem thema und ich hoffe auf meinungen/fehleraufzeigen.
-
Gehts jetzt um den Browser oder Plugins?
-
Von was für Plugins redest du denn?
-
Na von was wohl. Der flash und java mist.
-
quarkmischer schrieb:
Soetwas darf doch nicht sein. DUrch NX + ASLR auf 64-Bit ist doch die wahrscheinlichkeit*, dass ein bufferoverflow funktioniert geringer als die von einem blitz getroffen zu werden.
Das verstehe ich nicht, was hat 64-vs-32-Bit mit Buffer-Overflows zu tun?
-
Na wenn jemand auf einem 64-Bit system es schafft einen buffer-overflow zu benutzen, dann muss er die returnadresse(ohne NX) so verändern, dass sie auf den stack zeigt. Das geht meistens mit dem finden einer assembler instruktion in der anwendung die in etwa so aussieht: call eax(FF D0).
Nun tut der anwender also an einer stelle, an der im eax register der stackpointer gespeichert ist(beispiel printf u.ä. wegen auf-dem-stack-gespeichertem char array) bei einem overflow die return adresse mit der festen adresse der oben gefundenen assembler instruktion fütter, woduch eip nun auf den stack zeigt. (das klappt nur ohne NX).
Wenn NX aber aktiviert ist kann der bösewicht nurnoch eine return-to-libc attacke starten, d.h. z.B. einen string auf den stack legen, und als return adresse die adresse von der C-funktion system(char*) angeben, die den string dann als ihr argument nimmt.
Nun wenn jetzt jedoch ASLR aktiviert ist, dann kann die system-funktion an 2^(32 oder größer) verschiedenen stellen liegen, was dazu führt, dass bei den anderen 4 milliarden angriffen das (unsaber geschriebene?)programm einfach ins leere springt und ganz normal abstürzt, und so keine infektion zulässt. ==> buffer overflow wäre geschichte, und infektionen wären nur noch soetwas:
http://www.heise.de/newsticker/Virus-als-Vertrag-getarnt--/meldung/108347
-
du musst uns nicht erklären was ein buffer overflow ist oder wie das randomization zeug funktioniert du schlaubi schlumpf, der müll kann auc einem 32 bit system genauso implementiert werden
-
Was hat der Link damit zu tun?
-
hardrocker schrieb:
du musst uns nicht erklären was ein buffer overflow ist oder wie das randomization zeug funktioniert du schlaubi schlumpf, der müll kann auc einem 32 bit system genauso implementiert werden
Mit einer entropie von was? 8-bit?
@link: Das ist ein DAU-Virus
-
Vergrößerung des Adressraums hört sich für mich nicht wie ein akzeptables Sicherheitskonzept an.
-
Ist es aber, und wird es für sehr lange zeit sein.