Gdy masz do czynienia z przepełnieniem bufora, zasadniczo mogą się zdarzyć trzy rzeczy. Pierwsza to odmowa usługi. Jak widziałeś wcześniej, bardzo łatwo jest uzyskać błąd segmentacji podczas obsługi pamięci procesu. Jednak możliwe jest, że jest to najlepsza rzecz, jaka może się przydarzyć programiście w tej sytuacji, ponieważ awaria programu przyciągnie uwagę. Drugą rzeczą, która może się zdarzyć, gdy wystąpi przepełnienie bufora, jest to, że EIP może być kontrolowany w celu wykonania złośliwego kodu na poziomie dostępu użytkownika. Dzieje się tak, gdy podatny program działa na poziomie uprawnień użytkownika. Trzecią rzeczą, która może się zdarzyć, gdy wystąpi przepełnienie bufora, jest to, że EIP może być kontrolowany w celu wykonania złośliwego kodu na poziomie systemu lub roota. Niektóre funkcje Linuksa powinny być chronione i zarezerwowane dla użytkownika root. Na przykład, nadanie użytkownikom uprawnień roota do zmiany haseł byłoby ogólnie złym pomysłem. Dlatego też opracowano koncepcje Set-user Identification (SUID) i Set-group identification (SGID), aby tymczasowo podnieść poziom procesu, aby umożliwić wykonanie niektórych plików na poziomie uprawnień ich właściciela i/lub grupy. Na przykład polecenie passwd może być własnością użytkownika root, a gdy wykona je użytkownik bez uprawnień, proces będzie działał jako root. Problem polega na tym, że gdy program SUID/SGID jest podatny, udane wykorzystanie luki spowoduje utratę uprawnień właściciela pliku lub grupy (w najgorszym przypadku roota). Aby program stał się programem SUID, należy wydać następujące polecenie:
Program będzie działał z uprawnieniami właściciela pliku. Aby zobaczyć pełne konsekwencje tego, zastosujmy ustawienia SUID do naszego programu meet. Później, gdy będziemy eksploatować ten program, uzyskamy uprawnienia roota.
Program będzie działał z uprawnieniami właściciela pliku. Aby zobaczyć pełne konsekwencje tego, zastosujmy ustawienia SUID do naszego programu meet. Później, gdy będziemy eksploatować ten program, uzyskamy uprawnienia roota.