Koniec z bezpieczeĂąstwem w Windows?
Widzisz wersję archiwalną tematu "Koniec z bezpieczeĂąstwem w Windows?" z forum pl.comp.security
Henry(k) - 12 Sie 2002, 03:26
Witam.
Nie wiem czy było, ale dopiero tu zagościłem i chciałbym zapytać...
http://newsroom.chip.pl/news_41345.html
http://security.tombom.co.uk/shatter.html
...czy naprawdę jest tak źle?
Pozdrofka.
Bronek Kozicki - 12 Sie 2002, 05:09
...czy naprawdę jest tak źle?
nie jest. Artykuły do których podałeś linki to histeryczne doniesienie
(i zupełnie nieprzytomne komentarze do nich) o rodzaju ataków, które są
znane od lat, o których od dawna się pisze, i zabezpieczenie przed
którymi są wbudowane w system operacyjny również od dawna. Zapraszam do
przeczytania wątku "ile w tym prawdy ?" na pl.comp.os.advocacy
B.
Artur Karazniewicz - 12 Sie 2002, 06:49
| ...czy naprawd? jest tak ?le? nie jest. Artyku?y do kt?rych poda?e? linki to histeryczne doniesienie
(i zupe?nie nieprzytomne komentarze do nich) o rodzaju atak?w, kt?re s?
znane od lat, o kt?rych od dawna si? pisze, i zabezpieczenie przed
kt?rymi s? wbudowane w system operacyjny r?wnie? od dawna. Zapraszam do
przeczytania w?tku "ile w tym prawdy ?" na pl.comp.os.advocacy
Hmm - co do pcoa - to nie jestem pewien
czy jest to najlepsze zrodlo informacji jakichkolwiek a
juz napewno nie dot. bezpieczenstwa. Ale przeczytalem caly
watek i z tego co na szybko widze:
1. Nie wypowiadala sie tam zadna osoba ktora
ma doswiadczenie jako programista Windowows,
2. Zdania czy jest to dziura exploitowalna czy nie
sa podzielone.
Jesli chodzi o mnie to pisalem przez ok. 4 lata
w kilku firmach zawodowo oprogramowanie pod windows
(API, MFC i innego typu wrappery jak VCL czy OWL)
wiec moze sie ustosunkuje do ew. tlumaczen, ze nie jest
to dziura grozna bo:
nie przyjmowalo bzdurnych messagey"
odp.
aplikacji pod windows i nie wie, ze jest to praktycznie
niemozliwe :). Daje skrzynke piwa jesli znajdzie sie
piceiu programistow ktorzy w ten sposob pisza swoje aplikacje -
a juz wogole jest to nierealne przy pisaniu w czyms wyzejpoziomowym
byc a jakie nie maja byc obslugiwane przez dana kontrolke w MFC.
po drugie, zeby to wylaczyc nalezaloby kazda tego tupu kontrolke
(z-subclass-owac - jesli ktos pisze pod win to wie o co chodzi -
MessagePump) i wywalac tam wszystkiego czego sie nie spodziewamy) -
itd. itp. o innych problemach z tym zwiazanych nie wspominajac
(np. o tym, ze mozna bez problemu dostac sie do okienka
skladowego dowolnej aplikacji - nie chodzi o to, ze word nie obsluguje
komunikatu X - mozna sobie 'wy-enum-erowac' dowolny edit w dowolnym
aktualnie otwartym okienu Worda).
b. "Nalezy sprawdzac parametry z jakimi przychodzi komunikat"
odp.
IMHO to zadanie jest niewykonalne w C/C++ - wie o tym kazdy
kto widzial jak sa przekazywane parametry w WinAPI (
na najnizszym poziomie sa to wskazniki LPARAM i WPARAM - i to
co tam przychodzi jest _ZALEZNE_ od kontekstu - rzutowane nastepnie
na to czego sie spodziewamy i juz). Czyli jesli ma to byc np.
struktura opisujaca kolor - to jest to wskaznik to tego typu struktury
(jako LONG - stad LPARAM lub z dawnych czasow WORD - stad WPARAM).
Reasumujac IMHO jest to niemozliwe - a jesli ktos to w jakis
magiczny sposob robi to chyle czola :).
c. "Dotyczy niewielkiej ilosci aplikacji"
odp.
Znajac troche praktyke programowania pod windows dam sobie reke
uciac, ze tak nie jest - no ale poczekamy zobaczymy.
problem wydaje mi sie bardzo ciekway - mysle, ze za jakis czas
mozemy spodziwac sie sporo expoitow :).
Artur.
Wojtek Walczak - 12 Sie 2002, 07:46
Nie wiem czy było, ale dopiero tu zagościłem i chciałbym zapytać...
http://newsroom.chip.pl/news_41345.html
http://security.tombom.co.uk/shatter.html
...czy naprawdę jest tak źle?
Niestety nie.
Bronek Kozicki - 12 Sie 2002, 07:48
Hmm - co do pcoa - to nie jestem pewien
czy jest to najlepsze zrodlo informacji jakichkolwiek a
juz napewno nie dot. bezpieczenstwa. Ale przeczytalem caly
watek i z tego co na szybko widze:
To fajnie; zajrzyj jeszcze do BUGTRAQ i NTBUGTRAQ, tam wypowiadają sie
ludzie kompetentni jeżeli chodzi o bezpieczeństwo, również Windows. Te
wątek się na obu listach nieźle rozwinął i jest co czytać.
1. Nie wypowiadala sie tam zadna osoba ktora
ma doswiadczenie jako programista Windowows,
ja mam doświadczenie, nawet całkiem spore. Przy czym zaznaczam, że nie
chodzi o robienie UI, tylko aplikacje serwerowe, COM-y itp. - w C++ ,
często z wykorzystaniem ATL. Z zasady unikam MFC, bo jest wyjątkowo
nabałaganiony ale kiedy nie było alternatywy i musiałem robić UI - to go
używałem .
2. Zdania czy jest to dziura exploitowalna czy nie sa podzielone. Jesli chodzi o mnie to pisalem przez ok. 4 lata
w kilku firmach zawodowo oprogramowanie pod windows
(API, MFC i innego typu wrappery jak VCL czy OWL)
I to Twój błąd. Każdy framework robi "coś" po swojemu, i albo potrafisz
nad tym "czymś" zapanować, albo możesz przyznac się że go dobrze nie
znasz, i używasz "na czuja", albo masz ostatnią możliwość - zmienić
framework . Nie wiem jak tam z możliwościami WTL, ale po pobieżnym
zbadaniu wygląda bardzo interesująco - lekki, prosty, ładny :
kto widzial jak sa przekazywane parametry w WinAPI (
na najnizszym poziomie sa to wskazniki LPARAM i WPARAM - i to
co tam przychodzi jest _ZALEZNE_ od kontekstu - rzutowane nastepnie
na to czego sie spodziewamy i juz). Czyli jesli ma to byc np.
struktura opisujaca kolor - to jest to wskaznik to tego typu struktury
(jako LONG - stad LPARAM lub z dawnych czasow WORD - stad WPARAM).
są do tego funkcje Win32 API : IsBadCodePtr (sprawdzenie adresu funkcji)
, IsReadPtr (sprawdzenie dostępu do odczytu danych) , IsBadWritePtr
(sprawdzenie dostępu do zapisu danych) , IsBadStringPtr (sprawdzenie
poprawności napisu null-terminated) . Wystarczy z w/w funkcji skorzystać
przed odwołaniem się do parametrów komunikatu, one właśnie do tego są.
Oczywiście, w środowisku z chronionym dostępem do pamięci proces ma
dostęp tylko do własne przestrzeni adresowej, więc podawanie adresu
funkcji z innego procesu możesz włożyć między bajki. Już nie mówiąc o
tym, że w ogóle podawania adresu funkcji w komunikacie to bzdura, i
najlepiej po prostu sprawdzić czy jest to adres funkcji służącej do
obsługi tego komunikatu.
problem wydaje mi sie bardzo ciekway - mysle, ze za jakis czas
mozemy spodziwac sie sporo expoitow :).
wyłącznie na usługi, działające jako LocalSystem z dostem do desktopu.
Jest ich trochę, ale nie aż tak dużo żeby robić sensację (IMHO błąd
obsługi SSL jest znacznie poważniejszy) , i winę ponosi nie Win32 API
tylko programiści, którzy nie potrafią z niego korzystać. I oczywiście,
powtarzam po raz kolejny - nie jest to rzecz nowa, takie usługi były
exploitowane od roku 2000.
B.
Artur Karazniewicz - 12 Sie 2002, 08:57
ja mam do?wiadczenie, nawet ca?kiem spore. Przy czym zaznaczam, ?e nie
chodzi o robienie UI, tylko aplikacje serwerowe, COM-y itp. - w C++ ,
cz?sto z wykorzystaniem ATL. Z zasady unikam MFC, bo jest wyj?tkowo
naba?aganiony ale kiedy nie by?o alternatywy i musia?em robi? UI - to go
u?ywa?em .
Ja tez - w tym nad jednym z wiekszych systemow bankowych w kraju -
i NIGDY (_NIGDY_) nikt - ja ani moi wspolpracownicy tego nie robili
(podane pomysly) - zreszta jak dam reke uciac 99.99% programistow
windowsowych (napewno tych wychowanych na Petzoldzie).
Tylko mi nie mow, ze Ty zawsze kazde okienko (nie tylko okno aplikacji)
ale kazdego durnego Edita uzbrajales w mechanizm kontroli nad tym co
do nich przychodzi?
I to Tw?j b??d. Ka?dy framework robi "co?" po swojemu, i albo potrafisz
nad tym "czym?" zapanowa?, albo mo?esz przyznac si? ?e go dobrze nie
znasz, i u?ywasz "na czuja", albo masz ostatni? mo?liwo?? - zmieni?
:))) framework to framework - (niezle MFC i wszystko
o czym pisalem) - jak sama nazwa mowi - zwalnia mine z pewnych niepotrzebnych
szczegolow i dodaja pewna wartosc. Nie powinno mnie interesowac
co jest w srodku i jak to sie dzieje (takie sa zasady
inzynierii - dobra biblioteka nie zmusza uzytkownika do poznania
szczegolow na ktorych bazuje - buduje pewne reguly - i jesli dostarczysz
"wejscie" zgodne z tymi regulami mozesz spodziewac sie "wyjscia" rowniez
zdeterminowanego przez te szczegoly). Potrafie zapanowac nad MFC
- ale wlasnie ten szczegol ktorego nie nalezy ruszac w MFC to MessagePump
z kilku powodow o ktorych nie bede tu pisal.
s? do tego funkcje Win32 API : IsBadCodePtr (sprawdzenie adresu funkcji)
, IsReadPtr (sprawdzenie dost?pu do odczytu danych) , IsBadWritePtr
(sprawdzenie dost?pu do zapisu danych) , IsBadStringPtr (sprawdzenie
poprawno?ci napisu null-terminated) . Wystarczy z w/w funkcji skorzysta?
Mysle o czyms na wyzszym poziomie - jesli w LPARAM przesle wskaznik
np. na strukture RBG - to nie jest w stanie sprawdzic nikt co tam tak
naprawde jest - chodzi mi o mechanizm typu "dynamic_cast" w C++ - ktorego
tutaj nie da rady zastosowac.
przed odwo?aniem si? do parametr?w komunikatu, one w?a?nie do tego s?.
Oczywi?cie, w ?rodowisku z chronionym dost?pem do pami?ci proces ma
dost?p tylko do w?asne przestrzeni adresowej, wi?c podawanie adresu
funkcji z innego procesu mo?esz w?o?y? mi?dzy bajki. Ju? nie m?wi?c o
tak - ale w przypadku opisanym - chodzi o odpalenie procedury z przestrzeni
adresowej tego samego procesu (jest w pamieci zaalokowanej przez kontrolke
danej aplikacji) i to jest caly problem.
tym, ?e w og?le podawania adresu funkcji w komunikacie to bzdura, i
czyli tutaj sie zgadzamy :)).
| problem wydaje mi sie bardzo ciekway - mysle, ze za jakis czas | mozemy spodziwac sie sporo expoitow :). wy??cznie na us?ugi, dzia?aj?ce jako LocalSystem z dostem do desktopu.
Jest ich troch?, ale nie a? tak du?o ?eby robi? sensacj? (IMHO b??d
obs?ugi SSL jest znacznie powa?niejszy) , i win? ponosi nie Win32 API
tak - ale ten jest relatywnie bezproblemowy do usuniecia w odroznieniu od
opisanego powyzej.
tylko programi?ci, kt?rzy nie potrafi? z niego korzysta?. I oczywi?cie,
powtarzam po raz kolejny - nie jest to rzecz nowa, takie us?ugi by?y
exploitowane od roku 2000.
Byc moze - niemniej nie kwitowalbym tego stwierdzeniem typu:
to jest juz znane od 2000 i jakos nie ma za duzo Explotitow - poczekajmy...
Artur.
Bronek Kozicki - 12 Sie 2002, 09:11
Tylko mi nie mow, ze Ty zawsze kazde okienko (nie tylko okno
aplikacji) ale kazdego durnego Edita uzbrajales w mechanizm kontroli
nad tym co do nich przychodzi?
nie mówię ;
zapanowac nad MFC - ale wlasnie ten szczegol ktorego nie nalezy
ruszac w MFC to MessagePump z kilku powodow o ktorych nie bede tu
pisal.
wiem; właśnie dlatego pod żadnymi pozorami nie puściłbym go w warunkach
umożliwiających exploita (usługa działająca na desktopie). Do takich
rzeczy MFC się nie nadaje, kropka; a kto z niego korzystał do pisania UI
usług, ten był (co najmniej) naiwny.
to jest juz znane od 2000 i jakos nie ma za duzo Explotitow -
poczekajmy...
ano, poczekajmy. Coś się na pewno urodzi. BTW: gdyby Chris Paget "wziął
na deskę" gotowego frameworoka z wbudowanym MessagePump (właśnie MFC, na
przykład) to mógłby powstać znacznie bardziej interesujący artykuł, a i
późniejszy biuletyn bezpieczeństwa miałby .... donośniejsze konsekwencje
;)
B.
andrzej - 12 Sie 2002, 10:15
ja mam doświadczenie, nawet całkiem spore.
a ja nie mam zadnego. Lubie jednak poczytac p.c.s. ... :)
[..] I to Twój błąd. Każdy framework robi "coś" po swojemu, i albo potrafisz
nad tym "czymś" zapanować,
czyli wg. Ciebie bezpieczenstwo (systemu) zalezy od intencji/umiejetnosci
programisty piszacego "cos" pod ("bezpieczny") system?
[...] Jest ich trochę, ale nie aż tak dużo żeby robić sensację (IMHO błąd
obsługi SSL jest znacznie poważniejszy) ,
W moim mozdzku nie bardzo moge zrozumiec jak ma sie "jedno" do "drugiego".
Raczej przekladalem to sobie tak:
"bezpieczny" system -Polska
aplikacje -prawo, przepisy, etc.
ssl -prom
"inny" system -Szwecja
aplikacje etc.
Jesli jedziesz samochodem (plyniesz promem), jestes jakby poza
oddzialywaniem systemu. Jak prom dziurawy to tonie, tyle ze to "inna"
bajka. A jak jest w Polsce? Sam wiesz chyba dobrze? :)
i winę ponosi nie Win32 API
tylko programiści, którzy nie potrafią z niego korzystać.
Socjalizm to wspanialy ustroj, tyle ze spoleczenstwo do niego nie doroslo.
Dlaczego jednak funkcjonuja "inne" ustroje. Fakt, tez niedoskonale, jednak
chyba znacznie "lepsze"?
I oczywiście,
powtarzam po raz kolejny - nie jest to rzecz nowa, takie usługi były
exploitowane od roku 2000.
Wiec dlaczego jeszcze maja prawo bytu!?!
pozdrawiam Andrzej
Bronek Kozicki - 12 Sie 2002, 10:31
| I to Twój błąd. Każdy framework robi "coś" po swojemu, i albo | potrafisz nad tym "czymś" zapanować, czyli wg. Ciebie bezpieczenstwo (systemu) zalezy od
intencji/umiejetnosci programisty piszacego "cos" pod ("bezpieczny")
system?
bezpieczeństwo system OCZYWIŚCIE zależy od aplikacji działających z
wysokimi uprawnieniami. To jest reguła dla każdego systemu operacyjnego
!
Wiec dlaczego jeszcze maja prawo bytu!?!
wybacz, zupełnie nie zrozumiałem Twoich "przykładów" więc pomijam je
milczeniem. Jeżeli przypadkiem chodzi Ci o zarządzanie bezpieczeństwem,
to zapraszam do lektury WinSecurity Magazine (znakomity cykl Andrzeja
Białasa o polityce bezpieczeństwa).
Problemy z bezpieczeństwem każdego programu mają, i będą miały miejsce,
tak długo jak programiści będą popełniali błędy. Ponieważ programiści są
ludźmi, i nic się nie zanosi na zmianę, to problemy z bezpieczeństwem
programów były, są i będą. Jeżeli pewne programy korzystają w
niewłaściwy sposób z uprawnień nadanych przez administratora, to jest to
już problem systemu operacyjnego, na którym są one zainstalowane.
Programy SUID uruchamiane pod dowolną odmianą UNIXa, które niepoprawnie
korzystają np. z sprintf (...) powoduję podobne problemy, a jednak jakoś
nikt nie nazwał tego "poważnym problemem systemu operacyjnego" . Chyba
że sama możliwość ustawienia bitu SUID jest takim problemem, ale jakoś
ciągle jest on wykorzystany tu i ówdzie.
B.
andrzej - 13 Sie 2002, 03:39
| [...] wybacz, zupełnie nie zrozumiałem Twoich "przykładów"
wiec w skrocie
piszesz:
i winę ponosi nie Win32 API
tylko programiści, którzy nie potrafią z niego korzystać.
nie moge sie zgodzic z taka filozofia. Moim zdaniem powinno byc tak
idiotoodporne jak to tylko mozliwe (albo i wiecej:).
[...]Problemy z bezpieczeństwem każdego programu mają, i będą miały
miejsce,
tak długo jak programiści będą popełniali błędy. [...]
zgadzam sie, tylko ze bledy (jak mniemam) nalezy "naprawiac", tymczasem
czytam cos takiego:
powtarzam po raz kolejny - nie jest to rzecz nowa, takie usługi były
exploitowane od roku 2000.
jest to juz chyba olewanie (delikatnie mowiac) klienta. Chyba, ze
"podnoszenie bezpieczenstwa" polega na ukrywaniu zamiast lataniu dziur.
pozdrawiam Andrzej
ps. Teraz z kolei ja nie rozumiem Twoich przykladow. Masz na mysli
konkretny (dolaczany do systemu) program suid? I jak dlugo byl
nienaprawiony? Czy "jakies" programy "suid", ktore mozna, ale nie trzeba
uruchamiac?
Bronek Kozicki - 13 Sie 2002, 04:06
| i winę ponosi nie Win32 API
| tylko programiści, którzy nie potrafią z niego korzystać.
nie moge sie zgodzic z taka filozofia. Moim zdaniem powinno byc tak
idiotoodporne jak to tylko mozliwe (albo i wiecej:).
Jeżeli program działający z wysokimi uprawnieniami, zainstalowany przez
administratora, powoduje naruszenie bezpieczeństwa systemu, to nie ma
siły która by go przed tym powstrzymała. Tak działają współczesne
systemy operacyjne, i jeżeli sugerujesz że jest inaczej, to ja dziękuję
za dyskusję.
B.
Paweł Kot - 13 Sie 2002, 04:11
| [...] | wybacz, zupełnie nie zrozumiałem Twoich "przykładów"
wiec w skrocie
piszesz:
| i winę ponosi nie Win32 API
| tylko programiści, którzy nie potrafią z niego korzystać.
nie moge sie zgodzic z taka filozofia. Moim zdaniem powinno byc tak
idiotoodporne jak to tylko mozliwe (albo i wiecej:).
Tak jak strcpy()? ;-P
pkot
Konrad Stepien - 13 Sie 2002, 14:16
| i winę ponosi nie Win32 API | tylko programiści, którzy nie potrafią z niego korzystać. | nie moge sie zgodzic z taka filozofia. Moim zdaniem powinno byc tak | idiotoodporne jak to tylko mozliwe (albo i wiecej:). Jeżeli program działający z wysokimi uprawnieniami, zainstalowany przez
administratora, powoduje naruszenie bezpieczeństwa systemu, to nie ma
siły która by go przed tym powstrzymała. Tak działają współczesne
systemy operacyjne, i jeżeli sugerujesz że jest inaczej, to ja dziękuję
za dyskusję.
OK, tylko ktoś kto pisze ten "program działający z wysokimi uprawnieniami",
to na ogół zakłada, że system coś tam mu zapewnia (np. ochronę pamięci).
Nie pisałem nic poważnego pod win32, ale ..... z unixowego podwórka:
Pisząc program który działa z uid 0 mam prawo zakładać, że system
nie pozwoli "zwykłemu" userowi zrobić kill -coś na tym procesie
i nie muszę w tym celu przechwytywać wszystkich sygnałów w celu
weryfikacji. Jeśli się okaże, że powiedzmy linux takie coś przepuszcza,
to jest to bug jak cholera i trzeba go szybko porawić (w jądrze
a nie w aplikacjach).
Bronek Kozicki - 14 Sie 2002, 04:12
OK, tylko ktoś kto pisze ten "program działający z wysokimi
uprawnieniami", to na ogół zakłada, że system coś tam mu zapewnia
(np. ochronę pamięci).
Oczywiście, że system zapewnia ochronę pamięci, jak i ochronę przez DACL
wszystkich obiektów które sobie ów program utworzy - semaforów, plików,
_okienek_ itd. Jeżeli programista _świadomie_ z ochrony okienek
rezygnuje, tworząc swój program do pracy na desktopie usera, to jest to
sprawa programisty! Nikt mu nie każe, i _nie_ jest to domyślny sposób
działania usług w WinNT. Znacznie bardziej rozsądna jest izolacja usługi
(procesu działającego z wysokimi uprawnieniami) , zdefiniowanie
interfejsu przez który można się z nim z zewnątrz komunikować,
opatrzenie go DACL-em, dokładna weryfikacja każdego przychodzącego
który do tej komuniacji będzie służyć! Trochę roboty to owszem jest, ale
przecież w Win32 rozwiązań do takiej komunikacji jest multum do wyboru,
i niemal każdy jest bezpieczniejszy od message pump ! Twierdzę uparcie,
że problem poruszany w tym wątku ma swoje źródło w lenistwie
programistów tworzących aplikacje - to _nie_ jest problem systemu
operacyjnego. Inna sprawa, że Windows 2000 _też_ ma domyslnie
bepzieczeństwo systemu _może_ ucierpieć. Ale źródłem problemu nie jest
sam mechanizm message pump (choć przyznam że jest on STRASZNY), tylko
nieumiejętność korzystania z niego przez programistów!
B.
Konrad Stepien - 14 Sie 2002, 06:19
| OK, tylko ktoś kto pisze ten "program działający z wysokimi | uprawnieniami", to na ogół zakłada, że system coś tam mu zapewnia | (np. ochronę pamięci). Oczywiście, że system zapewnia ochronę pamięci, jak i ochronę przez DACL
wszystkich obiektów które sobie ów program utworzy - semaforów, plików,
_okienek_ itd. Jeżeli programista _świadomie_ z ochrony okienek
No właśnie nie jestem pewien tego "świadomie". To znaczy, mam mocne
I tak na oko, to to jest właśnie problem z windowsami, cholernie ciężko
że tak powiem "o wszystkim wiedzieć" i stąd programy pod win32 mają
szansę być znacznie bardziej dziurawe.
Jak za rok się okaże, że jest bug w jakimś mechaniźmie, to znów się
okaże, że to wina programistów, bo nie powinni korzystać z tego
macjanizmu :-)
A tak przu okazji, są jakieś sensowne materiały o tym jak programować
bezpiecznie pod windows ? Po dla unixów jest tego sporo, zresztą
da się je zawrzeć we w miarę niedużej objętości.
Bronek Kozicki - 15 Sie 2002, 13:24
A tak przu okazji, są jakieś sensowne materiały o tym jak programować
bezpiecznie pod windows ?
Keith Brown "Programming Windows Security", Addison-Wesley 2000
B.
Krzysztof Halasa - 15 Sie 2002, 13:32
Tak jak strcpy()? ;-P
strcpy() jest idiotoodporne dokladnie w tym samym stopniu, co zapisywanie
stringow jako ASCII-Z. Czyli w wysokim. Dla programisty jest oczywiste,
ze musi on zapewnic odpowiednia ilosc miejsca dla nowego stringu.
Co innego, gdyby wystepowaly tam jakies dodatkowe dziwne wymagania
w rodzaju przejecia sygnalu SIGSTOP oraz sprawdzenia, czy przypadkiem
/dev/tcp (/dev/udp w wersji z UTF8) nie jest plikiem, do ktorego prawo
x maja uzytkownicy.
Grzegorz Szyszlo - 19 Sie 2002, 04:30
| i winę ponosi nie Win32 API | tylko programiści, którzy nie potrafią z niego korzystać. | nie moge sie zgodzic z taka filozofia. Moim zdaniem powinno byc tak | idiotoodporne jak to tylko mozliwe (albo i wiecej:). Tak jak strcpy()? ;-P
czy ono wie co to jest strncpy() ? ;]
Grzegorz Szyszlo - 19 Sie 2002, 04:32
Pisząc program który działa z uid 0 mam prawo zakładać, że system
nie pozwoli "zwykłemu" userowi zrobić kill -coś na tym procesie
i nie muszę w tym celu przechwytywać wszystkich sygnałów
nie musisz sie tez specjalnie martwic, ze ktos przejmie terminal
(czy to graficzny czy tekstowy), i nie wykona tam operacji za admina.
jak widac z dyskusji, sa sugestie, iz win32 api ma dziury w tym
wzgledzie.
prawdopodobnie do okna nie trzeba nawet ladowac swojego kodu.
wystarcza kilka nieudokumentowanych komunikatow.
czyzby byl to efekt wtrorny zamknietego kodu aplikacji? tzn.
braku jawnosci zrodel?
Grzegorz Szyszlo - 19 Sie 2002, 04:34
Hmm - co do pcoa - to nie jestem pewien
czy jest to najlepsze zrodlo informacji jakichkolwiek a
juz napewno nie dot. bezpieczenstwa. Ale przeczytalem caly
watek i z tego co na szybko widze:
1. Nie wypowiadala sie tam zadna osoba ktora
ma doswiadczenie jako programista Windowows,
2. Zdania czy jest to dziura exploitowalna czy nie
sa podzielone.
Hmmmm..... to dlaczego zwykle "milczacy microsoft" i tym razem milczy,
czego efektem jest ze calkowicie wycofal sie z tego interfejsu
w technologii dot.net ? czy sam ten fakt nie jest niepokojacy?
Bronek Kozicki - 19 Sie 2002, 05:45
czego efektem jest ze calkowicie wycofal sie z tego interfejsu
w technologii dot.net ? czy sam ten fakt nie jest niepokojacy?
wcale. Interfejs "message pump" jest koszmarnie niewydajny i niestety
nadużywany. To wystarczający powód, żeby się z niego wycofać.
B.
Bronek Kozicki - 19 Sie 2002, 05:54
prawdopodobnie do okna nie trzeba nawet ladowac swojego kodu.
wystarcza kilka nieudokumentowanych komunikatow.
MS01-007 . Czyli gdzieś dzwoni, ale wiadomość jest mocno
przeterminowana. Poza tym - nie każda aplikacja ma swoje okno, a po
drugie większośc usług (z ustawień domyślnych systemu operacyjnego)
jest całkowicie odcięta od komunikatów użytwkonika.
B.
Gadu-Gadu a bezpieczenstwo
'Wysoki poziom bezpieczeństwa' systemu komputerowego.
Podyplomowe Studium Bezpieczeńst wa Systemów IT- PW Wydzial Elek.
2 pytania: dokument polityka bezpieczeñstwa, archiwum listy
E7EEEE EFEEF0EDEE EBEEF8E0E4E8 83021
chemia w naszym BFyciu
odszkodowania czestochowa
felsenbrC3A4u felsenbrC3A4u braune weisse
kolczyk w jezyku watek zbiorczy przekluwanie 250
babia wies
worms 4 demo download
sterowniki do karty 7600gt windows vista 32 bit
2009 11 02
Katalog wypowiedzi z for internetowych ^^ Strona Główna
|
|