Hacker News new | ask | show | jobs
by d33 3252 days ago
...isn't the usability of the tool limited because it's running in userspace, which has fewer privileges in terms of what instructions can be ran?
2 comments

I was wondering this myself until I read the pdf:

> For effective results, the injector should be able to identify instructions in more privileged rings, even if it cannot actually execute those instructions.

>This approach allows the injector to detect even privileged instructions: whereas a non-existing instruction will throw a #UD exception, a privileged instruction will throw a #GP exception if the executing process does not have the necessary permissions for the instruction. By observing the type of exception thrown, the injector can differentiate between instructions that don’t exist, versus those that exist but are restricted to more privileged rings. Thus, even from ring 3, the injector can effectively explore the instruction space of ring 0, the hypervisor, and system management mode.

So basically the same as throwing a 403 instead of 404 for authenticated resources in HTTP :)
When it comes to discovering possible bugs then there is really no guarantee that the instructions are acting as they should though.
As the slides say, this approach prevents the system from falling over entirely, while still resolving instructions from deeper rings.
Makes sense. I was thinking if there could be a bootable fuzzer of this kind, but you're right that it would be very difficult for it to be both usable and not crash very quickly.
I think once you found all possible instructions it shouldn't be too hard (for someone much smarter then me) to essentially generate a minimal OS that systematically tries out all found instructions from ring 0. That should dramatically reduce the amount of reboots necessary to actually try them all out compared to bruteforcing them from ring 3
What about hangs? I think you'd need a watchdog in order to have the process automated.
Firstly, the paper clearly explains that a userland (ring 3) process can easily discriminate between instructions that do not exist and instructions that the process lacks the credentials to execute simply because the two cases give rise to different exceptions (undefined and general protection, respectively).

Secondly, one could trivially log "I am going to try this" to a file, go ahead and do it, and if the machine crashes you consult the log and read exactly what was about to be done and evidently caused a hang. You don't necessarily need to write a log entry after doing something, in this case you can deterministically log what you are about to do and make deductions therefrom.

I'm sure there are ways to read out a CPU Hang and reset if that happens, if necessary via external hardware^(I'm guessing)^(I don't actually know)
Some enterprise-grade server platforms already have this functionality, it's called a "watchdog". Linux supports this since (at least) 2.4.

I've been using this with HP ProLiant servers and (for me, at least) it has always worked as intended.

For more info, search "linux watchdog timer".

Sure, just have the 'os' ping the external device in N second intervals. Without a ping, reset through a jumper.