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.
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.
Tror det är sällsynt med CGI skript som anropar Bash.
Sällsynt måhända, men det existerar.
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.
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.
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`.
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.
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.
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.