Description of problem: Many programs in the ghc-compiler package have an executable stack. "This makes it susceptible to stack based exploits should another weakness be found in the affected programs" (Steve Grubb). Version-Release number of selected component (if applicable): ghc-compiler-7.4.2-11.fc19 How reproducible: You can use following programs to check if a package is hardened: http://people.redhat.com/sgrubb/files/rpm-chksec OR https://github.com/kholia/checksec Steps to Reproduce: Get scanner.py from https://github.com/kholia/checksec $ ./scanner.py ghc-compiler-7.4.2-11.fc19.x86_64.rpm ... ghc-compiler,ghc-compiler-7.4.2-11.fc19.x86_64.rpm,/usr/lib64/ghc-7.4.2/ghc,mode=0100755,NX=Disabled,CANARY=Disabled,RELRO=Partial,PIE=Disabled,RPATH=Disabled,RUNPATH=Disabled,FORTIFY=Disabled,CATEGORY=None Notice "NX=Disabled" field. Upstream fixed this "bug" 4 years back. See http://hackage.haskell.org/trac/ghc/ticket/703
Re-opened upstream bug, http://hackage.haskell.org/trac/ghc/ticket/703
Thank you very much for reporting this. Should be fixed upstream, see https://github.com/ghc/ghc/commit/08a38628f29df63ac842f4d083efb414f42d7bff which I backported to rawhide in ghc-7.6.3-15.fc20. Note this affects ghc 7.4 and 7.4 (but not 7.0). I will backport later to F19 and F18.
Also just to clarify the report it affects not just the ghc executables themselves but all executables linked by ghc-7.4 and ghc-7.6. :)
Hi Jens, Thanks for tracking this. Hoping to see the fixed packages land soon! >> Also just to clarify the report it affects not just the ghc executables themselves but all executables linked by ghc-7.4 and ghc-7.6. :) Yes.
(In reply to Jens Petersen from comment #3) > affects [...] all executables linked by ghc-7.4 and ghc-7.6. Actually I am surprised but from my testing it seems ghc-7.4.1 (F18) is not affected, so currently this only affects F19 and Rawhide I believe.
(In reply to Jens Petersen from comment #2) > https://github.com/ghc/ghc/commit/08a38628f29df63ac842f4d083efb414f42d7bff > which I backported to rawhide in ghc-7.6.3-15.fc20. Unfortunately even with ghc-7.6.3-15.fc20 executables still seems to get executable stack... It also changed the ABI hash of the ghc library. :-( For now I added a workaround to ghc-rpm-macros to clear the execstack flag when building Fedora Haskell packages, but leaving this open until the actual problem in ghc is fixed.
ghc-rpm-macros-0.98.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ghc-rpm-macros-0.98.3-1.fc19
ghc-rpm-macros-0.98.3-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ghc still produces binaries with an executable stack. Clearing up after %install in RPM macros is a nice kludge, but doesn't help users who build their own software. Do we know why the version in F19 doesn't play nice with NX stacks?
I am not sure what went wrong in my earlier testing, I did a new test build and it *does* seem to fix the problem. :) So likely my earlier testing was incorrect. :-/ http://koji.fedoraproject.org/koji/taskinfo?taskID=6467138 This f21 scratch build should also work fine on F20. (You can use lftp etc to pull down the rpms from kojipkgs.)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6467138 > This f21 scratch build should also work fine on F20. I forgot I only built it so far for i686. Anyway I will build soon for rawhide and then it should be easier to test. As noted earlier, the ghc lib's ABI hash changes so unfortunately this also requires some rebuilds to push cleanly.
Thanks Jens! This should help in reducing the size of the following list, http://people.fedoraproject.org/~halfie/scans/rawhide-execstack-list.txt
Here's a scratch build for x86_64 too: http://koji.fedoraproject.org/koji/taskinfo?taskID=6467138 which should become identical to the final rawhide build once I have tested it.
(In reply to Jens Petersen from comment #13) > Here's a scratch build for x86_64 too: Ugh, I mean http://koji.fedoraproject.org/koji/taskinfo?taskID=6470812
The saga gets better: the 64bit build above does not fix execstack! unlike the 32bit one above... boggle, which is consistent with comment 6.
Still true for F21 alas.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.