Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 May 2015 10:41:17 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Pedro Giffuni <pfg@FreeBSD.org>
Cc:        Alfred Perlstein <alfred@freebsd.org>, freebsd-arch@freebsd.org
Subject:   Re: ASLR work into -HEAD ?
Message-ID:  <1432744877.1200.65.camel@freebsd.org>
In-Reply-To: <5565EB16.20208@FreeBSD.org>
References:  <555CADB6.202@FreeBSD.org> <CAPQ4fftbUUSMHYXjOD-yO0ZzxdKwXzd5LA5AycrEyKMT3o63xw@mail.gmail.com> <555CC369.1030206@FreeBSD.org> <555FBE83.6080103@FreeBSD.org> <CAHM0Q_O4bCTaVi5HvKohrcYE--Yw8Yoo-0wEp1ScnF=qLiiQiQ@mail.gmail.com> <55656245.3000205@freebsd.org> <5565EB16.20208@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2015-05-27 at 11:04 -0500, Pedro Giffuni wrote:
> 
> On 05/27/15 01:20, Alfred Perlstein wrote:
> >
> >
> > On 5/24/15 1:43 PM, K. Macy wrote:
> >> On May 22, 2015 4:41 PM, "Bryan Drewery"<bdrewery@freebsd.org>  wrote:
> >>> On 5/20/2015 12:24 PM, Pedro Giffuni wrote:
> >>>> My claim is that the majority of "professional" breachers and
> >>>> governments already have ASLR workarounds pre-coded and ready
> >>>> to launch. Finding an exploit is more difficult than beating
> >>>> ASLR so they are not going to hint everyone that they have
> >>>> an exploit until they can take all the linux/windows/MacOSX
> >>>> at the same time.
> >>>>
> >>>> The cost for the NSA and/or anonymous to step on
> >>>> ASLR is zero.
> >> Correct. But who are we really protecting against? If it's the NSA only air
> >> gap will really do.  In reality it's just a matter of making the cost of
> >> circumventing protections exceed the value of the data or items being
> >> protected. Locking one's doors and windows doesn't make one's house
> >> impenetrable by any stretch, but it does deter opportunistic passerby.
> >>
> >> Protecting against state overreach is a political matter and shouldn't
> >> factor into whether to invest in deterring lesser malfeasors.
> >>
> >> I'm sorry, but Bryan has it right. The political discussion is a side show.
> >>
> >
> > +1, also having a line item is good.  Not having ASLR just makes 
> > FreeBSD look derp.
> >
> 
> And of course I am in the minority that thinks that just because
> everybody else (or at least the OSs that matter)  has done it
> doesn't necessarily make it a great idea. This will be my last email
> on the subject and I'll stop whining ... promise.
> 
> > DragonFly BSD has an implementation of ASLR based upon OpenBSD's 
> > model, added in 2010.[
> > Microsoft's Windows Vista (released January 2007) and later have ASLR 
> > enabled
> > In 2003, OpenBSD became the first mainstream operating system to 
> > support partial ASLR
> > In Mac OS X Leopard 10.5 (released October 2007), Apple introduced 
> > randomization for system libraries
> >
> > Linux has enabled a weak form of ASLR by default since kernel version 
> > 2.6.12 (released June 2005).
> >
> > So basically 1 more week and we can be 10 years behind Linux. :)
> >
> 
> Happy birthday ASLR? ;) Somehow it hasn't been terribly useful in 10 years,
> and we haven't really missed it, unless there's something I am unaware of
> that the security advisories didn't mention.
> 
> If it comes to adopt things because we have to follow the herd,
> that I guess I prefer the Dragonfly BSD approach:
> 
> - It is a very simple, to-the-point patch.
> - It is off by default (NetBSD too?) but very
>   easy to setup with through a sysctl.
> - Given both points above it is very easy
> to revert once the marketing hype foo dies.
> 
> Again just my uneducated opinion, and I won't
> spend time on the "quick" approach either.
> 
> regards,
> 
> Pedro.

You may be in a minority, but you're not alone.  I just hope that when
this fad fades away we aren't left with a permenent performance hit that
we can't get rid of.  The best way to ensure that is to make sure
there's a no-performance-hit way to disable this stuff on day one.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1432744877.1200.65.camel>