Logbuch:Netzpolitik
Einblicke und Ausblicke in das netzpolitische Geschehen
https://logbuch-netzpolitik.de


LNP551 Schöne Fotos vom Weltuntergang

MERZ — Digitale Gewalt — Satoshi Nakamoto — Claude Mythos

Neben den drei großen Themen der Sendung gibt es heute erst mal Begriffsklärung in punkto Kunst und ihr dürft in Tims Schulzeit eintauchen. Danach ein Nachtrag zum Thema Digitale Gewalt und wir reflektieren kurz die jüngste Recherche der New York Times, die glaubt, dem Bitcoin-Erfinder auf die Schliche gekommen zu sein, der nur unter dem Pseudonym Satoshi Nakamoto bekannt ist. Den Rest der Sendung widmen wir der Ankündigung des neuen KI-Modells von Anthropic "Mythos", das wohl das Zeug dazu hat, die Cybersicherheit von Open Source Software grundlegend aufzumischen.

https://logbuch-netzpolitik.de/lnp551-schoene-fotos-vom-weltuntergang
Veröffentlicht am: 9. April 2026
Dauer: 1:55:48


Kapitel

  1. Intro 00:00:00.009
  2. Prolog 00:00:29.671
  3. MERZ 00:06:55.383
  4. Digitale Gewalt 00:19:14.124
  5. Satoshi Nakamoto 00:34:31.513
  6. Claude Mythos 00:52:50.085
  7. Epilog 01:50:04.541
  8. Bonus Track 01:52:08.235

Transkript

Tim Pritlove
0:00:00
Linus Neumann
0:00:02
Tim Pritlove
0:00:03
Linus Neumann
0:00:08
Tim Pritlove
0:00:30
Linus Neumann
0:00:51
Tim Pritlove
0:00:57
Linus Neumann
0:01:03

Ja.

Tim Pritlove
0:01:04
Linus Neumann
0:01:12
Tim Pritlove
0:01:16
Linus Neumann
0:01:23

Ja.

Tim Pritlove
0:01:24
Linus Neumann
0:01:26
Tim Pritlove
0:01:46
Linus Neumann
0:02:04
Tim Pritlove
0:02:14
Linus Neumann
0:02:27
Tim Pritlove
0:02:56
Linus Neumann
0:02:59
Tim Pritlove
0:04:04
Linus Neumann
0:04:13
Tim Pritlove
0:04:25
Linus Neumann
0:04:27
Tim Pritlove
0:04:28
Linus Neumann
0:04:37
Tim Pritlove
0:04:58
Linus Neumann
0:05:01
Tim Pritlove
0:05:09
Linus Neumann
0:05:18
Tim Pritlove
0:05:43
Linus Neumann
0:05:48
Tim Pritlove
0:05:54
Linus Neumann
0:05:57
Tim Pritlove
0:06:12
Linus Neumann
0:06:15
Tim Pritlove
0:06:20
Linus Neumann
0:06:36
Tim Pritlove
0:06:49
Linus Neumann
0:07:02
Tim Pritlove
0:07:17
Linus Neumann
0:07:53
Tim Pritlove
0:08:01
Linus Neumann
0:08:07
Tim Pritlove
0:08:13
Linus Neumann
0:08:14
Tim Pritlove
0:08:17
Linus Neumann
0:08:18
Tim Pritlove
0:08:26
Linus Neumann
0:08:27
Tim Pritlove
0:08:30
Linus Neumann
0:08:54
Tim Pritlove
0:09:02
Linus Neumann
0:09:23
Tim Pritlove
0:09:27
Linus Neumann
0:09:54
Tim Pritlove
0:09:58
Linus Neumann
0:10:24
Tim Pritlove
0:10:26
Linus Neumann
0:11:10
Tim Pritlove
0:11:12
Linus Neumann
0:12:03
Tim Pritlove
0:12:14
Linus Neumann
0:12:47

Ja.

Tim Pritlove
0:12:48
Linus Neumann
0:12:49
Tim Pritlove
0:12:51
Linus Neumann
0:12:57
Tim Pritlove
0:12:59
Linus Neumann
0:12:59
Tim Pritlove
0:13:02
Linus Neumann
0:13:02
Tim Pritlove
0:13:03
Linus Neumann
0:13:05
Tim Pritlove
0:13:11
Linus Neumann
0:13:11
Tim Pritlove
0:13:12

Also Kurt Schwitters ist ein Kind Hannovers, ja? Also ist in Hannover geboren, hat dort auch gewirkt und Kurt Schwitters ist halt sehr bekannt geworden, weil er als Teil dieser Dada-Kultur des Anfangs des 20. Jahrhunderts wahrgenommen wurde und da beigetragen hat. Also er hat einfach verrücktes Zeug gemacht, das war sozusagen Kunst, die es wirklich auch ihren eigenen Humor hat, schräges Zeug gemacht hat. Und Kurt Schwitters hat sich auch mit allerlei Dingen beschäftigt und bei ihm gab es auch mal so ein Schild, was auseinandergebrochen ist. Und auf diesem stand Kommerz. Und es ist natürlich auch nach drei Buchstaben abgebrochen. Und es blieb übrig, Merz. Und Merz hat er dann beschlossen, das ist sein Wort für die Kunst, die er macht. Und hat das dann sozusagen verwendet. Und Merz ist sein persönliches Wort für diese Dada-Bewegung. Unter dem Namen Dada gab es noch sehr viele andere Künstler, die da sozusagen verrücktes Zeug gemacht haben. Bei Kurt Schmitters war das dann halt Merz und so hat er unter anderem einen Merz Bau in seiner Wohnung gebaut, also hat er so angefangen so in seiner Wohnung so kubistische Skulpturen auszubauen, das meanderte dann, eine ganze Wohnung hindurch, so ähnlich wie das übrigens auch die, Seabase in Berlin entstanden ist, die ist ja auch mal in so einer WG, in so einem WG-Zimmer, was übrig war, entstanden, da haben sie dann angefangen da so Raumschiffzeug reinzubauen und dann war das ja quasi die Seabase, bis es dann irgendwann einfach nicht mehr in diese Wohnung gepasst hat.

Linus Neumann
0:14:57
Tim Pritlove
0:15:00
Linus Neumann
0:15:59
Tim Pritlove
0:16:01
Linus Neumann
0:16:05
Tim Pritlove
0:16:06
Linus Neumann
0:16:27
Tim Pritlove
0:16:34
Linus Neumann
0:17:06
Tim Pritlove
0:17:10
Linus Neumann
0:17:24
Tim Pritlove
0:17:25
Linus Neumann
0:17:39
Tim Pritlove
0:17:40
Linus Neumann
0:17:42
Tim Pritlove
0:17:51
Linus Neumann
0:17:52
Tim Pritlove
0:18:00
Linus Neumann
0:18:38
Tim Pritlove
0:18:39
Linus Neumann
0:18:54
Tim Pritlove
0:18:58
Linus Neumann
0:18:59
Tim Pritlove
0:19:08
Linus Neumann
0:19:14
Tim Pritlove
0:19:21
Linus Neumann
0:19:24

Ja, ja, ja Anne Roth hat da ein bisschen über den aktuellen, Stand oder das, was bekannt ist, über den Gesetzentwurf, zur Verringerung digitaler Gewalt vorgetragen wir haben einen Link zu der Aufzeichnung oder da, wo sie erscheinen wird in den Shownotes, und sie hatten vor allem davon berichtet, dass es eben, strafrechtliche. Anpassungen geben soll, also Strafbarkeitslücken werden geschlossen, die es, denke ich, ohne Zweifel gibt. Ich hatte, glaube ich, in der letzten Sendung auch davon gesprochen, dass es in dem Upskirting-Paragraf, also Upskirting ist ja auch so ein Thema, also dass das nicht konsensuelle Fotografieren bestimmter Bereiche, beispielsweise eben Upskirting, der Begriff erklärt das schon, dass es quasi nicht unter einem Straftatbestand fiel oder fällt, ein derartiges Foto ohne Konsens zu machen, weil der Gesetzestext eben auf eine Weise war, sodass dieses Verhalten nicht den Definitionstatbestand erfüllt hat. Und davon gibt es relativ viele Strafbarkeitslücke. Eine Strafbarkeitslücke ist deswegen doof, weil dann eben quasi gar keine, selbst wenn du das Verhalten nachweisen kannst, es eben straffrei ist. Man darf das. In diesem Bereich sollen da eben Anpassungen stattfinden, eine Sache, die Anne da aber betont hat war, wenn man Betroffene von, digitaler Gewalt ist, dann will man ja vor allem dass man eine Handhabe hat, dass das sofort aufhört und nicht, dass man drei Jahre später oder Monate später oder was auch immer irgendwie eventuell eine Strafanzeige erfolgreich war und in einer Strafe mündet. Sondern quasi die unmittelbare Abhilfe, dass der Angriff und das Verletzen der eigenen Rechte aufhört. Das fand ich erst mal einen wichtigen Aspekt, den sie da benannt hat. Und außerdem gibt es eben den Teil der Gesetzesänderungspläne, der sich nicht auf das Strafrecht bezieht und da kann man eben mit üblem Rechnen. Unter anderem natürlich Vorratsdatenspeicherung und anderen Dingen, die so die Idee der Zielsetzung, das Zivilverfahren vereinfachen sollen. Und da hatte ich glaube ich auch schon in der letzten Sendung ein bisschen drauf hingewiesen, da lauert erst recht der Rechtsmissbrauch im Zivilverfahren, vor allem wenn es da um Auskunftsrechte, Datenspeicherung und sonstiges geht. Man könnte sich natürlich auch Gedanken darüber machen, dass die Betreiber von solchen Plattformen, wo so etwas Verbreitung findet, den Betroffenen eine Möglichkeit bieten müssen, schnell dem ein Ende zu bereiten. Das wäre eine Lösung des Problems an der Wurzel, schnelles Abschalten der rechte Verletzung und ich glaube, was daran der Vorteil wäre, ist, dass halt quasi auch das Verhalten selber demotiviert wird. Also wenn ich weiß, okay, wenn ich jetzt etwas Bestimmtes tue, das ist strafbar. Ich weiß, es gibt irgendwelche Erfassungen. Und vor allem weiß ich aber, wenn ich das jetzt tue, dann wird das lange Zeit Bestand haben, was auch immer ich da gerade anrichte. Dann hat das natürlich psychologisch, ist es ein anderes Gefüge, als wenn ich weiß, wenn ich das jetzt tue, ist es sowieso sofort weg. Und ich kann quasi meine, den Schaden oder die Qual oder was auch immer ich da gerade anrichten möchte, nicht, Also, for lack of a better word, lange auskosten.

Tim Pritlove
0:24:05
Linus Neumann
0:24:06
Tim Pritlove
0:24:44
Linus Neumann
0:25:37

Ähnliche Aussagen trifft die Isar Schaller von der Initiative Ein Team gegen digitale Gewalt im Interview mit Netzpolitik.org. Die schildert jetzt, also die setzt sich spezifisch in Frauenhäusern mit dem Thema auseinander und da sind eben vor allem Bluetooth-Tracker oder gemeinsame Cloud-Konten mit Ortungsfunktionen, Kinderschutzfunktionen auf Geräten, etwas, was häufig in dem Kontext missbraucht wird. Ja, auch sind da sehr viele Kinder, wo dann die Täter Schul-Ipads, Smartwatches und ähnliche Dinge verwenden. Es gibt hier ein strukturelles Problem, was da dargestellt wird, dass häufiger mal der Partner, der Partnerin das Gerät einrichtet als umgekehrt, was eben auch hier das... Machtgefälle und die Möglichkeiten, derartiges zu tun, entsprechend verteilt und sagen, ja, auch hier fehlen die Ressourcen, ist ein erheblicher Mehraufwand in der Beratung, technische, pädagogische, rechtliche Kompetenzen sind da erforderlich und das überfordert halt viele. Es gibt, kann ich an der Stelle mal darauf hinweisen, von den Hexen, also dem virtuellen Flinta-Airfahrt im CCC. Virtuell, weil er eben nicht an einen Ort gebunden ist, sondern da versammeln sich eben die Hexen im CCC und tauschen sich aus. Sie haben eine ganz gute Online-Ressource geschaffen, antistalking.hexen.org, Hexen mit AE. Und ein bisschen über, ich sag mal, digitale Selbstverteidigung und so Inhalte, Schulungsmaterialien, Beratung und so weiter, Ressourcen zur Verfügung stellen. Aber die Forderung von Isa Schaller ist, und klar, die Hersteller müssen stärker in die Verantwortung genommen werden, bessere Warnsysteme gegen beispielsweise Bluetooth-Tracker. Wenn du jetzt irgendwelche Smart Home-Geräte und Location-Freigaben hast, dass das quasi das Gerät dir das sagt und einfach mehr... Den Nutzenden in die Hand gibt. Weil wenn Betroffene aus dem Digitalen gedrängt werden und sagen, ich traue mich jetzt nicht, mein Gerät zu verwenden oder so, das ist mitunter ja, also das kann man ja nicht erwarten. Also ist das okay. Ja, tut mir leid, du hast heute einen digitalen Stalker. Der kontrolliert alle deine Cloud-Konten und so. Und ja, musst du dich halt im Café treffen mit den Leuten und über die Telefonzelle vom Frauenhaus versuchen zu kommunizieren. Und das ist ja das, wohin dann Menschen flüchten, die von so etwas betroffen sind. Ja, also ich finde das sehr positiv, dass diese Stimmen jetzt eben auch in der Breite gehört werden, Plattformen geboten bekommen. Und hoffe, dass da auch etwas Positives dann bei rauskommt. Ja, wir haben auch darüber berichtet, dass ja die Chat-Kontrolle, also die freiwillige Chat-Kontrolle, die Erlaubnis, dass Anbieter Inhalte scannen dürfen, ausgelaufen ist. Und das ist auch irgendwie echt absurd. Sie haben es ja dann nicht akzeptiert. Abstimmung nochmal, ist auch wieder gescheitert. Also hört sich das jetzt auf. Und dann, diese Ausnahme gibt es dann nicht mehr. Und jetzt haben am 4. April Google, Meta, Microsoft und Snap so gesagt, ja, während ihr jetzt da eure unmittelbare Interim-Lösung diskutiert, werden wir weiter alles tun. Und zum Beispiel and we'll continue to take voluntary action on our relevant interpersonal communication services was bedeutet das was jetzt wieder verboten ist machen wir einfach weiter.

Tim Pritlove
0:30:31
Linus Neumann
0:30:32
Tim Pritlove
0:30:35
Linus Neumann
0:30:39
Tim Pritlove
0:31:28
Linus Neumann
0:31:40
Tim Pritlove
0:31:45
Linus Neumann
0:32:12
Tim Pritlove
0:32:58
Linus Neumann
0:33:05
Tim Pritlove
0:33:10
Linus Neumann
0:33:19
Tim Pritlove
0:34:24
Linus Neumann
0:34:32
Tim Pritlove
0:34:38
Linus Neumann
0:34:44
Tim Pritlove
0:35:11
Linus Neumann
0:35:16

Das ist, und unter diesem Namen wurde dieses Paper veröffentlicht und die unter dem Namen haben, also dieses Pseudonym wurde eben auch von, wurde auch in Online-Diskussionen und so im Weiteren auch verwendet. Also es gibt Äußerungen und Diskussionsbeiträge von Satoshi Nakamoto und seit jeher wildes Rätsel raten, wer denn diese Person ist, weil erstens das ja dann doch eine Erfindung von weitreichender Konsequenz war, technische Innovation für, die ja jetzt wirklich Milliarden Märkte eröffnet hat, geschaffen hat, bis hin zu Impfpässen, die man mit fünf Blockchains absichern muss. Also das ist so wirklich, das war eine weit, eine consequential Erfindung. Und unter anderem hat Satoshi Nakamoto eine relativ große Menge Bitcoins zu Beginn geschürft. Und das ist quasi der Anfang oder am Anfang der Bitcoin-Blockchain gibt es eben ein Wallet, was relativ viele Bitcoins hat und das ist offenbar das oder offensichtlich das von Satoshi Nakamoto und. Dieses Wallet hat bisher nie irgendwelche Funds bewegt oder so. Es hat aber einen relativ hohen Wert. Ich glaube, in dem Times-Artikel jetzt steht 118 Milliarden US-Dollar oder so. Also angenommen, wenn man das Geld ausgeben würde, würde es nicht sofort der Bitcoin. Aber das wäre jetzt der Face-Value ungefähr. Das heißt, es ist ein Mensch oder eine Gruppe mit relativ großen Ressourcen. Und das weckt natürlich allerhand Begehrlichkeiten. Ja, Gelüste, diese Person, ja ähnlich wie jetzt bei Banksy oder so, wird ja auch immer wieder, wir haben ja jetzt Banksy, meine Güte, lass den Arm, Mann doch mal in Ruhe, oder Frau, oder genau. Warum ist das bei uns erwähnenswert? Weil, also der Artikel ist wirklich enorm interessant, ist auch in den Show Notes verlinkt. Und der Autor schildert da seine Recherche und seine Indizien, wie er jetzt irgendwie auf den Adam Beck kommt. Und das hat er gemacht, auch unter Zuhilfenahme von AI. Und Satoshi Nakamoto ist auf jeden Fall, wer ein dezentrales, quasi anonymes Zahlungssystem erfindet, unter kluger, neuartiger Anwendung von Kryptografie oder neuer Kombination der Anwendungen von Kryptografie, Das ist jemand, der oder die oder eine Gruppe, die sich auf jeden Fall sehr mit ... Mit Anonymität, Privatsphäre und eben auch mit Finanzsystemen auseinandergesetzt hat und eine Expertise in diesem Fachbereich hat, die natürlich ziemlich gut sein muss und entsprechend hat sich Satoshi Nakamoto eben auch sehr gut, das wird auf jeden Fall jemand sein, der oder die weiß, wie man sich anonym halten kann. Und ja, was hat jetzt dieser Autor des New York Times Artikels gemacht? Also Cypherpunk-Mailing-Liste gelesen. Also das ist so die... Ja Tim, das kannst du besser erklären. Was sind die Cypherpunks?

Tim Pritlove
0:39:11
Linus Neumann
0:40:43
Tim Pritlove
0:40:48
Linus Neumann
0:40:52
Tim Pritlove
0:40:58
Linus Neumann
0:41:00
Tim Pritlove
0:41:07
Linus Neumann
0:41:08
Tim Pritlove
0:41:11
Linus Neumann
0:41:20

Genau, die 1992, ja, also die viel über, PGP-Diskussionen, so dieser ganze, dieser ganze Kontext. Cypherpunks Manifesto 1993. Privacy is necessary for an open society in the electronic age. We cannot expect governments, corporations or other large faceless organizations to grant us privacy. We must defend our own privacy if we expect to have any. We know that somebody has to write software to defend privacy and we're going to write it yeah this is a, Und ich denke, eine relativ einflussreiche Gruppe und auch Philosophie, die daraus entsprungen ist. So, jetzt gibt es also diesen New York Times Autor, der anfängt zu analysieren unter Zuhilfenahme von künstlicher Intelligenz und findet dann eben, also er hat eine Anfangshypothese, dass der Adam Beck diese Person sein könnte und recherchiert dann, was der so geäußert hat. Und jetzt skizziert die irgendwie Ende der 90er Jahre schon nahezu alle Kernkonzepte, die halt am Ende in Bitcoin zusammengeführt wurden. Dezentrales Cash, am Ende, dass es limitiert sein muss, Lösungen für das Double Spending, Problem, unveränderliche Zeitstempel, Hash-Trees. Ich will da jetzt gar nicht so in das, Detail gehen, was Bitcoin ausmacht. Das haben wir in einer anderen Sendung, glaube ich, relativ ausführlich erklärt. Und hat 1998. Vorgeschlagen, zwei andere Konzepte zu kombinieren, was dann eben Satoshi Nakamoto in dem Paper auch getan hat. Und er hat ähnliche Argumentationen wie Satoshi Nakamoto vorher schon vorgetragen. Jetzt haben die mit einer KI 34.000 Autoren analysiert, mit so einer Computational-Analyse über Stilmerkmale in der Kommunikation, also quasi nach bestimmten Auffälligkeiten in Satoshi Nakamoto's Art, sich auszudrücken, Orthographie und sonstigen in 34.000 Autorinnen auf Mailinglisten und so weiter. Am Ende blieb nur er über. 67 identische Bindestrich-Fehler, also dass bestimmte Dinge getrennt mit Bindestrich oder ohne geschrieben werden, das war halt eine besondere Auffälligkeit. Der Zweitplatzierte allein in der Analyse hat nur 38 Übereinstimmungen mit Satoshi Nakamoto. Spezialbegriffe, Partial, Pre-Image, Burning the Money, Proof of Work, die auch nur er und Satoshi Nakamoto so schreiben. Gleichermaßen Inkonsistenzen, E-Mail mal mit Binnenstrich mal ohne, Check mal mit Q mal mit CK und so weiter. Und dann aber auch Verhaltensauffälligkeiten, wie das auf einer Kryptografieliste, auf der sehr viel mit Satoshi Nakamoto diskutiert wurde. Da war er genau zu der Zeit, war er halt still. Und nachdem dann... Satoshis Coinstack publik gemacht wurde, war er dann auf einmal im Bitcoin-Talk und hat gesagt, ja, man sollte irgendwann mal aufhören, diesen Mann nachzustellen.

Tim Pritlove
0:45:23
Linus Neumann
0:45:26

Leave Satoshi alone, hat aber gleichzeitig, dann gab es irgendwie so Situationen, dass es dann irgendwann ernsthafte, Diskussionen, ich glaube um die Blockgrößen oder sowas gab, ja, in diesem ganzen Bitcoin-Universum, hat er dann vehement etwas verfochten und als es dann drohte zu kippen, meldete sich auf einmal Satoshi Nakamoto mit genau seiner Argumentation. Aber das Interessante an, also wenn man das jetzt so liest, ist es schon wirklich eine sehr auffällige Häufung von, Zufällen. Indizien, die vermutet werden oder Analysen, die durchgeführt werden, die dann genau diese Person zum Ergebnis haben und die auch, wenn man, so sag ich mal, methodisch dann schlüssig sind, wenn du mit 34.000 Leuten anfängst und du narrerst das runter auf genau eine Person, das klingt erstmal schlüssig, jetzt könnte es aber natürlich auch sein, dass es noch sehr viel weitere inhaltliche, orthografische Auffälligkeiten und Besonderheiten gibt und wenn du nach denen geprüft hättest, wärst du zu einem anderen Ergebnis gekommen oder so. Das muss man immer nochmal die Methode in. Ja, sagen wir mal, in Frage stellen und insbesondere, das ist halt vor allem eben mit AI durchgeführt worden. Und eine der, sagen wir mal, spannenden Lehren könnte sein, dass, wenn es stimmt, Adam Beck sagt, stimmt nicht, dass hier einer der auf jeden Fall erkennbar ausgewiesensten Privacy-Experten am Ende mit dieser Analyse und Zusammenhangs finde Technologie AI ja, wie soll man das sagen, die Klette gemacht hat.

Tim Pritlove
0:47:19
Linus Neumann
0:47:20
Tim Pritlove
0:48:07
Linus Neumann
0:48:10
Tim Pritlove
0:49:32
Linus Neumann
0:49:39
Tim Pritlove
0:49:54
Linus Neumann
0:49:57
Tim Pritlove
0:50:24
Linus Neumann
0:50:33
Tim Pritlove
0:50:48
Linus Neumann
0:50:56
Tim Pritlove
0:51:03
Linus Neumann
0:51:56
Tim Pritlove
0:52:14
Linus Neumann
0:52:31
Tim Pritlove
0:52:39
Linus Neumann
0:53:20
Tim Pritlove
0:53:20
Linus Neumann
0:53:38
Tim Pritlove
0:53:41
Linus Neumann
0:53:50
Tim Pritlove
0:53:59

Die drei würde ich sagen sind so in der Pole Position. Man kann da jetzt drüber diskutieren, ob da noch einer mit rein muss oder was jetzt alles die zweite Reihe ausmacht. Ist jetzt auch erstmal eigentlich egal. Wir haben Anthropic hier schon mehrfach erwähnt. Unter anderem, weil sie auch immer sehr schöne Erläuterungen bringen, wenn sie mal was Neues herausgefunden haben und auch diese Security-Abschätzungen machen etc. Naja, jetzt ist es auf jeden Fall wieder soweit und sie haben ein neues Modell angekündigt unter dem schönen Namen Mythos und auch hier handelt es sich um ein sogenanntes General Purpose Modell, also was quasi so für alles mögliche herangezogen werden kann. Aber sie meinen festgestellt zu haben, dass es extrem fähig ist im Bereich der Computer Security Aufgaben und in dem Zusammenhang haben sie dieses Modell auch mal dafür benutzt, um solche Fehler in kritischer Software zu finden, also in Software, die weltweit viel zur Anwendung kommt und meint dort einiges gefunden zu haben und kündigt halt an, dass das so earth shattering sei, dass sie also der Industrie jetzt quasi auch ein bisschen Vorlaufzeit gibt, auch eng da schon mit bestimmten Unternehmen zusammenarbeitet in einem Projekt namens Glaswing. Und das Ziel dieser Veröffentlichung jetzt ist auch hier zu sagen, Leute, unsere Modelle werden jetzt super intelligent, es muss etwas geschehen und zwar müsst ihr die Art und Weise, wie ihr mit Sicherheit umgeht, ändern, weil sonst seid ihr zukünftig potenziellen Angreifern ausgeliefert. Das Ganze sei also ein Wendepunkt im Punkto Security.

Linus Neumann
0:55:58
Tim Pritlove
0:56:38

Genau, also sie werden es irgendwann veröffentlichen, nur haben sie es jetzt zu diesem Zeitpunkt noch nicht veröffentlicht, sondern reden jetzt erstmal darüber und stellen auch so ein bisschen vor, was sie jetzt getan haben und meinen, dass sie also eine Menge Sicherheitslücken gefunden haben, von denen 99 Prozent, von denen die sie gefunden haben und dokumentiert haben, derzeit einfach noch nicht gefixt sind. Ein Prozent sei aber schon gefixt und darüber können Sie auch reden und das tun Sie dann auch sehr ausführlich und Sie meinen halt, Sie hätten sogenannte Zero-Day-Lücken, also bisher unbekannte Sicherheitslücken in allen wichtigen Betriebssystemen gefunden und in jedem relevanten Webbrowser, der derzeit im Einsatz ist. Also sprich in Chrome, in Safari und so weiter, wie sie alle heißen. Viele dieser Fehler, die sie gefunden haben, existieren teilweise seit 10 oder 20 Jahren, in einem Fall sogar seit 27 Jahren in einem Betriebssystem. Das haben sie auch benannt, nämlich OpenBSD. Was lustig ist, weil ja OpenBSD immer so, also sozusagen ja das Betriebssystem ist, was immer so Security sich auf die Fahnen geschrieben hat, ja, zu Recht auch, ja, da kam ja auch SSH und solche Entwicklungen, das kommt halt alles von da, ne. Genau. Und das Interessante ist, dass also dieses Mythos-Modell jetzt nicht einfach nur so alles auf alles draufhaut und dann irgendwelche Fehler dabei gefunden hat, wie man das ja so generell auch aus der Security kennt, sondern also richtig Verkettung von Fehlern, Ausnutzung da zusammengebaut hat und gezielte Strategien entwickelt hat, um also diesen Lücken da auf die Spuren zu kommen. Genau, also das geht dann also richtig weit. Sie finden da nicht nur Sicherheitslücken, sondern sie bauen dann auch gleich richtige Exploits, um das also auch gleich auszunutzen. Und das Besondere an diesem Mythos-Modell ist, dass das eben jetzt so eine neue Funktionalität ist, die sie entdeckt haben in dem Modell, was zum Beispiel in dem zuletzt und vor allem auch erst vor kurzem veröffentlichten Opus 4.6 Modell so bestenfalls ansatzweise nur drin war. Also eine ähnliche Funktionalität haben sie so nur in 1% der Fälle gefunden und bei dem Mythos-Modell irgendwie in 72% der Fälle. Ja genau und das heißt es handelt sich hier um eine emergente Fähigkeit. Also sie haben jetzt dieses Modell nicht speziell daraufhin trainiert, sondern sie haben einfach nur die nächste Variante ihres Modells entwickelt und festgestellt so, oh holla das ist jetzt so intelligent, das kann jetzt auch das machen. Und das hat halt große Implikationen. Deswegen haben sie jetzt dieses Projekt gestartet, um Unternehmen jetzt auch Vorlaufzeit zu geben, da was zu machen. Und zwar nicht nur, um jetzt gezielt einzelne Lücken zu finden, sondern um vielleicht auch generell ihre Strategie umzustellen.

Linus Neumann
0:59:43

Also wir müssen, glaube ich, zur Bewertung noch ein bisschen mehr dazu sagen, was war wirklich das Setup, was die hier gemacht haben. Und zwar haben wir das Ding halt Code lesen lassen. Ja, das ist schon nochmal ein sehr entscheidender Aspekt. Du hast ja gerade gesagt, wie das sonst in der Security üblich ist, einfach überall drauf zu kloppen. Ja, wir rüben uns ja auch teilweise des planvollen Handelns, aber hier ist eine spezifische Form der Security-Analyse zur Anwendung gekommen und das ist im Prinzip das Lesen von Quellcode. Keine, und nochmal, wenn du in OpenBSD, und zwar in der TCP Implementierung von OpenBSD, also das TCP aus TCP IP, das Transmission Control Protocol. Wo das im Prinzip für so Sachen auch da ist, dass du quasi die Sequenznummern von Paketen zählst und Bescheid sagst, hier hat eins gefehlt. Und da gab es dann einen Update am TCP. Du kriegst zehn sequenzielle TCP-Pakete und das fünfte wurde unterwegs verschluckt. Wenn du jetzt dann in der ursprünglichen Variante von TCP hättest du gesagt, ich brauche nochmal alles ab 5 Uhr. Weil du eben nur sagen konntest, das habe ich nicht bekommen. Und dann gab es ein Update von TCP, wo man gesagt hat, wir führen jetzt ein, das selektive Act oder nicht Act, dass du sagst, übrigens mir hat die 5 gefehlt. Und dann kriegst du nur die 5 nochmal und nicht alles ab der 5 nochmal. Dass also die Effizienz von TCP sehr stark optimiert hat. Und in dieser Implementierung haben die Leute bei OpenBSD vor 27 Jahren einen Fehler gemacht.

Tim Pritlove
1:01:46
Linus Neumann
1:01:48

Und Keiner hat es gemerkt, ja. Lange gut gegangen. Und das ist der andere Aspekt, der sich jetzt hier bei dieser Forschung zeigt. Sie haben einen Fehler in der Speicherverwaltung gemacht. Ich will das, ich sage es schon vorher, ich erkläre das jetzt sehr, sehr, sehr high level, weil das sonst einfach zu kompliziert wird. In Programmiersprachen wird Speicher verwaltet. Computer hat Arbeitsspeicher. Und wenn er sagt, ich speichere, ich muss mir jetzt etwas merken, dann muss das Programm ja selber zum Beispiel wissen, wo es sich was gemerkt hat. Oder auch wie viel Speicher es reserviert, um da etwas reinzuschreiben. Und sehr klassische Fehler in Programmiersprachen, insbesondere wie C, entstehen dadurch, dass du entweder... Oder dass du Fehler in der Speicherverwaltung machst, beispielsweise zu wenig Speicher reservierst und dann darüber hinweg schreibst, was eben in dieser Sprache möglich ist. Du sagst, ich bräuchte mal bitte, reserviere mir mal bitte Platz für 10 Byte und dann schreibst du aber 11 hin. Dann schreibst du das 11. Byte in irgendeinen anderen Speicherbereich, den du potenziell an anderer Stelle ausliest. Ja, weil du an dem Punkt eigentlich etwas anderes erwartest. Also Fehler dabei oder du sagst, ich brauche diesen Speicher nicht mehr, ich brauche das nicht mehr, ich überschreibe das jetzt, ich gebe das jetzt frei, da kann das Programm jetzt andere Dinge hinschreiben und dann liest du aber nochmal an der Stelle. Weil du sagst, quasi der Programmfluss dich in seiner Komplexität überfordert hat, sodass du irgendwann etwas liest, obwohl das Programm das quasi schon wieder gesagt hat, diesen Speicherding, da dürfen jetzt andere hinschreiben. Und dadurch so etwas passieren dann so Sachen wie Hardbleed, war auch so ein klassischer Speicherverwaltungsfehler, wo du Sachen gelesen hast oder ausgeben konntest, die halt schon wieder freigegeben, also quasi free waren und so weiter und so fort. Und diese spezifische Art von Fehler ist leicht zu machen und teilweise auch leicht zu finden. Es sei denn, die Bedingungen und die Verästelung im Code, um an diese Stelle zu kommen, dass du dort diesen Speicher, dass der sich nicht so verhält, wie du als programmierende Person unter allen Bedingungen, in denen sich das Betriebszustände, in denen sich das Programm befinden kann, ausgegangen bist. Und dass du immer denkst, okay, es kann nur so groß sein, ich reserviere jetzt hier so viel Sprecher. Diese Art von Fehler zu finden und zu vermeiden, ist eine sehr häufige Tätigkeit des Code Audits, wo also jemand oder ein Programm oder ein Mensch den Code liest und guckt, ob alle Annahmen, die zu einem gewissen Zeitpunkt über den Speicherzustand, seine Reservierungen, seine Größen usw. Getroffen wurden, auch zu jedem Zeitpunkt noch gelten. Und diese spezifische Fähigkeit haben Sie jetzt hier geprüft mit eben sehr beeindruckenden Ergebnissen. Und was ich glaube, was an den Ergebnissen beeindruckend ist, ist A, wenn 27 Jahre lang diesen Fehler in der Speicherverwaltung niemand gefunden hat. Heißt das nicht, dass 27 Jahre lang Menschen danach gesucht haben, aber es heißt auf jeden Fall, dass er nicht besonders trivial zu finden war. Weil wenn er trivial zu finden gewesen wäre, hätte ihn zwischendurch irgendwann mal jemand gefunden. Ähnlich ist es mit diesen ganzen Browser-Geschichten. Browser sind inzwischen so unglaublich komplexe.

Tim Pritlove
1:06:32
Linus Neumann
1:06:34

Ja, eigentlich Betriebssysteme. Die haben so viele Funktionen, Sprachen, die sie interpretieren müssen, dass es jetzt nicht überraschend ist, dass du dort derartige Fehler findest. Nur, dass sie dann auch noch ausnutzen kannst. Was du sehr häufig. Oder was du recht einfach findest, ist, dass du sagst, pass mal auf, hier wird, Speicher schlecht verwaltet. Oder hier wird unvorsichtig irgendwo hingeschrieben und nicht sauber sichergestellt, dass man genug Speicher reserviert hat. Wenn du eine solche Stelle im Code findest, heißt das noch lange nicht, dass du auch einen Pfad unter Realwertbedingungen durch den Code findest, um an einen Zustand zu kommen, dass du mit deinem Wert, der da nicht hingehört, an diese Stelle kommst, dass du hier tatsächlich eine Speicherverletzung begehen kannst. Das ist dieser andere Teil, den du gerade nanntest, das ist das Ding nämlich im Vergleich zu Opus, Opus hat in 1% der Fälle gesagt, hier pass auf, so kannst du, das musst du mit dem Programm machen, damit du diesen Fehler in der Speicherverwaltung auch tatsächlich ausnutzen kannst. Ja, hier sind die 180 Bedingungen und Edge-Cases und so weiter, damit du hier, da und noch dazu erfolgreich das Programm dann in seiner Integrität manipulierst, ja. Das ist die andere Kunst, die ist, ähm... Also wenn du erstmal die Schwachstelle hast, ist es natürlich ungleich einfacher, dich dahin zu hangeln, insbesondere für ein LLM, aber es zeugt eben bei, wenn die Schwachstelle oder dieser Fehler in der Speicherverwaltung so komplex ist, dass er niemandem erstmal aufgefallen ist, dann ist im Zweifelsfall auch der Weg, ihn zu triggern, sehr kompliziert und erfordert ein sehr hohes Verständnis des Codes. Da kommt das, was du gerade meintest. In der Security gehst du dann gerne hin und klopfst einfach drauf. Wir nennen es Fuzzing. Dass du nämlich Teile des Codes nimmst. Und den ganzen Code oder Teile des Codes mit invalidem Input bombardierst, einfach nur zu gucken, ob es irgendwann crasht. Ob es irgendwann in einen Zustand kommt, den du nicht haben willst. Oder der nicht definiert ist oder nicht wünschenswert wäre. Eine sehr hohe Kunst, weil. Nur drauf zu kloppen eben nicht ausreicht, wenn du den Code verstehst als einen verästelten Pfad von Möglichkeiten, und du willst alle Pfade dieser Möglichkeiten, alle Verzweigungen irgendwie abdecken, dann schaffst du das nicht, wenn du einfach nur Zufall drauf wirst, weil es ja zum Beispiel sein könnte, dass die am Anfang eine 50-Prozent-Wahrscheinlichkeit 1-0 oder so ist, die aber eine Komplexität oder eine Entropie von 1 MB hat oder so und dass du die Hälfte deines Inputs scheitert schon an der ersten Schranke. Das heißt, du musst sehr gezielt bei dem Fuzzing dir auch darüber Gedanken machen, dass du möglichst viel von deinem Input auch wirklich dazu führt, dass es unterschiedliche Pfade des Codes ergründet. Insofern würden insbesondere meine Kollegen, die sich mit Fuzzing auseinandersetzen, vehement widersprechen, dass es einfach nur draufkloppen ist.

Tim Pritlove
1:10:35
Linus Neumann
1:10:39

Aber selbst damit wurden offen, und ich bin mir sehr sicher, dass der TCP-Stack aus OpenBSD durchaus auch mal durch den Fasser gescheucht wurde, weil TCP eignet sich auch ganz gut zum Fassen. Auch damit wurde es in 27 Jahren nicht gefunden. Und das Beeindruckende ist also jetzt hier, dass es. Diese Sachen findet. Allerdings ist es jetzt auch nicht so, dass du sagst, hey, yo, Claude, hier ist mal übrigens dein, hier ist mal so ein Repo, findet man eben die Criticals, ja? Vor allem die, die 27 Jahre alt sind. Nein, sondern die brauchten, und das finde ich hier sehr spannend, vom Setup haben sie immer und immer wieder das Modell hochgezogen und immer und immer wieder die Aufgabe gegeben und haben quasi gleiche Aufgabe hunderte bis tausende Male gestellt. Hunderte Male auf jeden Fall. Mit natürlich auch immer unterschiedlichen Ergebnissen. Und dann kamen eben teilweise ... Solche Critical Spy raus. Das finde ich zum Beispiel auch spannend zu ergründen, woran das liegt und warum sie das mehrmals machen mussten, weil eben dieser Raum, der durch den Quellcode abgedeckt wird, also der Möglichkeitenraum, wie man sich in diesen Wirrungen, dieser logischen Bedingungen, die hintereinander geknüpft werden und unabhängig voneinander sind, wie man sich dadurch bewegen kann, der wird sehr schnell einfach enorm groß und der Speicherbedarf, der Arbeitsspeicherbedarf, um das zu repräsentieren für so ein Modell, wird auch sehr schnell sehr hoch. Das heißt, wenn du große Mengen Code analysieren willst, musst du den im Prinzip abstrahieren und quasi über die Menge der Funktionen und was dieser Code tut. Quasi Abkürzungen und Vereinfachungen bilden, um dann Hypothesen zu haben, wo Fehler passieren können und dann diese spezifischen Sachen dir noch einmal genauer anschauen. Das ist so ein Abstraktionsproblem, weil du nicht den gesamten Code in seinem kompletten Kontext einfach in dieses Modell packen kannst. Deswegen also dieses hier, sie haben es mehrmals gemacht und haben im Prinzip so eine probabilistische Wahrscheinlichkeit, dass das Ding, dass das Modell A einen Fehler findet und genauso eine probabilistische Angabe mit wie großer Wahrscheinlichkeit es dem Ding sofort gelingt oder überhaupt gelingt. Einen funktionierenden Exploit dafür zu machen. Im Vergleich Opus 4.6 kriegt das zuverlässig in weniger als 1% hin und hier hast du eins, was es in 72% der Fälle hinkriegt. Diesen zweiten Teil quasi Exploits zu bekannten Schwachstellen zu schreiben, den finde ich gewissermaßen ungleich beunruhigender. Weil wenn du jetzt überlegst, was bedeutet diese Entwicklung? Okay, Angreifer können ausreichend Tokens vorausgesetzt, jetzt in Quellcode, den sie haben, laut diesem Beispiel, das wird ja für andere Anwendungen eine ähnliche Entwicklung sich dann zeigen, aber bei Quellcode ist es jetzt noch relativ naheliegend. Angreifer können also jetzt sagen, alles klar, wir nehmen jetzt hier so einen Cloud-Mythos und eine Kreditkarte und geben ein paar tausend Euro aus und gucken mal, ob wir ein Critical in der und der Software-Library finden. So, gut. Was bedeutet das für Angriff und Verteidigung? Okay, wer ein bisschen Geld ausgibt, kann ein sehr mächtiges Code-Auditing-Tool zur Anwendung bringen. Das heißt aber, das können auch Verteidiger. Und am Ende haben Verteidiger wahrscheinlich in Summe mehr Geld, was sie dafür ausgeben, Code zu auditieren, als Angreifer. Es gibt einfach mehr Menschen, Firmen, Organisationen und Ressourcen, die an der Sicherheit von Code interessiert sind, als es Kapital gibt, das an der spezifischen Unsicherheit von Code interessiert ist. Also ich als Angreifer, was weiß ich, wenn ich eine Million habe, und ich will einen Critical irgendwo finden, dann hat meine Konkurrenz, zehn oder hunderte Millionen an jeder Stelle potenziell investiert, wo ich suche. Das heißt, da würde ich dann am Ende doch einen strukturellen Nachteil für Angreifer sehen. Immer long term. Aber wenn eine Schwachstelle gefunden wurde, Wie auch immer, sei es durch eine KI, sei es durch eine Sicherheitsforscherin, die sie gemeldet hat, dann gibt es ja einen Patch. Und eines der Risiken des Patching ist, wenn du den Patch bereitstellst, dann musst du natürlich auch inhärent, klärst du darüber auf, dass es eine Sicherheitslücke gab, die durch diesen Patch nun behoben ist. Das heißt, du verrätst implizit auf jeden Fall, wo die Sicherheitslücke war und worin sie bestand. Und das führt schon seit langem dazu, dass bei den besonders kritischen Schwachstellen, die irgendwo mitgeteilt werden, unmittelbar Leute sich hinsetzen und sagen, okay, ich will sofort wissen, wie die Schwachstelle funktioniert und ich bastle dazu jetzt einen Exploit. Und genau das war früher vielleicht eine Arbeit von Tagen, wenn es ein komplexer Exploit war, Wochen und wird jetzt halt eine automatisierbare Tätigkeit. Und dafür brauchst du dann auch nicht mehr zehntausende Dollar, sondern wahrscheinlich nur noch hunderte. Je nachdem, wie viel Wissen du bereits über die Schwachstelle hast oder wenn es jetzt im Open-Source-Tool ist und den Quellcode eh sehen kannst, dann sparst du sehr viel Zeit und Geld, einen funktionierenden Exploit zu bekommen. Fassen wir zusammen, die Fähigkeit, diese Schwachstellen zu finden, wird am Ende langzeitlich eher den Verteidigeren helfen. Die Fähigkeit, Exploits zu bauen, die wird sehr kurzfristig und unmittelbar Angreifern helfen. Und hier kommt jetzt die Realität zum Tragen, dass in größeren Organisationen, sag ich mal, das Einspielen von Sicherheitsupdates, das ist eine Abteilung, das ist ein Prozess, damit werden Familien ernährt. Ja, dass ganz viele Menschen sich darüber Gedanken machen, wann man jetzt das Update einspielt, welchen Patch-Gap man sich erlauben kann und so weiter und so fort, ja. Und wir patchen aber, ah, was haben wir denn diesmal? Es ist ja Patch-Tuesday. Was schreibt Microsoft diesmal? Ja, okay, alles klar, können wir erstmal so stehen lassen, ist jetzt nichts unmittelbar Wildes dabei. Da warten wir mal noch bis zum Wochenende und lassen das Werk jetzt hier weiter, produzieren oder arbeiten oder sonst was. Sodass du. Im Prinzip mit den ganzen Patches und so weiter aktuell in jeder größeren Organisation im Prinzip Triage betreibst. Machen wir das über den normalen Patch-Zyklus einmal im Monat? Oder ist hier jetzt etwas gekommen, was so dramatisch ist, dass wir von unseren normalen Abläufen abweichen und vielleicht tatsächlich mal was patchen? Kleiner, sarkastischer Kommentar. Auf jeden Fall schiebt jede ausreichend komplexe Infrastruktur und da könnt ihr einfach nur euer Heimnetz anschauen, eine nicht zu verachtende Menge an Patchgap vor sich her. Und das ist das, was sie jetzt eben sagen, also wenn wir das jetzt in die Hand der Öffentlichkeit geben, Dann wird jede Sicherheit, wenn erstens sehr viele gefunden werden und zweitens sehr schnell Exploits dafür da sein und dafür ist einfach die Art, wie IT heutzutage betrieben wird, in keiner Weise vorbereitet.

Tim Pritlove
1:19:34
Linus Neumann
1:20:29
Tim Pritlove
1:21:09
Linus Neumann
1:21:18

Er hat keinen Bock mehr, dass da die ganze Zeit irgendwelche AI-Bucks eben gefeilt werden. Bin ich jetzt mal gespannt, wie lange das noch hält. Also da kommt auf jeden Fall jetzt richtig was auf uns zu. und, es also die, ich vermute dass, mittelfristig halt die Lösung sein wird so, okay, pass auf, finde den Bug und statt einen Exploit zu bauen, sei doch so lieb und entwickle mal den Fix kannst du ja auch machen machst du mal Pull-Request, dann ist es trotzdem natürlich für die Maintenance von Open Source Software, eine Herausforderung da aufzupassen, was da alles gefeilt und gefixt und so weiter wird, dann musst du irgendwie vielleicht sehr, sehr viel mehr Testing haben, um sicherzustellen, dass dir da nicht irgendwas kaputt gemacht wird mit derartigen Patches, dass eine Funktionalität auf einmal abgesägt wird oder so, das Risiko halte ich übrigens für nicht so gering weil, genauso wie es kompliziert ist, den Pfad zu finden um es zu exploiten, kann es auch kompliziert sein. Quasi den Auslöser, den Teil, den du wirklich fixen musst, zu finden und nicht ungünstigerweise einen Teil des Codes auf einmal kaputt zu machen, den du gerade nicht in deinem Kontext hast, ja. Ja, also werden sicherlich auch Fehlfixes kommen. So, und dann bleibt aber das Problem, wie finden die jetzt ihren Weg in die Breite und zwar zügig. Das heißt, wir müssen im Prinzip in unseren Infrastrukturen das Patch-Problem lösen. Ja, wo dann so Konzepte wie selbstheilender Code eine Rolle spielen. Natürlich auch es gibt quasi diese Containerisierung und sowas kann da natürlich sehr viel helfen kann wichtiger, ein wichtiges Mittel auf dem Weg zu schneller heilenden. Infrastrukturen Systemen weniger komplex und so weiter sein also ich meine, Finde ich selber sehr schön, dass ich inzwischen den größeren Teil von dem, was ich irgendwie an Verantwortung nicht loswerde, kontainerisiert habe und das macht wirklich solche Prozesse wirklich angenehmer und schöner. Aber das kann jetzt halt auch kurzfristig dazu führen, dass du gar nicht mehr aus dem Container-Updaten herauskommst. Und da sind halt wirklich riesige IT-Infrastrukturen, die betrieben werden in der Industrie, in der Produktion, im Steuerbüro, sind einfach in keiner Form darauf ausgelegt, sagen wir mal, dass man jetzt eine Schwachstelle nur noch 24 Stunden tolerieren kann, statt, 27 Jahre. Und da kommt schon echt, also da wird die Art wie IT, betrieben wird, die Art, wie Code geschrieben wird, da werden sich wirklich Paradigmen fundamental ändern.

Tim Pritlove
1:25:16
Linus Neumann
1:26:30

Also ich finde es kein angenehmer Gedanke, aber es ist auf jeden Fall so. Und das liegt auch daran, dass wir darüber, wie Quellcode geschrieben wird und verwaltet wird, natürlich unglaublich gute Lernmaterialien für Modelle geschaffen haben. Also, Quellcode wird versionsverwaltet, commits in Git-Repositories, in Subversion, you name it. Da wird die ganze Zeit gesagt, folgendes wird am Code geändert, damit folgendes Problem gelöst wird, beziehungsweise folgendes Code zur Funktionalität hinzukommt oder folgender Bug gefixt wird. Und wenn man jetzt große Open-Source-Projekte nimmt, die funktionieren ja nur deshalb, weil die Menschen, die Code zu diesen Repositories beitragen, teilweise hunderte Menschen gleichzeitig an unterschiedlichen Stellen an einem Tag beitragen. Weil die in einer strukturierten Art und Weise das tun, kommentieren und erklären, was sie da machen. Also nur so funktioniert ja ein Open-Source-Projekt, wenn es für andere Menschen lesbar verständlich ist, sie die Änderungen erkennen, nachvollziehen können, sagen, ah, alles klar, pass mal auf, hier an der Stelle in dem Code, da möchte ich eine Verschlimmbesserung jetzt hier anbringen und ich erläutere die in meinem Commit- und meinem Pull-Request. Und der Code selber ist auch noch kommentiert. Und wenn du darauf Modelle trainierst und dann durch die Historie von Code durchgehen lässt, dann sehen sie ja dem Code beim Reifen und Verrotten zu und erkennen ja auch so, ah, jetzt ist der Moment, jetzt ist das Ding über den Hai gesprungen, jetzt muss man eigentlich was Besseres machen, jetzt fängt man lieber wieder von vorne. Ach, guck mal, hier haben sie auch gemacht. Und da finde ich es jetzt zum Beispiel noch nicht so wahnsinnig irre, dass es auf dem Weg der Lektüre von einem Vierteljahrhundert Open Source Code oder mehr ist es ja, irgendwann verstanden hat, was Memory. Corruption und Memory Management Fehler sind in diesen antiken Sprachen, die dir diese Fußpistole zu jedem Zeitpunkt in die Hand geben. Muss man ja auch sagen, diese Art von Klasse, diese spezifische Art von Fehler ist eine, die. Deren Abschaffung schon lange gefordert wird und das wäre halt, indem man modernere Programmiersprachen verwendet, die, Es quasi sehr schwer machen, solche Fehler zu machen, statt es sehr leicht machen, solche Fehler zu machen.

Tim Pritlove
1:29:41
Linus Neumann
1:29:47
Tim Pritlove
1:29:55

Ich meine damit auch nicht Rust. Aber das würde mich auch fast schon nicht wundern. Weil du es gerade angesprochen hast, Du hast zwar jetzt einen anderen Aspekt dabei abgedeckt, aber fand ich auch nochmal ganz interessant, weil sie ja da auch in diesem Text, also Anthropik da in dem Text drauf auch hingewiesen hat, diese Fähigkeit Zero-Day-Exploits, also bisher vollständig unbekannte Sicherheitslücken zu finden, die sich ja hier in diesem Mythos-Modell gezeigt hat, sagen sie, weist halt auch darauf hin, Das Modell hat nicht solche Fehler aus bestehendem Code direkt gelernt. Es ist nicht etwas, das irgendwo in einem anderen Code schon war und dadurch gefunden wurde, sondern diese Modelle entwickeln durch dieses moderne Training, was ihnen zugeführt wird, in zunehmendem Maße einfach so eine emergente Fähigkeit. Und ich finde das. Absolut, wie sagt man so schön, awe-inspiring. Also es ist wirklich irre, wie dieser Zweig der Software oder der Informatik, der man eigentlich als Linguistik begonnen hat, jetzt in den letzten Jahren von, oh es fängt an langsam zu funktionieren zu, es entwickelt Fähigkeiten, die keiner auch nur vorhergesehen hat. So einen Weg genommen hat und irgendwie crazy. Da müssen wir uns, glaube ich, ein bisschen auch mit abfinden, dass das jetzt auch wirklich stattfindet, weil ja oft auch gezweifelt wird, zu Recht auch, an Fähigkeiten von KI, weil man muss schon unterscheiden zwischen was wird da informatisch eigentlich gerade wirklich getan und wie wird es dann zur Anwendung gebracht von uns minderen Wesen mit einfacher, Humanintelligenz.

Linus Neumann
1:32:05
Tim Pritlove
1:32:10
Linus Neumann
1:32:12
Tim Pritlove
1:32:15
Linus Neumann
1:32:18

Das finden die nie. Ja, ja, ja, ja. Aber. Ich möchte es nur noch mal in den Kontext begeben, dass es jetzt nicht so ist, dass das eine, Also, dass diese Ergebnisse jetzt irgendwie mit wenig Rechenaufwand oder so gefunden wurden. Es handelt sich schon eben um eine Menge von Durchläufen und man könnte auf eine Weise sagen, da hat jemand einfach nur drauf gekloppt und halt oft genug. Und sie schreiben, ich glaube, bei dem einen Beispiel sagen sie halt auch so, naja, der einzelne Lauf, der einzelne Code-Audit hat ein Fofi gekostet, der zum Ergebnis geführt hat, aber wir mussten halt relativ viele davon machen, sodass das Gesamtinvest, dieses Ergebnis zu bekommen, halt 20.000 war. Nochmal, bei einem richtigen Auditor hast du, also es wurde offen, es wurde wahrscheinlich mehr Geld für Audits bis zu diesem Zeitpunkt durch Menschen ausgegeben und die haben das eben nicht gefunden. Und da ist dann 20.000 Euro für, find mal bitte ein Critical in Open BSD, ist halt unglaublich wenig. Es ist nur nochmal 20.000 Euro davon entfernt, dass du das findest. Das heißt, das wird dir dann erst irgendwie im November vergönnt sein, lieber Tim. Ja, also da sind wirklich ähm, Ja, also beeindruckende Entwicklungen, deren Konsequenzen auf jeden Fall in Frage stellen oder in eine komplett andere Realität hieven, wie IT betrieben wird. Es gibt da eine vor einiger, ich weiß nicht, ob ich das hier erwähnt hatte, vor, weiß nicht, vor einem Monat oder zwei, die Seite Zero Day Clock, wo so ein bisschen mal das Ganze, die Entwicklung so ein bisschen dargestellt wird, so, welche Zeit vergeht eigentlich, also die Time to Exploit, also die Zeit, die vergeht zwischen, es gibt eine Schwachstelle, die mitgeteilt wird und, dass sie ausgenutzt wird, wird bestätigt. Das ist natürlich bei einem Zero-Day, also einer Schwachstelle, die der Öffentlichkeit nicht bekannt war und durch ihre Ausnutzung der Öffentlichkeit überhaupt bekannt wird, da ist das dann eben Null oder kleiner Null. Und bei dem größeren Teil der Schwachstellen halt so im Bereich von Tagen und jetzt wandert es halt von Tagen in Richtung Stunden und wenn man die Kurve so weitermalt, dann ist es halt irgendwann in ein, zwei Jahren so bei einer Minute. Und gleichermaßen nimmt der Anteil an Schwachstellen zu, die zum Zeitpunkt ihres Bekanntwerdens eben schon ausgenutzt wurden, also die durchaus nur zum Bekanntwerden. Das ist ja quasi der schlechteste Fall. Deren Anteil nimmt zu. Es gibt relativ viele Schwachstellen, die man jetzt nicht unbedingt in the wild exploited sieht. Vor allem, also primär einfach, weil es keinen interessiert oder weil sie nicht massenhaft genug sind. Da gibt es relativ schöne Kurven, wo, sagen wir mal, nach bestem Wissen und Gehwissen Daten zusammengefasst wurden. Und dann extrapoliert werden. Da ist natürlich auch relativ viel... Also Extrapolation und Annahme mit dabei, aber kann schon eben erwarten, dass jetzt das industrialisiert wird, Schwachstellen zu finden und Exploits zu machen.

Tim Pritlove
1:36:33
Linus Neumann
1:36:52

So, dann gibt es jetzt in diesen, also dieses Zero-Day-Clock zeigt eben nur mal ein bisschen Daten, dann gibt es einen Call-to-Action, der also sagt, was folgt denn daraus? Erstens, hold the makers accountable, also wer den Code geschrieben hat, muss eben jetzt die Möglichkeiten zur Anwendung bringen, dass er erstens möglichst wenige Schwachstellen shippt, aber natürlich auch, das Tooling bereitstellt, um sie schnell zu beheben. Das ist das, was ich anfangs meinte, mit langfristig werden hoffentlich die Verteidiger die Nase vorn behalten in der Anwendung von AI, Augmented Code Audit, weil es einfach auf der Seite mehr Interessen gibt, aber das ist eben auch eine Aufgabe, der Softwareindustrie, dass sie eben nicht sagt, wir schicken die ganze Zeit irgendwelchen Murks und ach guck mal hier, da hat jemand eine Schwachstelle gefunden, mach mal jemand am Freitag, nee mach mal am Montag irgendwie ein Patch oder so, schreib mal eine E-Mail, ach scheiße, da kommen schon die Bullen, ja. Dann build Security into the Platform. Also. Die immer mehr Security-Kontrollen in Frameworks, in der Infrastruktur generell zu haben, damit du in den höher abstrahierten Applikationen nicht mehr so folgenschwere Fehler machen kannst. Ja, dann Forderung 3, hört mal auf zu patchen, fangt mal an, Sachen neu zu bauen. Ja, weil ich glaube wirklich, dass wir, dass diese Idee langlebige nicht, weißt du, ich behandle das öfter in Vorträgen, das ist das so, die deutsche Mentalität geht immer irgendwie so ein bisschen davon aus, dass etwas irgendwann fertig ist. Aber Software wird nicht fertig das heißt du also ich bin mir noch nicht mal sicher, ob jemand bis heute wirklich geschafft hat ein ausgereiftes, sicheres, wohlformuliertes Hello World zu schreiben. Also ob man da wirklich sagen könnte, das ist jetzt mein Hello World und das ist jetzt fertig.

Tim Pritlove
1:39:45
Linus Neumann
1:39:45
Tim Pritlove
1:40:56
Linus Neumann
1:42:41
Tim Pritlove
1:42:49
Linus Neumann
1:42:55
Tim Pritlove
1:42:58
Linus Neumann
1:43:02

Dann haben wir die Forderung. Was schon ein bisschen absurd ist, ist, dass Verteidigung immer so, das musst du extra kaufen, das Wissen wird nicht so geteilt. Wäre eigentlich schon sinnvoll, weil der eine Vorsprung, den die Verteidigung hat, ist die Kenntnis, der Wissensvorsprung, gegenüber dem Angreifer über die eigene Infrastruktur, das interne Netz, wo man hin will oder sonst was. Das heißt, da gibt es eigentlich relativ viel Wissen. Wenn man das klüger teilen würde, könnte man da mehr draus machen. Ja. Wenn wir das tun, dann kann durch AI, und das wäre schon meine These langfristig, Verteidigung den Vorsprung haben. Threat Intelligence, Teilen, zur Anwendung bringen. Anomalien feststellen kannst du vor allem, wenn du weißt, was normal ist, und das weißt du von deiner eigenen Infrastruktur und deinem eigenen Netz, schneller reagieren zu können, ohne menschliche Fehler oder menschliche Analysen. Da gibt es viele Möglichkeiten, mit AI zu arbeiten. Das müsste man sich halt überlegen, wie man das auch regulatorisch abdecken möchte. oder wann der Moment ist, so etwas zu erlauben. Und naja, dann gibt es noch so ein bisschen, fragt mal lieber die Hacker in eurer Politik, was jetzt sinnvoll ist. Das sage ich auch schon länger als Sprecher des CCC. Zero Trust Prinzipien zur Anwendung bringen. Also Zero Trust ein Paradigma, wo du im Prinzip an keiner Stelle implizit vertraust, sondern alles immer durchverifizierst, ob dieser Schritt, den du gerade machen darfst, der Zugang, den du gerade gewährst, wirklich legitimiert ist. Und dass nicht irgendwie dieses Vertrauen transitiv ist, somit auch, der ist ja hier im Internet, dann darf der ja wohl alles verschlüsseln. Also sehr auch wirklich, ich versuche diese Konzepte so zu erklären, dass sie hier für viele tausend Leute verständlich sind. Die Idee zu sagen, naja, okay, was an Angriffen passiert und welche technischen Schwachstellen oder Fixes notwendig sind, das ist halt nicht ein individuelles Problem, sondern eben auch ein Ökosystem oder ein Staaten- oder ein geopolitisches Problem. Ja. Für das du potenziell eben auch geopolitische Lösungen brauchst. Ich würde das mal so ein bisschen damit übersetzen, dass, also wie Angreifer angreifen, was sie für Motivationen haben, was sie verfolgen und wie sie zu ihrem Ziel geraten. Das ist ein relativ kleiner Ausschnitt von dem, was theoretisch alles möglich wäre. Das heißt, da, wo sich die Motivation, Angriffe zu machen, mit ausreichend verbreiteten Möglichkeiten dafür trifft, da entsteht so etwas wie eine Ransomware-Gang, die das über ein Jahrzehnt problemlos macht, weil sich keiner bewegt und das Problem irgendwie mal an der Wurzel überhaupt versucht anzugehen. Sondern Unternehmen gehen hin und sagen, achso, du willst ein Backup, was man nicht löschen kann, hier ist mein Angebot. Was auch in Ordnung ist, gibt ja auch eine Nachfrage danach, aber sie lösen halt nicht das Problem, sondern sie profitieren von dem Problem. Und dann natürlich werft man ein bisschen mehr Geld in, die Verteidigung, statt wie wir dann immer wieder von Staaten hören, zu sagen, in den Angriff zu investieren. Wer im Glashaus hackt, sollte das nicht in C machen. Wer im Glashaus hackt, sollte nicht in C coden. Das wäre jetzt so mein Fazit. Ja. Ich hoffe, dass wir das Thema breitenkompatibel ein bisschen näher gebracht haben. Und ich muss schon sagen, dass ich diese Art der Forschung, Aufbereitung, Umgang mit den Ergebnissen, von Anthropic schon immer wieder... Ja, wirklich, ja, also auf eine Weise sehr beeindruckend finde. Für diejenigen, die uns regelmäßig hören, ist es nicht lange her, dass wir uns über diesen, C-more-Cash und das ist das Ding, dass sie dann irgendwie, ihre Modelle dann den Snack-Automaten haben betreiben lassen und dann aber auch darüber reden und sagen so, hör mal, hat komplette Scheiße gemacht, hat Playstation gekauft und und philosophiert wie so ein Teenager. Also das ist schon ganz, aber es zeugt eben von einer wirklich forscherischen Auseinandersetzung mit dieser Technologie und eben einem. Natürlich profitieren die auch davon, dass jetzt die ganze Welt sagt, oh mein Gott, Claude kann alles hacken. Und dass diese Releases jetzt eben nicht in der Tiefe besprochen werden und gesagt wird, naja, es hat jetzt nicht Blackbox eine Infrastruktur gehackt, es hat halt in der Code-Basis in so und so wie tausende Anläufen Dinge gefunden, die nie jemand zuvor gefunden hat. Und das ist enorm beeindruckend, aber es gehört eben auch dazu, dass man versteht, dass es eine spezifische Art von Problem ist, die auf eine sehr spezifische Art und Weise gefunden wurde und trotzdem wurde noch erstaunlich viel Geld draufgeworfen. Nochmal, auch das hilft uns nur ein halbes Jahr, aber immerhin. So, das halbe Jahr haben wir noch. So, und bis dahin starte ich jetzt hier ein neues Projekt in C und das ist Vibe-Coding.

Tim Pritlove
1:49:45
Linus Neumann
1:49:51
Tim Pritlove
1:49:54
Linus Neumann
1:50:02
Tim Pritlove
1:50:04
Linus Neumann
1:50:15

Ja.

Tim Pritlove
1:50:16
Linus Neumann
1:50:37