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.

CVE-2020-8597: Pre-Auth RCE in PPP

Ist Euch mal aufgefallen, daß über eine der dicksten Sicherheitslücken in 2020 so gut wie kein Wort verloren wird?

CVE-2020-8597: Pre-Auth RCE in PPP

Im Point-To-Point-Dienst wurde eine Lücke entdeckt, die es erlaubt Code auszuführen, noch bevor man sich autorisieren muß. Die Brisanz an der Sache ist, daß nicht nur die Server betroffen sind, sondern auch die Clienten. Eingesetzt wird das u.a. bei VPN Systemen.

Was mich an der Sache ein bisschen ärgert ist, daß seit 2 Wochen das Update vom ppp bei Fedora im Bodhi hängt, weil mal wieder keiner zum Testen Zeit & Lust hatte, was mir sehr bekannt vorkommt. Davon mal abgesehen, wurde der aktuelle Chef vom Fedoraprojekt direkt nach entdecken der Lücke über die Brisanz, den Entdecker und die verifizierende Quelle informiert, keine 8 Stunden nach den ersten Gerüchten. Ich weiß das, weil ich das gemacht habe, mit dem Hinweis es an die Security von RH, PPP etc. zu  eskalieren.

Damit mußte eigentlich allen Beteiligten klar sein, daß es sich um ein Critupdate handelt. Kritisch ist das nämlich, weil viele VPN Techniken, außer SSH, auf den ppp setzen und damit eine echt große Angriffsfläche gegeben ist. Die Lücke ist so krass, daß die sogar osübergreifend existiert. Das erlebt man ja auch nicht jeden Tag.

Der, sagen wir mal schweigsame, Umgang mit der Lücke, auch in den Medien führt übrigens dazu, daß Kunden diverser Produkte die den ppp kommerziell einsetzen nicht mal wissen, daß es diese Lücke gibt, was dazu führt, daß es keinen Druck bei den Herstellern gibt. Ich befürchte sogar fast, daß die nicht mal wissen, das es die Lücke gibt, weil das erst heute, 2 Wochen nach bekanntwerden,  über FullDisclosure gelaufen ist und somit auch erst jetzt die Runde macht.

Pro-Linux.de ist übrigens eine der wenigen Seiten in Deutschland, die überhaupt über diesen Bug berichtet haben, aber auch mehr, weil es ein automatisches Advisory von Debian gab und weniger, weil daß jemandem aufgefallen ist. Für eine Pre-Auth RCE mit Eskalation zu Root ist das alles eine sehr seltsame Sache. The Hacker News hat vor 2 Tagen darüber berichtet, aber das wars dann schon. Golem oder Heise vermisst man mal wieder, dabei wäre das ein gefundenes Fressen für die Medien, weil es Millionen betroffener Clients und Server gibt.

Wenn Android hustet, …

…, wo niemand genau weiß, ob jemand wirklich davon betroffen ist, da raschelt es gleich im Blätterwald, aber wenn die Sicherheit von Millionen Hosts in Gefahr ist, dann bleibt alles ruhig?

Dem einen oder anderen stellt sich jetzt vermutlich die Frage, wieso habe ich das nicht gleich im Blog gepostet als ich davon erfuhr? Ich wollte meiner Distro einen kleinen Vorsprung geben, damit der Patch ausgerollt wird, bevor die Masse der Blackhats das mitbekommt. Nachdem Fefe das in seinem Blog rausgehauen hatte, konnte man zu dem annehmen, daß es im Blätterwald sehr schnell die Runde machen würde, was ja dann überraschenderweise nicht passiert ist.

Ihr merkt, bei dieser Lücke ist einiges anders als sonst. Ich frage mir nur gerade, was eigentlich die Lektion ist, die wir daraus lernen sollten: „trotz wager Infos die Posaune rausholen und sofort berichten“ oder „doch abwarten bis es mehr Infos gibt und so riskieren, daß keiner was meldet“? Ich muß gestehen, da bin ich auch überfragt. So etwas wie beim ppp darf sich jedenfalls nicht wiederholen.

MySQL Workbench 8

Kleines Ratespiel: Wurde für diese Meldung eine SQL-Datenbank benutzt oder nicht? 🙂 Wenig überraschend lautet die Antwort: „Ja“. Das könnte an der weiten Verbreitung und den vielfältigen Anwendungsmöglichkeiten liegen. Es folgt übrigens keine SQL Einführung oder gar ein SQL Lehrgang 😉

Desktop-App: MySQL Workbench 8

Wenn man mit einer SQL-Datenbank arbeiten möchte, braucht man i.d.R. drei Dinge: Einen SQL-Server, einen SQL-Clienten und ein Programm, daß mit den Daten in der SQL-Datenbank etwas machen möchte.

Der im FOSS vermutlich am häufigsten eingesetzt wird, ist MariaDB. Dieser Fork von MySQL entstand, weil Oracle, die die Firma hinter MySQL gekauft hatten, der Meinung war, mal die Regel zu ändern. Das hat einem Teil der Gemeinde, die bislang MySQL mit entwickelt hatten nicht gefallen und so zogen/forkten Sie in eine eigene Trägergesellschaft „The MariaDB Foundation“ um. Zu den größten Sponsoren zählen Booking.com ( die mit den dicken Spamproblem ), Alibaba Cloud und Microsoft (die mit dem eigenen Closed Source MSQL-Server {Wieso eigentlich Microsoft!?!?!?!}), aber auch WordPress Hersteller Automattic, IBM und ein paar Andere.

Bei MariaDB handelt es sich also um den Serverteil, der verschiedene Datenbank Engines unter ein Dach bringt, so daß man diese mit dem SQL-Clienten der Wahl ansprechen kann. Im MariaDB Paket ist ein einfacher Kommandozeilen Client namens „mysql“ mit dabei. Ja, der heißt nicht „mariadb“ sondern „mysql“, weil das ein Fork von MySQL ist, der eine möglichst große Rückwärtskompatibilität anstrebt. Mit anderen Worten, für den Endbenutzer sollte sich nichts ändern. Möglich ist das, weil MySQL eine FOSS Entwicklung ist, die jeder clonen und weiterentwicklen kann, solange er sich an die Lizenzregeln hält.

Jetzt mag nicht jeder in der Konsole rumschrauben, auch wenn das nicht wirklich schwierig ist, und möchte vielleicht eine Desktop-Anwendung benutzen. Hier kommt die MySQL Workbench ins Spiel:

man sieht ein Startfenster mit der Auswahl in welche Datenbank man einloggen möchte.Wenn man das Fedora Paket MariaDB-Server installiert ( dnf install mariadb-server mariadb ), dann kann man direkt mit der Workbench mit der Arbeit anfangen, da der ROOT Zugang zu dem Datenbankserver nicht beschränkt ist. Das ist natürlich auf Dauer eine völlig untragbare Situation, aber irgendwie muß man erstmal in den Datenbankserver rein kommen, um dann dort die Zugangsdaten für den Rootzugang zusetzen 🙂 In meinem Beispiel ist das erst einmal kein Problem, da die spätere App auf einem abgesicherten Server neu aufgesetzt wird. Aber sobald Eurer Server übers Netz erreichbar ist, ist ein Passwortschutz unumgänglich.

Mein drittes Problem, das welches mit den Daten arbeiten soll, gibts noch nicht, aber das wird dann in PHP oder JAVA geschrieben sein. Beide Sprachen bringen einen kompletten Support für MySQL(und Forks) Datenbankserver  mit.

Mit dem SQL-Clienten kann man jetzt die eigentlichen Datenbanken, Tabellen, Views, Indexe und in letzter Konsequenz auch die Datensätze anlegen und bearbeiten:

Im Beispiel oben die Datenbank namens „census“ und darin die Datenbanktabelle „users“.

Der eine oder andere könnte an der Tabellenbeschreibung erkennen, um was für ein Projekt es sich handelt, aber laßt Euch sagen, es funktioniert leider nicht sauber…{ PAM_MYSQL Frustanflug niederkämpf}.. Wie man hier sehen kann, ist die Ansicht der Datenzeile(n) reicht ansehnlich. Für einfache Bearbeitungen ist der Client gut zu benutzen, aber ehrlich gesagt ist PHPMyAdmin weitaus besser!

Also wenn Ihr mal ein Desktopprogramm sucht, mit dem Ihr in einer SQL Datenbank arbeiten könnte, das wäre ein brauchbares.

Für Fedora herunterladen könnt Ihr das hier: https://dev.mysql.com/downloads/workbench/#downloads Ihr müßt aber erstmal das passende OS ( hier Fedora ) auswählen, damit Euch die Downloadlinks angeboten werden. Das klappt sogar erfreulicherweise ohne Javascript 🙂 Die Fedora RPM-Pakete gibt es nur für 64Bit Versionen, aber das dürfte einen heutzutage nicht mehr wirklich stören.