Bash specially-crafted environment variables code injection attack

[Dan Lukes]

Zbyněk Burget wrote:
> Porad v tom nemam nejak jasno s tim apachem...
> je to tedy tak, ze je to opravdu problem JEN bashe? Tzn. Kdyz na stroji
> bash nemam, tak jsem v pohode nebo je nebezpeci i tehdy, pokud sice bash
> na stroji neni, ale apache pouziva CGI skripty v napr. perlu?

Pokud je znamo, problem nastava pri spusteni bashe pri importu sikovne
zmanipulovaneho environmentu.

Problem tedy mas pokazdy, pokud neduveryhodna osoba dokaze manipulovat
environmentem a spustit bash.

To prvni u CGI nastat muze, tam se do environmentu vkladaji data z HTTP
dotazu. Takze musis posoudit nakolik u tebe muze nastat to druhe.

To vely "halo" okolo toho je pravdepodobne zpusobene jen tim, ze Linux,
kterej je preci jen nejzastoupenejsi OS teto kategorie, nema vlstni 'sh'
a aby se to nepoznalo, tak misto nej pouziva prejmenovany bash.

Tam tedy problem nastava i pri pouziti "zakladniho shellu".

Na FreeBSD me cely ten problem nechava relativne klidnym, protoze bash
sice pouzivam jako osobni interaktivni shell, ale pokud pisu shellovske
scripty (a ty ja celkem rad) tak zasadne pro 'sh'. V souvislost se
zpracovanim "externich dat" se tedy u me bash nepouziva a tudiz by tu
prostor pro utok byt nemel.

Jina vec by byla, pokud bych si sednul k cizimu prihlasenemu terminalu a
napsal 'su' - to by se bash spustil do jeho environmentu se vsemi
riziky, ktere se s tim poji. Ale to ja stejne neudelam, protoze v tomhle
scenari ma pripadny utocnik daleko snazsi a ucinnejsi cesty jak ziskat
heslo, ktere do toho 'su' napisu ...


Dan