Mea maxima culpa.
Er hat hier im Forum gewettert als sie nc (netcat) ausgebaut haben,
dass diverse Hacks mit telnetd genauso easy wären wie mit nc.
Ja durchaus mit Recht ... ich finde es auch heute noch albern, wenn man Kette und Schloß an der Vordertür demonstrativ verstärkt - möglichst noch mit Warnung vor dem Fiffi - und die Hintertür dann nur ein Fliegengitter ist.
Wobei eben der Ausbau von "nc" immer noch Unfug ist, der Telnet-Daemon ist ja noch "drin" und nur nicht auf Anhieb erreichbar.
OT: Was AVM an weiteren gemeldeten Lücken in der finalen 06.25 (oder welche Nummer die auch immer haben wird) noch behebt, weiß ich nicht ... es ist irgendwann müßig, jede neue Version zu testen, wenn sich die Erkenntnisse in der nächsten dann schon wieder erledigt haben könnten. Solange man also nicht von AVM wieder in Kenntnis gesetzt wird, daß eine bestimmte gemeldete Lücke geschlossen wurde, teste ich das nur noch bei extremer Langeweile oder bei Release-Versionen. Das hat natürlich den Nachteil, daß man weiterhin bestehende und/oder neue Lücken erst dann findet, wenn es eigentlich schon wieder zu spät ist, weil sie nun erst mit dem nächsten Zyklus behoben werden können.
Aber zurück zum "nc" ... der "Mißbrauch" setzte ja ohnehin den schon bestehenden Zugriff voraus und die möglichen Vorteile (z.B. der Einsatz als Empfänger für Port 1012, um auf Anrufe zu reagieren in Skript-Code) überwiegen das Schadenspotential beim "nc" bei weitem - jedenfalls meiner Ansicht nach.
Wenn jemand ohnehin Zugriff hat (also ein Angreifer), dann ist es auch egal, ob die benötigten Kommandos für den vollen Funktionsumfang schon auf der Box vorhanden sind ... notfalls lädt man sie eben aus dem Internet nach. Das macht heute jeder Bot so, daß er sich "frischen Payload" von einen C&C-Server zieht.
Der einzige Angriffspunkt, wo das Fehlen von "nc" es wirklich schwieriger macht, ist ein Exploit, der nur eine sehr begrenzte Anzahl von Zeichen als Kommando einschleusen kann, da war das sehr kurze "nc" inkl. notwendiger Optionen schon mal ab ca. 20 Byte zufrieden. Aber auch ein wget, httpsdl, ftpget oder tftp läßt sich für den Down- oder sogar den Upload von Daten verwenden (bei ftpget dann natürlich das dazu passende ftpput) und so groß ist der Unterschied am Ende dann auch wieder nicht.
Ein Exploit mit einer so stark beschränkten Länge eines Kommandos ist ohnehin eher die Ausnahme und auch dann kann man ihn meist noch für das "composing" eines passenden Skripts nutzen, wenn es einen Speicherort dafür gibt.
Der Extremfall mit dem Schreiben einzelner Zeichen ist zwar recht aufwändig, aber ein
mit seinen 23 Zeichen (für den schlechtesten Fall) kann - mit genug Wiederholungen - ganze Geschichten (notfalls sogar binären Inhalt) in der Datei /var/tmp/x einer FRITZ!Box ablegen und das dann am Ende mit "sh /tmp/x" zu starten, ist noch wesentlich kürzer. Und das macht ohnehin niemand von Hand ... das läuft dann automatisch, aus einer zu übertragenden Datei die notwendige Folge solcher Kommandos zu generieren und diese auszuführen.
Sollte AVM hier tatsächlich mitlesen und den Ausbau des telnetd aus der Busybox doch noch in Erwägung ziehen (auch das ist noch kein Beinbruch für das "Modding", nur wenig mehr Aufwand und ich persönlich schwanke zwischen Befürworten (SIAB oder SSH wäre dann derselbe Aufwand wie der Einbau des Telnet-Daemons, vielleicht überlegen es sich einige dann ja doch, die sichere Variante zu nehmen) und Ablehnen), dann habe ich gleich noch die Bitte, die Liste der Applets auch um
- ubimkvol (oder dann doch ubifs einkompilieren bzw. als .ko-Module dazupacken)
- ubirsvol
- ubiupdatevol
- unirmvol
- chgrp
- chroot (ohnehin gefährlich, weil man eben nicht nur Prozesse vom Rest des Systems abschirmen, sondern ihnen - in erster Linie AVM-CS-Binaries - auch vollkommen andere Dateien vorgaukeln kann)
- fgconsole
- iostat
- login (ar7login ruft direkt /bin/sh auf und der Rest verwendet ohnehin die AVM-ACL-Funktionen für das Mapping)
- logname
- mpstat
- passwd
- pmap
- whois
zu erleichtern, von den diversen anderen Leichen außerhalb der Busybox fange ich nicht erst an. Auf Boxen ohne vorhandene nbd-Unterstützung (das sind vermutlich alle mit 2.6.28-Kernel) könnte dann auch noch der nbd-client der Busybox entsorgt werden.
Ich würde sogar die kühne Behauptung wagen, daß man auf einer 7390 mind. 500 KB (und zwar komprimiert) einsparen kann, wenn man sich auf das wirklich benötigte Arsenal an Tools beschränkt und an einigen wenigen Stellen auch noch die Shell-Skripte auf das beschränkt, was auf so einer Box wirklich (in aktuellen Versionen) enthalten ist ... vollkommen ohne einen Verlust an Funktionen.
koyaanisqatsi schrieb:
freetz mit telnetd ist echt irgendwie überflüssig.
Wofür gibt es sonst die (leider meist unbeachtete) Rudi-Shell?
Da fallen mir dann leider gleich mind. zwei Gegenargumente ein. Rudi-Shell ist eine (gut gemachte, damit wir uns da nicht mißverstehen) absichtlich sehr rudimentäre Shell, die über drei CGI-Skripte arbeitet. Als erstes kann man schon mal die Rudi-Shell und eine Telnet-Session mit einem ordentlichen Pseudo-Terminal nicht miteinander vergleichen ... alles, was echte Terminalfunktionen erfordert, von ANSI-Colors bis Text-Menüs wie beim "Midnight Commander" (als extremes Beispiel für die Nutzung von ncurses, denn das ist der eigentliche "Knackpunkt"), funktioniert in der Rudi-Shell nicht und außerdem ist sie - mangels TLS - auch keinen Deut sicherer als eine Telnet-Session. Ja, am Ende bündelt sie sogar die unterschiedlichen Gefahren von Telnet (offene Übertragung) und ShellInABox (XSS-/XSRF-Attacken denkbar, mindestens bei Fehlern im Browser) in einem einzelnen Tool.
Die Unterscheidung bei Freetz erfolgt nur anhand der Tatsache, ob da ein Telnet-Daemon bereits läuft, der nicht von Freetz selbst gestartet wurde. Wenn man das also auf irgendeinem Wege selbst startet, weil AVM das nicht mehr macht, dann "sieht" Freetz das auch als "by phone" - mein Eindruck aus der Analyse der rc.telnetd.
@qwertz.asdfgh:
Ja, bei Freetz-Images sollte der Symlink auch existieren (auch wenn es da für die
Ausführung des telnetd nicht relevant ist, weil ja die Freetz-BB den AVM-Patch nicht enthält und ihn somit nicht testet), da der ja im Rahmen der "normalen Installation" der Busybox (eigentlich "make install", aber fwmod macht das m.W. zu Fuß) angelegt wird.
Über diesen Link startet dann auch der telefon-Daemon den Telnet-Dienst ... Abhilfe würde wohl nur das Auslassen/Umbenennen des Links oder das Patchen des telefon-Daemons (als permanente Änderung lizenzrechtlich etwas schwierig, nur im tmpfs
vermutlich zulässig nach UrhG) schaffen.
Da sehe ich also - solange AVM die Funktion nicht selbst aus "telefon" ausbaut - eher wenig Chancen, denn das Löschen/Umbenennen des Links verwirrt sicherlich andere dann wieder, die ihn dann nicht mehr finden/aufrufen können.
Freetz startet allerdings meines Wissens den Telnet-Daemon gar nicht selbst, sondern läßt ihn bei Bedarf über inetd starten ... theoretisch wäre das Entfernen oder Ändern des Links also tatsächlich problemlos möglich, genauso wie das Verpacken des Telnet-Dienstes in einen irgendwie sichereren Wrapper (z.B. stunnel, aber der trägt ganz schön auf, der neue "matrixtunnel" - hat er13 erst vor kurzem auf die neue libgcrypt umgestellt, wenn ich das richtig gesehen habe - wäre eine denkbare Alternative, wenn GnuTLS jetzt weniger Macken haben sollte). Wobei - ob nun Telnet mit Wrapper oder SSH, das macht bei der Last fast keinen Unterschied, nur der Aufruf einer Telnet-Session über TLS ist für viele wohl komplizierter als eine SSH-Session und SSH erlaubt gleich noch das Login über einen Schlüssel anstelle eines Kennworts.
Wenn man das Anlegen des Symlinks bei der Busybox-Installation von Freetz verhindern will, muß man vorher eine Datei editieren (busybox.links) und ihn dort entfernen.
