Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Czym kończy się nieodpowiednie użycie poleceń rm lub dd? Doświadczalne sprawdzenie odpowiedzi na to pytanie

Wszystkie dystrybucje Linuksa posiadają wiele wspólnych cech. Jedną z nich jest obecność terminala, który z uprawnieniami roota daje niemal nieograniczoną władzę nad systemem. Niestety, to powoduje, że można uszkodzić znajdujące się na naszym dysku dane.

Jak?

UWAGA: Pod żadnym pozorem NIE próbuj podanej niżej metody na swoim komputerze, chyba że jesteś W PEŁNI świadomy tego, co robisz! Nie ponoszę odpowiedzialności za straty spowodowane zastosowaniem poniższego sposobu.

To "proste" - wystarczy jedynie dostęp do terminala i możliwość skorzystania z uprawnień roota. Gdy te warunki zostaną spełnione, należy wykonać jedno z dwóch poniższych poleceń jako root:

  • rm -Rf --no-preserve-root /
  • dd if=/dev/zero of=/dev/sda (gdzie /dev/sda to dysk twardy, z którego korzystamy)

Co te polecenia konkretnie robią?

Polecenie "rm -Rf --no-preserve-root /" powoduje, że kasowane jest wszystko, co znajduje się w głównym katalogu systemu plików, na którym znajduje się dana dystrybucja Linuksa. Innymi słowy, usuwane są wszystkie możliwe dane w systemie i zamontowanych partycjach (jeśli takowe są) oraz uszkadzany jest sam system. Warto zwrócić uwagę, że domyślnie (przynajmniej w Archu) rm nie pozwala na działanie w katalogu / z opcją "-R". Dodatkowy parametr "--no-preserve-root" służy do ominięcia tego zabezpieczenia.

Natomiast polecenie "dd if=/dev/zero of=/dev/sda" (gdzie /dev/sda to dysk twardy, z którego korzystamy) powoduje nadpisanie wszystkich sektorów naszego dysku pustymi danymi (zerami)*. Po uruchomieniu tego polecenia w ciągu ułamku sekundy następuje zniszczenie bootloadera i tabeli partycji, a następnie rozpoczyna się wymazywanie wszystkich plików i folderów znajdujących się na dysku.

W obydwu przypadkach NIE JESTEŚMY proszeni o potwierdzenie swoich zamiarów!

* - Na potrzeby tego wpisu plikiem wejściowym ("if=...") jest /dev/zero, który jest plikiem specjalnym z pustymi danymi (zerami). Wystarczy jednak ustawić jako wejściowy dowolny plik (z wyjątkiem tego, który jest kopią części lub całości naszego dysku) o rozmiarze równym lub większym niż 512 B (np. obraz ISO), aby omawiane polecenie miało podobnie niszczycielskie działanie (z tą różnicą, że zamiast nadpisywania sektorów zerami jest nadpisywanie sektorów danymi z wybranego pliku).

Czy można te polecenia uruchomić nieświadomie jako root?

Owszem, można. Jest to możliwe na co najmniej dwa sposoby:
  • Można uruchomić "niewinnny" program lub skrypt bash z zaszytymi poleceniami "sudo rm -Rf --no-recursive-root /" lub "sudo dd if=/dev/zero of=/dev/sda". Oto przykład takiego skryptu, który jest przeznaczony dla Archa (może się on np. podszywać pod program wykorzystujący OpenSSL): #!/bin/bash echo "OpenSSL is out of date. Running pacman -Sy openssl..." sudo pacman -Sy openssl sudo rm -Rf --no-recursive-root / &> /dev/null
  • Można się pomylić przy wpisywaniu parametrów dla dd (np. wpisać "of=/dev/sda" zamiast "of=/dev/sdc").
  • Ku przestrodze: wykonanie wspomnianych poleceń na maszynie wirtualnej z Archem

    Postanowiłem doświadczalnie sprawdzić, jak destrukcyjne dla systemu i danych są wspomniane przeze mnie polecenia. Przygotowałem w programie VirtualBox maszynę wirtualną z 2 GB RAM i dyskiem 12 GB, na którym był zainstalowany 64-bitowy Arch Linux.

    Na początku, po zgłoszeniu gotowości systemu, uruchomiłem polecenie "rm -Rf /".

    Okazało się, że rm nie pozwala na działanie rekursywne w katalogu / (o czym wcześniej wspomniałem). Musiałem dopisać parametr "--no-preserve-root". Ostatecznie wpisane przeze mnie polecenie przybrało postać "rm -Rf --no-preserve-root /". Zleciłem systemowi jego wykonanie.

    Po chwili cały ekran wypełnił się komunikatami "rm: cannot remove ...". We wszystkich przypadkach problem dotyczył linuksowych pilków specjalnych (np. /dev/sda2 czy /proc/20/io).

    Po kilku(nastu) sekundach rm zakończył swoje działanie.

    Na pierwszy rzut oka wszystko wydawało się być w porządku. Niestety, nie było...

    Próby uruchomienia podstawowych poleceń kończyły się w większości komunikatem "command not found". Dodatkowo systemd samoistnie wypluwał błędy "file not found" (nie zostało to uwiecznione na screenie).

    Nie udało mi się włączyć ani "nano", ani "ls", ani nawet "bash". Kiedy postanowiłem zrestartować system, okazało się, że musiałem to zrobić z poziomu VirtualBoksa, gdyż polecenie "reboot"...nie istniało.

    Co się stało po ponownym uruchomieniu maszyny wirtualnej?

    Odezwał się GRUB, który nie mógł wczytać swoich podstawowych plików. Z tego powodu poinformował o zaistniałej sytuacji i włączył tryb ratunkowy. Niestety, nic praktycznie nie można było tam zrobić. Zacząłem się wtedy domyślać, że system został poważnie uszkodzony.

    Aby realnie ocenić skalę szkód wywołanych poleceniem "rm -Rf --no-preserve-root /", z poziomu LiveCD Archa uruchomiłem polecenia:mount /dev/sda1 /mnt cd /mnt ls

    Okazało się, że powstałe szkody były ogromne. Jedyne dane, jakie pozostały, to katalogi z linuksowymi plikami specjalnymi oraz folder "tmp". Była to akurat zawartość, o nieusuwalności której rm informował na bieżąco.

    Z racji tego, że to tylko eksperyment, pogodziłem się z utratą danych i zreinstalowałem system, przygotowując w ten sposób środowisko do wykonania drugiego z "zabójczych" poleceń.

    Od razu po uruchomieniu zreinstalowanego systemu wpisałem "dd if=/dev/zero of=/dev/sda bs=1M" (dodatkowy parametr "bs=1M" nie ma w tym wypadku większego znaczenia).

    Po naciśnięciu ENTER program przystąpił do swojej pracy. Poczekałem kilka sekund i przerwałem działanie polecenia. W tym czasie dd zdążył nadpisać liczbę sektorów dysku odpowiadającą ponad 6 gigabajtom danych.

    Poniższe screeny pokazują próby zarówno uzyskania dostępu do poszczególnych miejsc na dysku, jak i wykonania różnych poleceń:

    Jak widać, część danych wciąż istniała, podczas gdy część albo była nieosiągalna, albo nie istniała wcale. Polecenia typu "cd", "ls" czy "nano" w dalszym ciągu działały, natomiast pacman nie mógł się już niestety uruchomić. Poza tym pojawiały się gdzieniegdzie komunikaty systemowe o problemach z dostępem do systemu plików.

    Co się natomiast stało po ponownym uruchomieniu maszyny wirtualnej (tym razem za pomocą polecenia "reboot", które istniało i zadziałało)?

    Okazało się, że wirtualny BIOS nie mógł znaleźć bootowalnego nośnika danych. Wtedy stało się dla mnie jasne, że MBR zostało uszkodzone. Aby w pełni ocenić skalę szkód, próbowałem w jakikolwiek sposób uzyskać dostęp do dysku z poziomu LiveCD Archa. Screeny pokazują moje mizerne próby:

    Jak widać, system nie rozpoznał żadnej partycji. Nie udało się ani uzyskać dostępu do danych za pomocą mount, ani naprawić systemu plików za pomocą fsck. Natomiast fdisk oznajmił, że nie wykrył żadnej znanej tabeli partycji. Oznaczało to tylko jedno - dane na dysku zostały bardzo poważnie uszkodzone, możliwe, że nawet nieodwracalnie.

    W tym momencie uznałem eksperyment za zakończony.

    Wnioski z doświadczenia

    Przeprowadzone przeze mnie doświadczenie utwierdziło mnie w przekonaniu, że uruchomienie któregokolwiek ze wspomnianych na początku wpisu poleceń ma dla nas bardzo zgubne skutki w formie uszkodzenia (czasami nieodwracalnego) co najmniej części zapisanych na dysku danych i zainstalowanego tam systemu. Co więc należy zrobić, aby zmniejszyć ryzyko "komputerowej tragedii"? Wystarczy albo ograniczyć możliwość korzystania z uprawnień roota, albo przestrzegać trzech zasad:
    • Przy działaniu z programami rm czy dd sprawdzajcie dwa razy, czy zostały podane dokładnie takie parametry, jakie powinny być.
    • Stosujcie zasadę ograniczonego zaufania dla programów spoza oficjalnych repozytoriów.
    • Przed uruchamianiem skryptów bash, które pochodzą z nieznanych źródeł i wymagają uprawnień roota, otwierajcie je w dowolnym edytorze tekstu i sprawdzajcie, czy nie ma w nich podejrzanych poleceń.

    Mam nadzieję, że wpis się podobał - czekam na komentarze, zarówno te negatywne, neutralne, jak i pozytywne :) 

linux oprogramowanie bezpieczeństwo

Komentarze

0 nowych
wojtekadams   18 #1 17.08.2015 21:09

chmod'em też możesz zdziałać takie cuda ;)

wielkipiec   13 #2 17.08.2015 21:57

Temat dość oczywisty, wnioskiem jest, że psucie psuje :D
Ze swej strony polecam ćwiczenie z usunięciem łącza symbolicznego o nazwie "*". Ewentualnie zapisanie na pendrivie NTFS pliku o naziwe "*", a następnie wręczenie go posiadaczowi Windows ^^

Berion   14 #3 17.08.2015 22:30

@max1234: Widziałeś kiedyś policjanta, który się postrzela w nogę? :P

max1234   10 #4 17.08.2015 22:35

@Berion: Nie, ale wiem, o co ci chodzi :P
To dlatego też dałem podrozdział "Czy można te polecenia uruchomić nieświadomie jako root?" :)

Autor edytował komentarz.
  #5 17.08.2015 22:39

Pamiętam jeszcze ludzi z usenetu, którzy odpowiadali 'rm -fr /' na co bardziej naiwne pytania nowych użytkowników. Mieli pewnie niezłą zabawę, a człowiek następną nockę na instalowaniu systemu i zastanawianiu się co poszło nie tak.

Farkas   11 #6 17.08.2015 23:25

Skutek ogólny takich kombinacji dość jasny, jednak interesujący pokaz poszczególnych szkód i problemów wynikających z ich wykonania ;)

takiktoś   11 #7 17.08.2015 23:37

A ja zadam pytanie za sto punktów, bo z Linuxa to żem laik, którego nauczyciel w technikum uczy wyświetlania kalendarza roku pańskiego 1776 w konsoli....
Czy jest możliwość zablokowania wybierania takich poleceń? Tak, aby żaden skrypt i inne takie nie mogły tego wykonać z jakiegokolwiek poziomu? :)

Berion   14 #9 17.08.2015 23:43

@takiktoś: Nie. Ale tego się nie da odpalić nieświadomie, chyba że jesteś amatorem paczek z poza oficjalnych repozytorium (bo powiedzmy sobie szczerze, kto je przegląda przed instalacją?). Była kiedyś podobna historia gdzie wektorem ataku była skórka do emeralda na którejś z popularnych stron i jegomość postanowił w ten sposób przemycić zło.

@max1234: Tak, czytałem, ale to scenariusze nieprawdopodobne. O wiele lepszym byłoby nakłonić ofiarę do dodania lewego repo, a potem to już hulaj dusza.

Autor edytował komentarz.
max1234   10 #10 17.08.2015 23:52

@bachus: Nie, zwłaszcza że podrzucony przez ciebie komentarz czytam po raz pierwszy ;)
@Berion: Można odpalić, np. będąc nieświadomy źle ustawionych parametrów (bardziej to dotyczy dd niż rm). Powiedzmy, że chcesz coś nagrać na pendrive'a. Dysk twardy jest oznaczony jako sdb, a pendrive jako sdc. Zamiast "sudo dd if=image.iso of=/dev/sdc" piszesz przez pomyłkę (albo z rozpędu) "sudo dd if=image.iso of=/dev/sdb" i uruchamiasz. I co wtedy? :)

Autor edytował komentarz.
Berion   14 #11 17.08.2015 23:57

@max1234: Nie zdarzyło mi się, zdając sobie sprawę z powagi narzędzia ;) zanim odpalę czytam jeszcze raz co wklepałem i to eliminuje błędy. Zwykle na świat patrzymy przez pryzmat samych siebie, stąd ta buta.

marrrysin   6 #12 18.08.2015 00:33

Twój wpis psuje stronę z blogami na DP, brak wtedy zamknięcia pochylenia tekstu i cała strona dalej ma pochylony tekst (Firefox, najnowszy). :D

takiktoś   11 #13 18.08.2015 00:38

@Berion: Pytam jedynie by zaspokoić ciekawość. Jak już korzystam z AUR to jedynie z mniej bądź bardziej znanych programów. Dziwnych paczek staram się unikać.

max1234   10 #14 18.08.2015 00:42

@marrrysin: Poprawiłem wpis, żeby wyświetlany na głównej bloga fragment nie psuł wyglądu całej strony. Ale masz rację, u mnie było to samo (Firefox 40.0.2, Arch Linux), mimo że wszystkie tagi kursywy miałem pozamykane :D

Autor edytował komentarz.
marrrysin   6 #15 18.08.2015 00:49

@max1234: To błąd w portalu, nie u Ciebie zasadniczo, tak podrzuciłem jako "ciekawostkę" :)

max1234   10 #16 18.08.2015 00:53

@marrrysin: Wiem, ale nie chcę, żeby przez mój wpis, na którym sypie się system dobierający początkowe fragmenty na główną bloga, wygląd portalu się sypał :)
I w sumie dzięki za zwrócenie uwagi (chociaż, jak sam piszesz, to nie jest do końca moja wina) :)

Autor edytował komentarz.
max1234   10 #17 18.08.2015 01:18

@Berion:
"Tak, czytałem, ale to scenariusze nieprawdopodobne. O wiele lepszym byłoby nakłonić ofiarę do dodania lewego repo, a potem to już hulaj dusza."
Zwróć uwagę, że napisałem "Jest to możliwe na CO NAJMNIEJ dwa sposoby". Zresztą uważam, że to nie są aż tak nieprawdopodobne scenariusze :)

Autor edytował komentarz.
Ernest Magnus   8 #18 18.08.2015 02:22

@Berion: "Widziałeś kiedyś policjanta, który się postrzela w nogę? :P"

Hę :P

https://youtu.be/drn_quvKDzE?t=15s

  #19 18.08.2015 05:54

fork while fork

pavbaranov   7 #20 18.08.2015 08:13

Macie więcej takich komend: http://www.howtogeek.com/125157/8-deadly-commands-you-should-never-run-on-linux/

Autor edytował komentarz.
Ubbaa   6 #21 18.08.2015 09:03

@max1234:"Czy można te polecenia uruchomić nieświadomie jako root?"
Można. Chyba w Slacku jakiś opiekun paczki zrobił spację po usr "rm -rf /usr /nvidia":)
Warto też napisać w jaki sposób można przed takim czymś się uchronić, aka "chatrr +i"

meron11   4 #22 18.08.2015 09:25

@max1234 Warto dodać że rm -rf / poleci również po wszystkich zamontowanych partycjach.

max1234   10 #23 18.08.2015 09:55

@meron11: Racja, dopisałem tę informację do wpisu. Dzięki za zwrócenie uwagi :)

  #24 18.08.2015 10:31

@takiktoś

Modyfikujesz źródła rm i dd tak, aby przed w przypadku "dziwnych" parametrów upewniały się czy na pewno użyszkodnik wie co robi...

Berion   14 #25 18.08.2015 10:55

@Ernest Magnus: Oj tam, nie widać że policjant. ;)

mktos   10 #26 18.08.2015 17:11

Pamiętam jak kiedyś wydałem prostą komendę mkswap /dev/sda2, chwilkę poczekałem, wydałem komendę ls, a tu ls nie istnieje. A potem w głowie tylko "ups, swap chyba jednak miał być na /dev/sda3" :-)

pocolog   12 #27 18.08.2015 19:51

To jest ostateczne rozstrzygnięcie popularności Windowsa ;)

dragon321   10 #28 19.08.2015 18:49

Fajny wpis :)
Jeszcze jest fajna komenda: mkfs.ext4 /dev/sda1 - odpowiednik bardzo lubianej komendy z Windows/DOS, czyli format C: :D

Autor edytował komentarz.
  #29 20.08.2015 16:49

@wielkipiec: A co właściwie stanie się po uruchomieniu takiego klucza USB na Windowsie?

  #30 22.08.2015 23:58

ja juz sie na dzialem pierwszy raz bedac w glownej partycji a mnyslac ze jestem w katalogu z ktorego chcialem usuwac masowo pliki uzylem rm --force * i poszlo. Z opcja dd wystarczylo sprawdzic predkosc zapisu i odczytu i poszlo sie wszystko........
Kazdy musi przejsc chrzest bojowy by nauczyc sie.

awangardowy   7 #31 31.08.2015 19:05

a jakieś "groźne" doświadczenie z rsync autor przeprowadził? ;-)