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 …

  1. This post has been deleted by its author

    1. Anonymous Coward
      Anonymous Coward

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

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

    2. Ken Hagan 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.

    3. JLV

      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.

      1. Electron Shepherd

        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.

        1. TonyJ
          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.

          1. JimC

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

              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.

        2. Naselus

          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.

          1. Anonymous Coward Silver 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.

            1. Kiwi
              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.

              1. Anonymous Coward Silver 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).

          2. Kiwi
            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).

            1. Naselus

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

      2. Doctor Syntax 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. Destroy All Monsters 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?

    5. Jonathan 27

      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.

  2. Anonymous Coward
    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?

    1. Anonymous Coward
      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.

      1. Anonymous Coward
        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....

        1. HieronymusBloggs

          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.

          1. This post has been deleted by its author

            1. sabroni 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....

              1. Anonymous Coward
                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?

                1. Tom 38

                  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.

                  1. Anonymous Coward
                    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.

              2. Paul Crawford 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.

              3. Kiwi
                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!)

    2. Anonymous Coward
      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.

      1. Robert Carnegie 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. Vic

          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.

        2. Paul Crawford 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)

        3. This post has been deleted by its author

    3. Vic

      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.

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

        1. Androgynous Cupboard 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...

          1. Munchausen's proxy
            Black Helicopters

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

            My sshd's NEVER listen on 22.

            1. Kiwi

              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.

        2. Anonymous Coward
          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.

          1. Bronek Kozicki
            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).

        3. Peter Gathercole 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!

    4. phuzz 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.

  3. Doctor Syntax 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.

    1. Kiwi
      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!

  4. BinkyTheMagicPaperclip Silver 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.

  5. John Smith 19 Gold badge
    FAIL

    Not just linux, also OpenBSD, NetBSD, FreeBSD and Solaris on 32-bit and 64-bit x86"

    "developers weren't building their code with sufficient stack protection checks."

    But y'know that secure coding stuff is right tricky and I imagine it's hard work. Let' see what the article has about a fix.

    "The fix, by the way, is to rebuild and reinstall the dynamic library ld.so and executables with gcc's -fstack-check feature, which should kill Stack Clash dead."

    So no, doesn't look like that hard a task to me. But I can already hear the squeal's of "But it'll hurt performance."

    I'll remind devs of DE Knuth's comment about "Premature optimization is the root of most evil." True then. Still true now. Most code does not spend the bulk of its time where you think it does. You should also factor in how often your oh-so-clever creation actually runs.

    If the "normal use case" is it runs 10 times a day and takes 10 seconds, but the secure version takes 11 seconds that's a whole 10 extra seconds a day. IR WTF cares?

    The fact that developing an exploit for this opens up a bunch of *nix variants suggest this would have been a very cost effective tool for "budget minded black hats" to work on.

    And by "budget minded black hats" I'm talking about the T&FLA's who spy on people.

    Developers. This one is on you. Update your build options to stop this happening. I'm quite sure GCC is not the only compiler suite that has this option available.

    1. Graham 32

      Re: Not just linux, also OpenBSD, NetBSD, FreeBSD and Solaris on 32-bit and 64-bit x86"

      "Developers. This one is on you. Update your build options"

      Why is it even an option? If it's the right thing to do the compiler should just work that way all the time (assuming it's an up to date compiler).

      1. John Smith 19 Gold badge
        Unhappy

        "Why is it even an option? "

        Because sometimes it will be the wrong thing to do?

        Because devs are compulsive knob twiddlers?

        Because in developing very large programs devs will favor a faster compile "dev version" of the program than the "full safety check" version, and then forget to change the settings for the compile to the release version?

        Pick any or all of the above.

  6. Brewster's Angle Grinder Silver badge

    Am I naive to think that the code that allocates new stack pages (libc? kernel?) or the code that allocates new heap pages (libc?) should check they're not about to overwrite each other?

    Recursion and alloca aside, the size of stacks are known at compile-time, too.

  7. Anonymous Coward
    Anonymous Coward

    User friendly solution

    From the article: "The fix, by the way, is to rebuild and reinstall the dynamic library ld.so and executables with gcc's -fstack-check feature"

    Again, this is why flavours of Linux have difficulty being accepted in the mainstream for use by Joe Public

    / Rejects asbestos jacket for shield of truth

    1. TonyJ

      Re: User friendly solution

      "...From the article: "The fix, by the way, is to rebuild and reinstall the dynamic library ld.so and executables with gcc's -fstack-check feature"

      Again, this is why flavours of Linux have difficulty being accepted in the mainstream for use by Joe Public

      / Rejects asbestos jacket for shield of truth..."

      No, I don't think it is.

      That's the immediate fix and it will undoubtebly be rolled out as a mainstream fix at some point down the line and is only the same as MS releasing patches before patch Tuesday - it tends to be IT pros that go looking for them, not your average user.

      The two things, in my personal opinion, that have held Linux back from the desktop have been the fact that your average Jill or Joe user goes to their local PC World, and buys whatever is off the shelf that slimy salesperson with no real knowledge sells them. That'll come with a copy of Windows.

      And...they are happy because that's what they use at work.

      Secondly, there's been a traditionally contemptuous barrier to entry on some of the more mainstream Linux forums, such that when they hear about it and decide to give it a go, they get shot down in flames.

      Now I don't know if the latter is still true today, to be honest as I've had no reason to frequent any forums for some time.

    2. Brewster's Angle Grinder Silver badge

      Re: User friendly solution

      Not a linux zealot, but would you trust the people who put it on their desktop or the people who put it on servers (and build it in mobile phones) to have a better grasp of security?

  8. Herby

    sudont

    Enough said.

    If you need root access for some reason, you should know the root password and use su. If you don't know how then who are you anyway, and get off. Sudo is a pretty big crutch, and is used WAY to frequently. Sadly I have to use it as well, but that is a topic for another rant.

    1. englishr
      Linux

      Re: sudont

      @Herby

      My most common sudo use case is to allow users to become another non-root user in a logged shell, e.g.

      %dba ALL=/usr/bin/rootsh -i -u oracle

      So, the DBAs can become the oracle user, but the session is logged. If you have a better way to achieve this, I'd appreciate hearing about it.

  9. Ramazan

    no info on whether their proof-of-concept works on grsec systems

  10. David Roberts

    So,

    sudo su - is a bad thing?

    Oops!

  11. Bronek Kozicki

    Update for 24th June

    Kernels 4.11.7 and 4.9.34 (and soon 4.12) gained some level of protection, thanks to change from Hugh Dickins "mm: larger stack guard gap, between vmas". As explained by author how this works:

    Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot.

    One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units).

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

Other stories you might like