Feit is dat linux voor een groot deel uit C code bestaat. En dat je dat niet zomaar even naar een memorysafe taal omzet met een roadmap.

Ook is oude code veiliger als nieuwe code die net geschreven is. Dus tien jaar oude C code is niet zo'n probleem wanneer je erover nadenkt.

Gebruik daar bovenop besturingsystemen die zulke memory overflow exploits mitigeren door te zorgen dat programma's niet onveilig worden uitgevoert, ongeacht of dat het desbetreffende werking van het programma in de weg zit.
Als je de software niet kunt patchen kun je de omgeving waarin de software draait patchen.
Uiteraard is dit makkelijker te doen in open source omgevingen dan te wachten tot Microsoft of Apple het een keertje voor je doet...
GrapheneOS heeft allerlei mitigaties om dit te voorkomen zoals MTE, (Pixel 8 en hoger) hardened memory allocator en meer.
Op desktop systemen kan een VM goed helpen, deze sandboxing kunnen systemen minder snel compromiteren, gebruik besturingsystemen zoals QubesOS.
Correct me if I'm wrong.

Dat geld voor elk OS. Windows, Mac, Unix, Linux, BSD

Hoezo geldt dit niet voor closed source software?

Grappig is wel dat Rust "memory-unsafe" kan voorkomen maar een van de laatste CVE's voor Firefox maakt hier dus misbruik van.
En van wie is Rust? Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare.

Daarom is het grappig :p

Het beste voorbeeld dat ik zo snel kan bedenken is de OpenSSL heartbleed bug (https://heartbleed.com).
Ook wel CVE-2014-0160 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160).
"allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c"

Ofwel: jarenlange exposure van open source C-code recht in het gezicht van experts die denken dat ze goede code hadden geschreven! En toch zijn die mensen geen God, want ze hebben zich vergist, met hele grote gevolgen!

Dan is er nu een methodiek van 'memory safe' programmeertalen als Rust, met een garantie dat een hele categorie bugs niet voor kan komen. En dan zijn er genoeg programmeurs die C / C++ programmeren die geen zin hebben om hun expertise te verruilen voor een lagere instap in een andere taal. Logisch, maar niet veilig.
Gelukkig speelt Rust met iedereen: je kan onveilige code in 'unsafe {}' blokken plaatsen. Of je linkt een C of C++ library, dan ben je er ook, dus ik snap dat probleem niet.
Er zijn ook verstandiger mensen, zo is er een project om alle core utilities in Linux te herschrijven met een memory-safe programmeertaal: https://github.com/uutils/coreutils. Ook big tech gebruikt al langer Rust om hun OS-en veiliger te maken, bijvoorbeeld Google: https://security.googleblog.com/2021/04/rust-in-android-platform.html

Overigens is Rust niet meer van Mozilla, maar van heel big tech.
https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html

De conclusie is dat C en C++ in snel tempo dino's aan het worden zijn. Meldingen uit de VS als hierboven beschreven versnellen dat proces nog eens extra. Het is aanpassen of uitsterven (kan even duren, zie de mainframe knakkers met FORTRAN). Ik kan er zelf niet mee zitten want ik zit aan de veilige kant door met Rust te werken.

Nog een aardig artikel, in 2014 werd er al uitgebreid over geschreven: https://ieeexplore.ieee.org/abstract/document/6547101

Van https://www.theregister.com/2024/09/25/google_rust_safe_code_android/:
Schrijf en compile je je operating system zelf? Omdat je aan de veilige kant zit met Rust?

Anoniem 11:47

Er worden anders genoeg buffer overflow gerelateerde bugs gevonden in code van 10 jaar en ouder. Grappig, wanneer het een probleem met een PHP applicatie betreft staan mensen direct klaar om die taal totaal de grond in te boren (waarbij opvalt dat er nogal eens geschermd wordt met gebreken die al > 10 jaar niet meer aanwezig zijn), maar wanneer eindelijk eens de zwakke plekken van C en C++ worden benoemd vegen we dat maar onder het tapijt nadat code een bepaalde leeftijd heeft bereikt?

Je moet even beter onderzoek doen dan zo maar wat roepen om rust te promoten.
Het ging om een extension voor OpenSSL geschreven door een PhD student (geen experts dus die dachten dat ze goede code hadden geschreven zoals jij beweert) . Daarnaast is deze code alleen door Stephen Henson (1 van de 4 core developers) ge-reviewd. Die fout heeft er 2 jaar ingezeten en dus geen jaren!
Het gaat om een ingewikkelde library. Het probleem was te weinig dedicated full-time resources. Zeg maar zoals zo vaak in Nederland wel willen gebruiken maar betalen of bijdragen ho maar.

Probleem is dat een memory-safe programmeertaal maar een fractie van het aantal securityproblemen oplost (buffer overflow). De echte problemen blijven er gewoon inzitten: dit zorgt voor schijnveiligheid.

Slechte programmeurs schrijven security bugs in iedere programmeertaal.

En dat terwijl een competente C++ programmeur weet welke subset van C++ veilig te gebruiken is (en hoe je dat doet).