Re: Gravierende Sicherheitslücke, neue Firmware

[sjw at gmx.ch]

Hallo

Da heute in den Medien über eine Sicherheitslücke in WLAN Geräten [1]
berichtet wurde, möchte ich das Thema nochmals aufgreifen.
Vorweg: Freifunk an sich ist davon nicht betroffen - den das Netz ist ja
sowieso offen und wird auf dem Router mittels VPN verschlüsselt.
Aber: Wenn ihr in den erweiterten Einstellungen des Freifunk Routers die
Option "Privates WLAN" aktiviert habt, ist dieses Netz betroffen.

Das Dilemma ist, dass vermutlich nur wenige Hersteller ein Update für
die Firmware des Routers bereit stellen werden. Und wenn, dann
vermutlich nur für die aktuellen Top Modelle.

Die Freifunk Software Gluon basiert auf LEDE, bzw. OpenWRT, und dort
wurde das ganze bereits gefixt (David wird uns sicher bald eine neue
Firmware bauen? ;) ).
LEDE und OpenWRT gibt es aber nicht nur für Freifunk-Kompatible Router,
sondern für unzählige weitere Modelle. Eine Liste findet sich hier:
https://lede-project.org/toh/start

Das Bekanntwerden der Sicherheitslücke wäre also ein guter Zeitpunkt, um
zu erwägen, ob man auch auf seinen nicht-Freifunk Routern LEDE
installieren möchte.
Da Gluon auf LEDE basiert, kann am Ende auch Freifunk davon profitieren,
wenn mehr Leute LEDE nutzen.

Lg
Jonas


[1] https://www.krackattacks.com/



Am 07.10.2017 um 15:07 schrieb David Lutz via ff3l:
> Ich möchte bei dieser Gelegenheit eh darum bitten, dass jeder, der einen Knoten in greifbarer Nähe hat, an den er jederzeit und problemlos herankommt, und bei dem es nicht überlebensnotwendig ist wenn eventuell mal Probleme auftreten, diesen auf den experimental-Zweig umstellt.
> Uns wird immer vorgeworfen, wir würden die Firmware immer viel zu früh freigeben und zu wenig testen. Fakt ist: Ich teste überall wo es möglich ist. Und wenn bei den Testknoten keine Probleme auftreten, ist sie OK und kann freigegeben werden.
> Dieses Jahr hatten wir mehrmals Probleme mit Firmware, bei der der Autoupdater buggy war. Zuerst hing der Autoupdater, so dass sich der Knoten gar nicht mehr aktualisiert hat wenn er eine gewisse Weile in Betrieb war. Das war mit Firmwareversion 2016.2.1-4 und wurde mit .5 behoben. Dann hatten wir mit der Umstellung auf LEDE das Problem mit x86-Hardware und der Partitionsgröße. Dies wurde in 2016.2.6 behoben, die ich vor dem Update auf 2017.1 für alle x86-Geräte dazwischengeschoben habe. Dann war das Problem in 2017.1.0 und 2017.1.1, dass beim Update als erstes alle Dienste gestoppt werden und das Mesh-Netz deaktiviert wird. Nun kam es vor, dass das sysupgrade fehlschlägt und abstürzt, dadurch aber die Dienste und die Verbindungen nicht wieder gestartet werden. Dadurch ist dann gut ein Drittel der Knoten beim Update gehangen, was sich aber durch einen einfachen Neustart beheben ließ. In unserer aktuellen stable 2017.1.2 ist dieses Problem bereits gepatcht, so dass es eigentlich zu keinen größeren Ausfällen kommen kann. In der ersten 2017.1 gab es einen Bug mit den Ubiquiti Picostations, der schnell mit 2017.1.1 behoben wurde. Da ich keine Picostation besitze, und auch niemand anderes eine Picostation auf experimental hatte, ist dieser Fehler trotz Abwartens niemand aufgefallen. Ein ähnliches Problem hatten wir mit dem Allnet ALL0315N in Säckingen auf dem Münsterplatz, der jedes mal beim Updateversuch abgeschmiert ist.  Konnte niemand testen, weil niemand anderes dieses sündhaft teure Gerät besitzt. Nicht mal die Gluon-Entwickler. Wurde mit 2017.1.2 behoben, seitdem hat dieser Knoten auch wieder die aktuelle Firmware drauf. Mit den ersten 2017.1-Releases kam ein Bug zum Vorschein, der ein Multicast-DDOS im Mesh ausgelöst hat. Ließ sich durch unsere Tests nicht herausfinden, weil das Problem erst ab einer gewissen Zahl Knoten im Mesh auftritt.
> Man sieht also: Durch reines Abwarten ist nichts gewonnen. Firmware reift nicht wie alter Käse nur durch liegen lassen.
> Bitte benutzt, wenn es euch möglich ist, den Experimentalzweig, gebt Feedback und helft mit den Software-Stand unseres Meshes aktuell zu halten. Freifunk lebt vom Engagement vieler, nicht nur einzelner.


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.ff3l.net/pipermail/ff3l/attachments/20171017/cc95f025/attachment.sig>