Here's the problem (found by Björn Esser):
https://bugzilla.redhat.com/show_bug.cgi?id=977446#c10
and then later on:
https://bugzilla.redhat.com/show_bug.cgi?id=977446#c14
So it seems as if _hardened_build for some reason doesn't work for libtool-compiled libraries. It does look as if the correct CFLAGS and LDFLAGS are getting to the build. See for example:
http://koji.fedoraproject.org/koji/buildinfo?buildID=429062 http://kojipkgs.fedoraproject.org//packages/nbdkit/1.0.0/4.fc20/data/logs/x8...
but the plugins from that build are not hardened fully:
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found! Fortify Source functions: no, only unprotected functions found! Read-only relocations: yes Immediate binding: yes
Also we had to add an LDFLAGS hack into the %build section to even get this far.
Any ideas? Is this a bug or how it should be?
Rich.
On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjones@redhat.com wrote:
but the plugins from that build are not hardened fully:
Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening?
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found!
No on-stack arrays that I can find.
Fortify Source functions: no, only unprotected functions found!
I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe. Mirek
On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjones@redhat.com wrote:
but the plugins from that build are not hardened fully:
Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening?
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found!
No on-stack arrays that I can find.
Fortify Source functions: no, only unprotected functions found!
I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe.
Yes, I think you're right. I only checked the simple example* plugins. The xz plugin which is rather more complicated does seem to be protected:
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes
Rich.
On Mon, Jun 24, 2013 at 08:46:51PM +0100, Richard W.M. Jones wrote:
On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones rjones@redhat.com wrote:
but the plugins from that build are not hardened fully:
Isn't it possible that the plugins are just so trivial that there were no opportunities for hardening?
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: no, not found!
No on-stack arrays that I can find.
Fortify Source functions: no, only unprotected functions found!
I can see libc calls with compile-time-known destination sizes except for example1_load () where it can be statically proven the call is safe.
Yes, I think you're right. I only checked the simple example* plugins. The xz plugin which is rather more complicated does seem to be protected:
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes
Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
Rich.
Am 24.06.2013 21:47, schrieb Richard W.M. Jones:
$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes
Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS
IMHO the hardening macro should always step in directly before %configure becaus it does also not work with rpmrc not importing the distribution defaults (for good reasons)
[builduser@buildserver64:~]$ cat /home/builduser/.rpmrc optflags: x86_64 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -maes -pipe -fstack-protector --param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2 -fexceptions
that is why is witched on my private build-environments to manually set all the FLAGS and avoid the hardening-macro at all
[builduser@buildserver64:~]$ cat /rpmbuild/SPECS/dovecot.spec | grep FLAGS export CFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all" export CXXFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all" export FFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all" export CPPFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all" export LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack -pie" export SH_LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack -pie"
On Mon, Jun 24, 2013 at 07:39:59PM -0400, Paul Wouters wrote:
On Mon, 24 Jun 2013, Richard W.M. Jones wrote:
Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?=
It's using autotools. The sources are linked from the bug report and here:
https://github.com/libguestfs/nbdkit/
Rich.
Am Dienstag, den 25.06.2013, 08:29 +0100 schrieb Richard W.M. Jones:
On Mon, Jun 24, 2013 at 07:39:59PM -0400, Paul Wouters wrote:
On Mon, 24 Jun 2013, Richard W.M. Jones wrote:
Note there is still a problem that an LDFLAGS hack was needed in the spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?=
It's using autotools. The sources are linked from the bug report and here:
Hi Rich!
Sorry, I faded away yesterday. I had an appointment with my new sponsoree, so I was busy rest of the day.
The LDFLAGS-Hack in rpm-spec is needed because "libcrap" purges {C, LD}FLAGS, which it thinks are not of use for the linker. The "-spec=..."-cli-switch from gcc is such a case. The "-Wl,z,now"-flag is expanded from such a gcc-spec, but libtool doesn't pass it, because of the explained behaviour.
This is a, not fixed yet, bug in libtool know for years. See: http://bit.ly/15Bnye5
Cheers, Björn