Security quotes of the week

Posted Jun 2, 2012 9:18 UTC (Sat) by AndreE (guest, #60148)
In reply to: Security quotes of the week by hummassa
Parent article: Security quotes of the week

Can you explain further please? "Always will" in particular

Security quotes of the week

Posted Jun 2, 2012 10:23 UTC (Sat) by hummassa (subscriber, #307) [Link] (1 responses)

As I told in my comment above, I don't have a formal proof of that statement. But things go more or less this way: once you have ANY access to a box, you can trip a vulnerability in the stack involved in the access, and from there you can trip another, and another and another until you have whatever you want from that box.

If you have SHELL access to a box, you already can do

echo BYTESBYTES > a.out; chmod +x a.out; ./a.out

where BYTESBYTES is a program with privilege escalation properties, because it trips some vulnerability on the shell or on libc or whatever.

IMNSHO, this will always (for a latu sensu definition of always) be that way because: (1) our systems programming language of choice today (C) is adversarial to the developer by making non-vulnerability-prone programs difficult to write (come on, before C with Classes I would have written C with Well-Managed Strings and Buffers And Access to The Overflow Flag); (2) programmers will always make mistakes; (3) with some rare, academical exceptions, we do not have a proven-secure programming (as in theorem proof) and those are rare and academical because we do not have a lot of proven-secure-capable developers. <rant>It's still hard to find developers that do not ignore the necessity of maintaining and passing my automated test suites, and those are not rigorous by any standards</rant>.

Security quotes of the week

Posted Jun 4, 2012 12:29 UTC (Mon) by nix (subscriber, #2304) [Link]

Even if we had all of those things, it still would not help. All you need for privilege escalation vulnerabilities is a system with sufficiently many interacting parts that you can't hold them all in your head at once, where some of those parts act as switches that ask 'is privilege escalated?' or act to escalate privilege. All OS kernels are far, far into this domain. Even reducing the number of priv-test-and-set points to one each wouldn't help, because those points would be used from many places... the real enemy here, as in so many other places, is complexity -- but this is at least partly *necessary* complexity.

(For extra points, the system must have sufficiently many interacting parts that you can't formally prove that nothing done excepting a few specific intended things can lead to privilege escalation, but since to a first approximation nobody ever formally proves their code correct in this fashion this is overkill).