5/3/2014
Ostatnio Apple zaliczyło podwójnego goto-faila ;) …ale trzeba przyznać, że takich fatalnych błędów bezpieczeństwa, które można było usunąć poprawką w jednej linii kodu było kilka. Oto lista 5 z nich dotyczących X (2006), OpenSSL w Debianie (2008), OpenSSL (2008), Android (2010), Tarsnap (2011).
Chcecie się pochwalić jakimś swoim fuckupem? :-)
Nie mój, ale epicki i klasyk ;)
http://sudokode.net/~tim/bumblebee/
Piękne.
Średnik za for()’em się liczy? :)
To nie jest dziura tylko zwykły bug. Po czymś takim ci się przecież kod nie skompiluje :)
jak sie nie skompiluje? jasne ze tak i trudne do znalezienia
dlatego trzeba uzywac klamerek
@Zacheusz – Klamerki nie pomogą, przynajmniej w C[++]. for(…); { … } jak najbardziej się skompiluje. Blok wyznaczony klamrami to normalny statement w gramatyce języka – nie musi znajdować się po instrukcji kontroli sterowania. I tak, czasami taki wolnostojący blok się przydaje – RAII. ;)
@Zacheusz
Nie musisz tego znajdywać, średnik bez sensu po klamrze nie spowoduje żadnego błędu, to jest tak jakby pusta instrukcja. Nic się nie stanie.
@wral:
Średnik po klamrze jest rzeczywiście nieszkodliwy, natomiast średnik po nawiasie okrągłym zamykającym wyrażenia sterujące pętlą spowoduje, że wnętrze pętli będzie puste, natomiast następujący po takim nieszczęsnym średniku blok umieszczony w nawiasach klamrowych (który w zamyśle miał być wnętrzem pętli) zostanie wykonany bezwarunkowo po wyjściu z pętli.
No i właśnie to jest piękno Open Source – takie bugi są znajdowane szybko. Kod z pewnością był przejrzany przez “gównodowodzących” i w ciągu kilku dni/godzin (raczej to drugie) załatany. Pewnie trzeba było czekać trochę na załatane binarki (chyba że ktoś wszystko z repo sam kompiluje, jak np. ja), ale źródła zostały szybko załatane.
W oprogramowaniu zamkniętoźródłowym takie coś by zapewne latami siedziało. Taki srajdołs ma setki tysięcy dziur, inaczej by wirusów nie było.
W ogóle WinAPI to jest jakiś żart. Umożliwia dostęp do pamięci innych procesów (SetWindowHook i inne), przed vistą to w ten sposób można było się dostać z poziomu aplikacji działającej na prawach ograniczonego usera do procesu aplikacji działającej z prawami admina i bawić się jego pamięcią (odczyt/zapis), a nawet do aplikacji działającej na prawach użytkownika SYSTEM (!). Implikacji chyba nie muszę wyjaśniać.
W Viście to załatali, ale kto wie ile tego typu dziur tam jest i czy na pewno wszystkie “dojścia” załatali?
Czy praktycznie sprawdziłeś możliwość dostania się do pamięci innych procesów z prawami administratora lub systemu, czy tylko o tym czytałeś?
https://niebezpiecznik.pl/post/23-letni-blad-w-x11-xorg/
A grzebanie w innych procesach jest i pod Linuxem – ptrace. Tylko by design nie powinno to pozwalać na dostęp do procesów innego usera, i nie słyszałem o takim bugu w nim.
Mógłbyś poprzeć jakimś źródłem, że przed Vistą można było ot tak grzebać w pamięci procesów innych userów (rzeczywiście pracując na koncie zwykłego usera, nie administratora. Praca na koncie administratora jest jak na roocie, a UAC na tym koncie to IMHO próba obrony usera przed samym sobą.).
z drugiej strony, https://news.ycombinator.com/item?id=7342655 – w komentarzach na HackerNews pod kwestią jednolinijkowego buga w GNUTLS ten temat wzbudził raczej krytyczną wobec mitów FOSS dyskusję