Bug 731111

*** This bug has been marked as a duplicate of bug 704820 ***

I don't think this relevantly a duplicate of 704820 - while it's true that the flags aren't being passed, trying to build with non-executable stacks will just result in a binary that doesn't work. grub 2 uses nested functions which gcc implements using a trampoline on the stack. Changing that would require either changing the toolchain or rewriting large parts of grub 2.

A patch for bug 704820 that reintroduces "correct" passing of the default flags has been in rawhide for some time and is now queued for f16 testing. It do however still explicitly remove the -fstack-protector. I assume that is the problem reported by Steve and what Matthews says is the way it has to be.

Well, we really don't want executable stack code in the distribution. Its been banished since around FC5.(This is what exec-shield was all about.) So, allowing it now is a regression.

I fail to see how potential buffer overflow in these binaries a security threat given that only superuser can use most of them and all configuration files have to be trusted anyway. If you're able to insert malicious data as an input to those tools you're already very privilegied and don't need (or get) any privelege escalation from this.

One potential 'attack' vector could be inserting usb devices with rougue partitioning/formatting while running the grub tools ... and perhaps also boot loader.

The problem here could probably be resolved by using TARGET_CFLAGS properly and no longer remove CFLAGS options that can't be used in the boot loader but might make sense in the userspace tools.

No stack protection would be effective on boot time. If an attacker can handicraft something like this and has physical access to the machine to insert a USB stick he can just press the reset button to make boot time and not tools exposed.

In reply to comment #3, this is not controlled by the -fstack-protector. This is caused by the way something is coded. In general, its pretty hard to cause gcc to require an executable stack these days. You have to do something like use assembler or create a trampoline on the stack. In all cases, this can be avoided with some care. The first step in evaluating this is figuring out what is needing an executable stack. Which piece of source code is it?

You need executable stack for nested functions requiring access to parent variables. And it's not a tiny change like you present it.

Do you know which source code file/function is doing this?

*.c pretty much

The biggest one is around filesystems. I have some ideas on filesystem revamp for speed and it included eliminating nested functions as well but it's not done yet.

I'm currently working on a pretty giant patch set to remove nested functions, and will post it upstream once I'm finished.  It won't be sanely backportable by any stretch of the imagination, as essentially all internal iterator-type interfaces need to change, but hopefully I can get it into the next upstream release.

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.

Thank you for reporting this bug and we are sorry it could not be fixed.

Still a problem, re-opening...

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 
'version' of '18'.

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 prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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 to Fedora 18's end of life.

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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.