Hello folks, I'm looking at this feature:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages
<quote> How To Test
Running checksec should always report only
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH
otherwise a tracking bug should exist for the respective packages </quote>
On a current Rawhide installation I'm seeing lots of potential failures, for example:
Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH
Question is how to deal with these because they appear to be in the hundreds ?
I will do my best to filter out any false negatives and group the results per package but this still leaves quite a big number of bugs to report.
How do you feel about reporting all of these offences automatically ? Are there any known exceptions which should be mentioned in the wiki page above ?
-- Alex
On Friday, 11 September 2015 at 13:50, Alexander Todorov wrote:
Hello folks, I'm looking at this feature:
https://fedoraproject.org/wiki/Changes/Harden_All_Packages
<quote> How To Test
Running checksec should always report onlyFull RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH
otherwise a tracking bug should exist for the respective packages
</quote>
On a current Rawhide installation I'm seeing lots of potential failures, for example:
Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH
Question is how to deal with these because they appear to be in the hundreds ?
How many, exactly? We have around 20000 SRPMs in the distribution.
I will do my best to filter out any false negatives and group the results per package but this still leaves quite a big number of bugs to report.
How do you feel about reporting all of these offences automatically ? Are there any known exceptions which should be mentioned in the wiki page above ?
Some RPATHs are acceptable, in general: %{_libdir}/foo. See https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libra...
Regards, Dominik
На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
Question is how to deal with these because they appear to be in the hundreds ?
How many, exactly? We have around 20000 SRPMs in the distribution.
On a system with 1170 packages installed I got 233 reported as failed. I'll try to get an exact number for all of the packages but my guess is over 1000.
This excludes most libraries (where instead of PIE enabled, checksec reports DSO) and excludes acceptable RPATHs (/usr/lib.*/.*).
The list is at: https://github.com/atodorov/fedora-scripts/blob/master/checksec.log
The script which produced it is at: https://github.com/atodorov/fedora-scripts/blob/master/checksec-collect
Packages like grub2 should probably be excluded, maybe also -devel ones or files like .o .a ? Are there any other packages that need to be excluded ?
I will also bring this up on fedora-devel in accordance with the mass bug filing wiki page before doing anything further.
-- Alex
Including fedora-devel on this topic.
На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
Question is how to deal with these because they appear to be in the hundreds ?
How many, exactly? We have around 20000 SRPMs in the distribution.
From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
Please let me know which packages need to genuinely be excluded and what should we do with these packages ? Some will probably be fixed once they are rebuilt but that may take a while.
Any package maintainers out there - please fix your packages in Rawhide so we don't have to file bugs for all of them.
Thanks, Alex
On 09/16/2015 10:24 AM, Alexander Todorov wrote:
Including fedora-devel on this topic.
На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
Question is how to deal with these because they appear to be in the hundreds ?
How many, exactly? We have around 20000 SRPMs in the distribution.
From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
Please let me know which packages need to genuinely be excluded and what should we do with these packages ? Some will probably be fixed once they are rebuilt but that may take a while.
Any package maintainers out there - please fix your packages in Rawhide so we don't have to file bugs for all of them.
I think we may have an issue with libtool throwing away the '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' option:
/bin/sh ../libtool --tag=CC --mode=link gcc -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O -fomit-frame-pointer -finline-functions -O2 -g -pipe -Wall -Werror=format-s ecurity -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -version-info 10:1 :0 -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libhdf5.la -rpath /usr/lib64 H5.lo.... H5Ztrans.lo -lz -ldl -lm
libtool: link: gcc -shared -fPIC -DPIC .libs/H5.o ... .libs/H5Ztrans.o -lz -ldl -lm -O -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,-soname -Wl,libhdf5.so.10 -o .libs/libhdf5.so.10.0.1
On 09/16/2015 11:08 AM, Orion Poplawski wrote:
On 09/16/2015 10:24 AM, Alexander Todorov wrote:
From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
Please let me know which packages need to genuinely be excluded and what should we do with these packages ? Some will probably be fixed once they are rebuilt but that may take a while.
Any package maintainers out there - please fix your packages in Rawhide so we don't have to file bugs for all of them.
I think we may have an issue with libtool throwing away the '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' option:
/bin/sh ../libtool --tag=CC --mode=link gcc -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O -fomit-frame-pointer -finline-functions -O2 -g -pipe -Wall -Werror=format-s ecurity -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -version-info 10:1 :0 -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libhdf5.la -rpath /usr/lib64 H5.lo.... H5Ztrans.lo -lz -ldl -lm
libtool: link: gcc -shared -fPIC -DPIC .libs/H5.o ... .libs/H5Ztrans.o -lz -ldl -lm -O -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,-soname -Wl,libhdf5.so.10 -o .libs/libhdf5.so.10.0.1
Looks like this has been known for two years:
Bug 985592 libtool + %global _hardened_build 1 = no full hardening - https://bugzilla.redhat.com/985592
Reported upstream but no response:
http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg00000.html
Work around would be to use -Wc,-specs=...
On 09/16/2015 11:08 AM, Orion Poplawski wrote:
On 09/16/2015 10:24 AM, Alexander Todorov wrote:
From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
Please let me know which packages need to genuinely be excluded and what should we do with these packages ? Some will probably be fixed once they are rebuilt but that may take a while.
Any package maintainers out there - please fix your packages in Rawhide so we don't have to file bugs for all of them.
I think we may have an issue with libtool throwing away the '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' option:
/bin/sh ../libtool --tag=CC --mode=link gcc -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -O -fomit-frame-pointer -finline-functions -O2 -g -pipe -Wall -Werror=format-s ecurity -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -version-info 10:1 :0 -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o libhdf5.la -rpath /usr/lib64 H5.lo.... H5Ztrans.lo -lz -ldl -lm
libtool: link: gcc -shared -fPIC -DPIC .libs/H5.o ... .libs/H5Ztrans.o -lz -ldl -lm -O -O2 -g -fstack-protector-strong -grecord-gcc-switches -m64 -mtune=generic -Wl,-z -Wl,relro -Wl,-soname -Wl,libhdf5.so.10 -o .libs/libhdf5.so.10.0.1
Looks like this has been known for two years:
Bug 985592 libtool + %global _hardened_build 1 = no full hardening - https://bugzilla.redhat.com/985592
Reported upstream but no response:
http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg00000.html
Work around would be to use -Wc,-specs=...
"AT" == Alexander Todorov atodorov@redhat.com writes:
AT> offending packages. You can find links to the script and execution AT> log here: AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
BTW to see if any packages you own are on the list, you can do:
wget https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.lo... for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" checksec.log|uniq; done
Use your FAS ID instead of mine, of course. You can also add --poc to the pkgdb-cli command line to limit it to just the primary maintainer.
Of course, several packages I comaintain are on the list (mainly due to Partial RELRO) and I have zero idea how to fix them. I read about what RELRO means from the blog post but that doesn't tell me what I actually need to do to make the errors go away, or even how to see what's causing them.
- J<
On 16/09/15 18:19, Jason L Tibbitts III wrote:
Of course, several packages I comaintain are on the list (mainly due to Partial RELRO) and I have zero idea how to fix them. I read about what RELRO means from the blog post but that doesn't tell me what I actually need to do to make the errors go away, or even how to see what's causing them.
The key thing to get full RELO rather than partial seems to be linking with "-z now" but the way that happens with rpmbuild appears to be extremely fragile...
Basically if you use %configure and the package uses libtool then ltmain.sh will get edited with sed to add this to the compiler flags:
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
In turn that specs file adds "-z now" to the linker flags.
So if you're building a package that doesn't use autoconf, or does but doesn't use libtool, then it likely won't happen and you will only get partial RELRO.
What I'm not sure about is why it's done like that rather than editing LDFLAGS as is done for the -zrelro that gets you partial RELRO.
Tom
On Wed, Sep 16, 2015 at 07:24:02PM +0300, Alexander Todorov wrote:
Including fedora-devel on this topic.
На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
Question is how to deal with these because they appear to be in the hundreds ?
How many, exactly? We have around 20000 SRPMs in the distribution.
From today's Rawhide snapshot my script counted around 4500 offending packages. You can find links to the script and execution log here: http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
The majority of the packages of mine on this list fall into three groups:
- erlang packages
- mingw packages
- ocaml packages
I'm pretty sure mingw packages should all be excluded. Who knows what Windows uses (and who cares).
Erlang code generation is an unknown quantity.
For OCaml, I think you should ignore anything under %{libdir}/ocaml/ since those are development files. (Their contents may eventually end up in a binary, but we can worry about that when we see the binary). That removes most of the failures.
For OCaml binaries, it seems as if most of them are like this:
Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH ./usr/bin/ocamlc.opt
As far as I understand it, the only problems there are "Partial RELRO" which should in an ideal world be "Full RELRO"; and "No PIE".
I guess we can fix the RELRO problem by linking with -z now. It may require a compiler patch.
The OCaml compiler doesn't support PIE but it does support -fPIC. I'm not clear if there would be some way to link the -fPIC objects into a PIE executable?
In general OCaml is much more robust against these kinds of attacks, since you have to deliberately let your pointers "go wild" by using special "unsafe_*" functions, and that's an immediate red flag when reviewing code.
Rich.
"AT" == Alexander Todorov atodorov@redhat.com writes:
AT> How do you feel about reporting all of these offences automatically?
Please don't. Post lists and let people work on things and develop a base of information before going and clogging bugzilla. Only end up at bugzilla after the easy things have been fixed and you have some documentation written to which you can link in the tickets you file.
At this point if you filed tickets against most packages, people would have no idea at all what to do with them and many would either be ignored or simply closed.
I know Kevin had a document about this but now that I need it I can't find a link.
- J<
On Sat, 12 Sep 2015 14:34:37 -0500 Jason L Tibbitts III tibbs@math.uh.edu wrote:
"AT" == Alexander Todorov atodorov@redhat.com writes:
AT> How do you feel about reporting all of these offences AT> automatically?
Please don't. Post lists and let people work on things and develop a base of information before going and clogging bugzilla. Only end up at bugzilla after the easy things have been fixed and you have some documentation written to which you can link in the tickets you file.
At this point if you filed tickets against most packages, people would have no idea at all what to do with them and many would either be ignored or simply closed.
I know Kevin had a document about this but now that I need it I can't find a link.
https://fedoraproject.org/wiki/Mass_bug_filing
kevin
Remember that some packages need to be built without these flags, or they will crash always.
So before doing some mass bug filling work, check which one really needs fix.
packaging@lists.fedoraproject.org
-
Alexander Todorov -
Christopher Meng -
Dominik 'Rathann' Mierzejewski -
Jason L Tibbitts III -
Kevin Fenzi -
Orion Poplawski -
Richard W.M. Jones -
Tom Hughes