Przy okazji pojawienia się ponownie informacji o tym że Google Chrome ściąga pliki bez pytania na bugtraq wznowiła się dyskusja o tym czy jest to bug, feature, czy może vuln (luka w bezpieczeństwie).

Przede wszystkim należy zauważyć że panowie z Google uznają to za domyślnie włączony feature, który można bardzo łatwo wyłączyć wchodząc w opcję i zaznaczając checkbox przy 'Pytaj przed pobraniem...'. Czy można nazwać więc bugiem coś co zostało przewidziane i można to wyłączyć? Raczej nie.

Czy można to nazwać vulnem? James C. Slora Jr. na bugtraq twierdzi że tak, i ma nawet sensowne argumenty. Podsumowując to co napisał: automatyczne ściąganie plików na dysk nie jest może atakiem samym w sobie, ale tworzy pewien wektor ataku który umożliwia zaistnienie innym atakom. Jako przykłady podaje choćby plik desktop.ini (chociaż afaic dużo z nim zrobić nie można), pliki skanowane przez antywirusy (o vulnach w antywirach słyszy się stosunkowo często), czy inne pliki które powodują jakąś akcję (jako przykład często podawany był vuln z code exec w animowanych kursorach rezydujących w plikach .ani).

Dorzucę i swoje 3 grosze do tego. Czy pamiętacie technikę zwaną DLL spoofingiem? W skrócie, stanowcza większość plików wykonywalnych importuje jakieś zewnętrzne biblioteki DLL. To gdzie loader PE będzie szukał danej DLLki zależy od tego czy DLLka znajduje się na liście znanych (systemowych) DLLek. Jeżeli DLL znajduje się na tej liście, to loader zacznie poszukiwania od katalogu System32/SysWOW64. A jeżeli jej tam nie ma, to loader poszuka jej w katalogu uruchamianego pliku wykonywalnego. Przykładowa lista systemowych DLLek z systemu Microsoft Windows Vista SP1 zawiera następujące DLLki:

clbcatq.dll
ole32.dll
advapi32.dll
COMDLG32.dll
gdi32.dll
IERTUTIL.dll
IMAGEHLP.dll
IMM32.dll
kernel32.dll
LPK.dll
MSCTF.dll
MSVCRT.dll
NORMALIZ.dll
NSI.dll
OLEAUT32.dll
rpcrt4.dll
Setupapi.dll
SHELL32.dll
SHLWAPI.dll
URLMON.dll
user32.dll
USP10.dll
WININET.dll
WLDAP32.dll
WS2_32.dll

Dodam że w XP była tam defaultowo jeszcze VERSION.DLL, ale na Vista jej tam nie uświadczymy. Dodam że wszystkie DLLki które są importowane przez w/w biblioteki również są uznawane za DLLki systemowe.
OK. A teraz załóżmy że user wchodzi Chrome na jakąś stronę, i bez żadnego potwierdzenia ściąga się mu VERSION.DLL, WS2_32.DLL i WSOCK32.DLL, wszystkie oczywiście są zdecydowanie szkodliwe.
User zapomina o tym / nie zwraca uwagi i serfuje dalej. Za dzień, może dwa, user ściąga sobie instalkę np. najnowszego Blendera, i zaczyna instalować.
No i tu następuje uruchomienie zaplanowanej pułapki - instalka Blendera importuje VERSION.DLL, które na Viście nie jest systemowe, więc zostaje uruchomione wcześniej podłożone VERSION.DLL. Co się dalej dzieje to aż strach pisać ;>

Dodam że instalka Blendera w żadnym wypadku nie jest wyjątkiem. Sprawdziłem tylko kilka instalek które leżały u mnie w katalogu ze ściągniętymi plikami, i połowa z nich miała w importach jakąś niesystemową DLLkę. Jako przykład mogę podać np. instalkę Open Office (wersja UX) czy Pluginu WGA (plugin do weryfikacji autentyczności Windowsa do FF by Microsoft).

Wymieniłem również pliki WS2_32.DLL i WSOCK32.DLL. Załóżmy że user ściągnie nie tyle instalkę, co program gotowy do uruchomienia - np. pewien bardzo popularny klient SSH - putty. Ów klient importuje oczywiście jedną z wymienionych DLLek, i dochodzi o analogicznego uruchomienia złośliwego kodu.

Podsumowując: moim zdaniem feature stanowi pewne niebezpośrednie zagrożenie, i defaultowo powinien być raczej wyłączony, lub, powinna być możliwość podawania typów plików które mają być weryfikowane (DLL, EXE).

PS. Na milw0rm pojawił się kolejny exploit na Chrome, tym razem również wymagający interakcji remote DoS związany z (prawdopodobnie) buffer overflow w Inspect Element (czyżby drugi bug w Inspect Element? o jednym takim już pisałem).