digitalmars.D - ELF object files: executable stack and security risk?
- Marco Leise (13/13) Jul 26 2011 I'm not into the details of ELF and object file stacks, but Gentoo Linux...
- Walter Bright (3/13) Jul 26 2011 Object files don't have their own stacks. I don't know what you're refer...
- Walter Bright (2/13) Jul 26 2011 Hmm. D is supposed to link with gcc code, so that could be an issue.
- bearophile (6/7) Jul 26 2011 How?
- Walter Bright (7/12) Jul 26 2011 It's not that technical.
- Walter Bright (7/11) Jul 26 2011 I should clarify that. If you write C style code in D, yes, your code is...
- Kagamin (2/9) Jul 26 2011 Do you consider code working with arrays and compiled in release mode sa...
- Walter Bright (3/4) Jul 27 2011 In D2, you have to specifically use -noboundscheck to turn off array bou...
- Marco Leise (11/18) Jul 26 2011 If these nested functions / closures were used in any of my installed
- Marco Leise (12/33) Jul 26 2011 Thank you for the info. That means when compiling the source this is a
- Marco Leise (1/1) Jul 26 2011 *[...] It seemed somewhat urgent to me, [...]
- Walter Bright (3/7) Jul 26 2011 If you (or someone else) would like to do this as a pull request, I'd be...
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
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
On 7/26/2011 6:51 PM, Walter Bright wrote:On 7/26/2011 6:45 PM, Marco Leise wrote:Hmm. D is supposed to link with gcc code, so that could be an issue.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.
Jul 26 2011
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
On 7/26/2011 7:06 PM, bearophile wrote:Walter:I believe Marco explained that: "GNU C closures need an executable stack"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:It's not that technical.http://blogs.technet.com/b/srd/archive/2009/08/04/preventing-the-exploitation-of-user-mode-heap-corruption-vulnerabilities.aspxD 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
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
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
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
Am 27.07.2011, 06:12 Uhr, schrieb Walter Bright <newshound2 digitalmars.com>:On 7/26/2011 7:06 PM, bearophile wrote: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?Walter:I believe Marco explained that: "GNU C closures need an executable stack"Hmm. D is supposed to link with gcc code, so that could be an issue.How?
Jul 26 2011
Am 27.07.2011, 03:51 Uhr, schrieb Walter Bright <newshound2 digitalmars.com>:On 7/26/2011 6:45 PM, Marco Leise wrote:Thank you for the info. That means when compiling the source this is a valid patch.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.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.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
*[...] It seemed somewhat urgent to me, [...]
Jul 26 2011
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