G

dy sudo jest skonfigurowane tak, aby umożliwić użytkownikowi uruchamianie poleceń jako dowolny użytkownik za pomocą słowa kluczowego ALL w sekcji “uruchom jako” (ang. Runas) możliwe jest uruchomienie poleceń jako administrator systemu (root) podając ID użytkownika jako wartość -1 lub 4294967295. Może to być użyte przez użytkownika z wystarczającymi uprawnieniami sudo do uruchamiania poleceń jako root, nawet jeśli w sekcji “uruchom jako” jest wyraźny zakaz dostępu do uprawnień tego użytkownika. Jest to tylko możliwe, o ile słowo kluczowe ALL jest wymienione jako pierwsze w specyfikacji Runas. Wpisy dziennika dla uruchomionych w ten sposób poleceń będą wyświetlać docelowego użytkownika jako 4294967295 zamiast root. Ponadto moduły PAM nie będą uruchamiane dla polecenia.
[ czytaj całość… ]

L

uka została ujawniona podczas zgłoszenia błędu na githubie. systemd nie potrafi obsłużyć odpalenia procesu użytkownika, którego login zaczyna się od liczby np. 0day i tym samym uruchamia proces z prawami administratora zamiast owego użytkownika. Brzmi to dość drastycznie:

> In case of bug report: Expected behaviour you didn’t see
The process started by systemd should be user previlege

> In case of bug report: Unexpected behaviour you saw
The process started by systemd was root previlege

[ czytaj całość… ]

W

programie sudo wykryto poważną lukę w kodzie, która umożliwia uzyskanie uprawnień administratora przez każdego użytkownika posiadającego dostęp do powłoki shell. Działa ona również na systemach z włączoną obsługą SELinux (CentOS / RHEL). Wystarczy, że lokalny użytkownik posiada w systemie uprawnienia do uruchomienia dowolnego polecenia za pośrednictwem sudo. Daje mu to możliwość eskalacji swoich uprawnienia do poziomu administratora.
[ czytaj całość… ]

G

dyby kogoś zdziwiły wpisy z przeszłości w logach np. dotyczące różnego rodzaju zadań wykonywanych w dość małych odstępach czasowych to nie należy się stresować:

May 19 18:55:01 darkstar CRON[7328]: (test) CMD (/bin/echo "test")
May 15 07:45:01 darkstar CRON[7942]: (test) CMD (/bin/echo "test")
May 19 19:05:01 darkstar CRON[7945]: (test) CMD (/bin/echo "test")
May  9 10:55:01 darkstar CRON[8563]: (test) CMD (/bin/echo "test")
May  4 18:50:01 darkstar CRON[8880]: (test) CMD (/bin/echo "test")
May 19 19:35:01 darkstar CRON[9819]: (test) CMD (/bin/echo "test")
May  9 19:45:01 darkstar CRON[10093]: (test) CMD (/bin/echo "test")
May 19 19:40:01 darkstar CRON[10143]: (test) CMD (/bin/echo "test")

Bug do Ubuntu zgłoszony już w 2015 roku, ale jakoś team rsyslog’a nie pali się do jego poprawienia.

Dlaczego nigdy nie należy zostawiać komputera bez jego blokady!

[agresor@darkstar ~]$ date
ptk  1 mar 20:29:14 2013 CET
[agresor@darkstar ~]$ sudo -k

Przestawiamy datę systemową na: 01-01-1970 01:00:00 za pomocą preferencji daty i czasu…

[agresor@darkstar ~]$ date
czw  1 sty 01:00:03 1970 CET
[agresor@darkstar ~]$ sudo su
[root@darkstar]#

Sprawdzone na Mac OS X 10.7.5. Prawdopodobnie działa również z systemami Linux wyposażonymi w Gnome / KDE, które pozwalają zmianę daty bez uprawnień administratora.

Więcej informacji: hukl twitter, sudo bug