Umfrageergebnis anzeigen: Soll der komplette Exploit (Shell-Code oder HTML-Seite mit JS) veröffentlich werden?

Teilnehmer
90. Du darfst bei dieser Umfrage nicht abstimmen
  • Könnte schon lange veröffentlicht sein

    13 14,44%
  • Sollte jetzt veröffentlicht werden

    61 67,78%
  • AVM sollte über die Veröffentlichung entscheiden

    16 17,78%
Seite 5 von 5 ErsteErste 12345
Ergebnis 81 bis 91 von 91

Thema: Disclosure or no disclosure?

  1. #81
    IPPF-Fan
    Registriert seit
    01.06.2006
    Beiträge
    390
    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.

  2. #82
    IPPF Dreitausend-Club
    Registriert seit
    18.02.2011
    Beiträge
    3.914
    [OT]
    Zitat Zitat von Ohrenschmalz Beitrag anzeigen
    Bissl OT: Ich frag mich sowieso, was außerhalb von D/A/CH genommen wird,
    Die Franzosen haben z.B. eine "Freebox".

    Zitat Zitat von PeterPawn Beitrag anzeigen
    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]
    Geändert von qwertz.asdfgh (18.02.2017 um 22:11 Uhr)

  3. #83
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.257
    @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
    Zitat Zitat von robert_s
    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.

  4. #84
    IPPF Fünfhunderter Avatar von Ohrenschmalz
    Registriert seit
    19.04.2006
    Beiträge
    537
    Zitat Zitat von qwertz.asdfgh Beitrag anzeigen
    [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...
    Anschluss: 1&1 Doppel-Flat 50.000 (25000/5000 geschaltet...danke Telekomik...)
    Hardware:Fritz!Box Phone WLAN 7362 SL FRITZ!OS 06.83, Bluetooth, Initio HS06THB 1.8" 60 GB USB-HDD, 320 GB USB-HDD, Ricoh 1210N USB
    DSL-Modem an LAN1: Sphairon AR860 mit Firmware RouterTech_3.6.0D_20080723_2.60_AR7RD
    Telefone: FON1 Siemens Gigaset A140 über DECT, FON 2 Fritz C3 über DECT, FON 3 Siemens Gigaset A58H über DECT, altes Android-Handy über Zoiper, Fax Intern über Fritz!Box
    Anrufbeantworter: intern über Fritz!Box
    Fritz!Box Software: jfritz 0.7.5 REV.23
    Kaffeemaschine: Philips Senseo

  5. #85
    IPPF-Einsteiger
    Registriert seit
    15.12.2014
    Beiträge
    3
    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 ...

  6. #86
    IPPF Achttausend-VIP Avatar von MuP
    Registriert seit
    27.03.2009
    Ort
    §9 Satz 1 AO
    Beiträge
    8.526
    Stimmt.
    "We want YOU!"
    1u1/DF50k +++ VDSL2/BC147.159
    FB3490/140.06.51/1.100.133.42 +++ FR1750E/6.51
    N510IP/42.242 +++ 3xSL750H/116.063.00 +++ GR/2.0

  7. #87
    IPPF Achttausend-VIP Avatar von koyaanisqatsi
    Registriert seit
    24.01.2013
    Ort
    Berlin (Neukölln)
    Beiträge
    8.951
    Mist, "Facility Manager" ist schon weg.
    Phantasie ist wichtiger als Wissen, denn Wissen ist begrenzt (Albert E.) mfg koy
    Anschluss: 1&1 Komplett VDSL 50/10 DS
    Fritz!Box: 7560 FRITZ!OS 6.83 & 6.52 & 1x 7112 (WDS Basis), 3x 7113 (Repeater)
    Telefonie: Rotes Posttelefon, 2x snom320-SIP 8.7.5.44, 2x (billig) DECT, 1x Fax (MuFuG)

    SmartHome: SensorAndSwitch auf Rasperry Pi mit OSMC/KODI (Jessie/Sarge)

  8. #88
    IPPF Achttausend-VIP Avatar von MuP
    Registriert seit
    27.03.2009
    Ort
    §9 Satz 1 AO
    Beiträge
    8.526
    BugBountyContractor steht auch nicht auf der Liste
    1u1/DF50k +++ VDSL2/BC147.159
    FB3490/140.06.51/1.100.133.42 +++ FR1750E/6.51
    N510IP/42.242 +++ 3xSL750H/116.063.00 +++ GR/2.0

  9. #89
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.257
    Wer will schon freiwillig den "Schädlingsbekämpfer" im Haus haben? 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.

  10. #90
    IPPF Achttausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    8.257
    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":
    Code:
    # sed -n -e p /proc/$(pidof firmwarecfg)/environ
    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
    # sed -n -e p /proc/$(pidof firmwarecfg)/cmdline
    /cgi-bin/firmwarecfg
    # sed -n -e p /proc/$(pidof firmwarecfg)/wchan
    unix_stream_recvmsg
    # ls -l /proc/$(pidof firmwarecfg)/fd
    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.

  11. #91
    IPPF Fünfhunderter Avatar von Ohrenschmalz
    Registriert seit
    19.04.2006
    Beiträge
    537
    Danke für die Info
    Zum Warum: Woanders wird sowas gemacht: https://www.heise.de/newsticker/meld...l-3678861.html
    Ein Blick übern Hof klärt auch, warum AVM um Verschiebung gebeten hat: Stehen alle aufn Hof und rauchen
    Anschluss: 1&1 Doppel-Flat 50.000 (25000/5000 geschaltet...danke Telekomik...)
    Hardware:Fritz!Box Phone WLAN 7362 SL FRITZ!OS 06.83, Bluetooth, Initio HS06THB 1.8" 60 GB USB-HDD, 320 GB USB-HDD, Ricoh 1210N USB
    DSL-Modem an LAN1: Sphairon AR860 mit Firmware RouterTech_3.6.0D_20080723_2.60_AR7RD
    Telefone: FON1 Siemens Gigaset A140 über DECT, FON 2 Fritz C3 über DECT, FON 3 Siemens Gigaset A58H über DECT, altes Android-Handy über Zoiper, Fax Intern über Fritz!Box
    Anrufbeantworter: intern über Fritz!Box
    Fritz!Box Software: jfritz 0.7.5 REV.23
    Kaffeemaschine: Philips Senseo

Seite 5 von 5 ErsteErste 12345

Ähnliche Themen

  1. [Info] GrandStream GXV3275 ist Thema auf "full disclosure"
    Von PeterPawn im Forum GS-Allgemein
    Antworten: 1
    Letzter Beitrag: 08.07.2015, 07:51
  2. Umfrage zu BS v8
    Von gismotro im Forum SOT / Streaming Client
    Antworten: 6
    Letzter Beitrag: 01.06.2009, 16:18
  3. Umfrage: Gigaset.NET
    Von VoIPMaster im Forum Gigaset
    Antworten: 8
    Letzter Beitrag: 09.04.2007, 12:20
  4. [SOT] Umfrage: Wer hat welche Box mit SOT
    Von karl2100 im Forum SOT / Streaming Client
    Antworten: 19
    Letzter Beitrag: 26.02.2007, 00:10

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •