OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Non executable mappings and compatibility options bugs

From: Bill Studenmund (wrstudennetbsd.org)
Date: Tue Jun 22 2004 - 00:22:32 CDT


On Tue, Jun 22, 2004 at 12:40:15AM -0400, Thor Lancelot Simon wrote:
> On Mon, Jun 21, 2004 at 09:26:42PM -0700, Bill Studenmund wrote:
> > On Mon, Jun 21, 2004 at 09:55:17AM -0400, Thor Lancelot Simon wrote:
> > > I strongly disagree; this would be a regression, with no warning to the
> > > user, in system security. Adding a COMPAT_ option shouldn't punch a giant
> > > hole in a fundamental security mechanism.
> >
> > How is this a regression? My understanding of the discussion is we would
>
> I would think that it would be quite simple to see how it's a regression:
> currently, code can be executed from no process's stack. The proposed
> change would allow it to be executed from _some_ processes' stacks.

I don't think it's a regression, because it strikes me that to really
emulate another OS, we need to map things in the same way it does. For us
to impose non-execness on other OSs strikes me as over-eager at best, and
a bug at worst.

> Causing the mere naive addition of COMPAT_FOO to a kernel config file to
> make that fundamental change to the semantics of what user processes can
> and can't do violates the principle of least surprise and is not something
> we should do without warning the user when the kernel's built and when it's
> run.

I also don't think that this behavior is that sacrosanct. Yes, it is a big
deal, and I'm very glad NetBSD has it. Yes, I do understand how it can
close a lot of security vulnerabilities in one act.

But it has neither been in NetBSD for a year nor has it made it into a
NetBSD release. So I do not think that making emulations have the same
security level in 2.0 that they had in 1.6 will be a surprise. As for
advertizing, we need only mention that we added non-exec stacks to only
NetBSD programs, and use it as a reason to favor running programs native.
:-)

And to be honest, if we're going to worry about emulations being less
secure than native apps, I think we should be much more scared of Linux
and IPv6.

> Obviously, if other operating systems have busted dynamic loaders such that
> this change is required to run them, it's necessary to allow correct
> emulation. But it's still a regression in security, and not one that users
> would have any reason to expect, and doing it without huge glaring warnings
> is wrong, wrong, wrong.
>
> Not to mention that, as Charles noted, the case mentioned in the beginning
> of this thread may not even be an example of what we think it is; the
> address in question is in the GOT, and we probably _should_ allow jumping
> there, no?

We probalby should allow jumping there. :-)

If I understood one of Charles's other posts, a.out NetBSD apps (i.e.
our old shared loader) will also be hit with this issue.

Take care,

Bill

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFA18IYWz+3JHUci9cRAmCuAJ95xm6nQDrXOSTPVwvRduZlBMmo2wCcDxHz
OhaPsKm5bFOoCpQ+wqK4DgQ=
=MJts
-----END PGP SIGNATURE-----