standalone fortify source implementation

standalone fortify source implementation

[Dimitris Papastamos]

Hi everyone,

I have been working on a standalone fortify source implementation[0] that
uses GCC's #include_next to overlay over the system headers.  The current
implementation has been tested against musl libc and OpenBSD's libc.

This implementation only supports _FORTIFY_SOURCE=1.  Level 2 is the same
as level 1.  If this is to be used by default on a system it makes sense
to only catch cases where UB would be invoked (level 1) rather than trap
on suspicious but legal code (level 2).

At the moment only out of bound writes are caught.  Should the implementation
trap on out of bound reads as well?

Overlap checks have been added to memcpy() and will probably be added to
other functions as well.

A short list of functions that still need to be covered:

* wide versions of existing functions
* confstr()
* fread()
* getcwd()
* getgroups()
* gethostname()
* poll()/ppoll()
* readlink()/readlinkat()
* reentrant variants such as ttyname_r, getlogin_r() etc.

I've received very useful feedback from dalias and fabled on IRC.  I
am putting this out here so that more people can have a look and share their
comments.

Thanks,
Dimitris

[0] http://git.2f30.org/fortify/

Re: standalone fortify source implementation

[Daniel Cegiełka]

2015-02-04 17:02 GMT+01:00 Dimitris Papastamos <sin@2f30.org>:
> Hi everyone,
>
> I have been working on a standalone fortify source implementation[0] that
> uses GCC's #include_next to overlay over the system headers.  The current
> implementation has been tested against musl libc and OpenBSD's libc.
>
> This implementation only supports _FORTIFY_SOURCE=1.  Level 2 is the same
> as level 1.  If this is to be used by default on a system it makes sense
> to only catch cases where UB would be invoked (level 1) rather than trap
> on suspicious but legal code (level 2).

Rich is planning this type of functionality:

http://www.openwall.com/lists/musl/2013/08/30/1

Isn't it better to establish a collaboration here?

Daniel

Re: standalone fortify source implementation

[Dimitris Papastamos]

On Wed, Feb 04, 2015 at 05:21:21PM +0100, Daniel Cegiełka wrote:
> 2015-02-04 17:02 GMT+01:00 Dimitris Papastamos <sin@2f30.org>:
> > Hi everyone,
> >
> > I have been working on a standalone fortify source implementation[0] that
> > uses GCC's #include_next to overlay over the system headers.  The current
> > implementation has been tested against musl libc and OpenBSD's libc.
> >
> > This implementation only supports _FORTIFY_SOURCE=1.  Level 2 is the same
> > as level 1.  If this is to be used by default on a system it makes sense
> > to only catch cases where UB would be invoked (level 1) rather than trap
> > on suspicious but legal code (level 2).
> 
> Rich is planning this type of functionality:
> 
> http://www.openwall.com/lists/musl/2013/08/30/1
> 
> Isn't it better to establish a collaboration here?

Yes this is intended to be an implementation of that idea.  I found
out about this open issue from the musl wiki[0].

[0] http://wiki.musl-libc.org/wiki/Open_Issues#Substitute_for_FORTIFY_SOURCE

Re: standalone fortify source implementation

[Rich Felker]

On Wed, Feb 04, 2015 at 05:21:21PM +0100, Daniel Cegiełka wrote:
> 2015-02-04 17:02 GMT+01:00 Dimitris Papastamos <sin@2f30.org>:
> > Hi everyone,
> >
> > I have been working on a standalone fortify source implementation[0] that
> > uses GCC's #include_next to overlay over the system headers.  The current
> > implementation has been tested against musl libc and OpenBSD's libc.
> >
> > This implementation only supports _FORTIFY_SOURCE=1.  Level 2 is the same
> > as level 1.  If this is to be used by default on a system it makes sense
> > to only catch cases where UB would be invoked (level 1) rather than trap
> > on suspicious but legal code (level 2).
> 
> Rich is planning this type of functionality:
> 
> http://www.openwall.com/lists/musl/2013/08/30/1
> 
> Isn't it better to establish a collaboration here?

This is the result of that collaboration.

Rich

Re: standalone fortify source implementation

[Dimitris Papastamos]

Hi all,

Having had a chat with the Alpine Linux developers, I'd like some
feedback on what is the recommended way of integrating this standalone fortify
implementation by default in a distribution.

Would it simply be a matter of adding another include dir in gcc specs
that gets preference over /usr/include?

In regards to glibc binary compatibility, will the __*_chk() symbols be
part of musl or would it be in a separate glibc compat shared library?

Cheers,
Dimitris