Description of problem:
Several programs in this package have an executable stack. This makes it susceptible to stack based exploits should another weakness be found in the affected programs:
To determine if these have an executable stack, just do the following:
# /usr/bin/eu-readelf -l /usr/bin/zdb | grep STACK
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8
As you can see, the permissions are RWE, the 'E' meaning executable.
Version-Release number of selected component (if applicable):
Running execstack -c on each of those binaries takes care of this, and doesn't seem to impede normal function. Should this be fixed in all releases, or just rawhide for now?
I would fix rawhide -> F17. Its better to go after the root cause. It may be nested functions or handwritten assembler that is causing the problem. But if nothing else, then execstack might be used.
Further investigation shows the problem is worse than I thought...this package does not have the stack-protector or FORTIFY_SOURCE settings applied either. I am working on a patch for this. Will attach it later.
Ok, I've already used execstack in rawhide, I'll apply your patch through f17 when it appears. Thanks!
Created attachment 697823 [details]
Patch that adds stack-protector and FORTIFY_SOURCE
The attached patch works on my F18 system. I had to patch a Makefile.in rather than Makefile.am in libumem because running autoreconf totally messed up the resulting Makefile. So, that means the patch may require some adjustment on upstream source upgrades.
I think the problem results because scons doesn't setup the right environment variables when it runs external scripts.
Please test carefully because now that the stack protector and FORTIFY_SOURCE are working, we just might detect actual problems. :-) Thanks.
Looks great, still works, I'll get it out the door. Thanks!
Hi...just checking on this...I see a -10 build sitting in koji, but I don't see any updates being pushed through bodhi. I was hoping this would go out to everyone as an update so that if there were any defects found at some point in the future, there is some measure of preventive mechanisms that would make it harder to exploit. Thanks.
Sorry about that, I'll get that out. That was a. . .full. . .week. :)
zfs-fuse-0.7.0-10.fc18 has been submitted as an update for Fedora 18.
zfs-fuse-0.7.0-3.fc17 has been submitted as an update for Fedora 17.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing zfs-fuse-0.7.0-3.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
zfs-fuse-0.7.0-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
zfs-fuse-0.7.0-10.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.