Slashdot Mirror
'Stack Clash' Linux Flaw Enables Root Access. Patch Now (threatpost.com)
msm1267 writes: Linux, BSD, Solaris and other open source systems are vulnerable to a local privilege escalation vulnerability known as Stack Clash that allows an attacker to execute code at root. Major Linux and open source distributors made patches available Monday, and systems running Linux, OpenBSD, NetBSD, FreeBSD or Solaris on i386 or amd64 hardware should be updated soon.
The risk presented by this flaw, CVE-2017-1000364, becomes elevated especially if attackers are already present on a vulnerable system. They would now be able to chain this vulnerability with other critical issues, including the recently addressed Sudo vulnerability, and then run arbitrary code with the highest privileges, said researchers at Qualys who discovered the vulnerability.
The risk presented by this flaw, CVE-2017-1000364, becomes elevated especially if attackers are already present on a vulnerable system. They would now be able to chain this vulnerability with other critical issues, including the recently addressed Sudo vulnerability, and then run arbitrary code with the highest privileges, said researchers at Qualys who discovered the vulnerability.
Very interesting that the major flavors (Sys V, BSD, and Linux [which I consider a rewrite of Sys V]) are vulnerable. Sounds like a deep seated logic flaw there. Wonder if other vendor specific ones (IRIX, SunOS, Ultrix, AIX, etc) are vulnerable.
A lot. There was a massive Linux source code leak (all the source code going back to the early 90s) over the winter and hackers have been using it to find exploits.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
This exploit still requires local access to a machine, so it's not as bad as people claim. Unless you're giving random people shell access to your server.
What's odd is that I think it got fixed a very long time ago, as in v7 or maybe 4.2BSD. How did it come back and end up in Linux?
It's been a long time, maybe I am remembering incorrectly, but it seems awfully familiar.
Red Hat sent out a notification on Monday. Nice to see the Slashdot editors catching up on the news this weekend.
https://access.redhat.com/security/cve/cve-2017-1000364
It is called Stack Smashing and OpenBSD is NOT vulnerable to it!
CVE-2017-1000372 and CVE-2017-1000373 are mentioned in the advisory? Broad statements without facts are not helpful. Try again.
Sifting through the CVE and the write-up:
The kernel places an unmappable guard page just below the process's maximum-alloted stack space. Normally a process gets allocated only as much stack space as it needs. When the process's stack usage grows, the kernel maps additional pages to grow the process's stack space, but will not grow it beyond the maximum alloted stack size. If the process enters an infinite recursion loop, it'll hit the end of the alloted stack space, and the unmappable guard page segfaults the process out of its misery.
The problem appears to be if the process's heap is right next to the stack, with only the guard page separating it from the stack, and a single function call creates a stack frame that exceeds the size of the guard page. This effectively places the stack pointer into the heap. The function call thinks it has allocated its usual, large stack frame, but the stack pointer is in the heap.
At this point, usual code execution will typically make further use of the stack, so it ends up crapping all over the heap.
That's not good, of course. But I would expect the process in question to attempt to access its alleged stack frame before much happens. At this point the process will try to access the guard page, and gets segfaulted. That, at least, is my understanding of the vulnerability.
The overall design involving a guard page to limit the size of the process's stack is a traditional OS design, which is why the general approach affects both Linux and BSDs, here.
For this to be remotely exploitable, the attacker has to arrange for a process to execute a function call that creates a large stack frame so that the stack pointer jumps over the guard page. I would expect common, battle-tested free software that powers the intertubes to be well designed and written by experienced greybeards who fully understand how an operating system works, and the fact that the stack is not an endless resource, that it is quite a limited resource actually; with the resulting code minimizing automatically-scoped object usage on the stack, which should eliminate the vulnerability completely.
I find Red Hat's write-up somewhat puzzling. They appeared to have taken the tack of addressing the exploit by increasing the size of the guard area to a megabyte, rather than a single page.
That seems to be somewhat inadequate to me, in the brave-new 64-bit world of ours. It seems to me that the permanent fix would be to map the stack into virtual address space that's a terabyte, or two, away from the heap and everything else. Seems to be a no-brainer solution to me, dunno why they didn't do it.
Privilege escalation exploits are in every system, because the attack surface is so broad. The key lesson is to not run unknown code on your system (containers won't help you here because this can escape the container).
Remote exploits are the real problem though. This is not a remote exploit.
"First they came for the slanderers and i said nothing."
A lot. There was a massive Linux source code leak (all the source code going back to the early 90s) over the winter and hackers have been using it to find exploits.
How do people not get this joke?
#DeleteChrome
Sorry if this is a dumb question but I'm pretty sure there's a lot of people with the same question.
I'm comfortable with apt-get but that's just upgrading all the softwares other than the operating system. How do I actually upgrade my OS?
My usage pattern tends to be, do a clean install of linux, install all the packages I need, edit the configuration files as I need them. Then use it till I buy a new computer only upgrading the installed packages. Then I start over. I never have actually pathced my Linux or installed an "upgrade". I'm terrified it would break all my packages.
How do I do this?
Some drink at the fountain of knowledge. Others just gargle.
It occurs to me that the people who crap on and on about any story that doesn't fit their personal definition of "tech" are mostly the same ones who aren't getting the tech joke.
It doesn't surprise me much, either.
Il n'y a pas de Planet B.
I understand systemd. I don't understand why they decided to replace yum. I'm sure they had reasons, but I don't understand them other than some kind of nih syndrome variation where you don't trust what was written by people who came before you.
"First they came for the slanderers and i said nothing."
https://www.qualys.com/2017/06...
this affects Linux Kernel versions 4.11.5 and earlier (the stackguard page was introduced in 2010).
https://nvd.nist.gov/vuln/detail/CVE-2017-1000364/
-- kjh
it becomes vulnerable?! WTF!
The NSA made selinux. Automatic backdoor!
Does anyone really think that was an accident?
I thought stack and heap were mapped to different memory spaces and you could not hop from one to the other - the "same" address would map to different physical memory regions (randomised and non-contiguous in the case of OpenBSD). Logical addresses might appear contiguous, so, theoretically, you could increment (or decrement) a number which is a pointer to Heap and end up in Stack or Vice Versa, but all this would do is let you mess up your data. That is just foolish allocation of the naming of address spaces. There are far more bits of address than the total logical addresses, so there is no reason for you to be able to get from one to another without doing so deliberately.
Obviously, assembly code can write to any address, which may be in either heap or stack, because they both need to be writeable memory, but neither should be executable, so you can't execute code you put in the stack or heap. Nor can YOU (usermode) write to the code page region - only execute it.
Trashing your own data may be unhelpful, but it is hard to see how it could lead to molesting other people's data, let alone executing useful code.
The gaps between heap, stack and code should map to "unassigned" - on 16 bit machines this was often mapped to a page preset to 0xf00l (which was an illegal instruction on the machines I used) and also marked not readable writable, or executable. It would trap for sure.
Molesting function return addresses is easy (in ASM) but you still can't jump to data pages - they are not executable - or outside the code pages. Certainly not out of your program's address space -that is what an MMU enforces - since the 1950's.
In short, I can see how you can trash your own code, but not how you gain anything from doing it.
And I don't see how anyone is going to insert a program they wrote, assembler or not, on my servers. If they can, that IS a problem I want to hear about.
Sent from my ASR33 using ASCII
The preceding message brought to you by the Slashdot Preview button.
Il n'y a pas de Planet B.
The stack clash - that's something that I have experienced when I coded in C on MS-DOS.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It's not a kernel exploit at all. It's an exploit against distributions vulnerable enough to ship suid binaries compiled without -fstack-check.
Now, there is a kernel patch to partially mitigate the effect of bugs in suid binaries, much like the kernel implements address space layout randomization to mitigate shellcode attacks, but the vulnerability exists in the application binary, not the kernel.
Or, they gave the benefit of the doubt, "he wouldn't make a non-joke that stupid and intend it as a joke... right?"
Which gives the speaker more benefit of doubt; that they might actually be so ignorant that there is a surprise in there that would create a funny irony, or that they might have left out some words and they meant to say something better?
If they say they don't get it, it means they're trying really hard to find an interpretation other than that you're an idiot, and they're failing. And they tell you that in a diplomatic way. But you missed it. Which isn't recursive at all, the whooshes never double back they just keep going.
Does it affect Android too?
Don't run code helps.
Another is: don't allow users. A privilege escalation relies on there being privileges to escalate. Services require privileges in order to start, but why should they keep them?
Actually, if you have systemd it might not be true that services have to have privileges to start, you might be able to give them sanitized I/O pipes and they never even open a filehandle. At least, in the future.
It makes a *lot* less than Windows...
Likely not. The Windows kernel is quite hardened these days, from being the largest target for so long. That's why almost all of the Windows security problems you read about have nothing to do with a kernel flaw, and tend to be "trick the user into running this thing as admin". Well, almost all flaws are browser attacks anyhow, but I was talking about the remainder.
Socialism: a lie told by totalitarians and believed by fools.
Yikes, another moron without a clue.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Are Darwin-based OSes, such as macOS and iOS, affected by this?
And if so, any information as to whether it is being, if has been, patched in those OSes?
A lot. There was a massive Linux source code leak (all the source code going back to the early 90s) over the winter and hackers have been using it to find exploits.
By god! A leak of this scale could go all the way to the top, does Linus know about this?
Of all tyrannies, a tyranny sincerely exercised for the (supposed) good of its victims may be the most oppressive
If OpenBSD wasn't vulnerable, why did they issue a patch:
https://ftp.openbsd.org/pub/Op...
?
Neither Windows nor Linux runs stuff as admin/root by default. Both require the user to escalate, in principle. Both have plenty of exploits, in practice. But Linux escalation exploits are more common than Windows these days.
Socialism: a lie told by totalitarians and believed by fools.
Windows is just about the smallest target you mean. Who uses it anymore? From phones, tablets, set top boxes, autos, satellites, routers, switches, san... well you get the picture. I could keep on going. It does have a hold of some business desktops, however even there it's going away. I'm seeing local businesses and even chains that use Linux.
So no, it's not the largest target. It's the smallest. There's a good chance that in 10 years people will say Microsoft windows - what's that?
Try coming in her pussy, then going for doggy-style anal. That way you've got plenty of fresh lubricant immediately to, ummm, hand in a convenient container.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
All I could read seemed to imply this was for Intel and AMD architectures. Do you know if Sparc64 or ARM are susceptible?
The attacks done by Qualys are near to the top of the stack. That is very hard to do on sparc64 as it has a hardware stack. I expect it can be done but it would be a real pain since you would have to attack a deeper level of the stack.
The sparc (and a few other non-x86 cpus) have "Register Windows" for their stack. What happens is the real stack is in static L0 ram just about like the registers are. Early systems would have 4 pages of 8 32 bit values. The means when you pushed up to 8 values on the stack, they went into register like memory. When you called a subroutine, those 8 where shifted 8 and the subroutine had 8 values that it could access, plus the 8 from the calling function and 16 from its callers. The stack was only written to main memory (or cache) after the depth went deeper.
--
ARS-33? get a real terminal. Blits are nice and use slightly less power.