back to article Stack Clash flaws blow local root holes in loads of top Linux programs

Powerful programs run daily by users of Linux and other flavors of Unix are riddled with holes that can be exploited by logged-in miscreants to gain root privileges, researchers at Qualys have warned. Essentially, it's possible to pull off a "Stack Clash" attack in various tools and applications to hijack the whole system, a …

This post has been deleted by its author

Anonymous Coward

Re: Security 101: If they're sitting at the computer...

Also, when the Rottwheelers hit the road. They own it.

0
0
Gold badge

Re: Security 101: If they're sitting at the computer...

Security 102: The phrase "logged-in" does not mean "physical access". The latter implies that you can dismantle the PC and plug its drives into your own box or something equally dramatic. The former implies nothing more than an SSH session from 10,000 miles away using a low-privilege account.

27
1
JLV
Silver badge

Re: Security 101: If they're sitting at the computer...

Hmmm, no that is not entirely true, though there is fair bit of wisdom in what you say.

Unix was brought up in "adversarial" university environments with logged in basic users sometimes sorely tempted to mischief (cf Morris Worm). It was always meant for multiuser use and had segregation of privileges built-in for example through all permissions system. So the system is intended to resist hacks by low-priv users.

Most of the time, it seems to work as designed, though letting in a _skilled_ evil user certainly can't be too good an idea, as per your remark.

That's in stark contrast to the Windows' original I-am-the-master-of-the-machine model. Still recommended by all some of the cluelessentsia that insist that disabling the (insufficiently strict and way too wolf-crying, imho) UAC is the way to go. I'd require some convincing that a std (desktop) Windows can be locked down well, and accounts fully isolated, by a moderately competent user. But I'd expect a Linux/BSD/Macos to mostly have it right from the get go, gross fuckup from configurator aside. Safe, again, from a low-mid level adversary, not Barnaby Jack.

So this is a screwup.

Despite some strident commentards' opinions to the contrary, there is no inherent anti-vulnerability magic fairy dust in Open Source. But at least you can be reasonably assured that this particular hole will be patched when all the libraries go over their code with a fine toothed comb. That's in stark contrast to the outcome in some other ecosystems where bug follows bug follows bug. Still, even OSS can't fully compensate for flawed approaches cough... OpenSSL ...cough...

I am sure someone is going to follow with a "see: Linux sucks! Windows rules!", but that's not drawing entirely the right lessons from this case. It is however a reminder to be vigilant, always. As users, as coders.

30
4
Silver badge
Paris Hilton

Re: Security 101: If they're sitting at the computer...

"If they're sitting at the computer....then it's not YOUR computer anymore."

How is that relevant?

6
1

Re: Security 101: If they're sitting at the computer...

" I'd require some convincing that a std (desktop) Windows can be locked down well, and accounts fully isolated, by a moderately competent user.

I think you're making the classic mistake of conflating the operating system with the applications that run on it. It's perfectly possible to lock down a Windows desktop in the way you describe, and there's very little they can do to mess up anyone but themselves.

The problem comes when someone logged on as that user wants to use an application that, since it is very badly written, has to run with administrative privileges. That is a huge problem in the world of Windows software, but it's due to developer laziness, not a fundamental problem with the operating system itself.

15
2
Silver badge
FAIL

Re: Security 101: If they're sitting at the computer...

".. has to run with administrative privileges..."

The number of times I see this crap regurgitated.

Real world experience of putting Citrix in from the days of yore when most application vendors would ask "what is that?" prove this is utter, total, rubbish. I am yet to see an application that has to run under administrative access with just a little bit of work.

Get a hold of Sysinternals' tools (filemon/regmon as they were and now morphed into procmon) and run it filtered on the application executable and it will show you were access denieds are occurring.

Unlock only the relevant bits for the relevant users.

Job done. Applications that run without having to open the world.

5
4
Silver badge

Re: Security 101: If they're sitting at the computer...

"But at least you can be reasonably assured that this particular hole will be patched when all the libraries go over their code with a fine toothed comb."

That's already been done.

4
2
Silver badge

Re: Security 101: If they're sitting at the computer...

"It's perfectly possible to lock down a Windows desktop in the way you describe, and there's very little they can do to mess up anyone but themselves."

While this is entirely true, the important part of his statement here was 'by a moderately competent user'. Windows can be brought into a locked-down state if you know what you're doing, but it requires a pretty advanced level of knowledge to do so - and that knowledge isn't really that well advertized.

The same is arguably even truer of most Linux distros, of course. Properly configured, Linux is one of the most secure OSes in the world. Improperly configured, it's one of the least secure. Far too many of the more obsessive Linux fans don't recognize this and simply believe putting Linux on a device automatically makes it secure - despite the obvious evidence from the Linux-based Android security hellscape and the IoT security shitshow.

11
0
Bronze badge
Mushroom

Re: Security 101: If they're sitting at the computer...

"Far too many of the more obsessive Linux fans don't recognize this and simply believe putting Linux on a device automatically makes it secure"

The opposite in my experience:

A windows server admin 'friend' decided to set up a linux box... because it's linux, it's inherently secure, so he didn't bother with locking down the firewall at all and just put it in the DMZ. With SSH open to the world. He also thought that 'abc123' was a sufficiently secure password.

It lasted 3 hours.

5
1
Bronze badge

Re: Security 101: If they're sitting at the computer...

It can also be used to write tojans/viruses that can gain root access after being run by a non-privileged user.

0
0
Silver badge

Re: Unlock only the relevant bits for the relevant users.

And you'll still end up having to unlock it every time there's the tiniest problem because question 1 on the script being run by the 1st line support at the vendor is "has it got administrator access", and you need to get past that before you get to anyone who might actually have a clue.

Also by the time you've opened up everything that's needed for whatever cocktail of applications the user is running, and then considered the overlaps then all too often you end up with either an unmaintainable mish mash of dozens of different configurations, or else so many exceptions they may as well have admin access anyway.

Its all very depressing...

1
0
Silver badge

Re: Unlock only the relevant bits for the relevant users.

Rubbish. You should be running the installer with administrative rights and I'm yet to find a piece of software that ordinary users run that re-writes the ACLs on either files or registry keys.

And even then... ever heard of documenting the fix?? Or perhaps scripting it. Old hat, eh?

And if you really find yourself in that position pit AppSense or heat (Lumension as was) on.

Come on. Stop perpetuating the lazy lie.

0
0
Silver badge
Linux

Re: Security 101: If they're sitting at the computer...

Far too many of the more obsessive Linux fans don't recognize this and simply believe putting Linux on a device automatically makes it secure - despite the obvious evidence from the Linux-based Android security hellscape and the IoT security shitshow.

Got a mate who "really knows everything there is to know" who proves the point - he has Linux but, well lets just say 5 different "network managers", only 2 of which I recognise, installs stuff from source files he "finds on the web" rather from the repo's, and of course you have to compile as root rather than doing it from normal user stuff, and you must use root for day-day stuff as having to type your password in every couple of minutes gets annoying (erm, why do you have stuff asking for that so often anyway? Oh, well this tool that checks for malware (another I don't recognise at all!)...)

Contrast that with a number of converts, who sometimes had problems with malware and the like (especially one who does a lot of "left-handed browsing") - they don't consider themselves as power users, just plain "want web/email/farcebook games etc that's it", the LHB one has had linux for 3 or 4 years now without any issues (bar for a mouse/kb I will NEVER touch!), others ranging from a couple of months to a few years who have not had an infection, slow-down or crash in that time (and love how they no longer get "please wait several hours while your machine shuts down/please wait many more hours for it to start" with updates). Next convert is going to be a "the driver where windows is installed is locked" victim who wanted to wipe&start from scratch when his machine sent splat.

TLDR; Yes, there's idiots in every OS, some who think they really know what they're doing but compromise the security of the machine very quickly. But out of the box Linux still is far more secure than Windows (not counting android).

3
0
Silver badge
Linux

Re: Security 101: If they're sitting at the computer...

It lasted 3 hours.

vs what was it, 17 minutes with Windows? (XP or Vista IIRC) And that was without the benefits of SSH.

0
1
Bronze badge
Mushroom

Re: Security 101: If they're sitting at the computer...

It lasted 3 hours.

vs what was it, 17 minutes with Windows? (XP or Vista IIRC) And that was without the benefits of SSH.

Funny you mention it... he was caught out in the days of slammer et al, where the machine got infected in the time it took to install a firewall (I know; he should've had the firewall installer on removable storage - CD-R in those days - and not connected to the net until it was on).

1
0
Silver badge

Re: Security 101: If they're sitting at the computer...

"TLDR; Yes, there's idiots in every OS, some who think they really know what they're doing but compromise the security of the machine very quickly. But out of the box Linux still is far more secure than Windows (not counting android)."

Tbh, I think we need to stop saying that, since it's not actually true. There's too many flavours of Linux out there to make blanket statements. Some distros are an absolute security abortion - even relatively big-name ones like Mint, which has left out certain kernel patches for no good reason for months or years at a time.

Really, we should just never refer to ANYTHING capable of connecting to a network as 'secure out-of-the-box' on general principles; there will be vulnerabilities we don't know about lurking in it, and without patching your secure-out-of-the-box solution will be insecure within 6 months. This seems staggeringly obvious to professionals, but to most consumers the notion that you actually need to make an effort maintain your device is completely alien. We're dumping them into a fast-moving arms race and encouraging them to think they don't need to hit the ground running.

1
1
Silver badge
Linux

Re: Security 101: If they're sitting at the computer...

Really, we should just never refer to ANYTHING capable of connecting to a network as 'secure out-of-the-box' on general principles; there will be vulnerabilities we don't know about lurking in it, and without patching your secure-out-of-the-box solution will be insecure within 6 months.

I did say "far more secure" as opposed to "totally secure". I'm not aware of the patch problem with Mint - I am aware that they can delay some patches but they're delayed on the basis of "more likely to cause problems" from what I know. Certainly I see stuff come through very quickly after a flaw is found, unlike a certain other OS that likes to do it once a month only.

But the case I mentioned with the left-hand browser, he's not got any issues with his machine, and all I've had to do is check backups and updates every few weeks. When he had Windows he was getting infections every few weeks, sometimes more than once in a week. Since he's been on Linux he's had nothing.. Well, nothing comptuer-related anyway.

No connected system is likely to be perfectly secure, not for a while yet anyway (if an OS stopped getting new features and only bugfixes then it should eventually become perfectly secure, but would also become pretty obscure though a lack of new shiny), but some are much better than others at security.

And some just plain suck.

0
0
Silver badge
Mushroom

Why am I not surprised to see sudo there?

Sudo, though available on FreeBSD, has been banned from my servers for a very long time already and quite frankly it doesn't surprise me at all to see it mentioned here. Ever since I learned that it can accept passwords through /dev/stdin and is also set suid root I dumped it (see it's manual page, you'll want the --stdin parameter). The reason why I think that's bad news should be obvious: a simple carefully placed shellscript called 'sudo' can be enough to capture someone's password (man in the middle attack so to speak).

Still, I can't help wonder how hard the BSD's have been tested or if assumptions have been made on that front. Although I definitely agree with the AC above me ("semi-local access is a potential risk per definition") I couldn't help notice the lack of BSD specific examples. The problem I have with that is because BSD has some failsaves in place. For example: security.bsd.stack_guard_page, security.bsd.unprivileged_proc_debug, security.bsd.unprivileged_mlock, security.bsd.map_at_zero. See the sysctl manualpage for more info on that. Note: not all of my examples are relevant to the problem at hand, but I'm trying to showcase that by default BSD already separates quite a bit when it comes to (unprivileged) memory access.

I also can't help wonder what options such as security.bsd.see_other_uids would do. This option effectively hides / blocks access to any process which is run / owned by any other UID than the current user. I know we're talking about direct memory access, but surely you'll need to know what processes to target in order to take 'm over, right?

7
15
Anonymous Coward

Re: Why am I not surprised to see sudo there?

I suspect someone only has a basic knowledge of sudo and shells here. You can lock down bash and sudo quite easily. Shit, you don't even have to use bash.

You can also prevent any account from accessing the shell to minimize the chances of someone pivoting off a service account via a suspect web app etc.

In terms of combatting a "well placed file", a properly implemented inotify setup will help you.

Theres plenty to be done to lock down sudo and reduce the risk of sudo being hijacked.

18
2
Anonymous Coward

Re: Why am I not surprised to see sudo there?

Agreed! The last thing Linux needs is to be easy to configure, then all sorts of plebs will start using it.

Your highly detailed explanation certainly seems more sensible than just blocking sudo, or at least sounds much cleverer....

3
4
Anonymous Coward

Re: Why am I not surprised to see sudo there?

"a simple carefully placed shellscript called 'sudo' can be enough to capture someone's password "

Like, no. Just, no.

10
0
Vic
Silver badge

Re: Why am I not surprised to see sudo there?

a simple carefully placed shellscript called 'sudo' can be enough to capture someone's password

Only if the attacker can already write to places on path - and that would mean he's already got either the user's password or he's got root access...

Vic.

23
0
Silver badge
Devil

Re: Why am I not surprised to see sudo there?

Oh noes! Now you've blocked sudo, so my password stealing script dosn't work :(

Oh well, just need to rename it passwd, or ssh, etc etc.

4
1
hmv

Re: Why am I not surprised to see sudo there?

Or someone has put "." in their $PATH (which used to be known as a Dumb Thing to do; now it may not be quite as well known but just as dumb as ever).

4
0
Silver badge

Re: Why am I not surprised to see sudo there?

If the real "sudo" is deleted by the cautious administrator then presumably a script in current directory named "sudo" will run instead.

1
0
Silver badge
FAIL

Re: Why am I not surprised to see sudo there?

Removing sudo is only half the solution - I've gone one step further and deleted the root user altogether. This is working fine, although I confess I am struggling to log in at the moment as "sshd" doesn't seem to be listening on 22...

16
0
Bronze badge

Re: Why am I not surprised to see sudo there?

"Agreed! The last thing Linux needs is to be easy to configure, then all sorts of plebs will start using it."

Sarcasm aside, you made a valid point here. I find the more "desktop user friendly" Linux gets, the harder it becomes to set up a server or workstation the way I want it. For many long-term users, Linux is a victim of its own success in this regard.

9
0
Vic
Silver badge

Re: Why am I not surprised to see sudo there?

If the real "sudo" is deleted by the cautious administrator then presumably a script in current directory named "sudo" will run instead.

No.

Vic.

8
0
Anonymous Coward

Re: Why am I not surprised to see sudo there?

What you mean is someone has put . at the start of their own $PATH, has a malicious script called exactly "sudo" in their current directory, the user has execution rights on that script and they've executed "sudo" in that current directory and not noticed anything awry.

2
0
Silver badge
Linux

Re: Why am I not surprised to see sudo there?

@HB, yep, including, IMO, the whole systemd stuff, which I don't believe you want anywhere near a server. I suggest you try FreeBSD.

4
1
Silver badge

Re: Why am I not surprised to see sudo there?

Seems to me that, no matter how well you can lock sudo down, it's more secure to remove it.

Why can't you just give the permissions you need to the relevant user? Reliance on sudo seems pretty hacky....

0
8
Anonymous Coward

Re: Why am I not surprised to see sudo there?

"Why can't you just give the permissions you need to the relevant user? "

Because you should always run with the least possible permissions required to do the operation you're carrying out, not the maximum you may need across all operations you might perform.

And because "giving the permissions you need to the relevant user" is exactly what sudo does. How else would you suggest doing it?

9
1
Silver badge

Re: @Robert Carnegie

To provide a slightly more useful answer, and as said it is 'no' because Linux searches your path only, so even if its not in your path but in your directory it won't be run. This is unlike Windows where it will look in your current working directory and with trying various extensions like .exe .com .bat etc.

So if its not in your path you need to use a fully resolvable path such as:

/home/me/sudo (from anywhere)

./sudo (from /home/me or similar as your current working directory)

1
0
Silver badge

Re: Why am I not surprised to see sudo there?

"Why can't you just give the permissions you need to the relevant user? Reliance on sudo seems pretty hacky...."

The reason for 'sudo' was to allow no root account being enable, so (1) any attacker has to know both a sudo-enabled user name AND the matching password, and (2) also to avoid the temptation to log in as root for general work.

2
0

This post has been deleted by its author

Silver badge
Joke

Re: Why am I not surprised to see sudo there?

What you mean is someone has put . at the start of their own $PATH, has a malicious script called exactly "sudo" in their current directory, the user has execution rights on that script and they've executed "sudo" in that current directory and not noticed anything awry.

if systemd goes any further in badly imitating default Windows setup on Linux, then what you described will be the next thing it will do. On top of it, "sudo" will be renamed to "runas" (and "su" will be removed, as no longer needed).

2
0
Silver badge

Re: Why am I not surprised to see sudo there?

"Why can't you just give the permissions you need to the relevant user? "

Because you should always run with the least possible permissions required to do the operation you're carrying out, not the maximum you may need across all operations you might perform.

And because "giving the permissions you need to the relevant user" is exactly what sudo does. How else would you suggest doing it?

I think you are arguing against yourself here - running with the least possible permissions is the opposite of what sudo does. Say you want to run a program to write a CD, and your user does not have access to the CD device. You could run the program with sudo, in which case it can access the DVD device, but also everything else.

Alternatively, you could create a group for CD access, change the group on the device and make it group writable, and add your user to the group. You can then run the program without sudo, and the only thing you can access is the CD device.

2
4
Silver badge

Re: Why am I not surprised to see sudo there? @hmv

Having "::" on your path is as bad. Also, having a trailing colon on the path will also include the current directory in any path searches.

Other stupid things to do include putting relative directories on the path, and also putting non-readonly variables on the path!

0
0
Black Helicopters

Re: Why am I not surprised to see sudo there?

My sshd's NEVER listen on 22.

2
0
Anonymous Coward

Re: Why am I not surprised to see sudo there?

"You could run the program with sudo, in which case it can access the DVD device, but also everything else"

You have a fundamental lack of understanding for how sudo works. Sudo does not simply raise your privileges to root. In fact in proper production systems this should very much be the exception, if it is at all possible.

Sudo is a fully featured privilege escalation programme. You can restrict which binaries may be executed with sudo, you can restrict where things can be run from within sudo, you can restrict which users may be impersonated, you can restrict where the impersonation can take place, you can restrict who may do the impersonation and you can enforce *any combination of these factors*

So it's entirely possible to do something of the form

sudo -u service_account_for_writing_cds /bin/write_a_cd /some/input

where the service_account_for_writing_cds may only read from /some/input and only execute /bin/write_a_cd, and only I may access that service account by inputing my credentials to sudo. And for bonus points that's all written to the audit log.

Or, you do what serious users do and run PowerBroker instead, which makes all of this stuff an absolute doddle.

3
1
Silver badge
Linux

Re: Why am I not surprised to see sudo there?

Why can't you just give the permissions you need to the relevant user? Reliance on sudo seems pretty hacky....

Because then you run into the situation where a text file or basic email message can pwn the computer.

Y'know, like with the stupidly insecure crapfest that is windoze.

(/me needs coffee!)

0
1
Silver badge

Re: Why am I not surprised to see sudo there?

My sshd's NEVER listen on 22.

Mine do.

But that's because they sit behind the firewall which listens on another port.

0
0
Anonymous Coward

HOW?!

You can't just grow the stack into the heap, IIRC we get 8mb of stack space (Java noobs, your stack is different) and then a guard page. Surely this is a case of input not being properly checked?

I am worried about this, but I want more information! You can't just be like "your program takes user input and has a stack, bam I can fuck with it!"

But they gave no details!

13
1
Bronze badge

Re: HOW?!

Hmm, it all sounds like a special case hype. Execution randomization tricks should mitigate this. OpenBSD now even randomizes the memory locations of kernel processes.

6
0
Silver badge

Re: HOW?!

You have to be a bit careful here, because in threaded environments, each thread gets a mini-stack that is actually created on the heap, so overrunning one of these stacks could damage the heap.

You also have variables local to a function context created on the stack, so if local variables are manipulated using unsafe routines that do not perform bounds checking, it is possible to damage surrounding stack frames, which can include the return address for other function calls.

Putting guard pages around each stack frame starts increasing the size of the memory footprint of even the smallest program.

1
0
jch

Re: HOW?!

Read the advisory from Qualys _carefully_ it does explain how it works. I'm sure you'll see a proof-of-concept if not an outright exploit soon as well.

1
0
Silver badge

Email from my email provider yesterday to say they were going to reboot last night because of that. Laptop has just been updated this morning. I'll reboot as soon as I've posted this.

Done and dusted.

3
1
Silver badge
Trollface

Done and dusted.

Don't you have to wait till the last Tuesday of next month or whenever!

How can you possible have a secure OS by releasing patches so soon after a bug is fixed!

0
0
Bronze badge

They didn't manage to break OpenBSD

They managed to crash their own program, after deliberately weakening OpenBSD's default settings.

Whilst the exploit is interesting, there far too much bullshit 1337 haxx0r crowing in their article.

7
1

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017