Kritiek lek in Linux-kernel geeft root-toegang

Via een kwetsbaarheid in het keyring-subsysteem van de Linux-kernel is het mogelijk om code in de kernel uit te voeren. Dat meldt het beveiligingsbedrijf Perception Point. Het lek zou al sinds Linux-kernel 3.8 aanwezig zijn, ofwel sinds 2012. Er is inmiddels een patch beschikbaar.

Bug CVE-2016-0728 heeft tot gevolg dat lokaal root-rechten kunnen worden verkregen, wat betekent dat de aanvaller al beperkte rechten moet hebben. Omdat de kwetsbaarheid al sinds 2012 in het systeem zit, betekent het dat ook 66 procent van de Android-telefoons kwetsbaar is, doordat die kernel 3.8 of hoger draaien. Dat schrijft Perception Point op zijn site. Daar komen nog eens tientallen miljoenen Linux-pc's en -servers bij. Vooralsnog is de exploit niet in het wild gezien, maar het is de ontdekkers van het lek al wel gelukt een proof-of-concept te maken.

Het lek wordt veroorzaakt door een reference leak in de keyring-functie, waarmee drivers beveiligingsdata, authenticatiesleutels, encryptiesleutels en andere data kunnen cachen of behouden in de kernel. De kwetsbaarheid maakt het voor een aanvaller mogelijk om code in de kernel uit te voeren en daarmee vervolgens root-rechten te verkrijgen.

Al met al duurt het wel relatief lang om de exploit te gebruiken. Het duurt ongeveer 30 minuten op een Intel Core i7-5500, schrijft het team, al is tijd niet zo relevant bij een dergelijke exploit. Het Red Hat Security-team heeft geholpen de bug te pletten. De onderzoekers sluiten af met de mededeling dat SMEP en SMAP het wel lastig maken de bug te misbruiken, net als SELinux op Android. Volgens Threatpost kan het voor Android-toestellen langer duren voordat patches beschikbaar komen, omdat fabrikanten deze zelf moeten uitbrengen.

Reacties (126)

[dormamu]

Met andere woorden vier jaar niet ontdekt hoewel het Open source is. Laat maar weer eens zien dat Open source niet the Holy Grail is met betrekking tot software ontwikkeling en beveiliging.

[stuiterveer]

Klopt, maar omdat de broncode door iedereen ingezien kan worden is de kans wel enorm hoger dat iemand een fout aantreft waardoor dit ook aangepakt kan worden.

Open source ≠ bugvrij, wel is het de gateway naar betere communicatie en ondersteuning voor software.

[Ozzy]

Als het waar is wat je zegt is het volgende statement ook waar : Omdat de broncode door iedereen ingezien kan worden is de kans wel enorm groter dat iemand een fout aantreft waardoor hij dit kan misbruiken.

Ik ben er overigens niet zo zeker van dat (één van) beide waar zijn. Dat komt vooral omdat over het algemeen ernstig wordt overschat hoeveel mensen a) die code lezen en b) hoeveel mensen die code ook daadwerkelijk grokken.

[CAPSLOCK2000]

Als het waar is wat je zegt is het volgende statement ook waar : Omdat de broncode door iedereen ingezien kan worden is de kans wel enorm groter dat iemand een fout aantreft waardoor hij dit kan misbruiken.

Dat is een heel redelijke gedachte, voor allebei is iets te zeggen. Gelukkig hebben we wetenschappers die dit soort dingen onderzoeken!

Er zijn verschillende onderzoeken op internet te vinden. Zo zijn er onderzoeken geweest die het aantal fouten in de broncode van verschillende projecten hebben geteld. Andere onderzoeken kijken naar hoeveel systemen er in praktijk gekraakt worden en waarom.

Ik ben er overigens niet zo zeker van dat (één van) beide waar zijn. Dat komt vooral omdat over het algemeen ernstig wordt overschat hoeveel mensen a) die code lezen en b) hoeveel mensen die code ook daadwerkelijk grokken.

Een aspect dat vaak vergeten wordt is dat je zelf actie kan ondernemen als er iets mis gaat. Vooraf alle code die je gebruikt vooraf fout-vrij maken is niet te doen. Op het moment dat je merkt dat er iets mis gaat ingrijpen is een stuk beter te doen, je hoeft dan alleen het stukje te begrijpen waar het probleem zit.

Bij closed source ben je altijd afhankelijk van de leverancier. Als je een dringend probleem tegen komt is het maar de vraag of je leverancier het ook dringend vindt en het probleem snel gaat oplossen.
Voor een bedrijf kan het dan erg prettig zijn om zelf iemand op het probleem te zetten. Niet iedereen kan dat, maar als je organisatie maar groot genoeg is, zoals mijn werkgever, dan heb je mensen in dienst die dat wel kunnen. Niet dat je alles zelf kan oplossen maar de meeste bugs zijn eigenlijk vrij simpel en zonder veel specialistische kennis te verhelpen of te omzeilen, als je maar even bij de code kan.

[drdelta]

Een aspect dat vaak vergeten wordt is dat je zelf actie kan ondernemen als er iets mis gaat.

Wat kan ik, als niet programmeur, ondernemen om mijn kwetsbare Android telefoon veilig te krijgen voor deze bug, dan? Vrij weinig vrees ik.

[84hannes]

Als wel-programeur denk ik dat ik mijn laatste Android-telefoon jaren geleden heb gekocht. De manier waarop fabrikanten hun telefoons ondersteunen is volledig in strijd met de Open Source-gedachte. Ik zeg niet dat commerciele activiteiten en open source incompatible zijn, (kijk naar bijvoorbeeld Red Hat), maar de fabrikanten van de huidige generatie Android-telefoons heeft geen boodschap aan communities, dus ik heb geen boodschap aan deze fabrikanten.
Overigens ligt dit ook aan de relatieve onvolwassenheid van het ARM-platform. Waar het goed te doen is om een algemene Linux-distributie uit te brengen die op 99% van de x86-pc's werkt, lijkt het onmogelijk te zijn zoiets voor een mobiele telefoon te doen. Dat ondanks het feit dat de meeste fabrikanten inmiddels mogelijkheden bieden je eigen rom te installeren.

[kreezjie]

Wat zou je anders kopen? iOS? Windows?
Veel keuze heb je niet en op die andere platforms moet je ook niet veel ondersteuning of communicatie verwachten hoor...

[84hannes]

Apple brengt nog jarenlang updates uit voor oude telefoons. Daar betaal je een prijskaartje voor, maar ik vraag me af of dat het niet waard is. Ik had een Jolla, elke twee maanden netjes een update, maar vreemd genoeg is het aantal updates hard afgenomen sinds ze alle ontwikkelaars naar huis moesten sturen. Hoe Microsoft het op telefoons aanpakt weet ik niet. Op PC's is het updatemechanisme van Windows natuurlijk tijdrovend en irritant (t.o.v. Linux althans), maar er is in elk geval een updatesysteem. De tijd dat dat een luxe-feature was ligt ver achter ons, en dat lijken de meeste Androidtelefoonfabrikanten zich niet te willen realiseren.

[geertdo]

Hoe Microsoft het op telefoons aanpakt weet ik niet. Op PC's is het updatemechanisme van Windows natuurlijk tijdrovend en irritant

Op Windows 10 Mobile moet ik zeggen dat updates erg vlot gaan en zonder provider, rechtstreeks via WiFi.
Je kunt, mocht de telefoon daarna opnieuw opgestart moeten worden, het opstarten plannen.
Dat vind ik toch wel erg luxe

[latka]

Android is dan ook niet echt open source: zit vol met binary blobs. Beter voorbeeld is je PC: die kun je wel voorzien van een nieuwe kernel zonder de bug. Punt is dat als de bug was gevonden in Linux 2.0 uit de vorige eeuw dan was er nog een patch voor beschikbaar. Wel zo fijn t.o.v. closed source waar de kans dat er een patch komt als het product uit support is onder het nulpunt daalt. Daarom opensource.

[N8w8]

Als niet-programmeur heb je natuurlijk zelf niks aan source code, want die is om te programmeren. Wil/kan je dat niet (om wat voor reden dan ook), ja dan houdt het gewoon op.
Maar je kan wel de vruchten plukken van wel-programmeurs, die daar wel wat aan hebben en daarmee mods kunnen maken.
Voor zover er een goeie mod community is voor jouw telefoonmodel dan, wat natuurlijk sterk verschilt. Maar daar kies ikzelf dan ook mn telefoon op uit.
Of desnoods kan je als niet-programmeur, een wel-programmeur betalen om het voor jou aan te passen. Of het zelf leren. Daar ben je vrij in.
Bij closed source kan je bepaalde mods meestal wel vergeten, kan alleen de fabrikant die doen.

[CAPSLOCK2000]

Wat kan ik, als niet programmeur, ondernemen om mijn kwetsbare Android telefoon veilig te krijgen voor deze bug, dan? Vrij weinig vrees ik.

Je kan iemand betalen om het voor je te doen of je kan het zelf leren. Je verliest niks ten opzichte van closed source, je hebt er alleen mogelijkheden bij gekregen.

[Anoniem: 668730]

Een aspect dat vaak vergeten wordt is dat je zelf actie kan ondernemen als er iets mis gaat.

Dit is in mijn ervaring het doorslaggevende argument voor open source software.

Security bugs vormen eigenlijk maar een klein deel van alle problemen waar ik zelf tegenaan loop. Veel vaker zijn het kleine functionele bugs of tekortkomingen die eenvoudig aangepast kunnen worden.

Dat kun je dan zelf doen, aan de originele ontwikkelaar vragen, of een willekeurige programmeur voor inhuren. Mits je een beetje redelijk inzicht hebt in wat wel en niet technische haalbaar is komt je eigenlijk nooit voor onoverkomelijke verassingen te staan. Bij "gesloten" software moet je maar hopen dat de ontwikkelaar meewerkt en/of redelijke prijzen hanteert.

[mbijkerk]

Bij closed source ben je altijd afhankelijk van de leverancier. Als je een dringend probleem tegen komt is het maar de vraag of je leverancier het ook dringend vindt en het probleem snel gaat oplossen.

Dit is dus precies wat ik altijd zeg tegen mensen die zeggen dat Linux niets is. Bij bijvoorbeeld Red Hat is een fix zo geregeld, soms zelfs dezelfde dag nog en je hoeft je geen zorgen meer te maken om dat lek. Tevens vind ik Windows Server ook wat instabieler aanvoelen dan bijvoorbeeld Debian of Red Hat etc. op servers en draait linux soms rustig 10 jaar door zonder 1 enkele herstart.
Ik heb het 1 keer aangeven op Windows toen iets fout ging en ik het foutrapport kon verzenden. 10 minuten later na alles netjes op een rijtje gezet te hebben was het verzonden en daarna nooit meer wat van gehoord ook.. en de bug nog maanden ervaren .

Het mooiste zou ik vinden als er meer software (dat je op Windows gebruikt) naar Linux distro's zou komen net als games. EA zei ooit Battlefield 3 naar Linux te brengen maar heb het nooit gezien, dit maakt het voor veel Windows gebruikers ook mogelijk Linux te gaan gebruiken.
Maar dit zal vast nog wel komen

[tc-t]

Dat zou kunnen, maar hoeft niet per definitie zo te zijn.

Het kan best dat de onderzoeker/hacker het lek op een andere maniet gevonden heeft dan door de broncode door te spitten.
In dat geval doet open of closed source niet terzake: hij/zij had het op die manier hoedanook gevonden.

[Denni]

Wat Ozzy zegt is in een boolean algebra het element/statement "Iedereen kan de broncode inzien dus neemt de kans op het vinden van fouten toe en kunnen ze opgelost worden" een compositie van drie elementen "iedereen kan de broncode inzien"->"de kans op het vinden van fouten neemt toe"->"de fouten kunnen opgelost worden". Het woord "kunnen" impliceert echter dat het statement "de fouten worden opgelost" niet volledig is. En zoals Ozzy zegt kun je inderdaad een statement toevoegen. "iedereen kan de broncode inzien"->"de kans op het vinden van fouten neemt toe"->("de fouten kunnen opgelost worden"^"de fouten kunnen misbruikt worden"). Uiteraard kan er nog meer gebeuren, bijvoorbeeld "niks", maar het punt is dat met de kans op het oplossen van fouten dus ook de kans op het misbruiken van fouten toeneemt.

Dat er andere wegen zijn om fouten in een OS te ontdekken heeft niet zoveel met het statement van Ozzy te maken.

[wvbe]

Dan graag ideeën betreft hoe code te delen met officiële en niet-officiële talenten, maar niet met kwaadwillende hackers. Je zult moeten berusten op een community van mensen die over het algemeen geen motivatie hebben om kwaliteit te dwarsbomen (eg. geld verdienen, de kosten van doorontwikkeling vermijden, gezichtsverlies bij het toegeven van een bug/hack vermijden). Natuurlijk is open-source niet waterdicht, maar ik denk dat juist transparantie rottigheid effectief bestrijdt *.

* da's een kwestie van mening, heb ik geen bron voor

[84hannes]

Dan graag ideeën betreft hoe code te delen met officiële en niet-officiële talenten, maar niet met kwaadwillende hackers.

Through the Shared Source Initiative Microsoft licenses product source code to qualified customers, enterprises, governments, and partners for debugging and reference purposes.
Ongeregistreerde talenten van ongeregistreerde hackers onderscheiden is natuurlijk onmogelijk, dat wist je zelf ook toen je die zin formuleerde. Ik zeg niet dat ik liever Shared Code dan Open Source heb, maar ik snap de redenatie van Microsoft.

[wvbe]

Het is ook onderdeel van het punt dat ik probeer te maken.

• De open-source projecten waar ik tot nu toe aan heb bijgedragen heb ik me niet eerst voor aangemeld, community gejoined, formulieren ingevuld of wat anders. Als ik dat moet doen voordat ik überhaupt weet hoe ik bij moet dragen denk ik dat er niet veel gebeurd.
• Iemand van het ene kamp altijd nog naar het andere kamp omzwaaien. Hoe waarschijnlijk dit is (waarschijnlijk genoeg IMHO) is niet eens relevant omdat het systeem bij de eerste convert al faalt.

Dus ja, het is onmogelijk om ze van elkaar te onderscheiden en juist daarom is closed/shared source schijnveiligheid.

[Jeanpaul145]

Dat hangt ervan af. De gemiddelde huis tuin en keukencoder zal niet zomaar in willekeurige sources rondneuzen nee. Maar wat denk je van de hack units van China's PLA? Als je ergens binnen wil komen is het verdomd handig om in de sources ervan in te kunnen zien. Dat is de negatieve kant van het verhaal.

De positieve kant is dat er weldegelijk veel bugs gefixt worden, oa. omdat coders die code willen gebruiken en tegen issues aanlopen. GitHub is een geweldige plek om dit te zien gebeuren.

Dus het punt is dat open source weldegelijk mogelijkheden biedt tov proprietary source, en dat die mogelijkheden flink benut worden ook.

[latka]

Echte hackers gebruiken de source als leidraad: naast bugs in de code zijn er ook bugs die ontstaan met veilige code met een brakke compiler (voorbeeld: Microsoft Visual C: https://bugzilla.mozilla.org/show_bug.cgi?id=977538). Echte hackers/mannen pakken de disassembly erbij om de gaten te vinden. Daar heb je geen source voor nodig.

[koelpasta]

De positieve kant is dat er weldegelijk veel bugs gefixt worden, oa. omdat coders die code willen gebruiken en tegen issues aanlopen.

Eeh. Nou. Dat proces levert anders ook veel bugs op.
Juist als je andermans code gaat gebruiken kan het zijn dat je een aanpassing moet doen voor jouw specifieke situatie. En dat betekent dat je je zooi niet voor andere situaties hebt getest.
En het proces van forken maakt het nog complexer. Als er een bug wordt gevonden in het origineel dan zullen alle forks dat ook moeten gaan oplossen.

[stuiterveer]

Als het waar is wat je zegt is het volgende statement ook waar : Omdat de broncode door iedereen ingezien kan worden is de kans wel enorm groter dat iemand een fout aantreft waardoor hij dit kan misbruiken.

Klopt, dat is een risico waarop de ontwikkelaar voorbereid moet zijn. Zorg daarom dat je bij beveiliging de risico's grondig naloopt.

Dat komt vooral omdat over het algemeen ernstig wordt overschat hoeveel mensen a) die code lezen en b) hoeveel mensen die code ook daadwerkelijk grokken.

Ook daarom: zorg dat je bij beveiliging de risico's grondig naloopt.

[Fairy]

Als het waar is wat je zegt is het volgende statement ook waar : Omdat de broncode door iedereen ingezien kan worden is de kans wel enorm groter dat iemand een fout aantreft waardoor hij dit kan misbruiken.

En bij closed source is het ook makkelijk om te zeggen dat als met de broncode niet kent, er niet zomaar ingebroken kan worden. Hebben ze een omschrijving voor: "security through obscurity". Ook dat is echter geen heilige oplossing. Open source kan in principe door iedereen gepatched worden, maar ook misbruikt. Echter closed source is erg gevoelig voor misbruik vanuit overheden en mensen die de broncode wél in bezit hebben.

Als een Microsoft of Apple een aanpassing doe aan windows waarop een speciaal wachtwoord altijd werkt, zullen we daar misschien niet zomaar achter komen, totdat het werkelijk gedaan wordt. Bij open source valt dit direct door de mand.

[dormamu]

Het is een illusie te denken dat als er meer mensen er naar kunnen kijken dat bugs dan sneller gevonden worden. Het gaat niet om het aantal mensen maar om de noodzakelijke kennis en laat het aantal mensen met de juiste kennis hiervoor per definitie al beperkt zijn.

[stuiterveer]

Daar heb je gelijk in, al heb ik hier wel wat extra toelichting op gegeven in de volgende comment: http://tweakers.net/nieuw...eaction=8135310#r_8135310

Er zal inderdaad een vrij laag percentage zijn dat daadwerkelijk kennis zal hebben van de gebruikte source (afhankelijk van de gebruikte programmeertaal, even niet uitgaande van enkel Linux aangezien er nog meer zaken open source zijn), al is het wel zo dat niet enkel de ontwikkelaars van het programma hiervan kennis zullen hebben. Dit betekent dus alsnog dat je meer mensen in staat stelt problemen vast te stellen.

[mae-t.net]

Het aantal is per definitie beperkt, maar je vergelijkt het met een aantal dat per definitie nog beperkter is. Dat kan dus nog steeds in het voordeel van openbronsoftware uitpakken.

De andere belangrijkste manier om fouten te vinden, uitproberen en reverse engineeren, is meer een wet van grote aantallen. Daarvan zal veel werk aan Windows plaatsvinden (al moet je niet het belang onderschatten van het kapen van webservers, die juist vaak openbronsoftware draaien).

[Anoniem: 28912]

Het is een illusie te denken dat als er meer mensen er naar kunnen kijken dat bugs dan sneller gevonden worden. Het gaat niet om het aantal mensen maar om de noodzakelijke kennis en laat het aantal mensen met de juiste kennis hiervoor per definitie al beperkt zijn.

Dat kan wel kloppen, maar dat is voor closed source nog veel meer het geval. Sterker nog met het verloop binnen een commercieel bedrijf zullen er hele stukken broncode te vinden zijn waar niemand meer precies weet of snapt waarom dat gedeelte zo in elkaar is gezet.

[W00fer]

Hoeveel mensen bezitten ook de kennis om daadwerkelijk dit soort dingen te ontwikkelen en door te spitten? Dit is niet iets wat de eerste de beste Linux devver tegenkomt in zijn dagelijkse gang van zaken.

Zijn er eigenlijk bounty's te verdienen net zoals bij Facebook voor het opsporen en melden van dit soort gevaarlijke lekken?

[bbob]

antwoord op jou vraag is geheime diensten spitten dit altijd door,hebben het geld en dus kopen ze de kennis hiervoor.

[Gomez12]

Alleen melden ze over het algemeen niets terug maar misbruiken het voor hun eigen doeleinden.

Net zoals black hat hackers ook de kennis ervoor hebben, er actief naar op zoek zijn maar nooit iets terug zullen melden omdat ze het zelf ge-/misbruiken.

[stuiterveer]

Wat betreft bounty's kan ik geen officiële zaken terugvinden, wel zijn er initiatieven van gebruikers zoals https://www.bountysource.com/.

Er zal inderdaad een vrij laag percentage zijn dat daadwerkelijk kennis zal hebben van de gebruikte source (afhankelijk van de gebruikte programmeertaal, even niet uitgaande van enkel Linux aangezien er nog meer zaken open source zijn), al is het wel zo dat niet enkel de ontwikkelaars van het programma hiervan kennis zullen hebben. Dit betekent dus alsnog dat je meer mensen in staat stelt problemen vast te stellen.

[YDh]

Je kunt het tweede deel van je zin perfect omdraaien:

Klopt, maar omdat de broncode door iedereen ingezien kan worden is de kans wel enorm hoger dat iemand een fout aantreft waardoor dit ook aangepakt kan worden en deze actief gaat misbruiken zonder aan iemand iets te zeggen.

Ik blijf voorstander van open source omwille van verscheidene redenen (didactisch, vooruitgang, levensduur, ...) maar wat betreft veiligheid zie ik echt weinig meer- of minderwaarde.

[stuiterveer]

stuiterveer in 'nieuws: Kritiek lek in Linux-kernel geeft root-toegang'

Bottom line:
Dat is een risico waarop de ontwikkelaar voorbereid moet zijn. Zorg daarom dat je bij beveiliging de risico's grondig naloopt.

[Gomez12]

Bottom line:
Dat is een risico waarop de ontwikkelaar voorbereid moet zijn. Zorg daarom dat je bij beveiliging de risico's grondig naloopt.

Zinloze bottom line, er worden nu eenmaal fouten gemaakt (want anders had je geen bugs) en dus ook in de beveiliging.

Dan kan je 100x zeggen : Grondiger nalopen, maar er worden gewoon fouten gemaakt en die zullen er dus in blijven zitten.

[atlaste]

Klopt, maar omdat de broncode door iedereen ingezien kan worden is de kans wel enorm hoger dat iemand een fout aantreft waardoor dit ook aangepakt kan worden.

Wat een onzin. Vrijwel alle exploits van dit type maken gebruik van buffer overflows om code te injecteren die vervolgens geexecuteerd wordt. Meestal loop je daar tegenaan omdat je rare dingen ziet bij het gebruiken van een API; hackers gaan gewoon op zoek naar dit soort signatures en proberen de situatie te forceren.

Inmiddels weten we ook dat partijen als de NSA proberen dergelijke situaties gewoon in te bouwen als back-door. Die doen dat net zo goed bij open source (hiding in plain sight) als bij closed source (koop een medewerker om bij Microsoft).

Kortom: open source of closed source maakt volgens mij echt geen pepernoot uit.

[Anoniem: 205328]

Het kan ook zijn dat ze wisten dat ze bestonden, maar het zaten te verbergen

3.!! Linux developers have a tendency to a) suppress news of security holes b) not notify the public when said hole have been fixed c) miscategorize arbitrary code execution bugs as "possible denial of service" (thanks to Gullible Jones for reminding me of this practice - I wanted to mention it aeons ago, but I kept forgetting about that).

Here's a full quote by Torvalds himself: "So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special."

Year 2014 was the most damning in regard to Linux security: critical remotely exploitable vulnerabilities were found in many basic Open Source projects, like bash (shellshock), OpenSSL (heartbleed), kernel and others. So much for "everyone can read the code thus it's invulnerable". In the beginning of 2015 a new critical remotely exploitable vulnerability was found, called GHOST.

Year 2015 welcomed us with 134 vulnerabilities in one package alone: WebKitGTK+ WSA-2015-0002. I'm not implying that Linux is worse than Windows/MacOS proprietary/closed software - I'm just saying that the mantra that open source is more secure by definition because everyone can read the code is apparently totally wrong.

Many Linux developers are concerned with the state of security in Linux because it is simply lacking.

Bron

[Blokker_1999]

Ik zou toch even willen opmerken dat shellshock an sich geen bug was maar dat bash gewoon werkt zoals het ontworpen is. Het toont vooral aan dat bash afkomstig is uit een tijd waarin het gebruik ervan veel beperkter was en men er nog niet aan had gedacht dat zoveel andere applicaties dit zouden gaan gebruiken als een interpreter.

Vele FOSS gebruikers weten ook dat het open karakter van de broncode echt niet betekend dat deze projecten niet vatbaar zijn voor bugs of dat bugs daarom minder snel opgelost worden. De belangrijkste reden om voor open source te kiezen is net dat je wel volledig inzicht kunt krijgen, indien gewenst, in de code van je software en dat je nooit met een vendor lock-in te maken zult hebben.

Toch blijf ik geloven dat open source inherent veiliger is dan closed source. Daarom niet minder vatbaar voor bugs of virussen, maar omdat deze projecten vaak zijn opgebouwd met veiligheid in gedachten en net omdat bij het ontdekken van een bug de benodigde patch binnen enkele uren op de eerste systemen geïnstalleerd staat.

[Anoniem: 28912]

Klopt dat shellshock gewoon een feature i.p.v. een bug. Dat bepaalde ontwikkelaars programma's gaan gebruiken waar ze totaal niet voor bedoeld zijn, verandert de doeleinden van een programma niet.

Als je FORMAT.COM gebruikt om de label van je medium te veranderen, is het geen bug dat je het medium ook meteen leegmaakt.

[Spekkie88]

Het voordeel van opensource is niet direct dat er minder fouten in zitten, maar vooral dit:

Het Red Hat Security-team heeft geholpen de bug te pletten.

Bij opensource software (en zeker populaire opensource projecten als de linux kernel) ben je niet afhankelijk van 1 bedrijf die de source in handen heeft om het probleem op te lossen, maar kan "iedereen" te hulp schieten.

[Anoniem: 310408]

Bij opensource software (en zeker populaire opensource projecten als de linux kernel) ben je niet afhankelijk van 1 bedrijf die de source in handen heeft om het probleem op te lossen, maar kan "iedereen" te hulp schieten.

Maar hier is het dus gedaan door een betaald team van Red Hat. Niets mis mee hoor, goed dat Red Hat het deed.

[Spekkie88]

Dan nog, als je een bug in windows vind kan je er nog zoveel betaalde programmeurs tegenaan gooien als je wil maar opgelost krijg je het niet, totdat microsoft zelf met een oplossing komt.

Opensource hoeft ook helemaal niet per definitie gratis te zijn/onderhouden te worden.

[geertdo]

Opensource hoeft ook helemaal niet per definitie gratis te zijn/onderhouden te worden.

Open Source is per definitie gratis.

Dan nog, als je een bug in windows vind kan je er nog zoveel betaalde programmeurs tegenaan gooien als je wil maar opgelost krijg je het niet, totdat microsoft zelf met een oplossing komt.

Dat kan ook voordelig zijn. En gelukkig hebben ze een update mechanisme :-) Uiteraard hoop ik dat Windows ooit open source wordt

[Reactie gewijzigd door geertdo op 26 juli 2024 11:32]

[DenBeke]

Open Source heeft NIETS te maken het met al dan niet gratis/betaald zijn van software...

[geertdo]

Weer die discussie, maar dat geeft niet

De basis van open source is de 'open definition'. Er was altijd ruimte voor interpretatie, maar dat is nu voorgoed opgelost.

Voor handelingen omtrent de code mag wel geld gerekend worden, maar voor de code zelf nooit.

[Reactie gewijzigd door geertdo op 26 juli 2024 11:32]

[- peter -]

Jij mag gewoon geld vragen voor opensource code hoor.

[geertdo]

Natuurlijk. Maar je kunt degene aan wie je de source code 'verkoopt' niet weerhouden om het gratis weg te geven. Je betaalt niet voor de source code, maar voor de dienstverlening.

Lees https://opensource.org/osd

Regel 1

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

De source is gratis. Altijd. Anders heet het geen 'open source'.

[Anoniem: 28912]

Lees https://opensource.org/osd

De source is gratis. Altijd. Anders heet het geen 'open source'.

Erg vreemde bron die je daar aanhaalt.

Als ik "Open Source" hoor, denk ik gelijk aan GNU, FSF, Stallman en GPL. Niet aan een vreemde club uit Californië genaamd OSI die de klok hebben horen luiden, maar niet weten waar de kepel hangt.

[Hoopje]

Als ik "Open Source" hoor, denk ik gelijk aan GNU, FSF, Stallman en GPL. Niet aan een vreemde club uit Californië genaamd OSI die de klok hebben horen luiden, maar niet weten waar de kepel hangt.

Dat is vreemd, want de OSI heeft de term "open source" uitgevonden (of preciezer: een van de oprichters van de OSI, Eric S. Raymond, heeft de term uitgevonden). Stallman en zijn clubjes praten consequent of "free software" en gebruiken "open source" alleen om naar de OSI te verwijzen.

De FSF heeft een zeer ideologische inslag: het gaat hen om de vrijheid (in teksten van GNU of FSF komt dan ook gevoeld om de zin het woord "freedom" voor). De OSI denkt veel pragmatischer over open source. Met uitzondering van enkele randgevallen komen open source en vrije software echter overeen: de belangrijkste licenties zijn zowel vrije software als open source.

[Anoniem: 28912]

[...]


Dat is vreemd, want de OSI heeft de term "open source" uitgevonden (of preciezer: een van de oprichters van de OSI, Eric S. Raymond, heeft de term uitgevonden). Stallman en zijn clubjes praten consequent of "free software" en gebruiken "open source" alleen om naar de OSI te verwijzen.

De FSF heeft een zeer ideologische inslag: het gaat hen om de vrijheid (in teksten van GNU of FSF komt dan ook gevoeld om de zin het woord "freedom" voor). De OSI denkt veel pragmatischer over open source. Met uitzondering van enkele randgevallen komen open source en vrije software echter overeen: de belangrijkste licenties zijn zowel vrije software als open source.

Apart, Ik had nog nooit van deze splintergroep gehoord. Ik denk dat het misschien aan mijn leeftijd ligt. De FSF stamt uit 1983. Deze splintergroep komt uit 1998 en houdt volgens Stallman haar eigen definitie van "Open Source" aan.

Hier is wat RMS erover zegt:
https://www.gnu.org/philo...-misses-the-point.en.html

Nu snap ik ook waar geertdo zijn vreemde interpretaties vandaan haalt.

[geertdo]

Dan ligt het zeker aan je leeftijd, maar je bent nooit te oud om te leren.

Gelukkig is de 'open definitie' nu zonder discrepanties. Dat was namelijk niet zo. Tijden veranderen gelukkig.

Lees het maar goed door. https://opendefinition.org/od/2.1/en

1.2 Access

The work must be provided as a whole and at no more than a reasonable one-time reproduction cost, and should be downloadable via the Internet without charge

2.1.9. No Charge

The license must not impose any fee arrangement, royalty, or other compensation or monetary remuneration as part of its conditions

Open source en open data is per definitie gratis.

Je kunt wel betaald krijgen voor distributiemiddelen en als je bijvoorbeeld diensten verricht.

[Hoopje]

Gelukkig is de 'open definitie' nu zonder discrepanties.

Je linkt nu naar een website van de Open Knowledge Foundation, weer een andere club dan de FSF en de OSI. Die "open definitie" beweert specifiek een definitie van "open kennis" en "open gegevens" te zijn. Niet van "open source code" dus. Het is ook tekenend dat er geen bekende opensourcelicenties, zoals de GPL, onder de "conforming licenses" worden opgenomen.

Jouw punt, dat open source per definitie gratis is, wordt ook tegengesproken door het feit dat de meeste opensourcelicenties het verkopen van software expliciet toestaan. Lees bijvoorbeeld de tekst van GPL maar eens door. Daarin staat (punt 4):

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

Is GPL'd software niet open source, volgens jou?

[Blokker_1999]

Ja klopt, en als de gebruiker de broncode van je project opvraagt (zeker in geval van GPL en aanverwante licenties) mag je hem wel niet meer aanrekenen dan dat het jouw kost om die code op te sturen. Bijkomend moet de code ook minstens 3 jaar na verkoop van het product beschikbaar blijven.

[Anoniem: 582905]

free as in 'vrij' niet free as in 'gratis'

[Tokkes]

En open source is ook niet zomaar 'vrij'.
Dat de software opensource is wil nog niet zeggen dat je ermee kan doen wat je wil.

[geertdo]

Wel als er geen GPL licentie aan kleeft.

[ng128]

Neen dat is het niet. Free as in speech, not as in beer.

[geertdo]

Dat geldt alleen voor 'free software'. Dat geldt niet meer voor Open Source.

[JAVE]

Nee hoor, het staat je vrij om open source programma's te verkopen.
Of je er wat aan kan verdienen is een tweede: De eerste persoon die je code koopt kan de source code gebruiken om een eigen versie te compileren en al dan niet gratis weg te geven.

Daarom is over het algemeen open source software ook gratis. Maar het is niet PER DEFINITIE gratis.

Er is een verschil tussen 'free as in beer' en 'free as in speech'

[geertdo]

'Free as in beer' wil zeggen dat je een biertje koopt en gratis weggeeft zonder tegenprestatie; doe er mee wat je wilt.

Prima dat je wilt betalen voor die software, maar als je de source niet zelf kunt downloaden en kunt aanpassen en kunt verspreiden is het volgens de open definitie niet 'open' en dus GEEN open source.

Tijden zijn veranderd. Gelukkig.

[Gomez12]

Dan nog, als je een bug in windows vind kan je er nog zoveel betaalde programmeurs tegenaan gooien als je wil maar opgelost krijg je het niet, totdat microsoft zelf met een oplossing komt.

Wat niet wezenlijk verschilt met een regulier groter open source project. Of je moet echt 100% zelf een fork gaan maken en bijhouden in de toekomst.

De core-ontwikkelaar zal ten allen tijde jouw code moeten toevoegen om het in het standaard pakket te krijgen of die core-ontwikkelaar nu MS is of een OS-programmeur.

En je kan best bij ook bij MS code-patches insturen hoor.

[elmuerte]

OpenSource heeft niks te maken met mensen die wel of niet betaald worden. Heeft ook weinig te maken met betalen voor support of OpenSource software.

OpenSource = source code is in te zien, en aan te passen na wil, en dit ook te kunnen verspreiden.

[Tokkes]

....aan te passen na[ar] wil, en dit ook te kunnen verspreiden.

Nee, nee, nee!
Dat hangt toch echt wel af van de licentie waaronder die code wordt vrijgegeven!

[leoBO]

Idd! Een veel voorkomende misvatting (tot voor kort ook bij mij) corrigeer me, maar laat de veel gebruikte gnu gpl licentie niet geen commercial use toe?
Open source = in te zien.

En ten aanzien van deze bug: is de code inzien überhaupt nuttig om zo'n gat te vinden of vinden ze dit soort dingen voora door te prikken in een draaiende gecompileerde kernel?

[JAVE]

Open source code kan (en mag) je ook zelf aanpassen.
Of je je aanpassingen zomaar mag verspreiden (xonder de source code mee te leveren) is een ander verhaal; dat ligt aan de licentie die gebruikt is.

Het grootste probleem van de GPL is dat als je GPL code gebruikt voor een eigen project, jouw code automatisch ook onder de GPL valt.
Dat betekent dat je je code dus niet alleen binair mag verspreiden, maar ook de source code beschikbaar moet stellen.

De BSD licentie daarentegen staat commercieel gebruik van code wel toe. (Een van de redenen dat Apple's OSX is gebaseerd op FreeBSD)

[latka]

Commercial use is geen probleem met GPL, BSD/Apache en de meeste andere open source licenties. Verschil zit hem in de wijze waarop je commercieel mag gaan:
BSD/Apache: ga commercieel, patch/verknal het en verkoop het voor veel geld. De sources hoeft je niet vrij te geven
GPL: ga comercieel, patch/verknal het en verkoop het voor veel geld EN geef de gebruiker de mogelijkheid de sources ook te krijgen. Sources opvragen is dus een recht van de koper (en alleen van de koper) en geen verplichting van de leverancier (uiteraard moet deze wel leveren als er gevraagd wordt).

Mag jij raden welke licentie bedrijven graag zien en welke licentie beter is voor afnemers.

[glaaj]

Red Hat heeft er zelf baat bij om te helpen dus zo gek is dat niet

[compufreak88]

Dat is het idee juist. Elk bedrijf dat er baat bij heeft kan er naar kijken, niet alleen de ontwikkelaars.

Er zijn weinig bedrijven die dit soort dingen zullen doen als ze er zelf geen baat bij hebben, maar juist veel free software wordt ondersteund doordat bedrijven ontwikkelaars beschikbaar stellen om er aan te werken.

[geertdo]

Bij opensource software ben je niet afhankelijk van 1 bedrijf die de source in handen heeft om het probleem op te lossen, maar kan "iedereen" te hulp schieten.

Dit is iets te rooskleurig gesteld, zeker geen algemene 'open source' stelling. Genoeg voorbeelden gehad waar 'te hulp schieten' (vooral op lange termijn) niet werkt of dat PR's niet worden geaccepteerd en je niet weer in sync komt.

Maar om even op dormamu te reageren; the holy grail is het niet, maar wel de meest wenselijke manier.

[Borromini]

Je hebt wel nog steeds de vrijheid om de aangepaste broncode te compileren, met een closed source programma kan je zelf niet patchen of hercompileren. De gevallen waarin je als klant toch toegang krijgt tot gesloten broncode zijn op één hand te tellen en alleen weggelegd voor overheden of vergelijkbare instanties.

[Loller1]

Er is echter wel nog steeds 1 persoon die bepaalt of de patch er wel of niet in komt te zitten.

[Anoniem: 718569]

Laat maar weer eens zien dat Open source niet the Holy Grail is met betrekking tot software ontwikkeling en beveiliging.

Volslagen incorrecte conclusie. Het enige dat het laat zien is dat bugs langere tijd onopgemerkt kunnen blijven. Maar dit geldt voor Closed Source net zo hard. Denk je dat dat voor closed source minder het geval is? Natuurlijk niet. Closed Source ontwikkelaars zijn niet automatisch beter; ze schrijven niet automatisch betere, meer bugvrije code.

De kracht van open source heeft dan ook minder te maken met de kwaliteit van de geschreven code als wel met de transparantie, de inzichtelijkheid ervan.

[LaMaZitten]

Volslagen incorrecte conclusie. Het enige dat het laat zien is dat bugs langere tijd onopgemerkt kunnen blijven.

'Volslagen incorrect' klinkt een beetje alsof de conclusie dus andersom zou moeten zijn. En dat lijkt me ook niet zo, gezien je terechte opmerking dat bugs blijkbaar langere tijd onopgemerkt kunnen blijven.
Indien dat mogelijk is, dan is Open Source toch inderdaad niet de 'Holy Grail'? Begrijp me niet verkeerd: ik zeg niet dat het concept daarmee minder waard is, maar het is dus niet zaligmakend. Een terechte conclusie volgens mij!

Maar dit geldt voor Closed Source net zo hard. Denk je dat dat voor closed source minder het geval is? Natuurlijk niet. Closed Source ontwikkelaars zijn niet automatisch beter; ze schrijven niet automatisch betere, meer bugvrije code.

De vergelijking met Closed Source is eigenlijk niet relevant. Althans, niet ten aanzien van het feit of Open Source de 'Holy Grail' zou zijn of niet. Het klinkt of je hiermee in de verdediging wilt springen, Immers: Closed Source is toch ook niet de 'Holy Grail'? Dat klopt, beide systemen hebben voors en tegens.

De 'Holy Grail'... tja... die is zo ongrijpbaar, zelfs voor een avonturier Indiana Jones nog niet eenvoudig

[Anoniem: 718569]

'Volslagen incorrect' klinkt een beetje alsof de conclusie dus andersom zou moeten zijn.

Nee. In het geheel niet zelfs. De wereld is niet digitaal. Iets is niet zwart OF wit. Als in, de conclusie kan zondermeer volslagen incorrect zijn zonder te betekenen dat het omgekeerde correct is. En dat bedoelde ik dus ook helemaal niet te suggeren. Ik bedoelde precies te suggeren wat ik al schreef -- dat de enige enigszins steekhoudende conclusie een compleet andere is.

Het klinkt of je hiermee in de verdediging wilt springen

In de verdediging waartegen? Nee, geef maar geen antwoord. Was eerder retorisch bedoeld.

En, holy grail? Ach, dat was jouw woordkeuze. Maar, ik wil er wel even op ingaan -- Perfectie bestaat niet, per definitie kan perfectie niet bestaan. Omdat het een subjectief concept is. Perfectie voor jou is hoogstwaarschijnlijk totaal anders dan perfectie voor mij is. Ik bedoelde enkel duidelijk te maken dat het bestaan van bugs binnen Linux niet noodzakelijkerwijs ook maar enige invloed hoeft te hebben op de validiteit van Open Source in het algemeen. Iets wat jij wel bedoelde te suggereren.

En dat was veel en veel te kort door de bocht. Nogmaals, de wereld is niet zwart OF wit. De wereld is bijzonder grijs.

[LaMaZitten]

Goed even terug naar de originele post dan:

Laat maar weer eens zien dat Open source niet the Holy Grail is met betrekking tot software ontwikkeling en beveiliging.

Hier reageer jij op met:

Volslagen incorrecte conclusie.

Terwijl je terecht stelt dat kennelijk:

... bugs langere tijd onopgemerkt kunnen blijven.

Het spijt me, maar ik leid daar uit af dat Open Source niet de 'heilige graal' (of perfecte oplossing zo je wilt) is m.b.t. softwareontwikkeling en -beveiliging. Ik vind dat dus wel degelijk een correcte conclusie. Daarmee niet gezegd willen hebbende dat Closed Source dat wel is. Of dat Open Source als concept niet waardevol kan zijn als het gaat om softwareontwikkeling en -beveiliging.

Het is echter niet de 'heilige graal' en nogmaals: daarmee is de conclusie m.i. niet 'volslagen incorrect'.
Het dus is inderdaad grijs en niet zwart òf wit.

[Reactie gewijzigd door LaMaZitten op 26 juli 2024 11:32]

[Anoniem: 718569]

Goed even terug naar de originele post dan:

Niemand heeft ooit beweerd, binnen de context van dit artikel, dat Open Source de heilige graal is. Dat was jouw bijdrage. Dat deze 1 bug in de Linux kernel voor jou aantoont dat Open Source niet de "heilige graal" is is... jouw conclusie. Niets meer en niets minder. Ik probeerde enkel aan te tonen dat het volslagen kolder is om 1 bug in 1 open source software project op een dusdandige wijze op te blazen dat opeens Open Source niet de heilige graal zou zijn.

Ik weet niet wat je met je originele kritiek probeerde te bewerkstelligen maar, ik zie hem echt even niet hoor. Wat wil je nou van ons horen, of van mij specifiek? Dat Open Source niet ideaal is? Dat zul je van mij niet te horen krijgen. Omdat het maar om 1 stuk software gaat, om 1 voorbeeld van Open Source. En, in de context van dit artikel, om 1 bug in een stuk software van meer dan 20 miljoen regels code. 20 miljoen. Have fun debugging! Het punt -- Geen enkel stuk software is gevrijwaard van bugs. En dat heeft dus geen enkele betrekking wat dan ook op het licentie model, op de beschikbaarheid van de broncode of wat dan ook.

Of Open Source de heilige graal is of niet is volslagen irrelevant binnen de context van dit artikel. We kunnen het wel uitgebreid hebben over de validiteit van Open Source, maar, laten we dat ergens anders doen. Want daar zijn we vele duizenden en duizenden woorden aan kwijt, met gemak.

[LaMaZitten]

Niemand heeft ooit beweerd, binnen de context van dit artikel, dat Open Source de heilige graal is. Dat was jouw bijdrage. Dat deze 1 bug in de Linux kernel voor jou aantoont dat Open Source niet de "heilige graal" is is... jouw conclusie. Niets meer en niets minder.

Ik denk dat je in de war bent. Je hebt oorspronkelijk niet op mijn post gereageerd, maar op die van dormamu. Die stelling was dus niet mijn bijdrage, alhoewel ik haar wel onderschrijf.

Wat wil je nou van ons horen, of van mij specifiek? Dat Open Source niet ideaal is? Dat zul je van mij niet te horen krijgen. Omdat het maar om 1 stuk software gaat, om 1 voorbeeld van Open Source.

Jouw eerdere -terechte- conclusie, dat bugs in Open Source langere tijd onopgemerkt kunnen blijven, beperkt zich natuurlijk niet tot dit ene voorbeeld van Open Source. Dat zal helaas gelden voor het meerendeel van Open Source software.

Je geeft zelf aan dat de wereld niet zwart òf wit is. Echter stel je wel dat

... Het enige dat het laat zien is dat...

Dat vind ik vrij zwart/wit eerlijk gezegd, omdat ik vind dat je wel degelijk meerdere conclusies uit dit artikel kunt trekken. De wereld is inderdaad veel grijzer.

[Anoniem: 718569]

Dat vind ik vrij zwart/wit eerlijk gezegd, omdat ik vind dat je wel degelijk meerdere conclusies uit dit artikel kunt trekken.

Sorry. Maar dat is echt even een paar bruggen te ver. Maar goed, ik ben dit inmiddels een klein beetje beu aan het worden; als je niet in kunt zien waarom het afbranden van Open Source in het algemeen niet van toepassing is naar aanleiding van 1 bug in 1 software project dan heb ik echt niets meer te zeggen dan

[LaMaZitten]

[...]
als je niet in kunt zien waarom het afbranden van Open Source in het algemeen niet van toepassing is naar aanleiding van 1 bug in 1 software project dan heb ik echt niets meer te zeggen dan

Iets niet de 'heilige graal' noemen, lijkt me nu niet echt gelijk staan aan 'iets afbranden'. Immers, jij stelde voor om i.p.v. 'heilige graal' de term 'perfect' te gebruiken (wat me een mooi synoniem lijkt in deze). Iets 'niet perfect' noemen en iets 'afbranden' ligt wat mij betreft mijlen ver uit elkaar.

Ik denk dat we het volgende kunnen concluderen:
Ja: ook in Open Source kunnen langere tijd bugs blijven zitten, daarmee is het dus niet 'perfect'
Nee: We gaan het 'perfecte' model als het gaat om software waarschijnlijk nooit vinden (het bestaat waarschijnlijk gewoonweg niet).

Of Open Source dan voorts 'de beste kandidaat die we tot nu toe hebben gevonden' is, dat is een andere discussie.

Voorts kunnen we wellicht ook concluderen dat stelligheid dikwijls leidt tot moeizame discussies.

[Anoniem: 28912]

Beetje onzinnige gekibbel over interpretaties en definities dit....

[mcDavid]

Hier het bewijs dat Open Source toch de holy grail is:

* KEYS: Fix keyring ref leak in join_session_keyring()
- LP: #1534887
- CVE-2016-0728

Zodra het bericht op tweakers staat, zit de patch in je updates. Zie dat maar eens voor elkaar te krijgen met de gangbare closed-source systemen waar je ofwel tot patch-tuesday moet wachten, ofwel de patch uberhaupt niets oplost.

Daarnaast is bij OSS de kans vrij groot dat, zoals in dit geval, een lek door een goedwillende onderzoeker gevonden wordt. Bij closed source software heb je de garantie dat goedwillende onderzoekers niet in de broncode kunnen kijken, en de kans dat iemand die de broncode ergens illegaal voor veel geld gekocht heeft net zo vriendelijk is, is heel wat kleiner dan dat hij de exploit ook weer door gaat verkopen aan de hoogste bieder.

[Reactie gewijzigd door mcDavid op 26 juli 2024 11:32]

[xleeuwx]

Dat heeft totaal niets met Open Source of Closed Source te maken maar met de snelle afhandeling van de patching mechanisme van Linux...

Leuk dat Android OpenSource is maar nu maar afwachten hoe lang het duurt voordat 25% van de alle kwetsbare Android devices gepatched zijn.

Android is atm niet meer OpenSource maar zijn nog wel versie's OpenSource die ook kwetsbaar zijn. (http://computerworld.nl/m...droid-is-geen-open-source)

[mkools24]

Dat artikel slaat werkelijk nergrens op, Android is gewoon open source. Je mag het aanpassen, forken, weggeven ermee doen wat je wilt. Ok je mag dan geen Google services meer draaien maar dat doet niks af aan dat feit.

[Loller1]

Err. Android AOSP is open source, de Android die jij mogelijk op je smartphone hebt? Die is daar alleen maar op gebaseerd. Net zoals Chromium open source is, Chrome daarop gebaseerd is, maar Chrome zelf een closed source browser is.

[mkools24]

Android is niets meer dan AOSP + Google Play en dat laatste is closed source dus is Android zelf wel open.

Wat jij eigenlijk zegt is ik heb een open source Linux distro daar installeer ik een closed source nvidia driver op dus is Linux niet meer open source, daar komt het op neer.

Google gebruikt AOSP en past dat aan maar dat kun jij zelf ook doen dus de basis van Android is gewoon open source.

[Loller1]

Door gewoon Google Play Services te installeren op AOSP heb je niet plots het Android dat je hebt op toestellen van Samsung, LG, etc or Google's eigen Nexus.

[mae-t.net]

In de praktijk zijn vrijwel alle fabrieksimplementaties van Android grotendeels gesloten. Als je het puur van open software moet hebben, ben je niet alleen de playstore kwijt maar mogelijk ook de mogelijkheid om te bellen of de wat geavanceerdere features van je telefoon te gebruiken.

[Tomtest]

Dijken houden ook geen tsunami tegen, dat wil niet zeggen dat dijken nutteloos zijn.

[dormamu]

Wat een flauwe reactie. Ik zou het anders formuleren; Dijken houden geen tsunami tegen ook niet als de bouwtekeningen door iedereen in te zien zijn.

[DaFifthSense]

Dit is er een bug die in 99.99% van de gevallen niet getriggered wordt, maar gewoon goed gaat. Waarschijnlijk nog vaker zelfs. Daarom dat je gemiddeld een half uur full blast op deze bug moet proberen voordat je een keertje er door komt.
Dit soort racecondities zijn moeilijk te doorgronden en zeker als het bijna altijd goed gaat makkelijk aan te nemen dat het wel altijd goed zal gaan.
Op een telefoon heb je minder zorgen. Die is langzamer en als je een uur of 2 a 3 full power cpu gebruikt zal de batterij leeg zijn, dat valt toch op.

[Gomez12]

Dit soort bugs zijn geen races to the finish, op een smartphone kan je bijv ook verspreid over 1 maand 2 a 3 uur cpu pakken en dat ding is dan toch geïnfecteerd

[Delgul]

Dat hoeft niet. De stelling is dat de kans op langdurig opgemerkte beveiligingsfouten kleiner is bij Open Source om een aantal redenen:

- Men kan niet 'stiekum' terug vallen op Security through Obscurity, iets waar commercieel bedrijven in het verleden regelmatig op zijn betrapt.
- Evenzo kan men een fout niet ontkennen. Als het eenmaal ontdekt is, dan ligt het open voor de wereld en MOET men patchen. Veel bedrijven in closed source houden eerst maanden vol dat er niets aan gehand is.
- Als iets gepatcht wordt, wordt het meestal goed gepatcht omdat de rest van de wereld mee kijkt. Je komt dan meestal niet weg met een halfslachtige fix. En ja, hier zijn ook veel closed source programma's aantoonbaar in de fout gegaan.
- Slordige en slechte code vallen meteen op en hier zal commentaar op komen. In closed source kan zo'n situatie jaren lang bestaan.
- Het is lastig (niet onmogelijk, maar veel lastiger dan bij closed source) om backdoors in te bouwen. En ja... ook hiervan zijn veel closed source voorbeelden bekend.

Met het bovenstaande in gedachten is het aan closed source toko's om te bewijzen dat ze aan de zelfde standaarden kunnen voldoen als Open Source en niet andersom. Eigenlijk kan dat alleenfoor hun eigen code te openen. Als ze goed zouden programmeren zouden ze dat durven. Het laat zich raden waarom ze dat dus niet doen...

[CAPSLOCK2000]

Met andere woorden vier jaar niet ontdekt hoewel het Open source is. Laat maar weer eens zien dat Open source niet the Holy Grail is met betrekking tot software ontwikkeling en beveiliging.

Wat een stroman. Niemand beweert dat Open Source een garantie is voor veiligheid.

[Gomez12]

Ik zou zeggen lees de rest van de reacties eens...

[Bartosy]

Je kan ook denken van goh 4 jaar voordat het ontdekt were met open scource.. Terwijl de hele wereld er naar kon kijken. Hoeveel gaten moeten er dan wel niet in een besturingsysteem als windows zitten waar maar slechts een klein gedeelte de scource code kan zien. Ik denk dat er zat gaten zitten in windows die het daglicht nog niet hebben gezien en waar dagelijk van geprofiteerd wordt door criminelen en de makers van de software zelf.

[pibara]

Open source is hier veel minder relevant dan de grote van de trusted code-base. Basically : we hadden gewoon naar Tannenbaum moeten luisteren met z'n allen en een micro-kernel moeten gebruiken in plaats van de monsterlijke monolytische kernel die we nu hebben. Hoe kleiner de trusted code-base, hoe meer eyeballs de 'trusted' code zullen kijken trouwens.

[sarcast]

Nou ja, niet ontdekt.. In ieder geval niet eerder publiek gemaakt.

Er is een complete black market waar je exploits kan aanschaffen. Dit soort exploits zijn bakken met geld waard. Die maak je niet publiek als niet-ethische hacker, daar verdien je je brood mee.

[Dstre4m]

Verbeter me als ik het verkeerd heb maar hebben de meeste android telefoons niet kernel 3.4 of lager?

[Soldaatje]

Mijn Z2 draait de laatste nightly van Cyanogemod en ja inderdaad die draait Linux kernel 3.4.0 met Android versie 5.1.1.

[Spekkie88]

Dat is vooral afhankelijk van de gebruikte hardware en bijhorende drivers...
Even gestolen van wikipedia:

Android's kernel is based on one of the Linux kernel's long-term support (LTS) branches. Since April 2014, Android devices mainly use versions 3.4 or 3.10 of the Linux kernel. The specific kernel version depends on the actual Android device and its hardware platform.

Er zijn al toestellen met android 4.4.2 die gebruik maken van de 3.10 kernel.

[erikdenv]

Mijn Z1 draait de officiële Android 5.1.1 rom van Sony en die heeft ook kernel 3.4. Mijn PC draait al een poos op een 4.* kernel.
Ik weet eigenlijk niet waarom zo'n oude kernel gebruikt wordt icm Android.

[dehardstyler]

Ik zie op mijn S6 3.10.61 staan, bij de instellingen onder kernelversie.

[watercoolertje]

Klopt alleen heeft die weer SELinux, waardoor je alsnog beschermt bent (naja volgens het artikel/google dan in ieder geval)...

[BliXem]

Volgens redhat lijkt enkel CentOS 7 vatbaar te zijn voor dit lek.

Bron: https://bugzilla.redhat.com/show_bug.cgi?id=1297475#c6
Statement:

This issue does not affect the Linux kernels as shipped with Red Hat Enterprise Linux 5, 6. This issue affects the Linux kernels as shipped with Red Hat Enterprise Linux 7 and will be addressed in a future update.

[Reactie gewijzigd door BliXem op 26 juli 2024 11:32]

[vanaalten]

Wellicht dat ik je verkeerd begrijp, maar volgens mij zegt Red Hat *NIET* dat enkel CentOS-7 vatbaar is.

Ze zeggen dat RHEL 5 en 6 *niet* vatbaar zijn (klopt, kernel 2.6); RHEL7 (en dus CentOS7?) draait op 3.10 en is dus wel vatbaar.

Maar afgezien van Red Hat zijn er nog tientallen andere distributies die best vatbaar kunnen zijn: mijn Debian server bijvoorbeeld, met kernel 3.16.

[Reactie gewijzigd door vanaalten op 26 juli 2024 11:32]

[W00fer]

66 procent van meer dan 1.4 miljard (bron: http://www.androidcentral...android-devices-worldwide) dat gaat dus voor meer dan 30% nooit gefixed worden.

Oppassen voor malicious apps dus!

[watercoolertje]

Oppassen voor malicious apps dus!

Zoals altijd dus? Met of zonder dit lek moet je gewoon niet zomaar iets installeren als je niet eens weet wat je installeert...

[SvenHe]

Dit hele verhaal doet me vooral op het hoofd krabben hoe verstandig het is om afhankelijk te blijven van android.

Ik gebruik een paar google dingen die ik niet graag zou missen omdat ze fijn werken maar eigenlijk komt bovenstaand verhaal er op neer dat je je apparaat moet blijven vervangen om up to date te blijven en je oude telefoon die technisch nog heel goed is kan weggooien.

Met een computer kan je vaak de hele technische levensduur gebruik blijven maken van up to date linux.
Ik gebruik een pc van voor 2007 voor een primair bedrijfsproces (cnc frezen) die met linux zeer geschikt is gebleken voor dit doel.

[Anoniem: 634684]

Ga je je dat ook afvragen bij een ander OS als er morgen een artikel is over een security lek van een ander OS ?

En hoezo afhankelijk van een Android OS ?
Je bent afhankelijk van eten en drinken en zuurstof

[Reactie gewijzigd door Anoniem: 634684 op 26 juli 2024 11:32]

[flux_w42]

De patch is een one-liner

[Grimm]

Opensource bevat minder fouten dan propriëtaire code:

http://tweakers.net/nieuw...an-proprietaire-code.html

[Grimm]

"Uit de analyse bleek dat de opensourcebroncode gemiddeld 0,45 fouten per duizend regels bevatte, terwijl bij propriëtaire code 0,64 fouten per duizend regels werden aangetroffen. Daaruit zou blijken dat opensourceprojecten gemiddeld minder fouten bevatten, al scoren beide categorieën onder de 1.0, het gemiddelde aantal gemaakte fouten in software.

Verder stelt Coverity dat de broncode van drie opensourceprojecten een zeer hoge kwaliteit heeft: Linux 2.6, PHP 5.3 en PostgreSQL 9.1, met een respectievelijke foutdichtheid van 0,62, 0,2 en 0,21. Dergelijke cijfers worden door de organisatie omschreven als 'industry benchmarks'."

[H!GHGuY]

Systemen met PaX/grsecurity zijn ook niet kwetsbaar, aangezien PAX_REFCOUNT dit probleem mitigeert.

[ch4rl3m4gn3]

Gelukkig update LG Android op mijn telefoon niet meer dus zit ik lekker veilig op kernel 3.4...

In Ubuntu nu de patch binnen trouwens.

[Reactie gewijzigd door ch4rl3m4gn3 op 26 juli 2024 11:32]

[Clubbtraxx]

Nou dat stuk over Android kan je wel uit het artikel knippen want zelfs de nieuwste net ge-update modellen die sinds kort Android 6 MM hebben, draaien bij mijn weten toch pas kernel 3.4.0. Jammer voor alle sensatiebakken en android bashers maar helaas voor jullie is dus helemaal niet 66% van alle Android phones kwetsbaar hierdoor.
Lekker overpennen wat de rest ook roept zonder je bronnen te controleren verwacht ik bij bepaalde sites, maar hier bij tweakers toch eigenlijk niet. Jammer!

[Reactie gewijzigd door Clubbtraxx op 26 juli 2024 11:32]

[Lawine93]

Het zal inderdaad minder zijn dan 66%, maar mijn galaxy s6 zit op kernel versie 3.10.61, draai android 5.1.1.

[Clubbtraxx]

Klopt, er zijn zeker ook toestellen die wel op een hogere versie zitten.
Maar het ging mij dan ook voornamelijk om dat totaal uit de lucht gegrepen getal van 66%, want zoveel jaar Android en dus is per definitie zoveel procent kwetsbaar. Duh!

[Reactie gewijzigd door Clubbtraxx op 26 juli 2024 11:32]