News VP8-Videokodierung: Zero-Day-Schwachstelle betrifft weit mehr als nur Chrome

[pseudopseudonym]

Ich kapiere sowieso nicht dass man kritische Befehle nicht einfach komplett entfernt.

Ist wirklich kein Angriff, aber viel mit Informatik hast du nicht zu tun, oder?

 

[ReactivateMe347]

Welche Anwendung encodiert denn Inhalte, die ein Angreifer manipulieren kann - Das mag etwa bei Handbrake ein Problem sein und auch da eher theoretisch, weil es durchaus nicht so einfach sein dürfte, jemanden dazu zu bringen, ein Video zu enkodieren.

Clientseitig dürfte da das Risiko gering sein. Anders sieht es natürlich aus, wenn ein öffentlich zugänglicher Videodienst wie Youtube in VP8 kodiert.

Ergänzung (30. September 2023)

Ja genau, ein weiterer riesen Vorteil von Linux

Das ist solange ein Vorteil, bis das Update einer Lib die Kompatibilität zu einer Anwendung zerstört, die nicht mehr bzw. nicht rechtzeitig gepflegt wurde.

 

[gymfan]

Welche Anwendung encodiert denn Inhalte, die ein Angreifer manipulieren kann

Das Beispiel steht doch schon in der Meldung. Chrome, allgemeiner jeder Videotelefonie-SW und jede Screencast-SW. Da werden halt nicht nur die Live-Bilder der Kamera codiert sondern auch gerne mal Bildschriminhalte. Nicht selten auch der Inhalt einer im Meetng aufgerufenen Webseite, die, wenn man so doof ist (sorry, so industriefreundlich), auch noch Werbung oder andere dynamische Inhlte enthält.

Clientseitig dürfte da das Risiko gering sein.

Wenn Du keine Videokonferenzen mit Deinem PC machst oder dort weder unbekannten Inhalt oder schon nur das Bild anderer Teilnehmer wieder codierst, mag das so sein.

Ich würde mich hier eher fragen, welche SW VP8 (und nicht VP9 oder sonstwas) nutzt.

PASCAL wurde früher immer als sicherer als C beworben.

Sicherheit kostet halt in den allermeisten Fällen Performance, selbst wenn ein moderner Pascal-Compiler kein P-Coide System mehr nutzen mag sondern sowas wie jit-Compiler.

 

[cbtestarossa]

Ist wirklich kein Angriff, aber viel mit Informatik hast du nicht zu tun, oder?

Warum lässt man alte unsichere Befehle noch in einer Sprache?
Wenn man das nicht sicher bekommt ist es besser gewisse Dinge ganz zu entfernen.

Warum gibts jedes Jahr gefühlt zig neue Sprachen?
Ist ja fast so wie bei Linux Distris.

Jedes Monat die selbe Grüze mit irgendwelchen Überlaufsmeldungen.

C ist für mich sowieso nichts da ich mit Basic, Comal, Pascal und ASM programmierte.
Mach aber schon lange nichts mehr weil sich die Zeiten und Prioritäten geändert haben.

 

[pseudopseudonym]

Warum lässt man alte unsichere Befehle noch in einer Sprache?
Wenn man das nicht sicher bekommt ist es besser gewisse Dinge ganz zu entfernen.

Ich probier's zu später Stunde.

da ich mit Basic, Comal, Pascal und ASM programmiert

In Assembler hast du doch sehr oft selbst in irgendwelche Register bzw Speicheradressen geschrieben. Jetzt stell dir mal vor, diese Möglichkeit entfernt man. Da bleibt dann nicht mehr viel für dich übrig, damit bekommst du dann kein vernünftiges Programm mehr hin. Dass du einfach irgendwo hinschrieben kannst, ist aber der Angriffsvektor.

Genau das hast du in C aber auch mit Pointern, die ein essentieller Teil von C sind.
Wenn du z. B. ein Array hast, benutzt du das über einen Pointer. Hat das Point 5 Felder, gehst du als Programmierer davon aus, dass hinter dem Ziel deines Pointer noch 4 weitere freie Felder sind. array[1] ist eigentlich nur syntaktischer Zucker dafür, dass du eine Adresse hinter die Adresse vom Array springst (Arrays gibt's in C nicht wirklich, das ist alles nur, damit der Quellcode schöner ist).
Da ist also kein einfacher Befehl, den du mal eben entfernen kannst.
Einfach erkennen kannst du diese Zugriffe auch nicht, du müsstest für jeden Zugriff alle möglichen Checks ausführen, die jede Menge Performance fressen. Teilweise würdest du damit vermutlich auch Verhalten verbieten, das von Programmieren seit 50 Jahren bewusst mit guten Absichten benutzt wird. Du hast also im Prinzip eine komplett neue Programmiersprache.

Und jetzt kommen ganz schlechte Nachrichten: Am Ende wird alles Maschinencode, der eben genau diese Zugriffe erlaubt. Also selbst die "beste" Programmiersprache kann wieder einen dummen Bug irgendwo haben, der dir alle guten Ideen zunichte machst.

Warum gibts jedes Jahr gefühlt zig neue Sprachen?

Weil die meisten (gut, eigentlich alle) Sprachen für Vorteile wieder Nachteile haben. Mehr Luxus/Sicherheit -> Schlechtere Performance (jaja, grob gesagt).
Und weil sich viele weiterentwickelt. Rust z. B. schafft es irgendwie doch, ein gutes Dev-Erlebnis (Luxus&Sicherheit) mit Performance in Einklang zu bringen.
Cross-Plattform-Fähigkeiten sind auch ein größeres Thema. Wie baust du eine Anwendung, die auf iOS, Android, im Browser und aufm Desktop laufen kann? Mit C wird das schon mal nichts.
Testbarkeit kann auch ein Thema sein. Gute Unit-Tests mit Mocks usw für C++-Anwendungen zu bauen, ist echt ein Albtraum, kann ich dir sagen! Da weiß man modernere Sprachen echt zu schätzen.
Dann hängt an den Programmiersprachen oft auch noch ein Ökosystem dran.
So kommen wir allein bei uns in der Firma auf 6 Sprachen im Techstack, HTML und CSS natürlich NICHT mitgezählt (zumal die Webseite eh nicht wirklich ein Thema des Dev-Teams ist, wäre zu teuer), Shell-Scripte und ähnliches auch nicht.

Jedes Monat die selbe Grüze mit irgendwelchen Überlaufsmeldungen.

Ich bin nicht gut im Erklären, aber ich hoffe, dass du jetzt etwas besser verstehst, warum das leider dazugehört.

 

[ReactivateMe347]

Das Beispiel steht doch schon in der Meldung. Chrome, allgemeiner jeder Videotelefonie-SW und jede Screencast-SW. Da werden halt nicht nur die Live-Bilder der Kamera codiert sondern auch gerne mal Bildschriminhalte.

Guter Punkt - Die Frage ist, ob das für einen Angriff reicht , denn so kann man ja den Input-Stream zwar beeinflussen, aber eben nicht frei beeinflussen.
Nach der groben Beschreibung war ich davon ausgegangen, dass man den Input wirklich frei bestimmen können muss als Angreifer. Wäre sehr neugierig, was die Anforderungen" sind.

Wenn etwa ein Einzelbild größer sein müsste als erwartet, dann könnte der Angreifer das nicht beeinflussen im von Die genannten Szenario, das er nur das Was beeinflussen kann, nicht das wieviel.

 

[nirgendwer]

Das ist solange ein Vorteil, bis das Update einer Lib die Kompatibilität zu einer Anwendung zerstört, die nicht mehr bzw. nicht rechtzeitig gepflegt wurde.

Wenn beides Teil der Distribution ist, dann wird beides zusammen getestet und das Release erst freigegeben, wenn eine Lösung des Problems gefunden wurde.

Tatsächlich ist es hier durchaus von Vorteil, die Lib ausgelagert zu haben. Manch reale Linux-Distribution behebt hier CVE-2023-5217 tatsächlich ganz konkret an zentraler Stelle für alle Anwendungen, die die libvpx nutzen und muss Anwendungen wie Firefox daher gar nicht einzeln patchen.

Cross-Plattform-Fähigkeiten sind auch ein größeres Thema. Wie baust du eine Anwendung, die auf iOS, Android, im Browser und aufm Desktop laufen kann? Mit C wird das schon mal nichts.

Ein und das selbe Programm über alle deine Beispiele wird auch ohne C wohl eher nichts bzw. bleibt da als einzige Möglichkeit nur eine layout-flexible Web-App.
Plattformunabhängigkeit an sich ist dagegen prima auch mit C möglich und ein Großteil an plattformunabhängiger Software ist tatsächlich in C geschrieben.

 

[pseudopseudonym]

Plattformunabhängigkeit an sich ist dagegen prima auch mit C möglich und ein Großteil an plattformunabhängiger Software ist tatsächlich in C geschrieben.

Ich bin auf deine Liste von C-Anwendungen, die auch im Browser laufen, gespannt! Ich meinte damit auch wirklich den Code, der im Browser läuft, nicht nur einen Teil des Backends.
Hast du irgendeinen Link, der darauf hinweist, wie das vernünftig machbar ist?

Du willst allen Ernstes in C eine Anwendung bauen, die vernünftig auf iOS, Android und vielleicht noch auf dem Desktop läuft? Viel Spaß! Sicher ist das irgendwie möglich, aber warum sollte man sich das antun?
Und mein Beispiel enthielt noch Browser als Plattformen, da dürfte Schluss sein.

Wenn die Anwendung nur auf klassischen Desktops laufen soll oder eine Lib ist, die gar keine UI hat, ist das natürlich wieder eine andere Sache.

 

[nirgendwer]

Bitte meinen Beitrag nochmal lesen:

Ein und das selbe Programm über alle deine Beispiele wird auch ohne C wohl eher nichts bzw. bleibt da als einzige Möglichkeit nur eine layout-flexible Web-App.

Und genau genommen ist die Web-App gerade nicht plattformunabhängig, denn sie benötigt eine sehr spezifische Plattform: den Browser.

Das darauf folgende:

Plattformunabhängigkeit an sich ist dagegen prima auch mit C möglich und ein Großteil an plattformunabhängiger Software ist tatsächlich in C geschrieben.

... bezieht sich offensichtlich, wie auch dort schon steht, eben auf "Plattformunabhängigkeit an sich" und das ist eben sehr wohl bei C-Anwendungen üblich (die z.B. auf einer Fülle an unterschiedlichen Betriebssystemen und CPU-Architekturen laufen).

 

[pseudopseudonym]

Bitte meinen Beitrag nochmal lesen:

Ja, hab auch noch ein paar Sachen editiert. Klassischer Sonntagspost

Und genau genommen ist die Web-App gerade nicht plattformunabhängig, denn sie benötigt eine sehr spezifische Plattform: den Browser.

Deswegen war der Browser auch Teil einer Liste:

OS, Android, im Browser und aufm Desktop

bezieht sich offensichtlich, wie auch dort schon steht, eben auf "Plattformunabhängigkeit an sich" und das ist eben sehr wohl bei C-Anwendungen üblich

Gut, damit hast du theoretisch recht.
Aber was bringt es dir, irgendwie C-Code auf jeder Plattform (außer Browsern, die sind damit raus) auszuführen, wenn du noch eine UI brauchst, die auf allen Ziel-Plattformen vernünftig läuft? Mit reinem C eine Codebase zu bauen, die wirklich auf Desktops (da gibt's dann noch wieder Linux, MacOS und Windows...), iOS und Android vernünftig läuft und aussieht, dürfte ein riesiger Akt sein.
Deswegen hat der VLC-Player dafür auch gleich mal drei Codebasen:
https://github.com/videolan/vlc
https://github.com/videolan/vlc-android
https://github.com/videolan/vlc-ios

Und Browser sind mit C ziemlich sicher raus. Genau deswegen hat man sich dafür andere Technologien einfallen lassen, die eben auch neue Sprachen enthalten.

Davon abgesehen sollte es auch kein Geheimnis sein, dass komplexe C-Anwendungen alles andere als trivial sind, gerade wenn dann eben noch UI dazu kommt. Ich bin wirklich froh, dass man da inzwischen andere Optionen hat!

 

[nirgendwer]

Klassischer Sonntagspost

passiert 😂

... komplexe C-Anwendungen alles andere als trivial sind, gerade wenn dann eben noch UI dazu kommt...

Man macht da, was man anderswo ja auch nicht anders macht: Man verwendet ein UI-Toolkit, welches selber wiederum plattformunabhängig sein kann.

GCompris ist z.B. so eine Anwendung, die Desktop und Mobile abdeckt. Zwar überwiegend nicht direkt C sondern C++ und aktuell auch (noch) kein iOS, aber immerhin Windows, Linux, Mac und Android. (und ganz nebenbei ein durchaus gutes Beispiel für eine sinnvolle Open Source-Anwendung, unterhaltsam und auch mit Lerneffekt für Kinder 😀)
C lässt sich so genauso nutzen und Qt (das hier genutzte Toolkit) unterstützt generell auch iOS. Insofern vermutlich durchaus ein valides Beispiel - sofern sie nicht große Teile für jede Plattform einzeln neu implementiert haben, das hab ich jetzt nicht konkret geprüft.

 

[pseudopseudonym]

@nirgendwer
Du hast dann eben auch solche Codeblöcke:

QString ApplicationInfo::getFilePath(const QString &file)
{
#if defined(Q_OS_ANDROID)
    return QString("assets:/share/GCompris/rcc/%1").arg(file);
#elif defined(Q_OS_MACX)
    return QString("%1/../Resources/rcc/%2").arg(QCoreApplication::applicationDirPath(), file);
#elif defined(Q_OS_IOS)
    return QString("%1/rcc/%2").arg(QCoreApplication::applicationDirPath(), file);
#else
    return QString("%1/%2/rcc/%3").arg(QCoreApplication::applicationDirPath(), GCOMPRIS_DATA_FOLDER, file);
#endif
}

Wenn man mal in den activities nach ähnlichem sucht, sieht das so aus:

Ist machbar, bequem sieht das nicht aus. Wenn ich eine Anwendung bauen will, die auf allen Mobil-Plattformen läuft und vielleicht noch auf dem Desktop oder im Browser, fallen mir wenig Gründe ein, auf das hier gesehene zu setzen. Erst recht, wenn ich mit Entwicklerressourcen haushalten muss.

Um den Bogen zum Ursprung mal zurückzuschlagen: Weil ich mit der Ansicht nicht allein dastehe, gibt es eben immer mal wieder neue Ansätze bei Frameworks und Programmiersprachen. Das Gleiche gilt natürlich auch für andere Anwendungsbereiche.

 

[gymfan]

Guter Punkt - Die Frage ist, ob das für einen Angriff reicht , denn so kann man ja den Input-Stream zwar beeinflussen, aber eben nicht frei beeinflussen.

Die von mir als Beispiel genannten Werbeanzeigen kann ein Angreifer nahezu frei beeinflussen. Wenn es die Leute (früher) schon geschafft haben, darüber Flash-Plugins zu installieren, könnte es auch gelingen, ein solches Werbebild mit exakt dem Inhalt auszuliefern, welches zumindest lokal auf dem PC, auf dem der Browser die Webseite öffnet, auch den Pufferüberlauf generieren kann.

Wenn etwa ein Einzelbild größer sein müsste als erwartet, dann könnte der Angreifer das nicht beeinflussen im von Die genannten Szenario, das er nur das Was beeinflussen kann, nicht das wieviel.

Dazu müsste man den genauen Fehler kennen. Videocodecs arbeiten u.A. mit einer Bewegungserkennung, womit sie jedes Einzelbild irgendwie ein Teile zerlegen. Wenn der Fehler dort liegen sollte und bei speziellen Konstellationen des Ausgangsbildes der Pufferüberlauf dabei erzeugt werden sollte, dann reichen u.U. ein paar dutzend korrekt plazierte Pixel im Bild, um den Pufferüberlauf auszulösen. Die Werbung kann, z.B. als GIF, auch einen animierten Inhalt anzeigen.

Auf Grund der fehlenden Infos zur genauen Arbeitsweise ist das für mich jedenfalls eine eher mögliche Angriffsmethode im Clinetumfeld (bei genutzter Videokonferenz-SW), wie bei allen Spectre/Meltdown und Nachfolgebugs zusammen. Getoppt aktuell nur durch den WebP Decoderbug, den Google vor ein paar Tagen hochgestuft hat. Der ist zwar auch schon gefixed, aber erst ab libwebp 1.3.2, die noch lange nicht überall angekommen sein mag. Chrome/Firefox sollten die Fixes hoffentlich schon haben, bei Irfanview muss man derzeit selber Hand anlegen und die aktualsierten Plugins installieren.

 

[DarkSoul]

Ich kann als erfahrener C-Programmierer mit dieser Aussage nichts anfangen. Kannst Du mal ein konkretes Beispiel nennen? Zu mal "Sniplets" was ganz anderes sind als "Bibliotheken".

Das ist ganz einfach, statt jedes Mal von Hand bei einem neuen Projekt z. B. eine Stringausgabe bei DOS zu programmieren, erstellt man sich eine Funktion, die den Text übernimmt und ihn ausgibt. Bei Assembler das gängiste Verfahren, da solche Funktionen nicht nativ vorliegen. Das kann man auf alles übertragen, was man mit Daten tun will.

In der Praxis ist meist eine Mischung daraus. Was würdest Du anders machen?

Nein, das eine sind Datenstrukturen und das andere der Umgang mit den Daten. In deinem Fall wird bei vernünftiger Datenarchitektur eben auch die aktuelle und zu erwartende Größe mit angegeben (die bei der Ablage bzw Komprimierung bekannt ist) und dann hat man an dieser Stelle schon eine Sicherheitslücke weniger. Dann kann die Funktion aus der oben genannten Bibliothek diese Daten zur Prüfung bereits bei der "Annahme" der Daten als auch beim Ablegen verwenden.

Welche Prüfungen? In Realität wird längst nicht jeder Code einem intensiven Review unterzogen, und selbst wenn es ein Review gibt, ist es nicht sicher, das es jeden Fehler findet.

Natürlich nicht, daher gibt es automatisierte Tools, die das für einen übernehmen.

OpenSSL wird seitdem zwar besser überprüft, trotzdem gab es 2022 wieder eine Lücke:
https://www.heise.de/news/Jetzt-akt...durch-Luecke-in-OpenSSL-moeglich-7163675.html

Und ich habe nicht den Eindruck, dass die Probleme weniger werden, wenn ich die Menge an Security Hinweisen unseres Firmen CERT Teams so ansehe.

In dem Fall ist das eher ein "unglücklicher" Mix von Datenstruktur, Algorithmus und Funktionsabsicherung. Bei OpenSSL sind es wohl die Pointer: "OpenSSL makes heavy use of function pointers." und der kommt wohl von: "Interestingly, he also found an apparent bug in the paper by Shay Gueron upon which the RSAZ code is based." Ursache ist, wenn ich das richtig verstanden habe die Reduzierungsfunktion: "For some values of B, E, M for which B ^ E % M == 0, some functions would return M instead of 0; the result was not fully reduced."

Solche Fehler sind in komplexen Algorithmen mit viel größerer Warhscheinlichkeit zu finden als natürlich in simplen Hello-World-Anwendungen. Daher sind Verschlüsselungen, (De)Komprimierungsalgos & Co genauso wie Kopierschutzmechansismen dafür am anfälligsten.

Ergänzung (2. Oktober 2023)

Wenn C oder eine andere Sprache solche Fehler erlauben zu programmieren läuft irgendwas falsch.

Nö, das ist ganz normal bei einem System, das über Speicherzugriffe funktioniert. Gerade Assembler und C(++) sind wegen der direkten Verwendung von Pointern (was nichts anders als ein Zeiger auf einen Speicherbereich ist) anfällig, vor allem auch, wenn man unallociierten Speicher verwendet.

 

[TomH22]

Dann kann die Funktion aus der oben genannten Bibliothek diese Daten zur Prüfung bereits bei der "Annahme" der Daten als auch beim Ablegen verwenden.

Klar. Nur wie stellt man sicher, dass der Programmierer der Bibliothek das auch richtig implementiert? Wie gesagt, mir geht es nicht um den Benutzer der Bibliothek (der muss sich zu einem gewissen Grad darauf verlassen, das die Library korrekt programmiert ist - jedenfalls ist es nicht praktikabel jede benutze Bibliothek selber einem Audit zu unterziehen...), sondern um den Autor.
Egal ob Heartbleed oder die jetzige Lücke in WebP, es handelt sich um Implementierungsfehler in Basisbibliotheken.

BTW: Auch wenn ich in Rust programmiere, bin ich natürlich nicht davor gefeit, dass in Compiler (für die Compile Time checks) oder in der Runtime (z.B. für Bounds-Checks) Fehler schlummern.

Natürlich nicht, daher gibt es automatisierte Tools, die das für einen übernehmen.

Klar, die finden heute auch schon eine ganze Menge. Problem sind die False Positives, bzw. die Klärung der Frage ob ein False positive wirklich ein False Postive ist.

Wir nutzen auch Tools um unsere Dependenicies auf bekannte Vulnerabilities und auch Lizenzprobleme zu überprüfen. Die finden in der Praxis immer etwas. Am Ende muss man dann immer abwägen, wie man damit umgeht. Wir haben z.B. diverse NPM Packages die nur im Rahmen der Testautomatisierung eingesetzt werden. Das ist natürlich anders zu bewerten, als wenn es in einem produktiven Web Service verwendet wird.

 

[cbtestarossa]

Mir ist es sowieso egal solange Dinge gefixt werden.

Was mich betrifft bin ich der selben Meinung wie der Herr hier
Warum "C" nicht meine Lieblingsprogrammiersprache ist

 

[TomH22]

Was mich betrifft bin ich der selben Meinung wie der Herr hier
Warum "C" nicht meine Lieblingsprogrammiersprache ist

Ich kenne diesen Artikel und er ist zum größten Teil Schwachsinn.
Grundsätzlich sind Pascal und C in Realität ähnlich unsicher. Das gilt vor allem für "erweiterte" Pascal Implementierungen wie Turbo Pascal, Delphi und Free Pascal, die eben viele Konstrukte von C übernommen haben, um Pascal tauglich für systemnahe Programmierung zu machen.

Das gilt z.B. für Type Cast Operatoren, Generische Pointer (Datentyp "address" in Turbo Pascal), und MemAlloc und MemFree (weiß nicht genau ob ich die Namen richtig in Erinnerung habe, TP ist lange her, aber sie entsprechen malloc und free).

Die Syntax von Pascal mag etwas freundlicher sein, aber das ist reine Gewöhnungssache.

Aber selbst das Ur-Pascal von Jensen&Wirth hatte mit "Freien Varianten", das sind Record Varianten ohne Selector-Variable, eine Entsprechung des Union-Typs in C. Damit konnte man beliebigen Schindluder treiben, inkl. auch Pointer auf beliebige Speicherbereiche zu erzeugen.

Der Autor des Textes hat auch keine Ahnung was Standard Pascal ist, denn er behauptet Pascal Strings haben eine max. Länge von 255 Zeichen und ein Längenbyte am Anfang. Das ist die Implementierung von UCSD Pascal und Turbo Pascal. "Ur-Pascal" hat nur Strings fixer länger die kaum benutzbar sind. Da 255 Zeichen schon unter CP/M nicht immer reichten, haben viele Pascal Programmierer Strings selber in C-ähnlicher Weise implementiert.

Die vom Autor des Textes gelobten Pascal Sets sind zwar ein auf dem ersten Blick hübsches Feature (ich habe das seinerzeit auch gerne benutzt, es erlaubt recht elegant zu lesenden Code), aber leider ist die Maxiamle Größe eines Sets extrem implementierungsabhängig. Das Original Pascal auf der CDC 6000 erlaubte nur 60 Elemente (weil die CDC eine 60 Bit Maschine war), bei Turbo Pascal waren aus glaube 256 Elemente, manche anderen Pascals erlaubten bis zu 4096 Elemente.

Das größte Problem von Pascal war, dass eben der Sprachstandard so mangelhaft für praktische Projekte war, das jeder Compiler seine eigne inkompatible Erweiterung mitgebracht hat.

Einer der Gründe warum sich C durchgesetzt hat war, dass man damit wirklich portablen Code schreiben kann. Die Mittel in Form von Präprozessor Macros dazu sind zwar teilweise "krude" und fehleranfällig. Aber da der Preprozessor Bestandteil der Sprachdefinition ist, funktioniert er überall.


Jetzt sind wir natürlich weit weg vom Ausgangsthema, wenn die Diskussion im Aquarium landet ist es ok, aber ich wollte darauf doch gerne antworten...

 

[ReactivateMe347]

Auf Grund der fehlenden Infos zur genauen Arbeitsweise ist das für mich jedenfalls eine eher mögliche Angriffsmethode im Clinetumfeld (bei genutzter Videokonferenz-SW)

Da können wir weiter hin und her spekulieren, das bringt nichts.

wie bei allen Spectre/Meltdown und Nachfolgebugs zusammen.

Ist auf nem normalen PC relativ irrelevant, weil Apps eh nicht so richtig isoliert sind voneinander. Bei Virtualisierung/Containern und Diensten verschiedener Nutzer ist das wesentlich relevanter.

Chrome/Firefox sollten die Fixes hoffentlich schon haben, bei Irfanview muss man derzeit selber Hand anlegen und die aktualsierten Plugins installieren.

Vorallem eben alles, was auf diesen erbärmlichen WebApp-Frameworks basiert (Electron, Chromium Embedded Framework usw)

​

Ergänzung (3. Oktober 2023)

Ein und das selbe Programm über alle deine Beispiele wird auch ohne C wohl eher nichts bzw. bleibt da als einzige Möglichkeit nur eine layout-flexible Web-App.

Wenn es mal so wäre. Vergleiche mal Dekstop-Spotify, Web-Spotify (Vollbild und auf Handyformat verkleinert), Android-App und iOS-App. Da liegen welten dazwischen, da ist nix mit einmal einwickeln für alle Plattformen.