Uciekając z sudo – część druga
Napisał: Patryk Krawaczyński
18/10/2014 w Bezpieczeństwo Brak komentarzy. (artykuł nr 462, ilość słów: 683)
W poprzedniej części omówiliśmy niebezpieczeństwo przyznawania podwyższonych uprawnień do programów, które posiadają możliwość uruchamiania powłoki systemowej. Zanim przejdziemy do kolejnego problemu poleceń wykonywanych za pomocą sudo wróćmy jeszcze na chwilę do programu less
. Dopełniając poprzedni wpis warto nadmienić, że umożliwia on również uruchomienie innych zewnętrznych programów np. edytora za pomocą polecenia “v”
v – Invokes an editor to edit the current file being viewed. The editor is taken from the environment variable VISUAL if defined, or EDITOR if VISUAL is not defined, or defaults to “vi” if neither VISUAL nor EDITOR is defined. See also the discussion of LESSEDIT under the section on PROMPTS below.
lub wczytania innych plików systemowych za pomocą polecenia :e [plik]
.
Examine a new file. If the filename is missing, the “current” file (see the :n and :p commands below) from the list of files in the command line is re-examined. A percent sign (%) in the filename is replaced by the name of the current file. A pound sign (#) is replaced by the name of the previously examined file.
Czy istnieje możliwość ograniczenia tego typu programów, aby nie uruchamiały dodatkowych poleceń? W przypadku polecenia less
wystarczy nadać zmiennej systemowej LESSSECURE
wartość 1, w celu wyłączenia wszystkich niebezpiecznych funkcjonalności:
When the environment variable LESSSECURE is set to 1, less runs in a "secure" mode. This means these features are disabled: ! the shell command | the pipe command :e the examine command. v the editing command s -o log files -k use of lesskey files -t use of tags files metacharacters in filenames, such as * filename completion (TAB, ^L) Less can also be compiled to be permanently in "secure" mode.
Pierwszym krokiem jest globalne ustawienie zmiennej “LESSSECURE” w tryb tylko do odczytu dla wszystkich użytkowników. W przeciwnym wypadku użytkownik za pomocą polecenia unset
może usunąć tą zmienną przed uruchomieniem polecenia “less”. Możemy to osiągnąć poprzez dodanie do ścieżki w systemie /etc/profile.d pliku o nazwie np. lesssecure.sh i zawartości:
LESSSECURE=1 readonly LESSSECURE export LESSSECURE
Drugą czynnością jest wymuszenie na programie sudo, aby zmienna “LESSSECURE” została zachowana dla użytkownika, jeśli wszystkie inne zmienne są resetowane. Osiągnąć to możemy dodając opcję env_keep w pliku sudoers
:
Defaults env_reset, env_keep=LESSSECURE
W przypadku innych programów niż “less” – uruchamianie zewnętrznych plików wykonywalnych może zostać zablokowane poprzez dodanie tagu NOEXEC
(działa tylko jeśli program sudo został skompilowany z jego obsługą i tag posiada też wsparcie od strony systemu operacyjnego):
%users ALL = NOEXEC: /usr/bin/less /etc/named.conf
Kolejną pułapką przy przyznawaniu uprawnień “sudo” są prawa dostępu do plików i katalogów. Jeśli prawa dostępu są zbyt “szerokie” użytkownik systemu może obejść złudne ograniczenia. Na przykład użytkownik “splunk” posiada możliwość uruchomienia za pomocą sudo skryptów start.sh, stop.sh oraz restart.sh w ścieżce “/opt/splunk/
“. Niestety, jeśli uprawnienia do katalogu będą, jak te poniżej:
$ ls -ld /opt/splunk drwxr-xr-x 2 splunk splunk 4096 Oct 3 13:58 /opt/splunk
Użytkownik splunk może bez większego problemu wykorzystać ten fakt do spreparowania zawartości dowolnego skryptu:
$ mv /opt/splunk/restart.sh{,.bak} $ ln -s /bin/bash /opt/splunk/restart.sh $ sudo /opt/splunk/restart.sh [sudo] password for splunk: # id uid=0(root) gid=0(root) groups=0(root)
To samo tyczy się symboli wieloznacznych (ang. wildcards) – szczególnie tych z gwiazdką (*). Wpis w pliku sudoers
typu:
agresor ALL= (root) /bin/less /var/log/*
potrafi wygenerować, co najmniej dwie drogi ucieczki:
$ sudo less /var/log/../../etc/shadow
oraz
$ sudo less /var/log/dmesg /etc/shadow
Gdzie w drugim przykładzie możliwe jest użycie kombinacji klawiszy “:n
“, co w less przechodzi do kolejnego pliku z wczytanej listy. Nieprawidłowe prawa dostępu oraz używanie wildcardów, których nie do końca rozumiemy może być dość destrukcyjne w skutkach. Przy tego typu zezwoleniach należy mieć na uwadze nie tylko skrypty i programy, dla których podwyższamy uprawnienia, ale także ich otoczenie, a filtry typu *
lepiej zastąpić dokładną walidacją wprowadzanych danych.