[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Fabrice Fontaine]

Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
default.

This could help making IoT more secure and fight against the assumption
that buildroot does not support binary hardening (see
https://cyber-itl.org/2019/08/26/iot-data-writeup.html)

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
Changes v2 -> v3:
 - Drop BR2_ENABLE_SSP comment from Config.in.legacy
 - Drop condition on second RELRO default (after Yann E. Morin review)
 - Set BR2_FORTIFY_SOURCE_1 by default (after Yann E. Morin and Matthew
   Weber review)

Changes v1 -> v2:
 - Use RELRO_PARTIAL if toolchain does not support PIE
 - Enable BR2_FORTIFY_SOURCE_2 by default

 Config.in        | 6 +++++-
 Config.in.legacy | 1 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Config.in b/Config.in
index e35a78fb71..6d954e1e0f 100644
--- a/Config.in
+++ b/Config.in
@@ -715,6 +715,7 @@ comment "Security Hardening Options"
 
 config BR2_PIC_PIE
 	bool "Build code with PIC/PIE"
+	default y
 	depends on BR2_SHARED_LIBS
 	depends on BR2_TOOLCHAIN_SUPPORTS_PIE
 	help
@@ -727,7 +728,7 @@ comment "PIC/PIE needs a toolchain w/ PIE"
 
 choice
 	bool "Stack Smashing Protection"
-	default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
+	default BR2_SSP_ALL
 	depends on BR2_TOOLCHAIN_HAS_SSP
 	help
 	  Enable stack smashing protection support using GCC's
@@ -789,6 +790,8 @@ comment "Stack Smashing Protection needs a toolchain w/ SSP"
 
 choice
 	bool "RELRO Protection"
+	default BR2_RELRO_FULL if BR2_TOOLCHAIN_SUPPORTS_PIE
+	default BR2_RELRO_PARTIAL
 	depends on BR2_SHARED_LIBS
 	help
 	  Enable a link-time protection know as RELRO (RELocation Read
@@ -825,6 +828,7 @@ comment "RELocation Read Only (RELRO) needs shared libraries"
 
 choice
 	bool "Buffer-overflow Detection (FORTIFY_SOURCE)"
+	default BR2_FORTIFY_SOURCE_1
 	depends on BR2_TOOLCHAIN_USES_GLIBC
 	depends on !BR2_OPTIMIZE_0
 	help
diff --git a/Config.in.legacy b/Config.in.legacy
index 629d02dbf2..4b920b400e 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -3527,7 +3527,6 @@ config BR2_PACKAGE_PYTHON_PYXML
 	  PyXML is obsolete and its functionality is covered either via
 	  native Python XML support or python-lxml package.
 
-# BR2_ENABLE_SSP is still referenced in Config.in (default in choice)
 config BR2_ENABLE_SSP
 	bool "Stack Smashing protection now has different levels"
 	help
-- 
2.30.2

[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Yann E. MORIN]

Fabrice, All,

On 2021-05-03 20:22 +0200, Fabrice Fontaine spake thusly:
> Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
> default.
> 
> This could help making IoT more secure and fight against the assumption
> that buildroot does not support binary hardening (see
> https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> Changes v2 -> v3:
>  - Drop BR2_ENABLE_SSP comment from Config.in.legacy
>  - Drop condition on second RELRO default (after Yann E. Morin review)
>  - Set BR2_FORTIFY_SOURCE_1 by default (after Yann E. Morin and Matthew
>    Weber review)
> 
> Changes v1 -> v2:
>  - Use RELRO_PARTIAL if toolchain does not support PIE
>  - Enable BR2_FORTIFY_SOURCE_2 by default
> 
>  Config.in        | 6 +++++-
>  Config.in.legacy | 1 -
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Config.in b/Config.in
> index e35a78fb71..6d954e1e0f 100644
> --- a/Config.in
> +++ b/Config.in
> @@ -715,6 +715,7 @@ comment "Security Hardening Options"
>  
>  config BR2_PIC_PIE
>  	bool "Build code with PIC/PIE"
> +	default y
>  	depends on BR2_SHARED_LIBS
>  	depends on BR2_TOOLCHAIN_SUPPORTS_PIE
>  	help
> @@ -727,7 +728,7 @@ comment "PIC/PIE needs a toolchain w/ PIE"
>  
>  choice
>  	bool "Stack Smashing Protection"
> -	default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
> +	default BR2_SSP_ALL

While discussing this with Matt on IRC, we noticed that SSP-all can have
quite a significant impact on performance, and that SSP-strong (when
available) would be a better default (resorting to SSP-regular
otherwise).

Yes, this decreases the security level Buildroot wil use by default. But
security is always to be balanced against performance, and this is always
a tricky choice to make; I believe relaxing SSP was striking a good
balance (especially since, today, most gcc versions should have
SSP-strong available).

Applied to master, thank you!

Regards,
Yann E. MORIN.

>  	depends on BR2_TOOLCHAIN_HAS_SSP
>  	help
>  	  Enable stack smashing protection support using GCC's
> @@ -789,6 +790,8 @@ comment "Stack Smashing Protection needs a toolchain w/ SSP"
>  
>  choice
>  	bool "RELRO Protection"
> +	default BR2_RELRO_FULL if BR2_TOOLCHAIN_SUPPORTS_PIE
> +	default BR2_RELRO_PARTIAL
>  	depends on BR2_SHARED_LIBS
>  	help
>  	  Enable a link-time protection know as RELRO (RELocation Read
> @@ -825,6 +828,7 @@ comment "RELocation Read Only (RELRO) needs shared libraries"
>  
>  choice
>  	bool "Buffer-overflow Detection (FORTIFY_SOURCE)"
> +	default BR2_FORTIFY_SOURCE_1
>  	depends on BR2_TOOLCHAIN_USES_GLIBC
>  	depends on !BR2_OPTIMIZE_0
>  	help
> diff --git a/Config.in.legacy b/Config.in.legacy
> index 629d02dbf2..4b920b400e 100644
> --- a/Config.in.legacy
> +++ b/Config.in.legacy
> @@ -3527,7 +3527,6 @@ config BR2_PACKAGE_PYTHON_PYXML
>  	  PyXML is obsolete and its functionality is covered either via
>  	  native Python XML support or python-lxml package.
>  
> -# BR2_ENABLE_SSP is still referenced in Config.in (default in choice)
>  config BR2_ENABLE_SSP
>  	bool "Stack Smashing protection now has different levels"
>  	help
> -- 
> 2.30.2
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Romain Naour]

Le 03/05/2021 ? 22:41, Yann E. MORIN a ?crit?:
> Fabrice, All,
> 
> On 2021-05-03 20:22 +0200, Fabrice Fontaine spake thusly:
>> Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
>> default.
>>
>> This could help making IoT more secure and fight against the assumption
>> that buildroot does not support binary hardening (see
>> https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
>>
>> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
>> ---
[...]
>> diff --git a/Config.in b/Config.in
>> index e35a78fb71..6d954e1e0f 100644
>> --- a/Config.in
>> +++ b/Config.in
>> @@ -715,6 +715,7 @@ comment "Security Hardening Options"
>>  
>>  config BR2_PIC_PIE
>>  	bool "Build code with PIC/PIE"
>> +	default y
>>  	depends on BR2_SHARED_LIBS
>>  	depends on BR2_TOOLCHAIN_SUPPORTS_PIE
>>  	help
>> @@ -727,7 +728,7 @@ comment "PIC/PIE needs a toolchain w/ PIE"
>>  
>>  choice
>>  	bool "Stack Smashing Protection"
>> -	default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
>> +	default BR2_SSP_ALL
> 
> While discussing this with Matt on IRC, we noticed that SSP-all can have
> quite a significant impact on performance, and that SSP-strong (when
> available) would be a better default (resorting to SSP-regular
> otherwise).
> 
> Yes, this decreases the security level Buildroot wil use by default. But
> security is always to be balanced against performance, and this is always
> a tricky choice to make; I believe relaxing SSP was striking a good
> balance (especially since, today, most gcc versions should have
> SSP-strong available).
> 
> Applied to master, thank you!
> 

It seems that some defconfigs are failing to build with this option by default:
https://gitlab.com/kubu93/buildroot/-/pipelines/299584088

At least:
qemu_riscv32_virt_defconfig
https://gitlab.com/kubu93/buildroot/-/jobs/1247043359

qemu_s390x_defconfig
https://gitlab.com/kubu93/buildroot/-/jobs/1247043361

(I was testing the new qemu 6.0.0)

Best regards,
Romain


> Regards,
> Yann E. MORIN.
> 

[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Fabrice Fontaine]

Hi Romain,

Thanks for warning me about these failures.

Le sam. 8 mai 2021 ? 17:37, Romain Naour <romain.naour@gmail.com> a ?crit :
>
> Le 03/05/2021 ? 22:41, Yann E. MORIN a ?crit :
> > Fabrice, All,
> >
> > On 2021-05-03 20:22 +0200, Fabrice Fontaine spake thusly:
> >> Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
> >> default.
> >>
> >> This could help making IoT more secure and fight against the assumption
> >> that buildroot does not support binary hardening (see
> >> https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
> >>
> >> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> >> ---
> [...]
> >> diff --git a/Config.in b/Config.in
> >> index e35a78fb71..6d954e1e0f 100644
> >> --- a/Config.in
> >> +++ b/Config.in
> >> @@ -715,6 +715,7 @@ comment "Security Hardening Options"
> >>
> >>  config BR2_PIC_PIE
> >>      bool "Build code with PIC/PIE"
> >> +    default y
> >>      depends on BR2_SHARED_LIBS
> >>      depends on BR2_TOOLCHAIN_SUPPORTS_PIE
> >>      help
> >> @@ -727,7 +728,7 @@ comment "PIC/PIE needs a toolchain w/ PIE"
> >>
> >>  choice
> >>      bool "Stack Smashing Protection"
> >> -    default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
> >> +    default BR2_SSP_ALL
> >
> > While discussing this with Matt on IRC, we noticed that SSP-all can have
> > quite a significant impact on performance, and that SSP-strong (when
> > available) would be a better default (resorting to SSP-regular
> > otherwise).
> >
> > Yes, this decreases the security level Buildroot wil use by default. But
> > security is always to be balanced against performance, and this is always
> > a tricky choice to make; I believe relaxing SSP was striking a good
> > balance (especially since, today, most gcc versions should have
> > SSP-strong available).
> >
> > Applied to master, thank you!
> >
>
> It seems that some defconfigs are failing to build with this option by default:
> https://gitlab.com/kubu93/buildroot/-/pipelines/299584088
>
> At least:
> qemu_riscv32_virt_defconfig
> https://gitlab.com/kubu93/buildroot/-/jobs/1247043359
This one should be fixed by
https://patchwork.ozlabs.org/project/buildroot/patch/20210508194155.3678473-2-fontaine.fabrice at gmail.com/
>
> qemu_s390x_defconfig
> https://gitlab.com/kubu93/buildroot/-/jobs/1247043361
This one should be fixed by
https://patchwork.ozlabs.org/project/buildroot/patch/20210509091800.708933-1-fontaine.fabrice at gmail.com/

Do you think there are other failures that are related to the activation of SSP?
>
> (I was testing the new qemu 6.0.0)
>
> Best regards,
> Romain
>
>
> > Regards,
> > Yann E. MORIN.
> >
Best Regards,

Fabrice

[Buildroot] [PATCH v3, 1/1] Config.in: enable FORTIFY_SOURCE, PIC/PIE, RELRO, SSP by default

[Romain Naour]

Hi Fabrice,

Le 09/05/2021 ? 11:22, Fabrice Fontaine a ?crit?:
> Hi Romain,
> 
> Thanks for warning me about these failures.

You're welcome.

> 
> Le sam. 8 mai 2021 ? 17:37, Romain Naour <romain.naour@gmail.com> a ?crit :
>>
>> Le 03/05/2021 ? 22:41, Yann E. MORIN a ?crit :
>>> Fabrice, All,
>>>
>>> On 2021-05-03 20:22 +0200, Fabrice Fontaine spake thusly:
>>>> Enhance security by enabling FORTIFY_SOURCE, PIC/PIE, RELRO and SSP by
>>>> default.
>>>>
>>>> This could help making IoT more secure and fight against the assumption
>>>> that buildroot does not support binary hardening (see
>>>> https://cyber-itl.org/2019/08/26/iot-data-writeup.html)
>>>>
>>>> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
>>>> ---
>> [...]
>>>> diff --git a/Config.in b/Config.in
>>>> index e35a78fb71..6d954e1e0f 100644
>>>> --- a/Config.in
>>>> +++ b/Config.in
>>>> @@ -715,6 +715,7 @@ comment "Security Hardening Options"
>>>>
>>>>  config BR2_PIC_PIE
>>>>      bool "Build code with PIC/PIE"
>>>> +    default y
>>>>      depends on BR2_SHARED_LIBS
>>>>      depends on BR2_TOOLCHAIN_SUPPORTS_PIE
>>>>      help
>>>> @@ -727,7 +728,7 @@ comment "PIC/PIE needs a toolchain w/ PIE"
>>>>
>>>>  choice
>>>>      bool "Stack Smashing Protection"
>>>> -    default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
>>>> +    default BR2_SSP_ALL
>>>
>>> While discussing this with Matt on IRC, we noticed that SSP-all can have
>>> quite a significant impact on performance, and that SSP-strong (when
>>> available) would be a better default (resorting to SSP-regular
>>> otherwise).
>>>
>>> Yes, this decreases the security level Buildroot wil use by default. But
>>> security is always to be balanced against performance, and this is always
>>> a tricky choice to make; I believe relaxing SSP was striking a good
>>> balance (especially since, today, most gcc versions should have
>>> SSP-strong available).
>>>
>>> Applied to master, thank you!
>>>
>>
>> It seems that some defconfigs are failing to build with this option by default:
>> https://gitlab.com/kubu93/buildroot/-/pipelines/299584088
>>
>> At least:
>> qemu_riscv32_virt_defconfig
>> https://gitlab.com/kubu93/buildroot/-/jobs/1247043359
> This one should be fixed by
> https://patchwork.ozlabs.org/project/buildroot/patch/20210508194155.3678473-2-fontaine.fabrice at gmail.com/
>>
>> qemu_s390x_defconfig
>> https://gitlab.com/kubu93/buildroot/-/jobs/1247043361
> This one should be fixed by
> https://patchwork.ozlabs.org/project/buildroot/patch/20210509091800.708933-1-fontaine.fabrice at gmail.com/
> 
> Do you think there are other failures that are related to the activation of SSP?

I did another test with master branch and there are the same issues:
https://gitlab.com/kubu93/buildroot/-/pipelines/299615886

For nios2, the system doesn't boot as soon as BR2_PIC_PIE is set.

I started to look at ppc e500mc if the issue is also related to BR2_PIC_PIE
option but I need time to investigate.

Best regards,
Romain


>>
>> (I was testing the new qemu 6.0.0)
>>
>> Best regards,
>> Romain
>>
>>
>>> Regards,
>>> Yann E. MORIN.
>>>
> Best Regards,
> 
> Fabrice
>