SoylentNews is people
SoylentNews
El Reg published an article that describes a clever technique Intel is considering implementing in future CPU designs to prevent certain types of malware infections called Control-flow Enforcement Technology (CET) [PDF], those that use return-orientated programming (ROP) and jump-orientated programming (JOP) to implement exploits:
CET works by introducing a shadow stack – which only contains return addresses, is held in system RAM, and is protected by the CPU's memory management unit. When a subroutine is called, the return address is stashed on the thread's stack, as per normal, and also in the shadow stack. When the processor reaches a return instruction, the processor ensures the return address on the thread stack matches the address on the shadow stack.
If they don't match, then an exception is raised, allowing the operating system to catch and stop execution. Therefore, if exploit code starts tampering with the stack to chain together malicious instructions to install malware or otherwise compromise a system, these alterations will be detected and the infiltration halted before any damage can be done.
Given that these are two of the major techniques used by exploit authors to perform arbitrary code execution, being able to block such attempts through hardware could make digital life a little bit safer.
(Score: 4, Interesting) by coolgopher on Sunday June 12 2016, @02:53AM
In a former project we were tasked with implementing replacement firmware for certain comms cards deployed to hundreds of thousands of units. The new firmware was needed for regulatory compliance, and due to cost- or time-reasons not merely corners had been cut from the original firmware. Rather than actually doing anything comms related, said firmware pretty much only supported a framed serial "update protocol". And when I say "supported", I mean that in the sense of "if on a sunny day with the stars properly aligned and the right number of goats sacrificed, it may be possible to communicate with the old firmware to do an upgrade". Said state was really only available after the card had been reset, but the hardware designers had for some unfathomable reason not included a way of reset or power cycle the comms board (w.t.f.?!). There were further undocumented hardware errata that made it even more challenging to talk to the board, but that's for another story.
So, what does one do when faced with a board in an unknown state with no obvious way of rebooting it? Well, as it turns out, the serial receive routine for the framed messages wasn't doing proper bounds checking on the length field, so with a carefully crafted message it was possible to execute a stack smash against the board. From memory I used a two-pronged attack, first to attempt overwriting the return address with the address to the reset vector, and second, as a fallback, to trigger an access to an unmapped memory region which would result in an unhandled exception, and via that also a reset. This allowed us to successfully do firmware upgrades on boards in nearly any state (the only exception being if they had interrupts closed, but that was never observed).
This is the one and only time I've legitimately used a stack smash. Of course, if people had done their job properly originally (hardware and firmware), this would never have been needed. Makes for a fun anecdote though.