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).

Lang geleden zeiden ze dat ook van Cobol. De belastingdienst harkt thans gepensioneerden binnen die Cobol beheersen.

De zwakke plek is wat de programmeur er mee doet. Mijn ervaring is dat oude c/c++ programmeurs veel beter zijn dan die gasten van tegenwoordig. De ouderen denken eerst goed na (geheugen management) voordat ze beginnen met compileren. Ik erger me dood aan die jonkies die met copy en paste programma's in elkaar flansen en dan met trial en error het werkend proberen te krijgen. De skills ontbreken gewoon omdat ze c/c++ er wel even bij denken te kunnen doen als ze een beetje python ervaring hebben. Dan hebben we het nog niet over een algoritme want dat kan ook heel beroerd zijn icm rust.

Ze hebben Rust echt niet voor niets bedacht. Je hebt volkomen gelijk dat er nog zat andere categorieën bugs overblijven en dat dus ook niet alle problemen weg zijn, maar ze hebben wel een verdomd grote categorie van wel degelijk echte problemen stevig verbeterd.

Rust staat nog steeds onveilige code toe, maar die moet als zodanig gemarkeerd worden en als ik het goed begrijp helpt de manier waarop dat is opgezet om de onveilige code tot een minimum te beperken en zijn de overgebleven stukjes onveilige code typisch zo klein en overzichtelijk dat ook daarvoor makkelijker is geworden om te overzien en te garanderen dat het veilig is.

Maar dat kan dus geen 100% garantie opleveren dat alles veilig is, en ik heb dat ook nooit ergens geclaimd zien worden. Men claimt een substantiële verbetering, geen perfectie. Dat laatste was pas grappig geweest, zo grappig dat vermoedelijk niemand Rust nog serieus had genomen ;-).

Je kunt nu wel prat gaan op competentie, maar daarmee red je het niet. Want het probleem is dat iedereen een auto moet kunnen besturen. Je kunt ze wel een rijbewijs geven maar bijna niemand wordt zo goed als een ervaren coureur van een racecircuit. In een auto accepteren we ook systemen als autogordels (ook al kwamen die later, net als Rust) zodat het minder erg is als jij of iemand anders een keer fout stuurt. Waarom is het zo moeilijk om dat te accepteren voor C++ programmeurs?

Welke reden, anders dan dat er nu nog relatief veel mensen zijn met ervaring in een memory unsafe programmeertaal, is er om niet over te gaan op een memory safe taal? Natuurlijk herschrijf je niet meteen alle software, maar wat is het bezwaar tegen autogordels?

Volgens mij zou EWD zou daar juist blij mee geweest zijn, dan weet je juist zeker dat je een categorie fouten niet kunt maken. Scheelt weer!

Er wordt een stelling geponeerd over opensourcesoftware.
Er wordt niets beweerd over closed source software.

De discussie lijkt te gaan over kwetsbaarheden van individuele software producten: "Het is duidelijk dat product X beter is dan Y".

Volgens mij wordt er dan een belangrijk punt gemist, nl. hoeveel impact hebben kwetsbaarheden in software op de maatschappij? Dat hangt primair af van het marktaandeel van die software, want hoe hoger het marktaandeel, des te meer is het interessant om die software aan te vallen, want dat levert cybercriminelen meeste op.

De vraag die ik essentieel vind: zijn we bereid om als maatschappij de risico's van veel kritieke processen te stapelen, omdat ze dezelfde software gebruiken? Deze risico stapeling is het gevolg van de inschatting dat software diversiteit voor kritieke systemen de beheerkosten te hoog maakt. Ik ben benieuwd wat jullie inzichten zijn over dit dilemma.

Dat is inderdaad grappig maar het wordt pas serieus als code ook fail save ge-genereerd kan worden vanuit een symbolic description language.
Wat mij aanstaat is dat rust ook geen null pointers accepteert maar een goede c programmeur test daar altijd op voor gebruik. Is rust ook zelf in rust geschreven? of is dat een kip en ei probleem?

Het is bekend dat de grote bouwers van besturingssystemen inmiddels ook Rust als memory safe optie gebruiken:
- Microsoft: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/
- Google: https://security.googleblog.com/2021/04/rust-in-android-platform.html
- Linux: https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

De reden: Rust is een 'silver bullet' om een hele categorie aan veelgemaakte security fouten te voorkomen, met als bijkomend voordeel dat multithreaded programma's beter (oa. minder deadlocks) draaien vanwege het geheugenbeheer.
Dit is een structurele verbetering waar de hele maatschappij indirect van profiteert.

Echter, het is 'slechts' een categorie aan security issues. Het is nog steeds mogelijk om daarin fouten te maken, maar je moet er als ontwikkelaar veel meer je best voor doen om het fout te doen. Andere categorieën blijven nog altijd bestaan, er komen zelfs nieuwe bij met generatieve AI: https://www.aivd.nl/documenten/publicaties/2024/10/17/generatieve-ai.-een-transformatieve-impact-op-cybersecurity
Je hoeft als security expert voorlopig niet bang te zijn dat je zonder werk komt te zitten.

De bijbehorende CWE-119:
Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
https://cwe.mitre.org/data/definitions/119.html

Dat is nogal een aanname. Code heeft de kwaliteit van de organisatie en/of cultuur waarin het geschreven is. Tot nu toe zitten er aannames in hun cultuur ("maak geen fouten, want C is niet memory safe") die niet waar zijn ("want mensen maken altijd een percentage fouten"). De vraag is hoeveel aannames er zijn die een zwakte vormen in het coding proces.

Het is mogelijk dat met een andere taal er ook een ander proces en cultuur wordt binnengehaald. Bijv. dat het in sommige talen gewoner is, en dat ze geschikter zijn, om tests voor te schrijven.

Ik begrijp wat je bedoelt maar code wordt niet geschreven in een cultuur maar in een taal :) Degene die die taal gebruikt is natuurlijk wel beïnvloed door de cultuur van een organisatie. Bv we accepteren geen code als er niet eerst pseudo code of UML diagram wordt gemaakt.

Dat is een aanname, want Android heeft het hoogste aandeel en ik denk niet dat dat systeem aanvallen het meeste oplevert.
Wat het meeste oplevert zijn de kroonjuwelen en die draaien meestal onder Linux (servers) maar die systemen zijn duidelijk van meer kwaliteit omdat het slagingspercentage gering blijkt. Het zwakst blijkt duidelijk de kantoorautomatisering (windows) want die gaat regelmatig op slot. Ik denk te zien dat de kwaliteit van de code bepalend is en niet het marktaandeel.
Het is net de natuur, een ziek en zwak dier wordt eerder opgegeten, niet omdat er veel van zijn. Als er veel zwakke dieren zijn lijkt het of het aantal bepalend is.

Grappig dat het momenteel veiligste OS in C geschreven is…. OpenBSD.

Je mag even uitleggen wat een symbolic description language is, want dat is iets dat ik in de 40 jaar dat ik al programmeer kennelijk overgeslagen heb, en een uitleg ervan zie ik niet in zoekresultaten of op wikipedia terug. Leg dan ook meteen even uit waarom het dan pas serieus is en tot dan grappig.
Dat is een opgelost kip-ei-probleem. Zo is dat opgelost:
https://rustc-dev-guide.rust-lang.org/building/bootstrapping/intro.html

Nee. Zie: https://secureblitz.com/most-secure-operating-systems/

Hoe lang doet een programmeur die aan C++ begint om er competent in te worden als die kennelijk eerst een zoektocht door moet met ongetwijfeld veel vallen en opstaan om te ontdekken wat je beter wel en beter niet kan gebruiken in die taal? Jaren, vermoed ik. En wat doen we met alle code die programmeurs al opleveren voordat ze competent zijn?

En ook goede programmeurs maken fouten. Iedereen maakt fouten. Als je denkt dat je geen fouten maakt is die zelfoverschatting vermoedelijk je grootste fout. En als je de fouten niet maakt kost het je tijd en energie om ze niet te maken. Als je in een taal kan werken die bepaalde categorieën fouten uit kan sluiten (in de bulk van de code), dan heeft de programmeur meer capaciteit over voor andere aspecten van de code en gaat de kwaliteit omhoog. Dat geldt ook bij goede programmeurs.

Hoe wil je dat veilig houden met de nieuwe lichting programmeurs, gezien de staat van het onderwijs?

Dat leer je toch niet op school maar door een ervaren vakgenoot.

Symbolic Description Language is in mijn oude Philips tijd bedacht om specificaties te beschrijven waarmee code gegenereerd kon worden voor digitale telefooncentrales. Blijkbaar is dit altijd gesloten gebleven en vergaan. Er was zelfs nog een computertaal bedacht speciaal voor het project en in de proprietary wereld vergaan.
Dit lijkt er wel op: https://en.wikipedia.org/wiki/Specification_and_Description_Language

Echt weer zo'n reactie van mensen die het niet weten/begrijpen. Je kunt met C of C++ gewoon veilig programmeren het hangt er gewoon vanaf hoe je het gebruikt. Dit is weer typisch zo'n geval van je kunt een spijker ergens uittrekken netjes met een nijptang of door 'm te vernachelen met een hamer.

Je kan veilig programmeren, maar er zit geen mechanismen in die je waarschuwt als je al of niet per ongeluk foute code schrijft. De bewaking zou je kunnen overlaten aan compilers, lint, of wat voor soort extra software dan ook, maar ziet die alles? Je kan en moet je software uiteraard testen, maar met testen haal je niet alle fouten eruit. Na het testen weet je alleen dat je software het onder de meeste omstandigheden goed doet.

Het venijn zit hem in het woord 'kunnen', met andere woorden: het hoeft niet zo te zijn.
Bij Rust heb je op het gebied van memory safety garanties.
Ik vind die vergelijking met die auto-gordels vrij treffend. Wie is daar nou op tegen?

Met heul veul security audits.

Dat is bij hun een doorlopend proces van een team van 6-12 mensen die niet eens specifiek op securityproblemen letten maar op bugs, en die worden hersteld. Dat betekent dat bij hun bugs meestal al zijn verholpen jaren voordat iemand ontdekt dat ze ook een security-impact hebben.
https://www.openbsd.org/security.html
Op een heel besturingssysteem, en zelfs alleen op de kernel van een besturingssysteem, vind ik 6-12 mensen niet veel. Interessante benadering.

Op Slashdot kwam ik gisteren tegen dat er een voorstel is om C++ uit te breiden met mogelijkheden om memory-safe te programmeren:
https://developers.slashdot.org/story/24/10/20/2359227/an-alternative-to-rewriting-memory-unsafe-code-in-rust-the-safe-c-extensions-proposal
De basis is kennelijk al geïmplementeerd en bewezen, de grote inspanning die er nog komt is om memory-safe versies van bestaande libraries te maken.

Ah, dank. Het lijkt een beetje het midden te houden tussen een Domain Specific Language met een grafische specificatie-interface en een flowchart die in ieder geval deels op statement-niveau werkt. Wat Wikipedia beschrijft stamt al uit de jaren '70 en was toen al grafisch, dat is geavanceerd voor die tijd.

Je (neem ik aan) schreef eerder:
De grap is dat als code wordt gegenereerd het heel goed mogelijk is om in een onveilige taal toch code te genereren die veilig is. Dat is een kwestie van de codegenerator de fouten niet te laten maken die gemaakt kunnen worden in die taal, en daar natuurlijk heel grondig op te testen.

Bedenk dat elke compiler een codegenerator is die machinetaal oplevert (of een tussentaal, maar laten we het beeld simpel houden). De programmeertaal is dan de "description language" voor de machinetaal. In machinetaal kan je elke onveiligheid die de CPU maar ondersteunt uitbundig botvieren, en toch kan je veilige programmeertalen ontwerpen waaruit de compilers veilige machinetaal genereren.