Quote
In Ubuntu 6.10 and later versions this option is enabled by default
Bitcoin is build on 10.04 LTS, so it looks like we are using it.That's great, so everybody who uses the binary from bitcoin.org is already having it.
Topic: GCC recommendation: -fstack-protector - page 2. (Read 4721 times)
That's great, so everybody who uses the binary from bitcoin.org is already having it.
I've added the option to the build script of my client, seems to work OK in Linux and Mingw builds.
I did notice that it is important to provide the option to CXXFLAGS as well as LDFLAGS, otherwise it will give errors when linking.
I did notice that it is important to provide the option to CXXFLAGS as well as LDFLAGS, otherwise it will give errors when linking.
Quote
In Ubuntu 6.10 and later versions this option is enabled by default
Bitcoin is build on 10.04 LTS, so it looks like we are using it. Quote
Does it affect performance much?
If not, please submit a pull request, everything that makes bitcoind more safe against future exploits is good.
If not, please submit a pull request, everything that makes bitcoind more safe against future exploits is good.
I could not see any performance differences, but I wanted to hear some more opinions.
I didn't commit that yet because I don't know how such a change would affect people who want to use a compiler other than GCC. Will there be something like a ./configure script in the future? I think the flag must be set at the point where you know what compiler is used.
Does it affect performance much?
If not, please submit a pull request, everything that makes bitcoind more safe against future exploits is good.
If not, please submit a pull request, everything that makes bitcoind more safe against future exploits is good.
I recommend to include the option -fstack-protector to the UNIX makefile. Many distributions (including Ubuntu) use it by default, but some others may not.
Why does it make sense?
On the one hand the Bitcoin client is supposed to be online and connected with many peers. On the other hand it handles data that must be kept secret at all costs.
Thus the client processes messages from unknown peers all the time. If there is a bug in processing, there could be buffer overflows. Those could be exploited to take over the client.
There are three common measurements at the moment against such attacks:
- NX bit: a CPU feature that prevents data from being interpreted as code
- address randomization: the Linux kernel gives each process different stack addresses every time
- GCC stack protector: buffers on stack are surrounded by test data which makes it hard to overflow a buffer without being detected
While the first two are configured by hardware and OS, the third one is configured at compile time.
Any disadvantages?
Of course every measurement of this kind affects Performance. But this affects only functions that have buffers of more than 8 bytes.
And if you have built it on Ubuntu until now, you have had it activated anyway without knowing.
Why does it make sense?
On the one hand the Bitcoin client is supposed to be online and connected with many peers. On the other hand it handles data that must be kept secret at all costs.
Thus the client processes messages from unknown peers all the time. If there is a bug in processing, there could be buffer overflows. Those could be exploited to take over the client.
There are three common measurements at the moment against such attacks:
- NX bit: a CPU feature that prevents data from being interpreted as code
- address randomization: the Linux kernel gives each process different stack addresses every time
- GCC stack protector: buffers on stack are surrounded by test data which makes it hard to overflow a buffer without being detected
While the first two are configured by hardware and OS, the third one is configured at compile time.
Code:
-fstack-protector
Emit extra code to check for buffer overflows, such as stack
smashing attacks. This is done by adding a guard variable to
functions with vulnerable objects. This includes functions that
call alloca, and functions with buffers larger than 8 bytes. The
guards are initialized when a function is entered and then checked
when the function exits. If a guard check fails, an error message
is printed and the program exits.
NOTE: In Ubuntu 6.10 and later versions this option is enabled by
default for C, C++, ObjC, ObjC++, if none of -fno-stack-protector,
-nostdlib, nor -ffreestanding are found.
Emit extra code to check for buffer overflows, such as stack
smashing attacks. This is done by adding a guard variable to
functions with vulnerable objects. This includes functions that
call alloca, and functions with buffers larger than 8 bytes. The
guards are initialized when a function is entered and then checked
when the function exits. If a guard check fails, an error message
is printed and the program exits.
NOTE: In Ubuntu 6.10 and later versions this option is enabled by
default for C, C++, ObjC, ObjC++, if none of -fno-stack-protector,
-nostdlib, nor -ffreestanding are found.
Any disadvantages?
Of course every measurement of this kind affects Performance. But this affects only functions that have buffers of more than 8 bytes.
And if you have built it on Ubuntu until now, you have had it activated anyway without knowing.
Jump to: