[HN Gopher] Undocumented x86 instructions to control the CPU at ...
___________________________________________________________________
Undocumented x86 instructions to control the CPU at the
microarchitecture level [pdf]
Author : ingve
Score : 86 points
Date : 2021-07-07 19:19 UTC (3 hours ago)
(HTM) web link (raw.githubusercontent.com)
(TXT) w3m dump (raw.githubusercontent.com)
| Chilinot wrote:
| Interesting, the conclusion only speculates that this can have
| security consequences. Anyone with better understanding that
| could provide an example of what would be possible to do using
| these instructions?
| dmitrygr wrote:
| anything! if you can get them to execute. the authors found one
| way to enable them, but others may exist (we do not know).
| maybe another secret instruction enables these also. we do not
| know.
| d3k wrote:
| It should be possible to see if a given "secure" binary makes
| use of a given microcode instruction. If that is the case, it
| could be possible to use udbgrd/udbgwr to modify the microcode
| instruction to do something else, e.g. to store some register
| data in the URAM or the SRAM. By doing this you should be able
| to "spy" the data the "secure" binary is processing.
| TeeMassive wrote:
| https://www.youtube.com/watch?v=_eSAF_qT_FY
| garaetjjte wrote:
| See also (2018, for old VIA cpu):
| https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mo...
| sabas123 wrote:
| Except that these latest findings are actually undocumented
| instead of known debug instructions (albeit still technically
| impressive)
| sivizius wrote:
| Very interesting, but irrelevant for most of us.
| babesh wrote:
| Should we be able to scan binaries for these instructions? I
| guess an exploit should be able to call these instructions.
| duskwuff wrote:
| These instructions only work if the CPU is in a particular,
| unusual state ("Red Unlocked"); even then, they require a value
| to be written to a MSR, which is a privileged operation. It's
| highly unlikely that there is any way to activate this
| functionality from userspace. Indeed, it's not clear that it's
| possible to activate without physical intervention (e.g. JTAG
| access).
| ipython wrote:
| But in the paper they explicitly test the possibility that
| the undocumented instructions could be speculatively executed
| and have visible side effects.
|
| They found that the instructions are actually executed, but
| they couldn't jump to arbitrary microcode (a side effect of
| one of the undocumented instructions) because of a single
| lfence ucode op. They proved that at least on the atom
| processor they could unlock, the speculative execution of the
| undocumented instruction calculated an offset and placed it
| in internal registers even though the instruction was
| executed from the "green" (normal) operating mode.
| dmitrygr wrote:
| no way - x86 has no instruction alignment requirements, so the
| same bytes could be an immediate in some innocuous instruction.
| Also the same bytes can be run two ways in x86 and this is
| sometimes used. Plus, code can be created dynamically on almost
| all platforms except iOS.
|
| so in short: no
| CalChris wrote:
| That would help but self modifying code after a stack smash
| could still JIT them.
| ori_b wrote:
| Keep in mind: in a variable length instruction set like x86,
| you can jump into the middle of an instruction, and have it
| interpreted as another instruction. If you have
| mov $0x123, %r16
|
| you can think of it as a sequence of bytes, which
| (oversimplified) encodes to something like:
| 0: $0xb8 # opcode for mov 1: $0x10 # destination
| register 2: $0x23 0x01 0x00 0x00 # constant
|
| if you jump to address 2, you're in the middle of your
| constant. If that constant happens to be a malicious opcode,
| you're screwed.
|
| So you can't just decode instructions starting from the program
| entry to find out if an opcode is trying to execute malicious
| code. You need to find all possible paths, including all
| computed jumps, to make that decision.
| ericbarrett wrote:
| What about CET and the ENDBR64/32 instructions? Isn't there a
| "shadow stack" as well? Not sure if this is possible with a
| modern x86 OS, but it also wouldn't surprise me if there were
| workarounds either.
| retrac wrote:
| It's particularly bad with x86 due to the enormous variety of
| encodings and prefixes accumulated over the last half-century
| in the architecture. For example, the two instructions:
| mov rax, [table + rax*8] mov [table + rax*8], rax
|
| plus some lookup tables make a Turing-complete subset:
| https://drwho.virtadpt.net/files/mov.pdf (With jumping via
| conditional faulting done with an invalid MOV, of course.)
| There are many other subsets. And even C compilers targeting
| them: https://github.com/xoreaxeaxeax/movfuscator
|
| Even better, there are multiple encodings of those
| instructions. And even better than that, there are Turing-
| complete subsets comprised only of printable ASCII
| characters. And even better than that, there are subsets of
| x86 the instruction set that can masquerade as _readable
| English text_ : https://news.ycombinator.com/item?id=16312317
|
| If your program counter ever diverges off to start executing
| unsanitized user data on x86, you are potentially pwn'd.
| sabas123 wrote:
| The chance you're pwn'd is really unlike as generating
| these kinds of binaries are nearly impossible.
| im3w1l wrote:
| I know that in the past legitimate programs did obfuscations
| like this for anti-piracy reasons. But do they still? Or can
| it nowadays be considered a red flag?
| nostrademons wrote:
| That's sounds like one of those tasks that's isomorphic to
| the halting problem. Replace the malicious opcode sequence
| with "HALT" and your static analyzer can determine whether an
| arbitrary program can halt, something known to be impossible.
| bqmjjx0kac wrote:
| The halting problem concerns deciding whether _any_ program
| will halt.
|
| It's definitely possible to decide whether some programs
| will halt.
| fooker wrote:
| Look up 'Posts Correspondence Problem' which is almost like
| this problem and is probably equivalent to the halting
| problem.
| olliej wrote:
| this is actually something various JITs have to deal with as
| it provides an attack vector for loading shell code
| sabas123 wrote:
| Regular compilers also deal with this now as well. They try
| to avoid generating an ENDBR as an argument when possible
| IIRC.
| dang wrote:
| _Undocumented x86 instructions to control the CPU at the
| microarchitecture level [pdf]_ -
| https://news.ycombinator.com/item?id=27764806 - July 2021 (27
| comments)
| tinktank wrote:
| How do people find these instructions?
| 1-6 wrote:
| Perhaps someone accidentally left the doors open on the Atom
| CPU which allowed them to run a disassembler.
|
| "In mid-2020, our team managed to extract microcode for modern
| Atom processors that are based on the Goldmont
| microarchitecture. It became possible to do this on Atom
| Goldmont systems-on-chip (SoCs) due to an arbitrary code
| execution vulnerability in Intel CSME (Intel-SA-00086)."
| x0re4x wrote:
| Probably using something like that:
| https://github.com/xoreaxeaxeax/sandsifter
| sabas123 wrote:
| They have been reverse engineering Atom for over half a decade
| (possibly longer) now.
| thricegr8 wrote:
| In case anybody doesn't feel comfortable downloading a PDF within
| the context of the title :)
|
| https://github.com/chip-red-pill/udbgInstr/blob/main/paper/u...
| ori_b wrote:
| Turns out that opening it in the browser downloads it too.
___________________________________________________________________
(page generated 2021-07-07 23:01 UTC)