Der aktuelle MTN-Artikel zur Zoom-Malware brachte mich dazu, diesen Thread zu erstellen, auch wenn er nicht direkt mit brew zu tun hat und das Installieren von Zoom per brew in dem Fall eher ein Schutz wäre.

Ich installiere eigentlich so gut wie alles per brew, von Adobe über Microsoft Office bis eben hin zu Zoom (und nicht nur Casks, sondern auch Formulae wie azure-cli, herdr, ffmpeg oder zsh). Als ich vor Jahren aus Bequemlichkeit dazu über gegangen bin, Software wenn möglich per brew zu installieren (vor allem auch auf neuen Geräten sehr zeitsparend), habe ich mich gefragt, wie sicher das alles eigentlich ist, da es ja kein offizieller Installationsweg ist, sondern die Community effektiv auf die entsprechenden Installationsdateien verweist. Ich habe dann aber nicht weiter darüber nachgedacht und so ist es bei mir zum Standard geworden.

Nachdem aber zunehmend auch Maintainer und Paketdienste (wie zuletzt npm) als Schwachstellen angesehen werden, wollte ich mich bei euch mal erkundigen, wie ihr dazu steht. Die Frage richtet sich hauptsächlich an diejenigen, die Homebrew kennen und eben nutzen oder nicht nutzen. Ist das Nutzen von brew eher sicherer oder unsicherer geworden? Gibt es Maßnahmen, um sich zusätzlich abzusichern (bspw. neue Versionen erst nach einer Karenzzeit installieren)? Oder sollte man doch direkt von der Herstellerseite laden und bestenfalls (falls vorhanden) den Hash abgleichen? Bei letzterem denke ich mir, dass wenn man die Installationsdatei verändern kann, auch den Hash auf der Webseite ändern kann.

Aber genug geredet. Kurzum: Ich mache mir vermehrt Sorgen, ob ich durch das Nutzen von brew nicht fahrlässig bin und würde gerne eure Meinung dazu hören.

Die Frage ist berechtigt, sie stellt sich aber für den Apple App Store genauso, über den ebenfalls schon Schadsoftware verbreitet wurde.

Bei Casks baut Homebrew nichts selbst. Der Cask-Download kommt vom selben Server wie beim manuellen Download beim Entwickler. Downloadadresse und Prüfsumme liegen aber in einem öffentlichen GitHub-Repository. Einige Casks verzichten allerdings auf eine Prüfsumme.

Die eigentlich unabhängige Prüfung ist deshalb die Signatur. Homebrew schaltet seit September alle Casks ab, die die Gatekeeper-Prüfung nicht bestehen, also nicht notarisiert sind. Die Option --no-quarantine, mit der man Gatekeeper umgehen konnte, ist entfernt.

Entwickler ohne Notarisierung müssen ihre Software in Taps anbieten. Seit ca. Juni (Homebrew 6) muss man einem solchen Tap ausdrücklich vertrauen, also bestätigen, bevor man von dort installieren kann.

Mit brew pin lassen sich Casks auf einer Version festhalten. Das wäre so eine Art Karenzzeit.

Ein Sicherheitsaspekt der für Homebrew spricht: Wer brew install zoom eintippt, landet nicht bei irgendeiner Fake-Website über die Mac-Malware verteilt wird, sondern bei brew.sh. Für Software aus dem offiziellen Repository halte ich eher für sicherer als den manuellen Download.

In Teilen kann man mit brew Software installieren ohne nach einem Admin-Passwort gefragt zu werden. Da kann natürlich auch mal etwas Böses darunter sein, insbesondere durch diese "SupplyChainAttacks". Das würde heißen, da wird das "Manifest" für ein HomeBrew-Paket manipuliert wird, um Malware auszuliefern. Das Risiko besteht, ist aber nicht größer als bei GitHub oder dergleichen das falsche Paket geladen zu haben.

Viel kiritscher bei den SupplyChainAttacks auf NPM war, dass jemand Malware über die npmjs.org Registry anderen Produkten untergejubelt hat. Gerade Apps, die auf NodeJS beruhen (das gab es aber schon bei Python und auch Rust ist davor nicht geschützt), verwenden diese Registry, da man ja nicht jedes Mal das Rad neu erfinden mag. Man greift bequem auf Module anderer zu, was legal ist, solange diese OpenSource sind. Wenn man da ein häufig verwendetes Modul manipuliert, dann wird das beim Bauen der Apps (kann auch Webseiten betreffen) von tausenden Projekten geladen und eingebunden ohne dass der Entwickler etwas davon merkt. Diese fungieren dann als Multiplikatoren der Malware - das macht diese Angriffe so kritisch. Dafür gibt es bei npm eine eigene CVE-Datenbank. Mit "npm audit" kann man dann gezielt nach CVEs und Malware suchen, die sich in den verwendeten Paketen verstecken und gegebenenfalls durch Updates bereinigen. Diese DB bei npmjs.org wird relativ schnell bei solchen Bedrohungen aktualisiert. Das sollte zum "guten Ton" von Entwicklern gehören. Diese Angriffe (wie damals bei "Shaihulud") haben also eine viel größere Dimension.

Als Nutzer/Kunde könnte man natürlich in Zukunft nach den SBOMs fragen und mit entsprechenden Tools nach Sicherheitslücken in den verwendeten Komponenten suchen.
Tatsächlich ist das eine meiner Aufgaben bei meinem Arbeitgeber - SBOMs für unsere Produkte erstellen und validieren, dass diese keine Sicherheitslücken enthalten.