Microsoft Announces New 'Hardware-Enforced Stack Protection' Feature (zdnet.com) 36
Microsoft announced today a new security feature for the Windows operating system. From a report: Named "Hardware-enforced Stack Protection," this feature allows applications to use the local CPU hardware to protect their code while running inside the CPU's memory. As the feature's name suggests, its primary role is to protect the (memory) stack -- where an app's code is stored during execution. "Hardware-enforced Stack Protection" works by enforcing strict management of the memory stack through the use of a combination between (1) modern CPU hardware and (2) shadow stacks. The term shadow stacks is a new one and refers to a copies of a program's intended execution flow (also referred to as the code's execution order). The new "Hardware-enforced Stack Protection" feature plans to use the hardware-based security features in modern CPUs to keep a copy of the app's shadow stack (intended code execution flow) in a hardware-secured environment.
Re: (Score:3, Funny)
You do know that they're talking about CPUs, right? The size of which is measured in sub-microns?
Bullshit bingo (Score:5, Informative)
Re:Bullshit bingo (Score:4, Insightful)
Re:Bullshit bingo (Score:5, Insightful)
Re: (Score:2)
You wouldn't have to save the entire stack then, would you? On function call, send the real return address to the protected blob.
That doesn't answer how one actually does a return. Are there special return instructions for accessing the protected blob? I'm not familiar with Intel's architecture but the blurb seems to refer to any "modern" architecture.
This sounds like something cooked up by the marketing dept.
Re: (Score:2)
Yeah it occurred to me shortly after posting that they literally only need to shadow the return addresses if this is what it's doing. I don't think there are any wrinkles with return values (they'd be set literally as part of the return, so no chance to be used for an overflow) or othersuch, but I'm no expert on the calling conventions.
As for the actual return, given normally it would be returning by moving execution to the address held in a certain place in the stack, if some flag is on you just need t
Re: Bullshit bingo (Score:2)
Yes, CPUs have specific call and return ops, but Iâ(TM)d be worried about some more creative performance optimisations being broken by this. For example, Appleâ(TM)s obj-c runtime optimises out reference count increment and decrements that happen at function return by checking if thereâ(TM)s an increment at the return address and jumping straight from before the decrement to after the increment, and popping the stack. Doesnâ(TM)t seem like that kind of thing would be possible in this e
Re: (Score:2)
Yeah, it takes a lot of reading of both the summary and the ZDNet article to finally find out what's being announced. Basically it's the use of shadow stacks, something that's been around for awhile, and even has initial support in compilers like LLVM/Clang since 7.0. A shadow stack puts addresses on a different stack to protect them from being overwritten. There were some issues for the x64, mostly stack-use race conditions, but it's present for aarch64. Intel's CET makes it easier to deal with the rac
Re: (Score:2)
Re: (Score:2)
Re:Bullshit bingo (Score:5, Informative)
WTF is this article summary? It makes no sense. Application code hasn't been running on the stack for over a decade. Non-executable stack has been the default behavior of every sane operating system for ages. Does anyone care enough to provide a real summary, if the article actually has a valid point?
it is explained well enough in the references provided in tfa: https://techcommunity.microsof... [microsoft.com]
for more general info: https://en.wikipedia.org/wiki/... [wikipedia.org]
sorry but it is hard to condense all this in a single sentence for you to grasp with minimal effort, beyond what is already expressed in the summary: protect the execution stack. if you can't bother to even skim-read those sources then you really don't need to know anything about these exploits and the mitigation that is intended by this.
Re:Bullshit bingo (Score:5, Informative)
It's not for applications, it's for improving application security. Against stack-smashing attacks.
You see, the stack contains function return pointers that tell the CPU where execution should resume after a subroutine call. It used to be you could put in shellcode on the stack via a buffer and jump into it, but non-executable stacks block this. But since return pointers aren't executable, a new form of programming called Return-Oriented-Programming (ROP) has emerged. In this case, your shellcode consists of function pointers to subroutines, so the CPU is simply returning from a subroutine, it retrieves the return address and then jumps to that code. That code is usually the tail of some function which lets you set up the stack the way you want, then the next subroutine return will "call" the desired function and parameters.
It's a bit tricky to set up, and requires a sufficiently complex application to have enough functionality to ensure turing completeness.
Things like ASLR help against ROP because they randomize the target addresses, however if you can discover the address of a function in a library, you can use offsets from that to beat ASLR since a library is typicalloy loaded in one big blob. So the start address of the library may be unknown, but once discovered it is easy to figure out the rest.
Using this means ROP is effectively dead - the shadow stack is basically the return address - when you do make a subroutine call, the PC is pushed to both the normal application stack, and the shadow stack. You can manipulate the application stack as much as you want - completely destroy it, if desired. When you return, though, the CPU will get the return address from the shadow stack instead of the application stack.
The shadow stack is guarded and cannot be written to by the application, so you cannot actually manipulate the return address from the application.
Presumably to increase security there is an additional CPU trap if the shadow stack return address and the application stack return address do not agree - which may be due to an application bug smashing its own stack rather than something malicious.
Re: (Score:2)
Re: Bullshit bingo (Score:2)
Iâ(TM)m not sure entirely, but I think itâ(TM)s talking about two things:
Re: (Score:2)
WTF is this article summary? It makes no sense. Application code hasn't been running on the stack for over a decade. Non-executable stack has been the default behavior of every sane operating system for ages. Does anyone care enough to provide a real summary, if the article actually has a valid point?
Indeed. What is also true is that protecting the stack against execution does not help nearly as much as some people think. For example, return-oriented programming is a away around it, and than there is the little fact that you do not always need code execution to do a successful attack. Just overwriting some neighboring variables on the stack or the heap can be quite enough.
Software Hardware Interaction Threat Evaluation (Score:3)
Please feel free to make your own acronyms.
Re: (Score:2)
Re: (Score:2)
Special Highly Intense Threat-protetion!
this is trash (Score:1, Interesting)
Look, I get it... you want "lazy" developers to find a way to run code in a safe environment... well guess what? This just creates a single point of failure and is a failure waiting to happen. Once this "feature" has been compromised nothing in it is safe.
If security was taken seriously applications would build some security into their software... that way when it becomes compromised... (and it will) it can be updated to patch the hole. Fixing a HW failure/bug/vuln is whole different ballgame.
We are lite
Re: (Score:1)
The huge problem I think is a social problem. Yes there always have been and always will be malcontents, but I think this is the most paranoid a society has ever been in human history. Yes, even more than a society under a Soviet, Nazi, or any other kind of fascist and totalitarian regime. People have been worked up into a huge frenzy over the past 40 or so years into believing that everybody else is out together, and there is a $2_LEGGED_MONSTER_TYPE hiding behind every bush. I never heard the term "play
Re: (Score:1)
"The huge problem I think is a social problem."
should say
"A good portion of the problem we are facing I think is social"
Re: (Score:2)
Indeed. Redundancy (usually called defense-in-depth in secure software engineering) is the thing that all good engineering critically relies on.
A link that might help cut through the BS (Score:5, Interesting)
Here's a link to a document from Intel [intel.com] that explains what's going on. Section 1.1 explains the shadow stack.
My take-away is that there are attacks based on getting the CPU to jump back to something other than the valid return address. The shadow stack is a hardware-protected copy of the working stack. If the code attempts to return someplace other than where it was called from, an exception is raised.
Re: (Score:2)
Would not it just be simpler to write-protect the stack at the point where the call is placed and the PC pushed onto the stack? This would require only a VERY minor microcode update on the processor and would have nothing whatsoever to do with Microsoft ...
Re: (Score:2)
Because it is perfectly legal to modify variables on the stack:
void main()
{
int x = 7;
change(&x);
}
void change(int *px)
{
*px = 5;
}
Re: (Score:2)
This capability does not yet currently exist. Please plan to replace all your computer equipment when it does.
Re: (Score:1)
BSD, Linux, Windows protections (Score:2)
All the major OSs have been doing stack protection since the turn of the century. Here is a description of BSD https://argp.github.io/2010/04... [github.io] and Linux https://link.springer.com/arti... [springer.com] while Windows had a stack canary system since 2003.
This MS announcement is the latest feature, which requires new CPUs. So this is Intel one-upping AMD for a change.
Not interested (Score:2)
Somebody is stealing my cookies. What I need is hardware-assisted snack protection.
Re: (Score:2)
Nice one!