Message-ID: <487E2CE9.8301.1FE8B8D5@pageexec.freemail.hu>
Date:	Wed, 16 Jul 2008 17:16:25 +0200
From:	pageexec@...email.hu
To:	Theodore Tso <tytso@....edu>
CC:	Tiago Assumpcao <tiago@...umpcao.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [stable] Linux 2.6.25.10

On 16 Jul 2008 at 9:21, Theodore Tso wrote:

> On Wed, Jul 16, 2008 at 11:33:12AM +0200, pageexec@...email.hu wrote:
> > not so quick. security is a big field, noone really can claim to be
> > a general expert. Ted knows kerberos but he would be unable to exploit
> > the task refcount leak bug fixed in 2.6.25.10. Stephen and you know
> > MAC systems inside out but you too would be unable to exploit that bug.
> > different domains, different expertise, despite all being 'security'.
> 
> As far as I am concerned, knowing how to exploit a task refcount leak
> bug is a technician's job.

you can try to downplay it like that, but it doesn't make it a simple
technician's job (go tell that to the NSA's red team members ;). exploit
development is an art, it's an expertise that you can't acquire in formal
education for example. that holds for many other aspects of computer
security in fact, that's why it's not an engineering discipline in any
sense that civil or mechanical engineering is. let's wait a few more
decades or centuries, and it will probably become one, but not today.

the reason i mentioned exploit development is actually that if you are
not aware of how you can exploit a bug, you're likely to make a bad
judgement call when you have to decide a bug's exploitability. *that*
will have bad effects on everyone else depending on your judgement.

>  Sure, I can write code that given an
> intercepted or stolen Kerberos srvtab/ketab file, how to forge
> Kerberos tickets.  But at the end of the day, that's perhaps the least
> important part of what a "Security Expert" has to do.  Bruce Schneier
> has written about this extensively.

what is important depends on the situation. for a pentester it's quite
important to be able to write exploits for example.
 
> The important thing to recognize about security is that it is all
> about tradeoffs.  How do you protect the System (which may consist of
> one computers or multiple computers) given a particular threat
> environment, given adversaries with different levels of capability,
> given the consequences of a security breach, and how do you do it
> within a given parameters of cost and usability?  

we have a simpler description for the purpose of security: it's all
about risk management. risk management is indeed about making decisions
that often involve tradeoffs. the responsibility of kernel developers
is, or should be, if it isn't, to help such decisions by not covering
up security fixes.

> This is why there are so many arguments over security.  There are
> disagreements over what deserves more focus and attention, and what is
> and isn't worthwhile trading off against other things.  For example,
> last I looked, PaX significantly reduces the chance of buffer overrun
> attacks, but at the cost of cutting your address space in half and
> forcing you to use a custom-built kernels since modules are not
> supported either (which means no tools like Systemtap, as well).  For
> some people, particularly on 32-bit systems, this is unacceptable.
> But some people might consider that a valid tradeoff.

actually, if we're talking 2.6, that's not true anymore, PaX will use
the hw NX bit if present, else it will fall back to the segmentation
based method. also, there's been module support for years now, in fact
it's better than that of vanilla in that i added proper separation of
rx/rw mappings for modules.

> As another example, take for example some bug that might be able to
> cause a local privilege escalation.  If the machine running that
> particular kernel is part of a computing cluster which is totally
> disconnected from the Internet, that bug is from a security point of
> view totally irrelevant.

not necessarily, it depends on who has local access to that cluster
and whether they separate privileges or not. say, if the admin/user
roles are separate, then it's very much relevant there as well. sure,
the threat model is different, but it doesn't mean it's non-existent.

> So to do a true security analysis about the seriousness of a bug
> *always* requires some amount of context about what the capabilities
> that the adversary might have (or might have acquired).  Given that
> most systems these days are single user systems, a local privilege
> escalation attack may not be as big a of deal in this day and age.
> Many people draw their trust boundary around the entire computer.

in fact, in this day and age of client side bugs (think browsers, media
players, etc), it is even more relevant. not because as if acquiring
normal user privileges didn't already break the given user's security,
but because by elevating to root, an attacker reduces his risk of being
discovered, not to mention gaining access to both the wife's and the
husband's emails at once. FWIW, i'm told that there's windows malware
that uses 0-day for both browser exploitation and local privilege
escalation, there's no reason to believe that the same cannot occur
on linux or elsewhere.

> At the end of the day, it is an engineering discipline, and it is all
> about tradeoffs.  So while it is useful to have people who focus on
> the security of a single box against adversaries who have local shell
> access, it is very easy to lose perspective of the greater security
> picture.

i'm not sure if you're thinking of me as who's losing focus, but let
me tell you why you can't just so easily separate local from remote
bugs. in this age of networks, we do not simply have computer networks,
we also have trust networks. if you have a shell account at mit.edu,
then someone elevating to root there will be able to trigger a client
side ssh bug on your personal box (just an example, don't go looking
for one). in other words, locally exploitable bugs != single box
security.

> I have a theory which is that people who are focused on local system
> security to the exclusion of all else have a high risk of becoming
> unbalanced;

why does asking kernel developers to describe security fixes as such
risk becoming unbalanced?

cheers,
  PaX Team

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists