Florian Weimer wrote: > Kristian Koehntopp <[EMAIL PROTECTED]> writes: > > On Sun, Sep 21, 2003 at 04:47:44PM +0200, Florian Weimer wrote: > >> Bei ASN.1 und den Encoding Rules hat man *eigentlich* die Chance, dass > >> der Encoder solche Fehler nicht produziert. > > > > �h. Ja. > > Ich erw�hnte schon, da� es an brauchbaren Implementierungen mangelt. > Deswegen mu� aber nicht das Konzept an sich unbrauchbar sein, nur > etwas unpraktikabel.
Als Seitenlinie unserer Diskussion �ber ASN.1 bzw. bin�res XML und "die Folgen": ----- http://www.heise.de/newsticker/data/pab-30.09.03-000/ Sicherheitsl�cher in OpenSSL "... Diese Zertifikate sind nach der Abstract Syntax Notation (ASN.1) aufgebaut und enthalten unter anderem die Namen des Austellers (Issuer) und der Eigent�mers (Common Name, CN). Manipuliert ein Angreifer bestimmte ASN.1-Elemente, kann er damit den Dienst zum Absturz bringen oder beliebigen Code auf den Stack schreiben und ausf�hren. ..." ----- Disclaimer: Ich habe mir die Patches nicht angesehen und kenne die Natur der Fehler nicht. Die folgenden Gedanken sind unabh�ngig von diesem konkrekten Problem. Das Problem sind nie die korrekten Daten, sondern die defekten. In ASN.1-Anwendungen kommt neben dem Bin�rformat noch was anderes dazu: Widersprichlichkeit durch �berspezifikation. Wie bereits erkl�rt, bestehen einige ASN.1-Codierungen im Prinzip aus (Typkennung, L�nge, Nutzdaten)-Tupeln. Auf diese Weise kann ein lesendes Programm, das Typkennung nicht kennt, L�nge Bytes �berspringen und hinter den Daten wieder aufsetzen. ASN.1 kennt jedoch auch Containertypen, etwa Arrays oder Structe. Hier sind die Nutzdaten selber wieder (Typkennung, L�nge, Nutzdaten)-Sequenzen. Es ist nun m�glich, defekte ASN.1-Pakete zu konstruieren, in denen die Summe der L�ngen der Daten in einem Array nicht mit der angegebenen Gesamtl�nge des Containers �bereinstimmt. Das geht nur, weil ASN.1 an alles und jedes L�ngen dranschreibt, anstatt L�ngen wie nicht-bin�res XML implizit klar zu machen. Array 12 Byte <- hier 10 oder 14 Byte angeben Integer 4 Byte 3 Integer 4 Byte 0 Integer 4 Byte 2 Stimmt die L�ngenangabe im Array nicht, k�nnte ein Reader, der den Array-Typ nicht erkennt ("unwissender Reader", der ohne DTD auf wohlgeformten ASN.1 arbeitet), auf der L�ngenangabe oder dem Inhalt des letzten Integer wiederaufsetzen, w�hrend ein Reader, der den Array-Typ kennt, die Integer einzeln parsed. In XML ist die L�nge wissenden und unwissenden Lesern sofort und gleicherma�en klar: <array> <integer>3</integer> <integer>0</integer> <integer>2</integer> </array> Ein wissender ASN.1-Reader kann sich auch nicht auf die L�ngenangabe im ASN.1-Record verlassen, um Speicher zu bestellen. St�nde dort "10 Byte" und er w�rde dann 3 Integer a 4 Byte lesen, h�tte er zu wenig Speicher bestellt und w�rde Strukturen �berschreiben. St�nde dort eine sehr gro�e Zahl oder eine negative Zahl bestellt er entweder zu viel Speicher oder haut sich wegen Vorzeichen�berlaufs mit negativen Offsets sonstwo in die Pampa. Auch dieses Problem tritt mit nicht-bin�rem XML prinzipbedingt nicht auf, weil die Codierung wiederspruchsfrei ist (Beachte jedoch, da� <array len="3" /> uns zu demselben Problem in XML f�hrt wie in ASN.1 - len="3" ist beim Parsen keine Angabe, der ein Parser vertrauen k�nnte. Es interessiert nur, wie viele Elemente das <array/> tats�chlich enth�lt, alles andere ist �berspezifikation und ein Quell von Widerspr�chen!) Der "Vorteil" bei ASN.1 ist, falls man den L�ngenangaben vertraut, da� man das Array vorallozieren und dann einmalig durchlesen kann: Bestelle 12 Byte und haue dann dreimal ein Integer da rein, es wird schon stimmen (Das kann man jedoch billiger haben, siehe unten). Vertraut man den L�ngenangaben nicht, ist ASN.1 schwieriger zu parsen als nicht-bin�res XML: Auch hier mu� man bei Containern sich den Anfang merken, den Container durchlesen um die Gr��e zu bestimmen, Speicher bestellen, den Container tats�chlich einlesen und dann weiter machen. Anders als bei nicht-bin�rem XML mu� man jedoch noch damit rechnen, da� die Offsets bei verschachtelten Containern defekt sind und ggf. Backtracken. Ein embedded Endger�t gewinnt mit keiner Datenstruktur. Hier will man 00 00 00 17 00 00 00 03 00 00 00 00 00 00 00 02 �bertragen. "17" ist eine "Message Type 17", von der das Endger�t dann implizit wei� "12 Byte Nutzdaten" oder "kenn ich nicht, gib auf, signalisiere Error", es dann statisch 12 Byte Speicher bereitstellt und die Daten da ohne Parsen reinmapped. Das hat aber mit ASN.1 noch mit XML was zu tun, sondern ist so primitiv wie irgend m�glich. Es ist auch am wenigsten fehleranf�llig, weil qmail-like die Datens�tze genau gar nicht geparsed werden. Mithin genau das, was man im Bereich embedded eigentlich will. Andere Protokolle haben diese Problemfamilie auch geerbt - im Prinzip ist jedes Tunnelprotokoll f�r solche �berspezifikationsprobleme anf�llig. Wir haben solche Probleme in der Vergangenheut an so unwahrscheinlichen Stellen wie in SMB beobachten k�nnen. Hier werden DCE RPC Parameter in SMB Bl�cken in TCP/IP Paketen eingepackt und jede Kapselungsebene hat ihre eigene L�ngenangabe mitgebracht. Es widersprechen sich unterschiedliche SMB-Implementierungen (read: Windows-Dialekte und Samba) darin, ob und wo Padding mit in die L�nge eingeht oder nicht. Dies kann im Zusammenhang mit Memoryallokatoren, die L�ngenbytes aus den eingelesenen Daten glauben, zu interessanten Effekten f�hren... Hat sich jemand den OpenSSL-Patch einmal angesehen und kann erkl�ren, welche Problemklasse hier getriggert worden ist? Kristian
