[Erledigt] Disclosure or no disclosure?

[robert_s]

Zu den Alternativen als weiterhin Aussenstehender, würde ich versuchen so gut wie möglich als "hilfreich" wahrgenommen zu werden, also den Sachverhalt möglichst kurz und anschaulich darzustellen - und dann tatsächlich "machen lassen" und je nach Dringlichkeit vielleicht nach einem Monat oder halben Jahr ggf nachzuhaken, und es dann auch zu lassen. Denn was nützt es, "nervig" nachzufragen? Und mit der Veröffentlichung von Lücken, die AVM nicht beheben kann/will, schneidet man sich ja auch nur ins eigene Fleisch, wenn man das Produkt selbst benutzt...

Zum Thema Bewerbung: Da kann man ja erwähnen, dass man sich schon sehr mit der Software auskennt und die Leute, mit denen man schon Kontakt hatte, als Referenz angeben. Was die Umstellung von der Selbständigkeit zur Nichtselbständigkeit angeht, die habe ich auch hinter mir und war gar nicht schlimm. Über Probezeit und befristete Arbeitsverträge kann man da ja "reinkommen" ohne gleich das Gefühl zu haben, sich da "für immer" zu etwas zu verpflichten, was einem vielleicht dann doch gar nicht liegt. Und im schlimmsten Fall kann man eh kündigen.

 

[qwertz.asdfgh]

[OT]

Bissl OT: Ich frag mich sowieso, was außerhalb von D/A/CH genommen wird,

Die Franzosen haben z.B. eine "Freebox".

Die liefern eben ihre "Internet-Box 2" mit (...), [...] und eine integrierte DECT-Basisstation (keine Ahnung, ob die Cat-iq 2.0 kann)

Die "Internet-Box 2" kenne ich zwar nicht aber der Vorgänger (Internet-Box) unterstützt CAT-iq 2.0. Ich denke das wird auch auf den Nachfolger zutreffen denn die von Swissvoice Swisscom angebotenen DECT-Mobilteile setzen, ähnlich wie die dt. Telekom mit ihren Speedphones, ebenfalls auf CAT-iq 2.0.
[/OT]

 

[PeterPawn]

@robert_s:
Mit der Meinung, was man als "Außenstehender" machen sollte (am Ende wird fast jeder "researcher" zum Hersteller "extern" sein), stehst Du aber nicht nur im eklatanten Widerspruch zu mir, sondern zu fast allen Leuten, die sich auf diesem Gebiet auskennen.

Diese - etwas naive - Haltung unterstellt nämlich, daß sich ein Hersteller freiwillig mit einer älteren Firmware erneut befaßt und dort vorhandene Sicherheitslücken dann "aus reiner Nettigkeit" behebt. Wenn Du Dich etwas mit dem Thema beschäftigst (z.B. ist die Lektüre von Nachrichten in der "full disclosure"-Mailing-Liste schon mal eine gute Idee, wenn man sich ernsthaft mit dem Thema befassen will), wirst Du sehr schnell feststellen, daß es eben oft genug tatsächlich nur das Herstellen einer "Öffentlichkeit" ist, was die Hersteller auch wirklich zum Handeln "zwingt".

Ein aktuelles Beispiel wäre z.B. diese Lücke: http://seclists.org/fulldisclosure/2017/Feb/35 - auch dort wirst Du in der Timeline feststellen, daß der Finder sich an den Hersteller gewandt hat, dieser irgendwann sogar um eine "Verlängerung" bat (90 Tage Anfang August 2016) und sich dann trotzdem erst etwas tat (obwohl QNAP erst drei Wochen vor dem Fix eine neue Firmware-Version veröffentlicht hatte), nachdem er die Lücke öffentlich gemacht hatte (am 13.01.2017).

Ich stelle mal die These auf, daß 19 von 20 Sicherheitslücken niemals geschlossen würden, wenn sich tatsächlich deren Finder so verhalten würden, wie Du es für richtig ansiehst und sich nicht auch bei wirklich Großen der Software-Branche der Gedanke durchgesetzt hätte, daß man auch Sicherheitslücken einer "geordneten Bearbeitung" zuführen muß, weil man auch im Nacken immer die "Gefahr" spürt, daß diese Lücken an die Öffentlichkeit gelangen könnten oder - schlimmer - als 0day-Exploits von jemandem mißbraucht werden könnten. Und dazu gehört dann eben auch die Diskussion und das "nervige Nachfragen" durch den Finder ... es geht allerdings auch anders und das habe ich z.B. für #480894 auch exakt so gemacht. Nur mit Deiner Schlußfolgerung, was man bei ausbleibender Reaktion des Herstellers machen sollte (da lese ich bei Dir ein Achselzucken: "Dann bleibt das eben ungefixt und unveröffentlicht, na und."), gehe ich halt nicht konform.

Denn alle anderen von Dir im ersten Absatz geäußerten Ansichten stehen dann eben auch in eklatantem Widerspruch zu den "best practices" - was zugegebenermaßen bei mir Zweifel aufkommen läßt, ob Du diese verlinkten Dokumente überhaupt gelesen hast oder ob Du Dich tatsächlich mit dem Thema auskennst oder auch nur ernsthaft beschäftigst, denn dann hätte ich zumindest eine etwas fundiertere Argumentation erwartet, die z.B. auch darauf eingeht, warum die 48-72 Stunden für die erste Reaktion des Herstellers nach der reinen Eingangsbestätigung aus der "best practices"-Empfehlung des BSI aus Deiner Sicht nicht notwendig wären und warum das nach Deiner Meinung - je nach "Dringlichkeit" (wer schätzt diese dann eigentlich ein?) - irgendetwas zwischen einem Monat und einem halben Jahr sein sollte.

Das Argument

Und mit der Veröffentlichung von Lücken, die AVM nicht beheben kann/will, schneidet man sich ja auch nur ins eigene Fleisch, wenn man das Produkt selbst benutzt...

ist aber wirklich ulkig ... um es mal ganz eindeutig zu schreiben: Wenn eine Lücke Auswirkungen hat/haben kann und der Hersteller weigert sich tatsächlich, diese zu beheben, dann gehört das erst richtig an die Öffentlichkeit - weil man nämlich nicht nur selbst gefährdet ist (das wäre dann das "Schneiden ins eigene Fleisch" bei eigener Veröffentlichung), sondern weil es auch alle anderen Verwender dieser Geräte und dieser Firmware sind, wenn der Nächste diese Lücke findet.

Hier geht es dann tatsächlich in Richtung Ethik (und nicht nur um die eigene "Nabelschau", weil man selbst sich mit dem Wissen um das Bestehen des Problems auch noch schützen kann und sei es durch Aussonderung des Gerätes oder das Vermeiden der Benutzung einer bestimmten Funktion) und wer das schon im Grundsatz nicht verstehen will, wird auch den Rest der Diskussion gar nicht verstehen können.

Um das noch einmal ganz deutlich zu machen ... das ist auch nicht nur meine persönliche Ansicht, diese stimmt halt mit großen Teilen der "security researcher"-Szene überein (den erneuten Hinweis auf Google's "Project Zero" kann ich ja auch noch einmal einflechten) und auch wenn Du tatsächlich Deine eigene Meinung haben darfst und sollst, wenn es um diese Themen geht (wer wollte Dir das auch verbieten), disqualifizierst Du Dich in meinen Augen mit diesem Standpunkt, den Du einfach auch nur postulierst und gar nicht mit einer tragfähigen Begründung - abseits von "wenn der Hersteller nicht will, kann man ohnehin nichts machen" - untermauerst; die ganzen "best practices" und das praktizierte(!) Vorgehen einer "Branche" hättest Du dann zu widerlegen - such' Dir einfach einen Anfang für den roten Faden einer eigenen Argumentation, warum die alle falsch liegen und laß uns an Deiner Argumentation teilhaben) für eine weitere ernsthafte(!) Diskussion, solange Du das nicht nachvollziehbar begründen kannst oder willst.

Ich lasse mich diesmal auch gar nicht erst noch weiter vom Thema "weglocken" ... die ganzen Gedanken zur Bewerbung sind vollkommen abseits des Themas. Ich kritisiere hier zwei vollkommen verschiedene Aspekte bei AVM (die Existenz einer bestimmten Sicherheitslücke und das generelle "Handling" beim Aufzeigen solcher Schwachstellen durch externe Finder) - da gibt es mit einiger Wahrscheinlichkeit schon mal gar keine "Stellenbeschreibung", die gleichzeitig für das Beheben von Schwachstellen und parallel dazu für die "Darstellung" des Unternehmens ggü. den Kunden bei der Kommunikation in Bezug auf Sicherheitsprobleme (oder auch andere Firmware-Fehler) zuständig ist. Schon diese Annahme träfe vielleicht für ein "kleines Unternehmen" mit max. 10 Leuten zu - bei AVM wird sie recht unrealistisch und eigentlich müßtest Du das auch selbst wissen, wenn Deine sonstigen Ausführungen zu den eigenen Erfahrungen stimmen.

Es ist also auch müßig, diesen Gedankengang weiter zu verfolgen und wenn Du den Inhalt meiner Beiträge hier tatsächlich gelesen und verstanden hast, dann weißt Du auch, daß ich neben #515119 auch die Frage nach der generellen Handhabung von solchen Schwachstellen bei AVM stelle ... das Thema "bewirb Dich doch einfach da" dürfte spätestens dann vom Tisch sein, wenn es um andere Finder von Problemen geht. Du wirst ja sicherlich nicht ernsthaft jedem Pentester nun vorschlagen wollen, er solle sich - anstatt die Probleme an AVM zu melden und dann genau so zu verfahren, wie er es mit anderen Herstellern auch macht - einfach beim Hersteller der betreffenden Hard-/Software bewerben, um das Problem schließlich "von innen" zu lösen, wenn der Hersteller selbst nicht willens oder nicht fähig ist. Das klingt mir etwas zusehr nach "Team Wallraff", als daß ich es tatsächlich ernst nehmen könnte.

Wenn Du also fundiert den Standpunkt "Schwachstellen sollte man einmal an den Hersteller melden und dann einfach selbst vergessen" (das ist die "Zusammenfassung", in der ggf. noch die einmalige Nachfrage nach einem Monat bzw. einem halben Jahr fehlt) vertreten willst und dafür als Proponent auftreten möchtest (das erfordert dann aber eine nachvollziehbare Argumentation) ... gerne. Wenn es nur ums Diskutieren um des Diskutierens willen geht und es immer weiter von eigentlichen Thema wegführt (wie die Geschichte mit dem "von innen tätig werden"), dann sollten wir zwei diese (zunehmend unernste) Diskussion zwischen uns hier auch beenden.

 

[Ohrenschmalz]

[OT]

Die Franzosen haben z.B. eine "Freebox".


Die "Internet-Box 2" kenne ich zwar nicht aber der Vorgänger (Internet-Box) unterstützt CAT-iq 2.0. Ich denke das wird auch auf den Nachfolger zutreffen denn die von Swissvoice angebotenen DECT-Mobilteile setzen, ähnlich wie die dt. Telekom mit ihren Speedphones, ebenfalls auf CAT-iq 2.0.
[/OT]

Die "Internet-Box 2" kann CAT-iq 2.0. Steht auf der Swisscom-Seite. Für 280 Euro umgerechnet kann man das Ding kaufen. Find ich im Vergleich zum TP-Link (Archer 2600) zu teuer...

 

[Mjoelnir]

AVM müßte also eigentlich ziemlich viele Leute einstellen (wird wohl mehr als einen Entdecker von Schwachstellen geben) und andererseits müßten diverse Leute also Jobs bei 2-3 Firmen haben, wenn sie sich mit mehr als einem Produkt auseinandersetzen. Sicherlich überspitzt formuliert, aber auch nicht völlig argumentfrei ...

 

[MuP]

Stimmt.
"We want YOU!"

 

[koyaanisqatsi]

Mist, "Facility Manager" ist schon weg.

 

[MuP]

BugBountyContractor steht auch nicht auf der Liste

 

[PeterPawn]

Wer will schon freiwillig den "Schädlingsbekämpfer" im Haus haben? :mrgreen: Am Ende gar noch im "Edgar-Kostüm", was dann die Mitarbeiter verschreckt, so daß sie erst noch geblitzdingst werden müssen, damit sie wieder ihrer Arbeit nachgehen können.

So jemanden holt man max. noch als "Tatortreiniger" im Nachgang - aber das übernehmen auch immer häufiger "die Spezialisten" und die rücken dann auch gleich als "starkes Team" an.

Immerhin bin ich etwas erleichtert (aber auch ein wenig verwundert ob solcher Einstiegshürden), daß man bei AVM ohne erfolgreich abgeschlossenes Hochschulstudium der Informatilk oder Medieninformatik (oder einer vergleichbaren Studienrichtung - Wie wäre es mit Germanistik, Sozialpädagogik oder BWL? Ich tue mich mit dieser "Vergleichbarkeit" immer schwer und kann mir darunter nie so richtig etwas vorstellen, ohne dabei eine konkrete Studienrichtung vor dem geistigen Auge zu haben.) nicht ans FRITZ!Box-GUI gelassen wird.

Das läßt für die Zukunft hoffen - zumindest hat sich damit dann die Vermutung, daß an einigen Stellen eher der Praktikant unbeaufsichtigt(!) gewirkt hat, erledigt. Wobei ich durchaus auch schon Hiwis gesehen habe (also auch nicht gegen Praktikanten an sich, solange sich am Ende jemand dafür verantwortlich fühlt), die Bachelor-Absolventen locker in die Tasche gesteckt haben, wenn's um "die Praxis" ging - aber das ist sicherlich überall so und kommt auch auf die konkreten Personen und ihre Motivation/ihre Interessen/ihre Vorkenntnisse an.

 

[PeterPawn]

Nachdem mich AVM noch zweimal (durchaus verbindlich und freundlich) per E-Mails um eine Verschiebung gebeten hatte, ist nun aber der Punkt erreicht, wo die relevanten Modelle (außer der 6490) mit einer neuen Firmware versorgt wurden und wer bisher seine Firmware nicht aktualisiert hat, wird das sicherlich ohne triftigen Grund auch in absehbarer Zeit nicht machen.

Damit habe ich ins Repository zwei Dateien für die Demonstration der weiter vorne beschriebenen Lücke aufgenommen, einmal ein Shell-Skript und einmal eine HTML-Datei, die das Ausnutzen der Schwachstelle über Javascript (und damit eben potentiell auch über einen Browser beim Benutzer, der irgendeine Werbung in ein IFRAME lädt) zeigt.

Zu den Folgen habe ich schon genug geschrieben und angesichts des bisher hier Geschriebenen ist es schon fast ein wenig peinlich, wie simpel so ein Request aufgebaut sein kann - das war aber beim "webcm" auch nicht viel anders.

Ich selbst bin im Zuge diverser Versuche, eine FRITZ!Box aus dem LAN zum Absturz und damit zum Neustart zu bringen, irgendwann vor > 9 Monaten auch an der Stelle vorbeigekommen, wo ich versuchte, das 'firmwarecfg'-CGI mit mehr oder weniger falschen/unvollständigen Daten zu Fehlfunktionen (und in der Folge den "ctlmgr" als Host-Prozess zu einem Absturz mit nachfolgendem Neustart über den Watchdog) zu veranlassen. Da sich aus einem solchen Request ja auch nicht unmittelbar ein Absturz ergibt, fiel mir das "Hängenbleiben" entsprechender Requests auch erst auf, als ich irgendwann mal nach einem solchen Test einen Blick in die Prozess-Liste der getesteten FRITZ!Box warf und da immer noch eine Instanz von 'firmwarecfg' aktiv war, obwohl doch meine Aufrufe mit mehr oder weniger sinnvollen Daten lange beendet waren.

Warum will man überhaupt eine FRITZ!Box mutwillig zum Absturz bringen? Ich betone ja gerne bei diversen Fehlern in der Firmware immer aufs Neue, daß eine FRITZ!Box einem Angreifer beim Start des Systems (genauer beim Start des Bootloaders) vollkommen schutzlos ausgeliefert ist, wenn der Angreifer nur an eine kabelbasierte Ethernet-Verbindung zu so einer startenden Box gelangt. Da stellt natürlich jemand, dem man so eine "Voraussetzung" für einen Angriff erläutert, irgendwann zwangsläufig auch die Frage, wie man so einen Neustart denn auslösen will und daß das damit doch alles weiterhin nur reine Theorie wäre, was man da so erzählt. Also geht man irgendwann hin und versucht, die Box (zuerst von der LAN-Seite) zu einem Absturz zu bewegen.

Das geht sicherlich noch auf so manchem anderen Weg, aber aus einem Programm, was irgendwelche Dienste mit falschen UDP-Paketen füttert und sie so zu Fehlfunktionen verleitet, ist nun einmal kein Angriff (auch nicht in der Theorie oder nur sehr schwer zumindest) über einen Browser und irgendwelche eingeschleuste Werbung abzuleiten. So ein DoS-Angriff ist nun auch noch kein Absturz, aber mit entsprechender Hartnäckigkeit des Angreifers wird der Besitzer früher oder später gezwungen sein, selbst einen Neustart auszuführen. Lauert dann der Schadcode irgendwo im LAN auf einem kabelgebundenen Gerät nur auf diesen Augenblick, hat der Angreifer auch mit so einem DoS-Angriff sein Ziel erreicht.

Sonstige Schäden (collateral damage ;-)) aus einem DoS-Angriff sollten eigentlich nicht entstehen, ich habe bisher auch von AVM keine Information erhalten, daß auf diesem Wege (mit ausgefeilteren Parametern für den CGI-Aufruf) die (externe) Ausführung fremder Kommandos möglich wäre. Die Box ist halt (bei entsprechender Anzahl von TLS-Requests) von extern nicht mehr zu erreichen (da geht ja theoretisch jeder Zugriff über TLS), die Funktionen von "firmwarecfg" sind bereits mit einem einzelnen Request für die nächsten 40 Minuten nicht mehr erreichbar (dazu gehört z.B. der Im- und Export von Einstellungen u.v.m.) und bei ausreichend großer Anzahl von Verbindungsversuchen aus dem LAN scheitern weitere TCP-Verbindungen - mithin ist dann auch das GUI nicht mehr erreichbar und auch bei der Kindersicherung kann es Probleme geben (zumindest mit Sperranzeigen) - genauso natürlich mit SIP-Verbindungen, die auf TCP basieren.

Aber da hilft es dann, auf eine Version >= 06.80 zu aktualisieren, dort hat AVM das Problem behoben. Zwar wird das nicht ausdrücklich kommuniziert, aber es ist (zumindest bei den von mir getesteten Modellen) so. Sollte also jemand feststellen, daß seine FRITZ!Box nicht mehr reagieren will, obwohl die "Routing-Funktion" noch problemlos arbeitet, dann käme zumindest in der Theorie ein solcher DoS-Angriff auch als Ursache in Betracht. Ich kenne auch keine Methode, einen solchen Angriff auf einer Box ohne Shell-Zugang zu diagnostizieren ... die augenfällige Variante mit den Support-Daten scheitert in der Regel dann daran, daß deren Abruf ebenfalls über "firmwarecfg" erfolgt und das ja nicht funktioniert - mithin bliebe vielleicht (bei einer extern angegriffenen Box) noch diese "Verweigerung" der Support-Daten als Indiz übrig, daß mit "firmwarecfg" etwas nicht stimmt.

Über die eigentlichen Ursachen dieses "Hängenbleibens" kann ich auch nichts Definitives sagen ... schaut man sich den Zustand der File-Handle so einer aktiven Instanz von 'firmwarecfg' an, würde ich am ehesten darauf tippen, daß dort ein Lesen von STDIN versucht wird (wo ein CGI-Programm ja seine Eingaben vom HTTP-Server serviert bekommt, wenn es sich um einen POST-Request handelt, was hier der Fall ist) und da halt keine weiteren Daten vorliegen.

Angesichts der normalerweise an dieser Stelle noch erforderlichen SID als Nachweis der Berechtigung für den Zugriff, würde ich tippen (mehr ist es aber auch nicht), daß hier versucht wird, diese fehlende SID zu lesen und das halt zum Blockieren (für dieses CGI-Binary, das zu allem Überfluß offenbar auch noch ein Singleton ist) führt.

Andere Parameter-Kombinationen haben (iirc) ebenfalls noch funktioniert ... aber im Zuge der Dokumentation hatte ich mich dann irgendwann auf diesen "reboot"-Parameter beim Senden festgelegt und gar nicht mehr weiter getestet, welche anderen Kombinationen da ebenfalls noch erfolgreich waren - dieses "reboot" ist allerdings tatsächlich eine mögliche, legitime Operation für "firmwarecfg"; es ist genau das, was bei einem Neustart über das GUI aufgerufen würde (halt mit einer SID als "sid" im Request).

Bei einer 7580 mit 06.54 sieht das so aus für eine solche Instanz von "firmwarecfg":

# [B][COLOR="#0000FF"]sed -n -e p /proc/$(pidof firmwarecfg)/environ[/COLOR][/B]
PATH=/bin:/usr/bin
SERVER_SOFTWARE=AVM websrv
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=POST
PATH_INFO=/cgi-bin/firmwarecfg
PATH_TRANSLATED=/usr/www/html/cgi-bin/firmwarecfg
SCRIPT_NAME=/cgi-bin/firmwarecfg
REMOTE_ADDR=192.168.178.2
REMOTE_PORT=60720
SERVER_ADDR=192.168.178.1
SERVER_PORT=80
HTTP_USER_AGENT=handcrafted_exploit/0.1 (shell)
HTTP_ACCEPT=*/*
CONTENT_TYPE=application/x-www-form-urlencoded
HTTP_HOST=192.168.178.1
CONTENT_LENGTH=6
TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
OEM=1und1
Country=049
CONFIG_FON_HD=y
CONFIG_TIMERCONTROL=y
CONFIG_USB_STORAGE_USERS=n
CONFIG_WLAN=y
CONFIG_WLAN_RADIOSENSOR=y
CONFIG_AB_COUNT=2
CONFIG_EWETEL_SMARTMETER=n
CONFIG_FON_IPPHONE=y
CONFIG_I2C=n
CONFIG_LFS=y
CONFIG_LTE=n
CONFIG_PERL=n
CONFIG_USB_HOST_AVM=n
CONFIG_UTF8_FULL=y
CONFIG_VPN_CERTSRV=n
CONFIG_WLAN_TXPOWER=y
CONFIG_BETA_RELEASE=0
CONFIG_ATA_NOPASSTHROUGH=n
CONFIG_CAPI_NT=y
CONFIG_JFFS2=n
CONFIG_NFS_CLI=n
CONFIG_ONLINEHELP_URL=http://help.avm.de/fritzbox.php?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_T38=y
CONFIG_UDEV=y
CONFIG_WLAN_OPENWIFI=n
CONFIG_CODECS_IN_PCMROUTER=y
CONFIG_KIDS_CONTENT=n
CONFIG_LED_EVENTS=y
CONFIG_NFS=n
CONFIG_STOREUSRCFG=y
CONFIG_USB_TETHERING=y
CONFIG_CAPI_XILINX=y
CONFIG_NEUERUL=y
CONFIG_SQLITE=y
CONFIG_UBIK2=n
CONFIG_WLAN_ATH_NM_MAGPIE=n
CONFIG_YAFFS2=n
CONFIG_CHRONY=y
CONFIG_CONFIGD=y
CONFIG_DSL_UR8=n
CONFIG_FONGUI2=y
CONFIG_WEBGUI_PASS=y
CONFIG_FONQUALITY=y
CONFIG_FTP=y
CONFIG_GPS=n
CONFIG_SQLITE_VIDEO=y
CONFIG_TAM_ONRAM=n
CONFIG_USB=n
CONFIG_WLAN_WDS_NO_SLAVE=n
CONFIG_ENVIRONMENT_PATH=/proc/sys/urlader
CONFIG_MULTI_COUNTRY=n
CONFIG_NCURSES=n
CONFIG_PRODUKT_NAME=FRITZ!Box 7580 (UI)
CONFIG_VDSL=y
CONFIG_DECT_AUDIOD=y
CONFIG_DECT_NO_EMISSION=y
CONFIG_USB_HOST_TI=n
CONFIG_ASSIST=y
CONFIG_AVMIPC_REMOTE_IP=
CONFIG_HOME_AUTO=y
CONFIG_LED_NO_DSL_LED=y
CONFIG_NTFS=y
CONFIG_PROV_DEFAULT=n
CONFIG_SWAP=n
CONFIG_CAPI_POTS=n
CONFIG_DIAGNOSE_LEVEL=0
CONFIG_USB_INTERNAL_HUB=n
CONFIG_USB_STORAGE=y
CONFIG_VERSION=06.54
CONFIG_SUBVERSION=
CONFIG_MANUAL_URL=https://assets.avm.de/manual/?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_SAMBA=y
CONFIG_USB_XHCI=y
CONFIG_WEBSRV=y
CONFIG_BLUETOOTH_CTP=n
CONFIG_DECT_MONI_EX=y
CONFIG_RELEASE=1
CONFIG_BUILDNUMBER=41655
CONFIG_DECT_FW_ULE=n
CONFIG_FIRMWARE_URL=http://www.avm.de/fritzbox-firmware-update.php?hardware=225&oem=1und1&language=de&country=049
CONFIG_FLASH_DOUBLE=y
CONFIG_PRODUKT=Fritz_Box_HW225
CONFIG_SERVICEPORTAL_URL=http://www.avm.de/fritzbox-service-portal.php?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_ROMSIZE=0-nand_size=512MB
CONFIG_ACCESSORY_URL=http://www.avm.de/fritzbox_apps.php?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_BUTTON=y
CONFIG_MAILD=y
CONFIG_NO_EXTENDED_CODECS=n
CONFIG_TR064=y
CONFIG_VERSION_MAJOR=153
CONFIG_XILINX=y
CONFIG_BOXLOWRESSOURCES=n
CONFIG_CXX=n
CONFIG_DOCSIS_PCD_NO_REBOOT=n
CONFIG_FIBER=n
CONFIG_MEDIASRV_MOUNT=n
CONFIG_NQOS=y
CONFIG_ONLINEHELP=y
CONFIG_WLAN_ATH_NM_COMBO=n
CONFIG_GDB=n
CONFIG_USB_PRINT_SERV=y
CONFIG_VPN=y
CONFIG_ETH_COUNT=5
CONFIG_UPNP=y
CONFIG_CAPI=y
CONFIG_USB_LTE=n
CONFIG_WEBDAV=y
CONFIG_DSL_2DP=n
CONFIG_MAILER=n
CONFIG_TR069=y
CONFIG_WLAN_GUEST=y
CONFIG_WLAN_STANDALONE_MODE=n
CONFIG_CDROM_FALLBACK=n
CONFIG_DECT_HOME_HANFUN=n
CONFIG_FAXSEND=y
CONFIG_ONLINEPB=y
CONFIG_PLC_DETECTION=y
CONFIG_PLUGINV2=n
CONFIG_USB_GSM=y
CONFIG_WLAN_WEATHER_CAC=n
CONFIG_DECT=y
CONFIG_FHEM=n
CONFIG_USB_GSM_VOICE=y
CONFIG_WLAN_WDS=n
CONFIG_CAPI_UBIK=n
CONFIG_DECT_PICTURED=y
CONFIG_DSL_BONDING=n
CONFIG_FAXSUPPORT=y
CONFIG_INSTALL_TYPE=mips34_512MB_grx5_dect446_5geth_2ab_isdn_nt_2usb_host3_2wlan11n_hw225_27364
CONFIG_MTD_MAILSEND=y
CONFIG_NAND=y
CONFIG_RAMDISK=n
CONFIG_TELEKOM_KOFFER=n
CONFIG_WLAN_1130TNET=n
CONFIG_CONFIGSPACE_ONNAND=n
CONFIG_DECT_HOME=y
CONFIG_HOME_AUTO_NET=y
CONFIG_IGD=y
CONFIG_MULTI_LANGUAGE=n
CONFIG_QOS_METER=y
CONFIG_SRTP=n
CONFIG_WLAN_ATH_NM_PCI=y
CONFIG_WLAN_MADWIFI=y
CONFIG_DECT_14446=y
CONFIG_DECT_ONOFF=n
CONFIG_EXT2=y
CONFIG_FAX2MAIL=y
CONFIG_MEDIASRV=y
CONFIG_OEM_DEFAULT=avm
CONFIG_PLUGINV2_WEBCM_INTERPRETER=n
CONFIG_UNIQUE_PASSWD=n
CONFIG_WLAN_WMM=y
CONFIG_ATA=y
CONFIG_AUDIO=n
CONFIG_BASIS=y
CONFIG_BOX_FEEDBACK=y
CONFIG_ERR_FEEDBACK=y
CONFIG_EXT3=y
CONFIG_HOMEI2C=n
CONFIG_MYFRITZ=y
CONFIG_DSL_MULTI_ANNEX=n
CONFIG_ECO=y
CONFIG_IPV6=y
CONFIG_SQLITE_BILDER=y
CONFIG_URLADER_UPDATE=n
CONFIG_VLYNQ=n
CONFIG_VOIP_ENUM=n
CONFIG_WLAN_1350TNET=n
CONFIG_INETD=y
CONFIG_LOGD=n
CONFIG_STRACE=y
CONFIG_USB_HOST_INTERNAL=n
CONFIG_CDROM=n
CONFIG_GDB_FULL=n
CONFIG_GFAST=n
CONFIG_HOSTNAME=fritz.box
CONFIG_MEDIACLI=y
CONFIG_NOTELNETD=n
CONFIG_REMOTE_HTTPS=y
CONFIG_SPEEDSTEP=y
CONFIG_USB_WLAN_AUTH=y
CONFIG_UTF8=y
CONFIG_VOL_COUNTER=y
CONFIG_WLAN_EACS=y
CONFIG_WLAN_IPTV=y
CONFIG_AUTOUPDATE=y
CONFIG_DOCSIS_CLI=n
CONFIG_ECO_SYSSTAT=y
CONFIG_IPERF=y
CONFIG_LIB_MATH=y
CONFIG_USB_HOST=y
CONFIG_USB_STORAGE_SPINDOWN=y
CONFIG_AURA=y
CONFIG_DOCSIS=n
CONFIG_MAILER2=y
CONFIG_NETPERF=y
CONFIG_PLUGINV2_WLAN=n
CONFIG_WLAN_TCOM_PRIO=n
CONFIG_CAPI_TE=n
CONFIG_DECT2=y
CONFIG_KIDS=y
CONFIG_MTD_RSS=y
CONFIG_SESSIONID=y
CONFIG_WEBCM_INTERPRETER=y
CONFIG_WLAN_HOTSPOT=y
CONFIG_WLAN_WDS2=y
CONFIG_UPDATEFEATURE_URL=https://www.avm.de/fritzbox_firmware-features.php?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_ANNEX=B
CONFIG_DECT_MONI=y
CONFIG_LABOR_DSL=n
CONFIG_SOCAT=n
CONFIG_WEBUSB=y
CONFIG_WLAN_WPS=y
CONFIG_BUILDTYPE=1
CONFIG_NEWSLETTER_URL=http://www.avm.de/newsletter?hardware=225&oem=1und1&language=de&country=049&version=153.06.54&subversion=
CONFIG_DSL_VENDORID=
CONFIG_LINEARTV=n
CONFIG_MINI=n
CONFIG_PLC=n
CONFIG_ETH_GBIT=y
CONFIG_TAM_MODE=1
CONFIG_UBI=y
CONFIG_VLYNQ0=0
CONFIG_WLAN_GREEN=y
CONFIG_CAPI_MIPS=n
CONFIG_FONBOOK2=y
CONFIG_GDB_SERVER=n
CONFIG_MTD_MAIL=y
CONFIG_PPA=y
CONFIG_VLYNQ1=0
CONFIG_WLAN_BRCM=n
CONFIG_WLAN_SAVEMEM=n
CONFIG_ATA_FULL=n
CONFIG_BLUETOOTH=n
CONFIG_LLTD=n
CONFIG_LUA=y
CONFIG_MORPHSTICK=n
CONFIG_NAS=y
CONFIG_NFS_SRV=n
CONFIG_SDK=n
CONFIG_SPEECH_FEEDBACK=y
CONFIG_TAM=y
CONFIG_WLAN_ATH_NM_OFFLOAD=n
CONFIG_WLAN_ATH_NM_USB=n
CONFIG_DECT_CATIQ20=n
CONFIG_DSL=y
CONFIG_DSL_VRX318=y
CONFIG_FON=y
CONFIG_IPTV_4THOME=y
CONFIG_LIBZ=y
CONFIG_RAMSIZE=512
ANNEX=B
CLIENTCONNECTION=192.168.178.2:60720
HTTPS=off
Language=de
WEBDIR_PATH=/usr/www/html
HWRevision=225
# [COLOR="#0000FF"][B]sed -n -e p /proc/$(pidof firmwarecfg)/cmdline[/B][/COLOR]
/cgi-bin/firmwarecfg
# [COLOR="#0000FF"][B]sed -n -e p /proc/$(pidof firmwarecfg)/wchan[/B][/COLOR]
[COLOR="#FF0000"][B]unix_stream_recvmsg[/B][/COLOR]
# [COLOR="#0000FF"][B]ls -l /proc/$(pidof firmwarecfg)/fd[/B][/COLOR]
lrwx------    1 root     root            64 Apr 11 03:52 0 -> socket:[366877]
lrwx------    1 root     root            64 Apr 11 03:52 1 -> socket:[366877]
lrwx------    1 root     root            64 Apr 11 03:52 2 -> socket:[366877]

"wchan" gibt ja den Namen der Kernel-Funktion aus, in der ein Prozess "schlafengelegt" wurde und das ist hier "unix_stream_recvmsg". Basierend darauf, daß es hier nur drei mögliche Streams gäbe und nur STDIN (fd=0) für den "Empfang" taugen sollte, bin ich eben zu der o.a. Theorie gelangt (ohne irgendetwas wirklich zu tracen, also weder über einen Debugger noch über ein "strace" o.ä.), daß da versucht wird, zusätzliche und nicht vorhandene Daten zu lesen. Das muß aber keinesfalls stimmen, es ist nur eine Theorie auf der Basis der Information, wo das CGI-Programm am Ende hängengeblieben ist.

Die irgendwo zuvor von mir selbst gestellte Frage, ob die 7580 ebenfalls betroffen war und ob das dort auch vor Weihnachten 2016 bereits mit der 06.80 behoben wurde, ist inzwischen auch geklärt ... ich gehe einfach mal zugunsten des Herstellers davon aus, daß es sich da nur um eine Kommunikationspanne handelte und man mir nicht irgendwie "unterjubeln" wollte, daß die 7490 das erste Modell gewesen sei, welches Ende Januar 2017 den Fix für diese Lücke erhalten hat.

 

[Ohrenschmalz]

Danke für die Info
Zum Warum: Woanders wird sowas gemacht: https://www.heise.de/newsticker/mel...legt-unsichere-IoT-Geraete-still-3678861.html
Ein Blick übern Hof klärt auch, warum AVM um Verschiebung gebeten hat: Stehen alle aufn Hof und rauchen :gruebel:

 

[PeterPawn]

Mal so als "Abschluß" der Diskussion ... wohl das erste Mal, daß ein LG sich mit der Frage, welche Disclosure-Strategie wohl zu empfehlen wäre, befaßt hat. Auch wenn es am Ende nur einen Vergleich und kein Urteil gab ... https://heise.de/-4156393

 

[H´Sishi]

Der Vergleich ist immerhin eine Richtschnur, wie zukünftig beim Entdecken von Schwachstellen gehandelt werden könnte.

Das was hier rauskam, sollte eigentlich Standard sein:
- Den Hersteller über das gefundene Problem informieren. Dieser hat somit Zeit, das Problem zu prüfen und seine Kunden zu informieren.
- Eine angemessene Frist abwarten, bevor man die Öffentlichkeit grob über den Sachverhalt informiert. Es gibt viele Firmen, die ähnliche Produkte herstellen und spätestens jetzt werden die Anwender / Kunden auf das Problem sensibilisiert.
- Eine weitere Frist bzw. den Fix abwarten, bevor man mit genauen Details an die Öffentlichkeit geht, um die Notwendigkeit des Updates zu verdeutlichen.

Wenn der Hersteller allerdings nicht reagiert, das Problem aussitzt oder die Justiz in Marsch setzt, gehört die ganze Story veröffentlicht (allerdings ohne den Beispielcode), um potentielle Kunden von diesem Hersteller abzuraten.
Wenn einem Hersteller selbst eine angemessene Nachsorge der eigenen Produkte egal ist, verdient der keine Kunden.

 

[MuP]

Die Hersteller vermeiden generell Urteile, bevorzugen Vergleiche auch mit dem Nachteil des "Aufbrummens" der Gerrichts- und Anwaltskosten.
Sonst könnte ja jemand bei gkleichgelagerten Fällen auf die Idee kommen, sich zwecks Behebungsdurchsetzungsanspruch bzgl eines Mangels auf das (bindende!) LG- bzw. OLG-Urteil zu berufen.