5 ms·

Should we be able to scan binaries for these instructions? I guess an exploit should be able to call these instructions.

• duskwuff 5y ago
  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 5y ago
    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 5y ago
  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 5y ago
  That would help but self modifying code after a stack smash could still JIT them.
• ori_b 5y ago
  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.
  • im3w1l 5y ago
    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 5y ago
    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 5y ago
      The halting problem concerns deciding whether any program will halt. It's definitely possible to decide whether some programs will halt.
      • justinjlynn 5y ago
        This is a really good distinction to make - people use the halting problem as an excuse to avoid doing any sort of analysis because it can't work in general and give a fully definitive answer - but most analysis solutions don't need to be fully general or fully definitive in order to be valuable.