Hvilken idiot fik den ide ?

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....

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.)

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.

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.

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

Ja.

Med 'perl -T' kan man dertil i nogen grad beskytte sig mod at inddata utilsigtet eksekveres ifbm. setuid.

Er der andre og mindre forkætrede sprog med samme mulighed?

PS. V2s debatsystem ignorerer mine backticks...

Som udgangspunkt: Alle kompilerede sprog ?

Fair nok, jeg glemte at skrive 'fortolkede' sprog...

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.

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".

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?

Men mon ikke udvikleren på feature realiseringstidspunktet har tænkt "wow smart" og glemt de alternative anvendelser heraf?

Det virker som hovedgrunden til at den slags sker - ja.

Microsoft-udviklerne synes nok også det var enormt smart at eksekvere VisualBasic scripts attachet i emails indtil ILOVELYOU og venner illustrerede hvor nyttigt det var.

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)

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).

Opgaver, der når op på den (lille) kompleksitet, skal således ikke kodes i bash.

Opgaver, der når op på den (lille) kompleksitet, skal således ikke kodes i bash.

Hvilken opgave henviser du her til?

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.

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.

...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?

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.

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.

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

Der stod 4 moduler er udkommet på sidste tweet jeg lige så

Der stod 4 moduler er udkommet på sidste tweet jeg lige så

Jeg fandt to overvågnings kameraer jeg kunne lægge ned ved at besøge firmware update siden til dem, med en tilpasset user-agent. De er heldigvis ikke tilgængelige udefra :)

..det vigtige er at vedkommende ikke har skyggen af begreb om de allermest basale principper i computersikkerhed.

Når mennesker når et niveau af at for mange har for lidt forstand på for meget (tak Churchill :) så havner vi i forsimple løsninger.

Det er jo ikke første gang vi kvajer os i grande skala.

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!