Spengler: False Boundaries and Arbitrary Code Execution [LWN.net]

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 14:07 UTC (Wed) by jchaxby (subscriber, #63942) [Link] (18 responses)

Years ago, longer than I like to think, about 6 of the 32 VMS capabilities would allow you to acquire all of them: change-mode-to-kernel and set-privileges are the two I can remember now. There's nothing new under the sun is there?

This potential privilege escalation isn't there so much as to prevent programs from getting real-uid == 0 as to prevent them doing something unintended, somewhat akin to accidentally rebooting the machine.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 15:51 UTC (Wed) by cesarb (subscriber, #6266) [Link] (15 responses)

He is also assuming that the attacker has full control under whatever privileges the daemon has.

If, for instance, the daemon has a bug which allows you to write to an arbitrary path, and it does not have DAC_OVERRIDE and is not running as root, you cannot use that directly to for instance overwrite /etc/shadow. Instead, you have to first find another bug in the daemon (perhaps first writing to some file it will read and misinterpret) to be able to execute arbitrary code under the daemon's privileges. Only then you can exploit the capabilities as he described.

To explain in another way: you have a barrier (the daemon itself) which should pass nothing but accidentally lets pass B and D. The capabilities the daemon has allow it to do A and C. Unless you can own the daemon (thus being able to do anything it can do), you cannot pass the combined barrier, unless the holes happened to align (both the daemon and its capabilities allowed you to do E, for instance).

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 16:09 UTC (Wed) by drag (guest, #31333) [Link] (13 responses)

> He is also assuming that the attacker has full control under whatever privileges the daemon has.

Yes.

That is the point.

The idea behind capabilities is that you can reduce the exploit potential of bugs in otherwise setuid programs. Both Fedora and Ubuntu are expressing interest in eliminating their set of 'setuid by default' programs and replacing it with capabilities system for that expressed purpose.

The theory is that if you get rid of setuid privileges and use capabilities instead then if programs end up having a bug then you won't be handing over full root access.

Spender was pointing out that out of 20 of 35 capabilities offered by the Linux kernel provide little security benefit over just making the binaries 'setuid root' since those capabilities alone are enough to gain full root access. (remember that probably 15 capabilities are relatively safe to delegate and provide advantages over just using setuid root permissions)

The idea is that there remains quite a lot of work to hardening those capabilities to make them safe for their expressed purpose, if that is even possible. (apparently capabilities with PAX can solve most of the issues)

It is important that as administrators that everybody has a good understanding of what is a 'safe' capability versus potential vulnerabilities you may be opening yourself up to if you use them.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 17:17 UTC (Wed) by farnz (subscriber, #17727) [Link]

It depends; even the 20 capabilities that Spender points out are still an improvement on suid root binaries. As cesarb correctly points out, while a daemon running with one of those 20 capabilities is still potentially as dangerous as a suid root binary, there are cases where a bug would allow a daemon running as root unlimited ability to do harm, yet merely permit the capabilities variant to DoS the daemon in question.

As with so much in security, capabilities are not a silver bullet; 15 of them genuinely appear to limit an attacker's options, while the 20 capabilities that can be converted to root are still marginally better than suid root, as they convert a limited set of bugs from exploit to DoS. This doesn't mean that there's no room for improvement, merely that we've taken one more step towards real security.

Remember, too, that in the wider world, security is not a boolean. Even though capabilities as implemented in Linux today are incomplete, they're still a little bit better than suid root (aka full access by default) - after all, if capabilities mean that 1% of the bugs that previously got an attacker root are no longer exploitable, that's a small number of bugs converted from security-critical, will be exploited if not fixed, to fix ASAP, just in case the analysis is incomplete. Further, thinking about caps results in people beginning to think about better routes than all-or-nothing root. It's possible that a side effect of Spender's analysis and distros moving towards caps will be better caps that don't suffer the same problem.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 17:35 UTC (Wed) by iabervon (subscriber, #722) [Link] (11 responses)

They're equivalent to being root in the case of an arbitrary code execution bug. In the case of a bug that only allows the attacker to cause the daemon to perform a particular unintended operation, they are not all the same as root. There are plenty of potential bugs that can only cause the program to write to an unintended file, and if these programs only have special capabilities that don't directly affect permissions, the use of capabilities has prevented an attack. If, for example, there is a process running as nobody with CAP_SETUID which is secure except for insecure temporary file handling (of the sort where the attacker causes the program to open and write to the attacker's choice of path), the attacker won't be able to use this particular bug to get root. He does mention this, saying that a particular bug may have constraints that prohibit using the bug to execute the transitions that the capabilities allow. (In particular, if cron on his system had an insecure temporary file handling bug, having it not run as root and not with capabilities it doesn't actually have would prevent exploitation.)

Of course, arbitrary code execution is probably the most common end result of security hole, simply because once the program is doing something unintended, this starts violating assumptions and causing more unintended behavior.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 21:26 UTC (Wed) by epa (subscriber, #39769) [Link] (10 responses)

If the kernel makes sure that the text segment of a program (its executable code) is read-only, while the data segment is no-execute, does that not eliminate most arbitrary code execution exploits?

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 21:47 UTC (Wed) by cesarb (subscriber, #6266) [Link] (9 responses)

Not as much as one might think, thanks to return-to-libc attacks.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 11:02 UTC (Thu) by epa (subscriber, #39769) [Link] (8 responses)

I see... by overwriting the return address on the stack you can execute pretty much any code you want. I suppose some kind of 'stack guard' checking added by the compiler would mostly stop these attacks? I believe RHEL 5 now has that by default.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 13:54 UTC (Thu) by spender (guest, #23067) [Link] (7 responses)

SSP by no means prevents the ret2libc exploitation technique. It is of some use in preventing exploitation of linear stack overflows, but beyond that, it's none the wiser to exploitation. Consider this simple example:

stackbuf[attacker_controlled_index] = maybe_attacker_controlled_value;

SSP doesn't actually protect any function pointers or saved instruction pointers. It places a cookie it expects to be overwritten in the case of a linear stack overflow that it can check in function epilogues.

A proper ASLR implementation is a more useful mitigation (it helps even in the example above), though it too is of limited use in the presence of an additional info-leak vulnerability. It should be mentioned that SSP is also of limited use in the presence of the same vulnerability (leaking of the random cookie).

No one has real, deterministic protection against ret2libc (yet). Lest I be accused of FUD again by someone in an effort to drive up PaX usage, I won't mention who will be the first to implement this technology.

-Brad

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 16:29 UTC (Thu) by cesarb (subscriber, #6266) [Link] (6 responses)

Wouldn't a separate return address stack, which is accessible only to call and return instructions, completely avoid return-to-libc and related attacks?

For instance, if a processor has a separate hardware return address stack, pushes/pops from it on call/return, and needs a special instruction (not the normal memory load/store instructions) to manipulate it directly, it becomes much harder to manipulate the return address of normal code (you would only be able to manipulate the return address of code which does nasty control flow manipulations, and only if such code reads from somewhere which you can write to).

I can even see how to implement this idea in userspace on common hardware (but in a way no one would do since it would be too slow):

* The kernel makes available a stack in its memory which is not accessible to userspace, and provides system calls to read and write it
* The compiler, in each function's prologue, tells the kernel to push the return address (read from the stack or the return address register, depending on the architecture)
* The compiler, in each function's epilogue, just before the return instruction, asks the kernel for the return address and writes it to where the hardware expects it to be (so the return instruction will read it)

This could even be done within the kernel (and be even slower), by having the special return address stack be on a page which is mapped just before reading/writing and unmapping it from the page tables afterwards.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 16:41 UTC (Thu) by cesarb (subscriber, #6266) [Link] (4 responses)

In fact, I just thought of a way which, while not as secure, should be less slow.

Simply xor the return address in the prologue with a random number, and xor it back just before the return instruction. Two loads, a xor, and a store in the prologue, and again two loads, a xor, and a store in the epilogue. You can save one load if the random value is in a register (but then you add register pressure on x86-32). Should convert a return-to-libc into a jump to a random address, which should be quite effective on 64-bit architectures with lots of unmapped land. As long as the attacker cannot *read* the random number, of course, but it is yet another speed bump. It would be even more secure if the random value was always on a register and never saved to memory.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 19:19 UTC (Thu) by spender (guest, #23067) [Link] (3 responses)

See d.1 of http://pax.grsecurity.net/docs/pax-future.txt
You're only 8 years late ;)

-Brad

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 22:21 UTC (Thu) by cesarb (subscriber, #6266) [Link] (2 responses)

Cool. Has it ever been implemented?

My idea was a bit different; instead of XOR with an ASLR-randomized stack pointer, it would XOR with a cookie read from a global variable (initialized to a random number on a global constructor). So leaking the stack pointer would not be enough, you would need a leak of either the cookie or an obfuscated pointer (which you would then XOR with the expected unobfuscated pointer to recover the cookie). And, as a bonus, it does something useful even without ASLR enabled.

But what to XOR with is only a small detail (and a local decision even, since it is completely contained within each function, so different parts of the same program can XOR with values obtained in different ways even); the main idea, which is to XOR the return address in the stack, is the same both in my comment above and in your link ;-) . I completely forgot about the frame pointer, however (your link didn't).

The main problem with this idea is that it could break GDB badly (as mentioned in the link PaXTeam posted), unless an extension to the debugging format was developed to tell GDB where to find the cookie and which functions need it. Of course, the user can simply zero the cookie within gdb before debugging the program, to prevent the values from being obfuscated.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 7, 2011 21:02 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> Cool. Has it ever been implemented?

search google for the following titles/keywords:

"Embedded Firmware Diversity for Smart Electric Meters"
"Hardware and Binary Modification Support for Code Pointer Protection From Buffer Overflow"
"G-Free: Defeating Return-Oriented Programming through Gadget-less Binaries"
"HyperSafe: A Lightweight Approach to Provide Lifetime Hypervisor Control-Flow Integrity"
"Preventing memory error exploits with WIT"
"Control-Flow Integrity Principles, Implementations, and Applications" (in general, MSR's gleipnir project and the related papers)
"Automated Detection of Persistent Kernel Control-Flow Attacks"

of course this is just a small selection, this area of research goes back to decades (no, it didn't start in security ;-).

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 9, 2011 19:12 UTC (Sun) by nix (subscriber, #2304) [Link]

More examples to add to those PaXTeam suggested: glibc already does this with addresses inside jmp_bufs. This is not the only libc to do that. It is *widely* implemented.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 20:00 UTC (Thu) by PaXTeam (guest, #24616) [Link]

you might be interested in StackGhost then ;).

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 17:41 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

... and quite a few of his examples rely on stealing interactive password entry, which is no kind of substitute for production line instant remote root attacks we're still seeing occasionally today.

I can't tell if this is because there isn't (or Brad couldn't think of) a more practical (which is to say, automatic) root elevation from these privileges, or if he's just being nice by ensuring that POCs inspired by his posting will do something relatively harmless.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 17:38 UTC (Wed) by martinfick (subscriber, #4455) [Link] (1 responses)

> This potential privilege escalation isn't there so much as to prevent programs from getting real-uid == 0 as to prevent them doing something unintended, somewhat akin to accidentally rebooting the machine.

While this may be true in some cases, it is not in others. For example, in the case of linux vservers, capabilities are used to restrict the capabilities of the entire vserver. They are used as a mechanism to isolate vservers from the host. There is a mechanism for a host sysadmin to grant limited capabilities to a vserver when it needs to perform certain privileged operations. Therefor, it should be of concern if granting certain capabilities to a vserver means that users in that vserver can effectively gain more capabilities than the host sysadmin intended them to receive.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 18:03 UTC (Wed) by SEJeff (guest, #51588) [Link]

It seems like Information Assurance in the form of MAC (hello SELinux) is a cleaner option than capabilities where possible. I know that Fedora / RHEL taught libvirtd about SELinux and called it sVirt[1]. This seems like the best possible way forward over simple capabilities.

[1] http://selinuxproject.org/page/SVirt

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 5, 2011 21:18 UTC (Wed) by gmaxwell (guest, #30048) [Link] (1 responses)

Some of the escalations listed related to root owning most system binaries thus the lack of DAC_OVERRIDE being irrelevant for a EUID 0 process being able to modify most of them.

Is there any particular reason that all system binaries, except SUID ones, couldn't be changed to be owned by another user which processes never run as ("bin" perhaps?). Since root normally has DAC_OVERRIDE this shouldn't have a ton of administrative impact but it would reduce that family of loopholes a little bit.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Mar 3, 2011 7:30 UTC (Thu) by roblucid (guest, #48964) [Link]

I don't like the sound of that idea. What programs can root safely run?
IMO root risks privilege escalation via a trojan, any time they execute non-root owned code.
In past under UNIX, many binaries were owned by 'bin', but this just meant gaining user 'bin' was another way to root the box.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 2:05 UTC (Thu) by mheily (subscriber, #27123) [Link] (2 responses)

Ugh. This article is basically FUD intended to scare people into using grsecurity. Notice how there were no actual examples of capabilities being misapplied in the real world. When used appropriately, capabilities are a big improvement over running things as root. My personal favorite is CAP_NET_BIND_SERVICE since it allows non-root users to run daemons that bind to the "privileged ports". It's possible to misuse capabilities to make your system insecure, just like it's possible to misuse chown(1) to make all your files world writable.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 9:33 UTC (Thu) by adisaacs (subscriber, #53996) [Link] (1 responses)

Hardly FUD, it's a useful contribution to the discussion around capabilities and where we need to look to make Linux more secure. I'm grateful to Brad for writing his post, he has thought really deeply about these issues and has a ton of useful advice to give.

(Sure, I wish Brad would post patches upstream rather than letting bugfixes and practial prophylaxes languish in grsecurity, but if I were him and got people badmouthing me with "FUD" every time I write a forum post, I'd probably be cranky too.)

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 14:36 UTC (Thu) by nix (subscriber, #2304) [Link]

Indeed so. This sort of analysis is tedious, boring, and error-prone, so it's good that Brad both did it and solicited comments so he could fix any problems later. Everyone knows that the set of capabilities is irregular and more than slightly badly thought out, but no detailed data was available before now. Figuring out just *what* is wrong with them is the first step to fixing them (hopefully before too many people come to rely on the current set).

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 2:43 UTC (Thu) by Baylink (guest, #755) [Link] (13 responses)

Not having read the full piece yet, the abstract makes this sound as if in fact it supports my argument that using capabilities instead of SUID does nothing productive, instead extending the complexity of the attack surface to the point of unmanagability.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 10:17 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (12 responses)

It's possible to make this argument, but only if you're utterly determined not to be pragmatic. I doubt that's Brad's position (but who knows)

"After two days, the administrator logged in and I was able to retrieve the root password for his su session" is a huge distance from "I ran this script I found on the Internet and got a remote root shell immediately".

Right now these processes have capabilities. The capabilities aren't something new, they're mostly now very old. What will change is that some processes may have _less_ capabilities, which even with Brad's examples makes the work of getting "full root" and thus the ability to cover your tracks, more tricky.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 16:44 UTC (Thu) by PaXTeam (guest, #24616) [Link] (11 responses)

> [local exploit] is a huge distance from [remote exploit].

indeed, but not in the sense you meant it probably ;). it appears you're not the only one not getting spender's post, so here's the simplified logic:

1. some sw runs with privileges (uid or caps)
2. said sw may have exploitable bugs

the question we want to answer is whether we're better off with the uid or the caps based system, security-wise, that is. notice the a priori assumption in 2. it doesn't matter what way you exploit the target, in both privilege systems you get to do the same thing: act as the target. so if you get injected code execution in the target, you get to do whatever you want while having a privileged uid or some caps (if you get to control less in the target, you get to do less in either case too, not just one of them). now with that in mind the question reduces to this: by having a given capability, can one eventually do the same thing as a privileged uid? if the answer is yes, then said capability is not actually useful (and is quite unfixable short of capability explosion). why everyone is or should be interested in this question is also simple: the raison d'etre of capabilities is/was the promise of reduced damage from eventual compromise of privileged targets.

PS: 2 days is nothing for a real life attacker. not even 2 years.

"eventually"

Posted Jan 6, 2011 19:11 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (10 responses)

It's not about "eventually". It was never about "eventually".

Trapdoor functions don't achieve anything "eventually". Bank vaults might as well be glass cabinets "eventually". We're all mortal, the very Earth itself will be just another burnt cinder "eventually".

We're talking about a momentous shift, from CPU cycles to business days and you dismiss it because of "eventually" ?

If Brad was really thinking this way (and I'd rather he spoke for himself) then I'm disappointed.

"eventually"

Posted Jan 6, 2011 19:53 UTC (Thu) by drag (guest, #31333) [Link] (5 responses)

having the ability to sniff passwords/keys/monitor sudo access/etc etc.

All these things quantify as serious issues were you might as well just give them root immediately. Sure there is a practical difference; Maybe somebody has enough intelligence to run a prepared script to exploit a capability-privilaged binary, but not enough smarts enough to know what to do with the ability to ptrace a shell account or whatever... so you _might_ be better off. Maybe not. Maybe you'll win the lottery, too. Maybe nobody will notice that your SMTP server is misconfigured to be a open relay.

But from the perspective of having to actually secure a system it really does not matter.

The difference of a few cycles to get UID0 to a few days to sniff root password is not really a big deal when faced with a exploitable vulnerability.

"eventually"

Posted Jan 6, 2011 20:11 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (4 responses)

So there's no benefit in strong passwords, because they only extend the time taken to guess them when compared to weak passwords? Security isn't a binary decision. A capability-based system may still be insecure, and some capabilities are trivially equivalent to root and therefore pretty much useless. But being able to snoop passwords off a tty isn't a win if the system's only ever logged into via key-based accounts, and so a system where your exploited daemon only gives you that option may be more secure than a system where that daemon gives you root immediately.

"eventually"

Posted Jan 7, 2011 0:34 UTC (Fri) by drag (guest, #31333) [Link] (3 responses)

> So there's no benefit in strong passwords, because they only extend the time taken to guess them when compared to weak passwords?

Isn't this like begging the question, strawman, or some other sort of logical fallacy?

The difference between a weak password (puppy) versus strong password (rE$l1^=^)vCQzI,m>M\m) is several orders of magnitude difference versus what we are discussing here. So much so that it does not have any relevance at all.

> Security isn't a binary decision.

I am glad I never said it was.

> A capability-based system may still be insecure, and some capabilities are trivially equivalent to root and therefore pretty much useless.

It depends on what capabilities your actually enabling. The benefits over 'setuid 0' can range from 'none' to 'everything in the world'.

"eventually"

Posted Jan 7, 2011 0:35 UTC (Fri) by drag (guest, #31333) [Link]

(depending on the situation)

"eventually"

Posted Jan 7, 2011 2:11 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

You said "The difference of a few cycles to get UID0 to a few days to sniff root password is not really a big deal when faced with a exploitable vulnerability", which I think oversimplifies. Whether it's a big deal or not is context dependent, whereas if the daemon were running as uid 0 it'd be guaranteed to be a big deal.

"eventually"

Posted Jan 7, 2011 6:25 UTC (Fri) by dlang (guest, #313) [Link]

a weak password vs a strong password sounds like a similar difference to wha tyou would have between a fraction of a second (clock cycles) and a few days (waiting for someone to login and sniffing their password)

1 second to one day is four orders of magnatude.

"eventually"

Posted Jan 6, 2011 20:21 UTC (Thu) by spender (guest, #23067) [Link] (3 responses)

The PaX Team was trying to give you a second chance to understand. That didn't work, so here's the blunt truth:

The only "huge distance" is between real attackers and your feeble mind. It seems you think hacking = stuff script kiddies do with things they download off the internet. If that's your only concern (and may be legitimate -- perhaps you're a nobody and no one wants to target you directly with a "real" exploit), then you still need to give up this "huge distance" idea.

The reason is simple: it only takes one person to release reusable code for performing these kinds of complex interactions once arbitrary code execution is involved. This is the entire idea of a "virtual playground" I wrote about in the post. If you want real examples of this, look at the capabilities metasploit gives to someone just for writing an exploit within its framework -- remote shells without a shell binary, proxying attacks through several exploited hosts, etc etc -- all without writing to disk. If that's not enough, look at what happened when I released my enlightenment framework for kernel exploits: essentially every exploit released since then has in one form or another been using my code for reliable symbol lookup, disabling of all LSM-based security, and gaining full root and capabilities across nearly all 2.6 kernels.

Basing your security on the benevolence of others is not a sound strategy.

-Brad

"eventually"

Posted Jan 7, 2011 3:38 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

You've substantially changed the post since I read it. Since I can't expect you to provide anything to cite, I will remember in future to cite third party screenshots, as is done for Andy Schlafly, the Awful Poo Lady and other people who try to put their mistakes into the memory hole.

When I read it, your post listed several "and then we wait for the user to enter the root password" type tricks. These can't be sped up using someone else's code, you can only wait for the user to fall into your trap. This might happen in a few minutes, a few days or never at all. There are obvious scenarios where it simply can't work (not to mention you seemed to embarrassingly forget how SSH does its thing)

But the current version of the post is more circumspect, retracting some such examples entirely and replacing others with vaguer claims. I, of course, only found this out when I went back to quote some of the relevant bits and found they were gone.

[ It is generally a truism in security research that flaws only get worse. So imagine my surprise to discover that while yesterday Brad had found 20 out of 35 capabilities to be root-equivalent, today the same code has only 18 root-equivalent capabilities. By the time you read it may be even less ]

"eventually"

Posted Jan 7, 2011 4:41 UTC (Fri) by spender (guest, #23067) [Link]

It said (and has always said) in the first sentence that I intended it to be a reference. I mention in the comments how I've updated the post and given credit to each person that's sent in suggestions/changes either through the site comments or via email.

I didn't "embarrassingly forget how SSH does its thing" -- I still believe the listed attack, now generalized to network services, would be successful in many cases (to deny this is to deny that anyone would click on malicious links or open suspicious attachments, would visit websites that give SSL certificate errors, etc). The only thing that changed was I moved those specific entries into their own section since the immediate example of sshd gives a warning on connect, so listing it wasn't fair. When I first posted the article, it was only 15/35 -- so what's your point? I shouldn't be accurate?

As the PaX Team and I both mentioned already, in the real world, attackers *do not care* if it takes a few minutes or a few days. I assure you they can speed up that process as well (i.e. they don't have to wait for you to feel like connecting on your own). If you had an imagination, you'd be able to figure this out, but it's not common among armchair experts.

-Brad

"eventually"

Posted Jan 7, 2011 22:34 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> It is generally a truism in security research that flaws only get worse.

the truism isn't about the flaws but the attacks (think bugs vs. exploits). in the original attributed to the NSA by Schneier: "Attacks always get better; they never get worse".

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 16:48 UTC (Thu) by nye (subscriber, #51576) [Link] (6 responses)

Some of these capabilities seem so obviously and trivially equivalent to having uid 0 that I wonder if I'm missing something. For example, in what cases would CAP_SET_UID or CAP_CHOWN be useful? Surely you may as well be running as root already.

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 17:49 UTC (Thu) by unBrice (subscriber, #72229) [Link] (5 responses)

You might be inside a chroot-like and only have access to your own files on a filesystem mounted with nosuid,

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 6, 2011 19:24 UTC (Thu) by spender (guest, #23067) [Link] (4 responses)

chroot doesn't matter: in 2002 I wrote in the French MISC magazine 11 ways to break out of a chroot jail. One of them applies here: chroot doesn't matter if you have CAP_SETUID, in fact CAP_SETUID is basically equivalent to CAP_SYS_PTRACE. If i can change to any UID, then I can effectively ptrace any process (including those running outside of the chroot) giving me full control of the host system.

-Brad

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 7, 2011 8:23 UTC (Fri) by job (guest, #670) [Link] (3 responses)

Is this article online?

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 7, 2011 11:38 UTC (Fri) by Aissen (subscriber, #59976) [Link] (2 responses)

I found it here, but it's in french:
http://www.touslesreseaux.com/forum/index.php?showtopic=40

Funny, I think I might still have the magazine (Misc 9) in a box somewhere

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 11, 2011 14:29 UTC (Tue) by job (guest, #670) [Link] (1 responses)

"Page non trouvée". (404)

Spengler: False Boundaries and Arbitrary Code Execution

Posted Jan 11, 2011 14:52 UTC (Tue) by Aissen (subscriber, #59976) [Link]

Seems like I made someone remember about this installed forum, and the article in it by linking to it.

But webarchive still has it:
http://web.archive.org/web/20080609074507/http://www.tous...

Also, a quick pastebin of the text & html versions of the article:
http://pastebin.com/kjCqFnv1