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.)