Slår alarm om stort sikkerhetshull

[OHJohansen]

Kan ta over maskinen din.

Slår alarm om stort sikkerhetshull

[LoveAmiga]

Og fremdeles er det noen som lar seg lure til å tro at enkelte OS er helt trygge...

[kobresia]

PROTIP: dette har pent lite med Linux å gjøre. Takk for meg.

Endret 25. september 2014 av kobresia

[fa2001]

Hvis man kan starte bash har man allerede tilgang til et shell, og kan kjøre alle kommandoer som brukeren har tilgang til.

 

Det kan være et problem i noen tilfeller når en server kaller bash med bruker-input på kommandolinjen, og bare luker bort de kjente "farlige" tegnene, som ; \n < > | etc.. Det skjer, men kan ikke sammenlignes med heartbleed.

[Cretinous Git]

Jøje meg. Det hadde vært en fordel om hw.no faktisk hadde kompetente folk til å skrive for seg.

[kwrl]

Det var da voldsomt så oppblåst dette hørtes ut da. Hvis man får sneket inn noe kode via bash så er det på ingen måte gitt at man har full kontroll over maskinen. Bash kjører ikke i kernel mode, og kan naturlig nok ikke gjøre hva enn det vil.

 

Det er da vitterlig almenn praksis å ha minimalt av rettigheter satt på brukerne som kjører applikasjoner koblet til nett også.

 

Dette er på ingen måte sammenlignbart med heartbleed så vidt jeg kan forstå.

 

Bash er forøvrig ikke en del av linux heller.

[enixitan]

Slår alarm om stort sikkerhetshull i Linux

 

Dermed kan utallige maskiner som kjører operativsystemet Linux være i faresonen, et system som brukes i alt fra enkelte mobiltelefoner til biler. Feilen kan ifølge CNN også gjelde maskiner som Apples Macer, Windows-maskiner og IBM-baserte varianter.

Det var jo ei treffande overskrift.

[G]

Snakk om å "bash'e på leggen".

 

Hvorfor har Windows eksempelvis dette bash-systemet? Dere sier jo vitterlig så i artikkelen ihvertfall.

Endret 25. september 2014 av G

[tommyb]

Hvis man kan starte bash har man allerede tilgang til et shell, og kan kjøre alle kommandoer som brukeren har tilgang til.

 

Det kan være et problem i noen tilfeller når en server kaller bash med bruker-input på kommandolinjen, og bare luker bort de kjente "farlige" tegnene, som ; \n < > | etc.. Det skjer, men kan ikke sammenlignes med heartbleed.

Dette er en (vanlig) misoppfatning av dette sikkerhetshullet. Dette sikkerhetshullet er vurdert til høyeste alvorlighetsgrad. Du får ikke høyeste alvorlighetsgrad dersom man må ha tilgang til bash for å angripe.

 

Du trenger ikke tilgang til bash. Du trenger heller ikke finne et CGI-script som mangler validering på et input-felt. Det du trenger er for eksempel å kjøre en ondsinnet GET-kommando på en server som har CGI påslått. Eller en ondsinnet MIME-type-definisjon. Eller noe annet enn CGI, jeg har sett OpenSSL bli nevnt. Og jeg har sett OpenSSH nevnt. Jeg tror OpenSSL er feil og OpenSSH riktig.

 

Jeg skal ikke si at denne ikke er oppblåst, men faktum er at alle som tror du trenger lokal tilgang til bash eller et usikret CGI-script, har misforstått.

Endret 25. september 2014 av tommyb

[tommyb]

Jeg har ikke lest om hvorfor de nevner at noen Windows-maskiner kan være berørt, men dersom man f.eks. har installert KDE for Windows, Apache/Tomcat for Windows, etc, er det vel en risiko for at man har bash installert. Eller cygwin. Git for Windows er nevnt som et potensielt angrepspunkt.

 

Feilen er ikke operativsystemspesifikk, men programvarespesifikk for bash. Som er vanligst på andre operativsystemer enn Windows, men også kan eksistere på Windows.

Endret 25. september 2014 av tommyb

[Hårek]

"Bash er en kommandolinje som brukes for å kontrollere ledeteksten"

En fullstendig meningsløs oversettelse av "Bash is the software used to control the command prompt"

[enixitan]

Men du vil uansett bare få eit shell med rettighetane til brukaren som køyrer prosessen som køyrer shell-et. Altså, rettighetane til web-serveren/skriptet, eller kva det måtte vere. Eg kan sjå at ein ondsinna DHCP-server er eit problem, men det er avgrensa til nokon med fysisk tilgang til nettverket ditt, som i tillegg klarer å svare på DHCP-førespurnaden din før den ekte DHCP-serveren i nettverket gjer det. Det kan vere eit problem i store lokalnettverk, til dømes universitet.

 

Om nokon framleis køyrer web-serveren sin som root, synd for dei.

 

Dette er sjølvsagt eit større problem for typiske embedded-system (ruterar, IP-kamera, andre smådingsar) fordi dei som regel bare har ein brukar (root), men kor mange embedded-system har bash installert i det heile tatt? Alle eg kjenner til brukar Busybox (med ash).

Endret 25. september 2014 av enixitan

[Leftie]

 

Hvis man kan starte bash har man allerede tilgang til et shell, og kan kjøre alle kommandoer som brukeren har tilgang til.

 

Det kan være et problem i noen tilfeller når en server kaller bash med bruker-input på kommandolinjen, og bare luker bort de kjente "farlige" tegnene, som ; \n < > | etc.. Det skjer, men kan ikke sammenlignes med heartbleed.

Dette er en (vanlig) misoppfatning av dette sikkerhetshullet. Dette sikkerhetshullet er vurdert til høyeste alvorlighetsgrad. Du får ikke høyeste alvorlighetsgrad dersom man må ha tilgang til bash for å angripe.

 

Du trenger ikke tilgang til bash. Du trenger heller ikke finne et CGI-script som mangler validering på et input-felt. Det du trenger er for eksempel å kjøre en ondsinnet GET-kommando på en server som har CGI påslått. Eller en ondsinnet MIME-type-definisjon. Eller noe annet enn CGI, jeg har sett OpenSSL bli nevnt.

 

Jeg skal ikke si at denne ikke er oppblåst, men faktum er at alle som tror du trenger lokal tilgang til bash eller et usikret CGI-script, har misforstått.

 

 

Ja, men i henhold til CVE teksten, er det aldri snakk om noe privilege escalation. Jeg mener sikkerhetshullet er alvorlig (det er for så vidt alle remote execution sårbarheter), men ville lagt meg på 9, gitt at man kun får de samme privilegiene som bash instansen har fra før.

[tommyb]

Ja, men i henhold til CVE teksten, er det aldri snakk om noe privilege escalation. Jeg mener sikkerhetshullet er alvorlig (det er for så vidt alle remote execution sårbarheter), men ville lagt meg på 9, gitt at man kun får de samme privilegiene som bash instansen har fra før.

 

 

Ja, du får eksekvere kode som den brukeren du angriper (f.eks. apaches bruker). I gamle dager var det i praksis slik at hadde du tilgang til en bruker, kunne du skaffe deg tilgang til root. Med SELinux påslått, skal dette være betydelig vanskeligere. Men det er en grunn til at det finnes en skala for vurdering av sikkerhetshull, og det er en grunn til at denne kommer på toppen av det. Flinkere folk enn meg og deg [antar jeg, jeg vet ikke hvilket fagfelt du er spesialisert på] som setter disse vurderingene. Jeg er i alle fall langt unna kompetansenivået.

 

...Og dette gjelder jo alle remote execution sårbarheter. Jeg vet ikke hva som skal til for at slike "bare" skal få en nier.

Endret 25. september 2014 av tommyb

[RattleBattle]

Men du vil uansett bare få eit shell med rettighetane til brukaren som køyrer prosessen som køyrer shell-et. Altså, rettighetane til web-serveren/skriptet, eller kva det måtte vere. Eg kan sjå at ein ondsinna DHCP-server er eit problem, men det er avgrensa til nokon med fysisk tilgang til nettverket ditt, som i tillegg klarer å svare på DHCP-førespurnaden din før den ekte DHCP-serveren i nettverket gjer det. Det kan vere eit problem i store lokalnettverk, til dømes universitet.

 

Om nokon framleis køyrer web-serveren sin som root, synd for dei.

 

Dette er sjølvsagt eit større problem for typiske embedded-system (ruterar, IP-kamera, andre smådingsar) fordi dei som regel bare har ein brukar (root), men kor mange embedded-system har bash installert i det heile tatt? Alle eg kjenner til brukar Busybox (med ash).

Hvis vi tar et eksempel: Hvis man for eksempel har en php-fil på webserveren som viser MySQL-passord i klartekst, noe som ikke er uvanlig, så vil vel denne sårbarheten gjøre at man kan liste det ut og igjen utføre bashkommandoer som gjør at man kan utføre MySQL-spørringer i databasen. Eller tar jeg feil?

Endret 25. september 2014 av RattleBattle

[RattleBattle]

Og fremdeles er det noen som lar seg lure til å tro at enkelte OS er helt trygge...

Er vel helst fanboys av Windows som liker å fremstille det sånn.

Endret 25. september 2014 av RattleBattle

[tommyb]

 

Men du vil uansett bare få eit shell med rettighetane til brukaren som køyrer prosessen som køyrer shell-et. Altså, rettighetane til web-serveren/skriptet, eller kva det måtte vere. Eg kan sjå at ein ondsinna DHCP-server er eit problem, men det er avgrensa til nokon med fysisk tilgang til nettverket ditt, som i tillegg klarer å svare på DHCP-førespurnaden din før den ekte DHCP-serveren i nettverket gjer det. Det kan vere eit problem i store lokalnettverk, til dømes universitet.

 

Om nokon framleis køyrer web-serveren sin som root, synd for dei.

 

Dette er sjølvsagt eit større problem for typiske embedded-system (ruterar, IP-kamera, andre smådingsar) fordi dei som regel bare har ein brukar (root), men kor mange embedded-system har bash installert i det heile tatt? Alle eg kjenner til brukar Busybox (med ash).

Hvis vi tar et eksempel: Hvis man for eksempel har en php-fil på webserveren som viser MySQL-passord i klartekst, noe som ikke er uvanlig, så vil vel denne sårbarheten gjøre at man kan liste det ut og igjen utføre bashkommandoer som gjør at man kan utføre MySQL-spørringer i databasen. Eller tar jeg feil?

 

 

Ja, det kan nok skje. Men det skal være nok å gjøre en GET til en server med CGI påslått, hvis jeg forstår riktig. Altså noe som er mye mer sannsynlig enn at man har tilgang til en usikret PHP-fil.

[Leftie]

Ja, du får eksekvere kode som den brukeren du angriper (f.eks. apaches bruker). I gamle dager var det i praksis slik at hadde du tilgang til en bruker, kunne du skaffe deg tilgang til root. Med SELinux påslått, skal dette være betydelig vanskeligere. Men det er en grunn til at det finnes en skala for vurdering av sikkerhetshull, og det er en grunn til at denne kommer på toppen av det. Flinkere folk enn meg og deg [antar jeg, jeg vet ikke hvilket fagfelt du er spesialisert på] som setter disse vurderingene. Jeg er i alle fall langt unna kompetansenivået.

 

...Og dette gjelder jo alle remote execution sårbarheter. Jeg vet ikke hva som skal til for at slike "bare" skal få en nier.

 

Vel, litt samme tankegang som til stadighet diskuteres her angående skala for spillanmeldelser. Hvis det skal få toppkarakter, bør det ikke kunne tenkes ut noen forbedringer. En kombinasjon av remote execution og privilege escalation ville kanskje være det ultimate marerittet.

 

For øvrig er det ett sikkerhetsfirma som har gitt dette sikkerhetshullet 10/10.

National Vulnerability Database er ikke helt enig

 

Jeg har jobba med drift av Unix og Linux servere i ~10 år, men har ikke spesialisert meg innenfor sikkerhet, så det er absolutt et poeng du har med tanke på eksperters vurdering av sikkerhetshullet.

[tommyb]

 

Vel, litt samme tankegang som til stadighet diskuteres her angående skala for spillanmeldelser. Hvis det skal få toppkarakter, bør det ikke kunne tenkes ut noen forbedringer. En kombinasjon av remote execution og privilege escalation ville kanskje være det ultimate marerittet.

 

For øvrig er det ett sikkerhetsfirma som har gitt dette sikkerhetshullet 10/10.

National Vulnerability Database er ikke helt enig

 

Jeg har jobba med drift av Unix og Linux servere i ~10 år, men har ikke spesialisert meg innenfor sikkerhet, så det er absolutt et poeng du har med tanke på eksperters vurdering av sikkerhetshullet.

 

 

I tillegg til at jeg så et selskap som ga det 10 av 10, og et annet som ga det 10 av 10 på tre av tre målte parametre, så har faktisk National Vulnerability Database gitt det 10:

 

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

 

Du lenket til en annen vulnerability...

Endret 25. september 2014 av tommyb

[enixitan]

Hvis vi tar et eksempel: Hvis man for eksempel har en php-fil på webserveren som viser MySQL-passord i klartekst, noe som ikke er uvanlig, så vil vel denne sårbarheten gjøre at man kan liste det ut og igjen utføre bashkommandoer som gjør at man kan utføre MySQL-spørringer i databasen. Eller tar jeg feil?

Du kan køyre alle kommandoar brukaren du "kom inn som" kan køyre. Det er derimot ikkje gitt at du får sjå output frå kommandoen du snik inn, så om eg sender ein GET-førespurnad som får serveren til å køyre "cat passwords.txt" får eg ikkje nøvendigvis innhaldet i passwords.txt som svar på førespurnaden. Ved å opprette eit reverse shell vil du kunne få eit shell på serveren, men framleis bare med rettighetane til brukaren du kom inn som. Du vil då kunne sjå filene denne brukaren har tilgang til å sjå, til dømes, og køyre PHP-skriptet du nevner, og sjå resultatet av det, samt køyre spørjingar mot databasen, gitt at du har (tilgang til) all informasjonen du treng; brukarnavn, passord, server osb.