20:26
11/1/2011

Windows i ochrona stosu w driverach

Autorem poniższego tekstu jest Mateusz “j00ru” Jurczyk oraz Gynvael Coldwind.
W opublikowanym na Niebezpieczniku pod koniec listopada wpisie Exploit 0day na windows – omija UAC autor napisał, że luka ta jest exploitowalna m.in. na Windowsie XP, co spotkało się z protestami niektórych czytelników, którzy zarzucali autorowi wpisu wprowadzanie w błąd. Kwestia ta była o tyle dyskusyjna, że podatna funkcja w systemie Windows XP posiadała dodatkowe zabezpieczenia — nieobecne w wersjach z Visty oraz 7 — w postaci tzw. security cookies (znane również jako stack canaries), które wg. ówczesnego stanu wiedzy zapewniało wystarczającą ochronę przed możliwością wykonania wrogiego kodu, przy użyciu błędu przepełnienia bufora na stosie.

W opublikowanym przez nas blisko 40-stronicowym artykule pt. “Exploiting the otherwise non-exploitable – Windows Kernel-mode GS Cookies subverted” udowadniamy, że ciasteczka w domyślnych sterownikach systemu Windows są bardzo słabe, a co za tym idzie, omawiany błąd jest jak najbardziej exploitowalny na Windows XP. Udane podniesienie uprawnień użytkownika systemu Windows XP SP3 przy użyciu wspomnianej luki bezpieczeństwa zostało przedstawione na poniższym nagraniu.

Słabe źródła entropii

Poziom bezpieczeństwa zapewnianego przez wspomniane wcześniej ciasteczka w dużej mierze zależy od doboru odpowiednio dobrych źródeł entropii podczas jego inicjalizacji – im bardziej losowe i nieprzewidywalne źródło, tym bezpieczniejsze ciastko oraz odwrotnie – im bardziej przewidywalne źródła entropii, tym szacowanie prawidłowej wartości ciastka staje się łatwiejsze.

Security cookies?
Jak zapewne większość czytelników Niebezpiecznika wie, ciasteczko bezpieczeństwa umieszczane na stosie to pewna losowa (tj. trudna do przewidzenia przez atakującego) wartość oddzielająca zmienne lokalne funkcji od adresu powrotu. Bezpośrednio przed opuszczeniem funkcji następuje weryfikacja poprawności wartości ciasteczka. Jeśli owa wartość okazuje się być zmodyfikowana w trakcie wykonywania chronionej funkcji, dalsze działanie kodu (programu, systemu) zostaje awaryjnie wstrzymane. W przypadku trybu jądra, rezultatem jest dobrze znany Blue Screen of Death.

W przypadku domyślnego sterownika win32k.sys (winowajcy we wspomnianym “błędzie z UAC”) globalna wartość cookie jest generowana przy wykorzystaniu dwóch lub trzech źródeł entropii, w zależności od wersji Windowsa:

  1. adresu wirtualnego (VA) zmiennej globalnej win32k!__security_cookie (w której przechowywana jest wzorcowa wartość ciasteczka),
  2. aktualnego adresu ramki stosu w momencie wejścia do funkcji (tylko w Vista/7/2008),
  3. aktualnego czasu, mierzonego w tickach (w tym przypadku 1 tick = ~1/64 sekundy) od startu systemu.

W praktyce, ustalenie adresu zmiennej __security_cookie dla konkretnego modułu jest trywialne i sprowadza się do znalezienia relatywnego adresu __security_cookie, korzystając z pliku win32k.sys na atakowanej maszynie, odpytania systemu pod jakim adresem win32k.sys znajduje się w pamięci (można skorzystać z funkcji NtQuerySystemInformation) oraz połączeniu tych informacji – przekształceniu adresu relatywnego zmiennej (RVA) na adres bezwzględny (VA).

Analogicznie sprawa przedstawia się w przypadku ramki stosu – stały offset od początku stosu można wyliczyć np. posługując się dead-listingiem disassemblera lub WinDbg na innej maszynie z takim samym systemem (co do zestawu patchy). Natomiast adres początku stosu trybu jądra dla danego wątku dostarcza nam system, a konkretniej natywna funkcja API NtQuerySystemInformation z parametrem SystemExtendedProcessInformation.

Pozostaje więc problem ilości ticków od momentu startu systemu i tutaj sprawa się komplikuje – system nie udziela precyzyjnych informacji dotyczących czasu załadowania drivera. Istnieje jednak kilka sposobów pozwalających oszacować tę wartość z bardzo dużą dokładnością. Główna koncepcja opiera się na odpytywaniu jądra Windows o dokładny czas szczególnych zdarzeń – pośrednio lub bezpośrednio związanych z ładowaniem sterownika – takich jak czas utworzenia procesu powodującego załadowanie drivera, bądź czas utworzenia linku symbolicznego do danego urządzenia.

GS cookie bits

Poziom przewidywalności poszczególnych bitów ciasteczka, przy użyciu techniki Symlink-relative loading time.

Po złożeniu trzech odrębnych informacji w spójną całość, otrzymujemy oczekiwaną (poprawną) wartość ciastka, lub – w gorszym przypadku – jej przybliżenie. Dzięki temu, możliwe staje się ominięcie (bądź też oszukanie) zabezpieczenia w trakcie wykorzystywania błędu przepełnienia stosu i skierowanie ścieżki wykonywania kodu pod specjalnie spreparowany adres powrotu.

(Po szczegóły wraz z wynikami testów empirycznych zapraszamy do artykułu.)

Dalszy los GS Cookies

We wspomnianej publikacji znajduje się kilka propozycji, dotyczących możliwości przewidywania ciasteczka w zależności od czynników niezależnych od atakującego (takich jak rodzaj sterownika, w którym znajduje się błąd). W niektórych przypadkach całkowita entropia GS cookies została zredukowana do jednego bitu (skuteczność ataku oscyluje na poziomie 50%), w innych – do kilku (maksymalnie 6) bitów.
Należy jednak zauważyć, że dokument w żaden sposób nie porusza tematyki zabezpieczenia stosu w samym obrazie jądra Windows (a więc ntoskrnl.exe i pochodne), gdzie ciasteczko generowane jest w inny sposób.

Kontakt z Microsoftem

O wyniku naszych badań poinformowaliśmy Microsoft (6 grudnia 2010), który potwierdził otrzymanie informacji i dwa dni później przesłał odpowiedź z której wynika, że zespół systemu Windows jest świadomy problemu i rozważa zmianę metody generowania ciasteczka w przyszłych wersjach systemu. Firma Microsoft nie zwróciła się z prośbą o opóźnienie terminu publikacji artykułu.

Przeczytaj także:



26 komentarzy

Dodaj komentarz
  1. “rozważa zmianę metody generowania ciasteczka w przyszłych wersjach systemu.”
    No cóż, łatki nie wydadzą na aktualne systemy tylko będą zarabiać na nowszych :<

  2. “No cóż, łatki nie wydadzą na aktualne systemy tylko będą zarabiać na nowszych :<"

    Cały MS. W dupie ma tych co już są na ich łasce ;x

  3. Albo moglo by to zagrozic zgodnosci oprogramowania z systemem. Windows != linux, tutaj wszystko musi byc zgodne.

  4. @Kenobi @rambo dżon,

    Przyszła wersja Windows != Windows 8, to również SP (takie śmieszne numerki oznaczające kolejną kompilację się zmnienią co się pokazują jak nie aktywujesz windowz – to jest oznaczenie *wersji*).

    Fajnie MS ma mnie w dupie, ale i tak kupie kolejnego Windowsa, kupi go tez kilka milionów innych userów. Na ch*j piszesz takie pierdoły, nie moge tego już kur*a czytać. Jestescie jak dzieci, spier*alać na onet, pclab albo pudelka.

  5. Respect dla Niebezpiecznika, powracamy do publikacji bardziej mocnych artykulów :) czekam na więcej. A dla ekipy badaczy, thumbs up!

  6. Polecam również zerknąć na poniższy link

    http://blogs.technet.com/b/srd/archive/2009/03/16/gs-cookie-protection-effectiveness-and-limitations.aspx

  7. plan9 masz trochę racji ale nie całkiem M$ powinien wypuszczać przynajmniej poprawki bezpieczeństwa dopóki XP będzie popularny, fakt są nowsze systemy ale za nie trzeba zapłacić i to nie mało. A jeżeli Gates wydał ‘bubel’ to niech go teraz naprawi przecież ludzie za niego zapłacili i co teraz mają kupować kolejny, bo tamten okazuje się niedopracowany !?

  8. Gratulacje dla autorów badania! Przy okazji mam dodatkowe pytania.

    Pierwsze pytanie – czy ten atak może być stosowany zdalnie, czy jego obszar stosowania ogranicza się do ataku lokalnego (np. podniesienie uprawnień). Jak rozumiem (przyznam się, że nie miałem jeszcze czasu dokładnie przeczytać całości opracowania) możliwe jest zebranie informacji, które pozwalają z dużym prawdopodobieństwem określić wartość kanarka. Ale by te informacje zebrać, trzeba mieć możliwość uruchomienia kodu na atakowanej maszynie, dobrze rozumiem?

    Drugie pytanie – GS jest cechą kompilatora. Czy wartość (sposób generowania) cookie GS jest zależna od kompilatora, czy od systemu operacyjnego? Jak powinno (ewentualnie) wyglądać poprawienie tego błędu – modyfikacja funkcji systemu, czy modyfikacja kompilatora i przekompilowanie sterownika?

  9. @Paweł Goleń
    Thx thx ;)

    Ad pytanie 1.
    Nasze techniki były głównie nastawione na ataki lokalne (typu priv. escal.).
    Natomiast (patrz sekcja 3.3.4. Other techniques, strona 24), tick count (czyli jedno z dwóch/trzech źródeł entropii) można określić z 5% skutecznością nie mając dostępu do maszyny, ale znając jej specyfikację (sprzęt, wersja windowsa, zestaw patchy… czym więcej wiemy tym lepiej).
    Oraz podejrzewamy (patrz sekcja 6. Future work, strona 33), że niektóre bardziej precyzyjne (przy ataku zdalnym) informacje możnaby uzyskać sniffując niektóre rodzaje pakietów sieciowych wysyłanych przez system.
    Natomiast jest to tylko koncepcja, której nie weryfikowaliśmy.
    Podsumowując (patrz sekcja 8. Conclusion, strona 35), ponieważ nasze techniki opierają się o system calle które zdradzają za dużo informacji, a których nie można wywołać zdalnie, są nie do zastosowaniach przy atakach zdalnych.

    Ad pytanie 2 (część pierwsza).
    Ponieważ nasze badania skupiły się na defaultowych driverach dołączanych do Windows (głównie win32k.sys oraz wanarp.sys) posługujemy się wersjami Windowsa zamiast wersjami DDK/WDK (patrz sekcja 1. Introduction, strona 2ga, 4rty akapit od góry).
    Natomiast, wszystko co jest zawarte w papierku można spokojnie przetłumaczyć na odpowiednie wersje DDK/WDK (a więc i wersje kompilatora).
    Również, sprawdzaliśmy nasze obserwacje/wnioski w driverze skompilowanym korzystając z najnowszego WDK i możemy stwierdzić, że obserwacje/wnioski są poprawne i dotyczą również najnowszego WDK.
    Anyway, custom-drivery (np. te które dostajemy od firm produkujących sprzęt) będą miały oczywiście stack cookie generowane metodą związaną z DDK/WDK na którym zostały skompilowane, a nie z Windowsem na którym działają.

    Ad pytanie 2 (część druga)
    Poprawienie błędu, moim zdaniem, mogłoby polegać na przekompilowaniu driverów korzystając z nowszego kompilatora. Ale, tu pojawia się problem, który znają osoby mające do czynienia z dużymi build environment – zmiana wersji kompilatora powoduje, że pewne fragmenty kodu przestają działać, inne rzucają warningi których nie było, a jeszcze inne errory. Więc zmiana wersji kompilatora to duża sprawa i prawdę mówiąc nie dziwię się Microsoftowi, że zwleka z poprawą tego w ten sposób.
    Innym sposobem byłby “zhaczenie” /GS cookies w ich obecnym build env i zmiana metoda generowania ciasteczka. Natomiast hmm, nie jestem pewien czy to by nie wprowadziło dodatkowych problemów.

    (z ciekawostek, zachęcam do rzucenia okiem na ostatni akapit na 2giej stronie ;>)

    Jeśli pominąłem jakieś pytanie, daj znać :)

  10. czy tylko u mnie nie ma czegos takiego jak whoami ?

  11. @patryk
    Nie ma whoami.exe pod Windows XP by default, ale nie ma problemu żeby je zainstalować. Dostępne jest np. w Resource Kit lub Service Pack Support Tools wydanym przez Microsoft.
    (patrz http://en.wikipedia.org/wiki/Resource_Kit linki na dole strony)

  12. @ShutDown Windows XP został wydany jeśli dobrze pamiętam w 2001 roku (*dzisięć* lat tamu, w “świecie” IT to eony). To że da się go w ogóle zainstalować na względnie współczesnych komputerach zakrawa o cud, niemniej używanie go do dziś jest chyba jakąś formą masochizmu.

    Kupując auto liczysz na to że przez 10 lat producent będzie na własny koszt eliminował każdą usterkę? A samochody są kilkaset razy droższe od Windows…

    Masz dajmy na to P3 Coppermine 733MHz, 10 lat temu kupiłeś go za dwie i pół wypłaty, czy to daje Ci prawo narzekanie na brak SSE4 albo VT??
    ————–
    “A jeżeli Gates wydał ‘bubel’ to niech go teraz naprawi”
    1) To nie Gates tylko Microsoft, William niema teraz nic do gadania (prawie)
    2) Błąd logiki: Jeśli windows to ‘bubel’ (od siebie dodam że przeterminowany) to po jaką cholerę go używasz skoro są darmowe alternatywy?

  13. Plan9 – “im nowsze tym lepsze” to jest dewiza dziecka, a nie osoby dojrzalej. Ten “masochizm” jest na moje oko w 80-90% duzych przedsiebiorstw, gdzie nowo kupowane komputery sa downgradowane do XP Pro wlasnie. Ale pewnie ich dzialy IT sie nie znaja – to lamusy i masochisci, bo przeciez “im nowsze tym lepsze”.

  14. Straszny offtopic, bardzo przeprasza, że tak to ciągnę.
    @Ja, Twoje oko troszeczkę rozmija się ze statystykami.

    Mniej wiecej 1,5 roku temu realizowałem spore zlecenie na dostarczenie komputerów dla jednej ze spółek Allcerol Mittal, były to komputery (znanej hurtowni na A, z win7 kosztowaly około 1500pln netto/szt) oparte o 4 (cztero) rdzeniowe procesory AMD, 4GB ram i karty graficzne DX10. Oczywiście (wg. twojej torii) ci podli lamerzy z ich działu IT nie zdowngradowali ich do jądro-z-minionego-tysiąclecie-windowz-xp tylko zostawili preinstalowany o-zgrozo-windows-7.

    Gdyby byli prawdziwymi haxorami olali by ten zbędny GB ramu, 2 rdzenie CPU, CUDA, jakoś zintegrowali offica 97 z SharePoint 2010, podobnie jak usługi terminalowe… Rozpędziłem się idąc Twoim tokiem serwery 99% firm stoją zapewne na NT 4.0 Serwer aaalbo na Xenixie. Co za wygodnickie ku*wy.

    Od tamtej pory nie sprzedałem (jakilkolwiek firmie) komputera w pełni “zgodnego” z Windows XP. To, że XP dalej jest tak popularny świadczy źle o wielu sprawach ale NIE o MS.

    Do sedna: “im nowsze tym lepsze” – niekoniecznie, ale “zajebiście przestażałe = złe” jest już prawdą.

    PS.
    W zasadzie po co nam te wszytkie nowe technologie… Strony na ramkach też były niezłe, a Voodoo 2 starczał aż nad to by pociupać w unrila. Po kiego mi Chmury, Wirtualizacja i inne obcobrzmiące terminy.

  15. @Gynvael : Dzięki za odpowiedzi. Pytanie trochę z innego tematu – czy w pewnym stopniu implementacja kanarków z Windows XP i Windows 2003 z zerami nie jest lepsza od późniejszej z XOR? Przynajmniej w odniesieniu do błędach w operacjach na stringach?

    A ta “ciekawostka” rzeczywiście fajna. Ciekawe z czego to wynika. Może kiedyś tajemnica zostanie rozwikłana, tak jak ta: My, what strange NOPs you have! (http://blogs.msdn.com/b/oldnewthing/archive/2011/01/12/10114521.aspx)

  16. @plan9: wyobraź sobie, że są organizacje, dla których informatyka jest narzędziem, a nie celem samym w sobie. Takie organizacje mają różne takie dziwne pomysły, jakieś standardy korporacyjne, standaryzację sprzętu, oprogramowania, konfiguracji systemu. I jakoś im się nie chce przerabiać tego wraz z premierą każdego nowego systemu. Siedzą grzecznie przy Windows XP i nawet im przez myśl nie przejdzie, by migrować (choćby częściowo) do czegoś nowszego. Bo to jest dla nich ekonomicznie nieuzasadnione.

    I tak, wyobraź sobie, że wciąż sporadycznie są wykorzystywane Windows NT 4.0. Wiele domen jest opartych o Windows 2000, a nawet jak DC są zmigrowane do Windows 2003, to functional level jest dalej zostawiony na poziomie 2000. Po prostu te starsze rozwiązania są wystarczająco dobre.

  17. @Paweł Goleń
    Ad XOR z RSP/EBP, no cóż, jak wykazaliśmy, w lokalnym ataku czy jest, czy go niema, to w zasadzie bez różnicy.
    Ad zera – osobiście podoba mi się pomysł podoba (patrz ostatni akapit sekcji 5tej, strona 33). Warto zauważyć, że w 64-bitowych Windowsach te zera są uwzględnione (cookie ma 48 z 64 bitów, pozowałe 16 bitów to zera).
    Natomiast w kernel mode raczej operuje się na UNICODE_STRING, czyli length+text, a nie ASCIIZ/WideChar-Zero Terminated. Czyli to że jakiś tam wcscpy w kernel mode się w ogóle znalazł, to ciekawostka sama w sobie ;>
    Ale fakt faktem, może lepiej dmuchać na zimne i dodać te zera. Zresztą 48-bitów dobrej entropii to wystarczająco ;>

    Ad post o NOPach – ta, czytałem, dobre ;) Na oldnewthings masę ciekawych rzeczy gość publikuje :)

  18. @Gynvael: Właśnie się odnosiłem do tego fragmentu o przypadkowej(?) wartości dodanej tych zer. Zastanawiam się jakie było uzasadnienie, że kiedyś kanarek wyglądał tak, a później się zmienił.

    Ogólnie samo działanie kompilatora z opcją GS jest ciekawe, bo to, czy w danej funkcji znajdzie się dodatkowe zabezpieczenie, czy nie, decyduje kompilator na podstawie pewnych reguł, które zmieniały się między jego wersjami. I potem można się zastanawiać dlaczego na przykład w XP kanarek jest, a w Vista w tym miejscu akurat nie jest stosowany.

  19. @Paweł Goleń & @p9

    Panie Pawle dziękuję za wpis z 21:55. Ze swej strony, jako “pracodawca” a nie pracownik IT powiem, że mam bazę danych funkcjonująca w środowisku DOS, jakieś pól miliona rekordów (zależy ja liczyć). Ostatnim Windowsem, który obsługuje wywołania DOS-a dla mojego programu jest XP. Owszem przeszedłbym na inna wersję, ale spece, którzy robili konwersję mówili o 10-20% błędów z przejścia z mojej wersji na czytelną dla programu działającego na Vista/7. Mądrala jak p9 nie zdaje sobie sprawy, że komputer jest do pracy, a nie do tego, żeby się nim wciąż bawić.
    Na przyszłość planuję przejść na jakieś Ubuntu z VirtualBoxem i FreeDOS-em, lub coś w tym stylu. A to dlatego, że pracownicy mają tez inne zadania do wykonania na komputerze niż tylko wklepywanie do bazy, więc potrzebują procesora tekstów i przeglądarki internetowej oraz programu pocztowego.
    Konkludując: koszt migracji z XP na “7” jest tak duży i wymaga takich zmian, że warto zainwestować nawet w przejście na Ubuntu, OpenSuse, czy co tam mi informatycy zaproponują
    Do moderatora: mam nadzieję, że nie jest to “off-topic”. Nie jestem specem IT i może czasami mój głos uświadomi wszystkim fachowcom, że komputer służy do pracy, a nie “bycia komputerem”

  20. @Plan9
    “Kupując auto liczysz na to że przez 10 lat producent będzie na własny koszt eliminował każdą usterkę?”

    Złe porównanie auta z windowsem dlatego że auto zużywa się mechanicznie i z tym każdy się liczy, natomiast kupując windowsa nie wliczam sobie w koszty potencjalnych luk w nim i strat z nimi związanych. Dlatego jest to wina M$, którą powinien naprawić a nie wymagać kupna nowego systemu.

    “Błąd logiki: Jeśli windows to ‘bubel’ (od siebie dodam że przeterminowany) to po jaką cholerę go używasz skoro są darmowe alternatywy?”
    Błąd logiki, używam wielu systemów operacyjnych, jednakże przez dominację i praktycznie monopol windowsa na rynku również jestem zmuszony go czasami użyć (Choćby na virtualbox’ie)

    Oczywiście nie oczekuje, że XP będzie wspierał najnowsze technologie, bo to jest logiczne że pojawiają się nie zgodności chociaż przeważnie trochę wymuszone ;) aby zakupić nowszy system, no ale cóż takie są prawa rynku.

    Również przepraszam za offtop, ale mam nadzieję, że konstruktywny

    Pozdrawiam
    ShutDown

  21. @Paweł Goleń
    Skoro są “wystarczającą” dobre to o czym ta rozmowa.

    @Archanioł
    “spece” zapomnieli zapewne o “xp mode” i MS Virtual PC (dają to coś za darmo do Win7 Pro^)

    @ShutDown
    Na następnym spotkaniu rady nadzorczej opie*dole złodziei za pozycje w bilansie “modernizacja infrastruktury”:). Konkluzja: samo utrzymanie działu IT jest chyba liczeniem się z potencjalnymi lukami i nieprawidłowościami w działaniu sprzętu/oprogramowania…

    Nie twierdze, że migracja na nowsze oprogramowanie jest ZAWSZE najlepszym rozwiązaniem, jest najlepsza NAJCZĘŚCIEJ. No bo jasna cholera, jeśli się mylę, powinniśmy zostać przy maszynach do pisania albo ku*wa rylcach.

    Moja firma zajmuje się tworzeniem oprogramowania, stąd cała moja irytacja, nie chodzi mi o to że ktoś nie chce przechodzić na “nowe”. Dostaje tylko ku*wy jak ktoś się szczępi o 15 letni kod który nagle przestał mu działać bo coś tam i co ku*wa z tego? Mam robić karitas Polska Sp. z o.o.? Zatrudnić sztab pracowników do robienia czegoś kompletnie bez przyszłości i sensu?

    Każdy ale to absolutnie ku*wa każdy rozsądny i logicznie myślący człowiek zdaje sobie sprawę z tego że kod który tworzy, po 3 (TRZECH) latach będzie zajebiście przestarzały.

    Teraz jeśli taki dajmy na to programista, psychopata jeden dopuści się sprzedaży swojego dzieła już dożywotnio powinien być skazany na jego poprawianie?

    Co wy ku*wa myślicie, że robimy charytatywnie?
    Może jutro powiem pracownikom że skoro dostawali (jak oni swoją drogą mogli?!) wypłaty za programowanie, a ja popier*olec miałem czelność skalać tym rynek, będą zajmowali się tym już do usranej śmierci za free?

    Nie mamy żalu do Intela o to że Pentium II 233 jest powolny tylko dlatego że jego zdalny upgrade jest niemożliwy (mamy, chyba, na tyle wyobraźni). Jakby można było dodawać tranzystory zdalnie zapewne wszyscy by napier*alali. Jakby można było piracić procesory już dawno byśmy to robili.

    Moja płęta jest taka(na wypadek jakby to nie było oczywiste): Jak ci pasuje łidołs ikspe to dobrze ale *urwa nie miej pretensji do nikogo za złe działanie czegoś co kupiłeś sześć czy dzisięć lat temu. Kur*a.

  22. @plan9
    Drogi programisto, żyłka Ci pęknie i wylądujesz na OIOMie
    Zgodnie z twoimi własnymi słowami o darmowych alternatywach powiedziałem, że przejdę na jakiś Debian z VirtualBoxem, bo mam gdzieś XPmode w W7Prof., gdy moje komputery potrzebują obsłużyć 4 programy (baza danych w DOSie, procesor tekstu, prosty edytor HTML -OOo Writer robi te dwie rzeczy na raz, przeglądarka WWW i klient poczty) no i jeszcze jakiś menadżer plików.
    A pies jest pogrzebany rzeczywiście gdzie indziej. Jak napisałeś jesteś programistą i żyjesz z tego, że co 3 lata takiemu matołowi jak ja wciskasz to samo, większe o jakieś 500 MB z ładniejszymi ikonkami.
    Ja nie napadam na MS i wcale nie chcę od nich, żeby do usranej naprawiali swoje przestarzałe produkty. Ale czas wsparcia XP jest do 2014 r. a mamy 2011. Kapewu.

    Twoja kiesa opiera się na pisaniu wciąż tego samego od nowa, mój interes wydać jak najmniej. Stąd porozumienia między nami raczej nie będzie. CO najwyżej mogą być ostre negocjacje :)

  23. @Archanioł: jedna uwaga – Microsoft oferuje różne poziomy wsparcia w zależności od różnych czynników (umowy, wieku produktu). To, że XP jest wspierane do 2014 roku nie oznacza, że każdy błąd w tym czasie będzie poprawiany.

    Dodatkowo trzeba zauważyć, że to, co opisali chłopaki, nie jest podatnością samą w sobie. Jest to niedoskonałość pewnego dodatkowego mechanizmu bezpieczeństwa (kompilatora na dodatek), która w specyficznych warunkach może pozwolić na skuteczne wykorzystanie INNEJ podatności. I do usunięcia tej INNEJ (właściwej) podatności Microsoft jest zobowiązany w ramach oferowanego wsparcia.

  24. “którzy zarzucali autorowi wpisu wprowadzanie w błąd. Kwestia ta była o tyle dyskusyjna, że podatna funkcja w systemie Windows XP posiadała dodatkowe zabezpieczenia — nieobecne w wersjach z Visty oraz 7 — w postaci tzw. security cookies (znane również jako stack canaries), które wg. ówczesnego stanu wiedzy zapewniało wystarczającą ochronę przed możliwością wykonania wrogiego kodu, przy użyciu błędu przepełnienia bufora na stosie.”
    Toś chyba pan zagalopował odnośnie tego fragmentu

    OIdnośnie tezy że ciasteczka są słabe to nie są

    one poprostu raczej nie były “projektowane” (o ile można nazywać wstawienie losowej wartości na szcycie stosu pod eipem i jej porównywanie za pomocą dodatkowej procedury [tak to wygląda w ring 3 przunajmniej] projektowaniem)
    pod kątem błędów lokalnych
    (tak mi się wydaje :D)

  25. @ola
    Ad “Toś chyba pan zagalopował odnośnie tego fragmentu”
    Tzn? O którą część cytowanego przez Ciebie fragmentu Ci chodzi konkretnie i jak konkretnie brzmi Twoja uwaga do niego?

    Ad
    “one poprostu raczej nie były “projektowane” […] pod kątem błędów lokalnych
    (tak mi się wydaje :D)”
    Tzn jest tak jak mówisz (źródło?), czy tak Ci się wydaje?
    Bo np. mi się wydaje, że były projektowane tak, zeby zapobiegać atakom związanym ze stack-based buffer overflow, niezależnie od tego czy jest to atak lokalny czy zdalny.
    Co więcej, na MSDN (http://msdn.microsoft.com/en-us/library/8dbf701c(VS.80).aspx) nic nie zostało wspomniane o atakach zdalnych czy lokalnych.

  26. @ola
    Masz rację wydaje Ci się.
    Z chaosu Twojej wypowiedzi można by wydobyć coś o logicznej wartości zbliżonej do “silnik spalinowy nie był projektowany pod kątem spalania paliwa.”

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: