Bug 731111 - grub 2 depends on executable stacks
Summary: grub 2 depends on executable stacks
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-16 17:58 UTC by Steve Grubb
Modified: 2014-02-05 22:42 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 22:42:15 UTC


Attachments (Terms of Use)

Description Steve Grubb 2011-08-16 17:58:13 UTC
Description of problem:
There are several programs in grub2 that seem to have an executable stack:
/usr/bin/grub2-fstest
/usr/bin/grub2-script-check
/usr/sbin/grub2-setup
/usr/sbin/grub2-probe
/usr/sbin/grub2-mkdevicemap

# eu-readelf -l /usr/bin/grub2-script-check | grep STACK
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x8

That should be RW and not RWE.

Comment 1 Mads Kiilerich 2011-09-06 19:04:45 UTC

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

Comment 2 Matthew Garrett 2011-12-04 17:10:31 UTC
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.

Comment 3 Mads Kiilerich 2011-12-11 01:09:02 UTC
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.

Comment 4 Steve Grubb 2011-12-11 04:12:14 UTC
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.

Comment 5 Vladimir Serbinenko 2012-06-01 11:26:46 UTC
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.

Comment 6 Mads Kiilerich 2012-06-01 11:42:03 UTC
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.

Comment 7 Vladimir Serbinenko 2012-06-01 11:54:58 UTC
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.

Comment 8 Steve Grubb 2012-06-01 12:09:31 UTC
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?

Comment 9 Vladimir Serbinenko 2012-06-01 12:11:37 UTC
You need executable stack for nested functions requiring access to parent variables. And it's not a tiny change like you present it.

Comment 10 Steve Grubb 2012-06-01 12:20:17 UTC
Do you know which source code file/function is doing this?

Comment 11 Vladimir Serbinenko 2012-06-01 12:23:17 UTC
*.c pretty much

Comment 12 Vladimir Serbinenko 2012-06-01 12:26:37 UTC
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.

Comment 13 Colin Watson 2012-12-31 17:30:26 UTC
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.

Comment 14 Fedora End Of Life 2013-02-14 02:12:03 UTC
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.

Comment 15 Steve Grubb 2013-02-14 13:40:42 UTC
Still a problem, re-opening...

Comment 16 Fedora End Of Life 2013-12-21 14:56:51 UTC
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.

Comment 17 Fedora End Of Life 2014-02-05 22:42:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.