Das curl-Projekt stellt zu Ende Januar das Bug-Bounty-Projekt ein. Damit können IT-Forscher keine Prämie mehr für gefundene und gemeldete Sicherheitslücken in dem populären Open-Source-Tool bekommen.

Das hat Daniel Stenberg, seines Zeichens Maintainer von curl und libcurl, nun im sozialen Netzwerk Mastodon bekannt gegeben. Das hat auch Einzug in die curl-Quellcodes auf Github gefunden.

Demnach entfernt Stenberg Hinweise auf das Bug-Bounty-Programm auf HackerOne aus den Projekt-Quellen. Die Links dorthin werden entfernt. Bei Verdacht auf Sicherheitsprobleme sollen sich die Entdecker im Privaten an curl respektive Stenberg wenden. Die curl-Webseite zu dem gewünschten Prozedere zum Melden einer Schwachstelle verweist jetzt noch auf das Bug-Bounty-Programm. Allerdings finden sich bereits jetzt Hinweise, dass sich IT-Forscher an die Mailingliste security(at)curl(dot)se wenden sollen, was jedoch einige Voraussetzungen hat.

Die könnten eher abschreckend wirken: „Wir verlangen im Grunde genommen nur, dass du seit Langem am Curl-Projekt beteiligt bist und Verständnis für das Projekt und seine Arbeitsweise gezeigt hast nicht vorhaben, in naher Zukunft wieder zu verschwinden.“ Das wird sich vermutlich mit dem Ende des offiziellen Bug-Bounty-Programms jedoch ändern.

Gründe noch nicht genannt

Zu den konkreten Gründen für diesen Schritt hat Stenberg sich bislang nicht geäußert. Auf Mastodon reagierte ein User mit dem Kommentar: „Ich glaube nicht, dass das den Slop stoppen wird“, was die Kurzform von „AI Slop“ oder auf Deutsch „KI-Müll“ ist. Stenberg entgegnete dem mit „Nichts kann das stoppen, aber wir können das hoffentlich ausbremsen, indem wir einen starken Anreiz wegnehmen“.

Es liegt nahe, dass Stenberg den Schritt wegen zunehmender „KI-Müll-Meldungen“ geht. Er hatte sich des Öfteren massiv und frustriert über unbrauchbare Bug-Reports beschwert, die sich plausibel lesen und viel Arbeit zum Nachvollziehen verschlingen, sich dann aber als unsinnig herausgestellt haben. Auf LinkedIn schrieb er im Mai vergangenen Jahres deshalb bereits „Ich habe die Nase voll. Ich spreche ein Machtwort wegen dieses Irrsinns“.

Eine Anfrage zu den Gründen für das Ende des Bug-Bounty-Programms hat Stenberg nicht unmittelbar beantwortet. Ein Statement reichen wir an dieser Stelle bei Verfügbarkeit nach.

curl, kurz für „Client for URLs“ ein mächtiges, quelloffenes Werkzeug und eine Bibliothek zum Übertragen von Daten über diverse Protokolle wie HTTP, FTP und zahlreiche weitere. Die Glücksritter, die ihre KI-Tools teils offenbar auch ohne Sachverstand auf die curl-Quellen losgelassen haben, können ab Monatsende zumindest an curl kein Geld mehr verdienen.

(dmk)

Besitzer älterer Apple-Rechner, die Googles Chrome schätzen, müssen sich in absehbarer Zeit eine Alternative suchen: Google hat auf seiner Chrome-Platform-Status-Website offiziell angekündigt, dass ab der Desktop-Version 151 von Chrome macOS 13 alias Ventura zur Mindestvoraussetzung wird. Das Betriebssystem war im Herbst 2022 erschienen. Demnach wird Chrome 150 die letzte Version sein, die noch auf macOS 12 alias Monterey lauffähig ist. Google schreibt, Monterey sei ja sowieso „outside of its support window with Apple“, werde also auch vom Mac-Hersteller nicht mehr unterstützt.

macOS 12 selbst ist ungeschützt

Zur Einordnung: Momentan ist Chrome 144 aktuell. Es lässt sich nicht genau sagen, wie lange es dauert, bis Version 151 erscheint. Bliebe Google bei einem Release-Rhythmus von ungefähr einmal im Monat, hätten die User wohl noch bis Spätsommer oder Herbst Zeit – denkbar ist aber auch Winter.

Grundsätzlich ist es zwar unklug, ein altes Betriebssystem wie Monterey, das von 2021 stammt, auf einem Mac mit Internet-Zugang weiterzuverwenden, da Apple seit längerem keine Sicherheitsupdates mehr liefert. Allerdings stellte die Verwendung von Chrome sicher, dass man zumindest nicht in rein Browser-basierte Lücken hineinlief, da dieser Browser im Gegensatz zu Apples hauseigenem Safari, der Teil von macOS ist, noch regelmäßig abgedichtet wurde.

Die Situation bei Firefox

Bei der Konkurrenz von Mozilla ist die Lage bereits schlechter für User alter Macs. Firefox hatte mit Version 115 entschieden, Macs mit macOS 10.12, 10.13 und 10.14 in den sogenannten Extended Support Release (ESR) zu schieben. Dabei handelt es sich um Versionen des Browsers, die nicht alle neuen Funktionen erhalten und vor allem auf Stabilität ausgerichtet sind, deshalb werden sie etwa von Enterprise-Kunden geschätzt.

Der Standard-Firefox ist mittlerweile bei Version 147 angekommen, die ESR-Variante bei Version 140. Letztere läuft aber verwirrenderweise nur auf macOS 15 und höher, Nutzer mit macOS 14 und darunter benötigen ESR-Version 115, die noch bis März 2026 unterstützt werden soll. Danach ist damit auch Schluss.

(bsc)

Unter bestimmten Bedingungen können Angreifer an einer Sicherheitslücke in PAN-OS ansetzen und so Firewalls von Palo Alto Networks attackieren. Bislang gibt es dem IT-Sicherheitsunternehmen zufolge keine Hinweise auf Attacken.

Die Gefahr

Setzen Angreifer erfolgreich an der DoS-Lücke (CVE-2026-0227 „hoch“) an, können sie Geräte in den Wartungsmodus versetzen. In diesem Zustand ist davon auszugehen, dass der Firewallschutz ausgehebelt ist. In einem Beitrag führen die Entwickler aus, dass ausschließlich PAN-OS NGFW und Prisma-Access-Konfigurationen mit aktiviertem GlobalProtect-Gateway/-Portal verwundbar sind.

Cloud NGFW soll gegen die geschilderte Attacke bereits abgesichert sein. Für PAN-OS sind die folgenden Sicherheitspatches erscheinen:

• 10.2.7-h32 oder 10.2.18-h1
• 10-h30 oder 10.2.18-h1
• 10.2.13-h18 oder 10.2.18-h1
• 10.2.16-h6 oder 10.2.18-h1
• 10.2.18-h1
• 11.1.4-h27 oder 11.1.13
• 11.1.6-h23 oder 11.1.13
• 11.1.10-h9 oder 11.1.13
• 11.1.13
• 11.2.4-h15 oder 11.2.10-h2
• 11.2.7-h8 oder 11.2.10-h2
• 11.2.10-h2
• 12.1.4
• Prisma Access 10.2.10-h29, 11.2.7-h8

(des)