Ponieważ ten błąd dotyczy tak wielu platform, możemy dowiedzieć się czegoś z procesu, w którym wykryto tę lukę: czy był to moment εὕρηκα (eureka) czy wynik kontroli bezpieczeństwa?
Ponieważ wiemy, że Stéphane znalazł błąd Shellshock, a inni mogą również znać ten proces, bylibyśmy zainteresowani historią, w jaki sposób znalazł błąd.
bash
shellshock
bugs
vulnerability
Faheem Mitha
źródło
źródło
Odpowiedzi:
Aby uspokoić kilka osób, nie znalazłem błędu przez obserwowanie exploitów, nie mam powodu sądzić, że został on wykorzystany przed ujawnieniem (choć oczywiście nie mogę tego wykluczyć). Nie znalazłem go również patrząc na
bash
kod.Nie mogę powiedzieć, że pamiętam dokładnie wtedy mój ciąg myśli.
To mniej więcej pochodzi z refleksji nad niektórymi zachowaniami niektórych programów, które uważam za niebezpieczne (zachowania, a nie oprogramowanie). Takie zachowanie, które sprawia, że myślisz: to nie brzmi jak dobry pomysł .
W tym przypadku zastanawiałem się nad wspólną konfiguracją ssh, która umożliwia przekazywanie zmiennych środowiskowych niezaangażowanych od klienta, pod warunkiem, że ich nazwa zaczyna się od
LC_
. Chodzi o to, aby ludzie mogli nadal używać własnego języka podczasssh
wchodzenia na inne maszyny. Dobry pomysł, dopóki nie zaczniesz zastanawiać się, jak skomplikowana jest obsługa lokalizacji, zwłaszcza gdy UTF-8 jest wprowadzany do równania (i widzisz, jak źle jest obsługiwany przez wiele aplikacji).Już w lipcu 2014 roku, miałem już zgłoszone luki w glibc postępowania lokalizacyjnego, które w połączeniu z tej
sshd
konfiguracji, a dwóch innych niebezpiecznych zachowań nabash
powłoce dozwolone (uwierzytelnione) atakujący włamać się do serwerów git pod warunkiem, że były one w stanie przesyłać pliki tam ibash
był używany jako powłoka logowania użytkownika git unix (CVE-2014-0475).Pomyślałem, że to prawdopodobnie zły pomysł, aby użyć go
bash
jako powłoki logowania użytkowników oferujących usługi za pośrednictwem ssh, biorąc pod uwagę, że jest to dość złożona powłoka (gdy wszystko, czego potrzebujesz, to tylko parsowanie bardzo prostej linii poleceń) i odziedziczył większość błędnych projektów ksh. Ponieważ już zidentyfikowałem kilka problemów zbash
używaniem w tym kontekście (do interpretacji sshForceCommand
), zastanawiałem się, czy może być ich więcej.AcceptEnv LC_*
pozwala każdej zmiennej, której nazwa zaczyna się od,LC_
a ja miałem niejasne wspomnienie, żebash
eksportowane funkcje ( niebezpieczna, choć przydatna w danym momencie funkcja) korzystały ze zmiennych środowiskowych, których nazwa była podobnamyfunction()
i zastanawiała się, czy nie było tam czegoś ciekawego do obejrzenia.Już miałem odrzucić to na tej podstawie, że najgorsze, co można zrobić, to przedefiniować wywołaną komendę,
LC_something
co tak naprawdę nie może stanowić problemu, ponieważ nie są to nazwy komend, ale zacząłem się zastanawiać, jakbash
zaimportowano te zmienne środowiskowe.Co jeśli zmienne zostałyby wywołane
LC_foo;echo test; f()
na przykład? Postanowiłem więc przyjrzeć się bliżej.ZA:
ujawniłem, że moje wspomnienie było błędne, ponieważ zmienne nie zostały wywołane,
myfunction()
alemyfunction
(i to wartość zaczyna się od()
).I szybki test:
potwierdziło moje podejrzenie, że nazwa zmiennej nie została zdezynfekowana, a kod został oceniony podczas uruchamiania .
Gorzej, znacznie gorzej, wartość nie została również zdezynfekowana:
Oznaczało to, że każda zmienna środowiskowa może być wektorem.
Wtedy zdałem sobie sprawę z zakresu problemu, potwierdziłem, że można go wykorzystać również przez HTTP (
HTTP_xxx
/QUERYSTRING
... env vars), inne takie jak usługi przetwarzania poczty, później DHCP (i prawdopodobnie długą listę) i zgłosiłem (ostrożnie) .źródło