Google zoekt rol als opensource-veiligheidsautoriteit

Google maakt zich sterk voor beveiliging in opensourcesoftware via zijn rol in de nieuw opgerichte Ocert. Dit 'opensource computer emergency response team' zal helpen beveiligingsrisico's in opensourcesoftware te beperken.

De sites en diensten van Google leunen zwaar op aangepaste opensourceprojecten en het zoekbedrijf ontwikkelt zelf regelmatig software waarvan de broncode vrijgegeven wordt. Volgens beveiligingsmedewerker Will Drewry van Google is het echter soms lastig om een oplossing voor ontdekte beveiligingslekken in opensourcesoftware snel te distribueren, of om een kwetsbaarheid überhaupt bij de auteur van de software aan te kaarten en deze het hoofd te bieden. Om de problemen op te lossen hebben Inverse Path, Google en het Open Source Lab het Ocert-initiatief gesponsord en dragen zij actief aan het project bij.

De initiatiefnemer van Ocert is Andrea Barisani van beveiligingsbureau Inverse Path. Het project is vergelijkbaar met diverse bekende certs zoals het Internet Storm Center en US-Cert, maar richt zich volledig op opensource. De vrijwilligers, beveiligingsexperts uit de opensourcegemeenschap, hebben zich ten doel gesteld een centraal meldpunt voor beveiligingsproblemen in opensourcesoftware te vormen en te helpen bij het oplossen van de problemen. Vooral wanneer opensource-auteurs weinig ervaring hebben met het patchen van software, moeten de projectleden hulp bieden. Ten slotte zal Ocert een bijdrage leveren door te onderzoeken hoe de veiligheid van software verbeterd kan worden.

Reacties (13)

Zelfs bij de grotere Linux distributies is het verschil tot release van de veiligheids update erg groot. Bij Gentoo zijn updates meestal erg snel beschikbaar (er is weinig tot geen backporting nodig) waardoor een ebuild sneller als stable wordt bestempeld. Bij Debian gaat het allemaal wat langzamer omdat zij proberen de code eigenlijk bijna binary compatible te houden.

Ik denk wel dat een centraal veiligheids punt voor open source een toegevoegde waarde heeft, maar dan moeten wel alle grote opensource projecten zich aanmelden. Zo is bijvoorbeeld wel OpenBSD lid, maar Net- en FreeBSD niet. Maar ik mis ook een namen als Novell (alleen opensuse is lid) of GNU.

Bij Debian gaat het allemaal wat langzamer omdat zij proberen de code eigenlijk bijna binary compatible te houden.

Binary compatible? wtf heb je het over. In Debian Stable komen geen nieuwe versies van software, dat is de policy. Dus als er een security bug gevonden word moet dat in de versie die gebruikt is in Debian Stable gefixed worden. Dit gebeurt allemaal op source niveau waar vervolgens weer een nieuwe set binaries uitrolt die via debian.security verspreid worden. Dit duurt allemaal echt niet zo lang. Maar je weet tenminste wel dat je niet opeens een compleet andere versie van een applicatie hebt waardoor er vanalles stuk zou kunnen gaan. Gentoo doet nauwelijks aan patchen van security bugs, dat laten ze voor een groot deel over aan de oorspronkelijke developers van de software, Gentoo update alleen de download url voor de source in hun portage tree.
Een security bug fix in Debian: 1.2.5 -> 1.2.5-1
Een security bug fix in Gentoo: 1.2.5 -> 1.4.1
(theoritisch zou het in gentoo geleidelijk naar die 1.4.1 gegaan zijn als je elke keer update naar de nieuwste versie, maar soms wil je een bepaalde versie gebruiken ivm andere software en/of eisen).

"Backporten" van security bug fixes is over het algemeen echt geen tijd rovende bezigheid. Als de bug eenmaal gevonden is en gefixed is het vaak makkelijk te backporten. En andere keren is het niet eens van toepassing.

[Reactie gewijzigd door elmuerte op 7 mei 2008 13:31]

Ach ja, de theorie, maar wat is de praktijk? De praktijk is dat Gentoo helemaal niet zo snel is! Zie onder deze link een onderzoekje van Distrowatch: Debian helemaal bovenaan, zelfs de commercielen zijn trager.
http://distrowatch.com/weekly.php?issue=20080218#feature

Hopelijk rolt hier ook een open source security validation software pakket uit, waarmee programmeurs gemakkelijk hun source code kunnen scannen op zwakke punten. Er zijn wel wat oplossingen hiervoor, maar een wat meer volwassen oplossing zoals commerciëel al wordt aangeboden zou welkom zijn.

Het feit echter dat Google zeer snel zwakte voor de DMCA klacht op hun open source project website voor het CoreAVC codec project, terwijl de klacht helemaal geen gegronde redenen had, zet bij mij echter wel vraagtekens of Google alleen hun eigen belang dient en weinig geeft om andere opensourcesoftware (tenzij ze het natuurlijk zelf gebruiken).

Google geeft wel degelijk veel om open source projecten, ook degene die buiten hun gebruik liggen. Een goed voorbeeld daarvan in Google Summer of Code, waar ik dit jaar ook aan meedoe. Er worden dit jaar 1125 studenten gesponsort die aan open source werken, per student kost dit google ruim 5000 dollar. Alles wat maar in de FOSS zit kan meedoen en studenten aannemen, zo zijn er dit jaar veel studenten aan de slag bij KDE en gcc. Maar ook FreeBSD, wordpress, drupal, PHP en the python foundation worden gesponsort. Dit is voor google verder belangeloos, maar kost ze wel een hoop geld.

Persoonlijk zie ik het nut van ocert niet helemaal in, ik ben weinig oss projecten tegengekomen waar er niet een mailadres in de readme staat, of een aparte BUGS file wordt meegestuurd. Anders hebben veel projecten een pagina op sf.net e.a. waar standaard een bug tracker in zit.

Mwa, 5.000.000 dollar, een hele hoop free publicity en goodwill + ook nog wat doorontwikkeling aan software die je gebruikt. Lijkt me voor een bedrijf als Google gewoon een goede deal. Wat denk jij dat reclame kost?

Het was niet Google, maar CoreCodec zelf die hun project van Google Code hadden verwijderd, zoals je gisteren had kunnen lezen.

Volgens beveiligingsmedewerker Will Drewry van Google is het echter soms lastig om een oplossing voor ontdekte beveiligingslekken in opensourcesoftware snel te distribueren, of om een kwetsbaarheid überhaupt bij de auteur van de software aan te kaarten en deze het hoofd te bieden

Ik dacht dit net het sterke punt van open source en de community was, maar blijkbaar niet?

Het sterke punt is dat wanneer een kwetsbaarheid gevonden word en de auteur van de software kan om een of andere reden niet onmiddellijk beginnen met een patch, dan doe je het toch zelf?

de patch kan dan verspreid worden naar iedereen die de software gebruikt.

Maar het is gewoon ook in ieders belang dat de auteur van de software ook de patch krijgt om deze dan zeker in een volgende release te stoppen en om echt iedereen die de software gebruikt op de hoogte te stellen.

Het punt is dus: iedereen kan een bug vinden en fixen, maar als de ontwikkelaar een nieuwe versie uitbrengt met trug dezelfde bug in omdat hij geen zin/tijd/kennis heeft om die op te lossen brengt het iedere keer hetzelfde patchen met zich mee (meer werk dus)

wat men hier wil bereiken is de ontwikkelaars helpen (tijd/zin) en eventueel onderwijzen in security (kennis)

maar zoals hierboven vermeld, bij grote populaire projecten is dit natuurlijk niet nodig, die hebben tijd/zin en kennis genoeg (om security patches te maken/toe te passen)...

Weer een mooie kans om Google onmisbaar in de "server/web wereld" te maken.

Dit is niet nieuw, communities zijn vaak zeer gefocussed op dit soort zaken, alleen nu er een grote speler zich mee wil gaan bemoeien is het nieuws.

Google is niet onmisbaar, Google probeert handig in te spelen op iedere mogelijkheid in de markt.

Je tekent Google nu wel heel erg af als opportunistisch bedrijf met een 'ik ook' instelling. Ik neem aan dat je je nog de contest herinnert waarin Google 25 miljoen dollar uitreikt aan de eerste die een robotje op de maan kan laten rondkarren? Of, zoals hierboven ook genoemd is, Google Summer of Code? Tuurlijk zit er iets voor Google in, al is het maar publiciteit, maar het gaat erom dat ze anderen een kans geven die ze met kop en schouders boven 'de rest' uit kan laten steken. Handig inspelen op iedere mogelijkheid is iets waar je mijns inziens alleen Google maar van kunt betichten, het op al dan niet vijandige wijze trachten over te nemen van een kleinere speler in dezelfde markt kan ik niet alleen niet handig noemen, maar ook nog eens schadelijk voor de markt.

De goede open source projecten hebben hiervoor al lang een oplossing. Achter deze projecten staat vaak een goede stichting of bedrijf. De slechte open source projecten vallen vanzelf af doordat niemand ze meer gebruikt. Dus in hoeverre is dit echt een issue?

Hoe denk je dat een klein projectje groot wordt? In elk geval niet door eerst een stichting op te zetten en dan pas te programmeren. Eerst bouwen, als het dan 'uit de hand loopt' wordt het vanzelf professioneler. En zoals je kunt lezen in het nieuwsbericht

Vooral wanneer opensource-auteurs weinig ervaring hebben met het patchen van software, moeten de projectleden hulp bieden.

is het juist deze groep die wat ondersteuning wordt aangeboden.