In nieuwere iteratie van programmeertaal kunnen deze kwetsbaarheden worden opgelost. Het is ook sterk de compiler hoe de machine code er uit komt te zien. De "veiligere" programmeertalen zijn of vanuit het ontwerp al beter ontwikkeld. Wil niet zeggen dat je geheel veilg bent. Ook hier zijn op termijn exploits voor te vinden. Kijk hoe java eerst al veilig werd gezien. Daarna was het zo lek als een mandje en tegenwoordig weer een veilige taal.

Het is in C inderdaad makkelijk om geheugenproblemen te veroorzaken. Echter, het is met de juiste aandacht prima te voorkomen. Zo zijn met een eenvoudige test-library geheugenlekken eenvoudig op te sporen. Echter, geheugenlekken is een van de problemen die je kan veroorzaken met onveilig programmeren. Programmeurs laten overschakelen naar geheugen-veilige-programmeertalen is geen oplossing voor het probleem. Het zorg er niet voor dat programmeurs veiliger gaan programmeren.

In het algemeen generen "memory safe" programmeertalen een veel tragere code vanwege de extra checks. Het artikel wijst er ook op dat dit soort talen een 'niet-triviale' extra belasting voor de CPU en het geheugengebruik kan betekenen.

Pas in de appendix worden een paar voorbeelden genoemd van dergelijke talen. Interessant is de taal Swift, die ik niet kende. Mijn laatst gebruikte talen waren objective-C en Javascript. De laatste is volgens mij ook memory safe. Swift zou een goede vervanger van Objective-C zijn en zelfs code genereren die tot 2,6 keer sneller is.

Ook interessant dat "java" tussen de memory safe talen staat omdat daar in het verleden juist zoveel veiligheidsproblemen mee waren. Maar waarschijnlijk dan net niet door memory overflows.

Maar er zijn ook andere factoren.

Door het niet sneller invoeren van best policies blijft er ook een heleboel onveiligheid bestaan.

Waarom zijn er nog HTTP-only sites? Waarom niet overal header-security geimplementeerd e,d.?

Kennelijk zijn er spelers, die geen echt veilig Internet wensen.

Zo komt er ook nooit echt een einde aan cuybercriminaliteit.

Dus first things first,

luntrus

De five eyes landen dus

Nee maar de JVM implementatie dan weer wel want die is meestal in C++ geschreven.
Dus je verlegt het probleem daar enkel bij.

Daarnaast is het grootste risico toch nog altijd de cutting corners die developers uitvoeren zelf of onder druk en de bijhorende slechte controles van code. Vroeger als je een implementatie moest doen dacht je wel lang en breedt over na voor je release want je gebruikers gingen er niet van uit dat ze dagelijks patches zouden ontvangen. Nu is het als het niet werkt ach dan draaien we toch even een patch.

Rust voert deze checks uit tijdens compile-time, niet tijden run-time, wat voorkomt dat de fouten erin zitten of komen en voorkomt ook dat de performance van de code eronder lijdt. Het kan dus wel geheugenveilig en snel, maar daarvoor zijn wel talen nodig die zijn ontworpen met deze doelen in gedachten.

als je nu eens niet de aaname doet dat een progammeur altijd en overal veilige code KAN schrijven omdat ie een imperfecte mens is, dan ga je misschien anders naar de zaak kijken... je leert een kleuter ook geen kwamtum theorie immers.

Zolang basic BASIC commando's als PEEK en POKE nog werken blijft niks echt helemaal veilig.

Het beveiligingsrisico zit fundamenteel in het gebruiken van alles wat digitaal is. Niks is sneller veranderbaar dan data, code en de combinatie daarvan.

Het kan een byte in een geheugen niks schelen of het data of code is.

Leertip : MMU .
De wereld is verder gegaan dan de Z80 en 6502 .


Volgende leertip : NX bit op data segmenten.

Het is niet zo makkelijk als het was.
Uitgebreidere studie tip 'capability systems' , beloven nog meer maar zitten nogal in een niche .

'silver bullets' bestaan niet , maar jouw statements lopen echt een jaar of dertig achter , en de wapenwedloop tussen verdediging en aanval heeft een hoop cyclussen gehad inmiddels.

Denk ook aan de discrepantie tussen verdediging en aanval.

De verdediger moet over de hele linie met van alles en nog wat rekening houden.

De aanvaller heeft aan een klein maar werkend effectief rotgaatje genoeg.

Weet je hoe klein gaatje een muis nodig heeft om zich een huis binnen te wurmen?

#webproxy

Nim is een interessante taal in dit opzicht, omdat die toch snelle code weet te produceren.

Een van de uitgangspunten bij Nim is dat als de compiler dit soort dingen niet kan beredeneren je niet moet verwachten dat de programmeur het beter kan — en dus moet de compiler dat wel kunnen. Het heeft daartoe een "effects system" waarmee allerlei aspecten van wat code doet door de compiler kunnen worden beredeneerd. Als een procedure gemarkeerd is om geen neveneffecten te hebben dan krijg je compilatiefouten als ergens diep in indirect gebruikte code opeens iets wel een neveneffect heeft. Als je een procedure markeert om thread-safe te zijn dan krijg je foutmeldingen op alles wat niet thread-safe is, in je eigen code en in alle Nim-code die erdoor gebruikt wordt. Nim is er nog niet helemaal, een programma kan nog steeds crashen op het gebruik van een null-pointer (in Nim-terminologie heb ik het over een ref, technisch een pointer maar een waar de compiler volledige controle over heeft en die op runtime goed door de garbage collectors[*] wordt afgehandeld — voor onveilige interactie met C- of C++-code zijn er ook "gewone" pointers, maar die mijd je in Nim zoveel mogelijk). Er is een experimentele feature die, als je die aanzet, op zich via dat effects-system daarop controleert en dat goed lijkt te doen, alleen zitten er in de standard library nog macro's en templates die code genereren die je dan niet meer gecompileerd krijgt. Het is daardoor nog niet zo ver dat deze feature praktisch bruikbaar is en daarom zal hij als experimenteel gemarkeerd zijn, maar het is duidelijk dat het er wel aan zit te komen.

Het mooie van zoveel door de compiler laten controleren is dat er wel degelijk snelle code gegenereerd kan worden, en ook wordt. Dit is zo'n taal die niet uit de koker komt van een commerciële partij die snel wil scoren maar ontsproten is aan het brein van iemand die zowel veel kennis heeft opgedaan van wat andere talen aan interessante eigenschappen hebben als uitgesproken en zeer interessante eigen ideeën heeft over wat zijn ideale taal voor eigenschappen moet hebben, en die (natuurlijk samen met anderen die eraan mee-ontwikkelen) geen concessies doet aan die ideeën. Ideeën waarin overigens centraal staat dat alles praktisch nut moet hebben en niets erin moet zitten omdat iemand er toevallig op kickt.

Ik gebruik Nim sinds enige tijd voor privé-projecten, waarbij ik mezelf aardig in het diepe gooi door lastige software erin te schrijven (voor mezelf kies ik op de een of andere manier vaak dingen die complexer zijn dan ooit als werk heb moeten doen — vermoedelijk omdat ik niet te maken heb met management dat zuinig gaat kijken en kan kiezen wat me boeit). Ik vind het een feest om mee te werken. Nog niet af, nog niet perfect, maar zeer veelbelovend.

Het is qua aantal ontwikkelaars (zowel in Nim als van Nim zelf) een kleine, marginale taal, en dat kan natuurlijk voor een bedrijf een belangrijke reden zijn om er niet afhankelijk van te willen worden, los van wat de taal verder voor eigenschappen heeft. Ik ga daarom niet roepen dat iedereen aan Nim moet omdat ik het zo geweldig vind.

Maar ik moet wel denken aan hoe ik ooit Python "ontdekte", ervan gecharmeerd raakte en het ging gebruiken toen dat ongeveer zo oud was als Nim nu, en toen het nog helemaal niet grootschalig was aangeslagen maar gezien werd als iets waar je maar beter geen risico's mee kan lopen. En moet je Python nu zien. Als ik een neus heb voor die dingen (wat ik zelf wel denk maar waar natuurlijk de rest van de wereld het niet mee eens hoeft te zijn ;-) ) dan zou Nim over 15 jaar wel eens aan een indrukwekkende opmars bezig kunnen zijn.

[*] Dat ik garbage collectors (meervoud) schrijf is geen verschrijving, je hebt de keuze uit meerdere garbage collectors (of helemaal geen), waaronder een (sinds Nim 2.0.0 de default) met een minimum aan overhead.

Kijk eens wat er op een veelbezochte site als wikipedia nog kan worden gedaan.
bron: sucuri scan.

Soms zijn de talen wel een "probleempje". Echter binnen iedere taal moet je een gedegen framework en/of model hebben.
Goed programmeerwerk en testen is vaker het probleem dan zgn. onveilige talen.

Niemand is feilloos. Zelfs de meest ervaren programmeurs maken fouten. (Heartbleed)
Het is broodnodig dat er talen zijn waarmee je bewezen veilig kan programmeren.

Rust is veelbelovend in de zin dat het geheugenfouten voorkomt tijdens compile-time en daardoor race-condities voorkomt.
Het gebruikt geen garbage-collector en kan zich daardoor meten met C/C++, met veel ergonomie.
Er is een compleet eco-systeem met een keur aan frameworks.
De adaptatie neemt met het jaar gestaag toe volgens de TIOBE-index.
De grootste big tech bedrijven hebben zich achter Rust geschaard en gebruiken het om hun software (bv. Android) veiliger te maken.

En dan nu de aanbeveling van de FBI en de NSA. Dan heb ik het toch goed gezien om met Rust te gaan programmeren. Het probleem is niet alleen technisch, maar vooral ook zakelijk; veel software wordt niet vanuit een academische setting geschreven. Wanneer tijd en budget onder druk staan, staat kwaliteit van software onder druk. En dan is het goed om een achtervang te hebben met de 'borrow checker', met ook een unsafe mode (opt-out) voor wie het beter weet dan Rust.

En zo is het maar net.

En waarom schakelt Google dan over op Rust om veiligheidsredenen?
(https://www.zdnet.com/article/google-after-using-rust-we-slashed-android-memory-safety-vulnerabilities/)

Je wilt toch niet impliceren dat er bij Google prutsers werken aan Android?
En Google is niet de enige partij die 'Secure by design' inzet.
Nee, de industrie ziet het beter.

Het is wel jammer voor de hardwerkende consistente C-programmeur maar de focus wordt verlegd.
Maar vrees niet. Aan de kennis van een C-programmeur blijft altijd behoefte.