gcc: Add support for --enable-default-pie configure option.

By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie". With that enabled, GCC will produce PIE (Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization) that will make exploits like return-to-libc attack impossible.

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie with your CFLAGS/CXXFLAGS.

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie". With that enabled, GCC will produce PIE (Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization) that will make exploits like return-to-libc attack impossible.

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie with your CFLAGS/CXXFLAGS.

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

Hello,

Quoted 9 lines · Stefan Fr?berg

By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie". With that enabled, GCC will produce PIE (Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization) that will make exploits like return-to-libc attack impossible.

Quoted 6 lines

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie with your CFLAGS/CXXFLAGS.

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

As I said in my previous review, I think we want a solution that also applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO, FORTIFY options" in the mailing list archives,
https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie support, but in a more generic way. Could you use this instead ?

Thanks!

Thomas

Hi Thomas

Yes, of course PIE (and other hardening flags) could be passed with CFLAGS/CXXFLAGS/LDFLAGS.

But what if some package does not care about CFLAGS/CXXFLAGS/LDFLAGS? (Like for example, zlib by default does not do, but I see that buildroot maually passes them
to configure script)

Then you would need to patch all those packages while with default PIE there would
be no need to patch. Compiler would automatically do the right thing

And in the case of PIE, there seems to be tricky rules what to put and where:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages

From the above link:

"The key change is that for PIE builds, compilation for static linking (such as object files which go into the main program, not a library) needs the flag -fPIE.

But this flag /must not be included when compiling for dynamic linking/ because the
resulting object code is not compatible with that.

To repeat, /*you should not specify both -fpic and -fpie on the same command line/*
because this rarely has the intended effect. "

So with default pie built into compiler, the compiler would automatically do the right thing.

Other than letting compiler to handle the PIE and changing "fstack-protector-all" to
"fstack-protector-strong"? (introduced in GCC 4.9, pretty much the same result that "all" but with less performance penalty) that generic hardening patch looks okay to me.

So I suggest that let the compiler handle PIE.

Either builtin (need GCC 6.x + ), with specs file (very ugly and messy but also very effective) or maybe
compiler wrapper (call it "hardened-gcc/g++" or whatever) that I remember Arnout Vandecappelle suggesting.

Best Regards
-S-

Thomas Petazzoni kirjoitti 29.12.2017 klo 00:07:

Quoted 28 lines

Hello,

Quoted 9 lines · Stefan Fr?berg

By default, buildroot produces insecure binaries.

GCC 6.x added build time configuration option "--enable-default-pie". With that enabled, GCC will produce PIE (Position-independent executables) binaries.

PIE is a requirement for ASLR (Address space layout randomization) that will make exploits like return-to-libc attack impossible.

Quoted 6 lines

If you want to have a modern, secure system then enable this option.

To override this default behaviour, you can use -no-pie with your CFLAGS/CXXFLAGS.

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Link-Options.html

As I said in my previous review, I think we want a solution that also applies to external toolchains, by passing -pie in the compiler wrapper.

Please see "[PATCH 2/2] security hardening: add RELFO, FORTIFY options" in the mailing list archives,
https://patchwork.ozlabs.org/patch/830085/, it was also adding -pie support, but in a more generic way. Could you use this instead ?

Thanks!

Quoted 1 line

Thomas

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Yes, of course PIE (and other hardening flags) could be passed with CFLAGS/CXXFLAGS/LDFLAGS.

But what if some package does not care about CFLAGS/CXXFLAGS/LDFLAGS? (Like for example, zlib by default does not do, but I see that buildroot maually passes them
to configure script)

Then you would need to patch all those packages while with default PIE there would
be no need to patch. Compiler would automatically do the right thing

And in the case of PIE, there seems to be tricky rules what to put and where:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages

From the above link:

"The key change is that for PIE builds, compilation for static linking (such as object files which go into the main program, not a library) needs the flag -fPIE.

But this flag /must not be included when compiling for dynamic linking/ because the
resulting object code is not compatible with that.

To repeat, /*you should not specify both -fpic and -fpie on the same command line/*
because this rarely has the intended effect. "

So with default pie built into compiler, the compiler would automatically do the right thing.

Other than letting compiler to handle the PIE and changing "fstack-protector-all" to
"fstack-protector-strong"? (introduced in GCC 4.9, pretty much the same result that "all" but with less performance penalty)
that generic hardening patch looks okay to me.

So I suggest that let the compiler handle PIE.

Hello,

Quoted 33 lines · Stefan Fr?berg

Yes, of course PIE (and other hardening flags) could be passed with CFLAGS/CXXFLAGS/LDFLAGS.

But what if some package does not care about CFLAGS/CXXFLAGS/LDFLAGS? (Like for example, zlib by default does not do, but I see that buildroot maually passes them
to configure script)

Then you would need to patch all those packages while with default PIE there would
be no need to patch. Compiler would automatically do the right thing

And in the case of PIE, there seems to be tricky rules what to put and where:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages

From the above link:

"The key change is that for PIE builds, compilation for static linking (such as object files which go into the main program, not a library) needs the flag -fPIE.

But this flag /must not be included when compiling for dynamic linking/ because the
resulting object code is not compatible with that.

To repeat, /*you should not specify both -fpic and -fpie on the same command line/*
because this rarely has the intended effect. "

So with default pie built into compiler, the compiler would automatically do the right thing.

Quoted 7 lines

Other than letting compiler to handle the PIE and changing "fstack-protector-all" to
"fstack-protector-strong"? (introduced in GCC 4.9, pretty much the same result that "all" but with less performance penalty)
that generic hardening patch looks okay to me.

So I suggest that let the compiler handle PIE.

And what do you propose for external toolchains ?

That's the big limitation in your proposal: it works fine for the internal toolchain, but doesn't work at all for the external toolchain. Hence the discussion on using CFLAGS, or the compiler wrapper.

Thomas

Yeah, there is no other way for external toolchains than generic flags passing (and possibly patching)
or compiler wrapper (well, there is specs file but it's ...soooo messy...).

Personally, Im only interested of internal toolchain (and I think this is not the first case that internal/external toolchains have different rules?)

Hello,

Quoted 3 lines · Stefan Fr?berg

Yeah, there is no other way for external toolchains than generic flags passing (and possibly patching)
or compiler wrapper (well, there is specs file but it's ...soooo messy...).

And since the different method needed for external toolchains would also work for internal toolchains, there is no point in doing a solution that only works for internal toolchains. See my point ?

Quoted 3 lines

Personally, Im only interested of internal toolchain (and I think this is not the first case that internal/external toolchains have different rules?)

We generally try to have internal and external toolchains supported in the same way. You may only be interested in internal toolchains, but Buildroot as a project needs to keep the feature parity between internal and external toolchains, so we would like to have a solution that solves both situations.

Thomas