Jak działa zaktualizowany test podatności Shellshock dla CVE-2014-7169?

Rozumiem oryginalny test dla CVE-2014-6271, który brzmiał:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Ale jestem zdezorientowany zaktualizowanym testem i odpowiednimi danymi wyjściowymi dla CVE-2014-7169:

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BST

Czy ktoś mógłby krótko wyjaśnić, co się tutaj dzieje i jak omija łatkę do CVE-2014-6271?

Od czasu, gdy po raz pierwszy opublikowałem to pytanie, krążyłem po Internecie.

Według pierwotnego odkrywcy błędu, bash przed łatką CVE-2014-6271 zaimportował funkcję taką jak:

foo=() {
  code
}

zastępując znak równości spacją i interpretując go ... co oznaczało, że możliwa jest interpretacja poza definicją funkcji.

Łatka dla CVE-2014-6271 wprowadzono specjalny tryb funkcji parse_and_execute () do oceny granicznej do definicji funkcji, a nie poza nią.

Jednak, jak wyjaśniono w tym wątku , specjalnie spreparowana zmienna środowiskowa testu podatności CVE-2014-7169 ma na celu 1) pomieszanie analizatora składni ze śmiercią 2) pozostawienie skrawków w buforze 3) całkowitą zmianę tego, co robi oryginalne polecenie bash, gdy łączy się ze skrawkami znajdującymi się już w buforze.

Aby przeanalizować zmienną środowiskową:

X='() { (a)=>\'

• Analizator składni przeanalizuje () { (a)=>\. Zauważ, że \jest częścią ciągu; to jest nie uciekając z tyłu jeden cytat.

() {

• Analizator składni identyfikuje to jako definicję funkcji.

(a)=

• To dezorientuje parser do śmierci.

>\

• Analizator składni pozostawia ostatnie dwa znaki siedzące w buforze.

>\[NEWLINE]

• W pewnym momencie przed uruchomieniem shpolecenia nowa linia jest umieszczana w buforze.

>\[NEWLINE]echo date

• Kiedy shjest wywoływany (co w tym przypadku jest prawdopodobnie dowiązaniem symbolicznym), dodaje argumenty polecenia echo datedo znaków już istniejących w buforze.

>echo date

• Ponieważ znak nowej linii jest zastępowany, bash przeanalizuje bufor jako >echo date, co ma taki sam efekt jak date > echo. Plik o nazwie echojest tworzony, a standardowe wyjście datepolecenia jest przekierowywane do niego.

; cat echo

• Drugie polecenie wyświetla po prostu zawartość nowo utworzonego pliku.

Nie zapewnia ładnego, czystego wyniku, ale pokazuje błąd.

Bez błędu zmienna środowiskowa Xpowinna zostać zignorowana, bash powinien zostać uruchomiony echo date, a cat powinien narzekać, że nie ma pliku o nazwie echo. Np. Zastanów się, jak zachowuje się myślnik:

me@myserver$ rm -f echo && env -i  X='() { (a)=>\' dash -c 'echo date'; cat echo
date
cat: echo: No such file or directory

Nie powtórzę danych wyjściowych wyświetlanych w pytaniu i nie będę udawać, że rozumiem, jak to działa, ale bash działa datei umieszcza dane wyjściowe w pliku o nazwie „echo”. Możesz grać z alternatywami, aby dateprzekonać się, że jest to użyteczne i niebezpieczne.