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

Comments

SSDD

[Anonymous Coward]

Linux. Yikes. How many kernel exploits does this make, in 2017 alone?

Re:SSDD

[Anonymous Coward]

Linux. Yikes. How many kernel exploits does this make, in 2017 alone?

It makes a *lot* less than Windows...

Re:SSDD

[slashdice]

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.

Re: SSDD

[mbeckman]

SSD, Linux source code has always been available freel, always, and freely. Always. Only a moron doesn't know this.

Re: SSDD

[mbeckman]

The above comment, inadvertently directed to SSD, was intended for slashdice. Thanks for no editing, slashdot :)

Re:SSDD

[phantomfive]

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.

Re:SSDD

[93 Escort Wagon]

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?

Re:SSDD

[Zontar The Mindless]

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.

Re: SSDD

[Anonymous Coward]

No worries, given slashdice was obviously aware of the - rather well known - open source nature of Linux your message might have reached a hypothetical user 'SSD' that may have been educated now. Pat yourself on the back!

Re:SSDD

[Anonymous Coward]

People don't get the joke because of all the whooshing noise going on, which makes the joke recursive.

Re: SSDD

[Zontar The Mindless]

The preceding message brought to you by the Slashdot Preview button.

Re:SSDD

[Anonymous Coward]

Because we all know attackers only ever use exactly one exploit, a single remotely exploitable vulnerability, and nothing else when attacking a system.

Re:SSDD

[Z00L00K]

The stack clash - that's something that I have experienced when I coded in C on MS-DOS.

Re:SSDD

[Anonymous Coward]

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.

Re:SSDD

[Aighearach]

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.

Re:SSDD

[Aighearach]

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.

Re: SSDD

[Anonymous Coward]

woosh!

Re:SSDD

[lgw]

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.

Re: SSDD

[Anonymous Coward]

He was probably being sarcastic because of how just the other day the Windows core source code was leaked.

Re:SSDD

[gweihir]

Yikes, another moron without a clue.

Re:SSDD

[Mr. Shotgun]

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?

Re:SSDD

[Anonymous Coward]

If you are able to get a binary running on a windows-machine == machine owned.
If you are able to get a binary running on a linux-system == perhaps owned depending on if you have some exploit to use.

Windows 10: (Just check the number of *remotly exploitable* issues there is)
https://www.cvedetails.com/vul...

Linux:
https://www.cvedetails.com/vul...
And if you dig down a lot of issues are related to qualcomm and android.

https://www.cvedetails.com/ver...
https://www.cvedetails.com/ver...

Re:SSDD

[lgw]

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.

Re:SSDD

[ebvwfbw]

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?

Interesting, makes me wonder

[Anonymous Coward]

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.

Re: Interesting, makes me wonder

[Anonymous Coward]

It's only on specific processor types, which indicates the flaw is in the chips' instruction set and the OS patch is a mitigation.

Re: Interesting, makes me wonder

[Anonymous Coward]

It's an ABI flaw, not a instruction set flaw.

The real fix would be in the compiler and recompiling all libraries and binaries.

So yes, the kernel fix is "mitigation", because doing the real thing will take much longer.

Re:Interesting, makes me wonder

[Anonymous Coward]

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.

I'm actually still wondering if any of the above except Linux actually are vulnerable.

Only the "threatpost.com" article claims so, and of course the copy/pasted slashdot summary.

But the security researchers quoted in that very article explicitly say they discovered this in Linux, and nothing else.
The CVE issued explicitly says Linux kernels from 3.0 to 4.11.5 as well, no CVEs for other kernels or OSes.

Also the vulnerability in Linux only applies to Intel x86 and amd64 architectures, and it has been proven not to work on ARM processors.

So if it is processor specific, under what basis are they even assuming it would work on IRIX (riscX000 processors) or SunOS (Sparc processors) and so on?

That isn't to say x86 versions of the other OSes aren't vulnerable, but I'd like to see at least one person on earth attempt it to find out.

Threatpost just seemed to pulled that out of their ass to make one claim that has hasn't even been tested, and a few more claims that are actually proven false, which in the end makes their first unproven claim suspect, since if they are correct at all it was only by accident.

Re:Interesting, makes me wonder

[Anonymous Coward]

"The Stack Clash is a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64. It can be exploited by attackers to corrupt memory and execute arbitrary code."

https://blog.qualys.com/securi...

Re:Interesting, makes me wonder

[Anonymous Coward]

I'm actually still wondering if any of the above except Linux actually are vulnerable.

Go look up CVE-2017-1000372.
Now compare to CVE-2017-1000364.
Notice something?

Re:Interesting, makes me wonder

[Anonymous Coward]

Wonder no more, here's the actual technical description of the problem that includes attacks on non-Linux OSes: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt.

Slashdot editors: this link should have been in the summary. It's the relevant one to technical users interested in what the attack actually is.

Re:Interesting, makes me wonder

[Anonymous Coward]

Thank you to anon (#54682779) above as well as anon (#54682833) below for this link.

This was the missing info that was excluded from the summary that answers a couple of my questions above.

Re: Interesting, makes me wonder

[Anonymous Coward]

The compiler already is fixed, use -fstack-check

It's an option because it costs some performance and therefore you may want to use it only on applications subject to untrusted input.

Re:Interesting, makes me wonder

[phantomfive]

That's a really great writeup. This comment should be modded up.

Re:Interesting, makes me wonder

[Zero__Kelvin]

This is because those are the Operating Systems they tested. They indicate "Other operating systems and architectures may be vulnerable too, but we have not researched any of them yet: please refer to your vendor’s official statement about the Stack Clash for more information." in their blog on the subject.". In other words, Microsoft products are likely just as vulnerable (unless you think all these developers for all these OSs didn't think properly mitigate this, but Microsoft did.) Also, note that Linux has implemented a fix for this type of attack, it just turns out it wasn't good enough. They are increasing the stack guard size that they already implemented to deal with it now.

Re:Interesting, makes me wonder

[Anonymous Coward]

Best quote from the linked write-up:

The address-space of a 64-bit process is so vast that we initially
thought it was impossible to clash the stack with another memory region;
we were wrong.

Re:Interesting, makes me wonder

[thogard]

I see this as a rehash of the attacks often used in the late 1980s.

It is exactly like scanning IPv6 addresses, the problem is hard but computers can do billions of operations a second now. Throw in human issues and then the search space is much lower. Just like scanning systems trying ..:1::MAC or ..:1::ipv4 or probing the infinite space of SNMP starting with 1.3.6.1.4.1...

This is much harder to do on systems that have hardware stacks (sparc, some mips and others but not x86) since they can never ever run code near the top of the stack. Exploits require far deeper levels to get enough junk on the stack to be useful.

Stack Clash?

[Anonymous Coward]

That name will never sell, you gotta give it a name like "Spotted Donkey Cock"!

Re:Stack Clash?

[Anonymous Coward]

That would be "Spotted Donkey Cock Bleed", thank you very much. TV news people need for something to bleed before they think it's bad.

Re: Stack Clash?

[Anonymous Coward]

It did allow them to include Clash lyrics though, so unless there's a band called ...

requires local access

[humankind]

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.

Re:requires local access

[Zocalo]

Two words: "priviledge" and "escalation".

You might not be giving random people shell access to your server, but if they've managed to acquire it through some other means (e.g. a compromised acccount or some other form of compromise) this means that they can pretty much be assured of being able to go from there to root until you install the patch. Not as bad as a remote root exploit, but still very nasty and worth the "Patch Now".

Re:requires local access

[Anonymous Coward]

And it was already patched so nothing to see here except the Windows fans causing FUD.

Re:requires local access

[phantomfive]

There are always privilege escalation exploits available, because setting up a good permissions system that considers all the subtle interactions between parts is hard. At this moment in time, you have a chance of stopping remote exploits, but you have no chance of stopping privilege escalations once someone's code is already running on your system.

To me privilege separation seems like an area where formal verification could be useful, but so far no one cares enough to really work on it.

Re: requires local access

[Anonymous Coward]

Aka no one wants to spend money to get security right.

  Ooooooo shiny, what were we discussing again? xD

Re:requires local access

[chipschap]

I think the important thing is that effectively as soon as it was reported, it was fixed and a patch rolled out.

Linux certainly has flaws and vulnerabilities, just like any major OS.

But by and large, they don't get "solved" by hoping no one exploits them. They actually get fixed, more often than not in a timely manner.

Re: requires local access

[phantomfive]

tbh this seems like a fertile area for research. Probably many PhDs available in for people who want to work on making formally verifiable permission systems. Just starting to think about the problem here,

You'd need to start with a very simple permission system. For example, Android has so many complex, overlapping, and confusing permissions that holes are easy to find without any thought at all. Basic Unix has a very simple permission system so you could probably work with that, Windows is probably too complex to do reasonable proofs, and modern Linux gets rather complex with all the containers, too.

The next step would be to start looking at individual system calls. Is there a way to formally verify that they aren't going to cause problems outside the rules of the permission framework? Of course there is, and with some of the system calls it's really easy. Other system calls would be very much harder (I'm thinking of select() here).

Once they system calls have been divided into 'easy' 'hard' and 'intractable' (or other appropriate categories), you can get started formally verifying the easy ones, and ideally built an automated system to prove their correctness. Then, in the hard category, there are likely some syscalls that can be moved into the 'easy' category with some simple changes, like unifying code paths that are mostly the same, for example.

You can start chipping away at the intractable syscalls, and eventually move some of them into the hard category, but at least you'll clearly know which syscalls are the intractable ones. Once you know that, you can offer a 'safe' mode in the kernel, where certain processes are not allowed to call those syscalls that are known to be dangerous.

We should be able to reach DJB's goal of, "We will have invulnerable software systems, with no bugs in trusted code. We will be confident that these systems enforce the user's security requirements."

Re:requires local access

[OneHundredAndTen]

Two words: "priviledge" and "escalation".

One word: "privilege". A comment: Glaring spelling mistakes make one look stupid and ignorant.

Re:requires local access

[thegarbz]

so it's not as bad as people claim

Yes if your computer is your own and you don't do something like provide services for others.

Re:requires local access

[Anonymous Coward]

> This exploit still requires local access to a machine...

*sigh*

"Is it exploitable remotely?

Our research has mainly focused on local exploitation: as of this writing on June 19, 2017, we do not know of any remotely exploitable application. However, remote exploitation of the Stack Clash is not excluded; although local exploitation will always be easier, and remote exploitation will be very application-specific. The one remote application that we did investigate (the Exim mail server) turned out to be unexploitable by sheer luck."

https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash

Any error that results in code execution is often equivalent to "local access".

Re:requires local access

[Anonymous Coward]

Yes if by "provide services" you mean "provide a system with suid root binaries containing exploitable stack buffer overflows".

Stack Clash circumvents one specific *exploit mitigation* mechanism, stack guard pages.

That's it.

It's as much of an exploit by itself as return-to-libc to get around non-executable stack is.

First of all

[DaMattster]

It is called Stack Smashing and OpenBSD is NOT vulnerable to it!

Re: First of all

[Anonymous Coward]

The Linux cocksuckers are trying to downplay their tragic security issues by falsly claiming they also apply to others.

Re:First of all

[ISayWeOnlyToBePolite]

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.

Re:First of all

[Anne Thwacks]

All I could read seemed to imply this was for Intel and AMD architectures. Do you know if Sparc64 or ARM are susceptible?

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.

Re: First of all

[Anonymous Coward]

Here's tour vuln stack at the high level:

Something on your server has a library with a problem. Maybe the whole library is problematic, or maybe it is a rare flaw in an otherwise good library. How is libxml2 these days?

That part isn't running at root, but now it has been tricked into running someone else's opcodes via a flaw in someone else's code. It can then use privlege escalation to do rooty things to your box.

That is the general path of these sorts of things these days.

Re: First of all

[buchanmilne]

If OpenBSD wasn't vulnerable, why did they issue a patch:
https://ftp.openbsd.org/pub/Op...
?

Re:First of all

[thogard]

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.

This may be a very old bug

[Anonymous Coward]

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.

Re:This may be a very old bug

[manu0601]

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?

Warning: Asking this question may re-ignite the SCO case.

Slashdot

[Anonymous Coward]

The day before yesterdays news, tomorrow!

Red Hat Linux...

[__aaclcg7560]

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

Re:Red Hat Linux...

[Aighearach]

They were busy practicing with goop stones all week, just check the headlines. They even threw their backs out trying!

Re:Red Hat Linux...

[Anonymous Coward]

https://hostingkartinok.com/show-image.php?id=d09a8e9e28f89e99e3980d81295b794a

Requires poorly-designed software, basically

[mrsam]

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.

Re:Requires poorly-designed software, basically

[phantomfive]

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.

That's the most optimistic thing I've read today.

Re:Requires poorly-designed software, basically

[Anonymous Coward]

I understand this stack mechanism, but where is the privilege escalation?

Re:Requires poorly-designed software, basically

[Anonymous Coward]

I think this vulnerability isn't as spectacular as the summary makes it out to be.
You'd have to be running an application as root that can be tricked (by parsing a malicious file or script maybe) into recursively calling a function with a stack frame bigger than a page. I've done quite a lot of debugging and reverse-engineering and stack frames tend to be a few dozen bytes. Sometimes a buffer for a structure or something can be a few hundred but big stack frames tend to be close to the shallow end of the stack, not in deep-recursion land.
As it stands, it's a very theoretical risk.

Re:Requires poorly-designed software, basically

[complete loony]

From the original writeup (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt);

Based on our research, we recommend that the affected operating systems:

- Increase the size of the stack guard-page to at least 1MB, and allow system administrators to easily modify this value (for example, grsecurity/PaX introduced /proc/sys/vm/heap_stack_gap in 2010). This first, short-term solution is cheap, but it can be defeated by a very large stack-based buffer.

- Recompile all userland code (ld.so, libraries, binaries) with GCC's "-fstack-check" option, which prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack). This second, long-term solution is expensive, but it cannot be defeated (even if the stack guard-page is only 4KB, one page) -- unless a vulnerability is discovered in the implementation of the stack guard-page or the "-fstack-check" option.

That was one of the recommendations. Finding large stack allocations, in setuid binaries, that don't write to the allocated memory is hard.

Re:Requires poorly-designed software, basically

[Anonymous Coward]

I guess you are supposed to run a program that has its setuid bit set, which will run as root, and then feed that program input data that will cause it to clash its own stack. You can then make that program do what you want it to, rather than what its authors intended it to do.

So the real cause of privilege escalation is the setuid bit.

I've never liked the setuid bit model of security.

How do I actually "upgrade" my Linux.

[goombah99]

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?

Re:How do I actually "upgrade" my Linux.

[dissy]

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.

Actually "apt-get upgrade" will also get the latest kernel as well.
The only real difference is that you need to reboot into the new kernel, a step never needed for just upgrading software packages.

That's all you need to do to patch your system against this specific vulnerability.

But if by "OS" you mean "distribution version" instead of "kernel" (IE going from Debian 7 to Debian 8), you first do an "apt-get upgrade" like normal, and afterwards do an "apt-get dist-upgrade"

However you are correct that a dist-upgrade may break software packages, or specifically your custom configuration files.
The reason they call it the "stable" distribution is because any and all upgrades to software will guarantee config file compatibility.

But between two stable major versions, this is not guaranteed.
The new stable version may come with a significantly newer version of some program, not just the same version as shipped with all security fixes back-ported into it.
Because of that, if you've made any significant changes to a programs /etc configs, your copy of the "old versions" config will be kept, and may be missing required new lines or have deprecated old lines that will throw an error, thus the program won't run.

The dist-upgrade process WILL give you an opportunity to deal with it on a manual basis, but it sucks to have to do.

Your options are basically "Keep the old possibly missing things config", or "wipe away my config and install the new versions defaults", or "show me the difference and give me an editor"

As it sounds, none of those are "fun"

BUT there is good news!
If you installed Debian 7, and Debian 8 comes out, you don't need to dist-upgrade at all.
Security fixes and updates will continue to be released for 7 for some time, and you can just keep your working system as is.
So your process of waiting until you get new hardware and doing a new install from scratch is perfectly workable for quite some time after new distro versions come out.

Re: How do I actually "upgrade" my Linux.

[cloudmaster]

This being a kernel issue, the kernel package is what gets updated. You use the same apt upgrade command to update linux-image as everything else. You've probably already done so several times without even noticing - aside from the need to reboot afterwards.

Here's the Ubuntu page on the defect, along with instructions if you need them.
https://www.ubuntu.com/usn/usn...

Re:How do I actually "upgrade" my Linux.

[Anonymous Coward]

It will break everything. They say it won't, but the day you rely on that, it'll break everything, and then you're fucked.

What you do is install a new version to a new hard drive, then attach the old hard drive and copy over all of your files, then spend the next few days configuring the system as you slowly figure out what packages you were using and install them, and which files in /etc/ you had modified and modify them in the new system.

Also, at the start of the process, open up a text file and type into it *everything* you do to configure the new system, forever, in particular copy and paste any modifications you make to configuration files so that you don't have to re-learn the syntax. It'll make this process a lot less painful the next time you upgrade since most of what you need to know will be right there in the file, but of course, every time there will be a few things that have changed and so your notes about them will no longer be correct, and of course attempting to Google the new information will mostly result in people talking about how to do it the old way.

Re:How do I actually "upgrade" my Linux.

[Zontar The Mindless]

What you do is install a new version to a new hard drive, then attach the old hard drive and copy over all of your files, then spend the next few days configuring the system as you slowly figure out what packages you were using and install them...

The people who maintain the distro I use suggest the provided Export tool in the package manager for writing a list of all installed packages to a text or XML file, but what do they know?

Re:How do I actually "upgrade" my Linux.

[Anonymous Coward]

If you're using Ubuntu, there's an option "Software and Updates" under Preferences from the start menu.

You can get all the updates there.

Re:How do I actually "upgrade" my Linux.

[Anonymous Coward]

If you update a software package, you can always break things. Whether that is inter dependencies or just features that used to work in the old version but no longer work in the new one (or work in ways you aren't familiar with, breaking your workflow), these things happen. That's always the risk with updates.

Re:How do I actually "upgrade" my Linux.

[Mikkeles]

Simple instructions for Slackware can be found here on Paranoid Penguin.
Basically:

1. Download the linux source
2. Configure for your system
3. Make it
4. Copy to boot directory
5. While retaining the ability to boot your current kernel , make the new kernel your bootloader's default.
6. Restart

Re:How do I actually "upgrade" my Linux.

[Anonymous Coward]

already has. deb/ubuntu attempt at fixing the kernel broke UBNT's unifi controller software. Big thread on it at UBNT community forum.

Re:How do I actually "upgrade" my Linux.

[somenickname]

Yikes, "dist-upgrade" certainly does *not* upgrade you to latest release of a debian based system. As per the apt-get man page:

              upgrade
                      upgrade is used to install the newest versions of all packages
                      currently installed on the system from the sources enumerated in /etc/apt/sources.list.

              dist-upgrade
                      dist-upgrade in addition to performing the function of upgrade,
                      also intelligently handles changing dependencies with new versions
                      of packages

If you aren't familiar with the terminology then it's a bit confusing but, "apt-get dist-upgrade" is just a smarter "apt-get upgrade". Neither of which change the distribution version. I always use "dist-upgrade" because it actually does what most people would expect "upgrade" to do. If you want to do an inline upgrade to the latest version of a debian based distro, you need (at minimum) to point /etc/apt/sources.list to the latest distro. Some debian based distros will automate this process with simple tools but, on debian, it's a manual (but fairly simple) procedure.

Re:How do I actually "upgrade" my Linux.

[cas2000]

It will break everything. They say it won't, but the day you rely on that, it'll break everything, and then you're fucked.

That's an extraordinarily bizarre, and totally false, perspective.

I've been upgrading the system I'm typing this message on right now since 1994. First with dselect and/or 'dpkg -iGROEB' and later with apt-get. The ability to do this is a large part of the reason for running an upgradable OS like debian.

In all that time, with hundreds of upgrades performed (thousands if you include all the other machines I routinely upgrade), I've never once had the system "break", let alone "break completely" as a result of an upgrade. Mostly, upgrading just happens smoothly, without any problems. Occasionally, very rarely, less than once/year, upgrading some particular packager requires one or more configuration files to be edited to work with the new version.

Mostly I upgrade the software. Sometimes I upgrade some or all of the hardware - and whenever upgraded the hard disks, I just copy the old filesystem(s) over to the new disk(s) with rsync or tar or cp.

This particular system started out as a 80386-DX-40 with 4MB RAM. It's currently a Phenom II 1090T with 32GB RAM (it has been a 1090T since around 2011, and the RAM got upgraded from 16GB to 32GB about 2 years ago).

In the near future, it will be upgraded to a Ryzen 7 1700 (or maybe a 10-core "threadripper" with more future upgrade potential, depending on price), probably with 64GB RAM.

(alternatively, I may just build a brand new system to be my desktop machine, leaving my current system to be the home file/web/proxy/dns/etc server & internet gateway rather than combined server+desktop. it'll cost a bit more but i've been wanting to separate desktop and home server functions for years, it just hasn't been worth the expense. If I do that, I'll probably also pick up an FX-8320 or 8350 CPU cheap to upgrade the 1090T)

What you do is install a new version to a new hard drive, then attach the old hard drive and copy over all of your files, then spend the next few days configuring the system as you slowly figure out what packages you were using and install them, and which files in /etc/ you had modified and modify them in the new system.

That's exactly what you DON'T and shouldn't do. It changes a trivial, routine upgrade with no downtime into days or weeks of tedious work.

Avoiding that time-wasting, error-prone idiocy is one of the reasons I switched from Slackware to Debian in the 90s.

[...take notes...]

The only thing you've said that's even remotely correct is that you should keep notes on what you do to your systems. Planning and learning from experiences are always worthwhile.

Also, use etckeeper or just plain git or svn or whatever (even RCS is better than nothing) to keep a revision history of changes to configuration files....a timestamped, commented history of every configuration change is very much worthwhile.

Re:How do I actually "upgrade" my Linux.

[Anne Thwacks]

What you do is install a new version to a new hard drive, then attach the old hard drive and copy over all of your files,

Real men use tape. (So do real and virtual women, AFAICT).

Re: How do I actually "upgrade" my Linux.

[Anonymous Coward]

You must lack experience or will, but even in a worst case scenario with a newly installed system, you just need to compare the list of packages of your old system to the new one - a diff is pretty sample. Then again, others have pointed out there are specialized tools for doing that.

Re:How do I actually "upgrade" my Linux.

[swillden]

Yikes, "dist-upgrade" certainly does *not* upgrade you to latest release of a debian based system.

Yes and no. No, dist-upgrade will not change your sources.list. Yes, it's needed for release upgrades, and those are why it exists.

Normal updates do not involve package refactoring, but release upgrades often do. The thing that "apt-get upgrade" does not do is remove packages or install new packages. This is normally a good thing, because it reduces the chance that your system may actually lose functionality. But releases change a lot more, and so dist-upgrade is required. The chance of breaking something during a release upgrade is acceptable because that's something that happens rarely (for most people).

If you're running Debian unstable then package refactors can happen at any time, and you can -- and should! -- expect your system to break at any time (though it doesn't break that much, in practice). You should use dist-upgrade if running unstable. If you're running testing, you may need it occasionally, when upgrade reports that it is refusing to do things because they would involve package refactors. If you're running stable you should basically need dist-upgrade only when a new release comes out (and you should test).

If you're running a Debian derivative, you should follow the recommendations of the distro. In most cases this will not involve using dist-upgrade very often.

I always use "dist-upgrade" because it actually does what most people would expect "upgrade" to do.

Not really. Most people don't expect upgrade to remove packages or install new packages, which dist-upgrade can do. Most of the time it doesn't (except on rolling release systems), but by using dist-upgrade you are increasing the probability that you'll break something on your system. It's safer to use upgrade. If upgrade reports that changes are being held back, you should investigate why, and then take appropriate action (which may be dist-upgrade).

Personally, I mostly do upgrades in aptitude, which makes it easier to see what's being done, easier to resolve conflicts, and is smarter about distinguishing between packages that were intentionally installed and those that were automatically installed to support some intentional installation. That makes it easier to ensure that automatic dependencies are removed when they're no longer needed; otherwise systems tend to accumulate a lot of cruft.

Re:How do I actually "upgrade" my Linux.

[somenickname]

I always use "dist-upgrade" because it actually does what most people would expect "upgrade" to do.

Not really. Most people don't expect upgrade to remove packages or install new packages, which dist-upgrade can do. Most of the time it doesn't (except on rolling release systems), but by using dist-upgrade you are increasing the probability that you'll break something on your system. It's safer to use upgrade. If upgrade reports that changes are being held back, you should investigate why, and then take appropriate action (which may be dist-upgrade).

When I tell the system to upgrade, I expect it to install kernel updates. If you do an "upgrade", you may or may not get kernel updates because they may be considered a new package (for example, 3.16.0-4 vs 3.16.0-5). That's definitely not the functionality I want. The kernel, specifically, was what got me into the habit of using "dist-upgrade" instead of "upgrade". On debian proper, this is less of an issue since the kernel versions don't change often but, on Ubuntu, if you don't use dist-upgrade, you'll never get kernel updates. If I remember right, they went to the "always update the kernel version number" so that kernel installations wouldn't clobber existing kernels and possibly leave the system in an unbootable state.

Re:How do I actually "upgrade" my Linux.

[Anonymous Coward]

On debian proper, this is less of an issue since the kernel versions don't change often but, on Ubuntu, if you don't use dist-upgrade, you'll never get kernel updates.

I haven't used Debian in long enough that I can't speak to it, but regarding Ubuntu this is simply wrong.

You're talking about the company that...

[Anonymous Coward]

paid for Poertting to develop a varied of anti-free software to how windows-ify Linux.

Of course they would put a bandaid on the gangerenous leg and only wait until septic shock kicks in to amputate it :)

Re:You're talking about the company that...

[phantomfive]

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.

Damn

[hyperar]

You'd think that by 2017 this kind of linux vs. Microsoft childish discussion would be a thing of the past, but damn. Now, regarding TFA, it amazes me how long it took to reach /., i've read this on other portals days ago.

Explination

[FeelGood314]

https://www.qualys.com/2017/06...

Re:Explination

[FeelGood314]

Some quick (very simplified) background for people who don't know how an OS works
Most of the time user space programs will be running on a processor. Each user space program has its own memory space to work from. The processor switches back to the kernel when an interrupt occurs. An interrupt is a signal to the processor that causes it to save some information about the current running program and then jump to an instruction or function based on the interrupt. An interrupt could be an serial device demanding attention or a keyboard press. It could be a timer indicating that the current user programs time slice is up and it is time for the kernel to give another program a chance to run. Programs also trigger interrupts to get the kernel to do something. A printf() creates a string in memory, puts the address of the string in a register and then calls an interrupt so the kernel can display the string.

Interrupts are specific to processors.

On an x86 based processor one of the interrupts used by the kernel is the page-fault interrupt. This interrupt is triggered when a program accesses memory that it wasn't given permission to access. Often this occurs when the user program stack has grown to large for the amount of memory the kernel gave the program. The kernel will respond to the page-fault interrupt by giving the program more memory if it can.

However the page-fault interrupt doesn't reliably go off in the way the kernel programmers would like. It is possible to access memory that you were not supposed to be able to access with out the interrupt occurring. This unfortunate difference in expectation is what leads to this vulnerability and why it affects multiple OS on i86..

Re:Explination

[glenebob]

However the page-fault interrupt doesn't reliably go off in the way the kernel programmers would like. It is possible to access memory that you were not supposed to be able to access with out the interrupt occurring. This unfortunate difference in expectation is what leads to this vulnerability and why it affects multiple OS on i86..

I was on the bus until I got to this paragraph. What do you mean, "page-fault interrupt doesn't reliably go off" in a way that "It is possible to access memory that you were not supposed to be able to access"?

If this were really true, this would exploited every day and no computer would be even a little bit secure.

As I understand it, the "problem", which the guard page tries to mitigate, is that the stack pointer can be made to point to heap space that the process absolutely is supposed to have access to.

If that's the case, then IMO the stack component of the problem is a great big red herring. If causing a process to wreck its own heap space (by any means) can lead to privilege elevation, then THAT is a huge problem, and it's the problem we should really be talking about.

Re:Explination

[Anonymous Coward]

However the page-fault interrupt doesn't reliably go off in the way the kernel programmers would like. It is possible to access memory that you were not supposed to be able to access with out the interrupt occurring. This unfortunate difference in expectation is what leads to this vulnerability and why it affects multiple OS on i86..

You don't know a thing about how an OS kernel works, do you? Interrupts are asynchronous and faults/traps are synchronous to the instruction stream being executed. But neither executes on the user space stack.

Otherwise, as a user space program I could position the stack carefully and have the kernel smash whatever I want on the next interrupt. No -- it doesn't work like you described at all.

Please don't skip any more of your OS classes. Thanks.
 

Re:Explination

[Anne Thwacks]

If that's the case, then IMO the stack component of the problem is a great big red herring. If causing a process to wreck its own heap space (by any means) can lead to privilege elevation, then THAT is a huge problem, and it's the problem we should really be talking about.

That is the point I was trying to make earlier on, but put more elegantly.

This affects Linux Kernels 4.11.5 and Later

[kjhambrick]

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

Wait... Build with selinux, and...

[bferrell]

it becomes vulnerable?! WTF!

The NSA made selinux. Automatic backdoor!

Does anyone really think that was an accident?

Re:Wait... Build with selinux, and...

[thegarbz]

Does your doctor know you're off your meds?

Re:Wait... Build with selinux, and...

[Anonymous Coward]

Are you surprised by the fact that adding complexity to an already complex system adds bugs?

Re:Wait... Build with selinux, and...

[Anonymous Coward]

> Wait... Build with selinux, and it becomes vulnerable?!

N... no. Lrn 2 reed:

"Is the Sudo vulnerability Qualys published on May 30 related to Stack Clash?
https://www.qualys.com/2017/06/14/cve-2017-1000367/cve-2017-1000367.txt https://www.qualys.com/2017/06/14/cve-2017-1000367/linux_sudo_cve-2017-1000367.c

If CVE-2017-1000367 is combined with the Stack Clash, any local user (not just Sudoers) can exploit Sudo to obtain full root privileges on any vulnerable Linux system (not just SELinux systems). Because CVE-2017-1000367 was exploitable independently of the Stack Clash, we (and the affected vendors) decided to not wait for the June 19 Coordinated Release Date and published it on May 30.
"

https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash

Re:Wait... Build with selinux, and...

[Anonymous Coward]

Since it also affects openBSD I doubt it has anything to do with the NSA

Use ulimit -s

[Anonymous Coward]

You can see the problem by checking your processes with pmap. Here's the stack for my bash:

...
00007fe752e63000 16K rw--- [ anon ]
00007fe752e96000 4K r---- ld-2.25.so
00007fe752e97000 4K rw--- ld-2.25.so
00007fe752e98000 4K rw--- [ anon ]
00007ffda73f0000 132K rw--- [ stack ]

You can see that ld-2.25.so and its writable data (?) is reachable above the stack (remember, stack grows down). It is, however, 95GB away from the stack. If you limit your programs' stack size to, say a megabyte, with ulimit -s 1024 placed in bash startup scripts, you will be safe from the attack.

Android?

[Dwedit]

Does it affect Android too?

Re:Android?

[Zero__Kelvin]

It affects the Linux kernel, so that is a definite yes.

Re:Android?

[Anonymous Coward]

That's good news then, we can gain root on our Android devices and remove all those crappy apps bundled with our phones and tablets. Then install and ad-blocker.

Grsecurity fixed it 12 years ago

[Anonymous Coward]

Incredibly, but nobody found it important to mention that this vulnerability was known 12 years ago through a presentation on CanSecWest.

https://cansecwest.com/core05/memory_vulns_delalleau.pdf

And that grsec has long known about it and patched long time ago. Linux "security" is a joke.

dist-upgrade on Ubuntu doesn't change OS versions

[Anonymous Coward]

apt-get dist-upgrade on Ubuntu doesn't change OS major or minor versions. It only impacts the 3rd level version.

For example:
14.04.1 --> 14.04.2

To get from 14.04.x to 16.04.y then there is a "do-release-upgrade" tool.

Just one of the ways that Ubuntu-based distros are different from Debian. There are others.

Re:When?

[Anonymous Coward]

Have you ever heard him utter a three syllable word? Me neither. He couldn't outsmart door stop.

What about Darwin?

[TheFakeTimCook]

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?

Who cares, systemd is a bigger target

[Anonymous Coward]

To much work and difficulty already having over privileged over complicated surface to attack like systemd

That's it! I'm done! I QUIT!

[Anonymous Coward]

I hate linux, Windows, BSD, ALL of it. I am sick and frigging tired of computers. I've been doing this for 13 years now and none of this line of work has turned out the way I had imagined it would go before I got into it. Its just one vulnerability after another. These things do more harm than good. I don't wanna spend another minute sitting in a chair staring into a light-box clicking a bunch of little boxes and carrying around a handheld light-box to stare into whenever I'm not at work doing it. Fuck computers. I've made up my mind: I'M GOING _ANALOG_.

Re:Linux is like anal sex

[Anonymous Coward]

wtf did i just read...? oy, that's it, time to go to bed.

Solaris and other open source systems

[Anonymous Coward]

Waitwut ? Oracle Solaris is 'open source' now ?

Android?

[Anonymous Coward]

How badly does this affect the most widely used OS with all its sandboxed apps?

Re:Linux is like anal sex

[RockDoctor]

You're doing it wrong. I don't know about you, but when I have anal sex I don't experience pain or bleeding, and the woman I'm sodomising likes it too.

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.

The fix caused a massive Java regression

[Anonymous Coward]

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699772

All applications using the Java Invocation API, ie. calling Java from C/C++ (LibreOffice Base, Eclipse, Octave, ImageJ, SciLab, countless others) CRASH ON STARTUP due to a bug in the patch for this security issue.