Prawdziwa historia z moich pierwszych dni w Microsoft.
Nie zaznałeś strachu do dnia, w którym obudziłeś się i zobaczyłeś nagłówek na ZDNet.com tego ranka: „ Najgorsza dziura w zabezpieczeniach przeglądarki Internet Explorer, jaką kiedykolwiek odkryto w„ Blah ” ”, gdzie „Blah” to kod, który sam napisałeś sześć miesięcy wcześniej .
Natychmiast po rozpoczęciu pracy sprawdziłem dzienniki zmian i odkryłem, że ktoś z innego zespołu - ktoś, któremu ufamy, że wprowadzi zmiany w produkcie - sprawdził mój kod, zmienił kilka ustawień klucza rejestru bezpieczeństwa bez wyraźnego powodu, sprawdziłem go ponownie i nigdy nie dostałem recenzji kodu ani nikomu o tym nie powiedziałem. Do dziś nie mam pojęcia, co, u licha, robił; wkrótce potem opuścił firmę. (Z własnej woli.)
(AKTUALIZACJA: Kilka odpowiedzi na problemy poruszone w komentarzach:
Po pierwsze, zauważ, że wybieram charytatywne stanowisko, że zmiany klucza bezpieczeństwa były niezamierzone i oparte na nieostrożności lub nieznajomości, a nie na złośliwości. Nie mam dowodów w ten czy inny sposób i wierzę, że mądrze jest przypisywać błędy ludzkiej omylności.
Po drugie, nasze systemy odpraw są teraz znacznie, znacznie silniejsze niż 12 lat temu. Na przykład nie jest teraz możliwe wpisanie kodu bez wysłania przez system kontroli wiadomości e-mail z listą zmian do zainteresowanych stron. W szczególności zmiany wprowadzone późno w cyklu statku obejmują wiele „procesów”, które zapewniają, że wprowadzane są odpowiednie zmiany w celu zapewnienia stabilności i bezpieczeństwa produktu.)
W każdym razie błąd polegał na tym, że obiekt, który NIE był bezpieczny do użycia z Internet Explorera, został przypadkowo zwolniony jako oznaczony jako „bezpieczny dla skryptów”. Obiekt mógł zapisywać pliki binarne - w rzeczywistości biblioteki typu OLE Automation - w dowolne miejsca na dysku. Oznaczało to, że osoba atakująca może stworzyć bibliotekę typów zawierającą pewne ciągi wrogiego kodu, zapisać ją na ścieżce, która była znaną lokalizacją wykonywalną, nadać jej rozszerzenie czegoś, co spowodowałoby uruchomienie skryptu, i mieć nadzieję, że w jakiś sposób użytkownik przypadkowo uruchomiłby kod. Nie znam żadnych udanych ataków w „świecie rzeczywistym”, które wykorzystałyby tę lukę, ale możliwe było stworzenie z niej działającego exploita.
Szybko dostarczyliśmy łatkę całkiem cholernie dla tego, powiem ci.
Zrobiłem, a następnie naprawiłem wiele innych luk w zabezpieczeniach w JScript, ale żadna z nich nigdy nie zbliżyła się tak bardzo do reklamy.