Live data from Hacker News

Sandsifter: find undocumented instructions and bugs on x86 CPU

github.com

21–30 of 94 posts

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#21
post #10
post #7

tl'dr of the slides: Found on one processor... instruction Single malformed instruction in ring 3 locks Tested on 2 Windows kernels, 3 Linux kernels Kernel debugging, serial I/O, interrupt analysis seem to confirm Unfortunately, not finished with responsible disclosure No details available [yet] on chip, vendor, or instructions He's found a new f00f bug, winter 2017 is going to be interesting :)

For those not aware: https://en.wikipedia.org/wiki/Pentium_F00F_bug Can these kind of bugs possible to exploit to cause anything more than minor annoyance?

Use them to exploit the system itself - not likely. (Unless they cause some specific bad behaviour rather than a crash) But you can definitely use a DoS issue for other effects. For example if someone is using an auth revokation system which fails open, you could kill that part to use expired credentials. Or if you're able to sometimes inject data, you can keep killing the caching systems until your response is the saved one. (Like in DNS hijack)

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#22
post #3

Also from the same author https://sites.google.com/site/xxcantorxdustxx/visual-re

That looks fun, but the site doesn't seem to have any downloads available?

https://www.reddit.com/r/ReverseEngineering/comments/1izity/...

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#23
This is great. That a program can learn about and exploit the CPU on which it is running from unprivileged userspace reminds me of the notion in Charlie Stross' Accelerando of running a timing attack against the universe to learn about the virtual machine in which we are being simulated.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#24

This is great. That a program can learn about and exploit the CPU on which it is running from unprivileged userspace reminds me of the notion in Charlie Stross' Accelerando of running a timing attack against the universe to learn about the virtual machine in which we are being simulated.

It would be even better if there was a web service that would collect these logs for different processors so everyone didn't have to invest the time to run the analysis.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#25
post #15
post #9

...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?

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 proc…

So basically the same as throwing a 403 instead of 404 for authenticated resources in HTTP :)

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#26
post #19
post #17

Earlier quoted context omitted.

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.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#27
post #14

No instructions there to disable the IME?

If anything, I'd expect such a flag to hide behind MSRs (http://wiki.osdev.org/Model_Specific_Registers)

That's a mostly unused namespace of 2^32 64bit registers. To hide things even better, it would also be possible to change behavior based on officially unrelated registers (eg. MSR $x only acts as IME-switch if the calling address also ends in $y and esi is $z)

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#28
post #15
post #9

...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?

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 proc…

When it comes to discovering possible bugs then there is really no guarantee that the instructions are acting as they should though.

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#29
post #26
post #19

Earlier quoted context omitted.

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.

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)

Re: Sandsifter: find undocumented instructions and bugs on x86 CPU

#30

This is great. That a program can learn about and exploit the CPU on which it is running from unprivileged userspace reminds me of the notion in Charlie Stross' Accelerando of running a timing attack against the universe to learn about the virtual machine in which we are being simulated.

It would be even better if there was a web service that would collect these logs for different processors so everyone didn't have to invest the time to run the analysis.

Well they do mention in the description:

The results of a scan can sometimes be difficult for the tools to automatically classify, and may require manual analysis. For help analyzing your results, feel free to send the ./data/log file to xoreaxeaxeax@gmail.com. No personal information, other than the processor make, model, and revision (from /proc/cpuinfo) are included in this log.

Post reply on HN