Ich bereite ja gerade den Fnord-Jahresrückblick vor und gehe nochmal durch alle Blogmeldung des Jahres durch. Der Eindruck drängt sich geradezu auf, dass die Security-Firmen mich nötigen wollen, eine Kategorie für sie einzuführen.
Das Problem habe ich leider jedes Jahr aber so schlimm wie diesmal war es noch nie. Und es hört auch nicht auf! Guckt euch nur mal Palo Alto [0] an. So blöde ist ja hoffentlich keiner von euch, bei denen zu kaufen. Die Meldung da ist vom Juni.
Die stellen also ihr "Expedition"-Produkt ein, das noch nie durch eine vertrauenswürdige Qualitätssimulation aufgefallen ist.
Warum? Nun, das könnte etwas hiermit zu tun haben: auth bypass [1] (schöner Writeup dazu [2]) SQL Injection [3] OS Command Injection [4].
Ich applaudiere ja Palo Alto, dass sie erkennen, das ihr Produkt Schrott ist und weggeschmissen gehört. Das sollten viel mehr Hersteller machen. Aber wieso bei Expedition aufhören? PAN-OS [5] hat genau [6] solche Bugs [7] auch gehabt. Von anderen Herstellern wie Fortinet oder Cisco mal ganz zu schweigen.
Mich fragte heute jemand, ob die das abreißen, weil zu viele Bugs reinkamen, und sie daher gemerkt haben, wie schrottig das ist. Meiner Erfahrung nach wissen alle Hersteller, wie schlecht ihre Produkte sind. Einige wollen es auf Management-Schicht nicht wahrhaben, und ganz, GANZ selten gibt es auch Produkte, bei denen die Ingenieure nicht wissen, wie Scheiße ihr Produkt ist, aber das ist echt die Ausnahme. Habe ich in knapp 30 Berufsjahren zweimal erlebt. Die meisten Firmen wissen das, und die sehen das als Gelegenheit, mit Supportverträgen Profit zu machen.
Häufig ist das so, dass ein Produkt ein Team hat, das über die Jahre technical debt aufgehäuft hat, und häufig geht der Verantwortliche dann, weil ein Mann von meiner Statur muss sich nicht mit brennenden Mülltonnen herumärgern, und der Rest des Teams erzählt mir beim Audit dann "das ist nicht mein Code, ich habe den bloß geerbt" (soll heißen: Ich habe keine Ahnung, was der tut, und traue mich nicht den anzufassen). Da kann ich echt die Uhr nach stellen bei Audits.
Natürlich will niemand in den Rückbau von technical debt investieren, daher wird das immer teurer und träger und am Ende sitzt man Monate auf Bugfixes (das Palo-Alto-Dingens gerade wurde denen im Juni gemeldet). Und guckt euch mal an, was das für ein geiler Bug ist. Die haben da eine PHP-Datei, per Web erreichbar, die das Admin-Passwort auf "paloalto" zurücksetzt. Ohne Authentisierung, versteht sich. Kann man einfach aufrufen und ist Admin.
Sorry, aber das ist kein "Bug". Das wusste die Firma auch, dass sie das haben. Dafür müsste in einer gerechten Welt jemand in den Knast.
Übrigens, am Rande: Falls ihr euch dachtet, Programmierer würden doch von ihrer Ethik und ihrer guten Erziehung davon abgehalten, brennende Mülltonnen in der Landschaft zu verteilen, dann solltet ihr diesen Artikel lesen [8]. Programmierer sind von allen Berufsgruppen die unethischsten. Alle haben ein schlechtes Gewissen und fühlen sich als Betrüger, wenn sie "KI" fragen und dann so tun als sei das ihre Arbeit gewesen. Außer Programmierern. Die finden das normal.
>Zentrale Gründe für das Unbehagen seien das Gefühl, Nutzung generativer KI fühle sich wie Mogeln an (47 Prozent), sowie Ängste, als weniger kompetent (46 Prozent) oder gar faul gesehen zu werden (46 Prozent).
>
>In Deutschland waren es hauptsächlich Nachrichten an Chef (31 Prozent) oder an Kollegen auf der gleichen Hierarchiestufe (27 Prozent), Leistungsbeurteilungen (24 Prozent) oder Ideen-Brainstormings (22 Prozent), bei denen Befragte keine KI-Nutzung eingestehen mochten. Sich beim Coden von der KI helfen zu lassen, wäre hingegen nur neun Prozent peinlich.
Coder sind schlechte Menschen. Nur schlechte Menschen wie Scammer, Spammer, Marketing-Kokser und Coder lassen sich von "KI" helfen und haben kein schlechtes Gewissen.
[0] https://live.paloaltonetworks.com/t5/expedition-articles/important-update-end-of-life-announcement-for-palo-alto-networks/ta-p/589642
[1] https://censys.com/cve-2024-5910/
[2] https://www.horizon3.ai/attack-research/disclosures/palo-alto-expedition-from-n-day-to-full-compromise
[3] https://nvd.nist.gov/vuln/detail/cve-2024-9465
[4] https://www.cve.org/CVERecord?id=CVE-2024-9463
[5] https://www.cve.org/CVERecord?id=CVE-2024-3400
[6] https://www.cve.org/CVERecord?id=CVE-2017-15944
[7] https://www.cve.org/CVERecord?id=CVE-2020-2021
[8] https://www.heise.de/news/KI-Tools-im-Buero-Chefs-im-Investitionsrausch-Angestellte-zunehmend-verhalten-10034384.html
https://blog.fefe.de/?ts=99c5ffa0