Red Hat-Paketsystem RPM braucht Nachbesserung

Verfasst von

Im März 2021 hatte Dmitry Antipov, einer der Entwickler bei CloudLinux, der Firma hinter Alma Linux, entdeckt, dass die Signaturprüfung von RPM-Paketen unvollständig ist. Antipov sieht das als Sicherheitslücke, RPM-Entwickler Panu Matilainen eher als fehlende Implementierung von Teilaspekten der Signaturprüfung. Logisch, was nicht implementiert ist, kann keine Fehler enthalten. Geht aber völlig am Problem vorbei. Egal, wie man es benennen will, böswillige Akteure können dieses Verhalten ausnutzen, um einen widerrufenen oder abgelaufenen Schlüssel zur Installation schädlicher Pakete zu verwenden.

Widerruf ist eines der vielen nicht implementierten Dinge in der OpenPGP-Unterstützung von RPM. Mit anderen Worten, Sie sehen keinen Fehler als solchen; es ist einfach überhaupt nicht implementiert, ähnlich wie es die Ablaufzeit nicht ist.
Panu Matilainen auf GitHub

Seit 24 Jahren unsicher

Wie bei Debian mit DEB, werden Pakete im Paketformat RPM, was für Red Hat Package Manager steht, vom jeweiligen Maintainer mit seinem privaten Schlüssel signiert, dem die Anwender der Pakete vertrauen müssen. Seit der Einführung von RPM im Jahr 1997 durch Red Hat-Gründer Marc Ewing und Entwickler Erik Troan fehlen der Paketverwaltung sicherheitskritische Mechanismen wie die Prüfung, ob ein Schlüssel abgelaufen ist oder zurückgezogen wurde (revoked). Schlüssel werden unter anderem zurückgezogen, wenn sie kompromittiert sind. Somit passieren auch Pakete, die keinen gültigen Schlüssel mehr haben, die Sicherheitsbarriere, wie der Bugreport auf GitHub aufzeigt.

Patch-Implementierung kann dauern

Antipov hat einen Patch bereitgestellt, befürchtet aber, es könne aufgrund der Komplexität der Materie Monate dauern, bis der Patch angenommen, implementiert und bei den Anwendern angekommen ist. Da diese prekäre, leicht auszunutzende Lücke nun publik ist, denkt Antipov über eine CVE-Katalogisierung (Common Vulnerabilities and Exposures) bei Red Hat nach, um der Angelegenheit mehr Nachdruck zu verleihen.

Kommentare

12 Antworten zu „Red Hat-Paketsystem RPM braucht Nachbesserung“

2021-07-02

pain

Mit Linux wäre das nicht passiert….warte mal

Spass beiseite, wie ich gesagt habe, Linux und OpenSource vertraue ich auch nicht blind.
Der Source Code ist zwar einsehbar, muss aber auch verstanden werden und da ich nicht zu diesen Menschen gehöre ist mein Misstrauen nicht mal unbegründet wie man mal wieder sieht.

Wenn es um Privatsphäre geht, nur bezogen auf die Distribution selbst, da keine Telemetrie erhoben wird ist Linux erste Wahl.

Ansonsten denke ich nicht das (Distro deiner wahl) sicherer ist als andere Betriebssysteme.

Wahrscheinlich sind tausende von Bugs vorhanden die einfach noch nicht entdeckt wurden. Ist warscheinlich mittlerweile auch nicht mehr möglich die zu finden, bei dem Umfang, bestimmt nicht auf Freiwilliger Basis.

Die andere unschöne Seite von Linux sieht man genau hier, wo fehlende Dinge/Implementierungen als Feature verkauft werden. Bug/Fehler Beseitigung ohne Nachdruck überhaupt nicht stattfindet da der Ersteller keinen Bock/Zeit hat.

Deshalb nutze ich nur Software die regelmässig gepflegt wird.

Antworten
1. 2021-07-02
  
  kamome
  
  wo fehlende Dinge/Implementierungen als Feature verkauft werden.
  
  Wurde das als „Feature“ verkauft?
  
  Deshalb nutze ich nur Software die regelmässig gepflegt wird.
  
  So wie RPM? 😉
  
  Antworten
2. 2021-07-02
  
  Charon
  
  Linux ist <3
  
  Antworten
3. 2021-07-02
  
  Nick
  
  Ich finde deinerseits wird zu viel verallgemeinert. Und auch wenn es viele Linux-Distributionen gibt, die vermeintlich identisch anmuten, so unterscheiden sich diese mitunter beträchtlich, in Sachen Qualität, Sicherheit, Innovation und bezüglich der Leitlinien des Projekts. Allein wenn man mal das altehrwürdige Debian nimmt, dann ist quasi unübersehbar das über 200 Linux-Distributionen darauf basieren. Und das aus gutem Grund, zumal Debian qualitativer Vorreiter in vielen Disziplinen ist, keinem zentralen Diktat unterliegt, rigoros starke Leitlinien durchsetzt, und das Thema Sicherheit zeitgemäß sehr ernst nimmt. Darüber hinaus ist die Anzahl der Nutzer, sowohl privat als auch in Unternehmen weltweit sehr hoch, samt annähernd 1000 aktiver Entwickler, die Debian auf eine verlässliche Basis stellen. Auf komplett unabhängiger Basis gibt es das nur selten. Nun ja und eigentlich gäbe es da auch nur noch Arch, wenn man mal das fragwürdige AUR ausklammert, was sich ebenfalls unabhängig zurecht seine Reputation verdient hat. Alles andere steht primär unter fragwürdiger und oftmals mangelhafter Kontrolle wie auch Betreuung, womit das kaum dem Gedanken von Freiheit gerecht wird. Und diese ganzen Forks oder gar Forks von Forks, die mitunter von einer Hand voll Leuten betreut werden, braucht offen gesagt echt kein Mensch. Aber um nochmal zum Thema Paketmanager zurückzukommen, so haben sowohl apt als auch pacman eine sehr gute Reputation, und werden im Vergleich zu den Alternativen konsequent sicherheitstechnisch weiterentwickelt.
  
  Antworten
  1. 2021-07-02
    
    Gerrit
    
    Kleine Korrektur:
    
    samt annähernd 1000 aktiver Entwickler
    
    Debian hat zwar knapp 1000 Entwickler aber weniger als 300 Maintainer. Und das reicht für den riesigen Paket-Fuhrpark so gerade aus. Zumal nicht alle davon Sicherheitsexperten sind.
    
    Ob APT/dpkg wirklich so viel besser ist, kann ich nicht beurteilen.
    
    Antworten
    1. 2021-07-02
      
      tuxnix
      
      Beim Thema Sicherheit kann man nur dann absolut sicher sein wenn es nicht geklappt hat.
      Bei Debian muss man sich wenigstens nicht über die Motivlage und die kritische Auseinandersetzung damit Gedanken machen.
      Die Frage „ist das wirklich besser?“ hilft da nicht viel weiter.
      Prüf es doch nach, dann weißt du etwas mehr.
      
      Antworten
    2. 2021-07-07
      
      EinLeser
      
      Ob APT/dpkg wirklich so viel besser ist, kann ich nicht beurteilen.
      
      Beim Paketsystem habe ich nicht mehr zurückgeblickt, seit ich vor über 20 Jahren zu Debian gewechselt bin. RPM und Tools empfand ich wesentlich umständlicher als DEB und Co. Bei RPM hat mich damals genervt, dass man eigene Paket mühsam per Hand in der Abhängigkeitsreihenfolge installieren musste. Bei Debian genügte ein lokales Repo, das Paketsystem löste die Abhängigkeiten selbst auf. So soll das sein. RPM-basierte Distributionen werden das vermutlich mittlerweile beherrschen, aber für mich gibt es keinen Grund mehr zum Wechseln. Tatsächlich ist RPM bei mir sogar zum Ausschlusskriterium geworden, wenn ich mal eine andere Distribution ausprobiere.
      
      Antworten
  2. 2021-07-04
    
    excelsior
    
    „Qualitativer Vorreiter“, was für ein Schmarrn. Wie war das noch einmal mit dem „Debian openSSL bug“? Was das auch eine qualitative Vorreiterrolle Debians?
    
    Antworten
    1. 2021-07-04
      
      Jan-Uwe Koegel
      
      Ich habe förmlich darauf gewartet, dass das jemand wieder ausgräbt!
      D U hättest damals natürlich diesen Bug viel eher bemerkt und alles besser gemacht.
      
      Antworten
4. 2021-07-02
  
  Klaus Behringer
  
  Wenn es um Privatsphäre geht, nur bezogen auf die Distribution selbst, da keine Telemetrie erhoben wird ist Linux erste Wahl.
  
  Dir scheint entgangen zu sein, dass es einige Distributoren und Projekte als sinnvoll erachten, ebenfalls Telemetriedaten zu erheben.
  
  Deshalb nutze ich nur Software die regelmässig gepflegt wird.
  
  Dieser Satz schreit förmlich danach, mit Beispielen erklärt zu werden.
  Ansonsten ist es leider nur inhaltsleeres Geplapper.
  
  Antworten
2021-07-02

tuxnix

Das hat schon lustige Züge wenn ausgerechnet ein Alma Entwickler beim Clonen von CentOS über uralte Unterlassungen bei Red hat stolpert.
Aber alles halb so schlimm. Wenn er der erste ist, dem das auffiel dann ist ja nichts passiert.
Das ist allemal besser als ein security by obscurity von der Konkurrenz.

Antworten
1. 2021-07-06
  
  no one
  
  Die bauen ja auch eigene Pakete und dabei wird es ihnen aufgefallen sein.
  
  Ansonsten geht die Tendenz aber sowieso dahin, sich das Widerrufen von Zertifikaten ganz zu sparen und stattdessen auf Zertifikate mit kurzer Laufzeit zu setzen, die häufig ausgewechselt werden, einfach weil die Verwaltung widerrufener Keys viel zu kompliziert ist. Das in OpenBSD eingesetzte signify sieht die Möglichkeit zum Widerruf z.B. erst gar nicht vor.
  
  Antworten