Symlink race

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

Symlink race – w bezpieczeństwie teleinformatycznym, termin opisujący atak na uprzywilejowaną aplikację nieprawidłowo przeprowadzającą operacje na plikach.

Szczegóły techniczne[edytuj | edytuj kod]

Celem ataku wykorzystującego zjawisko symlink race jest sprowokowanie uprzywilejowanej aplikacji, takiej jak daemon lub program setuid, do odczytania, zapisania, lub zmiany statusu pliku, do którego użytkownik przeprowadzający atak nie ma normalnie dostępu (np. należących do innych użytkowników).

Symlink race (w polskim tłumaczeniu: wyścig związany z linkami symbolicznymi), to sytuacja, w której programista błędnie zakłada atomowość zachodzących po sobie operacji sprawdzenia statusu pliku oraz operacji na pliku (np. odczyt, zapis, utworzenie, usunięcie).

Przykład[edytuj | edytuj kod]

Proces foo, wykonywany z uprawnieniami superużytkownika tworzy w niebezpieczny sposób plik tymczasowy /tmp/temp, wcześniej sprawdzając czy taki plik istnieje w systemie plików (i w takim przypadku kończąc działanie procesu). Jeżeli atakującemu uda się spowodować wywłaszczenie przez system operacyjny procesu foo i w tzw. międzyczasie stworzyć dowiązanie /tmp/temp do nieistniejącego w tym momencie pliku, np. /etc/cron.d/bar, wtedy wznowiony proces foo utworzy plik /etc/cron.d/bar. Jeżeli atakujący ma wpływ na dane zapisywane do /tmp/temp - np. proces foo jest programem diagnostycznym, indeksującym pliki użytkowników - może dojść do niebezpiecznej sytuacji – eskalacji uprawnień atakującego użytkownika.

Log wywołań systemowych procesu foo:

access("/tmp/temp", F_OK) = -1 ENOENT (No such file or directory) w tym miejscu następuje wywłaszczenie procesu foo, a atakujący tworzy dowiązanie symboliczne /tmp/temp, wskazujące na /etc/cron.d/bar
creat("/tmp/temp", 0300) = 3 plik /etc/cron.d/bar został utworzony, wartością jego deskryptora pliku w ramach procesu jest 3

Obrona[edytuj | edytuj kod]

Obrona przed zagrożeniami powodowanymi przez zjawisko symlink race sprowadza się do używania bezpiecznych kombinacji funkcji. Np. w systemach uniksowych należy korzystać z funkcji open(2) z flagą O_EXCL (lub z jej wrapperów znajdujących się w bibliotece libc, np mkstemp(3)) w miejsce sekwencji wywołań access(2) oraz creat(2).

Warto jednak pamiętać, że nie zawsze obrona ta musi być skuteczna. Przykładem jest sieciowy system plików NFS, dla którego nieuwzględniana jest flaga O_EXCL w wywołaniu systemowym open(2).