Beveiligingslekken ontdekt in MySQL database-server

The Register meldt dat onderzoekers van de Duitse firma e-matters beveiligingslekken hebben ontdekt in de database-server MySQL. Kwaadwillende krijgen hierdoor de kans om de server te laten crashen, eigen code uit te voeren of zonder wachtwoord in een account te komen. Ook zitten er nog twee andere bugs in MySQL's client library, een heap buffer overflow bug en een klein foutje waardoor crackers '\0' kunnen schrijven naar elk geheugenadres, aldus Stefan Esser van e-matters. Een patch om bovenstaande problemen op te lossen is sinds 12 december beschikbaar. Beheerders wordt geadviseerd om up te graden naar MySQL versie 3.23.54, waarin de problemen worden opgelost. Ook in PHP zit een kopie van libmysql, de bugs komen daar dus ook in terug. Meer informatie is hier te vinden:

Stefan Esser, of e-matters and the PHP.net project, has also unearthed two flaws within MySQL's client library (a heap buffer overflow bug and another glitch that allows crackers to write '\0' to any memory address) that can result in application compromise. [...] Both flaws could allow DoS [Denial of Service] attacks against or arbitrary code execution within anything linked against libmysqlclient, he warns.

Reacties (60)

Mischien off-topic maar ok

Bestaat er eigenlijk wel software die geen beveilingslekken heeft?

Vroeger in het 8 bit tijdperk toen software maar voor èèn type machine werd geschreven had je nog perfecte software.

Maar door de grote verscheidenheid van hardware en de complexe programma's is het bijna onmogelijk foutloze en geheel veilige software te schrijven.

Vroeger was men nog niet zo bezig met security, ten eerste had je geen internet of uberhaupt een netwerk. En de zx spectrum, c64 en andere diverse consoles hadden al virussen.

Ook in het modem tijdperk waren remote cracks van bbs'en heel erg in.

Zelf denk ik dat met de komst van de buffer overflow techniek(stack smashing) de exploits inderdaad gegroeit zijn omdat zo'n beetje elk programma daar wel een fout mee heeft.

Ik gebruik al jarenlang qmail en de auteur daarvan (DJ Bernstein) houdt bij hoog en bij laag vol dat zijn software secure is.

(Zie: http://cr.yp.to/qmail/guarantee.html )

Qmail wordt op heel veel plaatsen gebruikt en de $1500 beloning is nooit opgeeist.

Als je bij het schrijven de security voorop stelt is het blijkbaar wel mogelijk om veilige software te schrijven.

Mvg,
Xenna

Tja, het probleem met die veiligheidsgarantie:
Je compileert qmail met een compiler, die compiler kan ook bugs bevatten. Je compileert qmail met extra dingen als vpopmail, ook daar kunnen bugs in zitten.

Dat Dan beweert dat qmail foutloos is, wil niet zeggen dat je setup waar je qmail in gebruikt ook foutloos is. Nog niet te spreken over al die onofficiele patches die er rondzweven.

Het verschil tussen bugs en securitybugs lijkt mij in deze discussie toch wel belangrijk. Dat een 'bug' in een compiler een security-bug in de gecompileerde software veroorzaakt kan ik me moeilijk voorstellen al kan ik het natuurlijk ook niet uitsluiten. De discussie over de veiligheid van compilers werd volgens mij vooral gevoerd m.b.t. met opzet gemaakte trojan-versie van compilers. En ja, die kunnen een veilig stuk software omtoveren tot een gatenkaas.

Patches op qmail kunnen natuurlijk ook weer gaten creeren. Theoretisch veilige software bestaat waarschijnlijk niet, maar dat iemand zo'n guarantee durft te geven en daar 5 jaar aan vast kan houden geeft wel aan dat het een stuk veiliger kan dan de makers van Apache, ssh, en mysql tot dusver hebben laten zien..

Mvg,
Xenna

Gezien de omvang van de source en het aantal developers denk ik dat MySQL en Apache httpd wel iets meer recht hebben op bugs dan qmail, SSH is wat discutabeler...

4 regels code bugfree schrijven kan bijna iedereen. Maar nu 4 miljoen, waarbij je naar een aantal miljoen codes linkt van modules, klassen en functies die je niet zelf geschreven hebt.... Zie dat maar eens secure te krijgen. Als ik me niet vergis linken MySQL, httpd en SSH allemaal weer aan SSL wat ze niet zelf geschreven hebben om maar een voorbeeldje te noemen.

Btw, Barnstein heeft ook een DNS server.

Yep, het Keep it Simple Stupid! principe geld hier ook weer.
Qmail is als vervanger bedoeld van sendmail wat een gigantisch gecompliceerd programma schijnt te zijn. Misschien is dat de definitie van een goeie programmeur, eentje die gecompliceerde problemen simpel weet te maken.

Ik gebruik trouwens de DNS caching software uit Bernsteins DNS server op iedere Linux server die ik beheer. Maakt servers sneller (door reverse lookups te cache) en stabieler (door afhankelijkheid van externe DNS servers te verminderen).

Mvg,
Xenna

Het schrijven van veilige software is wel mogelijk, echter er is bijna een lineair verband tussen functionaliteit en security. Het is dan ook niet vreemd dat er tegenwoordig meer bugs worden ontdekt aangezien men om steeds meer functionaliteit schreeuwt.

Ik denk niet dat je gelijk hebt.

Er is een oplopend verband tussen complexiteit en tijd. Er is een oplopend verband tussen complexiteit en kosten. Er is ook een oplopend verband tussen kosten en verkoopcijfers. Daarnaast is er nog een oplopend verband tussen verkoopcijfers en winst. En natuurlijk het overduidelijke AFlopende verband tussen winst en kosten.

Wil je goede verkoopcijfers halen, zul je veel moeten verkopen. Wil je goede winst halen, zul je zo min mogelijk kosten moeten hebben. Ergens moet er dus gesleuteld worden. Het makkelijkste wat je dan kunt doen is de kosten omlaag halen. Alleen zou dan de complexiteit omlaag moeten gaan. Maar dat kan natuurlijk weer niet zomaar, want dan gaan je verkoopcijfers omlaag. Wat je wel kan proberen is zorgen dat je minder tijd kwijt raakt aan dezelfde complexiteit.

Natuurlijk is er ook een verband tussen tijd en kwaliteit. Maar kwaliteit is duidelijk minder belangrijk. Ik heb vaak genoeg managers tegen programmeurs horen zeggen dat ze te lang bezig zijn met een bepaald onderdeel en dat het 'nou maar eens af moet zijn hoor'. Sterke programmeur als 'ie dan niet bij zichzelf denkt dat er bij het volgende functioneringsgesprek wel eens iets negatiefs over zijn prestaties verteld zou kunnen gaan worden als hij niet opschiet.

Aan de ene kant moet een programmeur veel beslissingen voor zichzelf nemen (zeker als een ontwerp slecht in elkaar zit), aan de andere kant wordt hij opgejut omdat tijd=geld. Sja, dat is een recept voor disaster.

Goed zeg! Ik heb nog niet eens Microsoft genoemd, die toch wel de trendsetter in deze is geweest. 'Software is zo goed als het platform waarop het draait'. Als het om geld draait wordt dat al snel omgedraaid: 'Software moet niet beter zijn dan het platform waarop het draait'. Anders stop je er te veel geld in.

Damn, nou heb ik toch weer Microsoft erbij gehaald .

Ik heb heel wat problemen gehad met het optimaliseren van de kwaliteit van mijn code naar de kosten ervan toen ik van CD-i programmeren naar Windows programmeren overstapte. Ik heb in het begin aardig vaak te horen gekregen dat het allemaal te veel ging kosten omdat het te lang duurde. Sja, mijn programma's *bleven* maar crashen, ik vond telkens wel weer een nieuwe manier om mijn programma en zelfs heel Windows onderuit te halen.

Bij CD-i werden we gedwongen om kwaliteitssoftware te maken. Elke titel moest naar Philips opgestuurd worden, en die gingen het daar nog eens grondig zelf zitten testen. Vrijwel geen buggy software op CD-i te vinden...

Gelijk heb je RetepV, er zit echter nog meer aan vast.

Niet alleen het OS moet goed ontwikkeld en kwalitatief hoog zijn. Dit gaat op voor ALLE libraries, componenten en andere herbruikbare code die gebruikt worden in een project. All deze vormen van herbruikbare code (net als het OS) hebben een sneeuwbal effect. Een fout aan de bron, een OS, library of component heeft immers veel grotere gevolgen dan die van een end user applicatie.

En dan heb ik nog niet eens compilers genoemd en ander ontwikkelsoftware of databases. Hier zitten vaak ook gigantische hoeveelheden bugs in. Heb ik al cusussen genoemd die ook geen goede ontwikkel praktijken bevoorderen?

Kortom de kwaliteit van de ontwerpers en ontwikkelaars bij deze toch zeer essentiele basis onderdelen van onze informatie maatschapij is ver beneden pijl.

En met de winsttekens in de ogen zullen leidinggevenden inderdaad niet snel een ervaren ontwikkelaar in dienst nemen, omdat dat gewoon te duur is. Natuurlijk houden ze zichzelf hiermee voor de gek, maar het gebeurd gewoon door korte termijn denken en snel winst boeken.

Veel mensen hebben de instelling (en worden er nog voor beloond ook) van:

Als ik nu een euro kan besparen en de veel grotere kosten die dat verder met zich meebrengt in het grotere geheel zijn voor een ander, dan doe ik dat. Dit heet economische optimalisatie (ofwel kortzichtigheid).

Dit alles werkt samen om alles kwalitatief laag te houden en zo goedkoop mogelijk te produceren. Kortom een verspillende millieu vernietigende en rechtongelijkheid bevorderende samenleving. Waarbij de mensen met de kleinste ballen en de grootste hebberigheid en het minste verstand worden beloond (ten koste van alles en iedereen).

Geloof me, we zijn dom bezig in IT land, het is vrijwel geheel gekaapt ven verkracht door mensen die niets van IT afweten en alleen uit direct eigen belang handelen.

Het is een flinke stap om van software bug over te stappen naar zulke zware uitspaken. Maar als je de oorzaak/gevolg keten volgt en enige kennis van software ontwikkeling hebt, dan zal je op ongeveer dezelfde niet zo fijne concusie komen.

Wat betreft buffer overruns, het is gewoon ongelooflijk dat deze nog steeds voorkomen. Met gewoon defensief programeren waar o.a. het gebruik van objecten voor arrays e.d. thuishoren kun je deze fouten onmogelijk maken! Het fijt dat ze nog voorkomen bewijst dan ook het amateurisme dat we in IT land zien. Het is elders ook het geval hoor, maar meestal zijn de gevolgen daarvan minder groot.

Als men klooit bij een energie of waterleiding bedrijf dan heeft dat grotere gevolgen dan dat een monteur een kraan niet goed heeft afgesloten in een keuken van een huis.

Kortom kwaliteit moet ten alle tijden voorrang krijgen en weg met all dat korte termijn denken en het ike ike ike, hebbe hebbe hebbe.

Goed is goed genoeg is een typische kortzichtige uitlating die je vaak hoort van lijdinggevenden. Aangezien zij helemaal niet kunnen beoordelen of iets goed is en ook langer goed zal blijven werken evolueert deze gedachtengang naar: Half af is goed genoeg om te verkopen.

Genoeg nu, ik loop weer veel te rood aan!

Evenzo claimt Donald Knuth al jaren dat er geen bugs in TeX zitten. Als je er eentje vind, kan je geld krijgen. Zie z'n homepage.

Gelukkig is niet iedere bug een security bug, want anders was het helemaal slecht met ons gesteld! ;-)

Mvg,
Xenna

Veel problemen kan je al voorkomen door een taal te gebruiken die de programmeur helpt bij het voorkomen van veel voorkomende fouten. Veel moderne talen garanderen bijvoorbeeld dat er nooit een index wordt genomen van een array die helemaal niet bestaat. Ook garanderen zeer veel talen dat er nooit een illegal operatie uitgevoerd kan worden op waarden van een bepaald type.

Als je dus gebruik maakt van talen als C# en Java bespaar je jezelf al een hoop moeilijkheden. Uiteraard kan je nog steeds een hoop verkeerd doen . Veel gebruikte software op basis van C# of Java ontbreekt echter nog: het gaat vaak om software waar al jaren en ontwikkeld wordt of waarvan men denkt dat men met C#/Java niet aan de performance eisen kan voldoen. Er wordt daarom nog vaak C/C++ gebruikt en deze talen bieden veel ongure constructies en controleren vrij weinig. Er kunnen hierdoor hele rare zaken gebeuren als je niet goed weet waarmee je bezig bent. Uiteraard een beetje goedkoop om de taal de schuld te geven, maar een taal die meehelpt scheelt in ieder geval een stuk.

Helaas is met het automatisch signaleren van een array overflow je probleem niet helemaal opgelost. Als ontwikkelaar moet je wel op de mogelijkheid van een overflow blijven anticiperen zodat je voor een goede foutafhandeling kan zorgen. Zomaar een programma afsluiten kan weer andere nare gevolgen hebben natuurlijk.

Punt is dat de programmeur altijd de zaak onder controlle moet hebben. Alle hulpmiddelen zijn daarbij welkom, maar zoals vaak geroepen wordt (zeker bij java en .net en scripttalen) is dat bv garbage collection (GC) zorgt dat geheugen problemen oplost doordat gebeugen vanzelf vrijkomt e.d.

Hierdoor besteed men geen aandacht aan het op de juiste tijdstippen vrijgeven van essentiele resources. Ook ondersteunen deze talen niet de meest veilige vorm van programeren, nl, object transacties d.m.v. scoping en destructors (oorzaak GC).

Kortom, talen als java en C# halen de controle over de van kwaliteit juist weg bij de ontwikkelaar. Het zorgt voor een vals gevoel van veiligheid en het aantal fouten die gemaakt worden door een gemiddelde ontwikkelaar neemt daarmee toe. Zeker bij de complexe projecten.

Zaak is alles goed te modelleren en defensief te programeren en veel gebruik te maken van scoping en destructors voor het opruimen van rescources (dus niet alleen geheugen). Dit vergt dicipline, maar dat is niet onbegrijpelijk. Het bouwen van een complexe machine verijst dit immers ook, dus dat is niet zo bijzonder.

Wat dus zo kwalijk is aan talen met standaard veiligheids features is dat ze veiligheid niet garanderen en onveilige programeerstijlen aanmoedigen. Een ervaren ontwikkelaar kan in al deze talen goede kwaliteit software afleveren, maar waar het ogenschijlijk makkelijker wordt gemaakt voor beginnende ontwikkelaars, daar wordt het een ervaren onwikkelaar juist moeilijker gemaakt.

Dus welke aanpak denk je nou dat op lange termijn en met oplopende complexiteit in programm's een betere aanpak is?

Juist talen zonder 'wonder' features in combinatie met goede tools, libraties en een veilige programeerstijl (onderwijs).

Er is een beter alternatief voor GC, en dit kan alleen in talen met echte destructors geimplementeer worden. Dit alternatief is gebruik van scoping in combnatie met objecten die destructors gebruiken voor het vrijgeven van geheugen en andere resources.

Dus wat is dit nu precies? Ik zal een zo klein mogelijk voorbeeld geven en verwacht wel wat inbeeldings vermogen van jou kant om dit verhaal niet overbodig complex te laten worden.

Voorbeeld van scoping:

int foo()
{
CFile oTestfile

if ( !oTestfile.opne( "filenaam.txt" ) )
{
// melding van niet kunnen openen bestand
}
else
{
// **** belangrijk ****
// een hele berg code die hier van alles naar het file object scrijft.

if ( !oTestfile.close() )
{
// er is een fout opgetreden in het volledig wegschrijven en afsluiten van het bestand
}
}
}

Ik hoop dat je wat can C++ en scoping afweet, anders wordt het moeilijk uitleggen In ieder geval is er een fileobject met een destructor die de file netjes opruimt als er iets mislukt en een close methode die de file netjes aflsuit. Er kunnen immers nog gebufferde gegevens aanwezig zijn en die moeten ook weggeschreven worden (wat kan mislukken). Ook de filehandles worden met de close opdracht vrijgegeven en alle geheugen die voor het bufferen gealloceerd was.

Welnu, nadat het bestand met success is geopend wordt er van alles mee gedaan en als er een EXCEPTION of een normale RETURN plaatvind die uit de betreffende scope springt, dan zorgt de COMPILER dat er code uitgevoerd wordt die de destructor van het CFile object aanroept. Als dit gebeurd en de file is nog steeds open dan kan het object alle nodige handelingen uitvoeren om de file netjes af te sluiten of te vereijderen afhankelijk van het gewenste gedrag. Dus niet alleen geheugen, ook de file handle en eventuelre andere objecten die door de file gebruikt werden.

Ik zou er ook nog een CWaitCursor omheen kunnen gooien om zo te zorgen dat ALLEEN tijdens het schrijven naar het bestand een zandloper op het scherm verschijnd. Ook is het ineens eenvoudig om database en filesystem synchroon te houden. De compiler in combinatie met de code garandeerd dat alles perfect verloopt.

In complex programma's is het voor een ander vaak niet te overzien wat de consequenties van een bepaalde annpassing zullen zijn. Te veel details. Door de beschreven stijl van programmeren bescherm je je hiertegen en is het voor een vreemde aantoonbaar dat els hij iets lkeins aanpast in een productie versie van een programma er niet ineens vage dingen gaan gebeuren.

Het gebruik van object transacties d.m.v. scoping en object destructord maakt het mogelijk de compiler alle details van de code in te laten vullen zonder dat de programmeur control verliest over wat er wanner moet gebeuren. Dit laatste is nu net wat wel geveurd in jave en C#, en de enige reden daarvoor is garbase collection.

Garbade collection is in theorie leuk, maar doordat het zo incompleet en ver van de praktijk afstaat is het gedoemd te mislukken. Dat het ook een lakse manier van ontwikkelen stiumuleerd, daar ga ik niet eens met je over in discussie (heb ik te vaak in de praktijk zien gebeuren).

Nog even terug naar de manier waarop de bovenstaande voorbeeld pseudo code in een taal met Garbage Collection zou plaatsvinden:

Je zou met exceptions werken, en je bestand zou pas later op een onbepaald tijdstip in een soort van finaliser komen.

Het verschil is dat de destructior in een taal als C++ altijd op een precies beschreven moment plaatsvind en altijd in de omgekeerde volgorde van definieren binnen een scope.

Dit laatste is essentieel om als ontwikkelaar objecten te kunnen gebruiken die mogelijk zelfs van elkaar afhankelijk zijn en automatich hun rommel opruimen. Met Garbase collection moet je alle details zelf afhandelen, waarbij het er eigenlijk op neer komt dat wanneer je controlle nodig hebt om de garbage collector heen moet programeren.

Dit laatste is nu net wat de meeste ontwikkelaars fout zullen doen en waar de meeste vage bugs in in programma' gebaseerd of een GC last van zullen hebben. Deze vorm van fouten is is veel lastiger op te sporen dan alle andere bugs die er zijn (inclusief geheugen).

En in geval wan een CWaitCursor class hief je hoef je in C++ dus all helemaal geen close of iets dergelijks aan te roepen. In een taal met GC zal je dit ALTIJD moeten doen, simpelweg omdat je niet weet wanner de garbage collector het object zal opruimen en de finaliser zal aanroepen. Je moet in een CG gebaseerde taal in een hoop situalties MEER details afhandelen. Doe je dit niet dan is de kans erg groot dat jij precies diegene bent waar ik het over heb en onwetend allerlij vage bugs in je programma hebt zitten die nauwelijks reproduceerbaar zijn!

Ik heb in het verleden jarenlang in C++ met MFC classes gewerkt en heel simple contructies gebruikt om geheugen en resources automatisch en op het juiste moment vrij te geven. In all die jaren heb ik geen enkele keer een memory leak of dubbel vrijgegeven geheugen of andere meegemaakt.

Als je deze techniek in combinatie met arrays en andere basis programmeer elementen toepast dan heb een een veel robuuster resultaat dan met GC gebaseerde talen. En een ervaren ontwikkelaar hoeft dan ook niet langer tegen de taal en compiler te programmeren, maar wordt er door ondersteund!

Nou, dat is pas vooruitgang!

Voor de duidelijkheid:

C++ is geen C met een smaakje.
C++ is strong typed, en heeft veel OO features.

Ik ben ook een voorstander van decleratieve oplossingen omdat deze niet de controle uit handen geven, maar er wel voor zorgen dat de details foutvrij door een compiler of interpreter afgehandeld kunnen worden.

"Dus welke aanpak denk je nou dat op lange termijn en met oplopende complexiteit in programm's een betere aanpak is?"

Grappig "mbravenboer", je antwoord op de deze vraag daar kan ik mij geheel in vinden. Op het ogenblik gebruik ik ook geen C++ meer, maar voornamelijk XSLT en domein specfieke talen. Maar aangezien de meeste software hier NIET in ontwikkeld wordt, maar in talen als java, C#, VB en C++ denk ik dat mijn analyse toch relevant is. Ik zie in java en C# en VB eigenlijk ook wel niet de oplossing voor de problemen die men heeft gehad met C++. Mijn punt is dan ook dat je als ontwikkelaar met kennis van zaken er met java en C# dan ook alleen maar op achteruit gaat. Ze lossen niets op dat met een goede programeerstijl in C++ niet beter op te lossen is.

En zoals je aan mijn voorbeeld reeds zag heb ik jaren geleden in een taal als C++ al voolop decleratief ontwikkeld. De declareerd m.b.v. een scope wat de levensduur van een object is en hoe lang je bepaade functionaliteit (de waitcursor) actief wil laten zijn. Dit is heel simpel en voorkomt dat je je als ontwikkelaar met details bezig moet houden. Het is tevens opbouwend omdat je geen controle wegneemt, maar het naar een hoger abstractie nivo lift. Talen met GC bieden een halve oplossing en maken de rest van de cases moeilijker en foutgevoeliger.

Lol,

Met alle respect ik ontwikkel veel in XSTL, en XSLT is volledig decleratief. Maar de kern van 'decleratief; is dat je iets vooraf definieerd en dat dat verder door een compiler of interpreter afgedwongen wordt.

Ik heb wel degelijk ervaring met talen die 'zelf' geheugen vrijgeven wanneer het hun uitkomt. Bijna alle scripttalen hebben deze 'voorziening' en ik werk hier ook veel mee. En ik kan ook je vertellen hoe laks mensen hiervan gaan programeren en wat voor bugs hierdoor ontstaan. Gelukkig worden deze talen niet voor zware topassing gebruikt. Maar dit excuus gaan niet op voor java en C#!

Wat betreft GC en exceptions is het zo dat de ontwikkelaar in beide gevallen de details zelf moet afhandelen of kennis van de gebruikte objecten moet hebben wanneer hij dit na wil laten.

Ook dit is een probleem, aangezien men niet kan weten of een object onder water nog wat andere resources dan geheugen gebruikt. Dus of de ontwikkelaar moet alles doen wat een taal in C++ automatisch doet. Of hij moet kennis van de interne implementatie hebben van de objecten waarmee hij werkt.

Heeft een ontwikkelaar geen detail kennis over de implentatie van een object (zoals in OO gebruikenlijk, er zijn slechts interfaces) of als hij niet bij ieder object dat hij gebruikt een close method aanroept (zoals M$ adviseert voor .net) dan loop je het risico op onverklaarbare en onrepoduceerbare fouten.

Voorbeeld is een object dat als bijwerking bestanden lockt (implementatie). Als dit object nog niet is vrijgegeven, maar het object is conceptioneel wel uit de scope, dan zal bij een volgende iteratie in een lus dat weer dit bestand probeerd te locken een deadlock of een error ontstaan. Deze deadlock gaat pas over als the GC het eerste object heeft opgeruimt.

Kortom de programeur moet in de praktijk meer details afhandelen en ook nog eens meer kennis van de interne werking van objecten hebben. Dit laaste is nu net wat OO moet voorkomen, dmv abstactie en interfaces.

OO en GC zijn elkaars vijanden wat betreft imperatief programeren! Wat betreft je argument dat het vreemd is dat dit nu allemaal net in de nieuwste generatie talen gebruikt wordt het volgende.

De talen markt en aanverwante tools wordt zuiver gedreven door commerciele belanngen. Dit geld zowel vor java (sun) als voor .net (M$). Beide verdienen goud aan het uitbrengen van hun eigen talen en de daaraan gekoppelde tools en cursussen, etc.

Is C++ perfect? Nee, helemaal niet, maar wat nu in deze 'nieuwe' talen geintroduceerd is plaats on alleen maar verder van een werkende oplossing en niet dichterbij. Een reden waardoor het soms anders kan lijken is doordat er ondertussen zoveel meer herbuikbare code is. Er zijn bijvoorbeeld mensen die een eigen browser maken en alleen maar een IE BRowser control of een form hebben gesleept. Ik bedoel maar, het is allemaal zo moeilijk in te schatten voor mensen! En dus volgen ze allemaal braaf het pad dat door de grote parijen is uitgezet!

Deze dagen hou ik mij vooral bezig met architectuur en ontwikkel ik allen nog maar gelaagd en dus met verschillende talen tegelijkertijd (DHTML, javascript, vbscript, COM, SQL, maar wel gescheiden gelukkig).

Maar ik kun je vertellen dat wat betreft dat transactie gericht denken en gebruik maken van scoping alle talen een puntje kunnen zuigen aan C++. En dit in combinatie met sober OO gebruik levert in mijn ogen dan ook de meest betroubare code op. Niets verstokt dus, maar ik mis die tijd wel ja. Goed mee in de vaart der volkeren en hopen dan M$ en sun er een niet nog grotere puinhoop van gaan maken. Ik vertik het echter om achter iedere nieuwe mode aan te hollen en alles wat ik met zekerheid weet door dom commercieel gebrabbel to laten overschreewen.

Hoeveel jaar programeer ervaring had je ook al weer? Vast niet meer dan 18

Helaas is met het automatisch signaleren van een array overflow je probleem niet helemaal opgelost. Als ontwikkelaar moet je wel op de mogelijkheid van een overflow blijven anticiperen zodat je voor een goede foutafhandeling kan zorgen. Zomaar een programma afsluiten kan weer andere nare gevolgen hebben natuurlijk.

Inderdaad moet je het probleem nog wel opvangen, maar een exception (ook al zorgt die voor het stopzetten van een opdracht of zelfs de hele applicatie) is in ieder geval aantrekkelijker dan ongedefinieerd gedrag. Juist deze onvoorspelbare situaties zorgen voor security problemen. Exceptions zorgen voor zonder goede foutopvang voor taken die niet uitgevoerd worden. Ik weet persoonlijk wel waar ik de voorkeur aan geef.

maar zoals vaak geroepen wordt (zeker bij java en .net en scripttalen) is dat gebeugen vanzelf vrijkomt e.d.

Tja, wil je beweren dat dit niet zo is? Uiteraard moet je echter wel zorgen dat er geen onnodige objecten maar bereikbaar zijn. Dat is een nieuw probleem waarmee programmeurs rekening moeten houden, maar naar mijn mening is dit een minder complex probleem dan het expliciet vrijgeven van elk stuk geheugen.

Kortom, talen als java en C# halen de controle over de van kwaliteit juist weg bij de ontwikkelaar. Het creeert een vals gevoel van veiligheid en het aantal fouten die gemaakt worden door een gemiddelde ontwikkelaar naamt daarmee allen maar toe. Zeker bij complexe projecten.

Ik ben benieuwd of je dat kan onderbouwen met onderzoeksresultaten. Inderdaad: je moet nog steeds weten waarmee je bezig bent, maar wat je hier beweert komt nogal vreemd over. Iedereen in het programmeertalen onderzoek zal je vertellen dat zaken als array bounds checking vanzelfsprekend zouden moeten talen in niet-systeem talen. Iedereen zal je ook vertellen dat garbage collection een goed iets is. Iedereen zal je vertellen dat sterk getypeerde talen een goede zaak zijn.

Wat dus zo kwalijk is aan talen met standaard veiligheids features is dat ze vijlig heid niet garanderen en onveilige programeerstijlen aanmoedigen.

Je wilt toch niet beweren dat een taal als Java/C# een onveiliger programmeerstijl aanmoedigt dan C? Java beperkt de programmeur juist tot een bepaalde stijl van werken en deze stijl is in ieder geval niet de onveilige stijl. Juist het toestaan van alles wat God verboden zou hebben als de computer in de tijd van Mozes al bestond, is toegestaan in C. Geen probleem: elke taal heeft zijn toepassing, maar je moet er geen applicaties op een hoger level in gaan implementeren. Bij declaratieve programmeertalen zie je dit nog veel sterker: hierbij houd je je helemaal niet meer bezig met een bepaalde executie, maar specificeer je slechts wat er moet gebeuren. Dit promoot wellicht ook een onveilige programmeerstijl?

Dus welke aanpak denk je nou dat op lange termijn en met oplopende complexiteit in programm's een betere aanpak is?

Dat is een interessante vraag. Ik denk declaratieve en domein specifieke programmeertalen: je abstraheert van irrelevante details en houd je bezig met het echte probleem. Hiermee verlaag je de complexiteit en verplaats je het hoe probleem voor een deel naar de compiler. Helaas is dit nog niet zo realistisch omdat de huidige generatie programmeurs volledig imperatief wordt opgevoed. Code generatie vanuit domein specifieke talen en specificaties kan wellicht een belangrijke rol spelen in de komende jaren: veel mensen zijn ermee bezig en praten erover. Ik geloof in ieder geval niet dat talen als C en C++ op dit moment met wat voor taal dan ook nog een bijdrage kunnen leveren aan het verlagen van complexiteit en het vergroten van de zekerheid van applicaties.

Uiteraard zijn er nog meer dan genoeg toepassingen van talen als C, maar het schrijven van hogere applicaties is daar zeker geen onderdeel van.

Wat dus zo kwalijk is aan talen met standaard veiligheids features is dat ze veiligheid niet garanderen en onveilige programeerstijlen aanmoedigen. Een ervaren ontwikkelaar kan in al deze talen goede kwaliteit software afleveren, maar waar het ogenschijlijk makkelijker wordt gemaakt voor beginnende ontwikkelaars, daar wordt het een ervaren onwikkelaar juist moeilijker gemaakt.

Dat ben ik niet met je eens en ik begrijp ook niet hoe je die conclusie kunt trekken. Een taal die je 'alles' laat doen is krachtiger en daarmee inherent gevaarlijker dan een taal die bepaalde constructies uitsluit.

Denk maar eens aan de heerlijke dingen die pointers in C ons gebracht hebben: een constructie die veel mogelijk maakt, maar ook veel fouten veroorzaakt, juist omdat vaak moeilijk te volgen is wat er nu precies gebeurt.

Met de toenemende complexiteit van software is het voor een programmeur ook steeds moeilijker om het alles tot in detail te overzien. Het helpt dan ook als je niet alles tot in detail hoeft te regelen, maar daarbij door een taal geholpen wordt.GC in Java vind ik persoonlijk een zegen. Het werkt behoorlijk goed en een complete categorie van programmeerfouten veroorzaakt geen problemen meer. Ik vind dat een duidelijk pluspunt.

Je hebt gelijk als je zegt dat een goede programmeur in elke taal een behoorlijk stuk software moet kunnen bouwen, maar met de al genoemde toegenomen complexiteit _en_ de gevraagde hogere produktiviteit is het nodig om talen te gebruiken waarbij de 'basis' aanwezig is en niet meer uitgeschreven hoeft te worden. Vergelijk het maar met de enorme hoeveelheid aan libraries die er beschikbaar is. Waarom het wiel uitvinden als je gratis een Formule 1 auto van FreshMeat kan halen?

Dta je in 'moderne' talen bepaalde dingen niet meer kan doen en er daarom geen fouten van dat type in kan maken is een voordeel. Dat is ongetwijfeld in sommige situaties een nadeel, maar zoals Johan Cruijff al zei: Elk voordeel hep se nadeel.

Er is een beter alternatief voor GC

Het lijt mij dat lokale scope niet bepaald een alternatief genoemd kan worden is voor garbage collection.

Welnu, nadat het bestand met success is geopend wordt er van alles mee gedaan en als er een EXCEPTION of een normale RETURN plaatvind die uit de betreffende scope springt, dan zorgt de COMPILER dat er code uitgevoerd wordt die de destructor van het CFile object aanroept.

Het lijkt mij dat try-catch-finally hiervoor uitstekende voorzieningen biedt in Java en C#.

Garbade collection is in theorie leuk, maar doordat het zo incompleet en ver van de praktijk afstaat is het gedoemd te mislukken.

Toch vreemd dan dat garbage collection al enkele tientallen jaren wordt gebruikt in vele verschillende programmeertalen, dat garbage collection een standaard onderdeel is van twee van de belangrijkste ontwikkelplatformen van dit moment: de .NET CLI en het Java Platform. Ik ben benieuwd wat je aan garbage collection nu eigenlijk incompleet vindt en waar je aanwijzingen ziet dat het fenomeen garbage collection aan het falen is.

Ik denk dat jij heel erg ervaren bent in het ontwikkelen in talen zonder garbage collection. Zodra je in een taal komt met garbage collection terecht komt schrik je je te pletter omdat de hele wereld er plotseling heel anders uit ziet. Dat jij zelf niet snel je weg kan vinden in deze wereld wil echter niet zeggen dat er iets mis is met deze wereld: je kan beide opties pas echt goed vergelijken als je zeer ervaren bent in beide opties.

C++ is strong typed, en heeft veel OO features.

Het spijt me, maar C++ is niet sterk getypeerd.

Ze lossen niets op dat met een goede programeerstijl in C++ niet beter op te lossen is.

En dat is nu juist het punt: een C++ programmeur moet beschikken over een goede programmeerstijl. Talen als Java en C# dwingen deze programmeerstijl af doordat er simpelweg geen andere mogelijkheid is.

En zoals je aan mijn voorbeeld reeds zag heb ik jaren geleden in een taal als C++ al voolop decleratief ontwikkeld.

Ik ben bang dat je dan niet goed begrepen hebt wat ik met declaratief programmeren bedoelt. Het gaat daarbij niet om variabele declaraties, maar om niet imperatieve talen zoals bijvoorbeeld Haskell en XSLT.

Met alle respect

Dat scheelt .

ik ontwikkel veel in XSTL, en XSLT is volledig decleratief.

Zeker, je hebt mij ook absoluut niet zien beweren dat dat niet zo is .

Maar de kern van 'decleratief; is dat je iets vooraf definieerd en dat dat verder door een compiler of interpreter afgedwongen wordt.

Declarativiteit heeft niets met afdwingen te maken. Declarativiteit is echter wel een zeer slecht gedefinieerde term in de informatica, dus verwarring rond deze term is goed te begrijpen . In een declaratieve taal specificeer je niet hoe iets moet gebeuren (waarbij het hoe slaat op termen van computer instructies), maar wat er moet gebeuren. Je specificeert dus een bepaalde berekening en beschrijft niet een bepaalde uitvoering zoals in imperatieve talen. Je opmerking dat je in C++ al tijden declaratief programmeurt is dus een beetje merkwaardig. Op zich kan je in C++ best een bepaalde stijl aan houden die je een declaratiever gevoel geeft: het is niet voor niets een slecht gedefinieerde term .

De discussie over GC vind ik tamelijk zinloos worden: de standpunten zijn wel duidelijk .

Het lijt mij dat lokale scope niet bepaald een alternatief genoemd kan worden is voor garbage collection

Lokale scope is idd. geen alternatief voor GC, maar een van de elegantste concepten van C++, door Stroustrup beschreven als 'resource allocation is initialization' ontbreekt toch wel in java. try-catch-finally is een mogelijkheid, maar vergt meer discipline van de programmeur.
Vergelijk het met synchronizatie in java:
synchronized (myLock) {
// critical section
}
is veel 'mooier' dan een alternatief met try-catch-finally:
mutex.acquire();
try {
// critical section
} finally {
mutex.release();
}

Voor synchronisatie kon het wel in java, waarom niet voor ander types van resource allocation?
Misschien brengt Aspect Oriented Programming daar wel een oplossing?

Anderzijds vind ik GC en andere beveiligingen in java een zegen. Natuurlijk moet men rekening houden met de beperkingen, maar geef me toch liever een taal die GC ondersteunt en dus de 'eenvoudige' problemen al ten dele oplost.

We agree to disagree then

Veel moderne talen garanderen bijvoorbeeld dat er nooit een index wordt genomen van een array die helemaal niet bestaat. Ook garanderen zeer veel talen dat er nooit een illegal operatie uitgevoerd kan worden op waarden van een bepaald type.

Een moderne taal als Pascal bedoel je.
(bijna 30 jaar oud ondertussen)

Inderdaad, des te schokkender dat nog steeds een groot deel van de security problemen hierdoor wordt veroorzaakt .

Das onzin, ook toen had je bugs/flaws en wholes. Echter door de komst van het internet krijgt het meer publiciteit, plus dat er vroeger veel minder aandacht naar security uitging, dit omdat de meeste systemen toch niet aan een open netwerk waren gekoppelt.

Wat jij noemt zijn wel goede punten, maar er is veel meer. De software is veel complexer geworden, software is big business en dus hebben economen meer in te brengen dan technici, de kwaliteit van programmeurs is heel erg afgenomen (tegenover elke expert die zijn eigen compiler programmeert, of een grafische engine in assembler, staan tegenwoordig 10.000 mannetjes die denken l33t te zijn omdat ze een teksteditor hebben gemaakt in visual basic), enz enz enz. Combineer de schaal, de complexiteit, connectiviteit en afhankelijkheid, en begrijp dat beveiliging heel belangrijk is (of beter gezegd: hoort te zijn).

Niet alleen complexiteit. In de jaren '90 zijn zo veel automatiseringsprojecten mislukt en dat heeft zoveel geld gekost dat niemand meer veel geld voor een automatiseringsproject durft te vragen. Er wordt van commercieele zijde tegenwoordig zo'n beetje *altijd* water bij de wijn gedaan. De marges zijn heel klein geworden. Dus staan programmeurs onder grote druk om een planning te halen die ze zelf niet hebben gemaakt. Die planning is vrijwel altijd (te) krap. Dus worden er vrijwel altijd shortcuts genomen bij het testen.

In principe hoeft complexiteit namelijk helemaal niet ten koste van de software te gaan. Als je alles modulair opbouwt en je netjes de communicatie tussen de modules afspreekt, zou er in principe niets fout moeten gaan. Toch gaat het fout. Waarom? Afgeraffelde modules.

tegenover elke expert die zijn eigen compiler programmeert, of een grafische engine in assembler, staan tegenwoordig 10.000 mannetjes die denken l33t te zijn omdat ze een teksteditor hebben gemaakt in visual basic

Ehm... Tegenover iedere "low level" guru horen minimaal 10.000 applicatie-programmeurs te staan. Die guru's leveren nl. geen eindproduct af (afgezien van misschien demo-apps), dat doen die applicatie-ontwikkelaars, gebruik makend van die compiler, grafische engine, database, etc.

En of je je dan "l33t" voelt of niet, als app.-ontwikkelaar hoef je helemaal niet te weten hoe je ontwikkeltools intern werken. Dat voegt bv. niks toe aan het ontwerpen van een goeie user interface of een goed datamodel.
En dat zijn de dingen waar de eindgebruiker mee te maken krijgt. En die zal 't een zorg zijn of 't in VB, C#, java of C++ is ontwikkeld...

Maar dit heeft niks met security te maken: een assembler-programmeur kan net zo goed lekken introduceren als een VB-ontwikkelaar.

Qmail , tinydns ?

Meestal is een database server niet bereikbaar vanaf internet, enkel via het interne netwerk. De enigen die dit kunnen misbruiken zijn dan dus jijzelf of (in geval je een hoster bent) je klanten. En om je eigen site nu opzettelijk naar de verdoemenis te helpen.

Als je de data niet controleert voor je ze in de database steekt, kan een bezoeker misschien ook iets doen, maar dat is sowieso niet erg slim...

De "COM_CHANGE_USER - Password Length Vulnerability" die enkel in de oorspronkelijke tekst van die Esser vernoemd wordt, lijkt me trouwens een groter probleem (misschien niet ernstiger, maar makkelijker te exploiteren).
http://security.e-matters.de/advisories/042002.txt

Niet echt shock voor mensen. Dit probleem :: Ook zitten er nog twee andere bugs in MySQL's client library, een heap buffer overflow bug en een klein foutje waardoor crackers '\0' kunnen schrijven naar elk geheugenadres, aldus Stefan Esser van e-matters
was volgens mij al veel langer bekend. Ik weet niet of ik toen op hier er iets over gelezen had. Ik ben echter wel blij dat alles is opgelost


Verder denk ik dat dit :: Ik ben benieuwd hoelang het gaat duren voordat iedereen deze patch heeft geïnstalleerd? echt niet zolang gaat duren. Ik denk als je van je server hou dan onderhoudt je hem goed en pas je elke patch toe. Dus een beetje een slap verhaal

De reden dat ik dit vermeldde is omdat PHP en MySQL het hart vormen van ongeveer de helft van alle databasegebaseerde websites. De ervaring leert dat security updates en patches maar op een klein percentage van alle servers snel worden geïnstalleerd.

Ik wil absoluut geen flame uitlokken (zie ook mijn smilie in mijn eerste post) maar PHP en MySQL worden zo vaak geupdate (kijk alleen al eens naar het versienummer: 3.23.54) dat een heleboel servers maandelijks of alleen bij iedere "major"-release worden geupdate.

Dat dit een reden is dat er nog steeds zoveel gecracked wordt moge duidelijk zijn, maar als dit soort fouten voorkomen in software die zoveel gebruikt wordt mag je je best zorgen maken denk ik.

Even voor de duidelijkheid, er zit geen bug in PHP, de bug zit in een library die PHP gebruikt als je MySQL wilt gebruiken.
En niet alleen PHP gebruikt die library Perl bijvoorbeeld ook.

Bovendien is het sterk de vraag of een bug in de libmysql library die PHP gebruikt door een externe hacker kan worden geexploiteerd. Meestal laat een mysql-based server je geen directe SQL queries intikken.

In de meeste Mysql installaties staat de mysql poort (3306 default) dicht (dat hoop ik tenminste van harte).

Het is allemaal een stuk minder dramatisch dan wordt gesuggereerd n.m.m.

Mvg,
Xenna

Tja, op zich kan je PHP er gewoon buiten laten als je het goed doet: dat ding kan je dynamisch linken met mysql. Als jij je libmysqlclient.so vervangt door de versie zonder bug, zal je er in PHP ook niets meer van merken.

Ik wil absoluut geen flame uitlokken (zie ook mijn smilie in mijn eerste post) maar PHP en MySQL worden zo vaak geupdate (kijk alleen al eens naar het versienummer: 3.23.54) dat een heleboel servers maandelijks of alleen bij iedere "major"-release worden geupdate.

Dat dit een reden is dat er nog steeds zoveel gecracked wordt moge duidelijk zijn, maar als dit soort fouten voorkomen in software die zoveel gebruikt wordt mag je je best zorgen maken denk ik.

Niet iedere nieuwe release bevat verbeteringen m.b.t. security issues. Er kunnen ook nieuwe features worden toegevoegd, of fouten die geen betrekking hebben op security worden opgelost.

als je van je server hou dan onderhoudt je hem goed

Zou je ook houden van de tientallen servers bij klanten en die stapel interne die niet down kunnen zonder eindeloos geregel?
Updaten is rottig. het is echt nodig maar je kan er uren mee bezig zijn. (automatisch down brengen kost net zoveel gedoe aan geregel)

Is een beetje kort door de bocht (of je bent inderdaad wild van je servers

Ehhm lang mee bezig... kan zijn, maar op een normaal gebruikte server heb je maximaal 2 minuten nodig voor een update van mysql en alle aanhangende dependencies... ik heb bijvoorbeeld gisteravond 3 servers geupdate binnen een kwartier (inclusief inloggen e.d.). De dependencies worden meteen mee - ge-update. Ik hou wel van allemaal ja, maar ik hou nog veel meer van alle data die erop staat.

Die van tweakers kan ik natuurlijk niets over zeggen, lijkt me dat de site een paar minuten down moet ja. (aangezien die helemaal op de database draait)

en je gooi zo een server/service down?!
dat is gemakkelijk als je zelf de enige bent die kwaad kan worden omdat 'het systeem' niet werkt.
Wat ik bedoel is dat de makkelijkheid van het updaten vaak wordt genoemd/geroemd door mensen die een leuke site hebben en that's it.

edit:
's avonds is inderdaad de mogelijkheid (meestal) om makkelijk te updaten

Lijkt me logisch dat je gewoon voor alle Zekerheid een extra backup wil maken zodat je in ieder geval 1 werkende backup hebt. Op dat moment mogen er eigenlijk geen users op het systeem zitten.

Als je een bug hebt op een publiek systeem , is het mijns inziens het slimste om de server opnieuw te installeren, want je weet (bijna) nooit 100% zeker of er gebruik gemaakt is van het gat, en een root-kit is ook zo geinstalleerd.

Helaas is dit niet in een paar minuten gedaan....

Als je een bug hebt op een publiek systeem , is het mijns inziens het slimste om de server opnieuw te installeren, want je weet (bijna) nooit 100% zeker of er gebruik gemaakt is van het gat, en een root-kit is ook zo geinstalleerd.

Helaas is dit niet in een paar minuten gedaan...

Na elke ontdekte bug je hele systeem opnieuw installeren? Zullen de users van dat systeem blij mee zijn En met de hoeveelheid bugs die worden gevonden kan je 24/7 je systeem opnieuw installeren.
Een Root-kit kan je redelijk goed detecteren, door dingen als tripwire en aide te gebruiken (met database en files zelf op een read only medium), lkm uitschakelen en /dev/mem cq /dev/kmem read only maken. Dit om te zorgen dat er geen evil code in je geheugen wordt geladen, wat je niet vanuit userland kan detecteren.

dan onderhoudt je hem goed en pas je elke patch toe

Nope.. als er iets is wat je niet moet doen op een goed draaiend systeem is elke willekeurige patch / update toepassen.

Laat staan hele ServicePacks.. Een update levert vaak meer problemen op dan dat het eigenlijk op zou moeten lossen.

Dit zijn erg serieuze beveiligingsfouten. Gelukkig is er al een patch voor. Ik ben benieuwd hoelang het gaat duren voordat iedereen deze patch heeft geïnstalleerd?

Zouden er mensen zijn die nu gaan vallen over de integratie tussen PHP en MySQL waardoor je ook PHP moet patchen terwijl je helemaal geen MySQL gebruikt?

Je kan MySQL support weglaten als je dat wilt. Sterker nog, als je de source zelf compileert is dat standaard.

Het is natuurlijk wel goed dat ook hier nog even het nieuwsbericht wordt gepost dat er gaten waren en inmiddels zijn gedicht in de update. De informatievoorziening vanuit MySQL is hierover heel erg slap en bijna niet terug te vinden op hun website (er wordt wel wat aandacht aan besteed, maar niet serieus voorpagina nieuws)
Echter het is wel al een wat oud bericht: 12 december was de update hiervan al verkrijgbaar. Kan dit niet wat sneller rondverspeid worden op het internet?

Even belangrijk: Volgens onze eigen meuktracker (meuktracker: MySQL 3.23.54c) zijn de eerste patches te snel uitgebracht. De versie die wel goed is is versie 3.23.54c.

Ik hoop dat de Open Source Community hier de komende tijd beter op gaat letten. Ik hoor telkens dat 1 van de voordelen van Open Source is dat er heel snel een patch beschikbaar komt, maar ik vind dat die patch dan ook wel betrouwbaar moet zijn. Microsoft is hier in het verleden regelmatig de fout mee ingegaan (en door alle Tweakers op afgerekend) maar lijkt deze zaken ondertussen op orde te hebben. Het afgelopen half jaar zijn een aantal belangrijke updates in de OSC verspreid met fouten en soms zelfs met Trojans. Als je als gebruiker eerst te horen krijgt dat je zo snel mogelijk moet updaten, dit vervolgens braaf doet en dit vervolgens nog een paar keer kan doen wegens te grote haast van de developers dan kijk je de volgende keer wel uit om patches direct te installeren (wat dan weer leid tot meer risico op hacks!).

Al met al lijkt het erop dat dit probleem nu definitief is opgelost en is het nu afwachten hoelang het duurt voordat iedereen deze patch heeft doorgevoerd.

Gelukkig dat ze er op een "normale" manier achter komen en dat niet iemand zich eerst heeft moeten
"opoferen" voor een cracker die de database eventjes kraakt door een loze bug..

was een tijdje geleden op bezoek bij een hacker die demonstreerde hoe hij moeiteloos diverse servers binnenwandelde. met name Unix achtigen waren zijn specialiteit en de friendly variant Linux benaderde hij op rootniveau. Ik kon op dat moment niet controleren hoe hij bepaalde zaken aanpakte en kreeg ook geen info daarover. ( goh, verassend he..
Dit soort berichten ondersteunt de kwetsbaarheid ook van veilig geachte systemen.
Iedereen zit te mopperen op MS maar ook Linux , MySQL , apache en andere applicaties/OSsen zijn dus duidelijk zo lek als het bekende mandje.
Probleem is de belangen die er spelen, veiligheid kost geld en moet afgewogen worden tegen de opbrengst.

Hackers dragen dit soort kennis niet zo maar over en profiteren van de gaten zonder daar ruchtbaarheid aan te geven. Helaas moet je tevens vaststellen dat iedere discussie over open source ontaard in een welles/nietes spelletje of een gezeur tussen MS en open source aanhangers.
Dit soort houding is een aantasting van de integriteit van de open source systemen.
Gezonde kritiek en vooral deze serieus nemen is essentieel om te overleven.
De inspanningen die MS de afgelopen maanden gedaan heeft beginnen daar hun vruchten af te werpen, nu nog positieve kritiek bij de open source aanhangers.
Dan stap ik morgen nog over... nou ja.. bij wijze van spreken dan...


je wordt toch ziek van die figuren die alle ongewenste bijdragen maar weg modereren...
Wat je niet weet is er niet.. struisvogels...

Dus binnenkort hebben we weer een aantal #1's op 't GoT forum? Ik neem aan dat de GoT MySQL daemon ook een upgreedje gaat krijgen nal van dit

Ik ben er van overtuigd dat die paar honderd extreme goede hackers die onze aardbol telt veel meer bugs kennen dan wij ons kunnen voorstellen en deze lekker voorzichzelf houden. Kan dus best dat deze bij hun al bekend was.

Ik zie het zo. Hackers hebben meestal tijd zat en zijn meestal goed geskilled (die paar 100 honderd dan), en zullen nooit bugs met veel andere mensen sharen. Voor ons is het dus een kwestie van de leverancier die een fout vindt, wat helaas vaak niet het geval is, of een bedrijf dat die een specifieke toepassing wilt en zelf aan de source gaat sleutelen en een fout tegenkomt.

Net zoals bij de rabobank en hun incassosysteem... zeker

Volgens mij is dit verkeerd opgevat, het ging erom dat het blijkbaar niet in dank afgenomen wordt tegenwoordig dat er bugs worden gemeld in een bepaald programma, zodat ze opgelost kunnen worden, en dan noem ik maar het voorbeeld van rabobank en hun incassosysteem....

Dus dat het voor zich gehouden worden is dus blijkbaar niet zo gek.

nee daar doelde ik niet op...

No offence maar dit is al iets van 1,5 week bekend ?

ff mierenneuken, het is hooguit 6 dagen publiekelijk bekend. De release van MySQL 3.23.54 zoals aangekondigd op http://www.tweakers.net/meuktracker/3336 is van 12 december. Zoals getty daarin terecht opmerkte, is de release een reactie op het security bulletin van 2002/12/12
http://security.e-matters.de/advisories/042002.html?SID=914c3975b5ea8b 9a4c03c58a929890e7

For Debian GNU/Linux 3.0/woody this has been fixed in version 3.23.49-8.2
and version 3.22.32-6.3 for Debian GNU/Linux 2.2/potato.

Daarom is het imho verstandig om als je een MySQL server gaat draaien voor je meut je poort ervan voor de buitenwereld afschermd. Tenminste zo heb ik het. De MySQL-server werkt wel, ook al staat hij niet geport-mapped voor het internet (icm phpBB bijvoorbeeld)