Vielleicht ist es besser, vorerst keine neue Software zu installieren

• Nach copy.fail wurden weitere Linux-Kernel-Schwachstellen bekanntgegeben
• Derzeit wird die Lage als ein Zeitpunkt eingeschätzt, an dem NPM-Supply-Chain-Angriffe besonders großen Schaden anrichten können
• Es gibt die Empfehlung, Linux-Kernel-Patches aus der Distribution als Ausnahme zu behandeln
• Ansonsten ist es vermutlich besser, die Installation neuer Software für etwa eine Woche auszusetzen
• Es wird darauf hingewiesen, dass sich Sachlage oder Umstände seit der Veröffentlichung geändert haben könnten; falls etwas falsch oder unklar erscheint, solle man vor einem Fazit Kontakt aufnehmen

[GN⁺]

Hacker-News-Kommentare

• Das war immer ein Albtraum, der irgendwann explodieren musste. Es gibt viel zu viele Pakete, und entsprechend ist die Angriffsfläche der Supply Chain so riesig geworden, dass das früher oder später alle treffen musste.
  Aber es war eben zu bequem. Menschen, die warnen oder den Schaden mindern wollten, wurden von Leuten abgetan, die nie etwas auf andere Weise gemacht hatten, und "import antigravity" war einfach zu verlockend, um darauf zu verzichten.
  Es wirkt, als wären wir jetzt in der Phase angekommen, in der wir „den Preis bezahlen“

  • In einem Unternehmen, in dem ich war, wurde wirklich extrem konservativ gearbeitet. Alle externen Komponenten waren versionsfixiert, wurden ohne Review nicht aktualisiert und bekamen normalerweise eine ausreichend lange Stabilisierungsphase.
    Fast alles, einschließlich Compiler und Kernel, wurde aus dem Quellcode gebaut, und die Build-Server/-Infrastruktur hatten überhaupt keinen Internetzugang; es gab ein Verfahren, um Änderungen kontrolliert hereinzuholen. Relevante CVEs wurden jedes Mal geprüft, wenn sie veröffentlicht wurden, um zu entscheiden, ob sie uns betreffen und wie wir sie abmildern oder behandeln.
    In der Firma danach hatten die Builds Internetzugang, und es wurde aktualisiert, sobald neue Versionen erschienen. Die Leute hielten das für gute Praxis, weil man so die neuesten Bugfixes bekomme, und die CVE-Prüfung lag beim Security-Team.
    Das Startup danach hatte einen Mix aus verschiedenen Praktiken. Einiges war sehr gut, aber es gab auch viele CVE-Schulden. Zum Beispiel waren Secure Boot und verschlüsselte Datenträger auf den Servern im Einsatz, und die Sicherheit der Kommunikation zwischen Komponenten war recht gut verstanden.
    Alle glauben, dass sie es richtig machen. Es ist fast unmöglich, Menschen, die „oft upgraden“, davon zu überzeugen, dass damit auch das Risiko steigt, neue Probleme einzuführen. Die Branche braucht ein besseres Bündel an Best Practices, und ich persönlich halte den Umgang des ersten Unternehmens mit Abhängigkeiten für besser. Insgesamt waren dort die Sicherheitspraktiken gut verankert, und das Produkt war wirklich sicher
  • Um die Büchse der Pandora einmal zu öffnen: Was, wenn der Nettoeffekt davon, all diese unbekannten Angriffsvektoren ans Licht zu bringen, darin bestünde, die gehorteten Schwachstellen der Nachrichtendienste weltweit aufzubrauchen?
    Dann wäre irgendwann jede nützliche Software durch Fuzzing-Tests, Property-Tests und formale Verifikation gegangen, und alle, die Schwachstellen suchen, müssten wieder bei null anfangen.
    Natürlich setzt das voraus, dass wir die Zwischenphase überstehen, in der Staaten ihre verbleibenden Mittel auf ihre schlimmsten Gegner werfen. Oder wir schlagen am Ende eben wieder mit Tierknochen aufeinander ein
  • Ich wünsche mir seit Jahren ein Capability-basiertes Sicherheitsmodell und habe auch hier schon darüber diskutiert. Capabilities wären so etwas wie Objektzeiger mit zugehörigen Rechten, ähnlich Unix-Dateideskriptoren.
    Auf Betriebssystemebene würde ein gestartetes Programm ein Capability-Token von der Shell oder dem Aufrufer übergeben bekommen, und jeder Systemaufruf müsste als erstes Argument eine Capability erhalten. Also würde "open path /foo" zu open(cap, "/foo"). Diese Capability könnte auf ein Fake-Dateisystem, einen Zweig des echten Dateisystems, ein Netzwerkdateisystem oder irgendetwas anderes zeigen, und das Programm müsste nicht wissen, in welcher Sandbox es lebt.
    Auch auf Bibliotheks-/Sprachebene müsste man beim Import von Third-Party-Bibliotheken wie npm-Modulen bei jedem Importzeitpunkt oder Aufrufort Rechte mitgeben. So eine Bibliothek sollte nicht Lese-/Schreibzugriff auf jedes Byte im Adressraum meines Programms haben und auch nicht auf meinem Computer alles tun können, als wäre sie ich. Die Kernfrage lautet: Wie groß ist der Blast Radius dieses Codes? Wenn eine verwendete Bibliothek bösartig oder verwundbar ist, braucht man vernünftige Standardannahmen für das Schadensausmaß. Ein Aufruf wie lib::add(1, 2) sollte nicht zu einer dauerhaften vollständigen Kompromittierung meines Computers führen.
    SeL4 bietet schon lange schnelle und effiziente Capabilities auf Betriebssystemebene, und das funktioniert gut. In vielen Fällen ist es schneller als Linux und sehr nützlich für transparente Sandboxing-Mechanismen, User-Space-Treiber, Interprozesskommunikation, Sicherheitsverbesserungen und mehr. Man kann Linux sogar als Prozess auf SeL4 laufen lassen. Ich will ein Betriebssystem, das alle Funktionen eines Linux-Desktops hat, aber sich wie SeL4 verhält.
    Leider scheint es keine Programmiersprache zu geben, die die Art von Capabilities auf Sprachebene bietet, die ich haben möchte. Rust kommt ziemlich nah heran, aber man bräuchte eine Möglichkeit, Third-Party-Crates daran zu hindern, beliebigen unsafe Code aufzurufen. Einschließlich unsafe, das von nicht vertrauenswürdigen Abhängigkeiten hereingezogen wird. Außerdem müssten alte Soundness-Bugs in Rust behoben werden, und es bräuchte eine Capability-basierte Standardbibliothek. Globale Dinge wie open() oder listen() müssten verschwinden; es dürfte nur noch Formen wie openat() geben und entsprechende Gegenstücke für andere Teile des Betriebssystems.
    Wenn LLMs weiter besser werden, lasse ich sie das in ein paar Jahren vielleicht einfach komplett bauen, falls es niemand vorher tut. Die Sicherheit moderner Desktop-Betriebssysteme ist ein Witz
  • Die meisten Menschen stecken sich nicht einfach irgendetwas in den Mund. Sie warten nicht auf ein positives Ergebnis aus einer mikrobiellen Kultur und lehnen es erst dann ab.
    Wir brauchen auch für Code eine Hygienekultur, und die unterscheidet sich gar nicht so sehr von den Normen, die die meisten Kulturen rund ums Essen entwickelt haben. Es ist eine Kombination grober Heuristiken, aber dieses Gefühl von „igitt“ rettet Milliarden Menschen das Leben
  • Vor einem Jahr habe ich schon die Ansicht vertreten, dass es oft besser ist, Code selbst zu schreiben, statt möglichst viele Third Parties hereinzuziehen. Damals galt schon die bloße Idee, LLMs zum Füllen der Lücken in Betracht zu ziehen, als ketzerisch.
    Heute reduziere ich meine Exposition gegenüber Abhängigkeiten stärker als je zuvor, besonders bei Dingen, die sich in ein paar hundert Zeilen implementieren lassen. Das ist wirklich ein Paradigmenwechsel

• Der Ansatz „warte eine Woche mit der Softwareinstallation“ funktioniert nicht. Erst vor ein paar Monaten traf eine massive Schwachstelle das Web; es war ein zeitverzögerter Angriff, der über einen Monat lang latent blieb und dann aktiviert wurde.
  Wenn alle anfangen, eine Woche zu warten, warten Angreifer eben zwei Wochen. Cyberkriminelle müssen nicht sofort ausnutzen, sie müssen nur irgendwann erfolgreich ausnutzen. Viele Arten von Schwachstellen wie Typosquatting ändern sich dadurch ebenfalls nicht

  • Der Autor scheint nicht zu meinen, dass man künftig alle Updates grundsätzlich verzögern soll, sondern schlägt eher einmalig vor, eine Woche zu warten, bis Fixes und Patches für die diesmal zu früh veröffentlichten konkreten Schwachstellen verteilt wurden. Dem Rest stimme ich zu
  • Ich glaube, du hast den Beitrag missverstanden. Der Vorschlag ist nicht, Software nach ihrer Veröffentlichung erst eine Woche später zu installieren. Gemeint ist: ab jetzt in den nächsten 7 Tagen einfach nichts installieren.
    Der Grund ist, dass es für diese Schwachstellen wahrscheinlich noch keine Patches gibt und selbst wenn doch, sehr wahrscheinlich bald noch schlimmere entdeckt werden
  • Dann kann man auch einen Monat oder zwei warten. Der Sinn der Wartezeit ist nicht, die Ausführung bereits installierter Exploits zu verhindern, sondern die Installation neuer Exploits zu vermeiden
  • Beliebte Pakete sind stärker exponiert. Sobald ein Artefakt veröffentlicht ist, kann die ganze Welt es sehen, und man kann davon ausgehen, dass irgendjemand die Diffs zwischen Versionen prüft.
    Aber ohne jede Verzögerung kann man von einem Exploit getroffen werden, den noch niemand gesehen hat
  • Alle Fälle von kompromittierten Abhängigkeiten, an die ich mich aus den „letzten paar Monaten“ erinnere, wurden nicht in Stunden, sondern in Minuten entdeckt. Das galt für litellm, axios, bitwarden CLI, Checkmarx-Docker-Images, Pytorch lightning und intercom/intercom-php.
    Außerdem hing die Entdeckung solcher Kompromittierungen überhaupt nicht davon ab, ob sie tatsächlich ausgenutzt worden waren. Deshalb verstehe ich die Aussage „wenn alle eine Woche warten, warten Angreifer zwei Wochen“ nicht

• Als andere Option könnte man auf ein Betriebssystem wie FreeBSD wechseln, das Sicherheit nicht im YOLO-Stil behandelt.
  Security-Fixes werden nicht einfach unkoordiniert in den FreeBSD-Kernel geworfen. Sie gehen über das FreeBSD-Security-Team, und wenige Minuten nachdem ein Patch in den src-Tree gelangt ist, werden Binärupdates über FreeBSD Update und pkgbase für 15.0-RELEASE ausgeliefert.
  Es dauert ungefähr ein paar Sekunden, bis auf Slack die Nachricht „Patch gepusht“ erscheint, 10 bis 30 Sekunden für den Upload des Patches und höchstens etwa eine Minute für die Synchronisierung der Mirrors

  • Da bin ich etwas skeptisch. Ich habe vor ein paar Jahren dem FreeBSD-Security-Team eine Schwachstelle gemeldet und ein paar Wochen später sogar nachgefasst, aber nie eine Antwort bekommen.
    Fairerweise betraf mein Report nichts Zentrales und war auch nicht leicht auszunutzen, aber Debian, OpenBSD, SUSE und Gentoo hatten alle innerhalb einer Woche Patches: https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Ich will damit nicht das ganze Betriebssystem anhand der Bearbeitung eines einzelnen kleineren Reports bewerten. Alles andere, was ich gesehen habe, spricht eher dafür, dass FreeBSD Security-Meldungen ziemlich ernst nimmt. Mit derselben Logik könnte man das aber auch auf Linux-Kernel-Bugs anwenden. Solche Fälle von schlecht gemanagten Patches sind auch unter Linux ziemlich selten
  • Wenn man wegen Sicherheit zu BSD wechselt, warum dann FreeBSD? Ist OpenBSD nicht das deutlich sicherere System? Ich frage nur, weil ich die Projekte schon lange nicht mehr verfolgt habe
  • FreeBSD ist bei Sicherheit, besonders bei Defaults und Konfiguration, ziemlich locker.
    Es bevorzugt Nutzbarkeit gegenüber Sicherheit. Ein bekanntes Beispiel gibt es hier: https://vez.mrsk.me/freebsd-defaults
    Ich schätze Beiträge zum Projekt, aber solange es solche schlechten Defaults gibt, kann ich Leuten mit gutem Gewissen keinen Wechsel empfehlen
  • FreeBSD hatte bis 2019 nicht einmal ASLR im User Space, und kASLR als eine weitere der Gegenmaßnahmen gibt es bis heute nicht. Für Menschen, denen Sicherheit wichtig ist, ist das kein ernstzunehmendes Betriebssystem.
    Wenn man FreeBSD und Sicherheit will, sollte man eher HardenedBSD von Shawn Webb verwenden
  • Bei solchen Themen taucht immer jemand auf. Schön, dass deine Lieblingsdistribution definitiv sicherer ist. Selbst wenn es nur noch um einen einstelligen Faktor weniger Exploits ginge, blieben am Ende immer noch ein paar Tausend übrig. Ozymandias hätte Gentoo benutzt

• Selbst Security-Experten müssen inzwischen akzeptieren, dass unsere Welt auf einem extrem fragilen Gleichgewicht steht. Ich glaube, die Leute unterschätzen das massiv.
  Nicht nur die IT-Welt, die ganze Welt ist auf zahllosen sehr fragilen Gleichgewichten aufgebaut. Security-Exploits wird es immer geben. Nicht nur in Software, sondern auch in der realen Welt. Jemand hat sich mal in eine Sicherheitskonferenz eingeschlichen, und das war nur ein YouTuber. Klar, das war kein Hochsicherheitsevent, aber das ist das Beispiel, das mir einfällt. Im Grunde ist es in den meisten Fällen wirklich leicht, Sicherheit zu umgehen.
  Was ich sagen will: Fundamental funktioniert unsere Welt nur deshalb, weil die meisten Menschen Dinge eben nicht ausnutzen. Menschliche Gesellschaften haben schon immer so funktioniert und werden das wahrscheinlich auch weiter tun

  • Ich erinnere mich an einen Trend unter britischen Influencern, sich mit der „Leiter und Warnweste“-Methode Zutritt zu Orten zu verschaffen, um zu zeigen, wie schwach physische Sicherheit oft ist https://www.youtube.com/watch?v=LTI0SeyhAPA
    Soweit ich weiß, ist der YouTuber Max Fosh sogar mehrfach in die International Security Expo hineingekommen. In Großbritannien benutzte er in https://www.youtube.com/watch?v=qM3imMiERdU, in den USA in https://www.youtube.com/watch?v=NmgLwxK8TvA jeweils die Aliasnamen „Rob Banks“ und „Nick Everything“.
    Ich habe mich einmal mit Sicherheitskultur beschäftigt, und meistens läuft es am Ende auf eine gleitende Skala hinaus: auf der einen Seite Sicherheit, auf der anderen Bequemlichkeit/Zugänglichkeit. Je sicherer, desto weniger zugänglich, und umgekehrt

• Für Supply-Chain-Angriffe auf Dependency-Manager wie npm, PyPI und Cargo gibt es bereits eine brauchbare Lösung. Man konfiguriert sie so, dass nur Paketversionen installiert werden, die ein paar Tage alt sind.
  Alle größeren jüngsten Angriffe wurden innerhalb eines Tages entdeckt und zurückgerollt; so hätte man sie sicher vermeiden können. Dieses Verhalten sollte der Standard sein. Freiwillige Beta-Tester und Security-Scanner-Firmen können ruhig die neuesten Paketversionen einen Tag früher verwenden. Eine Möglichkeit dazu gibt es hier: https://cooldowns.dev/

  • Ein solches Tool aus Show HN vor 3 Monaten scheint mir passender: https://github.com/artifact-keeper
    Ein Artefakt-Manager. Er sorgt dafür, dass nur genehmigte Dinge bezogen werden. Man kann schnell aktualisieren, wenn es nötig ist, und ansonsten konsistent validierte stabile Versionen verwenden. Man braucht ein wenig Konfigurations-Override, aber das ist leicht machbar.
    Ich habe mir einmal ein ähnliches, eher zusammengebasteltes Tool für denselben Zweck selbst gebaut; das hier ist ein gutes Projekt
  • Besser ist, wenn Unternehmen nur verifizierte Repositories verwenden und niemand direkt aus Internet-Repositories installieren darf.
    Außerhalb von Unternehmen funktioniert das natürlich nicht ohne Weiteres
  • Bekommt man dann Sicherheitsupdates nicht auch später? Viele Schwachstellen existieren jahrelang in realen Umgebungen, bevor sie entdeckt und gepatcht werden.
    Sobald sie entdeckt sind, gibt es direkt eine Explosionswelle von Exploits, und verzögerte Updates geben aufgeregten Angreifern mehr Zeit
  • Ich persönlich halte das Linux-Distribution-/BSD-Ports-/Homebrew-Modell für am nachhaltigsten. Neue Bibliotheken werden nicht direkt in ein öffentliches Register gepusht, sondern es werden Packaging-Skripte geschrieben, die bei jeder neuen Änderung überprüft werden.
    Ein anderes Modell ist Perl-CPAN, das nur Quelldateien verteilt

• Wer Continuous Integration und containerisierte Builds erst relativ kürzlich eingeführt hat, sollte prüfen, ob das System bei jedem Build aus mehreren Paketen latest zieht.
  Wir erstellen einen Basis-Container, in dem alle externen Abhängigkeiten enthalten sind, und aktualisieren ihn nur dann explizit, wenn wir entscheiden, dass es Zeit dafür ist.
  Dadurch hinken wir dem neuesten Stand vielleicht etwas hinterher, tragen aber viel weniger das Risiko, dass zufällige Supply-Chain-Schwachstellen sofort weltweit ausgerollt werden

  • Du wirst feststellen, dass das auch die CI-Build-Zeiten und instabile Fehlschläge deutlich reduziert
  • Zusätzlich sollte man nur interne Repositories verwenden

• Das ist ein aktiv schädlicher Meinungsbeitrag. Die Logik ist schwer nachzuvollziehen.
  Es dauert 45 Sekunden zu prüfen, wie alt die Schwachstellen copyfail und dirtyfrag tatsächlich sind. Das ist länger als das Lesen des Artikels. Dirtyfrag kann Systeme betreffen, die bis 2017 zurückreichen.
  Betroffen ist also nicht „neue“ Software. Und tatsächlich ist ältere Software in einem schlechteren Zustand, weil es viel mehr Zeit gab, Probleme darin zu finden

  • Der ursprüngliche Beitrag schlägt vor, derzeit keine NPM-Pakete zu installieren oder zu aktualisieren, weil ein Supply-Chain-Angriff im Moment besonders schlimm wäre, und so dieses Risiko zu senken

• Irgendwann wird jemand den gesamten Stack vom Betriebssystem bis zur Anwendung mit Upgrades auf Basis von Proof-Carrying Code neu bauen.
  Der einzige Weg, vertrauenswürdigen Code auszuführen, ist Co-Design und Co-Build von Beweisen und Code

• Das gilt nicht nur für Software, sondern eigentlich für fast alles.
  Ich weiß nicht mehr, wo ich das gelesen habe, aber am Ende läuft es auf den Unterschied zwischen Bedarf und Wunsch hinaus.
  Ich habe diese Regel schon benutzt, wenn ich zwischen Neuwagen und Gebrauchtwagen, zwischen teurem Staubsauger und Basismodell gewählt habe. Das Gleiche gilt für glänzende neue Gadgets, dafür, etwas Neues in den Tech-Stack aufzunehmen, oder einen neuen Tech-Stack auszuwählen

• Ich würde gern besser verstehen, was copyfail ist und wie es mit NPM-Paketen zusammenhängt.
  So wie ich es bisher verstanden habe, ist copyfail ein Kernel-Bug, der es einem bösartigen npm-Paket ermöglichen könnte, auf einem Linux-Server Root-Rechte zu erlangen.
  Das würde bedeuten, dass jetzt, wo es noch ungepatchte Server gibt, der perfekte Zeitpunkt für Angreifer wäre, auf NPM-Pakete zu zielen.
  Liegt der Grund, warum der Rat nicht einfach „aktualisiert euren Kernel“ lautet, darin, dass weiterhin neue verwandte Probleme gefunden werden, die noch nicht gepatcht sind?

  • Für die neuesten Schwachstellen gibt es noch gar keine Patches. Deshalb wäre jetzt, wenn ein neuer Supply-Chain-Angriff passiert, ein besonders schlechter Zeitpunkt, weil man auf fast jedem System Root bekommen könnte
  • NPM-Supply-Chain-Angriffe verbreiten sich extrem schnell.
    Wenn ein beliebtes NPM-Paket kompromittiert würde und einen copy.fail-Exploit enthielte, wären viele Systeme für eine Root-Rechteausweitung verwundbar
  • Der Grund, warum der Rat nicht „aktualisiert euren Kernel“ lautet, ist, dass es keine Updates gibt. Für die neuesten nach copy.fail entdeckten Schwachstellen gibt es noch keine Fixes