www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ELF object files: executable stack and security risk?

reply "Marco Leise" <Marco.Leise gmx.de> writes:
I'm not into the details of ELF and object file stacks, but Gentoo Linux  
gives me some QA warnings about executable writable sections. A Gentoo  
hacker helped me by writing a patch to dmd and the security warnings are  
now gone.

See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

I posted here to shed some light on the issue. GNU C closures need an  
executable stack, but D doesn't. Would there be any other feature that  
require executable stacks? If yes, then an option to disable these  
features and make the stacks non-executable would help. And why is it  
anyway that each object file has a stack of it's own? I thought stacks  
were a per-thread thing?

Best regards,
Marco
Jul 26 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 6:45 PM, Marco Leise wrote:
 I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
 me some QA warnings about executable writable sections. A Gentoo hacker helped
 me by writing a patch to dmd and the security warnings are now gone.

 See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

 I posted here to shed some light on the issue. GNU C closures need an
executable
 stack, but D doesn't. Would there be any other feature that require executable
 stacks?
Not at the moment.
 If yes, then an option to disable these features and make the stacks
 non-executable would help. And why is it anyway that each object file has a
 stack of it's own? I thought stacks were a per-thread thing?
Object files don't have their own stacks. I don't know what you're referring to.
Jul 26 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 6:51 PM, Walter Bright wrote:
 On 7/26/2011 6:45 PM, Marco Leise wrote:
 I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
 me some QA warnings about executable writable sections. A Gentoo hacker helped
 me by writing a patch to dmd and the security warnings are now gone.

 See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

 I posted here to shed some light on the issue. GNU C closures need an
executable
 stack, but D doesn't. Would there be any other feature that require executable
 stacks?
Not at the moment.
Hmm. D is supposed to link with gcc code, so that could be an issue.
Jul 26 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Hmm. D is supposed to link with gcc code, so that could be an issue.
How? Is the D GC eventually in need for some hardening? This is highly technical stuff: http://blogs.technet.com/b/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspx Bye, bearophile
Jul 26 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 7:06 PM, bearophile wrote:
 Walter:

 Hmm. D is supposed to link with gcc code, so that could be an issue.
How?
I believe Marco explained that: "GNU C closures need an executable stack"
 Is the D GC eventually in need for some hardening? This is highly technical
stuff:
It's not that technical.
 http://blogs.technet.com/b/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspx
D relies more on memory safety guarantees of the language rather than after-the-fact damage control. A well written D program will have very little unsafe code in it, whereas it's pretty much impossible to do that in C or C++, as they rely so heavily on pointer arithmetic.
Jul 26 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 9:12 PM, Walter Bright wrote:
 D relies more on memory safety guarantees of the language rather than
 after-the-fact damage control. A well written D program will have very little
 unsafe code in it, whereas it's pretty much impossible to do that in C or C++,
 as they rely so heavily on pointer arithmetic.
I should clarify that. If you write C style code in D, yes, your code is not verifiably safe and hence your programs could be susceptible to malicious attacks based on buffer overflow exploits. But, if you write in D style, using arrays, ranges, and other safe data structures, the risk of your program being vulnerable to such exploits is reduced enormously.
Jul 26 2011
parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:

 I should clarify that. If you write C style code in D, yes, your code is not 
 verifiably safe and hence your programs could be susceptible to malicious 
 attacks based on buffer overflow exploits.
 
 But, if you write in D style, using arrays, ranges, and other safe data 
 structures, the risk of your program being vulnerable to such exploits is 
 reduced enormously.
Do you consider code working with arrays and compiled in release mode safe?
Jul 26 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 11:15 PM, Kagamin wrote:
 Do you consider code working with arrays and compiled in release mode safe?
In D2, you have to specifically use -noboundscheck to turn off array bounds checking.
Jul 27 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 27.07.2011, 06:12 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 On 7/26/2011 7:06 PM, bearophile wrote:
 Walter:

 Hmm. D is supposed to link with gcc code, so that could be an issue.
How?
I believe Marco explained that: "GNU C closures need an executable stack"
If these nested functions / closures were used in any of my installed packages I would have gotten the same warnings as for dmd. We are dealing with a rarely used GNU only (in other words non-portable) feature that makes C programs arguably more vulnerable. This extension I think, could actually be ignored. From what I've read its usually assembly files that are assembled without a .note.GNU-stack section hint that end up with an executable stack for the benefit of doubt. Ignorant of all that, isn't this solely a linker issue and has nothing to do with dmd?
Jul 26 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 27.07.2011, 03:51 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 On 7/26/2011 6:45 PM, Marco Leise wrote:
 I'm not into the details of ELF and object file stacks, but Gentoo  
 Linux gives
 me some QA warnings about executable writable sections. A Gentoo hacker  
 helped
 me by writing a patch to dmd and the security warnings are now gone.

 See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.

 I posted here to shed some light on the issue. GNU C closures need an  
 executable
 stack, but D doesn't. Would there be any other feature that require  
 executable
 stacks?
Not at the moment.
Thank you for the info. That means when compiling the source this is a valid patch.
 If yes, then an option to disable these features and make the stacks
 non-executable would help. And why is it anyway that each object file  
 has a
 stack of it's own? I thought stacks were a per-thread thing?
Object files don't have their own stacks. I don't know what you're referring to.
I was wondering why scanelf was printing out lines for every object file in the libraries and read sentences like "Sure enough, these objects lack the .note.GNU-stack ELF section and they are linked into the final libsmpeg.so library." That made me assume that each object file can have this section and thus must have an own stack. Anyway me and Andrei wanted to at least notify you about this and that's done now. It seemed somewhat me, like when an old lady sees a fake website pop-up a virus warning.
Jul 26 2011
parent "Marco Leise" <Marco.Leise gmx.de> writes:
*[...] It seemed somewhat urgent to me, [...]
Jul 26 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/26/2011 6:45 PM, Marco Leise wrote:
 I'm not into the details of ELF and object file stacks, but Gentoo Linux gives
 me some QA warnings about executable writable sections. A Gentoo hacker helped
 me by writing a patch to dmd and the security warnings are now gone.

 See http://d.puremagic.com/issues/show_bug.cgi?id=6387 for details.
If you (or someone else) would like to do this as a pull request, I'd be happy to fold it in.
Jul 26 2011