Vollversagen bei OpenSSH: Is a directory

Nehmt es mir nicht übel, aber anders als ein komplettes Versagen auf ganzer Linie kann man den Fall bei OpenSSH nicht bezeichnen, zumal es um einen kleinen, aber sinnvollen Bugfix geht.

Vollversagen bei OpenSSH: „Is a directory“

Damit Ihr versteht um was es geht, müssen wir zurückreisen ins Jahr 2010. Damals wurde ein Bugreport im Bugtracker von OpenSSH veröffentlicht: https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Von dem wußte ich aber nichts, als ich 2015 über das Problem gestolpert bin. Das Problem sieht wie folgt aus:

scp testdatei user@servername:/topdir/subdir/

Wenn es „subdir“ als Directory gibt, dann wird testdatei dahin kopiert und alles ist gut. Wenn es „subdir“ aber nicht gibt, dann würde man ja wohl erwarten, eine Fehlermeldung zu bekommen, aus der genau das hervorgeht, oder? Tja, wie soll ich sagen, ähm…nein!

Actual results:

scp: /usr/doesnotexist/: Is a directory

Wow.. oder? Das komplette Gegenteil von dem was man annehmen würde 🙂 Diese Aussage bekommt jeder, der sich OpenSSH selbst aus den original Sourcen kompiliert, denn, obwohl der Fehler schon 2010 gemeldet wurde und 2015 Jakub Jelen von Red Hat einen kompletten Patch geschrieben hat und das seit Fedora 20 und RHEL8 an alle „Nutzer“ in einem „Feldtest“ ausgerollt wurde, sieht sich das Projekt hinter OpenSSH nicht dazu in der Lage.

Eingeführt wurde der Bug übrigens um das Jahr 2005 herum. Damit sind es streng genommen schon 15 Jahre, die der Bug da vor sich hin dümpelt. Da ich Fedora nutze, habe  ich das Problem nicht mehr und viele andere Distros haben den RH Patch übernommen, aber traurig ist das schon, oder?

Leider mußte ich gerade feststellen, daß die neue Fehlermeldung auch nicht gerade viel besser als die alte ist:

scp: /tmp/ugdjkfh/: Not a directory

Das stimmt zwar inhaltlich, gibt aber den wahren Ursprung meiner Meinung nach nur unzureichend wieder 😉 Daher war ich mal so frei, Jakub darauf hinzuweisen, zumal ich den Bug da auch bei RH reportet hatte, vielleicht bekommt man nach 10 Jahren dann doch nochmal ein „Does not exist“ 😀 Wobei man als Server ja unterscheiden können muß zwischen „directory gibts nicht“ und „Du User, darfst da nicht reinschreiben“ unterscheiden wenn so eine Anfrage kommt, sonst könnte ein User niedriger Privilegierung die Verzeichnisstruktur einfach durchtesten. Ok, er könnte das viel einfach, wenn er eingeloggt wäre, aber ggf. hat der Account nur SFTP Zugang, ohne Interaktiven Shellzugang zu haben. Wäre ja denkbar.

Wie man sieht, doch nicht ganz trivial so eine saubere Fehlermeldung 😉

Wenn Ihr jemanden im OpenSSH Team kennt, könnt Ihr Ihn ja mal auf dieses Problem ansprechen. Übrigens erinnert mich das ganz stark an meinen Bugreport an ProFTP, weil deren 20 Jahre alte CHROOT Anweisung den Fall, daß da einer das Ziel per Symlink umgeleitet hat, nicht abgedeckt hatte. Das wurde auch Jahrelang geblockt bis es dann doch wer geschafft hatte, die Entwickler umzustimmen. Leider durfte ich mit dem 20 Jahre Bug-Jubiläumsvortrag nicht auf dem CCC sprechen. Dabei wollte ich nur son 15 Minuten Vortragsfenster im Nebenraum haben. Ich hatte denen sogar einen Patch für das Problem geschickt. Das wäre bestimmt lustig geworden, wenn die ProFTP Devs sich auf der Vortragsliste gesehen hätten 😀 Vielleicht packe ich Euch den Vortrag als PDF mal auf die Seite.

Ein Args für netstat

Wenn Dinge nicht so funktionieren, wie sie sollten, dann liegt das oft daran, daß falsche Entscheidungen getroffen wurden. Bei dieser Entscheidung geht es um netstat und IPv6.

Ein „Args!“ für netstat

netstat zeigt einem die Verbindungen, Sockets und Ports an, die auf einem Linux PC verfügbar sind. Solange es dabei um TCP und IPv4 Adressen geht, ist alles ok. Wenn man aber ein Problem mit einer IPv6 Adresse hat, dann sollte man sich informieren, weil netstat dummerweise IPv6 Adressen unvollständig anzeigt… ohne Warnung übrigens.

Nun würde man ja annehmen, daß ein „man netstat“ alles wissenswerte zu den Optionen von netstat anzeigt, oder? Tja, Pech gehabt liebe deutschsprechende Gemeinde, Ihr seid leider am Allerwertesten 🙂

BESCHREIBUNG
Netstat zeigt Informationen des Linux Netzwerkssystems an.

Bitte beachten Sie, dass der Inhalt der deutschen man-page nicht vollständig ist,im Moment.

„nicht vollständig“ ist eine leichte Untertreibung und dieser „Moment“ hält auch schon seit 2007 an 🙁 Tief durchatmen. Es gibt ja noch eine englische Originalversion. Aber wie kommt man da ran? Fragen wir doch mal „man man“ dazu …

Handbuchseiten finden
-L Locale, –locale=Locale
man wird in der Regel Ihre aktuelle Locale durch einen Aufruf der C-Funktion setlocale(3) bestimmen, welche verschiedene Umgebungsvariablen auswertet (darunter sind eventuell auch $LC_MESSAGES und $LANG). Um den ermittelten Wert vorübergehend außer
Kraft zu setzen, können Sie man mit dieser Option eine Locale vorgeben. Beachten Sie, dass dieser Wert erst wirksam wird, wenn die Suche tatsächlich beginnt. Programm-Meldungen wie Hilfe-Nachrichten werden immer in der zu Anfang ermittelten Locale
angezeigt werden.

Also tun mir mal, was da exemplarisch nicht steht: „man -L EN_en.UTF8 netstat“ und plötzlich haben wir Zugriff auf alle Infos zu allen Optionen, die in der deutschen Version nicht mal angedeutet wurden. Wer auch immer das übersetzt und dann auf die Deutschen losgelassen hat, mochte uns wohl nicht.

Zurück zum Problem: Die IPv6 Adressen werden abgeschnitten

Lösung:

–wide, -W
Do not truncate IP addresses by using output as wide as needed. This is optional for now to not break existing scripts.

Nun, die Begründung verschlägt einem ja praktisch die Sprache. Da IPv4 Adressen nicht verkürzt werden müssen, sieht man den Bug selten, bis man mal IPv6 braucht. Wer sein Script aber ohne IPv6 Support gebaut hat, der kann mit der Ausgabezeile eh nichts anfangen, weil da dann zu viele „:“und zu wenige „.“ in den IPs drin sind. Vorhandene Scripts stolpern also vermutlich sowieso über IPv6, da hätte man die IPs auch komplett ausgeben können.

Noch cleverer wärs gewesen, die Ausgabe wie „less“ oder „vim“ erzeugen zu lassen, die scrollen einfach nach rechts, wenn man die Cursorsteuertaste „->“ benutzt. Wenn man also keinen Platz mehr in einem 80-Spalten Terminal hat, dann macht man sich halt welchen, aber verkürzt sicher nicht wichtige Informationen.

Warum man nicht ss benutzt?

„ss“ ist der „Nachfolger“ von netstat, aber IMHO, und mit der stehe ich wohl nicht ganz alleine dar, ist die Ausgabe von ss unverhältnismäßig unübersichtlich :

Beispiel:

$ ss -6 -t -p

ESTAB 0 0 [::ffff:127.0.0.1]:58772 [::ffff:127.0.0.1]:mysql users:((„java“,pid=1525,fd=59))

$ netstat -lnapW

tcp6 0 0 127.0.0.1:58772 127.0.0.1:3306 VERBUNDEN 1525/java

Was ist jetzt einfacher zu lesen? Es steht zwar das gleiche an Information zur Verfügung, aber es ist einfacher zu erfassen finde ich.

CoronaChroniken: Corona-App öffnet Angriffen Tür und Tor

Liebe Kasernierte,

da nächste Woche die Corona-App der Bundesregierung (offiziell) lanciert werden soll, ist es Zeit da mal vor zu warnen.

CoronaChroniken: Corona-App öffnet Angriffen Tür und Tor

Solche Grafiken sind die beste Argumentationshilfe überhaupt.

Kommen wir zur Corona-App:

„Wenn wir in den kommenden Wochen einige Millionen Bürger von der App überzeugen, dann bin ich schon zufrieden“ (Jens Spahn).

Ich vermute, daß es dazu nicht kommen wird, denn die App schaltet dauerhaft Bluetooth ein. Bluetooth ist bekannt dafür den Akkustand zu drücken, denn anders als sonst, wird Bluetooth auch wirklich benutzt, um aktiv nach anderen Coronakennungen zu suchen. Das dürfte schon ohne weitere Informationen zum Thema dafür sorgen, daß es aus vielen Handies nach einigen Tagen wieder entfernt wird.

Diese Art der Selbsthygiene ist auch dringend nötig, denn Bluetooth hat eine Sicherheitslücke, die auf nahezu allen bislang gebauten Geräten vorhanden ist:

Managed to reproduce BIAS (Bluetooth Impersonation Attack) CVE 2020-10135.
Impersonation of any previously paired and connected Bluetooth device in
vulnerable setup. Reproduction on Linux host and Samsung S3 Neo+ mobile.

More info in the repo:
https://github.com/marcinguy/CVE-2020-10135-BIAS

Diese Lücke kam erst vor wenigen Tagen ans Licht. Kurz gesagt, jeder kann einem verwundbarem Geräte(so ziemlich alles was Android fährt) vorgaukeln ein anderes, früher bereits gepairtes Gerät zu sein. Je nachdem welche App dann mit Daten versorgt wird, kann der Angreifer von da an prinzipbedingt weitere Schwachstellen in Prozessen exploiten, von der offensichtlichen Lücke, sich z.B. als Lautsprecher auszugeben und Audio abzugreifen ganz zu schweigen.

Und diese Lücke ist nur eine von vielen, die ungepatcht durch die Handyhersteller, auf alten Geräten warten.

A.d.R. wer mit BT Kopfhörern rumrennt, wird von den CVEs nichts mitbekommen, bis seine Wiedergabeliste so merkwürdige Einträge enthalten wird.

Merke:

Bluetooth ist auf alten Geräten eine komplette Sicherheitslücke und gehört abgeschaltet!

Da wären z.B. noch CVE-2020-0022, eine Lücke mit der man durch Bluetooth Pings an Teile des Hauptspeichers kommt, weil es da wohl an Sanitychecks mangelt. Stichwort: negative memcpy-Länge args!

Das ist zwar im aktuellen Android durch Google gefixt worden, aber wieviele Handies haben das schon und wieviele mehr werden diesen Patch nie sehen, weil sie noch AOS 4,5,6,7 fahren? Die völlig verkappte Updatepolitik von Google und den Handyherstellern sorgt für unsichere Geräte. Was war so schwierig daran, die Treiber per OTA zu updaten ohne gleich Kernelreinstalls zu machen? {Irgendeine Gottheit} sei dank, wird sich das ja jetzt mit den reinen Linuxsmartphones beheben. Android kommt mir jedenfalls nicht mehr auf irgendwelche Geräte.

In 2019 hatten wir dann noch diese lustige Lücke, wo man durch gezielte Pakete die Verschlüsselung von Verbindungen bis auf NSA Niveau erniedrigen konnte:

https://arstechnica.com/information-technology/2019/08/new-attack-exploiting-serious-bluetooth-weakness-can-intercept-sensitive-data/

Auch die ist in AOS 4,5,6,7 nicht behoben worden.

Welchen Grund sollte man also haben, einen Chip mit Strom zu versorgen, der bestenfalls nur den Akku schnell entleert, aber schlimmstenfalls das Gerät kapern lässt? Der informierte Leser hat jedenfalls keinen.

Das waren die Rahmenbedingungen unter denen eine Corona-App laufen soll, kommen wir zum Knackpunkt der Sache: die App selbst.

Die zentrale dezentrale Lösung der Bundesregierung

Versprochen hatte man uns die dezentrale Lösung, also alle Daten auf den Smartphones und keinen zentralen Server. Bekommt habt Ihr jetzt: viele Daten auf dem Smartphone und … einen Zentralserver von dem sich Euer Handy eine Liste mit Kennungen zum Abgleich mit Euren lokalen Daten zieht. Dazu muß aber regelmäßig nachgesehen werden, ob es da Updates gibt. Außerdem mußte eine Trollvermeidungsstelle eingerichtet werden bei der Telekom 😀

Wie regelmäßig der Datenabgleich ist, habe ich derzeit nicht zu Hand, aber zu lange Perioden werden es nicht sein, sonst wäre das nämlich komplett unsinnig. Eine Woche nach dem Infektionszeitpunkt brauche ich die Info nicht mehr, da liege ich schlimmstenfalls schon im Bett oder habe gemerkt, daß ich mich nicht angesteckt habe. Ergo wird das im Stundenbereich liegen.

Eine rein dezentrale Lösung konnte schon gar nicht sein, weil irgendwoher muß ja die Info kommen, wer infiziert gewesen ist. Selbst wenn die App einen Schalter hätte mit „Ich bin infiziert“ darauf und den Status im Signal mit ausstrahlen würde ( da fällt mir sofort der Judenstern ein ) , potentiell nutzt das anderen Menschen nichts, weil man sich halt nicht immer zweimal im Leben sieht. Daher war ein Zentralserver zwangsläufig immer mit im Spiel.

Andere Zentralserverlösung nutzt Ihr übrigens auch laufend:

WhatApps, Facebook, Twitter, Wetterdienste, News- und Rss-Feeds usw.

Da gibt es nur einen Unterschied: die kommen nicht so leicht an Namen zu (Mobilfunk-)IPs. Gut, Facebook wird das auch nicht müssen, Ihr habt Ihnen ja schliesslich gesagt, wer Ihr seid 😉 Aber denkt mal drüber nach, wer so alles weiß, daß Ihr jetzt gerade in der Stadt rumrennt oder zur Ostsee fahrt. Wie gut die GEO-Locationdatenbanken heutzutage sind, ist echt erschreckend.

Corona-App öffnet Angriffen Tür und Tor

Nun hatte der Artikel die Überschrift, daß die Corona-App Angriffen Tür und Tor öffnet und damit sind nicht die Trollangriffe gemeint, die eine Infektion nur vortäuschen und so alle Empfänger in der Nähe unnötig in den Coronatest stürzen.

Ich denke, die Lücken im BT sprechen für sich und da die Corona-App BT automatisch aktiviert, stimmt das so auch. Selbst wenn die Software nicht selbst auch noch für bislang unbekannte Angriffe genutzt werden kann, reicht die Sache mit dem BT schon von alleine aus um diesen Zwang abzulehnen, da der Nutzen ohnehin fraglich ist.

Wie man an den Grafiken sieht, ist die Zahl der Neuinfektionen pro Tag zwar nicht Null, aber praktisch kaum vorhanden. Es ist also schwierig überhaupt jemandem zu begegnen, der die Krankheit gerade verteilt. Von den jüngsten Pressemitteilungen ausgehend, wird die derzeit maßgeblich betroffene Gruppe auch diese App nie einsetzen, da sie sich schon den Tests verweigert hat, die nachsehen sollten, ob die überhaupt infiziert sind.

Wenn man den Horizont seiner Blasengruppe nicht verlässt, dann lernt man eben nichts neues dazu. Das hätte den Dinos auch mal rechtzeitig jemand sagen sollen, bevor sie ausgestorben sind.

PS: unsere diesjährig direkt im Baum neben dem Schlafzimmer ziemlich ortsfeste Dinogruppe namens „Krähenschwarm“ trat dann doch nach Beginn der Bauarbeiten den Rückzug an, was besonders morgens um 5 für Ruhe sorgte. Leider wars dann nach 6 Uhr nicht mehr so ruhig 🙁  Bauarbeiter sind echt alle gleich, mirgens um 6 Uhr 1h Lärm machen und dann den ganzen Tag ruhig sein, anstatt abends 1h Lärm zu machen und morgens dann die ruhigen Arbeiten zu erledigen.