uIP (Tool?) und CVE

[gh-baden]

https://www.heise.de/news/Nach-Amnesia-33-Forscherteam-warnt-vor-neun-weiteren-Luecken-in-TCP-IP-Stacks-5051555.html

(CVE-2020-27634)

mEin LaN iST UNsiChEr!!!11

[czietz]

Ich habe gerade nachgesehen: Der FreeMiNT-TCP/IP-Stack und der STinG-Stack haben dieselbe "NUMBER:JACK"  Schwachstelle. Ob ich wohl auch eine CVE-Nummer bekomme? Ob ich wohl auch einen eigenen Heise-Artikel bekomme? 

Aber ohnehin sollte man einen Atari (oder ähnlich alte Hardware) nicht in einem öffentlich zugänglichen Netz betreiben.

[Arthur]

Aber ohnehin sollte man einen Atari (oder ähnlich alte Hardware) nicht in einem öffentlich zugänglichen Netz betreiben.

Ist leider so... nichts ist für die Ewigkeit.

[gh-baden]

Ich habe gerade nachgesehen: Der FreeMiNT-TCP/IP-Stack und der STinG-Stack haben dieselbe "NUMBER:JACK"  Schwachstelle. Ob ich wohl auch eine CVE-Nummer bekomme? Ob ich wohl auch einen eigenen Heise-Artikel bekomme? 

Aber ohnehin sollte man einen Atari (oder ähnlich alte Hardware) nicht in einem öffentlich zugänglichen Netz betreiben.

Wenn du keine „eingetragene“ CVE-Nummerierungs-Institution bist, mußt du wo anklopfen, damit eine vergeben wird, tut mir leid

(BTW: ein Atari MegaST mit STING und 10 MBit/s Direktverbindung ins Internet, also kein NAT, keine Fritzbox, public IPA, hat er 3d lang gut überlegt, nichts abgestürzt. Und ja, das war ein kontrolliertes Setup.)

[mfro]

Ich habe gerade nachgesehen: Der FreeMiNT-TCP/IP-Stack und der STinG-Stack haben dieselbe "NUMBER:JACK"  Schwachstelle.

Interessant. Nicht dass ich jetzt vor Angst zittern würde - aber ist das tatsächlich bei MiNT auch so?

Ich habe das so verstanden, dass die "NUMBER:JACK"-Schwachstelle auf der "Erratbarkeit" der ISN ("Initial Sequence Number") bei TCP-Verbindungen beruht. Wenn ich also eine ISN kenne (von einer früheren TCP-Verbindung) und die Implementierung des PRNg's (oder welchem Algorithmus auch immer), der die nächste erzeugt, kann ich TCP-Pakete abfangen und durch gültige eigene ersetzen.

Bei MiNT werden die ISNs über get_random_bytes() erzeugt. Und die kommen - wenn ich das richtig interpretiere - zumindest bei >000 Kerneln von /dev/random, also einem "echten" RNG, der aus einem Entropie-Pool gespeist wird (die "kleinen" Kernel haben das aus Performancegründen nicht).

Abgesehen davon, dass meine MiNT-Netzwerkpakete haben darf, wer will: vielleicht bin ich (wie in letzter Zeit anscheinend öfter - you know what I mean ) noch nicht ganz wach, aber das sollte doch eigentlich "wasserdicht" sein, oder?
 

[czietz]

Bei MiNT werden die ISNs über get_random_bytes() erzeugt.

Werden sie? Ich sehe diese Funktion:
https://github.com/freemint/freemint/blob/9d9dfd610fdd7bbaa08a5cb74e3fcd840374afb0/sys/sockets/inet4/tcputil.c#L19-L29
... und die ist überhaupt nicht zufällig: isn += 999;

Und übrigens: Reine Zufallszahlen als ISN wären auch nicht die beste Idee. Es gibt Netzwerkstacks, die verlassen sich darauf (unter bestimmten Umständen) bei sukzessiven Verbindungen zur selben Gegenstelle monoton steigende initiale Sequenznummern zu bekommen.

EDIT: Und falls Du Dich fragst: ja, diese Funktion oben (tcp_isn()) ist auch die, die im Netzwerkstack aufgerufen wird. FreeMiNT hat zwar sys/random.c von Linux übernommen, aber nutzt die dort sogar extra bereitgestellte Funktion für sichere ISNs nicht: secure_tcp_sequence_number() wird nicht aufgerufen.

[mfro]

... FreeMiNT hat zwar sys/random.c von Linux übernommen, aber nutzt die dort sogar extra bereitgestellte Funktion für sichere ISNs nicht: secure_tcp_sequence_number() wird nicht aufgerufen.

Tja, genau diese Funktion habe ich im festen Glauben angeschaut, dass Sie auch aufgerufen würde.

Immerhin liesse sich - so man denn wollte  - die Sache relativ einfach reparieren.

[czietz]

Immerhin liesse sich - so man denn wollte  - die Sache relativ einfach reparieren.

"Relativ" ist relativ. Es ist nicht mit einem Austausch des Funktionsaufrufs getan. sys/random.c ist Teil des MiNT-Kernels, aber der Netzwerkstack ist ein Kernel-Modul. Module können nur Kernel-Funktionen über eine API aufrufen und secure_tcp_sequence_number()  ist da nicht enthalten. Änderungen der Kernel-Modul-Schnittstelle verursachen immer einen gewissen Aufschrei.

Aber zur Relevanz der Sicherheitslücke eine Erklärung, worum es bei erratbaren initialen Sequenznummern überhaupt geht: Sie erlauben, den Absender zu "spoofen", d.h. sich als jemand anderes auszugeben.

Nehmen wir an, Server Alice ist so konfiguriert, dass sie Client Bob alleine aufgrund von dessen IP-Adresse blind vertraut. D.h. Bob darf ohne Authentifizierung Kommandos an Alice schicken. Dann ist es für Angreiferin Eve attraktiv, sich als Bob auszugeben. Eve sendet also eine Anforderung einer TCP-Verbindungsaufnahme (SYN-Paket) an Alice, fälscht aber den Absender, sodass es aussieht, als käme es von Bob. Alice quittiert den Wunsch (SYN/ACK-Paket), aber diese Antwort bekommt Eve nicht zu sehen, denn Alice schickt sie ja an den scheinbaren Absender Bob. Diese Antwort enthält Alices initiale Sequenznummer. Wenn Eve nun diese Nummer raten kann, kann sie Alices Antwort wiederum in Bobs Namen quittieren (ACK-Paket) und eine TCP-Verbindung steht, bei der Eve vortäuschen kann, sie sei Bob. Diese Verbindung ist nur unidirektional (Eve -> Alice), denn Alices Antworten gehen ja an den unbeteiligten Bob und sind somit für Eve unsichtbar. Aber das kann ja reichen, um irgendein Kommando in Bobs Namen zu schicken. Unabhängig von dieser Sicherheitslücke ist es meiner Ansicht aber gefährlich, einem Host alleine aufgrund seiner IP-Adresse zu trauen.

Nun gilt für das uip-Tool: Es lässt sowieso jeden ohne Authentifizierung rein. D.h. man hat keinen Vorteil davon, dass man einen Absender "spooft". (Außer vielleicht, um Spuren zu verwischen.) Kurzum: uip-Tool sollte sowieso nicht in einem offenen/nicht-vertrauenswürdigen Netzwerk betrieben werden. Ich vermute auch, dass nicht sehr viele Server mit STinG als Stack betrieben werden. Am ehesten kann ich mir das tatsächlich noch bei MiNTNet vorstellen, aber auch hier gibt es vermutlich weit gravierendere Sicherheitslücken als dieses ISN-Problem, weshalb ich auch hier davon abraten würde, Services ungeschützt ins Netz zu hängen.

Eine letzte Anmerkung zu den Sicherheitsforschern: Es verwundert, wie viel Aufsehen sie erregen; Heise-Artikel inklusive. Die haben ja keine neue Lücke gefunden; das Problem ist seit mindestens den 1990ern bekannt. Sie haben bloß in diversen Open-Source-Embedded-IP-Stacks nachgesehen, also reine Fleißarbeit. (Die natürlich auch jemand machen muss, klar.)

[mfro]

Eine letzte Anmerkung zu den Sicherheitsforschern: Es verwundert, wie viel Aufsehen sie erregen; Heise-Artikel inklusive. Die haben ja keine neue Lücke gefunden; das Problem ist seit mindestens den 1990ern bekannt. Sie haben bloß in diversen Open-Source-Embedded-IP-Stacks nachgesehen, also reine Fleißarbeit. (Die natürlich auch jemand machen muss, klar.)

Ganz abgesehen davon, dass es im Netz ja - bei weitem - nicht nur TCP-Verbindungen gibt (die einem über RFC's erschöpfend dokumentierten) Standard folgen.

Viele "moderne" (insbesondere Kommunikations- und Muldimedia-) Anwendungen verwenden z.B. statt TCP UDP-Verbindungen (weil - vermeintlich oder tatsächlich) schneller oder besser geeignet und verwenden statt der (dokumentierten) TCP-Mechanismen zur Verbindungssicherung selbst "erfundene",  denen zumindest ich persönlich zum Großteil schlicht nicht abnehme, dass sie (Software von möglichst effizienten Programmierern aus sonstwoher) "wasserdichter" sind. Da guckt bloß keiner hin...

[czietz]

Und zur anderen im Heise-Artikel genannten Möglichkeit "Angreifer könnten sich etwa unbemerkt einklinken, um eigene Datenpakete einzuschmuggeln". Hier sind die Voraussetzungen etwas spezieller, da der Angreifer nicht die initiale, sondern die gerade aktuelle Sequenznummer erraten können muss.

Angenommen ein (unverschlüsseltes) Protokoll, bei dem sich Bob zu Beginn einer Verbindung bei Alice mit einem Passwort authentifiziert und dann die Verbindung offen lässt, um bei Bedarf Kommandos zu schicken. Angenommen, Eve schafft es (z.B. durch einen Denial-of-Service), dass sich Bob neu verbinden muss, und angenommen, Eve kann Bobs initiale Sequenznummern raten, und angenommen, Eve kann auch Bobs (i.d.R. zufällige) Quellportnummer raten, und angenommen, Eve kann raten, wie viele Daten von Bob bereits übertragen wurden (z.B. weil das Passwort immer N Bytes lang ist), kann Eve danach die gültige Sequenznummer berechnen und ein Paket mit der passenden Sequenznummer, der passenden Quellportnummer und einem gefälschen Absender mit einem Kommando schicken, das für Alice aussieht, als käme es aus der bestehenden und authentifizierten Verbindung mit Bob.

Wie man sieht, sind recht viele "angenommen" in der Erklärung. Sicherlich gibt es unter den Abermillionen IoT-Geräten welche, bei denen sich so ein Angriff konstruieren lässt, aber umgekehrt gilt auch, dass nicht jedes System mit erratbaren ISN gleich ge-"pwnt" werden kann.