Sicherheitslücken in TCP/IP-Stacks

100Ω W. schrieb:
> Als wie gefährlich würdet ihr die Lücke beurteilen?

Eher irrelevant, zumindest was uIP betrifft.
Die anderen Stacks kenne ich nicht.

Würde gerne wissen wie bei uIP eine Remote Code Execution auf einem AVR 
ausgeführt werden soll. Vor allem wenn jetzt zum Beispiel nicht der 
Befehl Store Program Memory im Programm (weder Applikation noch 
Bootloader) verwendet wird. Die AVR's haben ja meines Wissens ja eine 
Harvard Architektur.

Wenn der Befehl Store Program Memory verwendet werden würde, dann könnte 
ich es ja noch verstehen, dass hier die Rücksprungadressen manipuliert 
werden... Aber ohne diesem Befehl im Programm? Übersehe ich hier etwas?

Johannes K. schrieb:
> Würde gerne wissen wie bei uIP eine Remote Code Execution auf einem AVR
> ausgeführt werden soll.

Im Prinzip genauso wie bei stinknormalen PCs mit nicht ausführbaren 
Datenbereichen dank NX-Bit: 
https://en.wikipedia.org/wiki/Return-oriented_programming

Allerdings steigt das Potential ausnutzbaren Codes mit der Grösse des 
Codes. Bei einigen KB ist das schwieriger als bei einigen MB.

(prx) A. K. schrieb:
> Johannes K. schrieb:
> Im Prinzip genauso wie bei stinknormalen PCs mit nicht ausführbaren
> Datenbereichen dank NX-Bit:
> https://en.wikipedia.org/wiki/Return-oriented_programming
Das habe ich ja mit "Manipulation" der Rücksprungadressen gemeint. Also 
ein Art Return-to-libc.

Weil eigentlich wird hier ja "nur" bei einem fehlerhaften Programm 
(keine Überprüfung der Länge der Eingabedaten) der Buffer bis zur der 
jeweiligen Rücksprungadresse der Subroutine überschrieben. Mag, 
vielleicht jetzt etwas Laienhaft erklärt sein. Zu mindestens hab ich so 
laut dem Buch "Hacking - Die Kunst des Exploits" gelernt.

OT
Wollte das hier schon immer mal fragen. Gibt es auch eine Architektur 
bei dem der Datenstack und der Stack mit den Rücksprungadressen getrennt 
sind? Also ein Hardwareschutz. Wäre meine Idee für eine neue Architektur 
um das ganze etwas Einhalt zu gebieten. Man hat zwar ein paar mögliche 
Einschränkungen...aber irgendwie müsste man eine Architektur ja dadurch 
so einigermaßen sicher bekommen können.

EDIT
Hat wer Zeit um eine neue Architektur zu designen, sollte es solche 
ähnliche Architektur noch nicht geben? Zuerst mal in VHDL? Ich wäre 
dabei. :)

Johannes K. schrieb:
> Gibt es auch eine Architektur
> bei dem der Datenstack und der Stack mit den Rücksprungadressen getrennt
> sind?

Der IAR C Compiler für AVR trennt Returnstack und Datenstack. Sicherlich 
nicht aus Sicherheitsgründen, sondern vmtl weil eine atomare 
Manipulation des Stackpointers bei AVRs umständlich aber bei Interrupts 
unumgänglich ist. Das ist ein Designfehler der AVRs.

Manche kleinen µCs haben einen Hardware-Stack. Manche µCs tun sich 
überhaupt schwer mit Datenstacks und verwenden deshalb normalerweise 
keinen, statt dessen statische Daten für lokale Variablen und Parameter, 
was reentrant code erschwert (z.B. 8051).

Johannes K. schrieb:
> Würde gerne wissen wie bei uIP eine Remote Code Execution auf einem AVR
> ausgeführt werden soll.

evtl. über "DNS cache poisioning": Bieg den Firmware-Update-Server um, 
wenn das Gerät self-updates über's Internet macht (und die nicht nochmal 
gesondert signiert sind)

Ansonsten ist das für viele Angriffe garnicht wichtig, da reicht es wenn 
du über den Angriff ein paar Bytes am Datenstack/globale Variablen 
verstellen kannst.

Wenn der IP-Stack dann z.B. statt nur Einem gleich 0xFFFFFFFF ACK Pakete 
raussendet, womöglich noch an eine frei überschriebene Ziel-IP, dann ist 
das ein perfekter DDoS-Multiplikator.
Ganz ohne Fremdcode-Ausführung, ohne RoP, und ohne dass getrennte 
Daten/Return-Stacks helfen würden.

Naja, bei uIP wird außerdem ein Teil des TCP/IP-Stacks in die Anwendung 
ausgelagert (z.B. Retransmissions), da kommt es auf einen Bug im Stack 
auch nicht mehr an.

Mit der Verbreitung von IoT wird es ohnehin keinen Mangel an 
verwundbaren Geräten geben und da erst die Massenproduktion 
fast-identischer Produkte die IoT-Geschäftsmodelle überhaupt 
ermöglicht...