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:
root@FB7490:~ $ sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 1
root@FB7490:~ $
), 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:
root@FB7490:~ $ 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)
root@FB7490:~ $
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:
root@FB7490:~ $ 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
root@FB7490:~ $
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:
root@FB7490:~ $ sysctl -w net.ipv4.tcp_sack=0
net.ipv4.tcp_sack = 0
root@FB7490:~ $ sysctl net.ipv4.tcp_sack
net.ipv4.tcp_sack = 0
root@FB7490:~ $
... 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.
