Czy sposób wydawania poprawek zabezpieczeń przez Microsoft daje możliwość praktycznie automatycznego tworzenia exploitów i to dosłownie w kilka sekund? Grupa naukowców uważa, że tak.
Grupa czterech naukowców z Carnegie Mellon University, University of California w Berkeley oraz University of Pittsburgh ostrzega Microsoft, że sposób, w jaki wydawane są poprawki zabezpieczeń do jego produktów stwarza, wbrew pozorom, całkiem poważne zagrożenie. Na dowód tej tezy opracowali oni metodę nazwaną APEG (automatic patch-based exploit generation), dzięki której możliwe jest błyskawiczne, automatyczne stworzenie exploitu – jedyne, czego potrzeba, to wydana przez Microsoft poprawka i oryginalne biblioteki. To właśnie na podstawie jej analizy możliwe jest opracowanie złośliwego kodu.
Autorzy APEG twierdzą, że Microsoft wydając poprawkę, sam podaje kod eksploatujący “na talerzu”. Ostrzegają, że stosując APEG atakujący są w stanie wytworzyć exploit niemalże natychmiast po wydaniu poprawki przez Microsoft. Oczywiście hakerzy z całego świata dekompilowali poprawki od zawsze, aby poznać łatane przez nich luki. Zajmowało to jednak pewną ilość czasu – przy pomocy APEG kod powstaje w kilka sekund, a w najgorszym przypadku w kilka minut.
Więcej informacji: http://www.techit.pl/Aktualnosci/View.as...microsoftu
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
OSnews.pl jest społecznościowym serwisem informacyjnym poświęconym oprogramowaniu, systemom operacyjnym i światowi IT. więcej »
Ale do wersji sprzed aktualizacji… więc jak ktoś ma zaktualizowanego windowsa to nic mu nie grozi (z tego powodu)
niby tak, ale w czasie od wypuszczenia poprawki, do zalatania – userzy maja problem.
Więc jak wydawać poprawki, tak aby nie można było się dowiedzieć gdzie był błąd ?
Najważniejsze jest chyba to, żeby poprawka mogła dotrzeć jak najszybciej do każdego użytkownika. Model Microsoftu zostawia zbyt duży odstęp czasu między wypuszczeniem łatki, a jej dotarciem do użytkowników.
Nie rozumiem o jakim modelu mowisz. Jak tylko Microsoft publikuje latke jest ona dostepna. O tym kiedy trafi na Twoj komputer decydujesz Ty (mniej lub bardziej swiadomie). Moze trafic 2 godziny po opublikowaniu, a moze i po 2 latach. Tak czy owak ten news jest..niepokojacy. Jesli to naprawde robi to “automat” i to w kilka sekund/minut to dobrze nie jest. Z drugiej strony najbardziej masowe ataki jakie pamietam (LSASS Vulnerability – CAN-2003-05330) pojawily sie PRZED MS04-011
Drogi Ku8o – kolega Ceceron nie myślał o tym etapie dystrybucji poprawek. Problem opieszałości userów pod kątem pobierania łatek dotyczy wszystkich platform, ale to ich problem. Przecież nikt cię nie zmusi żebyś naprawił samochód jak ci się zepsuję.
Problem w tym że Windows ma zamknięte źródła oraz licencję która nie pozwala na przerabianie już istniejących programów – tzw. firmy trzecie mają tutaj dwie przeszkody: prawną i technologiczną.
Pracownicy Microsoftu bardzo dbają o to by ograniczać wolną konkurencję na rynku IT bo jeszcze wysłali by się na bezrobocie (tak zazwyczaj jest z kiepskimi programistami).
Gdyby opisana w newsie luka znajdowała się w Linuksie to:
1) łatka została by wykonana w kilka godzin, może nawet minut po ogłoszeniu błędu
2) Jest też plus. Jedyną osobą która może się włamać jest trzech naukowców z Kaliforni – w tym plusie kryje się jednak minus – mogli przecież nikomu nie mówić o swoim odkryciu, a zacząć po prostu zarabiać na swojej słodkiej tajemnicy. Ryzyko że ktoś znajdzie i ogłosi błąd jest znacznie mniejsze niż przy open source gdzie nie opłaca sie tworzyć złośliwego oprogramowania którym to będziemy wysysać te cenne numery kart kredytowych zaledwie przez 15 minut
3) Panowie z Kaliforni okazali się być szlachetnymi ludźmi. Mogli by być jeszcze bardziej szlachetni gdyby dano im szansę zmiany kodu źródłowego i wcielenia go do oficjalnej gałęzi oprogramowania które zostało dotknięte luką
Mnie się wydaje, że chodzi o coś innego – po przygotowaniu łatki, MS wypuszcza ją jako hotfix i testuje. Dopiero po przejściu testów, łatka jest wpuszczana do kanału dystrybucji poprawek (Windows Update).
Drogi witku, zostawmy Linuxa w spokoju. Nie o nim tu mowa. Nie wiem o czym myslal Ceceron ale wiem co napisal… “Model Microsoftu zostawia zbyt duży odstęp czasu między wypuszczeniem łatki, a jej dotarciem do użytkowników”. Napisal zatem o TYM etapie;) Gdyby napisal np. Model Microsoftu zostawia zbyt duzy odstep czasu miedzy wykryciem luki a opublikowaniem latki mialby/bys racje w 90 procentach.
Hmm… Chodziło mi o to, że gdzieś czytałem (poszukam źródła później), że system automatycznych aktualizacji w Windowsie nie umożliwia z powodów technicznych zaktualizowania wszystkich systemów w wystarczająco krótkim czasie. Po 24h od wydania łatki nawet ponad połowa z nich nie ma szans być zaktualizowana (zakładając nawet, że wszyscy chcą to zrobić jak najszybciej), a w tym czasie można już spokojnie stworzyć odpowiedniego exploita i go wykorzystać.
Jeśli dobrze zrozumiałem to wystarczy, aby patch był oferowany *tylko* przez windows update, a nie równolegle jako plik do pobrania, który da się spatchować i powiesić gdzieś z boku, aby użytkownicy mieli “łatwiej”.
Właśnie ze względu na podobne ryzyko nigdy nie pobierałem, żadnego softu dostępnego na stronie jego producenta z innych witryn. Niech przykładem będą buildy firefoksa latające po setkach serwisów “newsowo plotkarskich”.
No tak, Linuks jest zawsze najlepszy.
Oczywistym jest, że mając łatkę można przez porównanie kodu napisać eksploita. Nie ma przy tym znaczenia, czy łatka jest binarna (jak w Windows), czy w formie kodu źródłowego (w Linuksie). Zasada jest taka sama, co najwyżej raz pracujemy na kodzie w asemblerze, a drugi raz na kodzie w C. Oczywiście, w C jest łatwiej, przez co – o ironio – na Linuksie jest łatwiej pisać exploity w ten sposób niż w Windows.
Innowacja tutaj polega jedynie na tym, że proces został zautomatyzowany.
Dalej, wieszanie psów konkretnie na Microsofcie jest nieuzasadnione. Problem dotyczy każdego systemu wydawania łatek. Nie ma znaczenia, jak długo po zgłoszeniu błędu została wydana łatka. Wystarcza sam fakt, że została wydana. Można nawet postulować, że w przypadku błędów które nie zostały ujawnione publicznie, wydanie łatki zmniejsza bezpieczeństwo, ponieważ ujawnia istnienie buga tym, którzy wcześniej o nim nie wiedzieli.
Monokultura, ten dokument opisuje auto-tworzenie exploitów na podstawie zmiany stanu z P do P’. W przypadku Linuksów masz stany Q, R, T, itp. Np. ostatnia spora dziura z vmsplice nie ,,działała” na jądrach z grsec. Jak uczy biologia monokultura prowadzi do masowego wymierania (czyt. blaster, sasser itp.). To jest min. wada Windows.
Systemy operacyjne to nie biologia. Zastosowanie teorii z jednego do drugiego to ciekawy temat, ale nikt sensownosci tego podejscia nie potwierdzil.
Segfault na jądrach z grsec przy użyciu exploita na vmsplice to fakt.
widzisz krzy, na calym swiecie istnieja firmy zajmujace sie wykrywaniem bledow w kodahc roznych aplikacji. jadro linuksa jest najlepiej przejrzanym kodem zrodlowym na ziemi i zawiera najmniej bledow. z raportow tychze firm wynika, ze blad trafia sie raz na kilkadziesiat tysiecy linii. pozostale oprogramowanie open-source zawiera zdecydowanie wiecej bledow (powiedzmy jeden blad na 1k – 5k linii), ale calkowicie beznadziejnie w tych testach wypada oprogramowanie o zamknietym kodzie zrodlowym, gdzie jeden blad mozna znalezc na 100 lub nawet na kilkadziesiat linii kodu.
wbrew pozorom otwartosc kodu zrodlowego wcale nie pomaga w napisaniu exploita.
Częstotliwość występowanie błędów nie ma żadnego znaczenia. Mówimy o sytuacji kiedy błąd już wystąpi.
Analizę statyczną lepiej robi się na kodzie źródłowym niż binarnym, i to jest też fakt powszechnie znany.
Poza tym, blankietowe twierdzenie że oprogramowanie otwartoźródłowe jest z definicji lepsze jest błędne. Oczywiście kernel Linuksa jest zaudyotwany dość mocno, ale za to inne programy już znacznie słabiej. Sam pamiętam czasy jak w otrwartoźródłowym sendmailu była jedna dziura tygodniowo
. Ilość błędów zależy głównie od sposobu zarządzania projektem, a nie od otwartośći. I owszem, pewne praktyki typowe dla oprogramowania otwartoźródłowego zmniejszają ilość błędów, ale to nie jest tak, że jeżeli ktoś wypuści kod najeżony wywołaniami strcpy(), to on przez samą swoją opensourcowość stanie się bezpieczny.
Twierdzenie że FOSS jest mniej dziurawe od innego oprogramowania ma pewne umocowanie w praktyce. Vide raporty Coverity, robione nie na zamówienie jakiejś firmy ale US DoD.
Oczywiście wszystko zależy od programistów, ale tutaj intuicja podpowiada, że robiąc coś niemal wyłącznie dla przyjemności tworzenia, buduje się lepszy produkt. Gdy już ten lepszy produkt się zrobiło to kasa jakoś tak sama napływa…