T

owarzystwo Historyczne Uniksa (ang. Unix Historical Society) niedawno otrzymało i udostępniło kopię raportu technicznego Bell Labs z 1984 roku autorstwa Jamesa Allena zatytułowanego: “/bin/sh: Największa luka w zabezpieczeniach Uniksa” (ang. /bin/sh: The Biggest Unix Security Loophole). W czasach, gdy powstawał ten raport Unix był jeszcze znakiem towarowym AT&T Bell Laboratories. Z samego abstraktu możemy dowiedzieć się, że wówczas osoby zajmujące się łamaniem zabezpieczeń określało się terminem “crackerzy”. Mieli oni mieć wiele sposobów, aby stać się superużytkownikami w systemie Unix. Jednak autor wyodrębnił dwie główne klasy luk. Klasa pierwsza składała się z wielu tajemnych i trudnych do wykonania “sztuczek”. Druga klasa to jeden, łatwy sposób, z którego każdy mógł skorzystać bez problemu. Cały raport skupił się w głównej mierze na drugiej klasie. W szczególności na prawowitych poleceniach systemu (takich jak: mail, troff itp.), działających z uprawnieniami superużytkownika, które mogły zostać zmuszone do nieumyślnego wykonywania poleceń w powłoce systemowej. W praktyce raport pokazał, jak wiele programów posiadających bit setuid było napisanych w niedbały sposób zapewniając wspomnianemu crackerowi luki, których potrzebował, aby eskalować swoje uprawnienia. Poniżej znajduje się wolne tłumaczenie:
[ czytaj całość… ]

J

eśli nie używasz dockera z pomocą docker-machine (standardowo na systemie OSX oraz Windows) to może dojść do sytuacji, gdy polecenia dockera doprowadzą do przejęcia hosta na którym zostały uruchomione. Jeśli dodamy naszego użytkownika systemu do grupy dockera lub zmienimy uprawnienia do gniazda sieciowego – to Twój użytkownik lub szkodliwe oprogramowanie będzie mógło uzyskać uprawnienia administratora bez konieczności podawania hasła.
[ czytaj całość… ]

Sebastian Krahmer z SUSE Security Team odkrył lokalny exploit w systemd v228. Przez ten błąd użytkownik znajdujący się w podatnym systemie jest w stanie podnieść swoje uprawnienia do roli administratora. Patrząc na sedno błędu z wysokiego poziomu proces ten jest dość prosty:

1) Systemd używa wartości -1 do reprezentacji nieprawidłowej wartości mode_t (praw dostępu do systemu plików)
2) Przez przypadek wartość ta jest przekazywana podczas tworzenia (open) nowego pliku, co w rezultacie dawało nam plik z ustawionymi wszystkimi bitami dostępu: globalny zapis, globalne wykonanie i najgorsze: setuid dla root.
3) Atakujący może nadpisać ten plik dowolnym programem, ponieważ jest dostępny do zapisu dla wszystkich.
4) Atakujący może wykonać ten plik z wgranym programem, ponieważ jest dostępny do wykonania dla wszystkich.
5) Atakujący wykonuje program z prawami administratora, ponieważ plik posiada setuid dla root.
[ czytaj całość… ]