7:26
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? :-)

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

12 komentarzy

Dodaj komentarz
  1. Nie mój, ale epicki i klasyk ;)

    http://sudokode.net/~tim/bumblebee/

    • Piękne.

  2. Ś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.

  3. 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ę

Twój komentarz

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

RSS dla komentarzy: