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.
Sections
- lang: |
- RSS: |
- About me
- Tools
- → YT YouTube (EN)
- → D Discord
- → M Mastodon
- → T Twitter
- → GH GitHub
Links / Blogs
- → dragonsector.pl
- → vexillium.org
- Security/Hacking:
- Reverse Eng./Low-Level:
- Programming/Code:
Posts
- Paged Out! #5 is out,
- CVEs of SSH talk this Thursday,
- Debug Log: Internet doesn't work (it was the PSU),
- FAQ: The tragedy of low-level exploitation,
- Solving Hx8 Teaser 2 highlight videos!,
- Gynvael on SECURITYbreak podcast,
- Paged Out! #4 is out,
- I won't be able to attend CONFidence'24 after all :(,
- xz/liblzma: Bash-stage Obfuscation Explained,
- Two of my bookmarklets: image extraction and simple TTS,
- → see all posts on main page
// copyright © Gynvael Coldwind
// design & art by Xa
// logo font (birdman regular) by utopiafonts / Dale Harris
/* the author and owner of this blog hereby allows anyone to test the security of this blog (on HTTP level only, the server is not mine, so let's leave it alone ;>), and try to break in (including successful breaks) without any consequences of any kind (DoS attacks are an exception here) ... I'll add that I planted in some places funny photos of some kittens, there are 7 of them right now, so have fun looking for them ;> let me know if You find them all, I'll add some congratz message or sth ;> */
Vulns found in blog:
* XSS (pers, user-inter) by ged_
* XSS (non-pers) by Anno & Tracerout
* XSS (pers) by Anno & Tracerout
* Blind SQLI by Sławomir Błażek
* XSS (pers) by Sławomir Błażek
// design & art by Xa
// logo font (birdman regular) by utopiafonts / Dale Harris
/* the author and owner of this blog hereby allows anyone to test the security of this blog (on HTTP level only, the server is not mine, so let's leave it alone ;>), and try to break in (including successful breaks) without any consequences of any kind (DoS attacks are an exception here) ... I'll add that I planted in some places funny photos of some kittens, there are 7 of them right now, so have fun looking for them ;> let me know if You find them all, I'll add some congratz message or sth ;> */
Vulns found in blog:
* XSS (pers, user-inter) by ged_
* XSS (non-pers) by Anno & Tracerout
* XSS (pers) by Anno & Tracerout
* Blind SQLI by Sławomir Błażek
* XSS (pers) by Sławomir Błażek
Comments:
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: