[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[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. 

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

Signed-off-by: Stefan Fr?berg <stefan.froberg@petroprogram.com>
---
 package/gcc/Config.in.host | 10 ++++++++++
 package/gcc/gcc.mk         |  4 ++++
 2 files changed, 14 insertions(+)

diff --git a/package/gcc/Config.in.host b/package/gcc/Config.in.host
index 70cce0a5c5..bf646fa07b 100644
--- a/package/gcc/Config.in.host
+++ b/package/gcc/Config.in.host
@@ -152,3 +152,13 @@ config BR2_GCC_ENABLE_GRAPHITE
 
 comment "graphite support needs gcc >= 5.x"
 	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5
+
+config BR2_GCC_ENABLE_DEFAULT_PIE
+	bool "Enable default PIE support"
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_6
+	help
+	  This option enables the GCC to make PIE
+	  binaries by default.
+
+comment "default PIE support needs gcc >= 6.x"
+	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_6
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 27fc1e987c..0910fb3932 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -183,6 +183,10 @@ else
 HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
 endif
 
+ifeq ($(BR2_GCC_ENABLE_DEFAULT_PIE),y)
+HOST_GCC_COMMON_CONF_OPTS += --enable-default-pie
+endif
+
 ifeq ($(BR2_arc)$(BR2_or1k),y)
 HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
 endif
-- 
2.13.6

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Thomas Petazzoni]

Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fr?berg wrote:
> 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

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Matthew Weber]

Stefan,

On Dec 28, 2017 4:08 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:

Hello,

On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fr?berg wrote:
> 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

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 ?


I've got a v3 in the works for that one, I can incorporate this into it if
you'd like and send out the set this weekend (currently no computer)

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171228/eda3b18f/attachment.html>

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Stefan Fröberg]

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:
> Hello,
>
> On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fr?berg wrote:
>> 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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171229/b8c720cf/attachment.html>

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Stefan Fröberg]

Actually, now that I think of it...there is also --enable-default-ssp
flag too to
let compiler handle stack-protection automatically too

https://gcc.gnu.org/install/configure.html

|"--enable-default-ssp|
    Turn on -fstack-protector-strong by default. "


-S-


Stefan Fr?berg kirjoitti 29.12.2017 klo 15:25:
> 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:
>> Hello,
>>
>> On Thu, 28 Dec 2017 23:43:33 +0200, Stefan Fr?berg wrote:
>>> 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
>> 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
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171229/59bf1336/attachment.html>

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Thomas Petazzoni]

Hello,

On Fri, 29 Dec 2017 15:25:21 +0200, Stefan Fr?berg wrote:

> 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.

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[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...).

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

-S-

Thomas Petazzoni kirjoitti 29.12.2017 klo 15:42:
> Hello,
>
> On Fri, 29 Dec 2017 15:25:21 +0200, Stefan Fr?berg wrote:
>
>> 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.
> 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

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Thomas Petazzoni]

Hello,

On Fri, 29 Dec 2017 15:48:48 +0200, Stefan Fr?berg wrote:

> 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 ?

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 1/1 v2] gcc: Add support for --enable-default-pie configure option.

[Stefan Fröberg]

Hello


Thomas Petazzoni kirjoitti 29.12.2017 klo 16:04:
> Hello,
>
> On Fri, 29 Dec 2017 15:48:48 +0200, Stefan Fr?berg wrote:
>
>> 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 ?

Except can you be absolute sure that -fpic and -fpie will never happen
in the same commandline
when using just flags?

>> 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

Actually, not true. You already have options like "Enable compiler
link-time-optimization support",
"Enable compiler OpenMP support" and "Enable graphite support".
(with pretty spartan description I might add)

All those are optimization related, activated by built-time
configuration switches.
Mine is security related and also activated by built-time configuration
switch.

And when selecting External toolchain then ...*poof* ... they all vanish
into the air.

So if buildroot would really treat both external and internal toolchain
equally then those options should
also be added when using external toolchain.

-S-