Some time ago I had a crazy/funny idea for a local privilege escalation: run a privilege granting operation in an infinite loop and wait for a random bit flip in CPU/RAM that would make a 'can this user do this' check return 'true' instead of 'false'. Is this theoretically possible? Yes. And practically? Almost impossible, due to the unlikeliness of a bit flip and even more, the unlikeliness of a bit flip in the just right place. Nevertheless, I thought this idea was quite interesting and decided to dig into the topic. This post will summarize what I've found out and mention a few papers/posts might be worth reading.

Post dostępny jedynie po angielskiej stronie lustra.

Comments:

2011-06-28 17:03:29 = koptok
{
Maybe during a gamma burst?
}
2011-11-14 15:55:29 = Stasio
{
Z dużo większym prawdopodobieństwem Twój program trafi SEGV. Bo jak zacznie się coś sypać w komputerze to dlaczego akurat miałby to być ten jeden bit, skoro są miliardy innych od których zależy stabilność systemu. Tak więc co to piszesz nie jest to nawet teoretycznie możliwe, bo z miliardy miliardów większym prawdopodobieństwem komputer się po prostu wysypie.
}
2011-11-14 18:52:40 = Gynvael Coldwind
{
@Stasio
Mam wrażenie, że:

1. Nie przeczytałeś całego posta.
2. Nie za bardzo wiesz o czym piszesz :)

Dlaczego tak uważam? Po kolei:

1. Piszesz "miałby to być ten jeden bit"
W poście napisane jest "scan memory for any bit flips", co nie jest dość precyzyjne, ale wskazuje wyraźnie, że chodzi mi o większy obszar pamięci niż jeden bit. Sprecyzuje, że skanowałem obszar o wielkości 2GB, co stanowiło połowę RAMu zawartego w testowym laptopie.

2. Piszesz "Twój program trafi SEGV"
SEGV, a raczej SIGSEGV, to POSIXowa nazwa na błędy związane z dostępem do pamięci (związane z prawami dostępu do stron, segmentami, etc). Jak pisałem w poście, do testów korzystałem z OSAmber, czyli z mojego minimalistycznego bootloadera + mini kernela. OSAmber nie korzysta z pamięci wirtualnej, a segmenty ma ustawione na flat. Do tego maszyna miała 4GB RAMu. Z technicznego punktu widzenia więc, żeby wystąpił błąd dostępu do pamięci typu SIGSEGV, musiało by coś się stać ze segmentami w rejestrach CPU. Natomiast na CPU w żaden sposób nie oddziaływałem. Więc prawdopodobieństwo wystąpienia tego typu błędu było minimalne.

3. "skoro są miliardy innych od których zależy stabilność systemu"
Jak wyżej. OSAmber jest bootloaderem + mini kernelem. W środowisku testowym interrupty były wyłączone, a cały kod ograniczał się do mniej więcej 500 bajtów (+-200). Tak więc, ignorując na chwilę code cache procesora, szansa była 500B/4GB, że się zmieni coś w kodzie który jest wykonywany. Ofc ta szansa jest redukowana jeśli weźmiemy pod uwagę cache. Więc... nie za bardzo wiem o jakich "miliardach innych" piszesz.

4. "Tak więc co to piszesz nie jest to nawet teoretycznie możliwe"
Mylisz "teoretycznie możliwe" z "praktycznie możliwe". Nawet zakładając, że to co napisałeś jest prawdziwe (a nie jest), to teoretycznie możliwość i tak istnieje (tj. prawdopodobieństwo jest niezerowe).

5. "bo z miliardy miliardów większym prawdopodobieństwem komputer się po prostu wysypie."
Ponownie, nie wiem skąd wziąłeś "miliardy miliardów" (dla ułatwienia, miliard miliardów to trylion).
Po drugie, co to znaczy "komputer się wysypie"? Bardzo nieprecyzyjny termin w ogóle nic nie wyjaśniający.

Tak więc... zachęcam do przeczytania posta, tego co napisałem, i przemyślenia sprawy raz jeszcze :)
}

Add a comment:

Nick:
URL (optional):
Math captcha: 9 ∗ 7 + 3 =