[Info] featovl.cfg - Beschränkungen seit 07.00

[PeterPawn]

Weil es m.W. noch niemand im IPPF schriftlich festgehalten hat, hier noch eine "nachgelieferte" Feststellung bzgl. der "featovl.cfg" seit der Version 07.0x (bzw. seit Labor 06.98).

Während man bis zu dieser Version in der erwähnten Datei noch alle möglichen Variablen überschreiben konnte, solange sie nur auf die Maske ^CONFIG_[a-zA-Z0-9_]*=[a-zA-Z0-9]\+$ paßten (also auch "CONFIG_RELEASE" usw.), hat AVM die boxfeaturedisabled seitdem um eine "check"-Option erweitert und so wird nunmehr - sofern die /bin/boxfeaturedisable existiert in der Firmware - beim Start erst einmal diese Datei mit der passenden Option aufgerufen:

##########################################################################################
## ovl
##########################################################################################
if ! checkempty /var/flash/featovl.cfg 2>/dev/null ; then
if [ -x /bin/boxfeaturedisable ] ; then
/bin/boxfeaturedisable --check "`cat /var/flash/featovl.cfg`" &>/dev/null
for featovl in `cat /var/flash/featovl.cfg | grep "^CONFIG_[a-zA-Z0-9_]*=[a-zA-Z0-9]\+$"`; do
export ${featovl}
done
fi
fi

Da dieser Aufruf dann jeden Eintrag in dieser Datei killt, der nicht zu den von AVM genehmigten Variablen gehört:

case $i in
CONFIG_WLAN=[yn]) ## wlan
echo "[$0]: accept cmd ${i}"
echo ${i} >> ${featovl_tmpfile}
;;
CONFIG_DECT=[yn]) ## dect
echo "[$0]: accept cmd ${i}"
echo ${i} >> ${featovl_tmpfile}
;;
CONFIG_CAPI_NT=[yn]) ## S0-NT / Isdn
echo "[$0]: accept cmd ${i}"
echo ${i} >> ${featovl_tmpfile}
;;
CONFIG_USB=[yn]|CONFIG_USB_HOST=[yn]|CONFIG_AURA=[yn]|CONFIG_NAS=[yn]|CONFIG_USB_GSM=[yn]|CONFIG_USB_STORAGE=[yn]|CONFIG_MEDIASRV=[yn]) ## Massenspeicher
echo "[$0]: accept cmd ${i}"
echo ${i} >> ${featovl_tmpfile}
;;
CONFIG_LINEARTV=[yn]) ## lineartv
echo "[$0]: accept cmd ${i}"
echo ${i} >> ${featovl_tmpfile}
;;
*)
echo "[$0]: unknown or unsupported cmd ${i}"
;;
esac

, funktioniert also für viele Features das versuchsweise Abschalten über diese Datei (z.B. für POTS bei FPGA-Problemen) nicht mehr.

Wer das ansonsten noch benutzt, um z.B. bei einer installierten Firmware mal schnell den "Typ" zwischen "öffentlich" und "privat" umzuschalten (das sind dann CONFIG_RELEASE bzw. CONFIG_BETA_RELEASE) oder irgendeine Feature-Variable für Tests zu verändern (ohne das gleich in eine neue Firmware einzubauen, die dann erst mal installiert werden müßte), der müßte dann den Aufruf von /bin/boxfeaturedisable --check ... aus der rc.conf in der Firmware entfernen - ansonsten sind alle Änderungen in der Datei, die über die oben gezeigten Variablen hinausgehen, wieder verschwunden nach jedem Aufruf der rc.conf (und die wird gerne mal "außer der Reihe" - also abseits des Starts - aufgerufen). Das gilt auch für die aktuelle Laborreihe ... denn auch da wird - trotz geändertem Ablauf beim Start - irgendwann noch die "legacy version" in der /etc/init.d/rc.conf aufgerufen.

Zumindest kann damit auch kein Angreifer mehr durch ein TFFS-Image mit einer entsprechenden featovl.cfg die Firmware einfach auf den "privaten" Modus schalten und damit dann wieder Code über die /var/flash/calllog ausführen lassen - ich hatte das Beseitigen dieser Lücke durch AVM bisher noch nicht ausreichend gewürdigt, nachdem ich sie vor 1 1/2 Jahren aufgezeigt hatte: https://www.ip-phone-forum.de/threa...ben-der-var-flash-calllog.299002/post-2270213

Das zweite Problem bzw. den zweiten Angriffsvektor aus diesem älteren Beitrag (von AVM höchstselbst signierte Firmware-Images mit Shell-Zugängen, die eine reguläre Firmware ersetzen konnten) hatte AVM ja bereits zwischendrin dadurch gelöst, daß diese "Inhouse-Versionen" mit einem eigenen Key signiert wurden und sich daher nicht mehr ohne weiteres über eine andere Firmware installieren ließen.

 

[eisbaerin]

der müßte dann den Aufruf von /bin/boxfeaturedisable --check ... aus der rc.conf in der Firmware entfernen

Ja, ist schon seit Ewigkeiten bei mir ein eigenes modscript.
Und damit erlaubt es bei mir sogar Einträge ohne "CONFIG", so daß man wie früher auch "OEM=avm" oder "ANNEX=A" setzen kann.

Bei freetz gibt es das aber IMO noch nicht.

seit der Version 07.0x (bzw. seit Labor 06.98).

Stimmt nicht ganz, denn diese Schikane wurde auch in die FW der 7272-06.87 und 7412-06.86 eingebaut.
Und ich vermute auch in die letzten FW der 3390/7312/7370/7330SL/3370 06.55 und selbst in die 7320-06.34, 7360_SL-06.34 und 7360-06.35.

Einzig meine geliebte 7170 ist davon noch verschont geblieben.

Aber jetzt wissen wir ja endlich wem wir das zu verdanken haben.
Vermutungen hatte ich ja schon, aber ich wollte, daß sich der Täter freiwillig zu erkennen gibt.

 

[PeterPawn]

Stimmt nicht ganz,

Ja, ich hätte vermutlich genauer schreiben sollen: "... seit der Zeit, in der FRITZ!OS 7 entwickelt und veröffentlicht wurde." - wobei das eben auch zeigt, wie genau die Angaben von AVM zu ausgeführten Änderungen bei diesen "Wartungsversionen" tatsächlich sind, denn das wird (m.W.) mit keiner Silbe erwähnt bzw. ich könnte es den Angaben:

- Verbesserung - Zertifikate aktualisiert
- Verbesserung - Stabilität angehoben
- Verbesserung - Automatisches Software-Update für FRITZ!Fon M2

(Beispiele aus der 7412 06.86)
nicht wirklich entnehmen, daß auch an dieser Stelle Änderungen vorgenommen wurden.

Letztlich führt das halt auch dazu, daß Benutzer diese Versionen nicht direkt als "notwendig" erkennen (schon wegen des Risikos beim Update), weil sie über weitere Security-Enhancements gar nicht korrekt informiert werden - die "allgemeine Feststellung" von AVM, daß mit jedem Update auch Security-Fixes einhergehen würden/könnten, ist eben nur "Wischi-Waschi" und führt nur bei "Update-Junkies" (die diese Info auch nicht brauchen, weil sie ohnehin jede neue Version sofort installieren) zu entsprechender Aktivität.

Zumindest ist es mit den Update-Versuchen ja (meiner Meinung nach jedenfalls) etwas besser geworden in "freier Wildbahn", seitdem sich die Möglichkeit herumgesprochen hat, daß man so ein Update (bei den neueren Modellen mit zwei Systemen) auch wieder rückgängig machen kann, ohne gleich die ganze Box neu aufsetzen zu müssen (auch ein "restore" stellt ja bekanntlich nicht 1:1 den alten Zustand wieder her) nach einem Downgrade oder irgendwelche Konfigurationsorgien erneut zu starten (Stichwort Mesh oder auch "Vor-Ort-Pflicht" bei Werkseinstellungen durch die 2FA - was beim Rücksetzen eines Gerätes eben auch "Turnschuh-Administration" erfordert).

------------------------------------------------------------------------------------------------------------

Ob ich tatsächlich "der Täter" war, weiß ich gar nicht wirklich ... ich hatte das - neben dem o.a. IPPF-Beitrag, wobei ich davon ausgehe, daß AVM hier mitliest - gar nicht gesondert gemeldet, weil es sich ja eindeutig nicht um eine "Fehlfunktion", sondern gezielt von AVM programmiertes Verhalten handelte, aus dem sich halt nur - quasi als Nebenwirkung - auch eine denkbare Sicherheitslücke ergab.

Der IPPF-Beitrag lag halt deutlich vor den ersten Aktivitäten von AVM in dieser Richtung, daher gehe ich einfach davon aus, daß man sich da entweder ohnehin Gedanken gemacht hätte (wobei mich dann wieder die Frage quält, warum man das überhaupt reaktiviert oder weiterhin gepflegt hat - was da richtig ist, habe ich immer noch nicht geprüft anhand einer alten 06.3x oder so) oder daß man eben hier davon "in Kenntnis gesetzt" wurde und sich danach etwas überlegt hat.

Am Ende ist das jetzt ja doch die von mir im März 2018 angesprochene Whitelist, wenn nur noch Einstellungen aus dem eingeschränkten Wertebereich in der boxfeaturedisable geändert werden können auf diesem Weg.

 

[eisbaerin]

seit der Zeit, in der FRITZ!OS 7 entwickelt und veröffentlicht wurde.

Genau deswegen hat es mich z.B. auch sehr verwundert, daß AVM bei der 7272-06.87 in der S15-filesys kein "noexec" eingebaut hat, wie es jetzt allgemein üblich ist.