C en C++ zijn geen inherent onveilige programmeertalen, ze worden alleen regelmatig onveilig gebruikt.

De taal is niet het probleem, andere talen zoals bijv. Java of C# hebben wellicht niet de problemen die je met C/C++ hebt maar dat betekend niet dat ook die niet onveilig gebruikt kunnen worden.

You get so much slack with C/C++ it's easy to hang yourself.

Ik sluit me hierbij aan, hoewel het wel zo is dat het risico op fout gebruik redelijk hoog is.

Analogie: Nederlands correct schrijven is al een uitdaging ("dat betekend"...) ondanks een bekende set regels, laat staan dat programmeren foutloos zal gebeuren ;-)

"en veilig programmeren is nog lang geen begrip bij de grote softwarehuizen"

Dit is hét probleem en ook het enige probleem. Zolang men weigert om te leren van (andermans) fouten, zal er weinig veranderen. SQL injection is al decenia lang bekend, toch worden er nog steeds programma's geschreven met de mogelijkheid tot SQL injection. En dat heeft niets met de taal te maken, maar alles met het totale gebrek aan interesse in veiligheid. En dat geldt ook voor de klanten, die interesseert het ook al niks.

Ps. Helaas geldt dat niet alleen voor de grote softwarehuizen, de kleintjes maken er ook een puinhoop van.

C en C++ bieden programmeurs de vrijheid om te doen wat ze willen, zonder overbodige checks of dat wel zou moeten mogen. Daardoor zijn programma's in C of C++ vaak zoveel efficienter dan in andere talen. Dat programmeurs fouten maken waardoor die vrijheid een veiligheidsprobleem wordt, is niet de schuld van de taal maar van de programmeurs.

Nee, je dient mitigerende maatregelen te treffen zodanig dat het risico dat je loopt wordt verkleind. Dus goed de gebruikersinstructie volgen wanneer je die afkortzaag gaat gebruiken, zorgen dat je er met je aandacht bij bent als je dat ding gaat gebruiken, niet snel eventjes wat zagen zonder eerst logisch na te denken waar je in godsnaam mee bezig bent, geen "grapjes" uit gaan halen met een zaag en dat soort dingen.

Hetzelfde geldt voor programmeertalen, alleen is voor een succesvolle toepassing daarvan aanzienlijk meer kennis nodig dan het lezen van een gebruikersinstructie. Het vereist veel ervaring om te weten waar je echt mee bezig bent. Het vereist constante bijscholing in de nieuwste aanvalsvectoren. Het vereist kennis van tools die je kunnen assisteren in het veilig(er) maken van je code. En die kennis wordt op een of andere manier niet goed bijgebracht, wordt niet aangeleerd of wat dan ook. C/C++ maakt onveilig programmeren makkelijk voor onbekwame programmeurs. En daar lopen er helaas nogal wat van rond op deze planeet.

Het alternatief voor C/C++ is eigenlijk Pascal en Object-Pascal. Zo'n 30 jaar geleden was Pascal een vrij belangrijke programmeeurtaal en werden zelfs delen van bepaalde besturings-systemen in Pascal ontwikkeld. Dat, en Assembly natuurlijk, maar Assembly is nog "gevaarlijker" dan C of C++. En Pascal was (en is) een stuk beter bestand tegen buffer overflows dan C of C++ terwijl de taal eigenlijk vrijwel net zo stevig is als C en C++. (Hoewel dit deels afhangt van de gebruikte compiler.)
Alleen is C net iets meer low-level dan Pascal en daardoor iets flexibeler en werd C vrij populair om besturings-systemen mee te schrijven. Assembly en C gingen op dat gebied aardig concurreren en C won de strijd uiteindelijk. Pascal werd vervolgens nog wel ondersteund binnen die ontwikkel-omgevingen maar waarom zouden mensen nog een aparte Pascal compiler gebruiken als ze al een C compiler hebben? Nu werd Pascal wel gebruikt voor de CDC 6000 mainframes voor het schrijven van het besturings-systeem maar het heeft het nooit kunnen winnen van C op dat gebied. De extra beveiliging die de taal biedt en dus veiliger maakt zijn nou precies die dingen die ontwikkelaars liever kwijt waren om zo een betere performance te behalen.
Maar dan moet je wel weten wat je doet en tegenwoordig zijn veel programmeurs best slordig in hun programmeerwerk.

Pascal is vroeger ook populair geweest op Apple computers, hoewel ook daar uiteindelijk die positie door C is overgenomen.

En bedenk wel dat de kwaliteit van de software uiteindelijk sterk afhankelijk is van de kwaliteiten van het team dat deze software ontwikkelt. Ieder software-product heeft bugs, maar de slimmere ontwikkelaars zorgen ervoor dat de schadelijke bugs als eerste worden opgelost. Jammer genoeg zijn die vaak ook tijdrovender dan de rest, waardoor de productiviteit hoger lijkt indien je eerst alle eenvoudige, onbelangrijke bugs oplost. Management heeft vaak liever dat het team productief lijkt dan dat ze problemen oplossen.

Peter Vreugdenhil maakt me aan het lachen. Met zijn redenatie is iedere taal onveilig - zelfs een auto of baksteen. Het is maar net hoe je met de parameters van de gebruiker gaat spelen die de taal en beveiliging 'machtig' is. Het is dus ook eenvoudig om als beveiliging 'expert' denkfouten te maken over de oorzaak van een probleem. Schoenmaker blijf bij je leest - richt je op het zoeken naar problemen in programmatuur en een mening ernaast is verder vooral leuk. Of geef aan dat de redactie het verhaal iets teveel uit context hebben getrokken :) Nothing personal.

Wat een onzin opmerking. De taal is niet het probleem, de programmeur is het probleem:

Een goede programmeur kan in elke taal goed programmeren...

De toegankelijk van een taal kan ervoor zorgen, dat mensen die niet goed kunnen programmeren, zelf code gaan ontwikkelen, met alle gevolgen vandien... Dat wil niet zeggen dat het niet handig is dat een taal makkelijk toegankelijk is, maar in dit geval heeft dat voordeel ook een eventueel nadeel.

Het percentage goede programmeur is een (kleine) constante. Met de toenemende automatisering neemt het absolute aantal programmeurs toe, dat betekent dus ook dat het aantal slechte programmeurs ook dramatisch toeneemt...

GELUL !!! C++ is 1 van de beste talen ooit. Het zijn de programmeurs die het slecht gebruiken.

Iets teveel onnozele reacties hierboven. Het is erg makkelijk fouten te maken in C. Geen enkele C programmeur kan dat voorkomen. Als je denkt dat dat wel kan ben je hoogst waarschijnlijk geen programmeur. En als je dat wel bent, dan ben je zeer arrogant.

Een voorbeeldje: in C kun je eenvoudig geheugen aanspreken die je niet gedeclareerd hebt of die buiten het bereik van de variabele valt. C is dus intrinsiek onveilig. Een veilige taal zal zoiets niet toestaan.

Ik zal Theo de Raadt eens vertellen dat hij verkeerd bezig is met C. Omdat het zo'n "onveilige programmeertaal" is.

"C en C++ zijn geen inherent onveilige programmeertalen, ze worden alleen regelmatig onveilig gebruikt."
Ik sluit me hierbij aan.

Onveilig programmeren is altijd mogelijk, dit is is inherent aan de functionele werking van computers. Deste beter de vaardigheden van een programmeur, deste veiliger de software (over het algemeen). Programmeurs die geen rekening houden met b.v. stopproblemen of andere basic punten in computing theory, zullen software schrijven met basale fouten.

Kennis over de werking van hardware, is een must!

Het is juist arrogant om te denken dat dit door C komt, het komt doordat de programmeur een mens is en mensen fouten maken. Geen enkele programmeur is onfeilbaar, dat wordt ook niet beweerd. De bewering van de "onnozele reacties" is dat het onjuist is de fout bij de taal te leggen en niet bij de (slechte/menselijke) programmeur...

En jij bent waarschijnlijk geen programmeur door te denken dat het aan de taal ligt...

Trouwens http://vreugdenhilresearch.nl/about/:
Nogal aparte uitspraken voor iemand die met Perl werkt, want in zijn gedachtengang kan ik dan ook wel even een boekje open doen...

C en C++ zijn low level programmeertalen.

Hoe lower hoe voorzichtiger je moet zijn als programmeur.

C++ wordt veel gebruik omdat Microsoft de spijker precies heeft kunnen slaan met Visual Studio waarbij C++ de perfecte middelpunt tussen C en bijvoorbeeld C# of Java

Het zijn vooral de code generators die C code kunnen generen die fouten maken.

C en C++ zijn juist high level talen, low level is assembly en machinecode. Ga uit mijn gazon.

Tevens, lijkt alsof niemand weet heeft van een stack smashing protector. Zowel gcc als cl hebben het al jaren, dat is de echte WTF van dit artikel. Meneertje "beveiligingsexpert en hacker" is dus te beroerd om "man gcc" te lezen. Gelukkig voor hem spreekt LulzSec geen Nederlands.

Je kunt met een compiler ook security checks doen om verschillende programmeer fouten aan de kaart te stellen.

Verder heb je verschillende tools om codes te analyseren naar fouten.
http://www.dwheeler.com/flawfinder/#othertools

M$ heeft zelf goede tools om hun eigen code te testen de laatste 3 jaar. Dit zie je terug in win7 / office en essentials programma's.

Code-generatie gebruik je juist om fouten te voorkomen omdat het dan code betreft die vaak nogal hetzelfde is.
Wanneer die gegenereerde code fouten bevat hoef je alleen de generator aan te passen en de code opnieuw te genereren.
Wanneer je dus niet goed nadenkt over die generatoren, ben je alsnog fout bezig.
Dat heeft niets te maken met gegenereerde code, maar alles met het niet beheersen van je tools.

Met programmeren moet je altijd goed nadenken en het helpt wanneer je een goede library-set hebt kan dat helpen bij het voorkomen van fouten.
Zo hebben wij op het werk zelfgemaakte autopointers die netjes opgeruimd worden wanneer ze uit scope gaan. Dus geen memory-lekken meer bij dingen die op de heap gemaakt worden. En Smart pointers die opgeruimd worden wanneer alle referenties naar het object verbroken zijn. Die zaken zijn thread-safe en besparen een hoop problemen. Op deze manier kun je ook problemen voorkomen met null-pointers of pointers naar objecten die al gedestruct zijn.
Wanneer je gewone C-arrays gebruikt heb je geen bound-checking, maar die heb je wel bij gebruikt van std::vector.
Performance-wise scheelt het heel weinig, zolang je maar goed nadenkt over allocatie van geheugen. Allocatie kost namelijk tijd, dus re-allocatie ook.

Verder moet je in je tools ook zaken inbouwen die in debug wel basis-zaken testen in runtime, zodat je ze tijdens eigen tests al tegen komt.

Voor elke beroep geldt: Leer met je tools te werken en zorg dat je tools ook goed zijn.
Als je niet aan bound-checking doet, geen user-input checkt, noch gestructureerd alloceert en destruct, dan kun je beter helemaal niet gaan programmeren.
Doe het goed, of doe het niet. Er zit IMHO niets tussen wat acceptabel is.


Oh en nog een opmerking naar de redactie van deze site:
Aanmelding en bijhouden van wie ingelogd is, is een goed voorbeeld hoe het niet moet.
Uurtje geleden ingelogd, tussentijd een telefoontje gehad en bij het posten was ik weer niet ingelogd en bijna nog mijn posting kwijt ook. En dat terwijl ik inlog met "blijf maand ingelogd".

no shit sherlock ! n00bs !!

Ik zal de fout in jouw redenering uitleggen aan de hand van een eenvoudig voorbeeldje.

Het is 2011 en Piet werkt in een zagerij. Piet zaagt elk uur 30 stukken hout met een moderne zaag van goede kwaliteit. Op een dag komt Piet op zijn werk en ziet dat de zaag is vervangen door eentje van 70 jaar geleden, zonder beschermkap. Piet haalt zijn schouders op en gaat ermee aan de slag. Tevreden constateert Piet dat het een stuk sneller gaat dan met die andere zaag. Maar plots zaagt Piet een paar vingers eraf, als zijn hand te dicht bij het blad komt. Het was natuurlijk Piet's eigen schuld. Het komt immers niet door die oude onveilige zaag.

Voor zover ik weet gebeurd dat niet meer dan bij andere sites. Maar daar zit het probleem ook niet.

Dat gebeurd mij regelmatig als ik via m'n werk inlog. Komt waarschijnlijk door de proxy die er tussen zit. Thuis heb ik er nauwelijks last van.

Ik heb het op mijn werk elke ochtend dat ik in moet loggen. Zal wel iets met cookies of zo zijn. Het is inderdaad wat lastig want als je opnieuw inlogt ben je inderdaad je bericht kwijt. Dat overkomt je maar één keer ;)

OT: Ik vind het wat kort door de bocht om de onveiligheid bij de taal neer te leggen. Ik denk wel dat het een dermate hoog niveau vereist om 'veilig' te kunnen werken dat het wel tijd wordt voor een alternatief. Dat hoeft niet perse een alternatieve taal te zijn, maar bijvoorbeeld standaard je programma in een zandbak onderbrengen zodat jouw fouten niet het geheel kwetsbaar maakt.

Jouw voorbeeld onderstreept juist mijn bewering. Als Pietje niet kan werken (slechte zager, want hij weet niet hoe hij er mee moet omgaan) met die oude zaag, dan is het zijn eigen schuld als ie zijn vingers afzaagt...
Een goede zager zou namelijk, of weten hoe hij met zo een zaag werkt, of eerst leren/lezen hoe je met zo een zaag werkt, om te voorkomen dat hij zijn vingers afzaagt. Als je niet oppast zaag je ook met zo een "moderne" zaag je vingers er af.
Dus onzin voorbeeld. Als je niet kunt zagen moet je er ook niet aan beginnen, laat het zaagwerk dan aan experts over...

Dat mensen fouten maken hoeft geen probleem te zijn. Zolang ze de tijd krijgen om hun code goed te testen. Maar alles moet snel af want programmeurs kosten veel € per uur, en als iets uitloopt krijgt de tester minder tijd.

Testen zorgt er niet voor dat fouten verdwijnen. Buffer overflow fouten zijn vaak zeer moeilijk op te sporen. Kijk maar naar Microsoft: hun software wordt uitgebreid getest, en er worden nog steeds fouten in gevonden.

Dus als piet met een andere zaag moet werken kan hij opeens niet meer nadenken & veilig werken ?.

Nadenken is ook een kunst.

Oh, dus de arbo erbij halen mag wel, maar schijnbaar niet dat Pietje geen opleiding heeft gehad voor het werken met oude zagen...
Dat je in een Cessna kan vliegen, betekent nog altijd niet dat je een Boeing 747 ook kan besturen...

Volgens jou logica is zelfs een kussen gevaarlijk, want je kunt er potentieel in stikken bij onvakkundig gebruik...

Vraag maar na bij de arbeidsinspectie of je die oude, lichaamsonderdelen verkortende zaag nog mag gebruiken nu er veiligere zagen zijn met beschermkap.

C mag dan onveilig zijn maar Java heeft een onveilige runtime waardoor deze de hele PC kwetsbaar maakt.

70 jaar geleden konden ze ook met die zaag omgaan zonder ledematen eraf te zagen, dat pietje dat nu opeens niet kan ligt aan de vaardigheden van pietje en niet aan de zaag.

Dom voorbeeld dus.