Nach der Änderung bei der Anzeige von "Alle Geräte" in der Netzwerkübersicht sieht das jetzt so aus in der menu_data.lua:
Code:
["show"] = general.is_router() or general.is_ip_client(),
Lassen wir uns mal überraschen, was da noch auf uns zukommen wird. Spannend daran ist nur, daß AVM drei verschiedene Modi bei dieser "Betriebsart" unterscheidet, mehr ist im Moment nicht definiert (jedenfalls nicht in der general.lua):
Code:
function is_ip_client ()
-- Wird die Box als IP-Client betrieben ?
return g_opmode == "opmode_eth_ipclient"
end
function is_router()
-- Wird die Box als Router betrieben?
-- d.h. nicht IP-Client oder DSL-Modem oder WDS Client etc.
return g_opmode ~= "opmode_eth_ipclient" and g_opmode ~='opmode_modem'
end
function is_dslmodem()
-- Wird die Box als DSL-Modem betrieben?
return g_opmode == "opmode_modem"
end
Die Box ist also entweder "eth_ipclient", dann ist "is_ip_client()" wahr oder sie ist "modem", dann ist "is_dslmodem()" wahr. Nur wenn beides nicht der Fall ist, wird "is_router()" jemals eine Chance haben, seinerseits "wahr" zu sein. Wenn das also nicht nur eine recht verquere boolsche Logik sein soll, wird sicherlich irgendwann noch ein weiterer Fall bei diesen Unterscheidungen Einzug halten und wir dürfen jetzt schon gespannt sein, welcher das sein wird. So ganz konsistent ist die Verwendung dieser Funktionen aus der general.lua auch noch nicht, denn die Prüfung, die sich hinter "is_router()" verbirgt ("not modem and not ip_client", was ohnehin gleich als "not (modem or ip_client)" geschrieben werden könnte - meine Meinung, Tricks mit "early result" nach teilweiser Auswertung sind hier unnötig), findet sich an vier weiteren Stellen in wechselnden Formulierungen.
Wenn sich da nicht ebenfalls etwas geändert hat, kriegt man so eine 7490-Box aber praktisch ohnehin nicht mehr in die Betriebsart "opmode_modem" - nur noch beim Umschalten alter WDS-Repeater auf "Basis" gibt es dazu etwas im Lua-Code für das GUI ... mal sehen, wann da aufgeräumt wird.
-And now something completely different ...
Heute erst habe ich mich wieder wegen des Vodafone-Zwischenfalls mit dem TR-069 beschäftigt und siehe da ... es hat den Anschein, als hätte AVM da tatsächlich etwas unternommen in der neuen Firmware und ich habe es erst im Zusammenhang mit den schon erwähnten erweiterten Support-Daten gefunden (keine Ahnung, seit wann es diesen Part schon gibt, suche ich jetzt auch nicht).
Es gibt in der Support-Seite jedenfalls eine Option "ProviderAccess" (vorerst wohl noch als "hidden"-Control), mit dem eine Option "upload_enable" bei den TR-069-Einstellungen geändert werden kann. Ab hier gehen die Spekulationen dann los, weil ich erst einmal die neue Version live sehen muß ... aber es sieht zunächst mal so aus, als wäre da ständig der Wert "ignore" enthalten - solange der nicht irgendwie per JavaScript geändert wird (aber eben das sieht man erst im Live-Betrieb).
Die Lua-Seite würde jedenfalls bei einem Roundtrip mit einem Wert "0" oder "1" in diesem Control (was man ja mit Developer-Tools problemlos hinkriegt) die erwähnte Einstellung ändern. Welche Konsequenzen das für die tr069.cfg hat und ob das überhaupt persistent ist, braucht ebenfalls einen Test am "lebenden Objekt", genauso wie die Feststellung, ob der Parameter wirklich die erwartete Auswirkung hat, nämlich die Abschaltung der
Upload-Funktion des TR-069-Interfaces (Punkt A.4.1.5 der Spezifikation). Das wäre für mich eine richtig gute Nachricht ... mal sehen, wie man die Box auf "normalem Weg" dazu überreden kann, diese Einstellung zu setzen. Bei den Einstellungen für die "Anbieterdienste" taucht das jedenfalls wohl noch nicht auf ... zumindest nicht offensichtlich bzw. in einer Form, die "von außen" sichtbar wäre.
EDIT:
Ok, also der Inhalt der Einstellung "tr069:settings/upload_enable" wird in der Variablen "upload_enable
d" im "FirmwareDownload"-Abschnitt der tr069.cfg verwaltet (als "yes"/"no"). Damit ist er an dieser Stelle (m.E.) aber auch jederzeit für den Provider selbst bei der Konfiguration erreichbar und damit wäre eine Einstellung für den Benutzer, die ausschließlich solche TR-069-Uploads verhindern soll, natürlich an der vollkommen falschen Stelle. Wenn der Provider das tatsächlich ändern kann, bringt es aus Benutzersicht nicht ein Jota zusätzliche Sicherheit.
Diese ganze
Verwendung der Einstellung "upload_enable" ist auch tatsächlich neu in dieser Labor-Version (also 31976), ich war schon schwer verunsichert, warum mir das vorher durchgerutscht sein sollte. Ob ich bei früheren TR-069-Tests schon einmal die Einstellung in der tr069.cfg ändern mußte, damit ein Upload-Request vom CPE akzeptiert wurde, weiß ich nicht mehr sicher ... im Zuge solcher Experimente ändert man an allen möglichen Stellen und das könnte damals tatsächlich untergegangen sein, daß es diese Einstellung auch früher schon gab. Da sie aber wohl in jedem Falle an einer Stelle sitzt, wo der Provider auch herankommt (notfalls auf Umwegen), ist damit - dabei bleibe ich - keine zusätzliche Sicherheit für den Kunden verbunden.
Hinzu kommt noch eine merkwürdige Konstruktion in der support.lua ... ob es tatsächlich so beabsichtigt ist, wie es derzeit dort gelöst ist, weiß ich auch nicht. Wegen der Konstruktion beim Setzen der Einstellung:
Code:
if next(box.post) and box.post.support_plus then
local saveset = {}
cmtable.add_var(saveset, "emailnotify:settings/supportdata_enhanced",
box.post.supportdata_enhanced and "1" or "0"
)
if box.post.ProviderAccess ~= "ignore" then
cmtable.add_var(saveset, "tr069:settings/upload_enable", [COLOR="#FF0000"]box.post.ProviderAccess and "1" or "0"[/COLOR])
end
local err = box.set_config(saveset)
end
wird dieser Wert (upload_enable) jedenfalls auch niemals auf "no" gesetzt werden, solange man in der Support-Seite den "Einstellungen übernehmen"-Button drückt. Anders als die Checkbox für "supportdata_enhanced" ist eben der Wert aus dem "hidden"-Control "ProviderAccess" immer im Request enthalten und die Konstruktion mit dem "ternären Operator" (das "x and a or b" ist das "x ? a : b" aus anderen Sprachen) wird immer den Wert "1" ergeben, da das zugehörige Control auch immer vom Lua-Code in die Seite geschrieben wird. Allerdings hat es eben normalerweise den Wert "ignore" und dann wird die Einstellung ja überhaupt nicht angefaßt. Da fehlt wohl noch einiges an Programmierung ... es ist eben auch das erste Mal, daß diese Variable überhaupt im GUI irgendwie
gesetzt wird.
Will man also tatsächlich mit den Developer-Tools eines Browsers den Wert in der Box ändern lassen, muß man das "ProviderAccess"-Control (zumindest bei dieser Version der Firmware) aus dem DOM entfernen, damit ein Request komplett ohne dieses Control erfolgt. Eine ausschließliche Änderung des von der Box übermittelten Wertes "ignore" setzt praktisch immer den Wert "1" für die Einstellung. Das sieht für mich noch sehr unfertig aus, ich rechne fest damit, daß sich bis zur nächsten Labor-Version da noch einiges tut ... vielleicht soll "ProviderAccess" ja wirklich mal als Checkbox-Control enden, dafür stimmt dann die Auswertung bereits, denn so eine Checkbox taucht im Request nur auf, wenn sie angehakt ist.
Der Unterschied in den Support-Daten beschränkt sich weitgehend darauf, daß zusätzlich zu den bisherigen Konfigurationdateien (wo nach wie vor die verschlüsselten Stellen wieder mit "SECRET" überschrieben werden) ein Dump der TFFS-Partitionen erzeugt wird - in der Datei /bin/supportdata.tffs. Diese sieht so aus:
Code:
#!/bin/sh
DUMP_DIR="/var/tmp/tffs-dump"
ENC_CERT="/var/flash/test.cert"
ENC_EXE="/bin/openssl_smime"
if [ "`echo emailnotify.supportdata_enhanced | ar7cfgctl -s`" = yes ]
then
for tffs in `sed -nr 'y/ /_/;s/^(mtd[0-9]+):.+"((nand-)*tffs(_\([12]\))*)"$/\2#\1/p' /proc/mtd`
do
mtd_dev="/dev/${tffs##*#}"
mtd_name="${tffs%%#*}"
mkdir -p "${DUMP_DIR}"
case "${mtd_name}" in
nand-tffs*)
nanddump --bb=dumpbad --forcebinary --oob ${mtd_dev} | gzip -1 -c > "${DUMP_DIR}/${mtd_name}.dump.gz"
;;
*)
cat ${mtd_dev} | gzip -1 -c > "${DUMP_DIR}/${mtd_name}.dump.gz"
;;
esac
done
if [ -d "${DUMP_DIR}" ]
then
echo "##### BEGIN SECTION TFFS_DUMP TFFS Dump"
if [ -x "${ENC_EXE}" -a -e "${ENC_CERT}" ]
then
tar -c "${DUMP_DIR}" 2>/dev/null | \
${ENC_EXE} -encrypt -binary -aes256 -subject tffs-dump.tar -outform SMIME "${ENC_CERT}"
else
tar -c "${DUMP_DIR}" 2>/dev/null | base64
fi
echo "##### END SECTION TFFS_DUMP"
rm -rf "${DUMP_DIR}"
fi
fi
if [ -e /proc/tffs -a -e /dev/debug ] ; then
echo index > /proc/tffs
echo AVMDBG_EOF 1 >/dev/debug
grep -E '\[TFFS\]' /dev/debug
echo AVMDBG_EOF 0 >/dev/debug
fi
Kurz geschaut (ok, vergleichsweise kurz), was da passiert ...
- erst prüfen, ob erweiterte Daten zugelassen sind, das wird über die support.lua und die dortige Checkbox geregelt
- Dump der Partitionen erzeugen (offenbar gibt es auch Boxen mit dem TFFS im NAND, die 4020 war glaube ich so eine - zumindest hatten wir letztens mal so ein Modell - es könnte aber auch die 7412 gewesen sein)
- der Dump wird dann mit "gzip" noch einmal gepackt ... die Angabe von "-1" kann man zwar als guten Willen interpretieren, ein bereits gepacktes Filesystem nur noch mit wenig Aufwand erneut einem Versuch des Packens zu unterziehen - das Problem ist nur, daß das gzip der Busybox alle "-n"-Angaben geflissentlich ignoriert (aus gzip.c der Busybox 1.23.2):
Code:
opt = getopt32(argv, "cfv" IF_GUNZIP("dt") "q123456789n");
#if ENABLE_GUNZIP /* gunzip_main may not be visible... */
if (opt & 0x18) // -d and/or -t
return gunzip_main(argc, argv);
#endif
[COLOR="#FF0000"] option_mask32 &= 0x7; /* ignore -q, -0..9 */
[/COLOR] //if (opt & 0x1) // -c
//if (opt & 0x2) // -f
//if (opt & 0x4) // -v
argv += optind;
- anschließend wird versucht, das Programm "/bin/openssl_smime" und ein Zertifikat "/var/flash/test.cert" zu finden (Spoiler-Alarm: es existiert in dieser Labor-Version keines von beiden), damit würde das Ausgabeverzeichnis für die Dumps mit tar gepackt und mit OpenSSL verschlüsselt
- nun gut, wir haben erst mal kein openssl_smime, also wird das Verzeichnis nur mit tar gepackt und das Ergebnis von "base64" in genau dieser Base64-Kodierung ausgegeben, womit es 1:1 in der Support-Datei landet
Damit ist das mit der Aussage
GUI 06.36-39176 schrieb:
Die Supportdaten enthalten in diesem Fall auch Kennwörter in verschlüsselter Form.
auch genau nur so zu lesen, wie es da steht ... die Daten sind zwar verschlüsselt (das sind sie ja schon in der Box selbst), das heißt aber noch lange nicht, daß man sie nicht auch wieder entschlüsseln kann anhand der Daten im TFFS-Dump.
Der Dump einer einzelnen TFFS-Partition enthält schon alle Angaben, die es dazu braucht, weil auch das Urlader-Environment (mit der Angabe von "maca" und "wlan_key") dort vollständig enthalten ist. Selbst wenn man mal unterstellen will, daß AVM keine entsprechende Datenbank mit den MAC-Adressen und den Keys hat (wobei die bei der Produktion ja auch irgendwie verwaltet werden müssen und auch die Aufkleber hinten auf den Boxen sind sicherlich nicht handgemacht), sind diese Daten trotzdem zu 100% zu entschlüsseln (zumindest bisher und bei der hier diskutierten 7490).
Also sollte man die Warnung in der Support-Seite
support.lua schrieb:
Wählen sie diese Option nur, wenn Sie von AVM dazu gebeten werden.
sehr ernst nehmen (unabhängig von der falschen Formulierung ... schreibt man "dazugebeten" nicht zusammen
mrgreen: im Sinne von "eingeladen" - ok, Spässle g'macht) und hat die neue deutsche Rechtschreibung tatsächlich die Großschreibung des "Sie" in der Anredeform abgeschafft? Warum dann nicht immer? Ok, das "S" lassen wir als Tippfehler durchgehen - trotzdem bitte korrigieren.).
Wenn man sie dann doch einmal verwendet, muß man vielleicht auch noch beachten, daß für eine Änderung der Einstellung unbedingt der "Einstellung übernehmen"-Button verwendet werden muß. Wer nur die Checkbox an- oder abhakt und anschließend auf "Support-Daten erstellen" geht, darf nicht erwarten, daß die geänderte Einstellung in der Checkbox berücksichtigt wird - das sind zwei getrennte HTML-Formulare, was man im Browser nicht sieht.
EDIT2:
Wenn man sich das noch einmal genauer durchliest, was da unter "erweiterte Supportdaten" beschrieben wird, ist das offensichtlich doch noch extremer "work in progress" als es auf den ersten Blick den Anschein hat.
Die Aufzählung der zusätzlichen Daten stimmt nämlich noch nicht so ganz ... die VPN-Logs und das Eventlog sind schon bei den "normalen" Supportdaten dabei. Neben dem schon erwähnten TFFS-Dump ist eigentlich nur noch die Ausgabe des Kommandos "showshringbuf invite" und die Ausgabe der kompletten Anrufliste derzeit zusätzlich bei den "erweiterten Support-Daten". Das mit der Ausgabe der SIP-INVITES in einen getrennten Ringbuffer ist insofern witzig, als die alle auch (noch?) im "normalen" SIP-Ringbuffer stehen (showshringbuf sip) und der immer noch Bestandteil des "kleinen" Support-Files ist. Diese INVITE-Protokolle sind also im Moment doppelt. Die Anrufliste ist die mit dem Kommando "telefon --calllog" erzeugte Text-Liste der letzten 400 Anrufe (mehr speichert die Box ja nicht) unter /var/tmp/telefon.log, die 1:1 kopiert wird.
Nehmen wir mal an, daß AVM die Support-Daten bis zum Release noch an die Aussagen in der GUI anpassen wird. Lieber wäre mir zwar immer noch die Möglichkeit, ganz gezielt nur bestimmte Daten eines einmal komplett gesicherten Zustands an AVM übermitteln zu können (nach so einem "snapshot" wären die auch noch bei "Nachforderungen" zueinander passend) - wenn es ein Problem mit der Telefonie gibt, ist im ersten Anlauf sowohl das VPN als auch DynDNS, usw. (die Liste ließe sich lange fortsetzen) ja wohl außen vor und dann muß man nicht gleich komplett die Hosen runterlassen. AVM hat auch zur Auswertung der Support-Daten entsprechende Software, die die Ausgabe übersichtlicher darstellen kann ... da geht keiner hin und liest diese Dateien Zeile für Zeile. Es kann also nicht wirklich ein Problem sein, die Support-Daten grob nach Themen zu ordnen und dann nur jeweils die Daten auszugeben (meinetwegen sogar direkt in Kopie an den Support zu senden), die zum Problem passen. Wenn der Kunde ein WLAN-Problem hat, braucht AVM die Anrufliste nicht und auch nicht die Telefonnummern des betroffenen Kunden. Wenn die bisher komplett ausgegebenen Supportdaten erst einmal als Schnappschuß in der Box gespeichert würden (zumindest bei NAND-Boxen eigentlich gar kein Problem und da rede ich nicht von /var/media/ftp), dann könnte man in einem zweiten Schritt hingehen und eben die Auswahl einzelner "Pakete" aus diesem Snapshot zu einer Datei zusammenstellen - braucht man später wirklich noch andere Sektionen (das ist ja nicht immer von Beginn an klar), kann man die immer noch einmal ausgeben lassen. So würde ich mir das jedenfalls vorstellen und dann wäre ich persönlich auch viel öfter bereit, AVM irgendwelche Daten zusammen mit einer Fehlermeldung zu übermitteln.
Die Warnung vor dem Einschalten der "erweiterten Support-Daten" aus reinem Spieltrieb will ich trotzdem noch einmal betonen ... die Einstellung wird gespeichert und gilt z.B. auch dann, wenn aus der Diagnose-Seite heraus die Ergebnisse als Push-Mail gesendet werden. Ob dann jeder immer daran denkt, daß die dort ebenfalls enthaltenen Support-Daten bis zum Löschen im Postfach herumliegen und sowohl für den Mail-Provider als auch für einen erfolgreichen Angreifer auf das Postfach erreichbar sind, würde ich bezweifeln. Wenn sich dann die Möglichkeit herumspricht, daß in so einer Mail ein Dump der Einstellungen einer FRITZ!Box zu finden sein könnte, ist ein entsprechender Harvester, der E-Mails mit dem Betreff "FRITZ!Box-Diagnose" gezielt nach solchen TFFS-Dumps durchsucht, schnell erstellt.
Stehen da auch noch DynDNS-Daten drin in den Settings (kann auch ein MyFRITZ!-Konto sein), ist so eine Box ja auch leicht wieder gefunden im großen weiten Internet, damit man mit den gewonnenen Daten auch etwas anfangen kann. Also nochmal ... diese "erweiterten Support-Daten" immer wieder ausschalten, auch nach eigenen Versuchen an dieser Stelle. Sollte allerdings AVM die Support-Daten so einteilen, wie der Text es vermuten läßt, braucht man künftig für die Diagnose von VPN-Problemen die erweiterte Form, wenn die VPN-Protokolle dann nicht mehr zum Standardumfang gehören.
