Hvilken idiot fik den ide ?

Af 26

Der er ingen relevant forskel på Windows autorun.inf, SQL injections og den totalt roelamme idiotiske ide at environment variabler skal kunne exekveres i /bin/bash.

Alle tre ting baserer sig på den samme fundamentale hjerneblødning: At exekvere data som kode uden at være blevet bedt om det.

Og længere er den ikke.

Software Tools filosofien gør meget ud af at der kan være fordele ved at behandle programmer som data, f.eks til at lade andre programmer analysere en kildetekst for problemer og fejltagelser.

Men der er aldrig nogen der nogensinde i ramme alvor har argumenteret for fornuften i at behandle data som programmer og give sig til at exekvere alt hvad der ligner noget exekverbart uden at nogen har bedt om det.

Microsoft gjorde det i Windows, fordi "det skulle være ekstremt brugervenligt" og derfor har vi idag en tabt generation der klikker på hvad som helst der dukker op på skærmen, uden overhovedet at tænke på hvad de ønsker eller kan opnå eller risikere derved.

SQL injections skyldes det forudsigelige impedans-mismatch når man indlejrer et programmeringssprog i et andet. Det var en dum ide i 1980erne og det er en dum ide idag.

Her er en god grundregel hvis du er i tvivl: Hvis det ikke ligger i en fil med 'x' bit, skal du ikke exekvere noget uden explicit at være blevet bedt om det.

phk

PS: For folk med det rigtige ordforråd lyder reglen: "There is no ambient authority for execution".

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Hans Andersen

ikke helt det samme; men ftp put txtfil med JCL kommandoer til jobentry systemet (JES) som destination istedet for en fil, vil submitte det pågældende JCL som et batchjob med de rettigheder til filer og subsystemer som den pågældende ftp bruger har på systemet. Meget praktisk, men administrationen af brugerrettigheder skal være på plads....

  • 3
  • 0
#2 Troels Henriksen

At afvikle data som kode er ganske rigtigt en dårlig idé i almindelighed, men jeg synes ikke man i dette tilfælde kan opfatte det som årsagen til bash-miseren. Sproget, der skal implementeres, er immervæk shell script, og det har i forvejen en del sære evalueringsregler (mange af dem handler netop om at fortolke kode som data), og det virker derfor ikke usandsynligt at en gemen programmeringsfejl kan manifesteres som kodeafvikling. Bevares, man kan med nogen rette postulere, at Unix shell script fundamentalt set er en vederstyggelighed, men det er nok ikke praktisk at eliminere det lige med det samme.

Nej, den sande dæmon i maskinen er i dette tilfælde features; specifikt at implementere flere features end højst nødvendigt. Bash er primært designet som (1) en interaktiv shell, og (2) et udvidet shell scripting sprog. At installere bash som /bin/sh, der basalt set blot bør være en POSIX-shell, er afsindigt dumt, da ens /bin/sh derved har langt flere features, og langt større angrebsoverflade, end nødvendigt.

Enhver feature rummer mulighed for fejl, og især potentiale for utilsigtet interaktion med andre features. Jeg tror ikke det er noget tilfælde, at både Heartbleed og denne bash-fejl findes i features, der sjældent bliver brugt, og som slet ikke er nødvendige i forhold til det problem programmerne skal løse.

(Bash's "unødvendige feature" var i dette tilfælde muligheden for at eksportere shellfunktioner via miljøvariable - ikke helt så ubrugeligt som den heartbeat-protokol der var hjemsted for Heartbleed, men aldeles unødvendigt når det handlede om at levere en /bin/sh.)

  • 12
  • 0
#3 Poul-Henning Kamp Blogger

At afvikle data som kode er ganske rigtigt en dårlig idé i almindelighed

Det er lidt ligesom at sige at "kanibalisme er et problem vi relativt set har under kontrol."

Data må ALDRIG exekveres som kode, med mindre der sker som følge af en explicit instruktion (ie: 'eval') om at gøre det.

Hvorfor nogen har tilføjet det til netop bash er ikke vigtigt, det vigtige er at vedkommende ikke har skyggen af begreb om de allermest basale principper i computersikkerhed.

  • 10
  • 0
#4 Troels Henriksen

Unix shell script, og makrosprog, er stort set bygget op omkring afvikling af data som kode. Jeg giver dig helt ret i at dette er et frygteligt sprogdesign, men man kan desværre ikke fjerne Unix shell script lige med det første.

Alle Unix shells har nødvendigvis en fundamental evne til at afvikle data som kode, i form af at placere en variabel som programnavn (eller bruge eval), og i bash manifesteredes dette sig som en fejl i en unødvendig feature.

  • 2
  • 0
#5 Lars Lundin

ikke helt det samme

Hvorfor ikke?

Tilbage i midten af 90'erne arbejdede jeg med et ikke helt uvigtigt udenlandsk system, som uden videre kunne tilgås med ftp, men som krævede en manuel arbejdsgang, hvis man skulle udføre kode på maskinen.

For at lette arbejdet, så gav en kollega mig netop den ide at lave en "named pipe" på systemet, og så en enkel gang gå igennem den manuelle arbejdsgang for at starte et script, der læste og derefter udførte de kommandoer, der blev sendt via ftp til min "named pipe".

I betragtning af at den eneste autentikering skete via ftp, så var det nok godt at vi nogle få år efter gik over til ssh.

  • 1
  • 0
#6 Poul-Henning Kamp Blogger

Unix shell script, og makrosprog, er stort set bygget op omkring afvikling af data som kode.

Nix.

Der er en meget klar separation imellem data og program i shell-scripts.

Hvis du vil fortolke data som program skal du explicit bede om det, f.eks med 'eval' eller "back-ticks"

Ikke at separationen ikke kunne være bedre, det kunne den bestemt, men som udgangspunkt sker der ingen sammenblanding.

  • 3
  • 0
#10 Troels Henriksen

Ikke at separationen ikke kunne være bedre, det kunne den bestemt, men som udgangspunkt sker der ingen sammenblanding.

Det kan også gøres mere implicit:

#!/bin/sh  
   
prog=$1  
data=$2  
   
$prog $data

Hvis du kalder dette script med et tomt $1, så afvikles $2 som et programnavn. Det kan virke oplagt i dette tilfælde, men forestil dig, at det er noget kringlet logik der producerer $prog, og at det er muligt for angriberen at få denne logik til at danne en tom variabel.

Man kan gardere sig mod disse problemer ved at quote de rigtige steder, men klassisk shell script gør det fundamentalt set alt for nemt at skyde sig selv i foden.

  • 13
  • 0
#11 Dennis Jessen

Microsoft gjorde det i Windows, fordi "det skulle være ekstremt brugervenligt" og derfor har vi idag en tabt generation der klikker på hvad som helst der dukker op på skærmen, uden overhovedet at tænke på hvad de ønsker eller kan opnå eller risikere derved.

Den er lidt svær at 'fortolke'. Det omvendte er vel opnået - en paranoid masse der frygter at interagere. Skulle alt køre efter det du beskriver, er det vel heller ikke nødvendigt "overhovedet at tænke på hvad de ønsker eller kan opnå eller risikere derved".

  • 1
  • 0
#12 Klaus Elmquist Nielsen

Dagens ret: roegryde med bash bashing!

Umiddelbart er jeg enig i betragtningerne. Men mon ikke udvikleren på feature realiseringstidspunktet har tænkt "wow smart" og glemt de alternative anvendelser heraf?

Er der i øvrigt nogen der kort kan forklare hvordan denne fejl udnyttes via nettet?

  • 2
  • 0
#14 Uffe Seerup

Er der i øvrigt nogen der kort kan forklare hvordan denne fejl udnyttes via nettet?

Når bash startes så gennemløber den environment variable for at se om der er "funktioner" defineret i dem (på den måde kan man "eksportere" bash funktioner). Uheldigvis er der en fejl så hvis der er noget efter funktionsdefinitionen - så udføres det som kommandoer.

Ved traditionel CGI overføres parametre via env variable. Altså input som kan kontrolleres af angriberen. Hvis bash startes på et senere tidspunkt (fx en bash wrapper) så kører angrebet.

Det kan fx også være PHP som starter via CGI - men senere laver et kald ud til bash. Env variable forbliver i processens levetid så angrebet kan ligge "sovende" indtil bash på et tidspunkt bliver startet.

Jeg tror ikke at angrebet kan gennemføres gennem FastCGI.

En anden mulighed (ikke bekræftet endnu) er at dhclient på nogle distroer måske benytter bash til at sætte IP adresse med parametre modtaget fra DHCP server. Sæt en ond DHCP server op på mcdonalds (eller på virksomhedsnettet) og udsted svar med angrebet i. dhclient er SUID root - så det er total kompromittering.

(SUID er et bevidst, men kæmpe hul i *nix sikkerhedsmodellen)

  • 8
  • 0
#18 Troels Henriksen

Da jeg har en stump jeg jævnligt bruger der mere eller mindre følger denne opskrift vil jeg gerne vide hvad et sikkert designmønster ville være.

Sæt altid gåseøjne rundt om dine shell-variable. Det er ikke nok til at lave robuste shell scripts, da der også er problemer omkring wildcard-ekspansion, men det tager det værste.

Alternativt, undgå at bruge shell scripts. Det er enormt praktisk til hurtige hacks og interaktiv brug, eller situationer hvor robusthed ikke er vigtigt, men til alt andet bør man bruge et sprog med færre fælder.

  • 10
  • 0
#19 Robert Larsen

...env. variabel er:

smiley(){  
    if [ $? == 0 ]; then  
        echo ':)'  
    else  
        echo ':('  
    fi  
}  
export PS1="\$(smiley) \h:\w $ "

Det bevirker at min terminal altid viser, om senest udførte kommando gik godt:

:) robert-workstation:~ $ true  
:) robert-workstation:~ $ false  
:( robert-workstation:~ $

Ganske rart...falder det lidt ind under eksekvering af data?

  • 6
  • 0
#20 Troels Henriksen

Nej, det er bare læsning af data. Jeg tror selv den mest sikkerhedsparanoide vil medgive, at (visse!) programmeringssprog har brug for evnen til at træffe beslutninger baseret på værdien af variable.

Jeg har selv noget lignende i min PS1, bortset fra at det er den egentlige returkode der udskrives.

  • 2
  • 0
#22 Brian Hansen

En anden mulighed (ikke bekræftet endnu) er at dhclient på nogle distroer måske benytter bash til at sætte IP adresse med parametre modtaget fra DHCP server. Sæt en ond DHCP server op på mcdonalds (eller på virksomhedsnettet) og udsted svar med angrebet i. dhclient er SUID root - så det er total kompromittering.

Virker fint, der er nok noget på Metasploit om meget kort tid, hvis ikke allerede.

  • 2
  • 0
#26 Finn Christensen

Microsoft gjorde det i Windows, fordi "det skulle være ekstremt brugervenligt" og derfor har vi idag en tabt generation der klikker på hvad som helst der dukker op på skærmen, uden overhovedet at tænke på hvad de ønsker eller kan opnå eller risikere derved.

Den er lidt svær at 'fortolke'. Det omvendte er vel opnået - en paranoid masse der frygter at interagere.

Tror i begge er alvorligt 'skadet' af faget ;)

Det er ikke en enkelt generation men flere.

Og hvem har sikret at de nuværende småbørn, 'iBims-XL' generationen, få lidt solid viden og it-disciplin. Dags dato - ingen - så de må også overleve i junglen, da hverken deres folkeskole og ophav slår til her.

Selv fjollehovederne i kommunalbestyrelser, på borgen og i de statslige styrelser etc. Hvem som helst kan fortælle dem hvad som helst, og de har ikke den fornødne basis selv til skelne mellem skidt og kanel - synligt i fuld offentlighed!

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen