This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -fno-stack-protector


I can't say "quantitive" has any meaning to me in this context. But as
far as a qualitive approach, SSP seems to simply increase the attack
complexity. It doesn't actually lower the risk of a particular
vulnerability.

I've seen it said in quite a few places that SSP is theoretically (and
maybe practically) not as useful in a situation where an attacker has
local access, but I fail to see how this differs for remote access. If
you don't take into account the specific application (e.g. retry limits)
or any other external actors (e.g. IPS, IDS, etc.), there should not be
a difference, as far as I can see. It is most commonly the case, when
scoring vulnerabilities, that you do not take into account these factors
(e.g. in CVE, while PCI auditing or during actual exploitation). On the
other hand, if the application is confined to a very specific set of
behaviors (as is the case for some network-facing applications on
SELinux-enabled Red Hat systems), the vulnerability could actually be
mitigated instead of just having the bar for exploitability raised.

I would be curious to hear why Red Hat (or Gentoo) is using SSP (et al.)
for applications that they have already developed policies for. Sure, it
could be useful for debugging or testing a policy, but is that why
they're doing it?

Disclaimer: This is not to say that I beleive SSP (or any other such
similar technology) is a waste of time. In fact, it seems to me that
they are certainly useful, reasonably effective and quite practical. I
actually see it on the same level as C's static typing where it's
certainly nice to have, but in reality does not enforce any kind of
policy.

- Anthony

On Tue, 2008-05-06 at 08:00 -0400, Mike Frysinger wrote:
> On Tuesday 06 May 2008, Carlos O'Donell wrote:
> > On Mon, May 5, 2008 at 10:08 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > >  glibc follows the general redhat policy: only daemons that are networked
> > > are built as PIEs with SSP.  that means only nscd is built as a PIE with
> > > SSP enabled.  Hardened Gentoo takes a more extreme approach: build the
> > > entire system as PIEs with SSP.
> >
> > Has anyone written up a quantitative report on the benefits of
> > building the whole system PIE + SSP?
> 
> it's security.  quantitative measuring of how secure things are really isnt 
> doable.  i dont recall ever coming across anything directly applicable/usable 
> in my grad student work wrt security.  plenty of researchers attempting to 
> address the issue in a general non-specific matter, but that's about it.
> 
> the redhat policy PIE/SSP addresses remote access, but it doesnt address local 
> access.  but that's because the redhat policy wrt local access involves 
> selinux, not userspace technologies.
> -mike


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]