Diskussion - Drive by Download

[Encoder]

Hallo
Es gibt ja anscheinend schon einige Gefahren durch Drive by Download. Man besucht eine Seite und ohne irgendwas zu tun, hat man sich Schadsoftware eingefangen.
Wenn was neues rauskommt liest man gern mal, dagegen kann man gar nichts tun und alle Browser sind davon betroffen usw.

So und jetzt mal eine blöde aber trotzdem interessante Frage. Blöd deswegen weil ich selbst programmiere und weiß wie schnell man mal was übersieht.

Ist das wirklich so unmöglich, einen Browser und Plugins für Flash oder so, so dicht zu machen dass da nichts mehr rein kann?
Hauptsächlich geht es dabei wahrscheinlich um Speicherüberläufe, oder wo lauern diese Gefahren?
Sind das wirklich so unübersichtlich viele Stellen im Code, dass man die relevanten Abschnitte nicht durchsehen und auf Lücken prüfen kann?

Ich hab interessehalber ein bisschen gesucht, aber so wirkliche tiefergehende Infos waren bisher nicht dabei. Wer mag dazu etwas sagen oder kennt Quellen?

[Martin Rettberg]

Hi,

Die meisten nativen Browserplugins sind bestimmt nicht ohne Grund Closed Source ;)
Leider verstehen es die jeweiligen Hersteller der Plugins immernoch nicht, dass durch Obscurity eben keine Security erreicht werden kann.
Mozilla arbeitet zur Zeit wahrscheinlich genau deshalb an einer PDF-Alternative in JavaScript!
Den Code davon habe ich mir mal spaßeshalber runtergeladen und durch wc gejagt, mit folgendem Ergebnis:

  
mret@abakus ~/pdf.js/src $ wc -cl *.js utils/* images/*  
    716   24654 api.js  
    453   14225 bidi.js  
   1465   49988 canvas.js  
    119    6994 charsets.js  
   6948  510375 cidmaps.js  
   1367   76836 colorspace.js  
    590   19938 core.js  
    665   27100 crypto.js  
   1301   48656 evaluator.js  
   6775  239552 fonts.js  
    893   26851 function.js  
   4226  100243 glyphlist.js  
    464   16011 image.js  
   1078   39836 jbig2.js  
   1890   69663 jpx.js  
     97    3285 metadata.js  
   2961   57850 metrics.js  
    870   27843 obj.js  
    671   20673 parser.js  
    382   11482 pattern.js  
     32    1102 pdf.js  
   2363   81385 stream.js  
    723   21495 util.js  
    371   11301 worker.js  
     49    1250 worker_loader.js  
    312    5288 utils/cffStandardStrings.js  
    425   12974 utils/fonts_utils.js  
     41    3263 images/logo.svg  
  38247 1530113 total  

Allein diese Implementierung ist also über eine Million Bytes groß und hat fast 40000 Codezeilen.
Das Ausmaß des selben Codes in Sprachen wie C oder C++ kann man ja abschätzen!
Ich sehe das Problem der Drive-by Downloads allerdings etwas gelassener als du - solange man mit eingeschaltetem NoScript||ScriptSafe surft und die jeweiligen Plug-ins per "Click to play" (im Chrome in den Standardeinstellungen zu finden, bei Firefox 17 unter about:config > plugins.click_to_play) sollte man auf der sicheren Seite sein.
Wenn du dich wirklich für Sicherheitesthemen interessierst, sei dir noch media.defcon.org empfohlen.
Dort findest du, meist sehr komödiantisch dargestellt, sehr viel Hintergrundwissen über diese Sachen.

Martin

[Encoder]

solange man mit eingeschaltetem NoScript||ScriptSafe surft und die jeweiligen Plug-ins per "Click to play" (im Chrome in den Standardeinstellungen zu finden, bei Firefox 17 unter about:config > plugins.click_to_play) sollte man auf der sicheren Seite sein.

Ich nutze Noscript, das blockt erst mal schon einiges. Man weiß aber trotzdem noch nicht ob eine vertraute Webseite oder ein bewusst geöffnetes pdf plötzlich befallen ist.
Und wenn man auf eine Seite geht die Flash oder irgendwas nutzt und die dann nur noch sch... aussieht, das ist auch nicht unbedingt schön. Cooler wäre es, wenn man sowas wie Noscript gar nicht bräuchte, stattdessen die Seiten im Netz so sehen könnte wie sie gedacht sind und trotzdem nicht ständig in Angst leben müsste.

Ich hab kein aktuelles Problem mit dieser Thematik. Ich wundere mich einfach nur wie viele solcher "offener Tore" es in einem Programm wirklich gibt und ob es wirklich sooo unmöglich ist die zu stopfen.
Beispiel Browser. Ich rechne mit sehr vielen Codezeilen. Aber ich tippe* einfach mal die Anzahl der Stellen wo tatsächlich etwas von außen reinkommt und schaden kann, ist ja doch ziemlich begrenzt. Und dort wiederum sind die Möglichkeiten von Schädlingen auch begrenzt. Wenn ich millionenfach benutzte Software entwickle, wär das doch das erste wo ich Spezialisten hinsetze die das ganze durchchecken.

*heißt: ich weiß es nicht, daher dieser Thread :-)

Mir fehlt zB die Idee was alles ausgenutzt werden kann. Schreiben in fremden Speicherbereichen, wenn da steht "es kommen 100 Bytes" und dabei sinds 1000.
JavaScript sollte eigentlich doch längst in einer Sandbox laufen die auch wirklich eine ist. Die ganzen Plugins sowieso, sollte man denken.

Ich guck mir mal den Link an, danke dir!

[Der Martin]

Hallo,

Ich nutze Noscript, das blockt erst mal schon einiges. Man weiß aber trotzdem noch nicht ob eine vertraute Webseite oder ein bewusst geöffnetes pdf plötzlich befallen ist.

das ist wohl wahr, deswegen sollte Vertrauen auch nicht bedeuten, dass man sämtliche Vorsicht aufgibt.

JavaScript sollte eigentlich doch längst in einer Sandbox laufen die auch wirklich eine ist.

Das tut es AFAIK wohl.

Die ganzen Plugins sowieso, sollte man denken.

Nein, die nun gerade nicht. Browser-Plugins bestehen aus Code, der mit dem Seiteninhalt interagieren kann, und auf der anderen Seite mit denselben Rechten und Privilegien läuft wie der Browser selbst. Alles, was dem Programm "Browser" gestattet ist, ist dem Plugin damit automatisch auch gestattet. Mit anderen Worten: Ein Plugin hat alle Möglichkeiten, die auch dem Benutzer offenstehen, der den Browser aufgerufen hat. Weitere Netzwerkzugriffe mit beliebigen Protokollen, Zugriffe auf das Filesystem, Mails versenden, Verändern von Einstellungen ...
Und wenn das Plugin dann noch eine Schnittstelle zu Javascript hat, ist plötzlich auch Javascript nicht mehr ganz so harmlos, wie es eigentlich sein sollte.

Ciao,
 Martin

[Martin Rettberg]

Hi,

solange man mit eingeschaltetem NoScript||ScriptSafe surft und die jeweiligen Plug-ins per "Click to play" (im Chrome in den Standardeinstellungen zu finden, bei Firefox 17 unter about:config > plugins.click_to_play) sollte man auf der sicheren Seite sein.
Ich nutze Noscript, das blockt erst mal schon einiges. Man weiß aber trotzdem noch nicht ob eine vertraute Webseite oder ein bewusst geöffnetes pdf plötzlich befallen ist.

Das stimmt natürlich, aber das weiß man ja bei heruntergeladener Software auch nicht (es seidenn es ist Open Source und man studiert den Code).

Und wenn man auf eine Seite geht die Flash oder irgendwas nutzt und die dann nur noch sch... aussieht, das ist auch nicht unbedingt schön.

Ich hab schon seit Ewigkeiten keine Seite mehr gesehen, die nur per Flash navigierbar ist... und wenn doch, dann hab ich sie sicher direkt wieder verlassen ;)

Beispiel Browser. Ich rechne mit sehr vielen Codezeilen.

Die Codezeilen von Firefox wollte ich in meinem vorigen Post auch zählen lassen, habs dann aber doch lieber gelassen als das entpacken des Tarballs schon fast 'ne Minute gedauert hat :D

Wenn ich millionenfach benutzte Software entwickle, wär das doch das erste wo ich Spezialisten hinsetze die das ganze durchchecken.

Es gibt halt immer diesen einen kleinen edge-case an den man nicht denkt, weil solche Fälle meistens total absurd sind..

Mir fehlt zB die Idee was alles ausgenutzt werden kann. Schreiben in fremden Speicherbereichen, wenn da steht "es kommen 100 Bytes" und dabei sinds 1000.

Eine Lücke ist bereits das HTTP-Protokoll an sich.
Dein Browser ist im guten Glauben, dass er gerade HTTP spricht und in Wirklichkeit schickt er einen SMTP-Request raus.
So eine Cross Protocol Scripting-Attacke wird von Spammern schon seit Ewigkeiten benutzt (Cert listet diese Schwachstelle ja auch schon seit 2001)!
Das Cert ist übrigens genau die Adresse, die du wahrscheinlich gesucht hast.
Dort sind alle bekannten und relevanten Schwachstellen in einer Datenbank aufgelistet.

Martin