Säkerhetshålet Shell Shock drabbar världens webbservrar

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av rektor:

grep exec|passthru|shell_exec|system # Funktioner i PHP
grep /bin/*sh # Filer, sh, bash, dash, zsh, fish, tsh, etc
grep "`" # Backtick operator i PHP

Samt fler språk än PHP (Perl, Python, Ruby, etc.). Samt det som kanske inte finns installerat just idag. Dessutom är det många ställen som använder Bash som behöver göra detta, men ändå inte är utsatta, vilket dock skulle behöva kontrolleras.

Uppdaterar man Bash så är man säker på sitt personliga system, men det finns ju miljoner andra system runt om i världen, och på många av dessa lagras säkert information om både dig och mig. Problemet med storskaliga attacker är inte bara att just min dator skulle vara utsatt för risk, utan att stora mängder av datorer runt om i världen är utsatta. Problemet är inte löst bara för att min dator säkrats upp.

Skrivet av rektor:

Om du anropar `mkdir` so förmodar jag att den inte anropar mkdir via Bash, det vore ju konstigt.

Konstigt: tja, vanligen så har språk interna funktioner för sådana enkla saker. Omöjligt att hitta i kod: verkligen inte. Skalanrop via `system()`, backticks, etc., är lätta att hitta i skarpa kodexempel. Det ger direkta möjligheter att exempelvis använda skalomdirigering, vilket kan förenkla kod betydligt.

Det handlar generellt inte om hur världen borde se ut, utan om hur världen ser ut.

Skrivet av rektor:

Tror det är sällsynt med CGI skript som anropar Bash.

Sällsynt måhända, men det existerar.

Skrivet av rektor:

CGI blir mer och mer sällsynt, och dom som använder det brukar använda Perl skript.

Perl körs nog vanligare genom `mod_perl` idag, men likväl är de sekundära angreppen som beskrevs tidigare öppna.

Skrivet av rektor:

Shell scripts används sällan för CGI, och används det så brukar man väl använda 'sh', inte 'Bash'.

På många system är `/bin/sh` länkat till `/bin/bash`. `sh` är idag generellt inte en egen binär, utan bara något som garanteras vara en Bourne shell-kompatibel tolk. På Debianbaserade system sköts detta av Dash (dels med baktanken om att snabba upp skriptkörning, men även just för att minska attackytan som hjälp till att förebygga sådana här problem), men på andra fortfarande av just Bash.

Skrivet av rektor:

Bash är mer för slutanvändare, för att exekvera script brukat man använda 'sh' och när man skriptar brukar man vilja undvika sk "Bashisms" (bash-specifik syntax och funktioner).

"Brukar" är att ta i — jag rekommenderar generellt att använda `#!/bin/sh` som tolk till shellskript, tills man eventuellt tydligt märker att man behöver Bash. Det betyder inte att alla följer en sådan praxis, och dessutom så väljer man ibland att använda Bash, då det stöder många saker som Bourne shell inte definierar.

Bashisms behöver bara undvikas om man explicit anger `#!/bin/sh`; om man anger `#!/bin/bash` så är det ju fritt fram att nyttja Bashspecifika funktioner (om man inte utnyttjar några Bashspecifika funktioner så borde man ju inte explicit kalla på Bash överhuvudtaget, kan tyckas).

Och återigen så används Bash som `/bin/sh` på flera system. Det är ofta också grunden till problematiken bakom "Bashisms" — folk skriver `#!/bin/sh`-skript, säger "det funkar på min maskin", för att sedan se dem krascha på ett system som inte använder Bash som `/bin/sh`.

Skrivet av rektor:

Webbservern (och daemons i övrigt) körs normalt inte som root och bör heller inte göra det. Dom brukar köras som "nobody", alternativt en specifik användare för varje daemon.

De bör inte göra det, och gör det inte som standard om man använder distributionens verktyg för att initiera servertjänsten hos de stora distributionerna, men i verkligheten så ser det återigen ibland annorlunda ut.

I vilket fall så har webbserverns användare läsrättigheter till just de uppgifter som webbservern behöver kunna läsa, vilket ofta inkluderar exempelvis databasanvändaruppgifter i klartext.

Eventuella luckor gäller ej heller bara enkom webbservrar, även om en av de mest uppenbara attackerna kan ske den vägen. Det kommer säkert dyka upp förslag till hur man kan utnyttja liknande attacker via mailservrar och annat, eller DHCP som redan nämnts.

Den stora osäkerheten, vilket nämnts av flera i tråden, är att alla attackvektorer ännu inte är upptäckta eller genomgångna.

Skrivet av rektor:

Dessa går heller inte att logga in på, då deras shell i /etc/passwd är konfigurerat att peka mot /bin/nologin.

Det handlar inte om att "logga in" som användaren. Om man kan få användaren att exekvera ett skal genom vilket man exempelvis kan skapa omvänd anslutning till en fjärrkontrollerad dator så har man i praktiken fått åtkomst till systemet. Det kvittar vad användaren i sig har för angivet loginskal då man får dem att exekvera en ny process från en inloggad session. Det behöver ej heller vara så långt gånget som att få ett fullt skal; det kan räcka gott med att be dem att spotta ut innehållet av en konfigurationsfil direkt över HTTP (exempelvis med databasinloggningsuppgifter) till användarens webbläsare för att kunna öppna upp andra attacker.

Ofta så fungerar större exploits som kombinationer av mindre delar. Även om just denna inte ger ett färdigkonfigurerat root-skal till en attackerare så kan det vara en del i en större attack. Kan man få ett kommando att köras kan man också enkelt sätta igång exempelvis en fork-bomb som sänker tjänsten, vilket dels kan vara en del i en attack, men även högst irriterande på egen hand.

Skrivet av rektor:

Sedan bör de vara jailade med chroot, och köra AppArmor.

Återigen många "bör" . Oavsett vilket så kan de ändå läsa känslig information; annars skulle de inte kunna fungera. Ovanstående säkerhetslösningar berör inte dessa punkter.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av deegan:

Ja det är det andra scenariot du pekar ut som kommandot är effektivt mot. Man måste ju dock inte bli root på en gång, det kan ju finnas lokala exploiter. Så det är ju en flerstegsraket, men det är ju ofta så.

Helt rätt, denna lucka kommer säkert vara en standarddel av exploit-kits en lång tid framöver.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
stockholm
Registrerad
Okt 2007

Patchades bort igår

Skrivet av rektor:

Bash är väl mer av ett användarskal, och många servrar använder väl 'sh' som default skal istället?

Jag tror det här kommer patchas och fixas rätt snabbt. Jag tror inte det är en så allvarlig säkerhetsbugg.

Den låter ganska svårexploaterad.

Trädvy Permalänk
Medlem
Registrerad
Jan 2004

Jaha. Då blir det till att använda WAMP, tills skiten är åtgärdad -.-

Citera mig om du önskar ett snabbare svar.
Om mig

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002

Quick notes about the bash bug, its impact, and the fixes so far [lcamtuf's blog] var en i mina ögon kort och tydlig översikt över vad som händer i Bash (åtminstone vad gäller ursprungsbuggen CVE-2014-6271), inklusive en kort redogörelse om varför det är ett problem.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Plats
Karlshamn
Registrerad
Jan 2008
Skrivet av betan:

Vet du inte vad cygwin är har du det inte som, någon skrev innan. Cygwin och Exchange har inget att göra med varandra. Varifrån fick du att det just skulle vara Exchange?

Skickades från m.sweclockers.com

Tänkte eftersom de kör IIS. Inte för Exchange delen utan mest webbdelen för Outlook Web Access.
Men då slipper man göra nått iallafall. Har inga Linux webservrar.

Trädvy Permalänk
Medlem
Plats
#Archlinux
Registrerad
Jun 2007
Skrivet av truppenrille:

Patchades bort igår

Mjo liknande här.

[2014-08-13 06:29] [PACMAN] upgraded bash (4.3.018-3 -> 4.3.022-1) [2014-08-25 12:21] [PACMAN] upgraded bash (4.3.022-1 -> 4.3.024-1) [2014-09-24 22:04] [PACMAN] upgraded bash (4.3.024-1 -> 4.3.024-2)

Arch - Makepkg, not war -||- Asus Crosshair Hero VI -||- GSkill 16GiB DDR4 15-15-15-35-1T 3466Mhz -||- AMD 1600x @ 4.1GHz -||- nVidia MSI 970 Gaming -||- Samsung 850 Pro -||- EVEGA G2 750W -||- Corsair 570x -||- Asus Xonar Essence STX -||- Sennheiser HD-650 -||
Arch Linux, one hell of a distribution.

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av rektor:

Bash är väl mer av ett användarskal, och många servrar använder väl 'sh' som default skal istället?

/bin/sh pekar i väldigt många distar på /bin/bash

Skrivet av rektor:

Jag tror det här kommer patchas och fixas rätt snabbt. Jag tror inte det är en så allvarlig säkerhetsbugg.

Där har du fel, det är en extremt allvarlig säkerhetsbugg. Det är värre än heartbleed. Läs på lite.

Skrivet av rektor:

Den låter ganska svårexploaterad.

Tvärtom, den är väldigt lättexploaterad (det finns många attackvektorer, och många av de som finns är ofta förekommande).

Ser fler av dina inlägg och det är inte mycket rätt info i något av inläggen. Ex.vis så räcker det inte med att en user har /bin/false som shell. system()-anrop använder sig av /bin/sh -c och om då /bin/sh är en symlänk till /bin/bash, ja, go figure.

EDIT: Nuvarande "fixen" är heller inte komplett. Den kan göra det svårare, men problemet kvarstår.

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Dimman:

/bin/sh pekar i väldigt många distar på /bin/bash

Där har du fel, det är en extremt allvarlig säkerhetsbugg. Det är värre än heartbleed. Läs på lite.

Tvärtom, den är väldigt lättexploaterad (det finns många attackvektorer, och många av de som finns är ofta förekommande).

Ser fler av dina inlägg och det är inte mycket rätt info i något av inläggen. Ex.vis så räcker det inte med att en user har /bin/false som shell. system()-anrop använder sig av /bin/sh -c och om då /bin/sh är en symlänk till /bin/bash, ja, go figure.

EDIT: Nuvarande "fixen" är heller inte komplett. Den kan göra det svårare, men problemet kvarstår.

Heartbleed klassades av t.ex. Bruce Schneier som en 11 på en tiogradig skala, den gjorde det möjligt att läsa upp till 64kB RAM som med lite tålamod innehåll lösenord och kryptonycklar, helt utan att något loggades överhuvudtaget.

Detta är inte lika illa, men det är fortfarande rejält illa.

Att använda detta via SSH är totalt meningslöst, har du SSH access kan du ändå köra vad som helst i 999.99 fall av 1.000.000 och det är fortfarande med din eget user-ID. Och hur ska du utnyttja användare som har /bin/false som login-skal? Opensshd använder fork() + exec() för att starta login-skal, inte system().

Tyvärr lär väl många köra webbserver som en relativt privilegierad användare, men man är idiot om man kör den som "root". Krävs fortfarande att "/bin/sh" är en länk till "/bin/bash" + att det finns någon externt påverkbar väg att starta något via ett ska på ett sätt där man kan påverka miljövariablerna. Tyvärr verkar detta inte helt ovanligt enligt en del rapporter

Farligaste vägen för "vanliga" användare verkar vara DHCP-klienten om man kopplar upp sig via okända WiFi-hotspots. Har kan tydligen iOS potentiellt vara påverkad, vet inte om något läst om man rett ut om DHCP-klienten i iOS är påverkad eller ej.

Android verkar inte direkt påverkad då den inte länkar "/bin/sh" till "/bin/bash", inte allt för många lär köra webbserver på sin Android-enhet och här är inte DHCP-klienten påverkad.

Inbyggda system som kör Linux kör nästan uteslutande ash som skal (via BusyBox), så dessa är inte påverkade.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Södra norrland
Registrerad
Jul 2003

Så hur är det för oss som rullar OS X då? Är ganska säker på att jag kör Bash sedan jag lekte runt med wine, macports och dylikt för att få igång lite trilskande program.

Vad bör man göra för att patcha det?

Stationär: i5 750@3.8GHz kylt av H80 P'n'P| Asus DC2 7970 | 8GB RAM | 750GB SSD + 2.5TB HDD | FD Define R2 | beQuiet Dark Power 850W |
Bärbar: 13" rMBP | i5 2.4GHz | 8GB RAM | 256GB SSD | Intel Iris |

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Willhelm:

Så hur är det för oss som rullar OS X då? Är ganska säker på att jag kör Bash sedan jag lekte runt med wine, macports och dylikt för att få igång lite trilskande program.

Vad bör man göra för att patcha det?

Bash verkar vara standardskalet i OS X sedan en tid tillbaka, så du och mer eller mindre alla andra med OS X kör det troligen även utan att ha lekt runt bland inställningar (kanske snarare främst då).

Det är bara att invänta en ny uppdaterad programversion. Den kanske redan finns tillgänglig genom en vanlig systemuppdatering.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Registrerad
Dec 2009

Jag tänkte på det här istället:

Kanske en uppföljare? Ingen aning själv...

Edit:

Nej, tydligen finns det Shellshock: Nam '67 som föregår den här.

Jag har aldrig fattat varför man kallar program som bash, cmd och csh för skal/shell. Vad kommer uttrycket ifrån? Ska kolla runt lite.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2007
Skrivet av RzrTrek:

Ubuntu teamet var riktigt snabba med att täppa igen säkerhetshålet!

USN-2362-1: Bash vulnerability

Och som nån nämnt använder Ubuntu, som standard, Dash till standard.

Lite retfullt, Linux som skulle vara så säkert

Spel: Ryzen 7 1800x, Vega 64 8GB, 16GB DDR4 Flare X
Har haft dessa GPUer: Tseng ET6000, Matrox M3D, 3DFX Voodoo 1-3, nVidia Riva 128, TNT, TNT2, Geforce 256 SDR+DDR, Geforce 2mx, 3, GT 8600m, GTX460 SLI, GTX580, GTX670 SLI, 1080 ti AMD Radeon 9200, 4850 CF, 6950@70, 6870 CF, 7850 CF, R9 390, Vega 64
Lista beg. priser GPUer ESD for dummies

Trädvy Permalänk
Medlem
Registrerad
Dec 2009
Skrivet av Herr Kantarell:

Och som nån nämnt använder Ubuntu, som standard, Dash till standard.

Lite retfullt, Linux som skulle vara så säkert

Men jag trodde dash kördes för att det är snabbare än bash, men att det är lite för smalt och ersätts av bash när det behövs.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Luminous:

Jag har aldrig fattat varför man kallar program som bash, cmd och csh för skal/shell. Vad kommer uttrycket ifrån? Ska kolla runt lite.

Det kommer från Unix-föregångaren/förebilden Multics. En person (Louis Pouzin) som jobbade med förarbete som ledde fram till Multics tänkte fram konceptet och valde helt enkelt att kalla detta för ett skal [The Origin of the Shell]:

Skrivet av Louis Pouzin:

However, this idea of using commands somehow like a programming language was still in the back of my mind. Christopher Strachey, a British scientist, had visited MIT about that time, and his macro-generator design appeared to me a very solid base for a command language, in particular the techniques for quoting and passing arguments. Without being invited on the subject, I wrote a paper explaining how the Multics command language could be designed with this objective. And I coined the word "shell" to name it. It must have been at the end of 64 or beginning of 65.

Tanken är kanske liknelsen mellan ett "skal" som omger en "kärna". Skalet kan bytas ut, men kärnan är densamma. Termen verkar i vilket fall vara på väg att fira 50-årsjubileum.

Sedan har betydelsen vidgats, och idag pratar man väl även om exempelvis Windows grafiska gränssnitt som ett "skal".

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Luminous:

Men jag trodde dash kördes för att det är snabbare än bash, men att det är lite för smalt och ersätts av bash när det behövs.

Bash används vanligen som det "interaktiva skalet", dvs det som en användare startar när de öppnar en terminal, då det har en massa funktioner som underlättar för detta (tab completion, avancerad historik, med mycket mera). När man kallar på ett skript genom "standardskalet" `/bin/sh` så kallas dock i praktiken Dash på exempelvis ett Debianbaserat system, då `/bin/sh` egentligen är en kvarleva från äldre tider då det pekade på något som kallas Bourne shell ("Bash" står för "Bourne Again Shell" och är GNU-projektets reimplementation).

Bash stöder dock mer avancerade konstruktioner som kan underlätta skriptning i vissa fall, och överhuvudtaget möjliggöra saker som ett strikt Bourne shell-kompatibelt skal inte kan göra. Om man vill använda dessa funktioner så ska man explicit kalla på `/bin/bash` (den exakta platsen kan vara föremål för en annan utläggning), vilket också av denna anledning görs i många skript.

"Förr" så var det dock vanligt att man körde just hela Bash, med alla "bells and whistles" som `/bin/sh`, då det även är (mer eller mindre) fullt kompatibelt med Bourne shell, vilket var dess ursprungliga designidé. Det ledde dock till en del olater när personer skrev skript för `/bin/sh` som använde Bashspecifika konstruktioner och inte uppfattade att de var problematiska då det ju ändå var Bash som tolkade. När Debian började migrera systemet till Dash i stället, som är tänkt att vara ett närapå minimalt, snabbt och säkert skal med Bourne shell-kompatibilitet, så uppdagades mängder med "Bashisms" som smugit in i systemskript som kallade på `/bin/sh`. Det tog ett bra tag att reda ut alla dessa.

Om man upptäckte ett sådant problem i sitt skript så var en lösning att sätta sig in i skillnaderna [1, 2] och förhoppningsvis bara behöva fixa några enstaka problem. Ett annat sätt, som blev än mer attraktivt om det rörde sig om mer än något enstaka problem, var att helt enkelt ändra sin shebang till att peka på `/bin/bash` och köra vidare som tidigare. Detta var ju också den enda rimliga lösningen ifall man faktiskt förlitade sig på den utökade Bashfunktionaliteten.

Så: ja, Bash används fortfarande för skriptning här och var, av olika anledningar. Men om någon mjukvara generellt vill utföra något med systemets skal så kallas `/bin/sh`, vilket i exempelvis Debian alltså inte längre motsvarar Bash, utan Dash. Anropet `system()` (se `man 3 system`) som i bakgrunden kallas via flertalet programmeringskonstruktioner använder just `/bin/sh`, vilket alltså på Dash-baserade system inte innebär något problem i detta fall.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Registrerad
Aug 2013

Men men men... det är ju öppen sås!!

Trädvy Permalänk
Medlem
Registrerad
Nov 2013
Skrivet av Yoshman:

För att utnyttja buggen måste man endera ha access till systemet via SSH

http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_re...

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av Yoshman:

Heartbleed klassades av t.ex. Bruce Schneier som en 11 på en tiogradig skala, den gjorde det möjligt att läsa upp till 64kB RAM som med lite tålamod innehåll lösenord och kryptonycklar, helt utan att något loggades överhuvudtaget.

Detta är inte lika illa, men det är fortfarande rejält illa.

Det scenariot du nämner ovan; vi kan applicera det i fallet med webbservern. Du får samma privilegier som webbservern i och med att den payload du skickar med exekveras som den användaren. Du kan därmed få samma utfall som Heartbleed, fast bättre, om du väljer att göra det och vet vad du gör, poängen är att möjligheten finns. Att det inte loggas med Heartbleed är en sanning med modifikation, har du övervakning på trafiken, vilket många större firmor har via proxyservrar, så kan du se exakt vad som skickas ut.

EDIT: Bruce Schneier är krypto-/säkerhetsexpert, med det sagt är det inte säkert att han är Linuxexpert och insatt i omfattningen av denna bugg. Jag är rätt säker på att vi lär få höra mer från honom om ämnet inom snar framtid.

Skrivet av Yoshman:

Att använda detta via SSH är totalt meningslöst, har du SSH access kan du ändå köra vad som helst i 999.99 fall av 1.000.000 och det är fortfarande med din eget user-ID. Och hur ska du utnyttja användare som har /bin/false som login-skal? Opensshd använder fork() + exec() för att starta login-skal, inte system().

Jag har inte nämnt något om OpenSSH eller huruvida det är meningslöst eller ej? Har ej heller påstått att OpenSSH skulle använda sig av system()-anrop, så jag vet inte varför du tar upp det som om jag gjort påståenden om det?

Skrivet av Yoshman:

Tyvärr lär väl många köra webbserver som en relativt privilegierad användare, men man är idiot om man kör den som "root". Krävs fortfarande att "/bin/sh" är en länk till "/bin/bash" + att det finns någon externt påverkbar väg att starta något via ett ska på ett sätt där man kan påverka miljövariablerna. Tyvärr verkar detta inte helt ovanligt enligt en del rapporter

Inbyggda system som kör Linux kör nästan uteslutande ash som skal (via BusyBox), så dessa är inte påverkade.

Jo tack jag vet, jag jobbar med firmware på inbyggda system (och är väl bekant med Busybox)

Med Heartbleed så fanns det inte många attackvektorer, de var rätt lätta att identifiera. Men detta är något helt annorlunda. Det kommer dyka upp attackvektorer som är lika obskyra som buggen själv. Den är rankad som 10/10 på allvarlighetsskalan av NIST.

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av Herr Kantarell:

Lite retfullt, Linux som skulle vara så säkert

Blanda inte ihop äpplen och päron nu. Vem som helst kan installera osäkra userspace-applikationer, det gör inte kärnan mindre säker.

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Medlem
Plats
Helsingborg
Registrerad
Dec 2010

Haha t-shirt för buggen. För de extra nördiga kanske.
http://www.redbubble.com/people/markuslindberg/works/12713462...

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Dimman:

Det scenariot du nämner ovan; vi kan applicera det i fallet med webbservern. Du får samma privilegier som webbservern i och med att den payload du skickar med exekveras som den användaren. Du kan därmed få samma utfall som Heartbleed, fast bättre, om du väljer att göra det och vet vad du gör, poängen är att möjligheten finns. Att det inte loggas med Heartbleed är en sanning med modifikation, har du övervakning på trafiken, vilket många större firmor har via proxyservrar, så kan du se exakt vad som skickas ut.

EDIT: Bruce Schneier är krypto-/säkerhetsexpert, med det sagt är det inte säkert att han är Linuxexpert och insatt i omfattningen av denna bugg. Jag är rätt säker på att vi lär få höra mer från honom om ämnet inom snar framtid.

Jag har inte nämnt något om OpenSSH eller huruvida det är meningslöst eller ej? Har ej heller påstått att OpenSSH skulle använda sig av system()-anrop, så jag vet inte varför du tar upp det som om jag gjort påståenden om det?

Jo tack jag vet, jag jobbar med firmware på inbyggda system (och är väl bekant med Busybox)

Med Heartbleed så fanns det inte många attackvektorer, de var rätt lätta att identifiera. Men detta är något helt annorlunda. Det kommer dyka upp attackvektorer som är lika obskyra som buggen själv. Den är rankad som 10/10 på allvarlighetsskalan av NIST.

Nämnde SSH för vad var annars din kommentar mot att det inte hjälper att sätta login-shell till /bin/false riktad mot? Att man har det som login-shell för användare för olika services är ju självklart, men för att utnyttja CGI-vägen så behöver man aldrig använda login-skal så där blir det irrelevant att ens diskutera login-skal.

Är rätt säker på att denna kommer rankas på 10/10, men det är att ropa varg för så illa är det inte. Typ alla servers som innehåller något viktigt lär redan vara patchade eller så var det nog inte såå viktigt.

Heartbleed var värre. Visst är det så att vissa loggar meta-data om trafiken, men de maskiner som loggar "ser" bara krypterade paket när det är TLS så man vet inte vad som skickats ut. Tvivlar starkt på att man sätter om infrastruktur som delar ut session-nycklar från servers till loggers, vore ju som att be om problem i den hanteringen. Om man terminerar TLS i proxyn så har man ändå ingen loggning då hearbeat-paketet då går mot den och de loggades inte av OpenSSL. Så den data som läckte är än idag total okänd och man använder typiskt SSH för att trafiken är värd att skydda.

Om AES visar sig vara värdelös imorgon, vad ska man då sätta det på skalan? Är lite det jag sätter mig emot, detta och Heartbleed var illa men det var knappast en katastrof för våra ekonomiska system. Transaktioner man utför mot sin bank är typisk signerade via en HW-token, så även om Heartbleed skulle kunna gjort så att någon kan se vad jag såg när jag var inloggad så leder det ändå inte till att den personen kan utföra transaktioner mot mitt konto. De skulle se hur mycket pengar/värdepapper jag hade och vilka räkningar jag betalade, men det är allt.

Tycker detta är ett mindre problem för det har än mindre sannolikhet att få stora (stora som i att det spelar någon roll i global skala) ekonomiska konsekvenser. Tyvärr är det ju det som räknas i vårt samhälle, om ett problem inte leder till att det svider i plånboken så är det inte speciellt många som bryr sig i slutändan. Det är då knappast ett 10/10 problem, så jag håller inte med Schneier i att det var den katastrof han vill blåsa upp det till, för honom handlar det mycket om att boosta sitt eget namn och därmed sitt marknadsvärde (vilket i sig bara visar på god känsla för "marknaden").

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Trädvy Permalänk
Medlem
Plats
Kristinehamn
Registrerad
Aug 2014

Så. Då har jag patchat upp BASH.

Före:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
$ env foo='() { echo "foo body";}; echo "evaluated when interpreting foo definition, bad idea!"' bash -c 'echo "Bash started, calling foo"; foo'
evaluated when interpreting foo definition, bad idea!
Bash started, calling foo
foo body

Efter:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"bash: varning: x: ignoring function definition attempt
bash: fel vid import av funktionsdefinition för "x"
this is a test
$ env foo='() { echo "foo body";}; echo "evaluated when interpreting foo definition, bad idea!"' bash -c 'echo "Bash started, calling foo"; foo'
bash: varning: foo: ignoring function definition attempt
bash: fel vid import av funktionsdefinition för "foo"
Bash started, calling foo
bash: foo: kommandot finns inte

Citat:

sudo kill 1

För er som fattar. Haha.

Nej du, vi ska inte sticka dolken i vårt eget hjärta.

Kör Linux - Yes! We are the 2 percent! And growing... Föreslå inte ens något Windows-exklusivt om jag inte specifikt frågar efter något till Win.
2600K - 18GB RAM - 1TB HDD - 64GB SSD - GTX 650 Ti Boost
Minnesvärda trådar: 1, 2

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av Yoshman:

Nämnde SSH för vad var annars din kommentar mot att det inte hjälper att sätta login-shell till /bin/false riktad mot? Att man har det som login-shell för användare för olika services är ju självklart, men för att utnyttja CGI-vägen så behöver man aldrig använda login-skal så där blir det irrelevant att ens diskutera login-skal.

Min kommentar var riktad mot rektor's påstående om att de flesta users (för demoner typ httpd) har /bin/false som som login-shell och att det då skulle vara lugnt, så är alltså inte fallet, vilket är vad jag påpekade

Skrivet av Yoshman:

Är rätt säker på att denna kommer rankas på 10/10, men det är att ropa varg för så illa är det inte. Typ alla servers som innehåller något viktigt lär redan vara patchade eller så var det nog inte såå viktigt.

För att patcha servrarna behövs en patch som funkar, det har inte funnits förrän just nu verkar det som (ska pushas ut imorgon enligt Chet).

Skrivet av Yoshman:

Heartbleed var värre. Visst är det så att vissa loggar meta-data om trafiken, men de maskiner som loggar "ser" bara krypterade paket när det är TLS så man vet inte vad som skickats ut. Tvivlar starkt på att man sätter om infrastruktur som delar ut session-nycklar från servers till loggers, vore ju som att be om problem i den hanteringen. Om man terminerar TLS i proxyn så har man ändå ingen loggning då hearbeat-paketet då går mot den och de loggades inte av OpenSSL. Så den data som läckte är än idag total okänd och man använder typiskt SSH för att trafiken är värd att skydda.

Vi kan väl komma överens om att vi inte kommer enas om en gradering av denna bugg kontra heartbleed, helt enkelt för att jag tror att vi menar olika saker med graderingen. Båda är väldigt allvarliga är vi överens om

(Jag tror nog att de flesta större företag som tillhandahåller känslig information i någon skala sparar all trafik, inte bara metadata. Loggning kan också vara ett svårtolkat begrepp. Att lagra utgående datatrafik är en typ av loggning, medans den traditionella sysloggen är mer loggning så som vi tänker oss. Här krävs det också handpåläggning för att logga enskilda användares actions osv, det är inget som är default (förutom default-loggning som existerar från program som användaren använder..) ..) Det blir komplext hur man än vrider och vänder på det.

Skrivet av Yoshman:

Om AES visar sig vara värdelös imorgon, vad ska man då sätta det på skalan? Är lite det jag sätter mig emot, detta och Heartbleed var illa men det var knappast en katastrof för våra ekonomiska system. Transaktioner man utför mot sin bank är typisk signerade via en HW-token, så även om Heartbleed skulle kunna gjort så att någon kan se vad jag såg när jag var inloggad så leder det ändå inte till att den personen kan utföra transaktioner mot mitt konto. De skulle se hur mycket pengar/värdepapper jag hade och vilka räkningar jag betalade, men det är allt.

Tycker detta är ett mindre problem för det har än mindre sannolikhet att få stora (stora som i att det spelar någon roll i global skala) ekonomiska konsekvenser. Tyvärr är det ju det som räknas i vårt samhälle, om ett problem inte leder till att det svider i plånboken så är det inte speciellt många som bryr sig i slutändan. Det är då knappast ett 10/10 problem, så jag håller inte med Schneier i att det var den katastrof han vill blåsa upp det till, för honom handlar det mycket om att boosta sitt eget namn och därmed sitt marknadsvärde (vilket i sig bara visar på god känsla för "marknaden").

Jo men precis, lite detta jag menar med det jag skrev ovan att beroende på vad det är man graderar (utifrån vad man bedömmer) så får man olika resultat. Det är också svårt att dra några slutsatser om vilka ekonomiska konsekvenser det kan få när det bara handlar om dörröppnare. Resten är upp till attackern att ha kunskap inom ifall det är möjligt att nyttja hålet till vidare attacker som i sin tur kan få ekonomiska konsekvenser.

Citera mig för svar.
Arch Linux

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002

Det lutar enligt maillistor dels givetvis åt att den specifika "oväntade funktionaliteten" gällande att Bash exekverar eftersläntrande kod i en funktionsdefinition ska täppas till, och likaså det sekundära parsningsproblemet som var kvar efter första patchomgången (båda sakerna har i praktiken redan hänt).

Samtidigt så är det många som för första gången fått höra att det överhuvudtaget är möjligt att ge funktionsdefinitioner via miljövariabler genom specialsyntaxen `env X='() {}'`. I exempelvis Ubuntu just nu, med säkerhetsfixarna ovan applicerade, kan man fortfarande "skriva över" exempelvis `ls` enbart genom en miljövariabel enligt:

$ env ls='() { echo hej hopp;}' bash -c 'ls dokument' hej hopp

Då detta fortfarande kan kännas lite olustigt i ljuset av vad som uppdagats (även om man kan filosofera kring vad det skulle kunna ha för säkerhetskonsekvenser i praktiken, sans buggar likt den som upptäcktes) så är en patch på väg in som visserligen fortfarande kommer tillåta detta, men bara om miljövariablerna är på en viss form, med `BASH_FUNC_` som prefix och `()` som suffix.

Debian har redan applicerat denna patch (`variables-affix.patch` i deras system), så där skulle ovanstående kodexempel faktiskt köra "vanliga" `ls`, men man kan alltså fortfarande definiera funktioner genom miljövariabler genom konstruktionen:

$ env 'BASH_FUNC_ls()'='() { echo hej hopp;}' bash -c 'ls dokument' hej hopp

Skillnaden är att det krävs ett specifikt prefix för att Bash ens ska försöka sig på att tolka innehållet i miljövariabeln som kod (att Bash kunde exekvera innehållet i vilken variabel som helst var ju en del av problemet med CVE-2014-6271) som inte av misstag skulle råka passera en vitlista med tillåtna miljövariabler in i en process (och även vore lätt att definiera i en svartlista, om det någonstans skulle krävas).

Eventuellt kommer det i framtiden krävas någon speciell Bashflagga för att överhuvudtaget tillåta denna typ av funktionsdefinitioner, men den diskussionen kan nog dröja ett tag.

Diskussionen kring hur klokt det är att använda Bash som `/bin/sh` kommer nog också återupplivas av detta. Förhoppningsvis/troligen kommer även andra distributioner än Debian (och dess derivat) att börja använda ett mindre funktionsrikt skal för detta ändamål för att minska den möjliga attackytan.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Registrerad
Aug 2002

Finns det något sätt att testa utifrån ifall ett system är sårbart? Naturligtvis är jag inte ute efter att göra något olagligt, isf hade jag inte ställt frågan här och inte under mitt vanliga nick.

Som jag fattar det så är lite mera komplext än att man bara kan köra ett enda script eller dylikt för att testa? Det verkar bero på både ditten och datten och kräva en lite mera riktad attack?

i7-8700k | ASUS ROG Strix Z370-F Gaming | 4x8GB Corsair Vengeance LPX 3200 | ASUS GeForce GTX 1070 Dual OC | Samsung 860 EVO 1TB | WD Black 3TB | Noctua NH-U14S | Fractal Design ARC | Seasonic Focus Plus Gold 650FX | ASUS BC-12D2HT | ASUS Xonar Essence STX

Trädvy Permalänk
Hedersmedlem
Registrerad
Okt 2002
Skrivet av Micke O:

Finns det något sätt att testa utifrån ifall ett system är sårbart? Naturligtvis är jag inte ute efter att göra något olagligt, isf hade jag inte ställt frågan här och inte under mitt vanliga nick.

Som jag fattar det så är lite mera komplext än att man bara kan köra ett enda script eller dylikt för att testa? Det verkar bero på både ditten och datten och kräva en lite mera riktad attack?

Du måste en ingångspunkt till systemet som tolkas med Bash i något steg. En möjlighet är att datorn kör en webbserver som serverar CGI-skript som använder Bash (vilket inkluderar "vanliga" `/bin/sh` på många system pga länkning). Det finns dock inga direkta standardwebbapplikationer som fungerar så (åtminstone inte vad jag vet, eller vad jag läst rapporteras hittills) då det egentligen inte är en speciellt vacker lösning till att börja med. För att angripa den vägen behöver man alltså redan veta något om systemet i fråga.

Attacker via DHCP-anslutningar kräver ju som första steg att en sårbar dator väljer att ansluta till din DHCP-server (eller åtminstone befinner sig på ett LAN med en dator som skickar DHCP-paket).

Det kan finnas möjlighet att attackera exempelvis Gitservrar som använder någon (tänkt) nedlåst frontend för användarinteraktion som bakom kulisserna använder Bash för att exekvera `git`. Jag har inte sett några direkta möjligheter till allvarliga attacker genom denna väg än, dock: det är snarare på nivån att någon skulle kunna "hacka sig själv" om de verkligen ville, snarare än att kunna förstöra något för andra.

Har man tillgång till Bash på själva systemet i fråga så är det dock buslätt att testa genom en oneliner, vilket redan postats i denna tråd, i skärmbilden för nyheten, på T-shirtar (!), etc.

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Trädvy Permalänk
Medlem
Registrerad
Aug 2002
Skrivet av phz:

Du måste en ingångspunkt till systemet som tolkas med Bash i något steg. En möjlighet är att datorn kör en webbserver som serverar CGI-skript som använder Bash (vilket inkluderar "vanliga" `/bin/sh` på många system pga länkning). Det finns dock inga direkta standardwebbapplikationer som fungerar så (åtminstone inte vad jag vet, eller vad jag läst rapporteras hittills) då det egentligen inte är en speciellt vacker lösning till att börja med. För att angripa den vägen behöver man alltså redan veta något om systemet i fråga.

Attacker via DHCP-anslutningar kräver ju som första steg att en sårbar dator väljer att ansluta till din DHCP-server (eller åtminstone befinner sig på ett LAN med en dator som skickar DHCP-paket).

Det kan finnas möjlighet att attackera exempelvis Gitservrar som använder någon (tänkt) nedlåst frontend för användarinteraktion som bakom kulisserna använder Bash för att exekvera `git`. Jag har inte sett några direkta möjligheter till allvarliga attacker genom denna väg än, dock: det är snarare på nivån att någon skulle kunna "hacka sig själv" om de verkligen ville, snarare än att kunna förstöra något för andra.

Har man tillgång till Bash på själva systemet i fråga så är det dock buslätt att testa genom en oneliner, vilket redan postats i denna tråd, i skärmbilden för nyheten, på T-shirtar (!), etc.

Tack för svar! Ja att testa systemet när man redan är inloggad klarar jag Känns dock inte så relevant eftersom jag antar att är man redan inloggad så finns det förmodligen andra och kanske bättre sätt att elevera sig. Hittade också någon "oneliner" för att söka efter script som anropade om det nu var '/bin/sh' eller nått. Typ.

i7-8700k | ASUS ROG Strix Z370-F Gaming | 4x8GB Corsair Vengeance LPX 3200 | ASUS GeForce GTX 1070 Dual OC | Samsung 860 EVO 1TB | WD Black 3TB | Noctua NH-U14S | Fractal Design ARC | Seasonic Focus Plus Gold 650FX | ASUS BC-12D2HT | ASUS Xonar Essence STX

Trädvy Permalänk
Medlem
Plats
Västra götaland
Registrerad
Jul 2012

GA-Z97P-D3 | i5 4690K | 8Gb DDR3 | Gigabyte GF 760GTX | Samsung 850EVO 120Gb
Kylare: CPU: CM TX3 EVO3 | CPU: Arctic TwinTurbo II | PSU: Silver Power SP-S460FL (Passiv)
Lur: OnePlus 3T | NAS: Synology 211j + XPEnology Hemmabygge

Trädvy Permalänk
Medlem
Plats
Höör
Registrerad
Jun 2002
Skrivet av Yoshman:

Heartbleed var värre.
...
Tycker detta är ett mindre problem för det har än mindre sannolikhet att få stora (stora som i att det spelar någon roll i global skala) ekonomiska konsekvenser.

Het läsning för din del såhär några veckor efteråt:
http://webcache.googleusercontent.com/search?q=cache:I8s8KmZh...

Citera mig för svar.
Arch Linux