Linux TCP/IP Lücke gefunden ist AVM auch Betroffen?

TCHAMMER

Neuer User
Mitglied seit
24 Mai 2009
Beiträge
85
Punkte für Reaktionen
12
Punkte
8
Entwickler von Netflix haben eine Lücke in der TCP Sack Verarbeitung gefunden wo bestimmte Pakete das System zum Abstürzen bzw. bei Aktuelleren Kernel Versionen verlangsamen kann. Es sind alle Kernel ab Version 2.6.29 betroffen.

Hier ist diese Lücke beschrieben. Und Hier ist der Golem Artikel dazu.


edit:

AVM Prüft die Situation nachdem es schon auf deren Facebook Seite Posts zu dieser Lücke gab.
 
Zuletzt bearbeitet:

Whoopie

Aktives Mitglied
Mitglied seit
19 Okt 2004
Beiträge
828
Punkte für Reaktionen
4
Punkte
18
Welche Antwort genau erwartest du hier im Forum? Hast du schon eine Netzwerkanalyse bei deinem Router durchgeführt? Vielleicht selbst einem Tool wie Scapy TCP SACKs generiert und an den Router geschickt und dann geschaut, ob im dmesg ein Kernel BUG_ON steht?

Ausserdem ist die Wahrscheinlichkeit geringt, dass AVM diese Lücke selbst entdeckt hat, sie in ihren kompilierten Kernel gepackt hat und die Lücke nicht upstream gemeldet hat. Dir ist bewusst, dass die FritzBox-FW closed-source ist, oder?
 
Zuletzt bearbeitet:

TCHAMMER

Neuer User
Mitglied seit
24 Mai 2009
Beiträge
85
Punkte für Reaktionen
12
Punkte
8
Wo steht denn bitte das AVM die Lücke entdeckt hat die frage war nur ob sie von dieser Lücke auch betroffen sein könnte ? Hast du eine Netzwerkanalyse durchgeführt ? Wenn ja dann kannst du ja deine Ergebnisse gerne mit uns teilen.

Die 7590 verwendet den Kernel 3.10.xxx und dieser gehört anscheinend zu den Betroffenen Kernel Versionen.

Wenn AVM den Kernel selbst pflegt obwohl es schon EOL ist dann gibts ja keine Probleme und AVM wird die nötigen Patches einspielen. Einen Aktuelleren Kernel können Sie aus Technischen Gründen leider nicht nutzen.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,045
Punkte für Reaktionen
718
Punkte
113
Ich denke mal, man muß kein Prophet sein, um vorhersagen zu können, daß der geroutete Traffic schon mal nicht betroffen ist (zumindest nicht von CVE-2019-11477). Die Verarbeitung der TCP-Pakete findet ja auf dem jeweiligen Host statt und die FRITZ!Box leitet nur die Pakete (i.d.R. auch noch "in Hardware"), die zu einer TCP-Verbindung gehören, zum jeweiligen LAN-Client weiter.

Wenn die Box also angreifbar sein sollte (was sie vermutlich ist:
Code:
[email protected]:~ $ sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 1
[email protected]:~ $
), dann auch nur im Rahmen von TCP-Verbindungen, die bei ihr beginnen oder enden. Dafür kämen auf der LAN-Seite sicherlich deutlich mehr Dienste in Frage, als auf der WAN-Seite.

Nur braucht es dafür vermutlich nicht mal unbedingt diese "TCP SACK PANIC", wie das Problem wohl genannt wird (manchmal geht einem die Panik halt auch auf den Sack) - da lassen sich vermutlich noch genug Lücken in den Diensten hinter den LAN-seitig offenen Ports finden, wenn man diese nur ausreichend ausdauernd mit "fuzzed/random data" bepflastert.

Gerade im Zuge des Mesh sind da jede Menge Daemons mit offenen (LAN-)Ports hinzugekommen - es wäre gelacht (bzw. ich würde ganz, ganz tief den Hut ziehen), wenn die tatsächlich alle so sicher sind im Verwerfen von ungültigen Paketen, daß man die Box von der LAN-Seite nicht mehr abschießen kann.

Da auch jede Menge Dienste über entsprechende Watchdog-Timer abgesichert sind:
Code:
[email protected]:~ $ cat /proc/avm/wdt
hdl= 3 dsl_monitor   pid 2541 triggered before:   5.400 s(avg  19.990 s) state: S cpu0 pgfault 0 oom_score 0
hdl= 3 dsl_monitor   pid 2553 triggered before:   5.400 s(avg  19.990 s) state: S cpu0 pgfault 0 oom_score 0
hdl= 4 avmnexusd     pid 2612 triggered before:   4.410 s(avg   9.930 s) state: S cpu0 pgfault 0 oom_score 0
hdl= 5 l2tpv3d       pid 2787 triggered before:   1.120 s(avg   9.940 s) state: S cpu1 pgfault 0 oom_score 0
hdl= 6 ctlmgr        pid 2920 triggered before:   0.560 s(avg   8.240 s) state: S cpu0 pgfault 8 oom_score 0
hdl= 6 ctlmgr        pid 2922 triggered before:   0.560 s(avg   8.240 s) state: S cpu0 pgfault 8 oom_score 0
hdl= 6 ctlmgr        pid 3568 triggered before:   0.560 s(avg   8.240 s) state: S cpu1 pgfault 8 oom_score 0
hdl= 6 ctlmgr        pid 3569 triggered before:   0.560 s(avg   8.240 s) state: S cpu1 pgfault 8 oom_score 0
hdl=15 upnpd         pid 2953 triggered before:   9.130 s(avg   9.960 s) state: S cpu1 pgfault 0 oom_score 0
hdl=15 upnpd         pid 3589 triggered before:   9.130 s(avg   9.960 s) state: S cpu1 pgfault 0 oom_score 0
hdl=15 upnpd         pid 3590 triggered before:   9.130 s(avg   9.960 s) state: S cpu1 pgfault 0 oom_score 0
hdl= 7 multid        pid 3038 triggered before:   6.570 s(avg   9.940 s) state: S cpu0 pgfault 3 oom_score 0
hdl= 8 ddnsd         pid 3200 triggered before:   1.900 s(avg   9.940 s) state: S cpu1 pgfault 0 oom_score 0
hdl= 9 pcpd          pid 3204 triggered before:   1.740 s(avg   9.940 s) state: S cpu0 pgfault 0 oom_score 0
hdl=10 wland         pid 3238 triggered before:  72.880 s(avg  90.180 s) state: S cpu0 pgfault 0 oom_score 0
hdl=11 dsld          pid 3363 triggered before:   6.700 s(avg   9.940 s) state: S cpu0 pgfault 1 oom_score 0
hdl=12 deviceinfod   pid 3430 triggered before:   4.280 s(avg   9.940 s) state: S cpu0 pgfault 0 oom_score 0
hdl=13 pbd           pid 3453 triggered before:  62.000 s(avg  80.090 s) state: S cpu1 pgfault 0 oom_score 0
hdl=14 telefon       pid 3512 triggered before:  82.800 s(avg  90.170 s) state: S cpu0 pgfault 0 oom_score 0
hdl=14 telefon       pid 3584 triggered before:  82.800 s(avg  90.170 s) state: S cpu0 pgfault 0 oom_score 0
hdl=16 voipd         pid 3592 triggered before:   5.210 s(avg   9.930 s) state: S cpu1 pgfault 0 oom_score 0
hdl=17 plcd          pid 3673 triggered before:   1.910 s(avg   9.930 s) state: S cpu1 pgfault 0 oom_score 0
hdl=18 usermand      pid 3680 triggered before:   0.120 s(avg   9.940 s) state: S cpu0 pgfault 0 oom_score 0
hdl=19 contfiltd     pid 3683 triggered before:   0.570 s(avg   9.930 s) state: S cpu1 pgfault 0 oom_score 0
hdl=20 meshd         pid 3685 triggered before:   0.100 s(avg   9.020 s) state: S cpu1 pgfault 0 oom_score 0
hdl=28 aha           pid 3820 triggered before:   7.160 s(avg  30.150 s) state: S cpu0 pgfault 0 oom_score 0
hdl=29 boxnotifyd    pid 3828 triggered before:   6.960 s(avg  80.090 s) state: S cpu0 pgfault 0 oom_score 0
hdl=30 run_clock     pid 4220 triggered before: 2717.540 s(avg 1680.000 s) state: S cpu0 pgfault 0 oom_score 0
hdl=21 log_server[3720] triggered before:   0.040 s(avg   9.960 s)
hdl=22 log_server[3724] triggered before:   0.020 s(avg  10.020 s)
hdl=23 log_server[3729] triggered before:   0.020 s(avg   9.950 s)
hdl=24 log_server[3734] triggered before:   9.960 s(avg   9.960 s)
hdl=25 log_server[3736] triggered before:   9.960 s(avg  10.020 s)
hdl=26 log_server[3738] triggered before:   9.980 s(avg   9.950 s)
hdl=27 log_server[3740] triggered before:   9.920 s(avg   9.960 s)
[email protected]:~ $
und deren Ableben dann i.d.R. auch zum Neustart des Systems führt, braucht man nur mal einen Blick in die Liste der "listening ports" werfen, wenn man gerne Geisterbahn fährt:
Code:
[email protected]:~ $ netstat -lutp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:51111           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:51112           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:8010            0.0.0.0:*               LISTEN      4205/shellinaboxd
tcp        0      0 localhost:1011          0.0.0.0:*               LISTEN      3512/telefon
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      4207/dropbear
tcp        0      0 localhost:8888          0.0.0.0:*               LISTEN      3512/telefon
tcp        0      0 :::55777                :::*                    LISTEN      2612/avmnexusd
tcp        0      0 :::49443                :::*                    LISTEN      2953/upnpd
tcp        0      0 :::5060                 :::*                    LISTEN      3592/voipd
tcp        0      0 :::5031                 :::*                    LISTEN      4317/capiotcp_serve
tcp        0      0 :::4711                 :::*                    LISTEN      -
tcp        0      0 :::49000                :::*                    LISTEN      2953/upnpd
tcp        0      0 :::139                  :::*                    LISTEN      3787/inetd
tcp        0      0 :::49200                :::*                    LISTEN      2953/upnpd
tcp        0      0 :::www                  :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::1012                 :::*                    LISTEN      3512/telefon
tcp        0      0 :::ftp                  :::*                    LISTEN      3787/inetd
tcp        0      0 :::8181                 :::*                    LISTEN      3683/contfiltd
tcp        0      0 :::domain               :::*                    LISTEN      3038/multid
tcp        0      0 :::ssh                  :::*                    LISTEN      4207/dropbear
tcp        0      0 :::8182                 :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::57719                :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::8183                 :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::8184                 :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::8185                 :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::8186                 :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::443                  :::*                    LISTEN      2920/ctlmgr
tcp        0      0 :::445                  :::*                    LISTEN      3787/inetd
tcp        0      0 fe80::2de:adff:febe:efca:5053 :::*                    LISTEN      3238/wland
udp        0      0 192.168.xxx.1:34604     0.0.0.0:*                           3798/aha
udp        0      0 localhost:323           0.0.0.0:*                           3792/chronyd
udp        0      0 0.0.0.0:bootps          0.0.0.0:*                           3038/multid
udp        0      0 192.168.xxx.1:43332     0.0.0.0:*                           2920/ctlmgr
udp        0      0 192.168.xxx.1:1900      0.0.0.0:*                           3798/aha
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           3798/aha
udp        0      0 192.168.xxx.1:1900      0.0.0.0:*                           2953/upnpd
udp        0      0 192.168.xxx.1:1900      0.0.0.0:*                           2920/ctlmgr
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           2953/upnpd
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           2920/ctlmgr
udp        0      0 192.168.xxx.1:137       0.0.0.0:*                           4313/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           4313/nmbd
udp        0      0 192.168.xxx.1:138       0.0.0.0:*                           4313/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           4313/nmbd
udp        0      0 fe80::a96:d7ff:fe6e:xxxx:37891 :::*                                3798/aha
udp        0      0 :::44808                :::*                                3038/multid
udp        0      0 :::60942                :::*                                3363/dsld
udp        0      0 :::40980                :::*                                3038/multid
udp        0      0 :::49699                :::*                                2953/upnpd
udp        0      0 :::40740                :::*                                3038/multid
udp        0      0 :::49702                :::*                                3038/multid
udp        0      0 fritz.box:55343         :::*                                2920/ctlmgr
udp        0      0 :::57652                :::*                                3798/aha
udp        0      0 :::domain               :::*                                3038/multid
udp        0      0 :::36929                :::*                                3038/multid
udp        0      0 localhost:323           :::*                                3792/chronyd
udp        0      0 :::33862                :::*                                3650/feedd
udp        0      0 :::42823                :::*                                3038/multid
udp        0      0 :::46180                :::*                                3588/dect_manager
udp        0      0 :::4711                 :::*                                -
udp        0      0 :::4712                 :::*                                -
udp        0      0 :::4201                 :::*                                3723/log_server
udp        0      0 :::4202                 :::*                                3728/log_server
udp        0      0 fe80::a96:d7ff:fe6e:xxxx:1900 :::*                                3798/aha
udp        0      0 fritz.box:1900          :::*                                3798/aha
udp        0      0 fritz.box:1900          :::*                                3798/aha
udp        0      0 :::1900                 :::*                                3798/aha
udp        0      0 fe80::a96:d7ff:fe6e:xxxx:1900 :::*                                2953/upnpd
udp        0      0 fritz.box:1900          :::*                                2953/upnpd
udp        0      0 fritz.box:1900          :::*                                2953/upnpd
udp        0      0 fritz.box:1900          :::*                                2920/ctlmgr
udp        0      0 fritz.box:1900          :::*                                2920/ctlmgr
udp        0      0 fe80::a96:d7ff:fe6e:xxxx:1900 :::*                                2920/ctlmgr
udp        0      0 :::1900                 :::*                                2953/upnpd
udp        0      0 :::1900                 :::*                                2920/ctlmgr
udp        0      0 :::58225                :::*                                3038/multid
udp        0      0 :::4210                 :::*                                3730/log_server
udp        0      0 :::4211                 :::*                                3735/log_server
udp        0      0 :::4212                 :::*                                3737/log_server
udp        0      0 :::4213                 :::*                                3739/log_server
udp        0      0 :::37749                :::*                                3038/multid
udp        0      0 :::52853                :::*                                3038/multid
udp        0      0 :::4214                 :::*                                3741/log_server
udp        0      0 :::53879                :::*                                2920/ctlmgr
udp        0      0 :::57470                :::*                                3038/multid
udp        0      0 :::43651                :::*                                3038/multid
udp        0      0 :::45701                :::*                                3038/multid
udp        0      0 fe80::a96:d7ff:fe6e:xxxx:36491 :::*                                2920/ctlmgr
udp        0      0 :::60811                :::*                                3038/multid
udp        0      0 :::51353                :::*                                3038/multid
udp        0      0 :::7077                 :::*                                3592/voipd
udp        0      0 :::5031                 :::*                                4317/capiotcp_serve
udp        0      0 :::36268                :::*                                3038/multid
udp        0      0 fritz.box:52921         :::*                                3798/aha
udp        0      0 :::5060                 :::*                                3592/voipd
udp        0      0 fritz.box:59854         :::*                                3798/aha
udp        0      0 :::5351                 :::*                                3204/pcpd
udp        0      0 :::5353                 :::*                                3038/multid
udp        0      0 :::5353                 :::*                                3038/multid
udp        0      0 :::5355                 :::*                                3038/multid
udp        0      0 :::5355                 :::*                                3038/multid
udp        0      0 :::34028                :::*                                3200/ddnsd
udp        0      0 :::58611                :::*                                3038/multid
udp        0      0 :::59899                :::*                                3038/multid
udp        0      0 fritz.box:34044         :::*                                2920/ctlmgr
[email protected]:~ $
Die einzigen Ports, die hier zusätzlich offen sind, sind 8010 und 22 - Shell-in-a-Box und Dropbear sind von mir gestartete Services. Der Rest stammt von AVM und es wurden/werden mit dem Mesh auch immer mehr. Ich traue AVM ja viel zu ... aber für Fuzzing dieser ganzen Network-Daemons wird kaum noch Zeit vorhanden sein. Solange da nur "brave Daten" hereinkommen, mag ja alles gut sein ... aber das gilt ja auch für diese "TCP SACK PANIC". Solange da niemand drauf herumreitet, wird die Box auch nicht abstürzen ...

--------------------------------------------------------------------------------------------------------

WAN-seitig bliebe halt das GUI (TR-064 läuft ja auch darüber) und der TR-069-Service, wo die Aktivität von außen kommen könnte - mehr sollte aber auch schon nicht offen sein. Die VoIP-Telefonie verwendet i.d.R. eher UDP-basierte Protokollvarianten (RTP z.B. geht ja über beide L4-Protokolle), weil hier die Sicherungsmechanismen von TCP ohnehin nichts so richtig bringen, solange man nicht riesige Jitter-Buffer verwendet und erneut gesendete Sprachpakete damit dann noch rechtzeitig eintreffen, um in der korrekten Reihenfolge wiedergegeben zu werden. Allerdings lauscht der "voipd" tatsächlich auch auf dem TCP-Port ... und der ist i.d.R. sehr leicht zu finden. Wer hingegen FTP nach draußen freigibt, ist halt selbst schuld ... das sollte man sich auch ohne diese "Bedrohung" mehrmals überlegen.

Dazu gesellen sich dann noch die Verbindungen, die von der FRITZ!Box selbst aufgebaut werden und wo ein böswilliger Server kontaktiert werden könnte:

- SMTP für Push-Mails
- POP3 für E-Mail-Empfang über DECT-Geräte
- Internetradio/Podcasts, RSS-Feeds, Bilder, (Live-)Video - das ganze Zeug, was man auf einem FRITZ!Fon anzeigen kann ... hier kommt schon mal eher TCP zum Einsatz, als bei der (externen) VoIP-Telefonie
- diverse Updates - von Firmware für die Boxen und andere AVM-Geräte bis zur Liste der "bösartigen Server" (candc, wenn man eine entsprechende Version benutzt)
- wieder TR-069, auch zum AVM-ACS
- DynDNS-Updates
- externe Telefonbücher, hier ggf. auch wieder mit Bildern
- WebDAV

Es ist schon erstaunlich, an wievielen Stellen so ein Gerät wie eine FRITZ!Box, die doch eigentlich nur ein Router sein sollte, ihrerseits noch mit externen Diensten kommuniziert (als Client) ... handelt es sich bei einem solchermaßen kontaktierten Server dann um einen Angreifer, wird AVM vermutlich auch der eigene WAN-Stack nicht wirklich weiterhelfen, denn dessen "Geheimnis" besteht ja eigentlich eher darin, daß er für die FRITZ!Box selbst genauso zum Einsatz kommt, wie für alle anderen Clients - die FRITZ!Box-Dienste kleben ja (fast) alle am LAN-Interface und wenn ein solcher Dienst extern erreichbar sein soll, erfolgt das genauso über eine Portfreigabe (halt auf die Box selbst), wie für jeden anderen Client. Am WAN-Stack dürften Angriffsversuche von extern jedenfalls nicht scheitern ... solange sie die richtigen Ports verwenden, die man dafür auch erst einmal ermitteln muß.

Bei den kontaktierten Servern muß man dann halt überlegen, ob man denen traut ... ich würde auch dem AVM-ACS nicht unbedingt "blind vertrauen" oder dem MyFRITZ!-Server oder dem JUIS, etc. pp. - aber wenn man deren Dienste in Anspruch nimmt, braucht es eben auch wieder keine "TCP SACK PANIC"-Lücke, um eine Box zum Absturz, respektive Neustart, zu verleiten ... dafür gibt es dann "Interface-Funktionen".

--------------------------------------------------------------------------------------------------------

Wer Shell-Zugang zu seiner Box hat, kann ja den von Netflix vorgeschlagenen Workaround #2 nutzen und die SACK-Verarbeitung deaktivieren:
Code:
[email protected]:~ $ sysctl -w net.ipv4.tcp_sack=0
net.ipv4.tcp_sack = 0
[email protected]:~ $ sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 0
[email protected]:~ $
... solange man das nicht automatisiert, überlebt es halt keinen Neustart. Der erste Vorschlag von Netflix, der mit einem Filter für Pakete arbeitet (und Verbindungen mit einer MSS < 500 unterbindet), ist auf der FRITZ!Box so nicht anwendbar, da die Filterung eine vollkommen andere ist.

Ich bin mir gerade nicht 100% sicher, aber nach dieser Quelle: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt müßte das Abschalten von SACK bei den IPv4-Optionen auch für IPv6 wirksam sein ... TCP ist ja ohnehin ein L4-Protokoll (Transportschicht), was auf einer der L3-Varianten (IPv4 vs. IPv6 auf der Internet-/Network-Schicht) aufsetzt.
 

TCHAMMER

Neuer User
Mitglied seit
24 Mai 2009
Beiträge
85
Punkte für Reaktionen
12
Punkte
8
Es Sind ja jetzt Wartungsupdates erschienen leider steht dort nicht was gefixt wurde. Wenn dieses Wartungsupdate die Sack Lücke gefixt hat ist die frage wie haben Sie es gefixt. Haben sie den Kernel gepatcht so das er nicht mehr abstürzt oder haben sie das Workaround verwendet wie in der Github Meldung beschrieben und das TCP-SACK abgeschaltet. Wenn ja dann würde der Datendurchsatz bei TCP Verbindungen leiden wie auf der Wikipedia Seite erklärt ist:

" SACK ist eine Abkürzung für Selective Acknowledgment. TCP SACK ist eine Erweiterung des TCP-Protokolls, die für eine Steigerung des Datendurchsatzes bei Paketverlusten sorgt. SACK ermöglicht, dass bei Paketverlusten nicht der gesamte Inhalt des TCP Windows, sondern nur das fehlende Paket neu angefordert werden muss.
Dabei bestätigt der Empfänger im Falle eines Datenverlustes anhand der Sequenznummern selektiv diejenigen Teile des TCP Windows, die vollständig empfangen wurden. Der Sender sendet nun lediglich die fehlenden Fragmente erneut. "

Ich habe noch einen Router der mit OpenWRT betrieben wird und als IP Client Bridge fungiert und dort hab ich heute das Snapshot Release mit dem Kernel Fix installiert.

Openwrt Client  Router.png


mit SSH verbunden kann man sehen das TCP-Sack Aktiv.

OpenWRT SSH.png

@PeterPawn

Wenn dieses Wartungsupdate ein fix für diese Lücke sein sollte hättest du doch die Möglichkeit zu schauen ob das "net.ipv4.tcp_sack = 1 " Aktiv ist oder nicht?
 

3CX PBX - GRATIS
Linux / Win / Cloud

Neueste Beiträge

Statistik des Forums

Themen
232,031
Beiträge
2,018,104
Mitglieder
349,318
Neuestes Mitglied
H. Bert