"eventually"

Posted Jan 6, 2011 19:11 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: Spengler: False Boundaries and Arbitrary Code Execution by PaXTeam
Parent article: Spengler: False Boundaries and Arbitrary Code Execution

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