W sierpniu br. w Stanach Zjednoczonych odbyła się znana konferencja bezpieczeństwa komputerowego DEF CON 31, na której nie zabrakło polskiego akcentu. Podczas swojego wystąpienia Adam "pi3" Zabrocki i Alex Tereshkin z firmy NVIDIA zaprezentowali ponad 20 błędów w modułach BMC. Jednemu z nich przyjrzymy się w poniższym artykule.
OpenBSD stawia sobie za cel bycie najbezpieczniejszym systemem operacyjnym na rynku. Implementuje on wiele ciekawych metod mitygacyjnych, m.in. jako pierwszy domyślnie wspierał ASLR (Address space layout randomization) i PIE (Position-independent executables). Jemu również zawdzięczamy projekty takie jak sudo czy OpenSSH. Gdy w 2019 roku została opublikowana luka bezpieczeństwa CVE-2019-19521, wiele osób przecierało oczy z niedowierzaniem, że taki błąd uwierzytelnienia może pojawić się w systemie operacyjnym kładącym tak duży nacisk na bezpieczeństwo.
W artykułach z tej serii piszemy o tym, że oprogramowanie, które miało być bezpieczne, w rzeczywistości okazywało się podatne na ataki. Niektóre narzędzia, takie jak ping(8), istnieją w systemach operacyjnych od bardzo wczesnych lat. Podatność w tym programie może wywołać wiele emocji, ale czy każdy błąd oznacza kompromitację systemu?
Kiedy ktoś nas zapyta, jakie oprogramowanie uważamy za bezpieczne, jednym tchem wymieniamy takie programy jak OpenSSH, OpenVPN i sudo. Gdy w jednym z nich pojawia się poważny problem, świat administratorów trzęsie się w posadach. Dziś przyjrzymy się błędowi, który istniał w sudo. Co ciekawe, eksploit na tę podatność zmieści się w jednej wiadomości na Twitterze i zostanie jeszcze sporo miejsca do podzielenia się swoją opinią na jego temat.
W systemach operacyjnych istnieją mechanizmy, które początkowo nie miały nic wspólnego z bezpieczeństwem. Z czasem jednak dostrzeżono w nich potencjał i zaproponowano bazujące na nich rozwiązania. Takim przykładem jest wywołanie systemowe chroot(2). Dziś przyjrzymy się programistycznym błędom związanym z tym wywołaniem systemowym.
Na niektóre błędy bezpieczeństwa natrafimy we frameworkach dostarczonych do danego języka. Innym razem podatności można znaleźć w samej aplikacji. Zdarza się również, że błąd znajduje się w implementacji interpretera języka. Dziś przyjrzymy się właśnie takiemu przypadkowi.
Jednym z najpopularniejszych języków programowania jest dziś Java. Wiele dużych firm (takich jak banki czy te z gałęzi E-commerce) decyduje się na tworzenie aplikacji właśnie w nim. Dodatkowo jest to główny język programowania na platformie Android. Natomiast sam język to nie wszystko. Potrzebne są do niego także biblioteki. W tym artykule przyjrzymy się, jak poważny w skutkach może być błąd w najpopularniejszej, napisanej w Javie, bibliotece służącej do logowania zdarzeń. Czy eksperci przesadzali, okrzykując go najpoważniejszym błędem w ostatniej dekadzie?
OpenSSL jest najpopularniejszą biblioteką kryptograficzną na świecie. Jednym z podstawowych jej zastosowań jest obsługa protokołu TLS/SSL, powszechnie wykorzystywanego w Internecie. Niestety jakość kodu tej biblioteki pozostawia wiele do życzenia, co jest dość zaskakujące, biorąc pod uwagę fakt, że jest ona jednym z fundamentów zapewniających bezpieczeństwo sieci. O wątpliwej jakości kodu świadczy błąd CVE-2014-0160, potocznie nazywany Heartbleed, umożliwiający wykradanie poufnych informacji. W 2014 roku podatność ta zdobyła nagrodę Pwnie Awards w kategori najlepszy błąd po stronie serwera. Heartbleed zapoczątkował całą serię nowych inicjatyw mających na celu poprawę jakości kodu biblioteki OpenSSL.
Na rynku dostępnych jest wiele edytorów tekstów, a różnorodność i mnogość ich funkcjonalności może przytłaczać. Niestety, i w nich znajdziemy podatności, a jeżeli ten sam edytor ma wiele zastosowań – od środowisk programistycznych po edycję e-maili, błędy mogą okazać się bardzo dotkliwe.
W dzisiejszych czasach użytkownicy bardzo rzadko budują oprogramowanie ze źródeł. Dużo częściej korzystają z systemów do zarządzania pakietami. Takie systemy wykorzystują wcześniej przygotowane artefakty, które są pobierane i rozpakowywane na komputerach użytkowników. To podejście znacząco skraca czas potrzebny do instalacji bądź aktualizacji oprogramowania. Należy jednak zwrócić uwagę na pewną znaczącą kwestię dotyczącą bezpieczeństwa: skąd użytkownik ma pewność, że instalowane przez niego oprogramowanie zostało zbudowane bez żadnych złośliwych modyfikacji?