0:39
2/3/2013

Sprawdźcie sami: odpalcie sudo -k, potem przestawcie zegarek na 1970-01-01 01:00:00, a następnie wydajcie komendę sudo su — powinniście zostać rootem.

Ominięcie potrzeby uwierzytelnienia przez reset czasu

Powyższy błąd w sudo pozwala osobom, które uzyskają np. fizyczny dostęp do komputera na wykonanie dowolnego polecenia (z tych, które mogą wykonywać sudoersi) bez konieczności uwierzytelnienia się (tj. podania hasła do sudo).

sudo

sudo

Na ataki szczególnie narażeni są użytkownicy Ubuntu i Mac OS X — dlatego że na tych systemach dość często korzysta się z sudo, a atak niestety zadziała tylko na tych kontach użytkowników, którzy kiedyś przynajmniej raz skorzystali z sudo.

Na czym polega dziura?

Kiedy użytkownik korzysta z sudo, tworzony jest plik timestamp (znacznik czasowy), pozwalający na wykonywanie poleceń bez potrzeby ponownego uwierzytelniania się przez 5 minut. Polecenie sudo -k, do którego użycia nie jest wymagane uwierzytelnienie się, resetuje tenże timestamp do czasu epoki (1970-01-01 01:00:00) …a przestawienie zegarka (które na niektórych dystrubucjach nie wymaga podania hasła roota) do czasu epoki sprawia, że znów wracają nam moce “uwierzytelnionego sudo”, czyli de facto jesteśmy rootem :-)

Sudo

Sudo

Błąd dostał numerek CVE i został poprawiony w sudo w wersjach 1.8.6p7 oraz 1.7.10p7.

TL;DR Atak na sudo zadziała jeśli:
– masz dostęp fizyczny do maszyny i możesz na niej zmienić czas bez konieczności podania hasła (OS X w domyślnej konfiguracji)
– użytkownik, który się nie wylogował skorzystał w przeszłości z sudo

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

71 komentarzy

Dodaj komentarz
  1. Na Debianach domyślnie nie da się bez uprawnień zmieniać zegarka więc strachu nie ma :)

    • Na OSX można “zakłódkować” :>

    • Pod żadnym normalnym systemem nie można. (Co to znaczy, że „przestawienie zegarka (…) z reguły nie wymaga podania hasła roota”? Na prawdę są takie systemy?)
      Ale czy systemu nie można obejść? To że ani Ty ani ja nie znamy żadnego sposobu żeby taki atak wykonać, nie znaczy przecież że się nie da. No bo czy na przykład używasz uwierzytelniania NTP?
      Cieszmy się więc, że nie ma praktycznych implikacji, ale to nie znaczy że podatność nie istnieje.

    • “Ale czy systemu nie można obejść? (…) No bo czy na przykład używasz uwierzytelniania NTP?”
      Ciężko winić system za to, że użytkownik postanowił używać a) zewnętrznego, b) niepewnego źródła czasu.

      Zawsze można sobie czas synchronizować po GPS/DCF-77 i dalej mieć paranoję, bo irańskie wojsko może nam spoofować sygnał. ;)

    • A jakby tak zmienić czas w BIOSie? Aż musze to u kumpla sprawdzić.

    • Niektóre systemy mają zabezpieczenie przed gwałtownymi zmianami czasu przez NTP. Np. taki Windows XP

    • Na debianach w ogóle nie ma włączonego sudo, od tego
      zacznijmy. Poza tym oczywiście to co napisałeś jest
      prawdą.

  2. OK, jak ktoś ma zmienić ustawienie zegarka w systemie.. nie będąc uprzednio root’em? Oraz… już wcześniej używał sudo (do korzystania z uprawnień root’a), to chyba jest nieco za późno, żeby się martwić.. tym bardziej, jeśli nadal może przestawić zegar w systemie…

  3. Wypróbowaliście to aby? Bo na moim Mincie 13 który jest de facto Ubuntu 12.04 ten trik nie działa, sudo cały czas chce hasło, wersja 1.8.3p1. Z tego co zauważyłem jest już update do sudo (co prawda ta sama wersja, ale inna “rewizja”, czy jak się to tam nazywa), Canonical (jak z resztą całe środowisko OS) zawsze bardzo szybko reaguje na takie luki nie czekając na żaden “biuletyn bezpieczeństwa”, tylko poprawiając i wystawiając poprawiony pakiet.

  4. “Powyższy błąd w sudo pozwala(…)”
    Jak dla mnie, to nie jest błąd w sudo, tylko w Ubuntu i Mac OS X. W normalnych systemach datę ustawia się jako root, bo jest to zmiana dotycząca działania całego systemu, a nie preferencji pojedynczego użytkownika.

    • 1. Zmiana daty, po za wkurzaniem ew. innych użytkowników nie niesie *SAMA W SOBIE* żadnych niebezpieczeństw i nie zakłóca działania systemu (po za tym, że ktoś może sobie zmienić datę i wkurzać innych userów, że np. jest 2086 rok ;)).
      2. To jest błąd w sudo, nie w logice, bo zmiana daty *SAMA W SOBIE* jak już powiedziałem po za potencjalnym wkurzaniem innych osób korzystających z komputera nie niesie żadnych implikacji bezpieczeństwa.
      3. Przed tym można się zabezpieczyć wrzucając skrypcik synchronizujący czas po NTP do crona, żeby się np. co kilka minut odpalał i ustawiał poprawny czas (wyjątek: komputery bez dostępu do sieci).

    • “bo zmiana daty *SAMA W SOBIE* jak już powiedziałem po za potencjalnym wkurzaniem innych osób korzystających z komputera nie niesie żadnych implikacji bezpieczeństwa.”

      Pierwsze z brzegu: cron i atd – jeden user może mieć w ten sposób wpływ na wykonywanie (bądź nie) zaplanowanych zadań innego użytkownika.

      Niby nie bezpośrednie niebezpieczeństwo, ale zwykły user nie powinien mieć możliwości wpływania na działanie programów drugiego zwykłego usera, a tym bardziej roota i całego systemu (crontab roota).

    • @Supertux: Bardzo się mylisz. Np. taki dovecot, któremu zmienisz datę się najczęściej zamknie, bo czasy zmiany skrzynek mają wartość krytyczną dla niego. Systemy autoryzujące operują na bieżącym czasie, który nie ma prawa się cofnąć o więcej niż 1-2 godziny localtime (zmiana strefy, ale nie zmienia się UTC).
      Możesz też zakłócić działanie syslogów logujących wg dat, co przyda się przy np. zaciemnieniu włamania.
      W ramach pracy domowej znajdź sobie mnóstwo przypadków, gdzie zmiana daty wpłynie krytycznie na system.

  5. Teraz troche gdybania, poprawcie mnie jeśli pisze głupoty. Z tego co wiem to system bierze czas z płyty głównej ( z Real-Time Clock). Co jeśli przestawie taki zegar z poziomu BIOS’u/UEFI ? Czy linuxy na których do zmiany hasła potrzeba root’a dalej będą takie bezpieczne?

    • Jak masz fizyczny dostęp do kompa to nie musisz kombinować z sudo.

    • 1. jakiś Live Linux
      2. chroot i passwd
      3. done

  6. @Pawel, @Dexi: po uzyskaniu dostepu do BIOSu rownie dobrze mozna uzyc systemu z zewnetrznego nosnika/single user mode.

  7. A można przestawić czas w biosie bez rebootu? Bo o ile
    wiem, to normalny system w czasie rebootu kasuje pliki
    sudo.

  8. “Tandetne” Ubuntu 12.04: Co prawda czas zmieniłem bez
    hasła, co zaraz poprawię ale sudo su bez niego nie działa. “Sorry,
    try again.” ;-)

  9. Na Ubuntu 12.10 nie działa. Nadal wymagane jest hasło dla
    roota

  10. Wczoraj Canonical wydał aktualizację pakietu sudo. W
    repozytoriach Ubuntu 12.04 są dostępne dwie wersje pakietu:
    1.8.3p1-1ubuntu3 (precise) – wersja podstawowa 1.8.3p1-1ubuntu3.4
    (precise-updates) – aktualizacja Jak już powiedział Razi, Canonical
    szybko wydaje aktualizacje na błędy 0 day.

  11. Nie wiem po co te kombinacje. Przejęcie kontroli nad komputerem mając do niego fizyczny dostęp jest równie spektakularne co włamanie się do domu za pomocą dynamitu – jest dużo prostszych i bardziej skutecznych sposobów żeby zdobyć roota, chociażby boot z innego urządzenia czy konsola awaryjna, gdzie roota mamy na dzień dobry.

    • W większości przypadków rzeczywiście to jest najmniejszy
      problem. Z drugiej strony w ten sposób możesz wykonać atak w
      kilkanaście sekund. A ile zajmie Ci rozłożenie na czynniki pierwsze
      komputera jeśli BIOS jest również zabezpieczony?

    • +1/like dla tego Pana. Podpisuję się obiema rękami i nogami.

    • Tak, zwłaszcza przy jednoczesnym stosowaniu LUKS/dmCrypt…

    • @random
      Szyfrowanie partycji systemowej stosują chyba tylko masochistyczni paranoicy, a to właśnie tam trzymane są informacje o użytkownikach i ich uprawnieniach, a ich edycja jest dziecinnie prosta. Zaszyfrowanie partycji systemowej nie rozwiązuje wcale problemu, po prostu przestaje to już być dziecinnie proste.

    • Nie szyfrowanie partycji systemowej to g*** nie szyfrowanie. Nie można mówić o prywatności jeśli nie mamy pewności że środowisko nie zostało zmodyfikowane. Chociażby w celu przejęcia hasła do chronionych zasobów. Nie jest to masochizm, to tylko jedno hasło przy starcie systemu, a mamy pewność integralności danych. pozdrawiam

    • Jeśli jest to atak na sudo, jest szansa, że powiedzie się również przy zdalnym logowaniu (np przez SSH), a zatem może być nieco bardziej niebezpieczny. Nie testowałem takiego flow, ale o ile z terminala również można zmienić datę bez hasła, to nie widzę przeszkód.

    • @random
      Szyfrowanie partycji systemowej zabija wydajność systemu. Poza tym przed niczym nie chroni – boot i tak musi być nieszyfrowany, a tam sobie wrzucić możesz co chcesz, np kernel z wkompilowanym keyloggerem. Jak ktoś jest paranoikiem, to niech lepiej nie rozstaje się z komputerem, zamiast tworzyć sobie iluzję bezpieczeństwa szyfrowaniem czego się da :)
      Poza tym o czym my mówimy – osoba, która szyfruje dysk, nie będzie zostawiała włączonego i niezabezpieczonego hasłem komputera gdzie popadnie.

    • Rob006 – jakieś wyniki na poparcie tezy, że szyfrowanie systemowej zabija wydajność? :)

    • Co prawda nie jestem rob006, ale mogę potwierdzić. Kiedyś zaszyfrowałem partycję systemową w OpenSuSE (+ /home) i system ładował mi się 2 razy dłużej. Nie chodzi o samo bootowanie, ale też KDE się 2x dłużej odpalało, GIMP, KDEnLiVE, LMMS, etc. Zrezygnowałem z tego, bo i tak nie mam nic cennego na dysku (żadnych planów nowego źródła energii czy informacji na temat jak się kosmici ujawnią ;)), a to co mam to głównie rzeczy hobbystyczne, których raczej nie spieniężnię.

    • Czysta logika w połączeniu z moimi doświadczeniami po zaszyfrowaniu home. :]
      Poza tym zanim zdecydowałem się na zaszyfrowanie partycji domowej zbadałem trochę temat i wszyscy odradzali szyfrowanie partycji systemowej. Tym bardziej że sensu nie widzę – nie mam tam żadnych wrażliwych danych, a nie uważam się za kogoś na tyle ważnego, aby stać się ofiarą wymierzonego ataku (przed którym i tak by mnie to nie uchroniło). :D

    • Dalej proszę o dane/dowody, a nie empiryczne “bo inni tak mówili”. Tak się rodzą plotki.

      Co do szybkości, pracownikom, którzy narzekali na to, że mają wolne komputery w pewnej firmie zaaplikowany skrypt na starcie systemu wyświetlający następujące linie:

      Optymalizuje system plików……….
      Unowocześniam tabele danych………
      Przyśpieszam składniki systemowe….
      Włączam tryb szybkiej pracy………
      System przyśpieszono o {tu losowa wartość z (30,70)%}

      …i oczywiście nie zrobiono niczego ponad to. Opinie pracowników – no teraz działa zdecydowanie szybciej. Niektórzy sami włączali ten skrypt w trakcie dnia ;)

    • Pisałem, że opierałem się na własnych obserwacjach, i nie chodzi tu tylko o wychwytywanie różnic “na czuja” – opierałem się na wykresach zużycia procesora i szybkości odczytu/zapisu przy np kopiowaniu dużych plików albo skanowaniu większych ilości danych. Responsywność też była zauważalnie gorsza, i to tylko przy zaszyfrowaniu home. Jak chcesz konkretne liczby, to mogę ci na poczekaniu jakieś wymyślić, :) ale mi naprawdę nie zależy, żeby kogoś przekonać – szyfrujcie sobie co chcecie i kiedy chcecie. :]

    • Kwestia tego czym/w jaki sposób szyfrujesz :p

    • “Co do szybkości, pracownikom, którzy narzekali na to, że mają wolne komputery w pewnej firmie zaaplikowany skrypt…” no to fajnych mają pracowników w tej “pewnej firmie” ;-) poza tym to też nie dowód na to ze faktycznie tak było. Konkrety proszę! jaka firma nazwiska pracowników ;-))

  12. Mint 13 – muszę podać hasło, żeby zmienić datę, tak więc
    nawet jeśli działa to trochę teoretyczny ten atak :)

  13. Nie ma to jak nie używać sudo.

  14. Debian unstable/testing: xxxxxx@yyyyyy:~$ sudo -V Sudo
    version 1.8.5p2 Sudoers policy plugin version 1.8.5p2 Sudoers file
    grammar version 41 Sudoers I/O plugin version 1.8.5p2
    xxxxxx@yyyyyy:~$ sudo -k xxxxxx@yyyyyy:~# date -s “1970-01-01
    01:00:00” xxxxxx@yyyyyy:~$ sudo su [sudo] password for xxxxxx:
    Sorry, user xxxxxx is not allowed to execute ‘/bin/su’ as root on
    yyyyyy.

  15. Nie pamiętam wersji Ubuntu w której czas zmieniałoby się bez uprawnień roota więc wprowadzacie w błąd, szczególnie, że na pewno nie ma takiej możliwości na wszystkich aktualnie wspieranych wersjach tego systemu.
    Błąd bardzo głupi, chociaż rozwiązanie wydaje się najprostsze.

    • Faktycznie – nie da się jeśli próbujesz to zrobić przez Administracja/Czas i Data. Wtedy musisz wpisać hasło, żeby cokolwiek zrobić. Natomiast jak na pasku klikniesz na wyświetlaną datę i dasz zmodyfikuj, to system nawet się nie zająknie o hasło tylko łyknie wszystko co wklepiesz. Ubuntu 10.04, wsparcie ma chyba jeszcze przez miesiąc. Nie mów “na pewno” jeśli nie sprawdziłeś wszystkich możliwości.

  16. irth@VinylScratch:~$ sudo su
    (sudo) password for irth:
    irth nie występuje w pliku sudoers. Ten incydent zostanie zgłoszony.

    //zamienilem nawiasy kwadrotowe na () by nie wycielo
    //uzywam su -c :P

  17. Eee, u mnie nie działa na OSX (Lion):

    $ date 010101001970
    date: bind: Permission denied
    date: settimeofday (timeval): Operation not permitted

    • A żeby zmienić datę z poziomu okna dialogowego, musiałem kliknąć w kłódkę i zostałem i tak zapytany o hasło.

      A więc nie działa raczej na OSX Lion, może znowu Montain Lion jest bardziej podatny?

    • Domyślnie z UI można zmienić datę bez podania hasła: http://ne0.pl/$ZTs**/

    • Na Mountain Lion też chce hasło przed zmianą.

    • Domyślnie nie ma kłódki, jak sobie włączysz to masz. Ja nie miałem.

  18. A jak nie mam polecenia sudo, tylko su?

  19. Co za bzdury

    autorze wymień mi JEDNĄ dystrybucję gdzie można zmienić czas systemowy bez roota

    • Może być kilkadziesiąt? Prosto od znalazcy błędu: http://www.securityfocus.com/bid/58203/info

    • Dystrybucje w linku to jakieś starocie. Raczej nie znajdziemy obecnie dystrybucji która pozwoli na zmianę daty bez hasła roota. Nie wiem jak jest na jabłecznikach.

    • debian linux… 2.2, 3.0, 3.1

      Wooo to ktoś tych wersji jeszcze używa? Nawet wśród swoich archaików znalazłem najstarszego 4.0.

    • Co nie zmienia faktu, że w 4.0 jest podatna wersja sudo.

    • Debiana 4 nie ma na liście więc jest to dość ciekawe. Ale w sumie Debian 4 to dość stara wersja, szczególnie w przypadku Debiana gdzie “apt-get dist-upgrade” załatwia wszystko więc zdziwiłbym się gdyby ktoś trzymał jeszcze nieaktualnego Debiana. Wersje RedHata na liście to jakaś archeologia, Mandriva? – ktoś jeszcze tego używa, to jeszcze istnieje?

    • Szanowny autorze chociaż widziałeś listę tych dystrybucji? o_O

      To jakbyś dziś się czepaił błędów w win 3.11 a ’95….

    • @Piotr
      Czepiał? Wydaje mi się, że autor zauważa i opisuje tylko a nie czepia się.

    • *to jakbyś opisywał błędy w win 3.11

  20. wystarczy mieć dostęp fizyczny i dojście do biosu żeby zmienić datę. Linux po reboocie synchronizuje zegar systemowy ze sprzętowym.

  21. Najciekawsze że błąd polega na użyciu magicznego numerku. Ilu programistów przejechało się na magicznych wartościach -1, 0, max itd? Workaround zawsze się zemści.

  22. “Dalej proszę o dane/dowody, a nie empiryczne “bo inni tak mówili”. Tak się rodzą plotki.

    Co do szybkości, pracownikom, którzy narzekali na to, że mają wolne komputery w pewnej firmie zaaplikowany skrypt na starcie systemu wyświetlający następujące linie:

    Optymalizuje system plików……….
    …”

    Jak zwykle konstruktywnie Panie Piotrze. Ładny skrypt, bardzo ładny :). Pozdrawiam.

  23. na moich jablkach nie działa (mac book pro i mini). ale oba mają mountajn liona po upgrade od leopard. na vmware esxi 5 z konsoli tez nie.

  24. Na kubuntu dzisiaj dostałem aktualizację sudo poprawiajcą
    ten błąd.

  25. Ta zmiana czasu bez roota to wszystko wina córki Linusa, jakby nie dzwoniła ze szkoły do taty że potrzebuje roota by zmienić czas i podłączyć się do wifi szkolnego to Linus nie sugerowałby programistom suse popełnienie samobójstwa. (cytuję: by świat był lepszy)

    http://www.theregister.co.uk/2012/02/29/torvalds_tantrum_opensuse/

  26. Do tego co szyfruje dysk i mu “muli”: czas kupić komputer który wspiera AES sprzętowo (procesor), lub nie używać egzotycznych algorytmów tylko sprzętowo wspieranych.

    Na moim i5 nie widzę różnicy czy jest zaszyfrowany czy nie. Wydajność szyfrowania to ponad 2.5GB/s (zmierzona). Zmieniając algorytm na nieobsługiwany sprzętowo, wydajność spada nawet do 30-50MB/s

    Szyfrowanie dla szyfrowania to takie Security przez Obscurity, najpierw poczytaj o co w tym chodzi a nie narzekasz że czegoś nie rozumiesz.

    • >wspiera AES sprzętowo (procesor), lub nie używać
      egzotycznych algorytmów tylko sprzętowo wspieranych. jak dla mnie
      AES jakoś mocno popularny sie zrobił xD panie AES jest nie ma
      strachu coraz mniej mnie przekonuje. A co do samego szyfrowania to
      i5 2500 obsługuje kaskadowe aes-twofish bez najmniejszej zadyszki i
      spadków wydajności.

  27. Na laptopie mam obecnie Ubuntu 12.10, KDE 4.9.5, sudo 1.8.5p2 i cały czas prosi o hasło. Dodałem nawet użytkownika do sudoers, nadal prosi o hasło.

  28. testowałem na paru gentoo i nic z tego… chyba to co ktos wyzej pisal zgodze sie ze to jedynie zadziala na Ubuntu i Mac OS/X

    • To nawet na Ubuntu nie chce działać, więc pozostaje jeszcze tylko MacOS ;)

    • To dziura chyba z czasów windowsa 98 także dziś nigdzie nie będzie działać

      autora poniosła fantazja z tekstem że to działa na paru dystrybutcjach

  29. na Xubuntu 12.04 się nie da. przy opcji zmiany daty i czasu jest kłódka. Sudo wersja 1.8.3p1, czyli podatna na takie ataki. no cóż, nigdy nie wykluczałem dziur w jakimkolwiek systemie. z dziurą czy bez, żyje się dalej.

  30. A mi pomimo nowozainstalowanego i uaktualnionego Ubunto 12.04.2 LTS 64 -bit znów nie mogę się wylogować z roota :-(. Tak więc poprawka nie działa. Stało się to prawdopodobnie po resecie przy braku możliwość wpisania hasła na ekranie logowania.

Odpowiadasz na komentarz Piotr

Kliknij tu, aby anulować

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

RSS dla komentarzy: