Některé souvislosti o chybě:CVE-2014-6271
Bash podporuje export nejen proměnných shellu, ale také funkce shell
do jiných instancí bash prostřednictvím prostředí procesu do
(nepřímých) podřízených procesů. Aktuální verze bash používají proměnnou prostředí
pojmenovanou názvem funkce a definici funkce
začínající „() {“ v hodnotě proměnné k šíření definic funkcí
prostředím. K této chybě zabezpečení dochází, protože
bash se po zpracování definice funkce nezastaví; it
pokračuje v analýze a provádění příkazů shellu podle definice funkce
. Například nastavení proměnné prostředí naVAR=() { ignored; }; /bin/idspustí /bin/id, když je prostředí importováno do procesu bash
.
Zdroj:http://seclists.org/oss-sec/2014/q3/650
Kdy byla chyba představena a jaká je oprava, která ji plně opravuje? (Viz CVE-2014-7169)
Jaké jsou zranitelné verze mimo uvedené v CVE (zpočátku) (3.{0..2} a 4.{0..3})?
Byl chybný zdrojový kód znovu použit v jiných projektech?
Další informace jsou žádoucí.
Související:Co znamená env x='() { :;}; command’ bash do a proč je to nejisté?
Přijatá odpověď:
TL;DR
Zranitelnost shellshock je plně opravena v
- Na větvi bash-2.05b:2.05b.10 a vyšší (včetně opravy 10)
- Ve větvi bash-3.0:3.0.19 a vyšší (včetně opravy 19)
- Ve větvi bash-3.1:3.1.20 a vyšší (včetně opravy 20)
- Ve větvi bash-3.2:3.2.54 a vyšší (včetně opravy 54)
- Ve větvi bash-4.0:4.0.41 a vyšší (včetně opravy 41)
- Ve větvi bash-4.1:4.1.14 a vyšší (včetně opravy 14)
- Na větvi bash-4.2:4.2.50 a vyšší (včetně opravy 50)
- Ve větvi bash-4.3:4.3.27 a vyšší (včetně opravy 27)
Pokud váš bash zobrazuje starší verzi, váš prodejce operačního systému ji možná sám opravil, takže je nejlepší to zkontrolovat.
Pokud:
env xx='() { echo vulnerable; }' bash -c xx
ukazuje „zranitelný“, stále jste zranitelní. To je jediný test, který je relevantní (zda je bash parser stále vystaven kódu v jakémkoli proměnná prostředí).
Podrobnosti.
Chyba byla v počáteční implementaci funkce export/import představené 5. srpna 1989 Brianem Foxem a poprvé vydané v bash-1.03 asi o měsíc později v době, kdy bash nebyl tak rozšířený, než bylo zabezpečení. že existuje velký problém a HTTP a web nebo Linux vůbec existovaly.
Z protokolu změn v 1.05:
Fri Sep 1 18:52:08 1989 Brian Fox (bfox at aurel) * readline.c: rl_insert (). Optimized for large amounts of typeahead. Insert all insertable characters at once. * I update this too irregularly. Released 1.03. [...] Sat Aug 5 08:32:05 1989 Brian Fox (bfox at aurel) * variables.c: make_var_array (), initialize_shell_variables () Added exporting of functions.
Některé diskuze v gnu.bash.bug a comp.unix.questions v té době také zmiňují tuto funkci.
Je snadné pochopit, jak se to tam dostalo.
bash exportuje funkce v env vars jako
foo=() {
code
}
A při importu vše, co musí udělat, je interpretovat to pomocí = nahrazeno mezerou... kromě toho, že by to nemělo slepě interpretovat.
V bash to také nefunguje (na rozdíl od Bourne shellu) mají skalární proměnné a funkce jiný jmenný prostor. Vlastně pokud máte
foo() { echo bar; }; export -f foo
export foo=bar
bash šťastně umístí obojí do prostředí (ano položky se stejným názvem proměnné), ale mnoho nástrojů (včetně mnoha shellů) je nebude šířit.
Někdo by také namítl, že bash by měl používat BASH_ předpona jmenného prostoru, protože to jsou proměnné env relevantní pouze od bash po bash. rc používá fn_ prefix pro podobnou funkci.
Lepším způsobem, jak to implementovat, by bylo vložit definici všech exportovaných proměnných do proměnné jako:
BASH_FUNCDEFS='f1() { echo foo;}
f2() { echo bar;}...'
To by ještě bylo potřeba dezinfikovat, ale přinejmenším to nemůže být zneužitelnější než $BASH_ENV nebo $SHELLOPTS …
Existuje oprava, která zabraňuje bash z interpretace čehokoli jiného než definice funkce tam (https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html), a to je ta, která byla použita ve všech bezpečnostních aktualizace z různých distribucí Linuxu.
Nicméně bash stále interpretuje kód v něm obsažený a jakákoliv chyba v interpretu by mohla být zneužita. Jedna taková chyba již byla nalezena (CVE-2014-7169), i když její dopad je mnohem menší. Takže brzy přijde další patch.
Dokud nebude opravena zpřísnění, která zabrání bashu interpretovat kód v jakékoli proměnné (například pomocí BASH_FUNCDEFS přístup výše), nebudeme vědět jistě, jestli nejsme zranitelní chybou v analyzátoru bash. A věřím, že dříve nebo později bude vydán takový opravný prostředek.
Upravit 28. 9. 2014
V analyzátoru byly nalezeny dvě další chyby (CVE-2014-718{6,7}) (všimněte si, že většina shellů musí mít ve svém analyzátoru chyby pro rohové případy, to by nevadilo, kdyby tento analyzátor neměl 'nebyl vystaven nedůvěryhodným datům).
Zatímco všechny 3 chyby 7169, 7186 a 7187 byly opraveny v následujících opravách, Red Hat tlačil na opravu zpevnění. Ve svém patchi změnili chování tak, že funkce byly exportovány v proměnných nazvaných BASH_FUNC_myfunc() víceméně předjímá Chetovo rozhodnutí o designu.
Chet později zveřejnil tuto opravu jako oficiální upstream bash patch.
Tato oprava nebo její varianty jsou nyní dostupné pro většinu hlavních distribucí Linuxu a nakonec se dostaly i na Apple OS/X.
To nyní odstraňuje obavy z jakéhokoli libovolného env var, který využívá analyzátor prostřednictvím tohoto vektoru, včetně dvou dalších zranitelností v analyzátoru (CVE-2014-627{7,8}), které později odhalil Michał Zalewski (CVE-2014-6278 je téměř stejně špatný jako CVE-2014-6271) naštěstí poté, co většina lidí měla čas nainstalovat opravný balíček
Chyby v analyzátoru budou také opraveny, ale již nepředstavují tak velký problém, protože analyzátor již není tak snadno vystaven nedůvěryhodnému vstupu.
Všimněte si, že i když byla chyba zabezpečení opravena, je pravděpodobné, že v této oblasti uvidíme nějaké změny. Počáteční oprava pro CVE-2014-6271 narušila zpětnou kompatibilitu tím, že přestala importovat funkce pomocí . nebo : nebo / jejich jménem. Ty však mohou být stále deklarovány bashem, což vede k nekonzistentnímu chování. Protože funkce s . a : v jejich jménech se běžně používají, je pravděpodobné, že oprava obnoví přijímání alespoň těch z prostředí.
Proč to nebylo nalezeno dříve?
To je také něco, co mě napadlo. Mohu nabídnout několik vysvětlení.
Za prvé si myslím, že kdyby bezpečnostní výzkumník (a já nejsem profesionální bezpečnostní výzkumník) konkrétně hledal zranitelnosti v bash, pravděpodobně by je našel.
Například, kdybych byl bezpečnostním výzkumníkem, mé přístupy by mohly být:
- Podívejte se, kde
bashzískává informace a co s nimi dělá. A prostředí je zřejmé. - Podívejte se, na kterých místech
bashje vyvolán interpret a na jakých datech. Opět by to vyniklo. - Import exportovaných funkcí je jednou z funkcí, která je zakázána při
bashje setuid/setgid, díky čemuž je ještě jasnější.
Mám podezření, že nikoho nenapadlo zvážit bash (tlumočník) jako hrozbu, nebo že hrozba mohla přijít tímto způsobem.
bash interpret není určen ke zpracování nedůvěryhodného vstupu.
Skripty prostředí (nikoli tlumočníka) jsou často pozorně sledovány z bezpečnostního hlediska. Syntaxe shellu je tak nešikovná a existuje tolik námitek ohledně psaní spolehlivých skriptů (když jsem mě nebo jiní zmiňovali operátor split+glob nebo proč byste například měli citovat proměnné?), že je docela běžné najít chyby zabezpečení ve skriptech, které zpracovávají nedůvěryhodná data.
To je důvod, proč často slýcháte, že byste neměli psát skripty CGI shell, nebo že skripty setuid jsou na většině Unices zakázány. Nebo že byste měli být zvláště opatrní při zpracování souborů v adresářích, do kterých lze zapisovat (viz například CVE-2011-0441).
Důraz je kladen na to, na skripty shellu, nikoli na interpret.
Interpret shellu můžete vystavit nedůvěryhodným datům (přivádění cizích dat jako kódu shellu k interpretaci) pomocí eval nebo . nebo to volat v souborech poskytnutých uživatelem, ale pak nepotřebujete chybu zabezpečení v bash zneužít to. Je zcela zřejmé, že pokud předáváte neupravená data pro interpretaci shellu, bude je interpretovat.
Shell je tedy volán v důvěryhodných kontextech. Jsou mu přiděleny pevné skripty k interpretaci a častěji (protože je tak obtížné napsat spolehlivé skripty) pevná data ke zpracování.
Například ve webovém kontextu může být shell vyvolán v něčem jako:
popen("sendmail -oi -t", "w");
Co se na tom může pokazit? Pokud se předpokládá něco špatného, jde o data přiváděná do tohoto sendmailu, nikoli o to, jak je analyzován samotný příkazový řádek shellu nebo jaká další data jsou do tohoto shellu přiváděna. Neexistuje žádný důvod, proč byste chtěli vzít v úvahu proměnné prostředí, které jsou předány tomuto shellu. A pokud to uděláte, uvědomíte si, že jsou to všechny proměnné env, jejichž název začíná „HTTP_“ nebo jsou to dobře známé proměnné prostředí CGI jako SERVER_PROTOCOL nebo QUERYSTRING s žádným z nich shell nebo sendmail nemají co do činění.
V kontextech zvýšení oprávnění, jako je při spuštění setuid/setgid nebo pomocí sudo, se prostředí obecně bere v úvahu a v minulosti se vyskytlo mnoho zranitelností, opět ne proti samotnému shellu, ale proti věcem, které zvyšují oprávnění jako sudo (viz například CVE-2011-3628).
Například bash nedůvěřuje prostředí, když je setuid nebo voláno příkazem setuid (předpokládejme mount například, která vyvolává pomocníky). Zejména ignoruje exportované funkce.
sudo čistí prostředí:ve výchozím nastavení vše kromě bílé listiny, a pokud není nakonfigurováno, alespoň černé listiny, o kterých je známo, že ovlivňují shell nebo jiný (jako PS4 , BASH_ENV , SHELLOPTS …). Také obsahuje černou listinu proměnných prostředí, jejichž obsah začíná () (což je důvod, proč CVE-2014-6271 neumožňuje eskalaci oprávnění prostřednictvím sudo ).
Ale znovu, to je pro kontexty, kde nelze prostředí věřit:jakoukoli proměnnou s libovolným názvem a hodnotou může v tomto kontextu nastavit uživatel se zlými úmysly. To neplatí pro webové servery/ssh nebo všechny vektory, které využívají CVE-2014-6271, kde je prostředí řízeno (minimálně je řízen název proměnných prostředí…)
Je důležité zablokovat proměnnou jako echo="() { evil; }" , ale ne HTTP_FOO="() { evil; }" , protože HTTP_FOO nebude volán jako příkaz žádným skriptem shellu nebo příkazovým řádkem. Apache2 nikdy nenastaví echo nebo BASH_ENV proměnná.
Je to zcela zřejmé některé proměnné prostředí by měly být v některých kontextech na černé listině na základě jejich jména , ale nikoho nenapadlo, že by měli být na černé listině na základě jejich obsahu (kromě sudo ). Nebo jinými slovy, nikoho nenapadlo, že libovolné proměny env by mohly být vektorem pro vkládání kódu.
Pokud jde o to, zda by to mohlo zachytit rozsáhlé testování, když byla tato funkce přidána, řekl bych, že je to nepravděpodobné.
Když testujete funkci , otestujete funkčnost. Funkčnost funguje dobře. Pokud exportujete funkci v jednom bash vyvolání, je importováno v pořádku do jiného. Velmi důkladné testování mohlo odhalit problémy, když se exportuje proměnná i funkce se stejným názvem nebo když je funkce importována v jiném národním prostředí, než do kterého byla exportována.
Abychom však mohli zranitelnost odhalit, není to test funkčnosti, který byste museli provést. Hlavní pozornost by musela být věnována bezpečnostnímu aspektu a netestovali byste funkčnost, ale mechanismus a způsob jeho zneužití.
Není to něco, co vývojáři (zejména v roce 1989) často nemají na mysli a vývojář shellu by mohl být omluven, že si myslí, že jeho software je nepravděpodobné, že by byl síťově zneužitelný.