Audit OpenBSD-code onthult bugs maar geen backdoors

De code van OpenBSD wordt doorgelicht na de melding dat ontwikkelaars door de FBI betaald werden om backdoors in te bouwen. Vooralsnog zijn er echter geen achterdeurtjes gevonden, maar wel een aantal bugs met beveiligingsrisico's.

OpenBSD-ontwikkelaar Theo De Raadt riep vorige week op de ipsec-stack van OpenBSD, waarmee ip-verbindingen door middel van encryptie worden beveiligd, grondig door te lichten. Hij deed dit omdat hij een e-mail had gekregen van Gregory Perry, die tien jaar geleden als chief technology officer bij Netsec betrokken was bij de ontwikkeling van de ipsec-implementatie voor OpenBSD.

Perry beweerde dat de FBI tien jaar geleden een aantal OpenBSD-ontwikkelaars van Netsec had betaald om backdoors in de ipsec-stack in te bouwen. De claim zorgde voor veel beroering; OpenBSD staat als zeer veilig bekend.

De Raadt heeft deze week zijn voorlopige conclusies gepubliceerd. Hij gelooft dat Netsec waarschijnlijk door de FBI benaderd is, maar dat eventuele backdoors die ontwikkeld zijn niet in de ipsec-tree zijn opgenomen. De ontwikkelaar geeft toe dat de audit een lastige klus is en nooit perfect zal verlopen, aangezien de code te groot is.

Helemaal zonder resultaat is de zoektocht echter niet. Zo is er een bug in oudere versies van de Encapsulating Security Payload aangetroffen, die stilletjes in 2002 gedicht is. De kwetsbaarheid was echter niet bekend omdat er destijds geen publieke aankondiging van verscheen. Ook zijn er mogelijke kwetsbaarheden voor cipher-block-chaining gevonden, schrijft Ars Technica, die De Raadt omschrijft als een 'behoorlijk ernstig ongeluk'. Hij gelooft dat alle bugs die tot nu toe gevonden zijn per ongeluk in de code gekomen zijn en dat er geen opzet in het spel is.

Reacties (64)

Het ging hier om een sidechannel attack en die zijn soms niet eens zo heel makkelijk te "vinden" in code omdat het niet per-se om 'verkeerde' code gaat maar het "lekken" van informatie op een andere manier. Een mooi voorbeeld is dit. Ondanks dat code 100% correct kan zijn kan een attacker in sommige gevallen toch informatie onttrekken van gegevens/datastreams/verbindingen/etc. die hem uiteindelijk kunnen helpen bij het toegang verschaffen ertoe.

Ik vind 't dan ook aardig voorbarig om binnen een paar dagen (wat, een anderhalve week?) nadat er bekend is geworden dat iemand door de FBI is omgekocht te roepen dat 't waarschijnlijk wel snor zit. De code audit kan dan misschien wel geen verborgen backdoors hebben opgeleverd, het kan ook juist iets zijn dat de ontwikkelaar niet heeft gedaan: bewust niet geïmplementeerd zodat er op een obscure wijze bepaalde informatie lekt. En zoiets vind je niet 1, 2, 3.

quote: http://permalink.gmane.org/gmane.os.openbsd.tech/22557

My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF,...

[Reactie gewijzigd door RobIII op 24 december 2010 10:33]

Volgens mij wordt er niet beweerd dat er geen lek aanwezig is maar dat deze niet gevonden is. Dus om het zoals ik ooit eens ergens heb gehoord: No proof of excistence is no proof of non-excistence.

Hij gelooft dat Netsec waarschijnlijk door de FBI benaderd is, maar dat eventuele backdoors die ontwikkeld zijn niet in de ipsec-tree zijn opgenomen.

"Hij gelooft dat ... eventuele backdoors ... niet in de ipsec-tree zijn opgenomen." Daarmee trekt 'ie in ieder geval een, IMHO, wellicht wat voorbarige conclusie. Ik beweer ook nergens dat er een lek aanwezig is. Ik geef alleen aan dat ik 't wat vreemd vind dat ze al zo snel met zo'n conclusie komen. En dat een code-audit alleen niet voldoende zal zijn om uit te sluiten of er lekkage is; de lekkage kan ook op andere niveaus gebeuren die je niet (direct) in code zult aantreffen maar wel bewust (bijv.) achterwege gelaten.

[Reactie gewijzigd door RobIII op 24 december 2010 10:28]

Sja, bijvoorbeeld door een compiler te gebruiken die tijdens het compilen die specifieke backdoor inbouwt. Vind je niets van terug in de broncode inderdaad

Heb je überhaupt gelezen waar ik het over heb Het hoeft zelfs niet (expliciet/specifiek) in de binary te zitten.

Er kan iets (bewust) op een bepaalde manier geïmplementeerd zijn die 100% in orde is maar (onbedoeld, maar voor iemand die omgekocht is wel bewust, en subtiel) toch informatie lekt.

[Reactie gewijzigd door RobIII op 24 december 2010 10:43]

Yep, waarom je de negatieve invalshoek van mijn post kiest weet ik niet, maar ik sta aan dezelfde kant als jij hoor. Zonder meer. Timing bijvoorbeeld etc etc etc. Net als dat er een "corrupte" compiler kan zijn gebruikt. Dus... fijne dagen.

Ik zie niet hoe een "corrupte compiler" een side-channel zou kunnen veroorzaken (of je moet die "corrupte compiler" aan de rest van de wereld zien te verslijten of het project alleen als binary verspreiden). Daarbij impliceert een "corrupte compiler" in deze context dat er een 'aangepaste' binary uit komt rollen terwijl dat voor een side-channel helemaal niet nodig hoeft te zijn.

Maar verder no hard feelings hoor Jij ook fijne dagen

[Reactie gewijzigd door RobIII op 24 december 2010 15:09]

Correct. Maar het is wel degelijk mogelijk, en sterker nog, het wordt naar alle waarschijnlijkheid ook toegepast in bepaalde projecten. En laat dat IPsec daar nou net een perfecte kandidaat voor zijn.

Maar wat je zegt klopt natuurlijk. Het hoeft helemaal niet op die manier gedaan te zijn. Ik vind het alleen erg stug voor mensen om nu al te roepen dat er met het project niets mis zou zijn. Denk dat het heel waarschijnlijk is dat er precies op de manier die jij schetst "misbruik" ingebakken kan zitten. Zonder meer.

Thanks

Niet dat ik expert ben, maar is die timing methode geen onderdeel van de sidechannel-attack theorie? Volgens mij moet je het vergelijken met het openen van een brandkast door te luisteren wat voor mechanisme erin zit.
Hoe zo'n aanval inhoudelijk werkt volg ik dan weer niet. Wordt alleen het identificeren van het achter de beveiliging liggende systeem al als een aanval gezien, of hoort er ook nog een fase bij waarbij je echt het systeem binnen dringt?

Het is inderdaad aannemlijk dat als er een backdoor in zit er niet in het commentaar bij staat "//FBI backdoor starts here" maar dat het op dusdanige manier is gedaan dat het zeer lastig te ontdekken is, zelfs met directe toegang tot de broncode.

Zoals ik al aangeef: het hoeft niet eens in de broncode te zitten; informatie kan ook op andere manieren lekken. En die lekken zijn verdomd lastig (if not near to impossible) te vinden.

Ik vind 't dan ook aardig voorbarig om binnen een paar dagen (wat, een anderhalve week?) nadat er bekend is geworden dat iemand door de FBI is omgekocht te roepen dat 't waarschijnlijk wel snor zit.

Wat hij doet/probeert is damage control. Hij vind het waarschijnlijk belangrijk om zo snel mogelijk met iets naar buiten te komen, om de klanten/gebruikers gerust te stellen en te voorkomen dat ze en masse op een ander systeem overstappen.

Daarnaast wordt Theo De Raadt door mensen die met hem te maken hebben gehad, vaak omschreven als eigenwijs, arrogant en iemand die altijd alles beter weet en het bestaan van (design) fouten binnen OpenBSD niet accepteert. Weet verder niet of het waar is want ik ken de beste man niet, maar vanuit dat oogpunt gezien verbaasd het me dus ook niet.

Daarnaast wordt Theo De Raadt door mensen die met hem te maken hebben gehad, vaak omschreven als eigenwijs, arrogant en iemand die altijd alles beter weet

Das een ding wat zeker is.
Meerdere mensen hebben binnen NetBSD aangegeven dat er met hem bijna niet te werken is. Zelfs Linus (ook niet echt de makkelijkste als je zijn usenet postings zit te lezen) heeft Theo omschreven als een "moeilijk" persoon.

Dat artikel over timing attacks is zeker leerzaam, eenvoudig stukje code dat twee waardes vergelijkt timen om te kijken hoeveel karakters je goed hebt...

De ontwikkelaar geeft toe dat de audit een lastige klus is en nooit perfect zal verlopen, aangezien de code te groot is.

Tot zover voor het argument dat OSS veiliger zou zijn dan closed software omdat de broncode voor iedereen toegankelijk is....

Sowieso is er natuurlijk maar een klein percentage lui die de code in kwestie onder ogen zal krijgen en een nog kleiner percentage van die mensen zal daadwerkelijk een idee hebben hoe 't in elkaar steekt (en hoort te steken). En dan nog, ook al is iedereen 't met elkaar eens dat het veilig is, is er kans dat er (onbedoeld) informatie lekt zoals ik hier uitleg.

Exact! en dat maakt het verschil met proprietary code kleiner dan veel mensen veronderstellen. In theorie zou dat verschil groter moeten zijn.
Het werkelijke verschil zit hem in het licentiemodel wat uiteindelijk een ander marktmodel geeft.

En wie controleert / audit ooit de cryptografie van Windows dan?

Daar zit het verschil, bij gesloten cryptografie heb je geen flauw idee of de versleuteling echt gaat zoals het moet en kan je niet controleren op problemen. Daarom is 'proprietary'-versleuteling dus nooit te vertrouwen en feitelijk waardeloos.

Als het open source is, valt het tenminste te controleren (en als je dat zelf niet kan huur je daarvoor wat mensen in), zoals nu dus gebeurt.

Waarom zou NSA anders voor een open schema te weten Rijndael hebben gekozen? Juist ja, als ze gesloten meuk hadden gekozen als AES hadden ze nooit kunnen verifieren dat het veilig was!

[Reactie gewijzigd door kidde op 24 december 2010 13:38]

En wie controleert / audit ooit de cryptografie van Windows dan?

Lenny_z?

Oh en jij denkt dat men die veiligheid standaard gaat controleren door de broncode door te nemen?
Nieuwsflits:
Men gebruikt test suites om de veiligheid van protocollen te testen, en dat kan prima op proprietary, gesloten software.

De cryptografische oplossingen zijn 99 van de 100 keer niet door de software ontwikkelaar zelf ontworpen. Bijvoorbeeld: Kerberos zoals standaard gebruikt als authenticatie protocol binnen Windows en beschikbaar op bijna alle systemen is ontworpen door het MIT, en bijna altijd is de manier van implementatie onderdeel van de beveiliging zelf, een gemeten werking is dus inherent aan de implementatie.

Daarom is 'proprietary'-versleuteling dus nooit te vertrouwen en feitelijk waardeloos.

Is dus complete ONZIN.

[Reactie gewijzigd door lenny_z op 24 december 2010 14:40]

Ik denk niet dat een test suite voldoende is. Als je een binary blob hebt waar aan de ene kant informatie in gaat en de andere kant informatie uit gaat die aan jouw test suite voldoet is dat mooi. Maar wat doet de binary blob allemaal nog meer ? Dat weet je dus niet, dat is het probleem.

Binnen Microsoft wordt het principe van eat your own dogfood gehanteerd. Microsoft draait vrijwel volledig op Microsoft software. Microsoft heeft er dus veel belang bij dat de cryptografie van Windows goed is.

Bovendien zijn er binnen Microsoft genoeg echte goeroes die veel vrijheid hebben om zelf kwaliteit te waarborgen, zonder dat ze door program managers met andere belangen gedwarsboomd worden. Microsoft heeft heel veel geld, dus de kosten hiervan is het probleem, wat vaak in andere bedrijven wel een probleem is. Uiteraard is dit een relatief kleine groep goeroes op een enorm veel groter aantal ontwikkelaars, maar zo zit de open source community ook in elkaar.

In mijn mening heeft kwaliteit van software meer te maken met hoe het ontwikkel team georganiseerd is, dan of de broncode wel of niet vrij beschikbaar is. Als je binnen je team snel het roer om kan gooien om bijvoorbeeld een grootschalige audit te organiseren is dat een teken van een goede flexibele organisatie die in staat is om zich zelf aan te passen.

Microsoft heeft dit bijvoorbeeld laten zien door tijdens de ontwikkeling van het oorspronkelijke Longhorn project, toen er veel veiligheidsproblemen in Windows XP bleken te zitten, het project volledig te stil te leggen, om Windows XP SP2 te ontwikkelen waarin de belangrijkste veiligheidsproblemen opgelost werden. Dat was een moeizame stap, maar uiteindelijk zijn ze wel als organisatie gegroeid.

Dit was de reden waarom er zoveel tijd tussen de release van Windows XP en Vista heeft gezeten. Hoewel je misschien ook zou kunnen zeggen dat Windows XP SP2 een interim release is tussen deze twee Windows versies. Iets wat eigenlijk ook de bedoeling van het oorspronkelijke Longhorn project was.

[Reactie gewijzigd door Arjen42 op 25 december 2010 09:21]

Er is geen enkele reden om te denken dat men niet bij het maken van de productie versie (lees: CD, DVD, etc.) niet gewoon even wat extra's kunnen toevoegen.

Er is al een lang en ingewikkeld proces om serialkeys, etc. toe te voegen waardoor een simpele md5/sha-1 waarschijnlijk al niet meer werkt van de data die op de media staat.

Wie gaat DAT controleren ?

[Reactie gewijzigd door Lennie op 26 december 2010 12:14]

Zo is er een bug in oudere versies van de Encapsulating Security Payload aangetroffen, die stilletjes in 2002 gedicht is.

Vond ik wel een opmerkelijk stukje, voornamelijk dat 'stilletjes' bij een open source OS.
Maar daarvoor heeft RobIII een redelijke mogelijke verklaring.

Dat is natuurlijk onzin omdat het hier over een audit gaat waar de complete code wordt doorgenomen i.p.v. alleen code die later is toegevoegd.

Dat is nou juist het punt. Het heeft blijkbaar een audit nodig die dit soort bugs boven water moet brengen, ipv dat de bugs er al uit zijn gehaald door de community.

Dat is nou juist het punt. Het heeft blijkbaar een audit nodig die dit soort bugs boven water moet brengen, ipv dat de bugs er al uit zijn gehaald door de community.

En wie doet deze audit dan? Mensen die deel uitmaken van de community. En wie fixen de gevonden bugs? Mensen die deel uitmaken van de community.

Waar gewerkt wordt, worden fouten gemaakt. Met open source kun je ze echter zelf oplossen, met closed source ben je volledig afhankelijk van de leverancier en zijn (verborgen) agenda.

De licentievorm zegt niks over de kwaliteit van de broncode, dat zijn twee totaal verschillende dingen. Of zou product X van bv. Microsoft ineens veel veiliger of juist onveiliger worden wanneer Microsoft de code openbaar maakt? Er verandert geen enkele regel code wanneer je de code openbaar maakt, dat kan dus niet.

En wie doet deze audit dan? Mensen die deel uitmaken van de community. En wie fixen de gevonden bugs? Mensen die deel uitmaken van de community

Niet dus. Althans....meestal niet.
Hier blijkt WEER dat het een groep van harde kern ontwikkelaars is die de hete kolen uit het vuur halen.
In de praktijk kom je ook bij Open Source ontwikkeling steeds weer dezelfde namen tegen die grote bijdragen leveren. De fragmentatie is niet zo groot als je dus zou denken, met die "enorme community" die potentieel een bijdrage zou kunnen leveren.
Ik bedoel...Theo De Raadt. Dat is zo'n beetje de Bill Gates/Steve Jobs/etc van OpenBSD.

Beetje onzinnige opmerking, iedereen weet toch dat bij OpenBSD 'de gemeenschap' gelijk is aan de 'harde kern ontwikkelaars' lijkt me. Vziw zijn het er ~80, voor het hele OS.

Bij Linux niet, daar hebben alleen aan de kernel al 6000 (IIRC) mensen meegewerkt, dat is exclusief GNU dus, Apache, Perl / Python o.i.d. Daar werken aan het gemiddelde server-OS dus tienduizenden mensen mee.

Theo de Raadt is niet "zo'n beetje de Bill Gates", maar de oprichter, dat lijkt me toch ook wel algemeen bekend.

En OpenBSD is tevens het enige OS waarvan bekend is dat er security-audits gedaan worden (jaarlijks), dat doet genoemde 'community' dus en daarbij komen zakan aan het licht die bij de meeste andere stukjes software nooit aan het licht zullen komen. Dus de opmerking 'er is kennelijk een audit nodig' getuigt ook van een gebrek aan kennis van OpenBSD, de community is altijd bezig simpele "fouten" te fixen (gebruik unsigned ints etc), deze audit is voor complexere zaken die niet gelijk evident zijn, zoals bijna alles bij cryptografie.

iedereen weet toch dat bij OpenBSD 'de gemeenschap' gelijk is aan de 'harde kern ontwikkelaars' lijkt me. Vziw zijn het er ~80, voor het hele OS.

Ja? En dat is toch wat ik zeg?
Dit topic gaat toch over BSD en niet over Linux? Dus als ik het heb over "de community" in deze context dan is dat de BSD community.

Theo de Raadt is niet "zo'n beetje de Bill Gates", maar de oprichter, dat lijkt me toch ook wel algemeen bekend.

Bill gates is boegbeeld en medeoprichter van MS. Theo de Raads is dat van OpenBSD.
Dat is wat ik zeg. Wat zeg jij nou eigenlijk?

En die opmerking over audits, kwam niet van mij.

Over beetje onzinnige opmerkingen gesproken.

Ik zie dit dan weer geheel anders, om even als voorbeeld ubuntu te nemen,

je kan de source code van de site downloaden en bekijken en voor eigen gebruik compileren.
De gemiddelde mens (waaronder ik) kijkt hier nooit na,
wat nu als canonical in zijn "uitgegeven" distributie 'die te downloaden is' een andere code met gaten gebruikt en een source code zonder gaten publiceert.

Hoe ontdekt men dit dan?
lijkt me stug dat je alles kan gaan testen.

Het gaat niet om bugs maar om een backdoor. Je moet je verder realiseren dat alle software bugs bevat, zelfs die van Nasa. Gemiddelde professionele software (die gereleased is) bevat grofweg tussen de 0.5 en 50 bugs per 1000 regels code*. Als je denkt dat je code geen audit nodig heeft, dan verzeker ik je dat dat aantal veel hoger ligt - niemand heeft dan immers de moeite genomen naar bugs te jagen en de ontwikkelaar lijdt aan gevaarlijke zelfoverschatting.

Ik snap hier de conclusie ook totaal niet. Omdat iedereen een audit kan doen op de OpenBSD code, is het in potentie veel veiliger. Dan moet de audit natuurlijk wel gedaan worden. Als er backdoors in windows code zijn ingebouwd dan kunnen alleen overheden zulke audits uitvoeren. (Voor overheden is er een contract beschikbaar om de broncode van windows in te zien). Na dit bericht zal ik OpenBSD juist meer vertrouwen, niet minder!

* http://amartester.blogspo...gs-per-lines-of-code.html

Het gaat niet om bugs maar om een backdoor.

Reageer on-topic alstublieft, we hadden het over bugs. De stelling was: OSS heeft minder security issues, wegens "bewaking door de community". Die bewaking blijkt dus niet echt volop aanwezig, maar moet worden aangewakkerd door een gerucht over een mogelijke backdoor. Als dat gerucht er niet was geweest dan had de audit ook niet plaatsgevonden.

Ik zeg niet dat dat bij closed source software (CSS) niet hoeft. In z'n geheel niet zelfs. Ik beweer juist dat OSS *in de praktijk* eigenlijk helemaal niet zoveel verschilt van CSS. Dus dan kun je wel aankomen met argumenten als "ja maar bij CSS is dat ook", maar ik heb nooit het tegengestelde beweerd.

[Reactie gewijzigd door .oisyn op 24 december 2010 15:14]

Ik denk dat er 1 fout in jouw logica zit. En dat is principes en motivatie.

De motivatie van bedrijven om software te maken is om geld te verdienen, principes spelen veel minder een rol.

Bij een community project zoals OpenBSD is dat niet, daar is men alleen geinteresseerd in zinnige code. Vooral in het geval van OpenBSD, zij kijken meer naar mooie code dan naar mooie features.

Als bij een amerikaans bedrijf zoals Microsoft een CIA, FBI of andere overheids instelling eist dat er een backdoor wordt toegevoegd aan hun systeem, wat denk je dat er gebeurt ? Aangezien het de overheid betreft van het land waar het bedrijf is gevestigd, denk ik dat ze best veel invloed kunnen uitoefenen.

Als we zo kijken naar wat bij AT&T, etc. met aftappen is gebeurt dan is het helemaal niet zo gek om te denken dat in Windows een backdoor in de productie versie zit.

Tot zover voor het argument dat OSS veiliger zou zijn dan closed software omdat de broncode voor iedereen toegankelijk is....

Ik zie niet in waarom dit argument nu niet meer geldig zou zijn.
De ontwikkelaar gaf toe dat de veiligheid van de BSD IP stack nooit voor de volle 100% gegarandeerd kan worden, maar dat heeft ook nooit iemand beweerd.
Bij OSS kan iedereen die twijfelt over eventuele backdoors eventueel zelf nagaan wat ervan waar is. Bij closed source moet je maar vertrouwen op de blauwe ogen van een of andere PR manager.

Bij OSS kan iedereen die twijfelt over eventuele backdoors eventueel zelf nagaan wat ervan waar is. Bij closed source moet je maar vertrouwen op de blauwe ogen van een of andere PR manager.

Iedereen x eventuele x eventuele is dus uiteindelijk pas als iemand aan de bel trekt. Ja het is een voordeel, maar het geeft een vals gevoel van veiligheid. Er is teveel code en te weinig mensen om er van uit te gaan dat - omdat het open source is - er naar gekeken is.

Ik zie niet in waarom dit argument nu niet meer geldig zou zijn.

Probleem met Open code is dat niemand verwacht dat het onveilig is omdat het open is. Maar zolang er niet naar gekeken wordt en iedereen maar denkt dat er mensen naar kijken is het onveilig.

Onzin. Dit voorval doet helemaal niets af aan de stelling dat Open Source veiliger is dan Closed Source.

Het enige dat het bewijst is dat Open Source niet 100% veilig. Maar dat beweert dan ook niemand.

Wat mijn persoonlijke mening hier over is is niet relevant, ik wilde alleen de fout in je logica aangeven.

+1
Bovendien bewijst het OSS_principe zich in deze nog steeds: vorige week worden er (zware) beschulidgingen geuit aan het adres van OSS-software en onmiddellijk komt er reactie op: iedereen kan de code doorzoeken en in dit geval wordt zelfs onmiddellijk een audit georganiseerd en publiekelijk gemaakt.

Zulks is onmogelijk bij closed source-software. Hoogstens kan daar een audit bevolen worden gekoppeld aan een NDA, waarbij de ontwikkelaar nog steeds bepaald wat er publiekelijk wordt gemaakt van de resultaten van de audit.

[...]

Tot zover voor het argument dat OSS veiliger zou zijn dan closed software omdat de broncode voor iedereen toegankelijk is....

Dat je de code kunt inzien, betekent niet automatisch dat de software veiliger is dan software waarvan je de code niet kunt inzien. Je kunt echter wel zelf een oordeel kunt (laten) vellen over het veiligheidsniveau van de code, dat gaat met closed source code niet lukken. Daar kun je namelijk niet bij komen.

Open source of closed source, het zegt iets over de toegang tot de code en niet over de kwaliteit van de code.

Beetje raar dat je zo reageert, voel je open source als een bedreiging? Lijkt mij niet nodig, beide soorten kunnen prima naast elkaar bestaan.

Maar het feit dat je een audit kunt doen is wel belangrijk. Hoe anders is dat met bijvoorbeeld de beveiliging van Mifare DESFire chips. Nu de documentatie op straat ligt zegt Mifare voorlopig niet meer de beveiliging te kunnen garanderen.

En daarbij dan een audit van tijd tot tijd absoluut geen kwaad. In Januari doen wij op onze eigen code ook een audit. Net als een auto moet je code goed onderhouden, maar toch moet de auto van tijd tot tijd een beurt hebben.

De IPSEC en TCP/IP stack zijn twee belangrijke stukken code welke in heel erg veel besturingssystemen is opgenomen.

Haha, je kan er nu tenminste wel een onafhankelijke audit op doen. Die mogelijkheid is met veel closed source code niet mogelijk.

Domme logica want je argument zegt niets over de relatie tot closed source software maar je conclusie gaat er wel over.

Die uitspraak is vaak kort door de bocht maar van jouw is dat dus ook! Ligt totaal aan de manier en wat!

Bijvoorbeeld een distro wil vooruitgang dan zullen er meer programmeurs aan vooruitgang werken dan aan bughunting. Nieuwe interface enz.

Debian bijvoorbeeld doet meer aan stabiliteit en staat vooruitgang in een wat minder hoog vaandel dus meer bughunting! --> ¨vaak¨ veiliger!

Over het algemeen zijn dingen die snel vooruitgang boeken populair in de maatschappij en is het dus: U vraagt wij draaien! En de maatschappij wil nog altijd iets veiligs maar vooral iets nieuws! (vooruitgang) Dus hier zullen meer ontwikkelaars zitten.

En nu komt het: Naar MIJN mening is opensource veiliger als closed source omdat je alles kunt inzien! Dat het niet altijd gebeurt is waar maar als een cracker een backdoor inbouwt in een code die niet goed gescreend is dan zal hij daar meer voordelen van hebben in closed source als in open source, de KANS is immers groter dat hij bij opensource tegen de lamp loopt als bij closed source!

En wie beweert dat dan nog steeds? Ben wel benieuwd naar je bron.

En wie beweert dat dan nog steeds?

Eh, zo'n beetje ALLE Open Source / Free software evangelisten.
Dat is zijn punt. Elke keer komt dat punt weer voorbij. (fora, documentatie, discussies..)
Dus een bron... bronnen TE OVER.
(bijvoorbeeld het officiele Ubuntu server boek)

Nu is het misschien kort door de bocht om te beweren dat het argument niet meer waar is... maar ik denk dat je wel kan stellen dat er in de praktijk minder waarde aan gehecht kan worden dan men in theorie doet. een STUK minder waarde.

[Reactie gewijzigd door lenny_z op 24 december 2010 11:58]

Ik dacht eigenlijk dat het argument van closed source vs. open source software altijd was dat als software bugs bevat (wat volgens mij niet te voorkomen is) deze bugs sneller in open source software gevonden en opgelosten worden dan in closed source software.

Dat is het ook. Het argument is altijd dat "de hele community" er naar kan kijken en software dus stabieler, veiliger en efficienter is dan proprietary software.
Dit is een te makkelijke aanname.

In de praktijk vallen deze voordelen imho enorm mee.
Uiteindelijk lijken de meeste software ontwikkelingen binnen Open Source veel op gesloten ontwikkel trajecten in dat er een handjevol mensen aan werkt, vaak binnen een "Red Hat" of een "Canonical". Hierbij lijkt ontwikkeling veel op proprietary software ontwikkeling. Er zijn ook trajecten die WEL gedragen zijn door de community en dus veel auteurs hebben. Hier is soms de fragmentatie ook een nadeel, helemaal als meerdere onderdelen uiteindelijk een geheel moeten vormen, zoals bij een OS het geval is of bij een grotere applicatie. Het zijn dan ook vaak niet de onderdelen op zich die niet goed werken, maar discrepantie tussen die onderdelen.
Direct inherent aan die zwakheid is de fragmentatie in organisatie.

Ik vind zo en zo "de software is beter, want Open Source" behoorlijk kort door de bocht.
Je kan veel beter uitspraken doen m.b.t. marktwerking en open source software (harde uitspraken) dan over de stabiliteit en veiligheid van software.

Dat is waar, en een paar grote bedrijven leveren ook software die dan later in Debian terecht komt (die dus geen commerciele software toestaat zonder source en GPL). Red Hat is een slecht voorbeeld van Linux of FOSS, om dat het zo goed als gesloten is, en vooral niet vrij of gratis.

Canonical is een bedrijf dat geld wil verdienen met support contracten, dus daar kan je het ook niet zoeken. Ubuntu drijft grotendeeld op Debian.

Software kan beter zijn om dat het Open Source is, zoals een driver of kernel, om dat je dan altijd de optie behoudt om oude drivers mee te nemen of nieuwe te schrijven als dat nodig is. Nu kan het zijn dat niet iedereen dat kan, maar de mensen die het wel kunnen zijn dus compleet op Open Source software aangewezen.

Ook als een universiteit een studie publiceert waar software van kan profiteren, zal Open Source software de eerste en makkelijkste plek zijn om iets dergelijks te implementeren. Verder geeft het je de mogelijkheid zeer selectief te zijn. Als je bijvoorbeeld zeker weet dat je geen Legacy I/O nodig hebt, dan kan je dat gewoon uit de kernel slopen. Of als je geheugen hebt met beschadigingen, dan configureer je je software zo dat die beschadigde plekjes niet gebruikt worden, maar alles er om heen wel.

Als je aan beveiliging doet en/of encryptie, heeft open source ook veel voordelen, om dat je dan de algoritmes kan verifieren. Gewoon een programma pakken en hopen dat het doet dat op de verpakking staat is een aanname, een aannames zijn nou niet meteen een best practice.

Klein voordeel is ook dat niemand je tegen kan houden als je iets wil doen. Bij een closed source vendor ben je compleet afhankelijk. Die afhankelijkheid pakt bijna altijd slecht uit. En als je bijvoorbeeld veel in-house ontwikkeling doet, of geen geld voor support level agreements hebt kan je niet bepaald op closed source bouwen of vertrouwen.


Gewoon domweg roepen dat FOSS / OS beter is dan andere software is inderdaad onzin, maar er zijn genoeg situaties en redenen waar het wel zo is.

Een black box in je situatie opnemen is altijd een slecht idee. (Waarbij je situatie van alles kan zijn; financieel, technisch, wettelijk enz. - als je een financiele zwarte doos hebt wordt je niet heel gelukkig, je weet niet wat er in of er uit gaat [naderhand wel] maar je zal nooit weten waarom, en hoe. Je zal het nimmer kunnen optimaliseren.)

Dat is waar, en een paar grote bedrijven leveren ook software die dan later in Debian terecht komt (die dus geen commerciele software toestaat zonder source en GPL). Red Hat is een slecht voorbeeld van Linux of FOSS, om dat het zo goed als gesloten is, en vooral niet vrij of gratis.

Canonical is een bedrijf dat geld wil verdienen met support contracten, dus daar kan je het ook niet zoeken. Ubuntu drijft grotendeeld op Debian.

Red Hat is open. Ze moeten wel vanwege GPL en anderen maken daar dankbaar gebruik van

Verder vraag ik me af waarom Red Had zo'n slecht voorbeeld is.
Enorm veel ontwikkelingen vanuit Red Had sturen Linux in het algemeen op dit moment. En canonical "drijft" voor een klein deel nog op debian, het is een groot en volwassen bedrijf en veel werknemers zijn oud debian devs.

Ik wil geen evangelist zijn voor proprietary software, maar ik vind wel dat mensen nogal overgevoelig doen m.b.t. dit onderwerp, bijna alsof het iets slechts is. En dat vind ik dan weer een beetje eng. RMS-achtige houdingen.

Open Source software heeft voordelen, maar ook nadelen.
Ik vind de fragmentatie in ontwikkeling een groot nadeel maar zie ook dat JUIST bedrijven als Red Hat die fragmentatie enigzins weten te beteugelen door EN als een commerciëel bedrijf het product te behandelen EN een proefbalon op te laten in de vorm van Fedora. (en Novell doet in feite hetzelfde)

Een oud UNIX spreekwoord is: "Tools, not policy".
Echter, ik ben van mening dat "policy" exact is wat Linux nodig heeft, ondanks al die mensen die roepen dat de kracht van Linux is dat je zoveel keus hebt, honderden distro's en kan kiezen wat je wil. Uiteindelijk is ook DIE fragmentatie voor bedrijven een zwaktebod, men wil duidelijke oplossingen.

Dat is tenminste op dit forum en op bijv webwereld een algemeen gemaakte opmerking.
Die bron is dus moeiteloos zelf even te vinden.

Ik was er ook nooit zo van overtuigd dat OSS per definitie veiliger is. Maar nu je echter ziet dat er zelfs bij vermoeden van een veiligheidslek al een een grootschalige audit op poten gezet wordt, geeft dat wel te denken.

En vervolgens heeft deze audit tot gevolg dat er geen backdoors gevonden zijn en enkele bugs al preventief worden opgelost. In dit geval bravo voor OSS. Een dergelijke operatie is vrijwel ondenkbaar als een bedrijf op de broncode zit.

Verder valt uit dit bericht op te maken dat overheidsinstanties bedrijven onder druk zetten om backdoors in te bouwen. De overheid heeft een behoorlijke leverage als afnemer en als regelgever. Het zou niet meer dan logisch zijn als men (succesvol) hetzelfde spelletje gespeeld heeft met amerikaanse OS makers. Je kunt het nooit meer achterhalen, want niet open source.

Dit artikel is het sterkste argument dat OSS per definitie veiliger is. Ik ben in ieder geval om. Ik heb niets te vrezen, maar zou me wel twee keer bedenken voor ik gevoelige informatie aan Windows of OSX propriety beveiligingslagen toevertrouw.

edit: om niemand voor het hoofd te stoten.

[Reactie gewijzigd door snirpsnirp op 24 december 2010 14:51]

Kul. Je hoort alleen maar wat je horen wilt en je hebt totaal geen verstand van programmeren.

In een closed source programma kunt je een backdoor stoppen die 50% van de code in beslag neemt en je zult het nooit weten. Net zo makkelijk als er een easter egg in code gestop kan zijn. En dat gebeurd ook vaak zat.

Om in open source software een backdoor te plaatsen moet je dat ongelovelijk goed verbergen want anders wordt ie vroeger of later gevonden. En dan heb je een heel subtiele extra functionaliteit die delen van de informatie oplevert die je wilt hebben en geen volledig inzicht in de andere partij zijn doen en laten. Net zoals het onmogelijk is om een easter egg in closed source code te stoppen en het echt verborgen te houden.

Sure... DAT hebben ze "lekker snel" bepaald!!
Zelfs als je weet waar je naar zoekt kun je dingen soms gewoon niet terugvinden in code die door anderen geschreven is. Of bugs in code die door jezelf geschreven is, kan ook nog. Honderden keren kan je erover heen lezen en die knullen hebben ALLE broncode van (moet ook nog de juiste code zijn heh, ik ga er vanuit dat de software waarvan gezegd is dat het een backdoor heeft niet uitgebreid reverse-engineerd is, zoals met stuxnet is gedaan en als ze niet de "juiste" broncode hebben dan zitten er natuurlijk geen backdoors in nee...) binnen een week heulemaal doorgenomen, voor de volle 100% correct.

Sure...

[Reactie gewijzigd door HotDoggie op 24 december 2010 10:35]

Natuurlijk hebben ze de juiste broncode. Ze beheren / zijn eigenaar van de complete sourcetree van OpenBSD en dus ook de IPSec stack die daarin zit. Uit die broncode worden releases van OpenBSD (en dus ook de IPSec implementatie van OpenBSD) gebouwd.

Er is geen enkele reden om aan te nemen dat ze niet de juiste sourcecode bekeken hebben.

Bovendien zijn dit niet de eerste de beste developers die iets leuks kunnen in PHP. Reken maar dat ze iedere bit code onder de loep hebben gehouden.

Hebben zij ook daadwerkelijk de hele IPsec stack gebouwd of hebben ze, net als heel veel platformen doen, bepaalde delen van a en b en c en d aangepast en op hun eigen manier geimplementeerd?

Voor zover ik weet is de IPSec stack van (Open)BSD uniek. Hij wordt wel gebruikt door zuster-projecten FreeBSD en NetBSD, en volgens mij wordt hij ook elders gebruikt (je mag 'm relicensen per slot van, dus hij kan zo in GPL code terecht zijn gekomen).

Nou er is een zekere druk om het zeker te weten...daar iedereen mee kan kijken!
En Theo de Raadt is nou niet echt een knulletje. (i.e. grondlegger OpenBSD)

Alhoewel een audit altijd een goed idee is, heb ik wel mijn twijfels bij de beweringen van mr Perry. Waarom zou de FBI in 2000 particulieren inhuren om backdoors in te bouwen met een NDA van slechts 10 jaar? Ik meen dat die dingen pas zoveel jaar na je dood verlopen als je werkt met een dienst als de FBI.

Een NDA klinkt ook als een commercieel Beding dat gemaakt is, niet een veiligheids beding in lopende zaak. Je moet bij het aannemen van klussen ook waken dat je vervolgens niet meer in dat veld zou kunnen werken.

Het verhaal is immers ook dat FBI (niet NSA?) een commerciële opdracht heeft geven om iets te ontwikkelen.

Als er afbeeldingen geplaatst konden worden zou ik in dit geval kiezen voor de Iraakse minister van informatie.

Nou moet ik zeggen over de veiligheid van software dat ik niemand ken die van opensource programma's even de broncode gaat bekijken voor mogelijke veiligheidslekken, dus, het is ook niet heel verwonderlijk als men het lek niet tegen is gekomen.

En als men echt bang is voor de veiligheid van OpenBSD, dan richt je je ASA gewoon zo af dat de informatie van en naar de FBI gedropt wordt ? Of, je gebruikt de VPN functionaliteit van een externe machine totdat de veiligheid van OpenBSD bewezen is

Heb je als sysadmin ook nog iets te doen behalve koffie drinken en tweakers lezen

Uhm logica: Bijna alle transactie systemen draaien Linux/Unix. Geld en Defensie zijn 2 dingen die zeer belangrijk zij voor een maatschappij!

Ik weet dat er bij banken enorm veel bughunters werken! Om beveiligingsreden zeggen ze vaak niet van ik ben gedatacheerd bij ABN of wie dan ook, er is namelijk een kans op ontvoering! Enz.

Daarnaast vaak zijn black en gray hat´s meer open over wat ze werkelijk doen dan white hat´s en dat zijn voornamelijk bughunters. Ook werken hackers zowel black als White vaak alleen voor de gemeenschap en willen niet altijd aandacht krijgen van anderen.

Oftewel die man met de koffer en een bril die bescheiden is en zegt ik ben gedetacheerd programmeur op een conferentie, Kan het dagelijks leven best 2 man bewaking hebben en de aix constant op bugs hunten. (ik geloof dat hier dagelijks minimaal 30 man zit te hunten overigens) Dit weet jij niet als je hem zo spreekt! En waarschijnlijk vertelt hij dat ook nooit aan jou!

En nee ik ken niemand die dat doet.

[Reactie gewijzigd door rob12424 op 26 december 2010 00:46]

En waarschijnlijk vertelt hij dat ook nooit aan jouw!

klik