Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 41, views: 17.342 •
Bron: Security Focus

Securityexperts waarschuwen developers en gebruikers van open-sourcesoftware dat ze zich bewust moeten zijn dat Googles nieuwe zoektool voor programmeurs een nieuwe gelegenheid biedt voor hackers om gericht op zoek te gaan naar zwakheden in software. Met de normale zoekmachine van het bedrijf kan weliswaar ook al in sourcecode worden gezocht, maar de functionaliteit beperkt zich tot het zoeken naar het vóórkomen van specifieke stukken tekst. Met Google Code Search kan door gebruikmaking van reguliere expressies, een formalisme om tekstpatronen te beschrijven, veel gerichter naar potentieel kwetsbare code worden gezocht. Chris Wysopal van beveiliger Veracode wijst erop dat dat een nieuwe aanvalslinie opent op onder meer websites die gebruik maken van open-sourcecode. Het is een nieuw voorbeeld van hoe Google misbruikt kan worden: eerder was al duidelijk dat hackers de zoekmachine gebruiken om bijvoorbeeld potentieel kwetsbare serverapplicaties te vinden en databases te plunderen.

Google verrekijker (cropped) Volgens Johnny Long, expert op het gebied van hacken met behulp van Google, moeten programmeurs zich beter realiseren wat veilige programmeertechnieken zijn en wat beter vermeden kan worden. Zo dienen ze zich bijvoorbeeld te beperken tot het gebruik van onderzochte en veilig geachte libraries. Hij erkent dat het hackers wellicht een tijdje een voordeel zullen hebben eer developerscommunities zich de implicaties van doorzoekbare sourcecodeverzamelingen realiseren. 'Programmeurs moeten de verleiding weerstaan hun code te proberen af te sluiten van de zoekmachine', zo stelt Long, daarmee wijzend op de mogelijkheid om via het bestandje robots.txt de code op slot te zetten voor Google Code Search.

Reacties (41)

weer een vervelend nadeel van een goed initiatief inderdaad... gaat Google verplicht worden deze functie te verwijderen denken jullie?
je kan het ook omgekeerd bekijken, als je als programmeur een stukje ontdekt dat een beveiligingsrisico inhoud, kan je ineens alle andere projecten nakijken die dat ook kunnen hebben, en deze auteurs op de hoogte stellen.

gevolg: sneller gefixte security issues :)
Dat is het ultime Utopia!

Maar helaas als een bad-ass hacker dat vind maakt hij daar zelf gebruik van door minimaal een proof-of -contept te maken of de fout te laten uitlekken.
De échte hackers zijn juist de mensen die het probleem oplossen, en een proof of concept maken om het te kunnen misbruiken.

Ik zie hier geen gevaar in, eerder een veiligere code.
Gaat de fabrikant van messen aangeklaagd worden en dan maar botte messen van zacht plastic fabriceren? Wat denk je zelf?
En toch is het altijd nog de taak van de programmeur om zorgvuldig met zijn code om te springen.

Toch kan Google Code Search ook helpen bij het vinden van bugs etc in software...

dus 50/50 zeg maar...
'Programmeurs moeten de verleiding weerstaan hun code te proberen af te sluiten van de zoekmachine'
Vraag me af waarom hij dat zegt. Persoonlijk zou ik dat nl. wel doen. IIG totdat bekend is wat de risico's zijn. Debuggen kan ook op andere manieren...
Lijkt me nu net de essentie van zijn stukje.
Het bestaan van deze zoektool zal de community verder helpen als zo veel mogelijk mensen daaraan meedoen.
Het afsluiten van deze zoektool zorgt ervoor dat de opzet zal mislukken en dus als ontwikkelingsbiblitheek tot een zinloos gebeuren zal verwatren. Je moet dus niet je code afsluiten van de tool maar zorgvuldig omgaan met de te kiezen code. Op die wijze sla je twee vliegen in een klap, je stimuleert de code ontwikkeling en je voorkomt misbruik.
IIG totdat bekend is wat de risico's zijn.
'totdat' is niet nodig, er is nu al bekend wat de mogelijke risico's zijn en dat is dat mensen jouw fouten kunnen zien en mogelijk daarvan gebruik kunnen maken...
en bugvrije software bestaat domweg niet dus is het onmogelijk te denken: 'ik geef mijn broncode pas vrij zodra _alle_ bugs eruit zijn' ...

Ben je daar bang voor, kan dat heel terecht zijn en het is altijd een truc om dan je code gesloten te houden en te hopen dat niemand je fouten ziet, en vooral niemand er makkelijk misbruik van kan maken (alhoewel natuurlijk de fouten blijven bestaan en mogelijk hackers/crackers wel andere manieren vinden deze bugs te vinden)

Toch kan het voor bepaalde programmaeurs wel zin hebben om niet daarvoor te kiezen maar welbewust het risico aan te gaan...
Namelijk voor diegenen die blijvende support en ondersteuning voor hun broncode willen vinden en die eventueel gevonden bugs snel kunnen oplossen en die hun code continue willen verbeteren...

Op dat moment heeft 'open source' (waar het hier om gaat in essentie) wel zin, het bied een meerwaarde juist doordat het veel makkelijker is fouten op te sporen en te debuggen
Ik vind het een beetje vergezocht. Je kan met Google Code Search één of twee regels code per zoekresultaat vinden. Je kan op basis van een of twee regels niet zien of een programma veilig of onveilig is.

Fouten in de beveiliging komen ook meestal doordat je iets vergeten bent te doen, en daardoor code er dus niet staat. Het is heel lastig zoeken naar een stuk code waar iets niet in staat. Ik moet de eerste werkende exploit verkregen door dit systeem nog maar eens zien...
Wrong: het bekende security probleem 'Buffer overrun' wordt veroorzaakt door functies als strcpy en memcpy. Daarkun je dus op zoeken.
char* dest = new char[1000]
memcpy(dest, source, source_len);
De buffer overflow die jij als voorbeeld geeft is niet meer exploitable in moderne Linux distributies. Nu kun je zeggen "niet iedereen gebruikt Linux", maar van de mensen die (veel) open source gebruken, zullen er veel Linux gebruiken. Voor niet-open-source is dit "google lek" niet interressant natuurlijk.

De laatste jaren is er in Linux erg veel gebeurt in de compiler en C library om de beveiliging te verhogen; zowel tijdens het compileren als tijdens het uitvoeren worden een aantal checks uitgevoerd. Gevolg is dat de exploit die jij noemt, maar ook het "gets()" in het orgineel, niet meer een probleem zijn. Natuurlijk zijn er nog (te veel) andere problemen, maar in het algemeen zijn die veel moeilijker met een google regexp te vinden.
@fenrus
Ik kan me niet voorstellen dat er gechecked wordt op overflow zolang het programma binnen zijn eigen memoryspace blijft (hoe weet mijn besturingssysteem, waar ik wat in mijn geheugen heb staan?). Het exploiten van een programma is vaak voldoende (het is voldoende om een worm mee te maken die zich van server tot server verspreid, Als je de server helemaal wilt hacken heb je een voet tussen de deur en kan van daaruit verder werken, en je wil niet weten hoeveel deamons als root gedraaid worden...)

Overigens is er genoeg opensource software voor windows...
het gaat hier alleen om open-sourcesoftware, daar kan iedere hacker de broncode van inzien, de broncode is normaal niet toegankelijk en is alleen toegankelijk voor de server waar deze wordt geparst naar html als output, met Google Code Search kan je zoeken op welke servers deze open-sourcesoftware draait en zwakheden in de code uitbuiten
het gaat hier alleen om open-sourcesoftware
Ik denk dat jij het allemaal ietsje te optimistisch inziet.
Google spidert de website volledig, en stel dat jij even een ZIPje online zet met een backup van je sourcecode om die bvb van elders weer te kunnen dld'en, dan wordt die evengoed meegenomen in het archiveren, de spider pakt nl ook archieven uit. Je moet maar 1x de kleine vergissing maken van op een van je pages naar het bestand te wijzen en je hebt "het vlaggen".
ik zie het niet te optimistisch en elke zip files was zonder Google Code Search ook te vinden, je moet je eigen boncode nooit als zip online zetten

wat je met Google Code Search wel makkelijk kunt doen is zoeken naar niet gefilterde invoervelden, als je weet dat bij een cms de filter functie strip heet kan je met Google Code Search zoeken naar een formulier zonder deze functie en daar kan je dan weer code injecteren
En wie zegt dat $_POST niet eerder in de code al gesanitized is?
Eerst wordt gezegd dat Google Code Search niets nieuws is en dat Krugle en vooral Koders al veel langer bestaan, maar toch is het nu ineens een Security issue?

Lijkt me een beetje een geval van 'over de rug van Google bekend worden'. Aan de andere kant is Securityexperts gewoon ruim twee jaar te laat met deze waarschuwing, Koders bestaat al vanaf 2004 :P
Natuurlijk is het zo dat enkel de 'naam' Google meer publiciteit krijgt, maar verder is het wel zo dat de codesearch van Google nét wat meer uitgebreidde zoekmogelijkheden heeft, waardoor je veel flexibeler kunt zoeken...

de Reguliere Expressies kunnen ook door Hackers makkelijk worden toegepast en dus is het gevaar net wat groter dan met de al eerder bestaande searchengines...

Maar je hebt wel gelijk dat men niet moet doen alsof het gevaar an sich nu helemaal 'nieuw' is, het is eerder zo dat dit gevaar al langer bestaat, en ook al veel langer toegepast wordt (maar dan is het enkel positief dat hierover publiekelijk bericht wordt)
'Programmeurs moeten de verleiding weerstaan hun code te proberen af te sluiten van de zoekmachine'
daarin heeft hij volledig gelijk en dat is juist een essentieel punt aan het 'open source'-principe...

Omdat het betekent dat Programmaeurs snel geconfronteerd kunnen worden met hun fouten, mogelijk ook 'kwaadsschiks', is de drang (of zelfs 'dwang') om ook _goed_ te programmeren een stuk groter..

Natuurlijk, je kunt het zekere voor het onzekere nemen en de 'eenvoudigste' beveiligingstechniek toepassen, nl. je code gesloten en proprietair houden, maar dat is voor velen weinig leerzaam en geeft weinig motivatie om ook de programmatuur te optimaliseren en te verbeteren.
Dit is juist positief, het hele idee achter open source is dat veel ogen toekijken en bugs vinden. De mogelijkheid doelgericht security bugs te vinden zie ik als iets positiefs.

Natuurlijk is het aan de vinder of hij verantwoordelijk genoeg is het te rapporteren of patchen, maar dat is altijd het geval hoe de bug ook gevonden wordt... Daar kan Google ook niets aan doen.

IMO: openheid = goed
Ik ben het helemaal met je eens!

Deze nieuwe zoekfunctie is dus een goede aanvulling op bestaande bugzilla's...

Als de programmeurs slim zijn (en ik twijfel er niet aan dat ze dat gemiddeld genomen zijn), zijn ze de hackers voor en gebruiken ze google om bugs in hun code zelf op te lossen, vóórdat hackers hiertoe gelegenheid hebben.
Ik vind dit weer net zo'n artikel als het bericht van een tijdje geleden dat Google zou helpen bij het vinden van kinderporno (zie Google boos op Algemeen Dagblad).
Natuurlijk kun je zaken vinden met een search engine, en met een source code search engine zul je source code kunnen vinden. En niet alle code is goed, dus zul je ook problemen in de code kunnen vinden.

Verder is dit niet de eerste source code search engine (zoals ook al door anderen aangegeven) en daar werden deze opmerkingen niet bij gemaakt. Volgens mij is hier gewoon weer eens iemand op zoek naar publiciteit, en als je de naam Google gebruikt lukt dat meestal wel (zo blijkt hier ook weer).
Als je vindt dat 'security through obscurity' een goede beveiliging is, dan is deze zoekdienst inderdaad geen goed nieuws.

Voor echte veiligheid is dit echter wel een goede ontwikkeling. Op deze manier kan de broncode makkelijker onderzocht worden op fouten. Kwaadwillende gebruikers dit ook kunnen (en zullen) gebruiken om nieuwe zero-day exploits te vinden. Deze exploits blijven echter nooit lang geheim, waardoor ze snel gepatcht kunnen worden.

Op de lange termijn wordt de software hier alleen maar robuuster van.
Dit was ook mijn gedachte. Software wordt hierdoor alleen nog maar kwalitatief beter van. En kwalitatieve software is ook volwassen software.

Alleen vraag ik mij af of Google niet aangeklaagd kan worden als blijkt dat "software patenten" online komen te staan. Of een ander scenario. Een bedrijf dat gesloten software maakt en per ongeluk broncode lekt, zou Google kunnen aanklagen. Google indexeert immers interlectueel eigendom van een bedrijf. Ik ben benieuwd hoe het auteursrecht in deze zich gaat verhouden tot Google. Dit zal wel rechtzaken op gaan leveren.
Lijkt mij geen probleem. Op dit moment worden ook wel vaker documenten geindexeerd die onder copyright of andere bescherming vallen en die "per ongeluk" online zijn komen te staan. Ik geloof niet dat Google daar al eens (succesvol) voor is aangeklaagd.

Verder zullen ze wel dezelfde regeling hebben als bij de normale zoek resultaten: de eigenaar kan verzoeken om bepaalde pagina's uit de index te laten verwijderen.
Kort door de bocht. Natuurlijk is het hele idee van open source dat vele ogen ernaar kijken en het helpen verbeteren, maar er hoeft maar 1 paar ogen (of 1 oog, als het een piraat is) naar te kijken dat -niet- de intentie heeft om de boel te verbeteren, en die weet dan precies in welke versie welke zwakke plekken zitten.
Geen slechte ontwikkeling toch? Hoe sneller fouten gevonden worden hoe eerder ze kunnen worden opgelost lijkt me.
Ik denk niet dat er veel mensen Google Code Search gebruiken om hun code gaan debuggen :). Diegenen die via Google gaan zoeken naar fouten hebben andere intenties dan het oplossen ervan.

En dan nog maar te zwijgen over mensen die de fouten al kennen en de tool alleen gebruiken om te zoeken naar andere code waar de fout ook in zou kunnen zitten.

Op dit item kan niet meer gereageerd worden.



Populair: Apple iPhone 6 iPhone Apple iPhone 6 Plus Smartphones Laptops Microsoft Games Apple Activision Smartwatches

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013