/fefe/ – Fefes Kommentarfunktion

Von der Leyen gives nod to €100 billion ‘CERN for AI’ proposal [0].

Umgerechnet fünf Fusionskraftwerke. Aber hey, "KI" braucht ja keinen Strom, gell?

[0] https://www.euractiv.com/section/digital/news/von-der-leyen-gives-nod-to-e100-billion-cern-for-ai-proposal/

https://blog.fefe.de/?ts=985dac23

OpenAI macht wohl 5 Milliarden Miese dieses Jahr [0]. Spaß am Rande: Der Artikel darüber wurde offenbar auch von einer "KI" geschrieben.

>OpenAI soll etwa sieben Milliarden US-Dollar für die Entwicklung neuer KI-Modelle ausgeben. 1,5 Milliarden US-Dollar bezahlen sie den Mitarbeitern. Laut einem Bericht von The Information kommen aber offensichtlich nur etwa 2,5 Milliarden US-Dollar rein. Das Magazin beruft sich auf Informanten und nicht veröffentlichte Finanzberichte, die nahelegen, OpenAI werde in den kommenden zwölf Monaten kein Geld mehr zur Verfügung haben. Sie schreiben von fünf Milliarden US-Dollar Verlusten in diesem Jahr.

7 + 1,5 - 2,5 sind 6 Milliarden Miese, nicht 5.

Die 1,5 Milliarden für Gehälter fand ich ein bisschen viel, aber angeblich hat OpenAI 2500 Angestellte. Das läppert sich.

[0] https://heise.de/-9813052

https://blog.fefe.de/?ts=985c8fa5

Aus der beliebten Reihe "wäre billiger gewesen, gleich auf mich zu hören", heute: Captchas sind Scheiße [0].

>We explore the cost and security of reCAPTCHAv2 and conclude that it has an immense cost and no security. Overall, we believe that this study’s results prompt a natural conclusion: reCAPTCHAv2 and similar reCAPTCHA technology should be deprecated.

Ja NO SHIT, Sherlock! Hätte uns doch nur jemand rechtzeitig gewarnt!1!!

[0] https://arxiv.org/pdf/2311.10911

https://blog.fefe.de/?ts=985e3aac

AMD entdeckt noch schnell ein paar unspezifizierte Qualitätsprobleme in ihren Ryzen 9000 CPUs und verschiebt den Launch [0].

Das feier ich ja gerade. Was für ein großartiger Move. Auf der einen Seite sagen sie ihren Kunden: Bei uns ist das nicht wie bei Intel. Wir shippen lieber funktionierende Produkte und testen vorher.

Auf der anderen Seite liegt die Vermutung nahe, dass die unspezifizierten Qualitätsprobleme nicht bei ihnen sondern bei Intel liegen [1] :-)

Könnte sein, dass AMD gesehen hat, dass Intel unlauter die Benchmarks frisieren will, und lässt die jetzt mal so richtig auflaufen.

Oder die haben wirklich unspezifizierte Qualitätsprobleme. Kann auch sein.

[0] https://www.tomshardware.com/pc-components/cpus/amd-delays-its-ryzen-9000-launch-due-to-unspecified-quality-issue-new-launch-in-august-chipmaker-pulls-back-all-units-shipped-globally-for-quality-checks
[1] https://blog.fefe.de/?ts=9861270f

https://blog.fefe.de/?ts=985f44d1

CrowdStrike will be liable for damages in France, based on the OVH precedent [0].

[0] https://thehftguy.com/2024/07/25/crowdstrike-will-be-liable-for-damages-in-france-based-on-the-ovh-precedent/

https://blog.fefe.de/?ts=985cb8dd

Ihr müsst jetzt sehr tapfer sein.

77% Of Employees Report AI Has Increased Workloads And Hampered Productivity, Study Finds [0].

>Despite 96% of C-suite executives expecting AI to boost productivity, the study reveals that, 77% of employees using AI say it has added to their workload and created challenges in achieving the expected productivity gains. Not only is AI increasing the workloads of full-time employees, it’s hampering productivity and contributing to employee burnout.
>
>To add insult to injury, nearly half (47%) of employees using AI say they don’t know how to achieve the expected productivity gains their employers expect, and 40% feel their company is asking too much of them when it comes to AI. Workers are feeling the strain from rising productivity demands, with one in three full-time employees saying they will likely quit their jobs in the next six months due to feeling overworked and burnt out. The majority of global C-suite leaders (81%) acknowledge they have increased demands on their workers in the past year. Consequently, 71% of full-time employees are burned out, and 65% report struggling with their employer’s demands on their productivity.

Ja Scheiße, Bernd! Hätte uns das doch nur vorher jemand gesagt!

Aber wer konnte auch ahnen, dass der nächste Bullshit-Hype, der durchs Dorf getrieben wird, schon wieder ein Vehikel für Scammer sein würde, und am Ende vor allem negative Auswirkungen auf die Umwelt haben würde!?

[0] https://www.forbes.com/sites/bryanrobinson/2024/07/23/employees-report-ai-increased-workload/

https://blog.fefe.de/?ts=985e277b

Ich habe hier gerade ein faszinierendes dietlibc-Problem.

dietlibc hat eine libc.a und eine libpthread.a. Wenn man mit -pthread baut, wird auch libpthread.a reingelinkt.

Mehrere Symbole gibt es sowohl in libc als auch in libpthread, z.B. wenn man fputc aufruft, um ein Zeichen in ein FILE* zu schreiben. Die libc-Variante schreibt halt ein Zeichen, und die libpthread-Variante holt sich einen Mutex, schreibt dann das Zeichen, und lässt den Mutex dann wieder gehen.

Für die Korrektheit des Programms ist es also wichtig, dass die libpthread-Variante gewinnt.

Das ist relativ einfach:



OK, nächstes Problem: fopen. fopen ruft eine Init-Funktion auf, die ein FILE* alloziert und initialisiert. Die Variante der Init-Funktion in libpthread alloziert mehr Platz für den Mutex und initialisiert den. So und jetzt kommt das Problem: Hier gewinnt bei obigem gcc-Aufruf nicht etwa die Variante aus libpthread sondern die aus libc.

Ich habe mal ein Ticket aufgemacht bei GNU binutils (wo GNU ld herkommt), und die um Rat gebeten. Die meinten, ich soll -lc -lpthread machen.

Ich habe also einen kleinen Demonstrator gebaut, bei dem das auch nicht hilft. Schlimmer noch: Es gibt ja noch andere Linker als GNU ld. Es gibt noch GNU gold (auch aus binutils), lld (von LLVM) und mold (separates Projekt von dem Autor von lld). ld und gold sind sich einig, und lld und mold sind sich in die Gegenrichtung einig.

Das ist jetzt ein ziemlich riesiges Problem für mich, denn wenn ich nicht dafür sorgen kann, dass die Init-Funktion aus libpthread immer gewinnt, dann kriege ich Speicherkorruption, weil die aus libc zu wenig alloziert, aber dann jemand auf dem nicht mitallozierten Mutex herumpolkt. Und das Programm ist natürlich auch kaputt dann.

Falls ihr mal gucken wollt: Hier ist das binutils-Ticket [0]. Ich bin mal sehr gespannt, was die Nerds da jetzt vorschlagen.

[0] https://sourceware.org/bugzilla/show_bug.cgi?id=32006

https://blog.fefe.de/?ts=98614396

Netanjahus Ehefrau [0] soll jahrelang kofferweise Dreckwäsche auf Staatsbesuche mitgenommen haben, damit sie die dann dort im Hotel reinigen lassen kann, wofür dann der Staat Israel zahlt.

Immer dieser fiese antisemitische Judenhass, der die ganzen rassistischen Stereotype bedient!!1!

[0] https://www.timesofisrael.com/pms-wife-accused-of-sending-dirty-clothes-on-state-trips-for-dry-cleaning/

https://blog.fefe.de/?ts=985e118e

Ich amüsiere mich gerade über diese Meldung [0]. Das BSI hat gemerkt, dass alle KRITIS-Branchen von Crowdstrike betroffen waren, und sie wollen jetzt Microsoft und Crowdstrike "in die Pflicht nehmen".

Lasst mich mal kurz die ketzerische Frage stellen, warum die alle betroffen waren!

Ja warum denn, lieber Fefe? Na weil das fucking BSI denen vorgeschrieben hat, sie müssen ihre EDV "nach Stand der Technik" mit Schlangenöl tapezieren!

Und jetzt passiert völlig überraschend, was schon immer klar war: Das Zeug ist Software und hat auch Fehler.

Eigentlich sollte das BSI mal sich selbst in die Pflicht nehmen, wieso sie den Firmen gesagt hat, dass sie diesen Mist brauchen. Glaubt mal gar nicht, dass Carbon Black irgendwie besser ist, oder wie die Konkurrenten alle heißen. Das ist alles derselbe Klärschlamm, der da die Getriebe mit Sand füllt.

Also, liebes BSI. Ich finde auch, dass Microsoft und Crowdstrike in die Pflicht genommen werden sollten. Microsoft sollte endlich für ihre Ranzsoftware haften, und Crowdstrike sollte für die Schäden aufkommen, inklusive der Gehälter der IT-Leute, die hinter ihnen herräumen mussten. Das soll ruhig mehrere Milliarden kosten, Crowdstrike hat eine unfassbar große Marktkapitalisierung.

Aber stoppt da nicht. Nehmt als nächstes das BSI in die Pflicht. Es soll bitte von diesem pseudowissenschaftlichen Esoterik-Scheiß weg und evidenzbasiert arbeiten. Angriffsoberfläche kann man messen, und man kann sie minimieren. Potentielle Auswirkung von Sicherheitslücken kann man quantifizieren und das Risiko minimieren. Aber DAS schlägt das BSI irgendwie nie vor. Sie faseln lieber was von "secure by default" (was völlig sinnentleert ist und nichts konkretes bedeutet) und empfehlen flächendeckende Schlangenöl-Kontamination.

Und wenn dann was passiert, dann zeigen sie auf Microsoft und Crowdstrike.

[0] https://www.heise.de/news/Globaler-IT-Ausfall-BSI-nimmt-Crowdstrike-und-Microsoft-in-die-Pflicht-9811854.html

https://blog.fefe.de/?ts=985fe611

Ich möchte auch noch mal kurz aus Sicht eines Code Auditors auf diese Crowdstrike-Sache gucken.

Wie kommen solche Dinge zustande? Die hatten doch Code Audits von ihrer Software!

Das kann ich aufklären. Bei Code Audits sagen die Auftraggeber, was "in scope" ist und was nicht. Typischerweise sind Config-Dateien nicht in Scope, weil Crowdstrike findet, die können ja schließlich nur von uns kommen, und der Übertragungsweg ist kryptografisch gesichert, also kann da nichts passieren.

Dazu kommen so Überlegungen der Form (je nach Mächtigkeit der Konfigurationsmechanismen): Wenn der Angreifer DA Dinge zu unseren Kunden pushen kann, dann ist eh alles verloren!1!!

Am Anfang meiner Karriere habe ich mich über diesen Scope-Scheiß noch endlos aufgeregt und da gegen Windmühlen gekämpft. Ich habe z.B. wochenlang mit Microsoft verhandelt, dass USB eine Security Boundary ist, d.h. etwas, wo ein erfolgreicher Angriff schlecht ist und verhindert werden sollte. Microsoft fand damals, USB sei ein physischer Angriffsvektor und die seien eh nicht zu verhindern, da könne ja auch jemand mit einem Hammer kommen und das Gerät kaputthauen. Also war USB jahrelang kein Angriffsvektor, und damit auch nicht die Filesysteme und die Autorun-Dateien darauf. Das hat sich erst geändert, als das USB-Forum "wireless USB" standardisierte, also das über Funk erreichbar war. Das kam nie weit, aber hat fundamental Tore aufgemacht bei Microsoft und ich vermute auch bei anderen Betriebssystemherstellern.

Ich habe bei Microsoft auch mal den SMB-Code auditiert, und habe dann einen Riesenschreck gekriegt, als die ETERNALBLUE von der NSA bekannt wurde. Hatte ich das übersehen? Nein, hatte ich nicht. Das Scope endete ca 3cm links davon. Ich sollte SMB angucken, und ETERNALBLUE war ein RPC über eine Named Pipe von SMB. Andere Arbeitsgruppe, out of scope.

Wenn ihr also mal einen Code Audit oder Pentest beauftragt, tut mir einen Gefallen und erzählt den Auditoren nicht, was in Scope ist und was nicht. Ihr habt die eingeladen und beauftragt, weil ihr glaubt, dass die wissen, wo die Bugs sind. Dan lasst sich auch dort gucken, um Himmels willen!

https://blog.fefe.de/?ts=985fe3b7