Re: git: be04fec42638 - main - Import _FORTIFY_SOURCE implementation from NetBSD

On Sat, May 18, 2024 at 09:08:48PM -0500, Kyle Evans wrote:
> 
> 
> On 5/18/24 20:09, Pedro Giffuni wrote:
> > (sorry for top posting .. my mailer just sucks)
> > Hi;
> > 
> > I used to like the limited static checking FORTIFY_SOURCE provides and
> > when I ran it over FreeBSD it did find a couple of minor issues. It only
> > works for GCC though.
> > 
> 
> I don't think this is particularly true anymore; I haven't found a case yet
> where __builtin_object_size(3) doesn't give me the correct size while GCC
> did.  I'd welcome counter-examples here, though -- we have funding to both
> finish the project (widen the _FORTIFY_SOURCE net to more of libc/libsys)
> and add tests to demonstrate that it's both functional and correct.  It
> would be useful to also document deficiencies in the tests.
> 
> > I guess it doesn't really hurt to have FORTIFY_SOURCE around and NetBSD
> > had the least intrusive implementation the last time I checked but I
> > would certainly request it should never be activated by default,
> > specially with clang. The GCC version has seen more development on glibc
> > but I still think its a dead end.
> > 
> 
> I don't see a compelling reason to avoid enabling it by default; see above,
> the functionality that we need in clang appears to be just fine (and, iirc,
> was also fine when I checked at the beginning of working on this in 2021)
> and it provides useful
> 
> > What I would like to see working on FreeBSD is Safestack as a
> > replacement for the stack protector, which we were so very slow to adopt
> > even when it was originally developed in FreeBSD. I think other projects
> > based on FreeBSD (Chimera and hardenedBSD) have been using it but I
> > don't know the details.
> > 
> 
> No comment there, though I think Shawn Webb / HardenedBSD had been playing
> around with SafeStack (and might have enabled it? I haven't actually looked
> in a while now).
 
HardenedBSD has enabled SafeStack for userland applications and base
and a few ports. HardenedBSD uses -fstack-protector-all. I don't see
_FORTIFY_SOURCE, SafeStack, and SSP as mutually exclusive. In fact, I
view all three as complementary.

_FORTIFY_SOURCE can have a much wider reach than SafeStack at the
moment. SafeStack cannot be applied to shared objects, only
dynamically-loaded executables (ELF ET_DYN and ET_EXEC). SafeStack
relies on both ASLR and W^X for efficacy. SafeStack cannot be used
with setjmp/longjmp.

I would like to see SafeStack reach completion and have made attempts
in the past to help push the needle in that direction. We need
explicit support in the RTLD and libc in order to apply it to
libraries. Additionally, we would like to apply it to
statically-linked binaries.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc