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: 3, Interesting) by frojack on Saturday June 11 2016, @07:06PM
But is there ever a valid reason for stack smashing?
Its an honest question because I've only ever heard the phrase with regard to a form of attack.
No, you are mistaken. I've always had this sig.
(Score: 2) by BsAtHome on Saturday June 11 2016, @07:14PM
Well, "smashing" may not be the best description when you intentionally manipulate the stack pointer and contents. However, the point is that it is a shear impossible task to distinguish between intentional and non-intentional. The CPU does not know what the programmer intended to do and is in a terrible position to make decisions.
Therefore, you have normally two philosophies, you always allow stack changes or you never ever allow stack changes. Tacking on a "fix" on a system that allows stack changes it like trying to empty the sea with a small bucket.
(Score: 2) by frojack on Saturday June 11 2016, @07:32PM
shear impossible task to distinguish between intentional and non-intentional. The CPU does not know what the programmer intended to do
True, I believe we are in agreement here. Smashing isn't what either of us are thinking about. Instead we mean some corner cases that some programmers
and some compilers may use to "optimize" returns when they know they are 18 calls deep, and don't want to back track through all of them to get back to
where they started. So they start popping the stack.
The description in TFS suggests this new only happens on a RET instruction, but clearly this also must trap jmp instructions that push stuff onto the stack.
The intentional manipulation of the stack would use some forms of push / pop / peek operations, none of which would be shadowed by the processor.
No, you are mistaken. I've always had this sig.
(Score: 2) by krishnoid on Saturday June 11 2016, @08:32PM
How about a combination of:
This way (I think -- I'm rusty on this), presuming assembly code from a structured programming language, and not hand-coded:
I suspect the corner programming cases for this would be even more corner-y, but I think (?) this would cover many situations.
(Score: 2) by Aiwendil on Saturday June 11 2016, @09:34PM
Polymorphic/selfmodifying code.
Also it's pretty rare when at highlevel but is a fairly common trick at lowlevel (or when you work under restrictions in term of code or speed) - but in the world of "lets throw more hardware at it" there are very little reason for it.
Also - could be handy if you want to install linux on a gamingconsole ;)
(Score: 0) by Anonymous Coward on Saturday June 11 2016, @10:33PM
They're trying to plug the rooting hole, knowing every chip manufacturer will follow suit and license Intel's patent.
This is all about corporations retaining control of our computers, not 'providing security for the owner of the system.'
Intel already has unerasable signed ME code that has bus level access to the network at all times. Imagine when the next bios updates come out that require cryto signed bios in order to even boot (they already did it on some of the 'maker' embedded boards, see coreboot for references. Required getting your key/bios signed by intel in order to boot on your device.)
It is not much of a stretch to imagine this on all consumer available hardware in the near future. Doesn't even require the government to make obvious laws disallowing it, the steady march of progress takes care of that, as long as the back room pacts ensure the hardware is suitably locked down over time.
I scoffed at Continuum when it came on the air as being too fictiony. By the time it had ended it didn't seem too farfetched.
(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.