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.

 

Fedora Koji ist derzeit offline

Das Fedora Buildsystem Koji ist derzeit außer Betrieb aka. Offline. Da es dazu keine Ankündigung gab, kann man nur von einem Ausfall sprechen. Da hiervon aber auch alle Downloads aus dem Buildbereich betroffen sind, kann man derzeit nichts recherchieren oder ausprobieren. Dies bedeutet auch, daß alle Koji Links aus diesem Blog derzeit offline sind.

Fehlermeldung Server ist offlineSeit einigen Tagen Probleme

In der Entwickler Mailingliste wurden schon seit einigen Tagen dubiose Fehlermeldungen und lange Prozesslaufzeiten gemeldet. Ein Neustart des System brachte wohl nur kurzfristig Entlastung. Ein Zusammenhang mit dem derzeit laufenden 36C3 kann man wohl ausschließen, da Kevin Fenzi schon vor 7 Tagen darüber berichtet hat:

Aufgrund der Fehlermeldungen bricht da derzeit vermutlich ein Datenbankserver(Cluster) in sich zusammen, der für die Buildumgebung da ist.
Ich halte Euch auf dem laufenden.

Mailbox voll?

So sieht das Postfach am nächsten Morgen aus, wenn man vergisst, daß ein jetzt abgeschalteter Server noch irgendwo als Test-Referenz eingetragen ist und von einem Dutzend Server alle 10 Sekunden per Keep-Alive gepingt wird 🙂


Zum Glück war es nichts schlimmeres 😉

FBI Daten hatten ungeschützten Verkehr mit dem Netz

In Deutschland streitet man noch über die veröffentlichten Daten von Promis und Politikern, in Amerika ist man schon weiter:

Ungeschützte Regierungsserver geben Einblick in FBI Ermittlungen

Wie die Hacker News berichten, hat das Oklahoma Department of Securities  3 TB an Ermittlungsdaten ungeschützt auf einem Server geparkt gehabt. Ich denke, die müssen sich jetzt umbenennen in „Department of Insecurities“ 🙂

Die Inhalte waren teilweise Jahrzehnte alte Ermittlungsakten vom FBI. Dazu gabs dann noch Interna aus besagter Behörde wie z.B. Remote-Zugangsdaten, Sozialversicherungsnummern, die ja in Amiland zum Identitätsdiebstahl sehr beliebt sind, aber auch sensible Patientendaten von AIDS-Kranken. Wieso eine Regierungsbehörde AIDS-Krankendaten speichert, werden die wohl nur sehr wage bis eher ausweichend beantworten wollen.

Die Hacker News haben eine schöne Statistik mit gefundenen Filetypen und einer Sammlung von Outlook PST Files bis 1999 im Angebot. Die ältesten Daten stammen wohl von 1986. Die Behörde will jetzt alle informieren, deren Daten da sichtbar waren, was im Einzelfall (dank 1986) nur postmortem möglich sein wird.

Was war die Ursache? Kommt Ihr nie drauf!

„Bessere Security, durch Installation einer Firewall.“

Na das ging ja mal so richtig schief :DDD Für Spott braucht diese Behörde in nächster Zeit nicht mehr sorgen, das klebt denen bis zum Auflösung am Haken.

 

Das Host Europe Serverinterface

Was antwortet der Host Europe AgileDevOP auf die Frage: „Wo ist das Logoutbutton noch gleich?“ Vermutlich „Keine Ahnung, irgendwo halt.“

ärgerlich, das man danach suchen muß

Ich hatte heute das zweifelhafte Vergnügen im Host Europe Interface für Serververwaltung ausloggen zu wollen. Im Gegensatz zu dem erwähnten DevOP hab ich das dann doch noch gefunden:

Das Webinterface von Host Europe zeigt keine Buttons oder UI-Elemente, dafür ein Nummer unbekannter Herkunft und funktion, aus der ein PULL-DOWN Menü erwächst.Im Allgemeinen finde ich ja Buttons oder farbliche Hervorhebungen eine gute Idee, aber unter dieser nichtssagenden Nummer, die, wie ich vermute, wohl die Kundennummer ist, tauchte dann im 6pt Font ein „Logout“ auf. Ihr merkt schon, es war nicht einer meiner Server 😉

Sorry Host Europe

Aber das ist echt üble Benutzerführung. Wollt Ihr den Kunden mit der Oberfläche quälen oder zu Sachen verleiten, die er bereuen würde? Links war ja noch alles ok, aber wieso um alles in der Welt ist das Logout nicht auch da, so am Ende der Optionen für Server ? oder gleich mal ganz anders .. ( Brav aufs Datum achten, wir sind Euch da seit Jahren vorraus.)

Ich frage deshalb, weil ja ohnehin nicht allzu-viele Funktionen zur Verfügung stehen. Eine „Überladung des Interfaces“ brauchen wir bei der spärlichen Möblierung sicherlich nicht befürchten 🙂

@HE: Geht mal In Euch und überlegt mal, wie man das hübscher und bedienerfreundlicher machen kann. Danke.

Evolution Hosting Fenstersystem

(Screenshot einer Weboberfläche mit Fenstersystem (C) 2018 EVH )

Zum Abschluß noch …

@HE: Eure VNC Schnittstelle erwartet was auch immer für eine Tastaturbelegung und funktioniert auch mit dem von Euch favorisierten TigerVNC unter Linux nicht.

 

Proftpd Bugfix macht Login unmöglich

Die späte Rache ereilte vermutlich die Entwickler vom allseits beliebten FTP-Server Proftpd. Um das Problem zu verstehen muß man etwas ausholen und in die Vergangenheit des Servers zurückgehen:

Spätestens im Jahr 1999 wurde mit der Version 1.2.0pre9 die Funktion eingebaut, daß FTP-Benutzer die einloggen, in einer Chroot gefangen werden, damit sie nur auf ihr Homeverzeichnis zugreifen können. Die Option hies „DefaultRoot“. In der Doku zu der Option findet sich folgender Hinweis:

When the specified chroot directory is a symlink this will be resolved to it’s parent
first before setting up the chroot. This can have unwanted side effects. For example if
a user has write access to the symlink he could modify it so that it points to ‚/‘

Meint auf Deutsch in Kurzform, daß wenn das Homeverzeichnis eigentlich ein Symlink ist, diesem gefolgt wird und das, wo der rauskommt, das neue „/“ von der Chroot ist.

Im Klartext: wenn  /home/testuser ein Symlink auf  „/“  ist, dann ist der User nicht in /home/testuser gefangen, sondern kann sich frei im normalen „/“ Verzeichnis rumtreiben. Ein Sicherheitsloch, daß locker mal 20 Jahre existiert hat.

Die FAQ von Proftpd meint zu dem Thema Chroot, daß man als Admin gefälligst dafür Sorgen soll, daß User das nicht anlegen/ändern können und halt kein Sicherheitsloch entstehen soll. Die schoben die Verantwortung also an die Admins weiter, was zu einem bestimmten grad ok war, aber dann darf man andere Sachen gar icht erst erlauben.

Mein Teil an der Story

In 2012 habe ich den Entwicklern von Proftpd einen Patch für proftpd geschickt, der genau dies Problem adressiert hat und keine Nebenwirkungen hatte. Der Patch prüft bei jedem Zugriff, ob sich in dem Pfad ein Symlink eingenistet hatte. So konnte es keine RACE Condition geben, bei der der Benutzer durch schnelles löschen und SymLink anlegen, die Sicherungsmaßnahmen umgehen konnte. Kurzfassung: Der Patch wurde mit : „Nicht unser Problem, siehe FAQ “ abgelehnt. Was sich jetzt als tragisch herausstellt. Besonders tragisch, da für den 29C3 in 2012 ein Vortrag zu dem Thema von mir eingereicht wurde.

Das Jahr 2016

In 2016 hat es dann endlich jemand geschafft, die Entwickler zu einer Option zum Checken von Symlinks im Pfad zu nötigen. Herzlichen Dank dafür, keine Ahnung wie Du das geschafft hast! Klasse!

Das Jahr 2017

Nun konnte ja nicht sein, was nicht sein durfte, in der Routine zum Checken der Symlinks wurde ein Sicherheitsloch entdeckt ( Hämischer Kommentar: Told you so ! ) und diesem wurde die CVE-2017-7418 zugeteilt.

Nun gabs es dieser Tage den Patch zu dieser Lücke im Server und damit das obligatorische Update auf den Produktivsystemen. Keine große Sache, sollte man denken. Tja, wer hat es geraten ? Auch diese Routine failed. Die hat das Sicherheitsproblem auf einer völlig neuen Ebene gelöst: Es kann sich kein Virtueller FTP-User mehr einloggen 😀

Ursache ist das hier:

[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 1001, -1)     = 0
[pid 32571] setresuid(-1, 1000, -1)     = 0
[pid 32571] lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root/home", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
[pid 32571] lstat("/opt/root/home/testuser", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
[pid 32571] lstat("/opt/root/home/testuser/public_html", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
...
[pid 32571] geteuid()                   = 1000
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 0, -1)        = 0
[pid 32571] setresgid(-1, 0, -1)        = 0
[pid 32571] setgid(1001)                = 0
[pid 32571] geteuid()                   = 0
[pid 32571] setresgid(-1, 99, -1)       = 0
[pid 32571] setresuid(-1, 99, -1)       = 0
[pid 32571] lstat("/opt/root/home/testuser/public_html", 0x7ffee3d84dd0) = -1 EACCES (Permission denied)

Für die Laien unter Euch, das ist der Auszug eines STRACE Logfiles. Darin finden wir alle Befehle die der Prozess ausgeführt hat ( API-Calls , nicht Bashkommandos 😉 ) . Man sieht deutlich das im ersten Block mit einer UID/GID von 1000/1001 auf das Homeverzeichnis des Benutzers zugegriffen wird, weil der Prozess entsprechend seine UID/GID ändert. Das ist RICHTIG so.

Was falsch ist, daß er das nicht auch beim zweiten Block tut. Hier ist die UID des Prozesses (proftpd) statt 1000, nur 99, was dem User NOBODY entspricht. Das ist der User, zu dem Prozesse werden sollen um Ihre Rechte zu verlieren um im Falle eines Sicherheitsbruches den Schaden zu begrenzen. (@Team: Der Teil hat 1a funktionert. Ohne Logins keine Bedrohung mehr) . Natürlich müßte auch hier die UID/GID auf 1000/1001 gesetzt werden, damit man an seine Dateien rankommt, denn normalerweise haben Verzeichnisse wie „/home/testuser“ einen chmod von 700, damit nur der User drankommt.

20 Jahre bis Problem akzeptiert. 4 Jahre bis zum Fix und nur 6 Monate bis zum Totalausfall der Server. Eine Glanzleistung sonders gleichen. Hätte man meinen Patch in 2012 nicht todgeredet, wäre uns das erspart geblieben 🙂 Da der Vortrag abgelehnt wurde, ging das Thema am 29C3 leider unter und so könnten die Jungs und Mädels vom CCC unabsichtlich auch dran beteiligt gewesen sein 😉  Tja, so ist das Leben.

Kleiner Disclaimer:

Es hängt ein bisschen von der Serverkonfiguration ab. Wer keine Datenbank benutzt, sondern nur reale User, der hat das Problem den bisherigen Infos nach nicht. Wer „AllowChrootSymlinks on“ aktiviert hat ( was der Default ist) hat auch kein Problem mit dem Login, wohl aber mit dem Umstand, daß er/sie ein angreifbares System hat ( siehe oben ) das ganz schnell gehackt werden kann.

 

Über den Sinn und Unsinn von MD5 Checksummen auf Webseiten

Es war einmal vor einigen Tagen, … okok, es war heute, ich poste den Beitrag nur später… ähähämm .. nochmal… es war einmal ein junger Stern am Kryptohimmel. Sein Name war MD5 und er war von der Rasse der Hashe, die aus dem Land der Algorithmen stammten. Unser junger Stern wuchs schnell zu einem ganz großen Hash heran, der für viele Dinge der Menschen seinen Schutzzauber sprach und so für Ihre Sicherheit sorgte.

Eines Tages kam ein Sprößling der Gattung Mensch, aus der Rasse der Distributoren, auf die Idee, doch seine digitalen Datenrohlinge von unserem jungen Stern vor Veränderungen schützen zulassen,  so daß jeder erkennen mag, daß er eine Fälschung den digitalen Fluß hinabschifft.

Am Beispiele der Slacks soll hier gezeigt werden, wie er es anstellte :

Parent Directory
slackware64-14.2-install-dvd.iso30-Jun-2016 23:222.6G
slackware64-14.2-install-dvd.iso.asc30-Jun-2016 23:22181
slackware64-14.2-install-dvd.iso.md530-Jun-2016 23:2267
slackware64-14.2-install-dvd.iso.txt30-Jun-2016 23:21198K

Unser mächtiger Stern sprach einen Schutzzauber über den jungen Datenrohling aus und dieser wurde zusammen mit dem jungen Datenrohling in sein Netz gelegt. Nun konnte jedermann, der den Datenrohling inne hatte prüfen, ob es der echte Datenrohling war, oder nur eine böse Fälschung ins Nest gelegt worden war.

Die Jahre gingen ins Land und unserer mächtiger Stern wurde alt und gebrechlich. Seine Schutzkräfte liessen nach und dennoch wandten sich die Menschen an ihren einst so mächtigen Stern und erbaten seinen Schutzzauber. Ein junger, mächtigerer Stern aus der Rasse der Hashe, stiess unseren altern Stern von seinem Throne und erfüllte den Menschen füderan ihre Schutzwünsche; sein Name: SHA256.

Es war eine Zeit in Aufruhr, denn böse Mächte unter den Menschen brachen in die Datenhorte derer ein, welche die Datenrohlinge für das Gute schufen und tauschten diese gegen billige Fälschungen aus Fernost aus. Ein Hort nach dem anderen wurde heimlich aufgebrochen und infiltriert, und dennoch legten die Menschen weiterhin Ihren Schutzzauber einfach in den Datenhort Ihres Datenrohlings, denn sie vertrauten darauf, daß sie klüger waren, als die Bösen unter ihnen.

Eines Tages geschah das Unfassbare: Ein Mensch forderte den alten Stern auf, einen Schutzzauber für seinen Datenrohling zu sprechen und unser alter Stern, sprach den Zauber aus, und die Menschen legten den Zauber wie immer zu Ihrem Datenrohling, oder nicht ? Nein! Denn der Mensch war böse und hatte den guten Zauber für seine Fälschung erbeten. Da der alte Stern alt und gebrechlich war, erkannte er dies nicht und so konnte der Mensch seine Fälschung in einen infiltrierten Datenhort geben und den guten Schutzzauber dazu legen, ganz wie es die guten Menschen mit Ihren Datenrohlingen taten.

Ein böser Fluch kam über die Datenschiffer und alle diejenigen, die diese Datenrohlinge in Ihre Bratenröhre schoben. Die Menschen wandten sich an die Distributormenschen und diese verstanden die Welt nicht mehr. Genau deswegen hatten Sie doch den Schutzzauber zu Ihrem Rohling gelegt, auf daß die Schiffer vorher erkannten, das Ihrer echt war und der andere nicht. Der Datenrohling war nicht ihrer, ja, aber der Schutzzauber hätte das doch zeigen müssen!

Doch erst  dann, als es zu spät war, erkannten Sie Ihren Fehler: Sie hätten Ihren Schutzzauber in einen anderen Datenhort ablegen müssen, der nicht vom Bösen infiltriert gewesen ist.

Darum liebe Kinder merkt Euch: Digitale Signaturen und das damit signierte Datenpaket aus der gleichen gebrochenen Datenquelle zu vergleichen, ist komplett sinnlos. Signaturen, egal, ob alt und gebrechlich 😉 , gehören auf ein logisch nicht mit dem Datenfile zusammenhängenden anderen Datenspeicher, der anders abgesichert ist, als der für das signierte Datenfile.

Man darf weiterhin behaupten, es wäre eine gute Idee, keine gebrochenen Hashalgorithmen mehr zu benutzen. Aber das ist eine andere Geschichte.