https://www.intel.com/content/www/us/en/connected-home/ibc-smarthome-gateway-tech-brief.html
Customizable distribution based on the 3.x Linux Kernel provides a stable, open source supported development environment
Entweder Intel lügt hier schamlos in einem (Marketing-)Paper oder es gibt die Patches von Intel doch für verschiedene Kernel-Versionen. AVM verwendet hier ja einen 2.6.39(.3)-Kernel.
Interessant ist auch die Feststellung
Built-in hardware virtualization with Intel® Virtualization Technology (Intel® VT) and local storage makes it easy for service providers to add new revenue streams through additional IoT services such as home automation, home security, or energy management solutions. And because these services are added through a virtual machine, they can be dropped in on the fly, isolated from each other, and if a problem occurs, you only need to restart that VM and not the entire gateway.
Das klingt irgendwie so, als könnte auch der Puma6 bereits (vermutlich aber nur auf dem ATOM-Core) mit VMs umgehen. Beim GRX350 (in den 75x0-Modellen - und nein, die 7570 ist da ausdrücklich nicht eingeschlossen, es gilt also "x != 7") ist das ja vermutlich auch der Fall, wie die zwei Kernel in der Image-Datei vermuten lassen (da läuft wohl das komplette FRITZ!OS von AVM in so einer virtuellen Maschine und es gibt auch nur die eine zur Zeit - ist aber auch alles nur "Schlußfolgerung" anhand von bestimmten Anzeichen und kein gesichertes Wissen).
----------------------
Ansonsten habe ich den Hintergrund für den DoS-Angriff auf Puma6-Geräte damals so verstanden (muß nicht stimmen, was ich da hineininterpretiere), daß dabei durch viele (UDP-)Pakete (praktisch ohne nennenswerten Payload) auf dem Cable-
Modem (also noch vor der Software-Firewall von AVM, wo das Modem selbst noch gar nicht weiß, ob die eingehenden Pakete am Ende abgelehnt werden oder nicht) ständig weitere Lookup-Table-Einträge generiert werden (schon auf dem ARM-Core) und daß deren Verwaltung einen derartigen Overhead erzeugt, daß es bis zu einer gewissen Paket-Rate nur wachsende Verzögerungen gibt, aber danach kommt die Hardware dann gar nicht mehr hinterher ... und das ist eben schon mit einem "kleinen" Anschluß für den Angreifer zu bewerkstelligen, weil bereits ein recht niedriger Durchsatz (2-3 Mbps) ausreicht (und das auch mit "unsolicited packets" auf der WAN-Seite), um das Modem nahezu komplett aus dem Spiel zu nehmen.
Das kam ja Ende April 2017 auf (inkl. des Artikels in "The Register")... aber auch das kann kaum der Grund sein, warum AVM die 06.83 für die 6490 dann wieder zurückgezogen hatte. Die 06.63/06.64 verhielt sich dabei m.W. nicht anders und ich dachte eigentlich, daß auch dieses Problem mit der 06.84 (die ich immer noch nicht selbst installiert habe auf der 6490) jetzt vom Tisch wäre ... z.B. weil Intel da die Rate für neue UDP-"Connections" (und ja, ich weiß, daß UDP eigentlich verbindungslos arbeitet) limitiert. Das geht zwar nur für alle UDP-Pakete gleichzeitig (weil man deren Absenderadresse zu leicht fälschen kann, hilft es hier auch nicht wirklich, wenn man das nur pro Absenderadresse limitiert), aber als "real world scenario" gibt es eigentlich keinen Anwendungsfall (oder ich kenne einen solchen nur nicht), wo > 2.000 UDP-Pakete pro Sekunde mit wechselnden Adressen und Ports verwendet würden ... und die wechselnde Portnummer ist hier ja nach meinem Verständnis entscheidend, weil sonst kein neuer LUT-Eintrag erzeugt werden muß.
Wobei ich den Test hier (
https://www.unitymediaforum.de/viewtopic.php?p=382383#p382383) nicht nachvollziehen kann ... da wird dann dieser Traffic zur Adresse des Google-DNS erzeugt (also offensichtlich "von innen")? Das ist nicht das eigentliche DoS-Problem, was Ende April für den Puma6-Prozessor beschrieben wurde (da ging es um "unsolicited traffic" von außen, den man auch nicht blockieren kann bzw. wo die Firewall im eRouter dann zu spät dran ist, um den Overload zu verhindern) und wenn Du das ebenso getestet hast, ist es auch weniger verwunderlich, wenn das in der 06.84 noch vorhanden wäre.
Bei ausgehenden Verbindungen wird ja tatsächlich auch für die gesamte Dauer dieser "Verbindung" (wie lang bei AVM das UDP-Timeout ist, weiß ich gerade nicht und ich habe auch keine Lust, jetzt nachzuschauen - sollte sich über /proc/net/avm_pa/sessions leicht ermitteln lassen) ein Eintrag benötigt, damit das "connection tracking" funktioniert. Da dürfte von innen sogar noch viel schneller das Ende der Fahnenstange erreicht sein, was die max. Anzahl der PA-Sessions angeht. Die maximale Anzahl bei der 6490 waren da (iirc) 255 Sitzungen - ich weiß aber auch nicht mehr, wie sich das System da bei "overload" verhält und ob es diese "Sitzungen" nicht doch noch versucht zu starten und sie dafür in einer Warteschlange verwaltet.
Wobei ich auch hier wieder nicht verstehe, warum das die Verfügbarkeit des GUI und/oder anderer Dienste auf der Box selbst in Richtung LAN beeinflussen sollte ... die dürften gar nichts mit dem PA zu tun haben und - zumindest dort - auch nicht mit limitierten Ressourcen. Hier könnte aber auf der anderen Seite dann wieder das verwendete System eine Rolle spielen ... einerseits kann das System, auf dem das PHP-Skript läuft, an die Grenzen seiner Ressourcen kommen (auch eine Firewall, die hier ggf. läuft, muß da ja CT machen) oder es gibt wirklich am Ende ein Ressourcen-Problem auf der Box. Aber das können kaum TCP-Handle o.ä. sein (damit das GUI "unresponsive" wird oder auch TR-064) ... denn der gesamte Transit-Traffic dürfte auf dem TCP-Stack der Box selbst keine "Verbindungen" erzeugen und ein Overload des Prozessors kann ich mir mit 5.000 pps auch nicht so richtig vorstellen ... höchstens noch ein Deadlock irgendwo im IP-Stack, wenn auf freie PA-Sessions gewartet werden sollte oder auch eine Priorisierung von Transit ggü. lokalen Requests.
Der "DoS-Test" mit ausgehenden Verbindungen bringt also nichts ... das muß schon von außen an die eigene öffentliche IP-Adresse gesendet werden. Von innen sollte man mit einem ähnlichen Szenario tatsächlich so ziemlich jeden beliebigen Router in die Bredouille bringen können ... spätestens dann, wenn ihm die Portnummern (auf der WAN-Seite) für das NAT ausgehen.
Ob der dann gleich die Pakete verwirft (ggf. mit passender ICMP-Nachricht an den Absender) oder die Requests irgendwo "queued" in der Hoffnung, daß es innerhalb der Timeout-Zeit des Absenders noch freie Ressourcen geben könnte um eine neue Session zu kreieren, wird vermutlich von verschiedenen Herstellern auch unterschiedlich gehandhabt. Wobei "netfilter" (sicherlich von den meisten Nicht-AVM-Geräten verwendet für die Router-Firewall) meines Wissens beim Erreichen des Wertes in "net.ipv4.netfilter.ip_conntrack_max" dann einfach droppt und das entsprechend protokolliert (ip_conntrack: table full, dropping packet.).
