Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On 09/17/2015 12:53 PM, Alexander Todorov wrote: > Is it realistic to request a RFE with this information stored in the > compiled object and then be read by readelf ? If so I can file bugs in > bugzilla.redhat.com or upstream . elfutils would be a more likely choice to implement that tool. Note that looking for DW_AT_producer is not a complete solution. You also need to check that the DWARF information covers all object code. If you lose the hardening flags, it is quite likely that you lose -g and -grecord-gcc-switches at the same time. A simple grep on DWARF dumps will not show that it is missing. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 18.09.2015 в 03:15, Steve Grubb написа: I think Florian answered this. Indeed, the --debug-dump option does find these strings, but they are mixed in with other data. I think that if there is no canary and flags were passed, its not a problem. If the flags are absent, the build scripts are suspect. Hi Steve, thanks for the pointer. I have something which I'm not clear about. For example: readelf --debug-dump=info /usr/lib/debug/usr/lib64/libmemtailor.so.0.0.0.debug | grep "DW_AT_producer" shows 4 lines where I can clearly see -fstack-protector-strong is used. OTOH readelf --debug-dump=info /usr/lib/debug/usr/lib64/libmemtailor.so.0.0.0.debug | grep "Compilation Unit" gives me 8 lines. Can you briefly explain (or point me to relevant reading) what is the difference between the two and if it's OK to grep for the DW_AT_producer lines and look at the flags there. Thanks, Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, 17 Sep 2015 13:53:38 +0300 Alexander Todorov wrote: > На 17.09.2015 в 13:34, Steve Grubb написа: > > On Thu, 17 Sep 2015 11:07:37 +0300 > > Alexander Todorov wrote: > > > >> Can somebody comment on the -fstack-protector-all vs > >> -fstack-protector-strong issue ? Do we want to change the default > >> for %__global_cflags in /usr/lib/rpm/redhat/macros ? > > > > -all is not needed, -strong is the right balance between security > > and performance. For example > > > > int add(int a, int b) > > { > > return a+b; > > } > > > > Does that need a stack canary? This is the nature of why some > > functions don't get a canary. Whenever knowledge of a stack frame > > is passed as a pointer to a function, then -strong will kick in and > > do a stack check on return. > > > > Hi Steve, > thanks for the explanation. > > So it looks like I should ignore stack canary warnings (assuming the > package is using the default flags). Should this be ignore for both > libraries and executable binaries or only libraries ? Or the answer > is once again, you can't tell that easily ? Not completely. See below. > > To know if the right thing is being done is hard to script. You > > really need to see what flags are passed to each source file being > > compiled. You just can't get at that from readelf. > > > > Is it realistic to request a RFE with this information stored in the > compiled object and then be read by readelf ? If so I can file bugs > in bugzilla.redhat.com or upstream . > I think Florian answered this. Indeed, the --debug-dump option does find these strings, but they are mixed in with other data. I think that if there is no canary and flags were passed, its not a problem. If the flags are absent, the build scripts are suspect. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, Sep 17, 2015 at 16:45:46 +0300, Alexander Todorov wrote: > I meant turning it on globally as in "everything built with CMake in Fedora", > like updating the default flags in a RPM macro or updating the default CMake > config in Fedora. Which will change all the packages using CMake once they > are > rebuilt. Sorry, my first email may have been too subtle. From my first email: > so adding: > > -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON > > to %cmake when hardening is enabled should fix -fPIE missing. The %cmake macro is defined in macros.cmake which is the CMake version of %configure. It is part of the cmake package, so a bug there would be best. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 16:24, Ben Boeckel написа: Ben, is there any way this CMake property be turned on globally ? When a target is made, the POSITION_INDEPENDENT_CODE property is set to the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden manually. Anything that turns it or the property off explicitly will have to be patched. Or do you mean more globally than "this one CMake build"? I meant turning it on globally as in "everything built with CMake in Fedora", like updating the default flags in a RPM macro or updating the default CMake config in Fedora. Which will change all the packages using CMake once they are rebuilt. -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, 2015-09-17 at 12:00 +0100, Steve Grubb wrote: > Also, the full RELRO thing is a bit oversold. You need it if the > executable is PIE, and that's not needed in the general case. There are > far worse problems that are easy to fix that are not getting attention. > With the RELRO thing, you already have to have an exploit that allows > writing arbitrary memory under attacker control. Most vulnerabilities > just don't have this quality about them. Honestly the security benefits are a sideshow to me. Full relro and eager binding means that C's const keyword actually works. That alone justifies the effort to me. > What is more important is preventing common vulnerabilities from > achieving control over execution with simple heap and stack corruption > bugs. Hopefully we can start addressing this in F24. I look forward to your patches. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, Sep 17, 2015 at 10:57:28 +0300, Alexander Todorov wrote: > FYI: > https://bugzilla.redhat.com/show_bug.cgi?id=1263957 Thanks. > > [1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html > > Ben, > is there any way this CMake property be turned on globally ? When a target is made, the POSITION_INDEPENDENT_CODE property is set to the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden manually. Anything that turns it or the property off explicitly will have to be patched. Or do you mean more globally than "this one CMake build"? --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On 09/17/2015 01:03 PM, Alexander Todorov wrote: > На 17.09.2015 в 12:26, Richard W.M. Jones написа: >>> As far as I can see most of them report "Partial RELRO" which may >>> well be fixed as you propose below. If not I can easily exclude >>> them. >> >> They're intermediate files used by developers. They aren't runnable >> binaries. I think everything in %{libdir}/ocaml should be ignored. >> > > > I see .o files, .so files and some .cmxs ones. Should all of them be > ignored then ? .o files need to have an empty .note.GNU-stack section. If they are compiled with GCC (see the .comment section), they need to have debugging information, and the debugging information must include the recorded command line options. Those command line options must have the required hardening flags. The debugging information must cover all object code. For .so files, similar rules apply, but the debug information may have been separated. Instead of section, the non-executable stack is now controlled by the GNU_STACK program header. Additionally, there most be GNU_RELRO program header. and the relocations must not overlap with a page that is read-write. checksec cannot check most of this, unfortunately. I don't know how .cmxs files are used. They seem similar to .so files, so the same rules apply. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, Sep 17, 2015 at 02:03:51PM +0300, Alexander Todorov wrote: > На 17.09.2015 в 12:26, Richard W.M. Jones написа: > >>As far as I can see most of them report "Partial RELRO" which may > >>well be fixed as you propose below. If not I can easily exclude > >>them. > > > >They're intermediate files used by developers. They aren't runnable > >binaries. I think everything in %{libdir}/ocaml should be ignored. > > > > > I see .o files, .so files and some .cmxs ones. Should all of them be ignored > then ? Yes. Everything under here is for developers. The .so files would only be run under the bytecode interpreter, and Fedora only builds those for the benefit of developers. All Fedora-shipped OCaml applications should use native code, and go in /usr/bin. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 12:26, Richard W.M. Jones написа: As far as I can see most of them report "Partial RELRO" which may well be fixed as you propose below. If not I can easily exclude them. They're intermediate files used by developers. They aren't runnable binaries. I think everything in %{libdir}/ocaml should be ignored. I see .o files, .so files and some .cmxs ones. Should all of them be ignored then ? Looking at other replies on this thread it may even be better to focus only on executable binaries and as Steve Grubb says this also may not be a big deal after all. -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Wed, 16 Sep 2015 19:24:02 +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 2 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. I have studied this issue for a long time. You cannot say that a package must have a stack canary. Its quite possible that no function is eligible for a stack canary. In good cases, stack-protector-strong only gives 20 - 30% function coverage. It can actually be lower. I have hints on this in my devconf speech a couple years ago. As for FORTIFY_SOURCE, same thing. Gcc may decide that there is no size information available and therefore cannot have a _check function. FORTIFY_SOURCE coverage is lower than the stack protector. Also, the full RELRO thing is a bit oversold. You need it if the executable is PIE, and that's not needed in the general case. There are far worse problems that are easy to fix that are not getting attention. With the RELRO thing, you already have to have an exploit that allows writing arbitrary memory under attacker control. Most vulnerabilities just don't have this quality about them. What is more important is preventing common vulnerabilities from achieving control over execution with simple heap and stack corruption bugs. Hopefully we can start addressing this in F24. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 13:34, Steve Grubb написа: On Thu, 17 Sep 2015 11:07:37 +0300 Alexander Todorov wrote: Can somebody comment on the -fstack-protector-all vs -fstack-protector-strong issue ? Do we want to change the default for %__global_cflags in /usr/lib/rpm/redhat/macros ? -all is not needed, -strong is the right balance between security and performance. For example int add(int a, int b) { return a+b; } Does that need a stack canary? This is the nature of why some functions don't get a canary. Whenever knowledge of a stack frame is passed as a pointer to a function, then -strong will kick in and do a stack check on return. Hi Steve, thanks for the explanation. So it looks like I should ignore stack canary warnings (assuming the package is using the default flags). Should this be ignore for both libraries and executable binaries or only libraries ? Or the answer is once again, you can't tell that easily ? To know if the right thing is being done is hard to script. You really need to see what flags are passed to each source file being compiled. You just can't get at that from readelf. Is it realistic to request a RFE with this information stored in the compiled object and then be read by readelf ? If so I can file bugs in bugzilla.redhat.com or upstream . -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, 17 Sep 2015 11:07:37 +0300 Alexander Todorov wrote: > Can somebody comment on the -fstack-protector-all vs > -fstack-protector-strong issue ? Do we want to change the default for > %__global_cflags in /usr/lib/rpm/redhat/macros ? -all is not needed, -strong is the right balance between security and performance. For example int add(int a, int b) { return a+b; } Does that need a stack canary? This is the nature of why some functions don't get a canary. Whenever knowledge of a stack frame is passed as a pointer to a function, then -strong will kick in and do a stack check on return. To know if the right thing is being done is hard to script. You really need to see what flags are passed to each source file being compiled. You just can't get at that from readelf. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Thu, Sep 17, 2015 at 11:27:36AM +0300, Alexander Todorov wrote: > На 16.09.2015 в 22:59, Richard W.M. Jones написа: > >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). > > > > Hi Richard, > please correct me if I'm wrong but aren't these mingw* packages > supposed to facilitate development of Windows applications on Linux > ? IOW they are supposed to be working on Linux. As such I'd say they > should also be hardened, but this is probably a low priority item. Actually yes that's correct. For some reason I thought it was looking at the Windows DLLs, but it's looking at the native Linux binaries. > >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. > > > > As far as I can see most of them report "Partial RELRO" which may > well be fixed as you propose below. If not I can easily exclude > them. They're intermediate files used by developers. They aren't runnable binaries. I think everything in %{libdir}/ocaml should be ignored. > >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. > > > > Please post a link if you file a bug upstream. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 06:28, Jerry James написа: I am baffled as to why some of my packages show up on this list, as they use %configure or invoke gcc with both $RPM_OPT_FLAGS and $RPM_LD_FLAGS. For example, memtailor, which I just built yesterday, shows as lacking a canary, but it uses the %configure macro. What is going on there? Probably because memtailor builds with -fstack-protector-strong, see previous message from Kaleb about this. -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 06:28, Jerry James написа: On Wed, Sep 16, 2015 at 10:24 AM, Alexander Todorov wrote: 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. Some language environments provide their own memory managers that don't take kindly to address randomization, such as: - gcl - polyml - xemacs Hi Jerry, how about other offenses like "No PIE" or "No canary found" ? xemacs and polyml appear to have files with both good and bad values. -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 16.09.2015 в 22:59, Richard W.M. Jones написа: 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). Hi Richard, please correct me if I'm wrong but aren't these mingw* packages supposed to facilitate development of Windows applications on Linux ? IOW they are supposed to be working on Linux. As such I'd say they should also be hardened, but this is probably a low priority item. Erlang code generation is an unknown quantity. So I take this we should treat erlang packages as genuine errors until we know better. 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. As far as I can see most of them report "Partial RELRO" which may well be fixed as you propose below. If not I can easily exclude them. 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. Please post a link if you file a bug upstream. -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 16.09.2015 в 23:05, Kaleb S. KEITHLEY написа: On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote: "AT" == Alexander Todorov 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.log for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" checksec.log|uniq; done GlusterFS packages have seven "No canary found" [1]. I get the same results with gcc-5.1.1 on f22. However GlusterFS _is_ built with '%global _hardened_build 1' and I have confirmed that all its sources are compiled with -fstack-protector-strong. As I read the gcc man page for -fstack-protector, -fstack-protector-strong, and -fstack-protector-all, it's clear that with just -fstack-protector-strong it's entirely plausible that these DSOs would not have the call to __stack_chk_fail, i.e. the canary. If I compile them with -fstack-protector-all then the resulting .o and .so files _do_ have the call to __stack_chk_fail. Off hand I'd say that checksec's test for the canary is wanting. The glusterfs packages need to be excluded. Or change _hardened_build to use -fstack-protector-all. Hi Kaleb, thanks for pointing this out. Can somebody comment on the -fstack-protector-all vs -fstack-protector-strong issue ? Do we want to change the default for %__global_cflags in /usr/lib/rpm/redhat/macros ? -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 16.09.2015 в 21:56, Adam Jackson написа: On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote: What is the proper fix to these issues? Having fixed some myself and ajax having looked at a bunch of them I don't think it's as simple as just mass rebuilding the packages. A lot of it is libtool being shit, which is nothing new I suppose. I suspect this patch will help a lot: http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html Apologies for not having looked at this for a while, I've been on a much-needed vacation for the last few weeks. I'm going to test the above and see if it magically fixes naive autotools builds, probably it will. Adam, can you update this bug or comment on the mailing list when this is ready ? https://bugzilla.redhat.com/show_bug.cgi?id=985592 Should we block on ^^^ before doing the mass rebuild ? -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
На 17.09.2015 в 08:33, Ben Boeckel написа: On Wed, 16 Sep, 2015 at 16:24:02 GMT, Alexander Todorov wrote: 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 see lots (probably all) of ghc-* packages, so filing one against ghc-rpm-macros or ghc itself would probably be the most expedient there. If it is just a missed flag or something, it can be rolled up with the 7.10.0 rebuild which I believe is planned for Rawhide. FYI: https://bugzilla.redhat.com/show_bug.cgi?id=1263957 Of course, if ghc doesn't support everything checksec looks for, ignoring everything under %{_libdir}/ghc-*/ would be best. Jens? For any CMake-using projects (I see at least CMake itself and ParaView in the list), setting the `POSITION_INDEPENDENT_CODE` property[1] on targets would fix any missing -fPIE. It is initialized with `CMAKE_POSITION_INDEPENDENT_CODE`, so adding: -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON to %cmake when hardening is enabled should fix -fPIE missing. Anything with internal static libraries *might* need a scalpel to turn off the property on those targets. --Ben [1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html Ben, is there any way this CMake property be turned on globally ? -- Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Wed, 16 Sep, 2015 at 16:24:02 GMT, Alexander Todorov wrote: > 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 see lots (probably all) of ghc-* packages, so filing one against ghc-rpm-macros or ghc itself would probably be the most expedient there. If it is just a missed flag or something, it can be rolled up with the 7.10.0 rebuild which I believe is planned for Rawhide. Of course, if ghc doesn't support everything checksec looks for, ignoring everything under %{_libdir}/ghc-*/ would be best. Jens? For any CMake-using projects (I see at least CMake itself and ParaView in the list), setting the `POSITION_INDEPENDENT_CODE` property[1] on targets would fix any missing -fPIE. It is initialized with `CMAKE_POSITION_INDEPENDENT_CODE`, so adding: -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON to %cmake when hardening is enabled should fix -fPIE missing. Anything with internal static libraries *might* need a scalpel to turn off the property on those targets. --Ben [1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Wed, Sep 16, 2015 at 10:24 AM, Alexander Todorov wrote: > 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. Some language environments provide their own memory managers that don't take kindly to address randomization, such as: - gcl - polyml - xemacs Programs that use a plugin architecture have a distressing tendency to be broken by full RELRO. I maintain several packages like that: - bigloo - clisp - libpuma - polybori - polymake Richard already talked about ocaml programs. I've got a few of those: - coq - frama-c - gappalib-coq - ocaml-menhir - ocaml-ocamlgraph - ocaml-tplib - ocaml-zarith - why - why3 - z3 - zenon We do some fancy aliasing inside cddlib to allow mixing the gmp-compiled version and the non-gmp-compiled version, since polymake wants to link against both. That aliasing did not interact well with -z now when trying to build gfan, so I turned -z now off for gfan until I can understand the problem better, or find a better way of giving polymake what it wants. I am baffled as to why some of my packages show up on this list, as they use %configure or invoke gcc with both $RPM_OPT_FLAGS and $RPM_LD_FLAGS. For example, memtailor, which I just built yesterday, shows as lacking a canary, but it uses the %configure macro. What is going on there? Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote: >> "AT" == Alexander Todorov 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.log > for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" > checksec.log|uniq; done > GlusterFS packages have seven "No canary found" [1]. I get the same results with gcc-5.1.1 on f22. However GlusterFS _is_ built with '%global _hardened_build 1' and I have confirmed that all its sources are compiled with -fstack-protector-strong. As I read the gcc man page for -fstack-protector, -fstack-protector-strong, and -fstack-protector-all, it's clear that with just -fstack-protector-strong it's entirely plausible that these DSOs would not have the call to __stack_chk_fail, i.e. the canary. If I compile them with -fstack-protector-all then the resulting .o and .so files _do_ have the call to __stack_chk_fail. Off hand I'd say that checksec's test for the canary is wanting. The glusterfs packages need to be excluded. Or change _hardened_build to use -fstack-protector-all. [1] excerpted from https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log ... -- glusterfs-3.7.4-2.fc24.src.rpm /mnt/fedora/Packages/g/glusterfs-api-3.7.4-2.fc24.x86_64.rpm RELRO STACK CANARY NXPIE RPATH RUNPATH FILE Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/mount/api.so -- glusterfs-3.7.4-2.fc24.src.rpm /mnt/fedora/Packages/g/glusterfs-client-xlators-3.7.4-2.fc24.x86_64.rpm RELRO STACK CANARY NXPIE RPATH RUNPATH FILE Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/features/ganesha.so -- glusterfs-3.7.4-2.fc24.src.rpm /mnt/fedora/Packages/g/glusterfs-extra-xlators-3.7.4-2.fc24.x86_64.rpm RELRO STACK CANARY NXPIE RPATH RUNPATH FILE Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/encryption/rot-13.so Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_dht.so Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/features/prot_server.so Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/features/quiesce.so Full RELRO No canary found NX enabledDSO No RPATH No RUNPATH ./usr/lib64/glusterfs/3.7.4/xlator/testing/features/template.so ... -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
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 2 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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote: > What is the proper fix to these issues? Having fixed some myself and > ajax having looked at a bunch of them I don't think it's as simple as > just mass rebuilding the packages. A lot of it is libtool being shit, which is nothing new I suppose. I suspect this patch will help a lot: http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html Apologies for not having looked at this for a while, I've been on a much-needed vacation for the last few weeks. I'm going to test the above and see if it magically fixes naive autotools builds, probably it will. F24 has gcc 5.2.1 in package git, so I'm assuming once it builds on arm we'll be planning a mass rebuild anyway. So if the above libtool fix works it'll probably be sufficient to focus on non-autotools packages. I don't know of any systemic failures like that in cmake or whatever, but I suppose anything is possible. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
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/msg0.html Work around would be to use -Wc,-specs=... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
> На 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 2 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. What is the proper fix to these issues? Having fixed some myself and ajax having looked at a bunch of them I don't think it's as simple as just mass rebuilding the packages. If it is as simple as a mass rebuild please co-ordinate this with rel-eng [1] so it can be completed as part of any F-24 mass rebuild that's needed to minimise the churn. Peter [1] https://fedorahosted.org/rel-eng/newticket -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
> "AT" == Alexander Todorov 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.log 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< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
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 2 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct