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