Linux Foundation bant Amerikaanse universiteit wegens expres doorvoeren van bugs

Linux Foundation-fellow Greg Kroah-Hartman heeft een Amerikaanse universiteit verboden om patches bij te dragen aan de Linux-kernel. Dit is omdat onderzoekers van de universiteit geprobeerd zouden hebben om moedwillig kwetsbaarheden aan de kernel toe te voegen.

De beslissing wordt bevestigd in een discussie in de Linux-mailinglijst, merkte ook Phoronix op. De onderzoekers van de Universiteit van Minnesota publiceerden in februari al een rapport over 'de haalbaarheid van het ongemerkt introduceren van kwetsbaarheden van open-source software'. De researchers wilden onderzoeken hoe de kernel-community zou reageren op deze bugs in de kernel.

Meer recentelijk probeerde de groep onderzoekers een nieuwe lading patches door te voeren in de kernel, die volgens de onderzoekers voortkwamen uit een static analysis tool. De onderzoeker heeft de patches naar eigen zeggen opgestuurd in de hoop om feedback te krijgen. Kroah-Hartman schrijft in een reactie in de Linux-mailinglijst echter dat de patches twijfelachtig zijn en geen toegevoegde waarde hebben voor de kernel.

"Ze zijn duidelijk niet gemaakt door een static analysis tool van enige intelligentie, aangezien ze allemaal het resultaat zijn van totaal verschillende patronen, en ze allemaal duidelijk niet eens iets repareren", zo schrijft Kroah-Hartman. "Een paar minuten met iemand die ook maar een greintje kennis van C heeft, kan zien dat uw inzendingen helemaal niets doen."

De Linux Foundation-fellow schrijft verder dat kernel-contributies van de Universiteit van Minnesota niet langer welkom zijn, en dat alle voorgaande patches van de onderzoekers teruggedraaid zullen worden. In een follow-up in de Linux-mailinglijst bevestigt Greg Kroah-Hartman dat alle voorgaande patches van de onderzoekers, waarvan verschillende ook de stabiele branch hebben bereikt, inderdaad worden teruggedraaid.

Reacties (144)

Een opmerking van 1 van de onderzoekers/studenten.

I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.

These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.

Obviously, it is a wrong step but your preconceived biases are so strong that you make allegations without merit nor give us any benefit of doubt.

I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts.

Greg countert dat met onderstaande en daaropgevolgend dus de beslissing dat al hun toevoegingen eruit moeten. Daar is wat voor te zeggen.

When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.

Het is een combinatie van het verstorende effect in iets fundamenteels als de Linux kernel en het ethische vraagstuk. Dit soort onderzoeken hebben weinig nut als je het test op een project dat niet zo onder een vergrootglas ligt als de Linux kernel. Je gaat altijd wel iets vinden waarbij je het gaat lukken malicious code in te duwen. Het bewijst dan echter nog niet veel.

Echter, of dit nu de juiste methode was valt ook te betwijfelen. Daar zit natuurlijk niemand op te wachten en het schaadt het vertrouwen in contributers. De onderzoekers hadden natuurlijk vooraf een aantal personen in kunnen lichten, maar ik betwijfel of ze ooit goedkeuring hadden gekregen.

[Reactie gewijzigd door The Realone op 21 april 2021 19:40]

De Linux kernel maintainers moeten dagelijks een hele sloot aan inzendingen lezen, en vrijwel elke patch vereist weer een over en weer contact met de schrijvers voor eventuele aanpassingen.

Dan ga je als studentje hun tijd verspillen met waardeloze patches die wellicht zelfs opzettelijk bugs introduceren? Erg arrogant en respectloos, imo.

Ben het in dit geval met je eens hoor, maar in de bredere zin moet er wel ruimte zijn voor dit soort onderzoek, maar dan had het wel echt anders aangepakt moeten worden. Het ogenschijnlijke doel op zich is natuurlijk nobel, want iedereen wordt er beter van als scherp gehouden wordt voor wat betreft het beoordelen van (al dan niet opzettelijk) malafide code.
Echter heeft het er hier wel alle schijn van dat die die nobelheid hier nauwelijks sprake was maar dat de Linux kernel hier enkel het lijdend voorwerp van een onderzoekspaper was.
Dus ja, kwalijk.

Er is zoiets als "consent". Dat is er met een reden. Er zou hier consent gevraag moeten worden aan alle mensen waarom het experiment uitgevoerd wordt. Dat is niet alleen de ontwikkelaars, maar ook de gebruikers van de Linux kernel. Maar ik vermoed dat er helemaal geen ethische toetsing aan vooraf gegaan is. Dat zullen we vast nog wel horen. Ik ben benieuwd naar de reactie van de universiteit zelf.

Die is er https://cse.umn.edu/cs/st...el-research-april-21-2021

Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.

We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical.

Sincerely,

Mats Heimdahl, Department Head
Loren Terveen, Associate Department Head

[Reactie gewijzigd door cookie and egg op 22 april 2021 10:25]

Ja, toestemming van de (betreffende faculteit van de) universiteit. Dat is dus geen toestemming. Als je een nette pentester analyse als (commercieel) bedrijf/organisatie zou uitvoeren dan doe je die oftewel in opdracht van een bedrijf/organisatie of je vraagt om toestemming om dat te doen.

Je gaat niet zomaar allerlei dingen doen, dit is iets anders dan als ethical hacker een systeem blootstellen en netjes melden. Wat ze hier hebben gedaan is veel tijd verspillen van mensen (door opzettelijke foute patches aan te bieden - die weer in de project bureaucratie door moeten), mensen die wel belangrijkere dingen te doen hebben dan waardeloze patches terugdraaien en/of verbeteren.

[Reactie gewijzigd door Remzi1993 op 22 april 2021 13:25]

Het blijft discutabel. Vrijwel alle grote ethische hackers proberen software van grote bedrijven te kraken. Dat wil niet zeggen dat ze eerst alles aanmelden bij de maker van die software alvorens ze gaan proberen. Je weet notabene nooit waar je uitkomt en waar je een bug vind. Ook zou dit het openbaren van een beloningsysteem bij melden van bugs deels overbodig maken. De beloning kan dan vooraf worden bepaald door de verrichte werkzaamheden bij het aangeven van de poging tot het inbreken.

Ik denk dat als onderzoek deze methode het beste werkt. Gezien je een tegen een unbiased ontvanger praat, zo zal de kans op eventuele werking het grootste zijn.
Het nadeel van die aanpak is dat het verdomte lastig is achteraf te verdedigen. Simpelweg omdat je op heterdaad bent betrapt op zijn zachts gezegd in de categorie ongewenst valt. Vanuit dat oordeel gaan bewijzen dat je de beste bedoelingen had is erg lastig, en uiteraard veel lastiger als het vooraf aan te geven wat je aan het doen bent, al dan niet aan een deel van de ontvangende organisatie.

Nogmaals dat is anders, want zo'n ethische hacker zorgt er niet voor dat veel mensen hun tijd verspillen.

En het wordt netjes achteraf gemeld. Het gaat erom dat deze onderzoekers bewust mensen hun tijd verspillen aan nutteloze patches, dat doet een ethische hacker niet want die gaat zelf een systeem proberen binnen dringen of bloot stellen. Die hacker verspild geen tijd van mensen.

[Reactie gewijzigd door Remzi1993 op 24 april 2021 06:43]

Dat is ook maar voor een deel waar. Even als simpel voorbeeld dat je met een DDOS een systeem op z'n kant weet te leggen en op die momenten ergens anders juist in kan komen. Dan zit ook de systeembeheerder van het netwerk recht op in z'n bed met laptop op zijn schoot. Dus het is zeker niet zo dat ene direct tijd vreet en andere niet. Als het systeem goed is zouden deze proeven er ook nauwelijks tijd moeten kosten, omdat na 1 of 2 audits wel gezien moet worden dat de code erg vreemd is. Dus vanaf nummer 3 als er geen duidelijke beschrijving wordt gemeld wat is verbeterd en waarom kun je hem automatisch afweren. Gaat het niet zo zit niet alleen de schuld van tijd bij de "onderzoekers" kant maar ook aan de ander kant hoe ze met binnenkomende patches en bronnen omgaan.

Een ethische hacker maakt geen (financiële) schade. Die DDOS creëert hij dus niet, dat een ethische hacker een poging waagt tijdens zo'n DDOS is anders dan zelf een DDOS creëren of aanzetten. Een DDOS zorgt meestal voor financiële schade bij commerciële bedrijven, want dan kunnen klanten niet dingen kopen en/of bepaalde services gebruiken.

Ik denk dat wij op dat punt verschelen wat een ethische hacker doet of niet. Als het mogelijk is om via een DDOS ergens binnen te komen zal ook een ethische hacker dat uitvoeren. Ethisch betekend namelijk niet dat hij geen schade berokkend bij de ontvangende partij, maar dat hij het met goede bedoelingen doet. Als je het met goede bedoelingen doet, moet je ook soms dingen slopen/kosten maken aan de ontvangende partij. Puur en enkel omdat de criminele kant daartoe ook toe instaat is. Testen zijn alleen een afspiegeling van de werkelijk betrouwbaarheid als ze ook dezelfde middelen mogen gebruiken als de criminele aanval, anders is de test maar een schijnbeeld van de werkelijke veiligheid en dus tot op zekere hoogte zinloos.
Dit is mijn mening, geloof dat we daarin verschillen. En dat is je groot recht. Maar als je daaraan vasthoud gaan we denk ik niet dichter bij elkaar komen als we nu al zijn. En wil ik je bedanken voor de opbouwende discussie.

Inderdaad wij verschillen sterk op dat punt. Het heeft dus ook geen zin om daarover door te discussiëren.

Ik ben een korte periode in het verleiden technisch adviseur geweest als freelancer, jij hebt geen flauw benul waarover je spreekt. Gelukkig ben jij geen ethisch hacker, want hoe jij reageert neem ik aan dat organisaties zeker aangifte tegen jou zouden doen.

DDOS is en blijft gewoon not done. En wordt niet toegestaan, valt niet onder ethisch hacken en overheid en bedrijven doen dan zeker aangifte, want een DDOS is altijd schadelijk voor overheden en bedrijven want het stopt de werking van een service en/of soms van kritische systemen (denk aan waterbedrijf enz...). Echter wat wel onder ethisch hacken valt is dus beveiligingslekken vinden (ook tijdens een DDOS niet door jou veroorzaakt) en dit netjes melden (vertrouwelijk en niet meteen aan de wereld openbaren zonder de organisatie tijd te geven om het op te lossen en/of in overeenstemming - communicatie hierin is het belangrijkste).

Bronnen:
- https://www.security.nl/p...Hacken+-+Dos+and+Don%27ts
- https://www.ncsc.nl/aan-d...en-in-ict-systemen-vinden (overheid)
- https://dutchitchannel.nl...ische-hacker-precies.html
- https://www.om.nl/onderwe...sclosure---ethisch-hacken (overheid)

Jammerlijk is het respect voor mening duidelijk eenzijdig. Vooral omdat je je eigen fouten bewijst met de bronnen. En dus niet zozeer van mij af hoeven komen.

Is er gehandeld in het kader van een wezenlijk maatschappelijk belang?
Is er sprake van proportioneel handelen (of wel: ging de hacker niet verder dan noodzakelijk was om zijn doel te bereiken)?
Is er voldaan aan het subsidiariteitsvereiste (of wel: was/waren er geen minder vergaande manier(en) om het door de hacker beoogde doel te bereiken)?

Als een DDOS nodig is om een gehele gebruikers database inclusief passwords is te benaderen en dat de enige manier is. Dan is op alle vragen hierboven het antwoord ja. Is dat om enkel achter het aantal gebruikers te komen, dan is het antwoord nee. Vandaar dat ik ook beloond ben en niet aangeklaagd. Ik wens je nog veel succes in security. Tip, neem hele goede clausule op dat je voor mogelijke schade na je advies niet verantwoordelijk bent.

Dank voor de link!

De Linux kernel mag rustig het lijdend voorwerp van een onderzoek zijn. Die is open source en binnen de licentie mag je ermee doen wat je wil, dus ook een code analysis tool op loslaten gok ik. Dat je de resultaten van die tool wil laten beoordelen is prima en voor het onderzoek zeer waarschijnlijk noodzakelijk. Maar om dan gratis expertise te ge/misbruiken door Linux kernel maintainers als reviewers in te zetten zonder daar vooraf toestemming voor te vragen is belachelijk. Dat geldt ook voor patches indienen zonder hele duidelijke disclaimer.

Dus lijkt me een terechte reaktie vanuit de Foundation. Die zal vast niet heel vriendelijk zijn geweest zo te lezen, maar dat is te begrijpen gezien de situatie en de vele inzendingen die ze ongetwijfeld sowieso moeten behandelen.

De Kernel mag je gerust onderzoeken. Maar dat wil niet zeggen dat je zonder te vragen de processen er omheen en mensen die die processen uitvoeren aan je onderzoek mag onderwerpen. Dát is inderdaad niet acceptabel.

De onderzoekers hadden vooraf contact moeten opnemen met bijvoorbeeld Linus of de Linux Foundation, uit moeten leggen wat het doel van het onderzoek was en dat het daarvoor van belang was dat de reviewers niet van te voren op de hoogte werden gesteld. Dan zou je wellicht toestemming kunnen krijgen, met allerlei mitsen en maren en uiteraard maatregelen om te voorkomen dat de betreffende patches de mainline halen.

Dit! Dit verdiend een 3 plus. Het gaat om toestemming van bovenaf en om voorzorgsmaatregelen. Dan zouden ze goed de veiligheid/beveiliging kunnen testen en in samenwerking zelfs kunnen verbeteren.

Nu is het allemaal vijandig geworden en wilt men niks meer iets van elkaar leren. Zo jammer dit. Die studenten hebben niet langer nagedacht hoe ze dit het beste konden uitvoeren. Typisch theorie uitvoeren/testen en niet de praktisch gevolgen uitzoeken en pragmatisch te werk gaan.

[Reactie gewijzigd door Remzi1993 op 22 april 2021 13:30]

maar in de bredere zin moet er wel ruimte zijn voor dit soort onderzoek, maar dan had het wel echt anders aangepakt moeten worden. Het ogenschijnlijke doel op zich is natuurlijk nobel, want iedereen wordt er beter van als scherp gehouden wordt voor wat betreft het beoordelen van (al dan niet opzettelijk) malafide code.

Het onderzoek is geheel correct uitgevoerd. De resultaten spreken voor zich. Je moet geen onzin opsturen want dan krijg je gewoon een keiharde ban. Zeer leerzaam. Wat dat betreft hebben de onderzoekers goed werk geleverd.

Een ander deel wat onvoorzien nu ook bij dit onderzoek hoort is de les: leren leven met de consequenties van je daden.

Twee leerzame conclusies die uit dit onderzoek getrokken kunnen worden. Als de onderzoekers volwassen genoeg waren om dit onder ogen te zien hadden ze een dikke A+ verdient. Nu zijn het een stelletje losers die gaan klagen dat ze een ban kregen voor hun gesukkel.

Dan nog is dit uiterst slecht voor de universiteit zelf. Denk aan reputatieschade, geen patches meer kunnen doorgeven en ook de individuele personen zijn persona non grata. Ik heb al eerder op een comment gereageerd dat ze dit het beste anders konden uitvoeren. Meerdere Tweakers hebben voorbeelden hier gegeven hoe zit dit beter konden doen zonder nare consequenties.

EDIT: Een quote van mij:

Ja, toestemming van de (betreffende faculteit van de) universiteit. Dat is dus geen toestemming. Als je een nette pentester analyse als (commercieel) bedrijf/organisatie zou uitvoeren dan doe je die oftewel in opdracht van een bedrijf/organisatie of je vraagt om toestemming om dat te doen.

Je gaat niet zomaar allerlei dingen doen, dit is iets anders dan als ethical hacker een systeem blootstellen en netjes melden. Wat ze hier hebben gedaan is veel tijd verspillen van mensen (door opzettelijke foute patches aan te bieden - die weer in de project bureaucratie door moeten), mensen die wel belangrijkere dingen te doen hebben dan waardeloze patches terugdraaien en/of verbeteren.

Een quote van @ATS

De onderzoekers hadden vooraf contact moeten opnemen met bijvoorbeeld Linus of de Linux Foundation, uit moeten leggen wat het doel van het onderzoek was en dat het daarvoor van belang was dat de reviewers niet van te voren op de hoogte werden gesteld. Dan zou je wellicht toestemming kunnen krijgen, met allerlei mitsen en maren en uiteraard maatregelen om te voorkomen dat de betreffende patches de mainline halen.

[Reactie gewijzigd door Remzi1993 op 22 april 2021 13:53]

Ben het helemaal met je eens hoor. Dit hadden ze slimmer kunnen doen. Maar al doende leer je. Jammer dat deze universiteit nu niets meer bij kan dragen. Daar kunnen alle andere universiteiten van leren. Er is een reden dat white hackers en pen testers voorzichtig te werk moeten gaan, dit lijkt daar een beetje op. Zaak dus voor onderzoeksinstanties om hun mensen hier goed over voor te lichten en in op te leiden.

Daarnaast wordt de soep zelden zo heet gegeten als dat die wordt opgediend. Het zou mij niet verbazen als de ban na een tijdje en wat heen-en-weer geklets weer wordt teruggedraaid.

Helemaal mee eens, echter gaan deze onderzoekers nog een stapje verder. In plaatst van excuses aan te bieden en beter te beloven gaan ze alles ontkennen en kinderachtig lopen doen. Zie eerste comment van: @The Realone. Ik heb nog andere mailinglijsten gelezen en het bekvechten gaat over en weer.

Dan ben je snel klaar mee als Kernel onderhouders/projectleiders. Ik zou deze gasten ook verbannen van een project waar ik de (mede) leiding had. Ik dit als ze anders hadden gereageerd dat ze misschien iets coulanter waren geweest dan iedereen bannen en de hele universiteit persona non grata aan te merken.

Nu moet het bestuur van de universiteit zelf ingrijpen om de reputatieschade op te lossen. Ik weet zeker dat er grote consequenties komen voor de faculteit (de proffesor die deze wijze van werken toestemming heeft gegeven) en de individuele onderzoekers, want dit is een mega plunder

U vraagt, zij draaien:

https://cse.umn.edu/cs/st...el-research-april-21-2021

Nee dus, er zijn grenzen aan onderzoek. Je kan ook als onderzoeker niet zomaar gif in het drinkwater doen en dan kijken hoeveel mensen doodgaan, om maar een extreem voorbeeld te noemen.
Een universiteit heeft als het goed is en ethical review board (weet nl naam niet) die de impact van dit soort zaken zou moeten keuren. Ik hoop voor de onderzoeker dat hij dit ook heeft laten goedkeuren, anders kans dat hij hiervoor flinke gevolgen zal krijgen.

Er is toch ooit een onderzoek geweest dat als iemand op een knop drukte een vriend achter het gordijn een schok kreeg ofzo (dat was een acteur maar wist de persoon niet) Sindsdien zijn er toch regels voor deze ellende opgesteld wat ethisch kan en mag?

Edit: dit experiment; https://www.newscientist....riments-that-wed-ban-now/

[Reactie gewijzigd door rob12424 op 21 april 2021 23:40]

Er zijn best wel heel veel onderzoeken geweest die niet bepaald ethisch waren. Zie bijvoorbeeld https://en.wikipedia.org/...tion_in_the_United_States, https://en.wikipedia.org/wiki/Nazi_human_experimentation en https://en.wikipedia.org/...cal_human_experimentation.

Maar daar zijn nu inderdaad hele strenge regels tegen, in ieder geval in de ontwikkelde delen van de wereld

Ik vind arrogant en respectloos nog vrij mild.

Elke developer weet dat de mainline/trunk van een repository stable moet zijn. Om daar dan je static code analysis tool op los te laten en direct naar toe proberen te schrijven middels deze patches, is inderdaad op z'n minst onwetend te noemen. Kwaadwillend of arrogant zou een ander woord zijn als er opzet in het spel zit - wat blijkbaar zo is.

Ik weet niet zo goed wat de bedoeling daarvan is. Is het om te testen of developers wel opletten? Een wetenschapper zou er voor moeten waken dat indien een experiment negatieve gevolgen kan hebben, dat deze binnen de gestelde onderzoekskaders blijft. Daarin hoort ook kennisgeving van en wederzijdse toestemming. Dit experiment lijkt aan beide niet aan te voldoen.

Het is natuurlijk zeer ongemakkelijk om dit soort testen te beperken tot "toy projects" zonder dat er schade kan optreden. Een "real life test" op een groot OSS project is veel interessanter. Maar welkom in de echte wereld; de medische en social sciences hebben daar dagelijks mee te maken (veel meer dan een gemiddelde technische PhD/prof). Daarmee zou ik zelfs durfen stellen dat als je zoiets naar een ethische onderzoekcommissie trekt, dat ze daar ook wat over te zeggen hebben.

[Reactie gewijzigd door Hans1990 op 21 april 2021 20:48]

Ach ja, vind het ook valide om eens te onderzoeken of de politie het werk goed doet mja als je dat onderzoekt door bijv een inbraak te doen dan mag je van mijn de consequenties voelen

De reactie van die student is typisch hedendaagse, dit zie je vandaag de dag helaas steeds vaker; Je bent simpelweg de dader, maar omdat ze een niet zo malse reactie hebben gehad en worden aangepakt voelen ze zich "slachtoffer" en wordt er zielig gedaan. Onlangs ging er nog een filmpje de wereld rond van een dame die wordt aangehouden door de politie omdat ze onveilige dingen in het verkeer deed terwijl ze een auto bestuurde, maar het enige waar ze het over wilde hebben (op een zeer vervelende manier) met die agent is dat hij zich maar moest realiseren dat zo'n aanhouding toch wel heel erg schrikken is en bedreigend voelde voor haar... en de reactie van deze student is in mijn ogen exact hetzelfde.

Dit soort reacties gaan de haren in mijn nek van overeind staan... bah!

Dit soort reacties gaan de haren in mijn nek van overeind staan... bah!

Precies. Er zou ruimte moeten zijn voor newbies en non-experts.... Nou, liever niet in kernel development mat mijn OS, thank you very much.

Ik vind ook dat iedereen automonteur moet kunnen worden, maar oefen dan niet op mijn auto, en onder toezicht. Wat hij deed komt overeen met een eerstejaars monteur de Mercedes van een klant laten repareren en zien of hij niet vanzelf uit elkaar valt als de klant ermee gaat rijden. Gelukkig is de reparatie eerst door een deskundig monteur beoordeeld en de leerling monteur is niet geschikt verklaard. Laat 'm eerste maar op wrakken oefenen...

Als ze een serieus onderzoek hadden willen doen, dan hadden ze ook de laatste 100 security patches kunnen pakken en deze onder de loep kunnen nemen.

Dit wordt trouwens ook gedaan, want op die manier vinden ze dus veel 'veroorzakers' van bugs: Blijkt dat er onder de Linux ontwikkelaars ook gewoon een bel-curve van kwaliteit is, en dat ze overal wel een beetje voorkomen

https://dl.acm.org/doi/10.1145/2642937.2642990

Edit: Directe download:
https://www.itu.dk/people/brabrand/42-bugs.pdf

[Reactie gewijzigd door Eonfge op 21 april 2021 19:53]

Als ze een serieus onderzoek hadden willen doen, dan hadden ze ook de laatste 100 security patches kunnen pakken en deze onder de loep kunnen nemen.

Volgens mij willen ze onderzoeken hoe makkelijk het is moedwillig kwetsbaarheden in de kernel te plaatsen. Denk jij dat dat bij veel van de meest recente 100 patches de opzet was?

Wat is het verschil dan? De exploits die er per ongeluk in worden gebracht vallen minder op, ik denk dat dat het enige verschil is. Je kunt verder ook kijken naar bijv. patches die niet zijn doorgevoerd. Alleen is het lastiger om te zien of die ook securityrisico's met zich mee zouden brengen.

Ik vraag me ook af wat voor soort wetenschappelijk onderzoek dit is. Het lijkt me een beetje hobby-onderzoek eerlijk gezegd. Wat voor stellingen kun je er nou mee bewijzen of ontkrachten die enige wetenschappelijke waarde hebben? Ik kan er vrij weinig bedenken iig.

Uuhm zoiets als... conclusie "ja populaire/belangrijke projecten zijn in control"

Tuurlijk sluipen er foutjes in maar we zijn iig beschermd tegen scriptkiddies

[Reactie gewijzigd door Mellow Jack op 21 april 2021 23:03]

Ik denk dat ze willen weten of overheden en dubieuze organisaties moedwillig back doors kunnen plaatsen. Dat is een hele andere vraag dan of bugs in reviews gevonden worden.

[Reactie gewijzigd door 84hannes op 22 april 2021 13:21]

Mja dat testen ze dus niet. Hadden ze daadwerkelijk goed doordachte commits gedaan had je gelijk. Ze lijken gewoon een tooltje te hebben gebruikt

Je kan niet alles in 1 keer testen. Je wilt weten of opzichtige backdoors er doorheen komen en of subtiele backdoors er doorheen komen, backdoors in verder functionele en goede code en backdoors tussen een hoop troep. Dat kan nu eenmaal niet allemaal tegelijkertijd getest worden.

Ik praat het niet goed, ik probeer te raden wat ze wilden bereiken. Als ze wilde weten of alle veiligheidslekken gespot worden voor integratie dan hadden ze niet eens naar de afgelopen 100 commits hoeven te kijken, we weten dat er lekken worden gevonden, dus die lekken zijn ooit geïntegreerd. Kijken naar de afgelopen 100 commits is voor dit onderzoek dus niet echt nuttig te noemen, tenzij je weet dat daar bewuste backdoors tussen zitten.

exploits die er per ongeluk in worden gebracht vallen minder op

Maar daar gaat de onderzoeksvraag niet over. Je kunt niet onderzoek doen naar moord door alleen naar ongelukken te kijken. Je kunt er niet achter komen hoeveel spullen er jaarlijks gestolen worden door te kijken naar wat er bij de gevonden voorwerpen ligt; moedwillig en per ongeluk zijn twee totaal verschillende dingen zelfs als de uitkomst hetzelfde is.

These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.

Alleen al op basis van deze tekst vind ik de beslissing eigenlijk meer dan terecht. Zijn ze daar nu bezig om de Linux kernel ontwikkelaars te gebruiken als beta testers/proefkonijnen voor een analysetool?

Het is te bizar voor woorden dat de ethics committee hier niet voor is gaan liggen. Dr. Mengele praktijken, maar dan met software.

Tenzij de Linux Foundation beslist om echte pinguins te gaan gebruiken, denk ik niet dat zoiets snel op een ethics committee zal voorkomen.

Aangezien linux wereldwijd op talloze kritieke plekken wordt ingezet, was dit zeker onderzoek op "echte penguins".

Uit de mailinglijst kan ik afleiden dat elk onderzoek moet worden aftoetsen aan bepaalde criteria: in dit geval hadden ze dit moeten communiceren: https://lore.kernel.org/[e-mail]/

Dus vermoedelijk heeft de student niet de juiste policy gevolgd.

Gezien het mensen zijn die reviewen en reageren en ze proberen te kijken hoe ze die mensen het best kunnen misleiden en wanneer dat wel/niet lukt, zou je wel degelijk kunnen stellen dat er wordt geëxperimenteerd op mensen. En daar heeft een ethic committee wel iets over te zeggen en moet vooraf aangegeven worden om het te laten toetsen. (Kan zijn dat het er prima door was gekomen, daar niet van; al lijkt dat me stug zonder goedkeuring van de betrokkenen.)

Gefeliciteerd met uw Godwin.

We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.

Dit ... "does not compute" voor mij. Zijn zij nu gedegouteerd omdat ze zich (te) vaak genoodzaakt
voelen om zichzelf te uitten als "non experts" ? Jonge mensen he: heel veel ideeen en zelfzeker ... maar ooh wat een slechte keuringsfilter en gebrek aan praktische realiteitszin.

Newbies hebben ook niks te zoeken in de Linux kernel. Ik beschouw mijzelf in het programmeervak intussen niet meer als een newbie, maar Kernelwerk is nog heel wat bruggen te ver voor mij.

Als de onderzoekers van plan waren geweest om achteraf door te geven wat er was gebeurd, dan had het beschouwd kunnen worden als een white-hat hack poging. Ik weet niet wat voor code ondertussen in de stable branch is opgenomen maar als dat onderdeel was van ditzelfde onderzoek dan kan je sterk in twijfel trekken wat het doel eigenlijk was.

Inmiddels is het volgende bericht de wereld ingestuurd: https://cse.umn.edu/cs/st...el-research-april-21-2021. Eens kijken wat hier de komende dagen uit gaat komen.

Lol voor "research" als ze onderzoek willen doen kunnen ze toch gewoon de sources lokaal clonen en er daar mee kloten zonder te commiten?

[Reactie gewijzigd door danoam op 21 april 2021 19:51]

In een eerder stadium heeft een professor van de genoemde universiteit geprobeerd patches met 'known issues' gecommit te krijgen. Het doel was niet zozeer de patch maar het review proces van de Linux kernel testen. Een git clone helpt hier niet bij.

Tja, dan hebben ze toch precies gekregen wat ze wilden? Het review proces werkt prima en geeft een malafide code producent een dreun met de banhammer. Tijd om je onderzoek af te sluiten en je bevindingen op schrift te stellen. En uit te leggen aan je collegas van de IT wetenschappen waarom ze niet langer welkom zijn in een van de vlaggeschepen van de open source wereld...

Volgens mij werkt het proces dus niet prima, want er zijn in de afgelopen periode (jaren?) al meerdere patches doorgevoerd die security bugs geintroduceerd hebben.

De manier waarop is misschien niet helemaal goed, maar het onderzoek is wel interessant. Want als een universiteit dit kan, dan kan wellicht een partij als de NSA dit ook doen, misschien met wat meer tijd en geld op een minder opvallende manier?

Dit is geen fatsoenlijk onderzoek. Het pretenteer er een te zijn onder de drager van "security research" maar op zijn best is het sociologisch onderzoek naar het gedrag van reviewers in de linux kernel community. Ze onderzoeken letterlijk de kwailiteit en de kunde van de mensen en hoe ze er mee om gaan. Dit doen zonder instemming van de organisatie en "deelnemers" is sowieso al taboe en is in veel landen verboden.

Je kan conclusies trekken uit dit voorval, maar om het systematisch te doen moet je toch echt een vorm van dubbelblind onderzoek gaan doen naar meerdere projecten met meerdere groepen om daaruit enige vorm van conclusies te trekken over hoe men hiermee omgaat en mogelijk aanbevelingen te doen. Het al gepubliceerde paper is van bedroevende sample size (1) en zou daarom alleen al afgewezen moeten worden en komt neer op "het is mij gelukt om bewust een bug te introduceren in de linux kernel" maar geeft geen inzichten anders dan die iedereen vanuit zijn luie stoel al had bedacht.

Is het onderzoek dus interessant? Nee, men leert niets nieuws en krijgt geen nieuwe inzichten en de aanbevelingen komen neer op open deuren intrappen. Als het weloverwogen gedaan was met toestemming van de betrokkenen met voldoende wetenschappelijke onderbouwing, dan wellicht, maar nu zeker niet.

edit: open deuren intrappen mag altijd, ook voor onderzoek, maar schrijf dan een gewoon literature paper er over zonder "onderzoek" te doen. Dat krijg je niet gepubliceerd omdat het niet interessant is, maar dat is een ander dilemma.

[Reactie gewijzigd door kaas-schaaf op 22 april 2021 10:26]

De Linux kernel broncode lokaal klonen en er patches op uitvoeren kan iedereen, het is tenslotte open source software. Dat is echter niet wat deze onderzoekers hier claimen te willen onderzoeken. Zij willen graag onderzoeken hoe makkelijk of moeilijk het is om slechte code, die in het beste geval niets doet en in het slechtste geval fouten en beveiligingsrisico's introduceert, geaccepteerd te krijgen in een belangrijk open source project als de Linux kernel.

Zie het als een stukje social engineering waarbij je dus eigenlijk test of de QA en code review processen van een softwareproject wel op orde zijn. Iedere ontwikkelaar weet namelijk dat er na documentatie schrijven niets saaier is dan de code van een ander beoordelen op kwaliteit en correctheid, en daarnaast kan dat in complexe software en met een low-level taal zoals C ook nog behoorlijk lastig zijn. De hypothese van het onderzoek zal er dus waarschijnlijk op neer komen dat men verwacht dat er laks wordt omgegaan met code reviews. Dan zijn ze bij de Linux kernel echter aan het verkeerde adres.

I see, duidelijk. Thanks!

Alleen doen ze geen research naar de code, maar naar "kunnen we ongemerkt bugs introduceren" of "hoe betrouwbaar is het Linux review proces".
Welnu, ze kunnen verder met hun onderzoek.
Het antwoord is; nee, dat gaat niet zo makkelijk. En als het ontdekt wordt, dan wordt er keihard opgetreden.
Ik denk alleen niet dat ze goed hebben nagedacht over de mogelijke consequenties, want ze staan nu op een zwarte lijst en al hun contributies worden onderzocht. Als 1 afdeling dit heeft gedaan, maar een andere afdeling is wel legitiem bezig, dan zullen ze intern ook wel boos hierover zijn.

Dat er andere manieren zijn om het te kunnen onderzoeken daar zijn we het over eens. Maar ik denk niet dat het jou oplossing is die dan bij het doel past. Het doel leek te bewijzen dat de OSS community bijdragen van onvoldoende kwaliteit door zou laten, tenzij de onderzoekers ingrepen. Deze community lijkt me iets heel anders dan even zelf een groepje opzetten om onderzoek op te doen. Het behoort voor onderzoek wel representatief te zijn.

Als ze willen aantonen dat er meer nodig is om de kwaliteit van de controle te verbeteren dan hadden ze waarschijnlijk ook gewoon de code kunnen bekijken en dan in plaats van jou suggestie die code kunnen doornemen op fouten. Dan zouden de onderzoekers zich ook nog extra nuttig maken, in plaats van voor onnodige commits te zorgen en dan te verwachten dat anderen daar maar extra tijd in gaan steken.

"Een paar minuten met iemand die ook maar een greintje kennis van C heeft, kan zien dat uw inzendingen helemaal niets doen."

Maar als dat zo duidelijk is, hoe kan dit dan:

“... waarvan verschillende ook de stable-branch hebben bereikt, ...”

Zo makkelijk moet iets toch niet daar terecht kunnen komen? De linux kernel is nogal belangrijk, dit is nogal een security risico.

Het greintje C kennis slaat op:
"Meer recentelijk probeerde de groep onderzoekers een nieuwe lading patches door te voeren in de kernel, die volgens de onderzoekers voortkwamen uit een static analysis tool."

In het verleden is kennelijk andere code aangedragen en in de stable branch terecht gekomen. Het lijkt me dat ze uit pure voorzorg alle code van deze universiteit verwijderd heeft. Het zegt wat mij betreft nog niets over het beveiligingsrisico van die code in de stable branch.

[Reactie gewijzigd door KoffieAnanas op 21 april 2021 19:20]

Klopt, maar deze universiteit is niet meer vertrouwd nu er 2 maal geprobeerd is problemen te veroorzaken, en wordt elke betrokkenheid volledig ontvlochten.

Terecht ook dat ze alle code uit voorzorg verwijderen.

Maar een universiteit bestaat niet uit 1 onderzoeksgroep, en onderzoekers en onderzoeksprojecten wisselen om de zoveel jaar. De code in de stable branch kan dus valide code zijn. Dat zullen ze de komende periode neem ik aan wel gaan uitzoeken. Nadat ze eerst die code eruit gehaald hebben.

ik veronderstel dat er aan een universiteit ook zoiets is als een ethische commissie en iemand die zicht heeft op wat voor papers er worden gemaakt en welke niet mogen worden gemaakt. In dit geval zou zo'n orgaan (mits kennis van zake) misschien hun naam niet door het slijk willen hebben zien gehaald worden

Ja, maar dat is politiek!

Dat is uit voorzorg. De Linux Kernel heeft niks met politiek te maken. Veel servers en bedrijven gebruiken Linux. Daarom moet dit veilig zijn, want het gaat over veel geld (financiële belangen).

Een bekende Amerikaanse gezegde: better safe than sorry.

Linux gaat helemaal niet over geld. Waar heb jij het over ?

De Linux kernel zelf misschien niet als je het zo letterlijk neemt; maar zowat de hele server wereld draait op Linux en er zijn genoeg betaalde distributies.

[Reactie gewijzigd door Sp3ci3s8472 op 21 april 2021 20:43]

Ik heb het over indirect. Inderdaad de Linux Kernel zelf draait niet om geld. Ik had het over de vele servers die bedrijven hebben en onderhouden. Wat een autistische reactie weer.

Ook verlenen veel bedrijven support en een distro zoals Red Hat Enterprise Linux Server. Vergis je niet in de Linux wereld waar het over miljarden aan Dollars/Euros gaat. Ook in het bestuur van de Linux Foundation zijn de bedrijven vertegenwoordigd. Veel Linux Kernel ontwikkelaars en Kernel maintainers worden door bedrijven betaald en/of financieel ondersteund om hun werkzaamheden te doen (dit is ook logisch aangezien de bedrijven Linux gebruiken en er geld aan verdienen. Bijvoorbeeld hosting bedrijven enz....).

De Linux wereld is al een lange tijd geleden geprofessionaliseerd. Dat iets open source is betekent niet dat je er niet aan mag verdienen.

As the English adjective "free" does not distinguish between "free of charge" and "liberty", the phrases "free as in beer" (gratis, freeware) and "free as in speech" (libre, open source) were adopted.

Bronnen: https://meta.stackexchang...free-as-in-free-beer-mean en https://en.wikipedia.org/wiki/Gratis_versus_libre

Open source software is vaak free as in speech en niet als free as in beer (hangt van het project/ontwikkelaar/bedrijf af en welk licentie er wordt gebruikt). Dat betekent dat de ontwikkelaar weldegelijk zijn software kan verkopen/abonnementen aanbieden met een open source licentie. Jij heb de vrijheid om de software te gebruiken, de broncode in te zien, te bewerken en weer te distribueren (verspreiden).

Wat bedrijven/ontwikkelaars van (commerciële) open source software vaak doen is support/onderhoud abonnementen aanbieden rondom de software.

EDIT: Bekende gezegde van Richard Stallman : "Think free as in free speech, not free beer

EDIT 2: Dit is ook een goede uitleg:

Free as in beer: Visual Studio Express. You can get it for free, and you can use it, but you can't see how it does things, can't change it, and likely can't make copies for other people. Free as in speech: Subversion. You can get the source code, hack it as you please, and distribute the original or hacked versions as you please. Free as in speech software is usually, but not necessarily, also free as in beer. I could sell you some free-as-in-speech software, but I can't prevent you from giving it away for free.

[Reactie gewijzigd door Remzi1993 op 21 april 2021 22:08]

"there is no such thing as free beer"

Tanstaafl (There ain't no such thing as a free lunch).

Het internet hangt zowat met Linux aan elkaar, tuurlijk gaat het ook over geld.

Want een 'ip' ban werkt zo goed tegen cheaters...

Ik denk dat dit slaat op de nieuwe patches die zijn aangeboden:

Meer recentelijk probeerde de groep onderzoekers een nieuwe lading patches door te voeren in de kernel, die volgens de onderzoekers voortkwamen uit een static analysis tool. De onderzoeker heeft de patches naar eigen zeggen opgestuurd in de hoop om feedback te krijgen. Kroah-Hartman schrijft in een reactie in de Linux-mailinglijst echter dat de patches twijfelachtig zijn en geen toegevoegde waarde hebben voor de kernel.

Meer recentelijk probeerde de groep onderzoekers een nieuwe lading patches door te voeren in de kernel

Die quote die je aanhaalt gaat dus alleen over die laatste reeks patches en niet de voorgaande. Ik vermoed dat de voorgaande niet zo overduidelijk waren, en dat de onderzoekers de patches steeds duidelijker maakte qua onzin om te kijken hoe ver ze konden gaan.

Het gaat in die eerste opmerking om een recente contributie, waar dus het vermoeden over bestaat dat er vulnerabilities in zitten als test. De patches die de stable branch hebben bereikt zullen (denk ik) deel zijn van een eerdere contributie, die gewoon legitiem zou kunnen zijn. Ik denk dat ze voor de zekerheid en om een duidelijk signaal af te geven alle contributies van die universiteit terugdraaien.

Wat betreft je zorg over het introduceren van vulnerabilities in de Linux kernel, er kijken en hoop slimme geesten mee die je niet makkelijk allemaal te slim af zal zijn met jouw vulnerability, daarom is het niet zo eenvoudig om zo iets te doen.

De onderzoekers (toch in het eerdere onderzoek) leverde een fix aan voor een bug, maar die fix was onzin. Als die fix dan vervolgens werd goedgekeurd, stuurde ze zelf een waarschuwing terug dat hun fix een kwetsbaarheid bevatte inclusief een patch die daadwerkelijk het probleem verhielp. Waarschijnlijk slaat dat op die laatste fixes en willen ze dat terugdraaien en zelf opnieuw oplossen?

Hubble telescoop effect.

Que ? 🥴

Nouja, daarmee kun je dus stellen dat de onderzoekers wel bewezen hebben hoe simpel het is, en daarmee zou je dus patches etc zeer ZEER goed moeten beoordelen.

Ik snap het even niet meer. De patches waren toch afgekeurd. En hebben er zelfs voor gezorgd dat serieuze patches van de uni worden verwijderd? Hoezo hebben ze dan aangetoond dat het makkelijk was?

Een professor bij de zelfde uni probeerde het ook al een keer en is ook gepakt. Volgens mij worden ze al zeer goed beoordeeld...

[Reactie gewijzigd door pookie79 op 22 april 2021 09:47]

Waarom de serieuze patches van de uni verwijderen als die gewoon goed zijn? Nee, dat wordt gedaan omdat ze die patches dus nu niet meer vertrouwen.

Dat wil niets zeggen over of ze het goed gecontroleerd hebben of niet. Ze nemen gewoon geen risico. Dus wat ze nu hebben bewezen is mij niet duidelijk (behalve dat ze bewezen hebben dat zij in elk geval onbetrouwbaar zijn). Het was duidelijk dus juist niet zo simpel om er doorheen te komen...

Ik vraag me af of ze ook zo zouden reageren als de test gedaan was door IBM. Gaat dan alle code van IBM/Redhat uit de kernel?

Linus heeft regelmatig voorstaande developers de maat genomen en al het werk dat ze leveren tegengehouden totdat er kwaliteitsverbetering zichtbaar was. Dit heeft o.a. plaatst gevonden met Kay Sievers van Red hat.

Kay, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause.

en

Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

en

Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap.

Het zou wellicht een aderlating zijn en Torvalds is redelijk pragmatisch, maar ik sluit niet uit dat men die stap zou doen.

IBM heeft een duidelijk eigenbelang bij de commits (net als Microsoft dat bij sommige delen / commits heeft). Toevoegen van code / drivers zodat hun hardware goed werkt op linux, en daardoor bruikbaar is in het bedrijfsleven.
Als ze dit op deze manier verprutsen, verpesten ze hun naam en creeeren ze een extra risico voor hun markt.

Patches worden ingediend en beoordeeld door een team van ontwikkelaars die deze kernel onderhouden. Per release branch zijn specifiek een of twee mensen eindverantwoordelijk. Door dit proces is bovenstaande dus ook niet 'zomaar' in de source terecht gekomen, maar geblokkeerd.

Maar dat is niet voorbehouden aan open source.

Dat zeg ik ook niet. Dat zal bij (grotere) closed source projecten inderdaad net zo goed gebeuren. Maar het is dus niet zo dat er bij open source geen (eind)verantwoordelijken zouden zijn.

Ik ken weinig bedrijven die serieus aan code-review doen: is een kosten kwestie. Als het gemaakt is en het komt door de tests heen dan mag het naar productie. Iedere minuut langer kijken betekent kosten.

Dan zit je bij de verkeerde bedrijven. Wij committen niets zonder code review.

Helaas heb ik ook dezelfde ervaring als @laka
Echter ik heb bij veel shit/goedkope bedrijven gewerkt waar ICT op de tweede plek staat en alles zo goedkoop mogelijk ontwikkeld moest worden. Je hebt gelijk dat dit in "betere" bedrijven niet voorkomt.

Je krijgt -1 maar je hebt wel een punt. Open source betekent alleen maar dat mensen de code kunnen reviewen, niet dat het altijd goed gebeurd. Als je closed source hebt (en dat vooral als het zakelijke software betreft) dan kan dat gevolgen hebben voor een leverancier als bugs niet doeltreffend worden opgelost. In de SLA staat tot in alle details gespecificeerd wat een leveranciers moet doen en hoe snel. Maar wie is verantwoordelijk een bijvoorbeeld een kernel bug snel op te lossen binnen een SLA?

Daarnaast hebben we toch ook vaak genoeg "simpele" security bugs gezien in open source software die niemand had opgemerkt omdat er niet fatsoenlijk gereviewd was. En dat laatste snap ik ook wel, als je een beetje verstand hebt van software is het natuurlijk veel leuker om nieuwe features te bedenken en te bouwen, dan pagina's aan code van anderen te gaan analyseren.

[Reactie gewijzigd door K-aroq op 21 april 2021 19:46]

Nou, dat is het vooral: iedereen roept “ja maar je kan zelf de code checken!”. De meesten van ons kunnen dat niet en ook niet alle dependencies en daar de sources weer van overzien. En dan nog ben je afhankelijk van een random community waarbij je ook geen centrale verantwoordelijkheid hebt.

Exact wat je zegt dus.

[Reactie gewijzigd door DigitalExorcist op 21 april 2021 19:54]

Dat is een typische quote die je veel hoort bij aanhangers van gesloten software, en het is zeker niet geheel onjuist. Gamers gaan inderdaad niet uitpluizen of die driver van hun videokaart veilig is, je wil gewoon dat het goed werkt want daar heb je voor betaald. Of bijvoorbeeld het ontwikkelen van een web pagina met python of C# backend: dit trekt vaak ontiegelijk veel dependencies binnen waarvan je niet gaat uitzoeken of alles wel zo goed in elkaar zit dan dat ze doen blijken. Zelf wanneer je jouw eigen linux distributie bouwt trek je enkele duizenden andere pakketten en dependencies binnen waarvan je nooit echt met zekerheid kan zeggen of dat allemaal wel pluis zit. Hetzelfde geld voor docker containers, hoeveel ontwikkelaars gaan letterlijk een niveautje dieper kijken om te zien opdat alles wel pluis is. Dat doe je inderdaad niet al te vaak. Je hebt dus niet veel andere keuze dan te vertrouwen dat hetgeen geleverd wordt doet wat het belooft, ongeacht of dit nu open of gesloten is. Als ontwikkelaar dien je uiteraard wel een beetje te volgen wat er beweegt in securityland zodat je kan inspringen wanneer grove fouten bekendgemaakt worden in de media. Maar dat staat los van open of gesloten bron software: elke software bevat fouten.

Je hebt gelijk: open-source is niet per definitie veiliger, meer bug-vrij, of meer featurefull dan closed-source software. Ze zijn beiden gewoon software, waarbij de open variant vanuit een community komt (een groep van individuen of bedrijven met gemeenschappelijke belangen) en closed-source vanuit één bedrijf die dit gebruikt of aanbiedt uit eigen belang. Vaak is er het misverstand dat open-source gratis software is van een bende nerds op hun zolderkamer. Dat staat er eigenlijk los van, vaak kan je betaalde services krijgen op deze open-bron software en bovendien is er veel software die door bedrijven gebruikt wordt waardoor het niet enkel uit eigenbelang is dat dit naar behoren moet werken. Ze hebben dus betaalde engineers aan het werk om deze open-bron software te onderhouden.

Je moet zelf goed overwegen ofdat open-source voor jou iets is. Een voorbeeld van hoe dit voor jou goed uit kan draaien: in embedded systems is er een hele beweging naar open-bron software (bv. linux) aangezien dat er in deze markt vaak snel support komt voor de chip die jij wil gaan gebruiken. Engineers met kennis terzake kunnen hun zelfgemaakte PCB's voor de embedded markt werkende krijgen omdat de bron open is, zonder afhankelijk te zijn van een leverancier als Microsoft of Apple e.d. De leverancier is in dit geval de community, inclusief jezelf. Bovendien kan je dit dan weer delen met de rest, want misschien wil je wel dat andere mensen je helpen om de support van jouw PCB beter te maken omdat zij dit commercieel ook op één of andere manier gebruiken, wie weet.

Open source gaat soms ook verkeerd, en dat heb ikzelf al enkele keren ondervonden. Wanneer ik bugs meld aan zogenaamde grote spelers die het hart vol zijn van open-bron software (en daar bovendien maar al te graag praatjes over maken), dan worden die niet altijd behandeld. Ik kan gerust m'n eigen fork maken, maar dan mis ik natuurlijk wel een beetje de nieuwe features en andere bugfixes. En om nu zelf m'n eigen fork te onderhouden, daar zijn de meeste KMO's een beetje te klein voor... Dit is dus een goed voorbeeld van hoe dat open-bron niet alle problemen oplost. Doch, ik heb ook wel forks van grotere projecten gemaakt van bijvoorbeeld een MS omdat zij het vertikken om er enige vorm van maintenance op te doen. Het is me soms echt raadselachtig waarom ze überhaupt met deze dingen af komen. Het stelt me alleszins wel in staat om de software te doen werken, want had dit gesloten geweest dan had ik helemaal niets.

Een ook als eindklant kan je kiezen voor open-bron software, of bijvoorbeeld code-ownership opeisen. Stel dat je ten alle tijden jezelf wilt loskoppelen van de leverancier van je software, dan zou je dat kunnen overwegen. Dit is bijvoorbeeld voor overheden wil een aandachtspunt.

Waar je wel verkeerd zit is dat je niet inziet hoeveel waarde linux met z'n open-bron heeft in onze wereld ervan. Jij hebt het misschien niet rechtstreeks nodig, maar je begrijpt denk ik niet echt goed hoe linux bijgedragen heeft aan jouw computer ervaring. Android heeft erop gebouwd omdat het open-bron was, de basis van docker ligt bij linux, vele routers bevatten een vorm van linux omwille van de chip support en aanpasbaarheid, jouw tv kan best wel linux draaien, vele computerclusters draaien linux omwille van de flexibiliteit en specifieke support, en ga zo maar door!

Oh ik ga al mee sinds de vroege Slackwareversies hoor. Daarvoor al “gewoon” met MS-DOS (3.30) begonnen.. etc. dus ik heb wel een idee hoe belangrijk de Linux kernel is.

En in de basis is het goed. Maar het wordt lang niet altijd goed uitgevoerd. En je zegt wel, “gamers gaan niet zelf door de code” maar dat is wel de groep die als hardste roept “ja maar opensource is veilig want je kán zelf door de code bladeren!”. Ja, dat kán, maar of het (goed) gebeurd.....

Je kunt het leren, en je kunt iemand inhuren. Daarmee is de drempel niet 0, maar wel lager dan jij insinueert. Iets als shared source geldt hetzelfde voor, behalve dat de macht bij de beslissing tot delen bij een gecentraliseerde macht ligt, zoals bijvoorbeeld Microsoft.

Volgensmij onderschat je nog hoe groot de gemeenschap is in open source software en hoeveel mensen voor de lol code door spitten. Er zijn door de loop van tijd ook bergen bugs en exploits verholpen dankzij dit soort mensen.
Het voordeel van open source is in ieder geval dat je open kan laten zien dat je code veilig is en niet stiekem een bitcoin miner op het achtergrond draait. Closed software moet je maar hopen dat de fabrikant zijn zaakjes op orde heeft en blind vertrouwen dat het alleen doet wat het zegt wat het doet.

"Hoe vaak heb jij of een bekende al iemand ingehuurd om te controleren of de broncode van je tekstverwerker wel klopt voordat je die installeert?" dit is niet de gedachte achter open source.

Ik ben geen eigenaar van een tekstverwerker. De tekstverwerker die ik draai, draai ik via het welbekende citroentje. Mag jij raden welke tekstverwerker dat is. Tenzij je Sublime als textverwerker telt... maar die is proprietary.

RedHat Enterprise bevat praktisch geen closed source componenten, muv iets als bijv een Nvidia kernel module of firmware. Anaconda was in een ver, ver verleden closed source. Da's ook de reden dat Oracle Unbreakable Linux bestaat, of CentOS. Het enige proprietary eraan zijn de trademarks. Die mag je niet zomaar gebruiken.

Heb je wel eens goed naar een SLA gekeken: het vaak een inzetplicht, geen oplosplicht. En dan closed source: solarwinds was behoorlijk closed source en daar vond geen enkele review plaats met als gevolg intrusie in de backend monitoring van allerlei grote ministeries en het DoD. Lekker dan.

Heartbleed bug was dan weer in open source software.

Zomaar roepen dat er niemand verantwoordelijk zou worden gehouden behalve de onderzoeker, zonder dat te onderbouwen, heeft geen punt. Dat is zelf geen verantwoordelijkheid nemen voor een bewering om kennelijk maar af te geven.

Daarbij is het duidelijk ook flauwekul om het te beweren. De onderzoeker is geen onschuldig persoon die zich netjes heeft gedragen en zich iets aangetrokken heeft van behoorlijke beheersing van de risico's, op kosten van de community. Door zowel de onderzoekers als de universiteit die dit verantwoord vond niet meer toe te laten is verantwoordelijkheid nemen. Daarbij nemen de ontwikkelaars verantwoordelijheid door de code dus niet meer zomaar te vertrouwen en er uit te halen nu duidelijk is dat de onderzoekers het acceptabel vonden dat er opzettelijk fouten in de kernel konden blijven met enkel de hoop dat het er door een ander weer uit zou worden gehaald. Daarnaast is het erg makkelijk om over de community te klagen als die slachtoffer lijkt te zijn van personen met minder goede bedoelingen en ze daar dan op ingrijpen. Dat klinkt meer als slachtoffers de schuld geven dat anderen misbruik maakt van de situatie.

Linux sluit geen SLA's af. Zodra je een SLA nodig hebt (= bedrijfsmatig gebruik maakt van Linux) is er een oplosgroep. Dat kan een externe partij zijn (Red Hat / Suse / Conical verdienen daar hun geld mee) of interne partij (jouw IT afdeling). En die zal verantwoordelijk zijn voor de oplossing van het probleem in jouw kernel. En wellicht samenwerken met Linux om het in de standaard kernel te krijgen.

Voor closed source geldt dat exact hetzelfde. Met dien verstande dat jouw interne IT Afdeling (via een aparte SLA) voor kernel problemen bij een externe partij moeten aankloppen.

Er is geen enkele garantie dat er bij closed source software wel snel bugs gefixed worden of dat code wel goed gereviewed wordt. En van closed source software weet je zeker dat er behalve de eigenaar niemand naar kijkt.

Dat is totaal niet hoe open source werkt.

Open source betekent niet dat iedereen zomaar alles in de code kan kliederen wat hij of zij wil. Het betekent wel dat de source code vrij beschikbaar is, en dat je bijdragen kunt insturen. Maar degenen die het project onderhouden zijn niet verplicht om jouw bijdragen te accepteren, en zullen wel degelijk een kwaliteitscontrole doen, om te zien of je bijdrage nuttig is en past bij de doelen van het project.

En dat is exact wat het verhaal van dit artikel laat zien. De onderzoekers van de universiteit moeten niet zeuren, ze hebben met opzet geprobeerd een kwaadaardige bijdrage in de Linux-kernel te krijgen, dan moet je niet verbaasd zijn als je daarvoor gestraft wordt.

En iedereen is natuurlijk gewoon verantwoordelijk voor zijn of haar bijdragen.

https://nakedsecurity.sop...-no-the-sky-isnt-falling/

It was only after the bug was fixed in the code tree that it turned into a vulnerability.

Security researchers trawling through the recent list of modifications in the code (known in the jargon as diffs, after the program diff that’s used to display the differences between two versions of a file) urged that this change deserved an official vulnerability number…

…because it meant that the old versions of OpenSSH had a user enumeration flaw. (This bug is now officially CVE-2018-15473.)

Het gaat om een bug die al ruim 20 jaar in OpenSSH heeft weten te blijven en nooit opgevallen is omdat simpelweg niemand zich hierover gebogen heeft. Natuurlijk kun je hetzelfde zeggen van closed source (en daar móet ook iets van gezegd worden!) maar het maakt open source dus niet automatisch "het" antwoord.

Ik kwam deze willekeurig tegen. In de basis ben ik het met je eens hoor, maar in de praktijk lijkt het toch niet altijd zo rooskleurig te zijn helaas...

[Reactie gewijzigd door DigitalExorcist op 22 april 2021 17:54]

Zouden ze die kwetsbaarheden dan bijvoorbeeld kunnen verkopen aan criminelen, mocht het wel erdoor gekomen zijn, of er zelf malware voor schrijven?

Dit is natuurlijk altijd de vraag met software, open source of niet:
- Hoe weet je dat de software die je kunt inzien, ook op jouw machine draait
- Hoe weet je dat de software die je kunt inzien, geen fouten bevat

Er wordt natuurlijk altijd over gespeculeerd om een fout in Linux, Apache, en dergelijke te stoppen en deze dan daarna door te verkopen... en dit gebeurd vast wel. Echter, het is lastig om te doen omdat je, als je 1 keer tegen de lamp loopt, daarna nog maar moeilijk een patch ingediend krijgt. Houdt er ook rekening mee dat jouw backdoor in een open source product, ook gevonden kan worden door anderen. Amazon, Microsoft, en Google kijken mee, maar ook de NSA, GCHQ en het Kremlin. In de praktijk is het waarschijnlijk makkelijker om een bestaande bug te vinden en deze te misbruiken. Dit doen de NSA en zo ook, en pas als het Kremlin hem ook gaat gebruiken patchen ze de bug.

Beide zijn complexe vragen en uiteindelijk is er een Web-of-Trust om dat te valideren. Ik check niet mijn eigen Linux kernels (prive of zakelijk), ik laat dat over aan Red Hat en Amazon. Ik heb hier eens een heel artikel over geschreven:

https://fedoramagazine.org/web-of-trust-part-1-concept/

[Reactie gewijzigd door Eonfge op 21 april 2021 20:11]

Om ook de fixes die de stable hebben bereikt terug te draaien gaat wel ver. Is het niet zo dat deze onderzoeker in het verleden wel waardevolle aanpassingen heeft gedaan die nu zonder pardon terug gedraaid worden wat weer andere gaten open maakt?
Dit zou ik dan eerder per geval onderzoeken.

Snap best dat ze nu juist als gevolg van de breach of trust zeggen: eerst alles eruit want we kunnen hun commits blijkbaar niet vertrouwen, en dan per commit misschien nog eens kijken of het wel legitiem was. Het zal tijd kosten om die commits te reviewen.

Als het allemaal op dit niveau was niet hoor. Er was maar één regel code toegevoegd,

Als ik de code zo bekijk zie ik ook niet helemaal hoe dit een bug is. Volgens mij doet het namelijk helemaal niks.

[Reactie gewijzigd door Wolfos op 22 april 2021 10:43]

Apart verhaal ik dacht altijd onderzoek goed gekeurd moeten worden door de faculteit? Bij mijn opleiding culturele antropologie aan de UU hadden ze de ethische toetsingscommissie en daar waren ze redelijk strikt als je onderzoek met mensen wilde doen. Heeft de universiteit dit niet voor computerkunde?

Jawel, maar het lijkt erop dat de ethische commisie niet door had dat het een experiment op mensen betrof. Is ook niet heel gebruikelijk in de CS hoek.

Hulde aan Greg wat mij betreft. De Linux kernel is geen speeltuin.

Hier is het paper te lezen wat twee gasten van UMN hebben geschreven. Tenenkrommend wat mij betreft. Dit ondermijnt een gedachtegoed van OSS: met een community mooie software bouwen.

Dat daar mensen misbruik van proberen te maken lijkt me logisch. Overal lopen ratten rond. Maar dat je dat zo moet onderzoeken en een project als de Linux kernel mee moet vermoeien is wat mij betreft redelijk kansloos en asociaal.

Quote uit het paper waar ik best wel om moest lachen:

We believe that an effective and immediate action would be to update the code of conduct of OSS, such as adding a term like “by submitting the patch, I agree to not intend to introduce bugs.”

Maar inderdaad een bijzonder slecht geschreven paper, ik zet ook erg mijn vraagtekens bij de (wetenschappelijke) waarde hiervan.