Heutiger Samba Ausfall wegen Regression im Security Update

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