Software > Coding

uIP (Tool?) und CVE

<< < (2/2)

czietz:

--- Zitat von: mfro am Do 11.02.2021, 06:09:08 ---Bei MiNT werden die ISNs über get_random_bytes() erzeugt.

--- Ende Zitat ---

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:

--- Zitat von: czietz am Do 11.02.2021, 08:03:27 ---... 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.

--- Ende Zitat ---

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:

--- Zitat von: mfro am Do 11.02.2021, 11:18:24 ---Immerhin liesse sich - so man denn wollte  - die Sache relativ einfach reparieren.

--- Ende Zitat ---

"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:

--- Zitat von: czietz am Do 11.02.2021, 11:53:23 ---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.)

--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[*] Vorherige Sete