Sicherheitslücken im Kernel und bei Systemd geschlossen

Verfasst von

Systemd Lücke — Quelle: Negative Space | Lizenz: CC0

Die Forscher des Sicherheitsunternehmens Qualys haben eine Sicherheitslücke im System- und Sitzungs-Manager Systemd entdeckt. Bei erfolgreicher Ausnutzung der Lücke kann ein unprivilegierter Angreifer Systemd zum Absturz bringen und eine Kernel-Panik auslösen.

Lücke seit Systemd v220 vorhanden

Die Sicherheitslücke wurde bereits in Systemd v220 im April 2015 durch den Commit 7410616c eingeführt. Anfang Juni informierte Qualys dann das Red Hat Security Team über die als CVE-2021-33910 katalogisierte Lücke. Einen Monat später wurden Patches von Red Hat an die Mailing-Liste linux-distros@openwall geschickt. Am gestrigen 20. Juli wurde die Lücke dann öffentlich bekannt gemacht.

Angesichts der Breite der Angriffsfläche für diese Schwachstelle empfiehlt Qualys den Anwendern, die Patches für diese Schwachstelle sofort anzuwenden.
Bharat Jogi, Qualys Senior Manager für Sicherheitsrisiken

Die Lücke ermöglicht es Angreifern, die Funktion alloca() mit einer unkontrollierten Größe in der Funktion unit_name_path_escape ein Dateisystem auf einem sehr langen Pfad einzuhängen, sodass es zu einem Speicherfehler kommt, der Systemd und in der Folge das gesamte Betriebssystem zum Absturz bringt, da zu viel Speicherplatz im Systemd-Stack verwendet wird.

Patches werden verteilt

Die Patches werden bereits in den betroffenen Distributionen verteilt. Bei Debian Unstable etwa kam der Patch gestern in Form von systemd 247.3-6. Es ist dies nicht die erste Sicherheitslücke in Systemd und es wird vermutlich nicht die letzte sein. Kritiker werfen Systemd immer wieder vor, durch seine Komplexität solchen Lücken Vorschub zu leisten. Egal wie man dazu steht, wer Systemd verwendet, sollte das Update mit dem Patch möglichst zeitnah einspielen.

Kernel-Lücke

Zeitgleich hat Qualys eine weitere Lücke im Linux-Kernel entdeckt, die als CVE-2021-33909 katalogisiert wurde. Es handelt sich um einen Out-of-Bounds-Write-Fehler in der Funktion seq_file in der Dateisystemschicht des Kernels. Durch diesen Fehler kann ein lokaler Angreifer mit Nutzerprivilegien Zugriff auf Speicher erhalten, was zu einem Systemabsturz oder einem Leck in internen Kernel-Informationen führen kann. Das Problem resultiert daraus, dass die size_t-zu-int-Konvertierung vor der Ausführung von Operationen nicht validiert wird.

Systemd

Kommentare

21 Antworten zu „Sicherheitslücken im Kernel und bei Systemd geschlossen“

2021-07-21

wolf0

systemd ist die sicherheitslücke, furchtbarer mist. danke devuan.

Antworten
1. 2021-07-22
  
  Tux
  
  Systemd besteht ja auch aus über einer Millionen Zeilen C-Code, nistet sich im gesamten System ein und spuckt auf Alternativen wie z.B. BSD. Da kann man schon mal was übersehen.
  Zudem ist Corporate Linux (Red Hat und Co.) nicht an unserem Wohl interessiert (Krieg gegen RMS, FSF, GPL) und muss sich an gesetzliche Vorgaben (Cloud Act, Patriot Act) halten.
  
  Ein Glück, dass Alpine und s6 an einer Alternative arbeiten -> „systemd done right“:
  https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/
  https://skarnet.com/projects/service-manager.html
  
  Antworten
  1. 2021-07-22
    
    Tier4
    
    Danke für den Link:
    
    As many of you already know, Alpine presently uses an fairly modified version of OpenRC as its service manager. Unfortunately, OpenRC maintenance has stagnated: the last release was over a year ago.
    
    Antworten
  2. 2021-07-22
    
    Gerrit
    
    Realität an Tux, bitte kommen! Hören sie mich? Können Sie die übertragenen Informationen noch begreifen?
    
    Antworten
  3. 2021-07-22
    
    tuxnix
    
    Ob es Laurent Bercot gelingt eine weniger komplexe, ressourcenschonendere und schmalere Lösung zu schaffen?
    Sein Vorhaben ist auf jeden Fall sehr interessant.
    Ein Hauptmotiv für sein Projekt liegt wohl darin begründet, dass OpenRC ihm nicht genügt, systemD aber kein musil unterstützt. Ich bin auf jeden Fall gespannt auf s6/s6-rc.
    Schaun wir mal, am Ende werden die Dinge auf der pragmatischen Ebene entschieden und für den nächsten init-war ist ja auch noch etwas Zeit. 😉
    
    Antworten
    1. 2021-07-23
      
      Bert
      
      Ein Hauptmotiv für sein Projekt liegt wohl darin begründet, dass OpenRC ihm nicht genügt
      
      Schreiben tut er u.a. das OpenRC seit über einem Jahr kein Wartungsrelease herausgebracht hat.
      
      Antworten
    2. 2021-07-23
      
      kamome
      
      Über Alpine geht da hoffentlich was 🙂
      
      Antworten
  4. 2021-07-28
    
    Reindl Harald
    
    Erstens hast du offenbar keine Ahnung aus was sich diese Zeilenanzahl zusammensetzt und zweitens laufen eine Menge Tools im systemd repo zusammen die einzeln entwickelt haufenweise Abhängigkeiten und weniger shared Code hätten, also fetter wären
    
    Antworten
2. 2021-07-22
  
  Tier4
  
  Announcement ID: openSUSE-SU-2021:2410-1
  
  Rating: important
  
  References: #1188063
  
  Cross-References: CVE-2021-33910
  
  CVSS scores:
  
  CVE-2021-33910 (SUSE): 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
  
  Affected Products:
  
  openSUSE Leap 15.3
  
  ______________________________________________________________________________
  
  An update that fixes one vulnerability is now available.
  
  Wenn man eine gewartete Distri benutzt, ist das alles kein Problem.
  
  Antworten
3. 2021-07-28
  
  Reindl Harald
  
  Dämliches Geschwätz eines ewig gestrigen! Alleine die ganzen security Optionen für services die du so niemals mit einem init-Script hingefrickelt bekommst
  
  Antworten
2021-07-22

Nick

Ich finde die Berichterstattung bezüglich beider Sicherheitslücken aktuell, mehr als fragwürdig. Es wird deshalb so viel Wind aufgewirbelt als wäre das Ende aller Tage angebrochen, obwohl beide Sicherheitslücken keine praktische Relevanz haben. Bezüglich Systemd sind Abstürze zwar ärgerlich, aber die Sicherheit wird dadurch nicht gefährdet, noch lässt sich dieses Problem einfach so ausnutzen. Ein Angreifer benötigt mindestens lokalen Zugriff, womit die Angriffsfläche ziemlich stark eingeschränkt ist. Im regulären Betrieb gibt es keine Auswirkungen. Und bezüglich der Sicherheitslücke im Linux-Kernel, ist ebenfalls ein lokaler Zugriff samt Terminal erforderlich, noch lassen sich ohne Rootrechte mal eben rund 5 GB große verschachtelte Pfade (sind ja nur Milliarden von Zeichen, samt „//deleted“ am Ende), erstellen und bind-mounten um diese Sicherheitslücke bspw. auszulösen. Wie kommt ein Angreifer nun auf das System, um diese Sicherheitslücken jeweils auszunutzen? Bevor das nicht geklärt ist, sind diese Sicherheitslücken wiedermal schneller gefixt als praktisch relevant gewesen.

Antworten
1. 2021-07-22
  
  Ferdinand
  
  Die wenigsten Sicherheitslücken betreffen doch den Desktop-Anwender direkt. Ich weiß nicht, ob Meltdown und Spectre, über die monatelang berichtet wurde, überhaupt mal irgendwo ‚in the wild‘ ausgenutzt wurde. Das Level an Sophistication ist bei vielen Lücken schon sehr hoch. Ich denke, die Berichterstattung kann uns aber immer wieder klarmachen, dass es prinzipiell keine sichere Software ohne Fehler geben kann. Das, was uns im Alltag Sorgen bereiten sollte, sind dagegen eher schlampig geschriebene WordPress-Plugins oder schlecht abgesicherte Browser.
  
  Antworten
2. 2021-07-22
  
  Jörg
  
  Einen reisserischen Hype aus diesen beiden Lücken zu machen, wie es andere News-Seiten tun, halte ich ebenfalls für verfehlt. Angriffsvektoren, welche lokalen Zugriff erfordern, als praktisch nahezu irrelevant abzutun, halte ich jedoch ebenfalls für fahrlässig.
  
  Denn auch heute existieren in einigen Umgebungen noch Server, die hunderten von Benutzer:innen Zugriff auf eine Shell bieten. Nun ist eine Verzeichnishierarchie mit einer Schleife schneller angelegt, als man gucken kann. Einzig das Recht „mount“‐Befehle auszuführen, stellt hier ggf. noch eine Hürde da.
  
  Am besten gefällt mir, dass die Lücken verantwortungsvoll gemeldet und in einer angemessenen Zeit geschlossen wurden. Dass wir uns anschließend auch noch detailliert über die Lücken informieren können, gefällt mir ebenfalls. Dies ist mir, als interressiertem Anwender lieber, als „Allgemeine Produktverbesserungen“ in der Update-Beschreibung zu lesen.
  
  Antworten
3. 2021-07-22
  
  Uxx
  
  Ich finde es fahrlässig, solche Lücken als nichts abzutun. Auch einfache Lücken können es in Kombination in sich haben.
  Hier muss man aber auch gar nicht weit schauen: Linux wird als Multiusersystem benutzt, z.B. bieten Provider von Webspace manchmal auch Shellzugriff für ihre Nutzer und finden die es bestimmt nicht lustig, wenn man einfach den kompletten Server abstürzen lassen kann.
  Und warum sollten root-Rechte benötigt werden, um riesige Pfade zu erstellen?
  
  Für den Heimanwender sind sicherlich die meisten Lücken irrelevant.
  
  Antworten
4. 2021-07-22
  
  Urs Pfister
  
  Mag schon sein, dass die Lücken Dinge betreffen, die nur unter bestimmten eng gsteckten Szenarien zu einer Übernahme der Systeme bzw. durch Abstürze durch Angreifer führen. Aber, niemand wird heute ein System manuell kompromitieren wollen. Und von daher sind solche Angriffe ernst zu nehmen.
  
  In jedem Fall war dies für mich Grund genug, AVMultimedia und die ArchivistaBox mit „gepatchtem“ Kernel auszuliefern, siehe dazu hier:
  
  https://dev1galaxy.org/viewtopic.php?pid=30803#p30803
  
  Betr. dem Absturz unter SystemD. Der Absturz eines Systems ist für mich ein äusserst schwerwiegender Angriff. Ob es dabei SystemD oder ein anderes Tool trifft, interessiert mich nicht. Absturz heisst, die Lösung läuft nicht mehr und das ist nicht einfach nichts. Für mich war es übrigens der Hauptgrund, damals von Windows auf Linux zu wechseln.
  
  Antworten
5. 2021-07-28
  
  Reindl Harald
  
  Auf deinem Kindergarten Desktop ist das alles kein Problem, auf Servern wird aus einer lokalen Lücke schnell eines
  
  Antworten
2021-07-22

kamome

Ganz klar:

und in der Folge das gesamte Betriebssystem zum Absturz bringt

Das wäre mit xyz nicht passiert!

was zu einem Systemabsturz oder einem Leck in internen Kernel-Informationen führen kann

Das wäre mit BSD nicht passiert!

Ein (auch) systemd-Nutzer 😉
Aber ich freue mich, dass auch an Alternativen gearbeitet wird (wenn es denen auch leider etwas schwieriger gemacht wird als nötig)!

Antworten
1. 2021-07-23
  
  Nick
  
  Soll ich Dir sagen was mit allen BSDs auch nicht passiert wäre? Das sie überhaupt genutzt werden. Denn praktisch allen BSDs mangelt es gewaltig an Nutzern, wie auch Entwicklern die den Code auch pflegen. Und das sorgt unmittelbar dafür, dass die Basis verroht und viele Probleme oder gar Sicherheitslücken niemals entdeckt noch gefixt werden. Wer wirklich glaubt das die BSDs weitaus sicherer wären, nur weil man hier kaum etwas hört, macht sich nur selbst etwas vor. Übrigens ändern Abnehmer wie, Sony, Netflix oder Facebook, die sich am jeweiligen Code bereichern, nur wenig am grundsätzlichen Problem, da die Anzahl der Nutzer und Entwickler von Jahr zu Jahr annimmt.
  
  Antworten
  1. 2021-07-25
    
    kamome
    
    Das[s] sie überhaupt genutzt werden.
    
    Werden sie doch! Ich schaue mir dazu jetzt keine Zahlen an, aber möglicherweise nehmen die Zahlen ja absolut nicht mal ab? Jedenfalls scheinen die nicht alle kurz vor dem Aus zu stehen.
    
    Antworten
2. 2021-07-25
  
  Uli
  
  wenn es denen auch leider etwas schwieriger gemacht wird als nötig
  
  Wo genau wird denen das schwerer gemacht?
  
  Antworten
  1. 2021-07-28
    
    kamome
    
    Man kann Software nicht mehr so leicht portieren, wenn ein Großteil der Entwickler von systemd ausgeht (einige zwingend), muss dann diverse Shims bauen …
    
    Antworten