Heutiger Samba Ausfall wegen Regression im Security Update
Daniel Baumann
daniel.baumann at bfh.ch
Wed Nov 17 22:21:12 CET 2021
Hallo zusammen
Heute hatten wir ein Problem mit einer Regression in einem Security
Update auf unserem Samba Server. Dieser stellt fuer (vorallem) Clients
die Shares unseres Ceph Storage Clusters via SMB zur Verfuegung:
* Linux und macOS:
smb://bfh.ch/data/LFE
* Windows:
\\bfh.ch\data\LFE
* BFH Windows-Clients:
P:\LFE
Von 10:45 bis 11:45 war kein Zugriff moeglich. Ab 11:45 war der Zugriff
fuer die meisten User moeglich (je nach Usernamen, siehe unten), ab
20:30 wieder fuer alle.
Im folgenden die Erklaerung des Ausfalles als Dokumentation fuer uns.
Kurzfassung
===========
* Am Abend vom 9. November wurden neue Samba Versionen veroeffentlicht
(fuer uns ist 4.13.14 relevant), welche einige kritische Security-
Fehler fixen:
https://www.heise.de/news/Samba-Update-behebt-acht-Schwachstellen-6263212.html
Weils kritische Luecken sind haben wir umgehend nach Release bereits
aktualisierte Pakete fuer Debian 10 und Debian 11 gebaut und noch am
selben Abend/Nacht ins Repository hochgeladen.
* Da aufgrund der aktuellen Netzwerk-Priorisierung das automatische
Deployment von Security Updates fuer unsere Linux Systeme seit 4
Wochen ausgesetzt war und grundsaetzlich zurueckgestellt wurde,
haben wir das Update erst heute auf unserem Samba Server
installieren koennen.
* Samba 4.13.14 hat gegenueber 4.13.13 eine Upstream-Regression,
welche den Account-Namen verfaelscht und so jegliche Authentisierung
der User verunmoeglich. Deshalb war heute von 10:45 bis 11:45 der
Zugriff auf die Ceph Shares via SMB nicht moeglich.
* Heute Abend beim Verifizieren des Fix fuer die Regression haben wir
bemerkt, dass dieser fuer Accounts welche mit den Buchstaben A, B,
C, E, F, N, R, T oder V beginnen, nicht funktioniert (Erklaerung
siehe unten).
* Wir haben den Fix korrigiert, so dass seit 20:30 wieder wie gewohnt
auf die Ceph Shares zugegriffen werden kann.
Hintergrund
===========
* Unser Samba Server benutzt fuer Ownership und Permissions die LDAP
Server. Fuer die Benutzerauthentisierung werden die Microsoft
Active Directory Server benutzt (muss via AD laufen, sonst haetten
die Windows-Clients kein sinnvolles Single-Sign-On auf die Ceph
Shares).
* Weil unser Samba Server ein Linux System ist, kann er mit der
Windows-Domaene nicht viel anfangen und muss die AD-User auf die
LDAP-User mappen koennen, z.B. BFH\bad9 (AD) wird dann zu
bad9 (LDAP), so dass (fuer Samba gesehen) die User identisch
sind und der Authentisierende User (AD) zu File Ownership und
Permissions (LDAP) passt resp. benutzt werden kann.
* Bisher hat dies Samba 4.13.13 selber gemacht, d.h. die Windows-
Domaene wurde bei der Weiterverarbeitung des Usernamens automatisch
entfernt, so dass das "Bearbeitungsprogram" innerhalb der Samba
Konfiguration ein simples "echo" ist (d.h. die Konversion vom AD
User zum LDAP User ist ein no-op).
* Bei Samba 4.13.14 wird aufgrund einer Regression im Fix fuer
eine der Sicherheitsluecken (CVE-2020-25717) die Windows-Domaene
intern nicht mehr ausgewiesen wenn die User gemappt werden, so dass
Samba (weil es dann ja die Domaene nicht kennt) diese auch nicht
selbststaendig entfernen kann.
Damit funktioniert dann die Authentisierung nicht mehr weil es im AD
(so wie wir es aufrufen muessen aufgrund des AD-ist-gleich-LDAP-und-
umgekehrt Usernamen-Requirement), keinen BFH\bad9 User gibt, nur
bad9. Und damit geht dann kein Login auf die Shares.
* Natuerlich hat das auch andere Samba Server betroffen, nicht nur
unseren. Ende letzte Woche wurden die ensprechenden Bugs und Patches
dazu von anderen bei Samba eingereicht:
https://bugzilla.samba.org/show_bug.cgi?id=14901
* Der Workaround ist also, anstatt des bisherigen 1:1 Mapping mit echo
(weil Samba ja bisher die Windows-Domaene selber entfernt hat),
ein zusaetzliches Script zu verwenden welches die Domain wegstrippt.
Der relevante Teil dieses Mapping-Scripts lautet:
echo "${ACCOUNTNAME}" | sed -e 's/[^\\]*\\//'
und macht aus 'BFH\\bad9' ein 'bad9'.
* Jetzt wirds lustig (und etwas technisch): weil 'echo' ein Built-in
der Shell ist, und dieses POSIX-konform standardmaessig ANSI Escape
Sequences expandiert, wird z.B. aus einem '\b' ein Backspace, siehe
fuer eine Liste der Sequences die folgende Manpage:
https://manpages.debian.org/unstable/coreutils/echo.1.en.html
-> d.h. aus 'BFH\\bad9' wird (vor der sed Pipe schon!) ein 'BFad9'
(zweimal Backspace weil zwei Backslashes!).
* oder anderst: fuer alle BFH Accounts die *nicht* mit einer ANSI
Escape Squence beginnen (also keinem der Buchstaben A, B, C, E, F,
N, R, T oder V beginnen) hat obiges Mapping funktioniert und diese
konnten heute ab 11:45 bereits wieder wie gewohnt auf die Shares
zugreifen.
* Fuer alle anderen mit den obigen Buchstaben-beginnenden Usernamen
ging der Zugriff nicht (in meinem Fall: es gibt keine 'BFad9' User,
somit Authentisierung fehlgeschlagen, User kann nicht gemappt
werden, ich kriege trotz korrekt eingegebenem User und Passwort ein
"Permission denied").
* Meine zwei Kollegen haben den Fix verifiziert mit ihren Usernamen
(beide beginnen mit "s") sowie dem allgemeinen ITS Testuser (beginnt
auch mit einem "s"). Weil \s keine ANSI Escape Squence ist, hat
dort das Mapping funktioniert und der Zugriff hat funktioniert..
..wir dachten, das Problem sei geloest. Soviel "Glueck" muss man
erstmal haben :)
* Am spaeteren Nachmittag hab ich bemerkt, dass es mit meinem User
(noch) nicht geht und mir heute Abend das nochmal angeschaut..
..die Loesung ist, die Escape Squenzen nicht zu beachten resp.
nicht zu expandieren. "echo" als Shell Built-in kann das weder
in Bash (/bin/bash) noch in Dash (Debians /bin/sh), ist ja im POSIX-
Standard auch nicht vorgesehen dass das gehen sollte (weil dort ANSI
Escape Sequences explizit immer expandiert werden muessen).
Dafuer gibts aber /usr/bin/echo (also als eigenstaendiges Programm
Teil von GNU coreutils, nicht ein Shell Built-in) welches mit der
'-E' Option genau dies kann (also die Sequenzen ignoriert), der
relevante Teil im Mapping Script sieht dann also so aus:
/usr/bin/echo -E "${ACCOUNTNAME}" | sed -e 's/[^\\]*\\//'
..und dann klappts mit allen Benutzernamen, egal mit welchem
Buchstaben sie beginnen.
* Als Nebeneffekt wird dadurch bei jedem Aufruf fuer /usr/bin/echo
ein neuer Prozess geforkt, was aus Ingenieur-Sicht natuerlich
unschoen ist (aber in unserem Setup nicht Performance-relevant ist).
D.h. wir werden dann (ohne Eile) spaeter bei Gelegenheit noch
schauen, wie wirs funktional identisch behaltend, den vermeidbaren
Fork wegkriegen.
Wir entschuldigen uns fuer die Umstaende und danke fuer euer Verstaendnis.
Gruesse,
Daniel
--
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science
More information about the bfh-linux-announce
mailing list