fis-gtm does not run due to missing support for executable stack

[shabiel]

This is what I see.

samha@DESKTOP-9LM60MK:/usr/lib/fis-gtm/V6.0-003_x86_64$ ./mumps _date.m
%GTM-E-DLLNOOPEN, Failed to load external dynamic library ./libgtmshr.so
%GTM-E-TEXT, ./libgtmshr.so: cannot enable executable stack as shared object requires: Invalid argument

It seems that dlopen fails.

Here's what strace says:
samha@DESKTOP-9LM60MK:/usr/lib/fis-gtm/V6.0-003_x86_64$ strace ./mumps _date.m
strace: Test for PTRACE_O_TRACESYSGOOD failed, giving up using this feature.
execve("./mumps", ["./mumps", "_date.m"], [/* 17 vars */]) = 0
brk(0) = 0x603000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffee0000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22386, ...}) = 0
mmap(NULL, 22386, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff5ffff9000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\16\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14664, ...}) = 0
mmap(NULL, 2109744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff9f0000
mprotect(0x7ff5ff9f3000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ffbf2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7ff5ffbf2000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1840928, ...}) = 0
mmap(NULL, 3949248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff620000
mprotect(0x7ff5ff7db000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ff9da000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7ff5ff9da000
mmap(0x7ff5ff9e0000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff5ff9e0000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffed0000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5ffec0000
arch_prctl(ARCH_SET_FS, 0x7ff5ffec0740) = 0
mprotect(0x7ff5ff9da000, 16384, PROT_READ) = 0
mprotect(0x7ff5ffbf2000, 4096, PROT_READ) = 0
mprotect(0x601000, 4096, PROT_READ) = 0
mprotect(0x7ff5ffe22000, 4096, PROT_READ) = 0
munmap(0x7ff5ffff9000, 22386) = 0
brk(0) = 0x603000
brk(0x624000) = 0x624000
open("./libgtmshr.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\362\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0664, st_size=2239248, ...}) = 0
getcwd("/usr/lib/fis-gtm/V6.0-003_x86_64", 128) = 33
mmap(NULL, 4522072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff5ff1c0000
mprotect(0x7ff5ff3d2000, 2093056, PROT_NONE) = 0
mmap(0x7ff5ff5d1000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x211000) = 0x7ff5ff5d1000
mmap(0x7ff5ff5e3000, 184408, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff5ff5e3000
mprotect(0x7ff5ffe22000, 3668, PROT_READ|PROT_WRITE) = 0
mprotect(0x7ff5ffe22000, 3668, PROT_READ) = 0
mprotect(0x7ff5fffef000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)
close(3) = 0
write(2, "%GTM-E-DLLNOOPEN, Failed to load"..., 73%GTM-E-DLLNOOPEN, Failed to load external dynamic library ./libgtmshr.so
) = 73
write(2, "%GTM-E-TEXT, ./libgtmshr.so: can"..., 104%GTM-E-TEXT, ./libgtmshr.so: cannot enable executable stack as shared object requires: Invalid argument
) = 104
exit_group(150379250) = ?
<... exit_group resumed> _exit returned!
) = ?
+++ exited with 242 +++

[shabiel]

I just upgraded to Build 14342. Same errors.

[stehufntdev]

Thanks for reporting the issue. The "cannot enable executable stack as shared object requires: Invalid argument" is coming from the loader because of this failure:

mprotect(0x7ff5fffef000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)

WSL does not currently have support for the PROT_GROWSDOWN flag. In some cases, the executable stack flag isn't needed so you might want to create a backup of the original binary and run execstack -c libgtmshr.so to manually clear the executable stack flag in the binary.

Please give us feedback for this scenario on the uservoice so we can prioritize.

[shabiel]

I actually know the source code of this application to some extent as I am
involved in porting it to other platforms. It NEEDS an executable stack.
Having said that, I will try your suggestion and see what happens.

On Tue, May 17, 2016 at 7:25 AM, stehufntdev [email protected]
wrote:

Thanks for reporting the issue. The "cannot enable executable stack as
shared object requires: Invalid argument" is coming from the loader because
of this failure:

mprotect(0x7ff5fffef000, 4096,
PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid
argument)

WSL does not currently have support for the PROT_GROWSDOWN flag. In some
cases, the executable stack flag isn't needed so you might want to create a
backup of the original binary and run execstack -c libgtmshr.so to
manually clear the executable stack flag in the binary.

Please give us feedback for this scenario on the uservoice
https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo
so we can prioritize.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

[ksbhaskar]

Sam, as a possible workaround until the issue is fixed in WSL, see whether not specifying auto-relink in $gtmroutines / $zroutines gets you past this.

[shabiel]

I tried this and it worked. Now it complains that semget isn't there, which
I know.

On Wed, May 18, 2016 at 6:51 AM, K.S. Bhaskar [email protected]
wrote:

Sam, as a possible workaround until the issue is fixed in WSL, see whether
not specifying auto-relink in $gtmroutines / $zroutines gets you past this.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

[shabiel]

Before I forget, let me say thank you for your help. I can buy you a beer
if you live in Seattle.

I put this on uservoice. Alas, I am the only one who wants that feature!

The next issue is shared memory/semaphores. I contributed my votes to that
on uservoice.

On Wed, May 18, 2016 at 10:12 PM, Sam Habiel [email protected] wrote:

I tried this and it worked. Now it complains that semget isn't there,
which I know.

On Wed, May 18, 2016 at 6:51 AM, K.S. Bhaskar [email protected]
wrote:

Sam, as a possible workaround until the issue is fixed in WSL, see
whether not specifying auto-relink in $gtmroutines / $zroutines gets you
past this.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#286 (comment)

Sam Habiel, Pharm.D.
VISTA Expertise Network

Sam Habiel, Pharm.D.
VISTA Expertise Network

[JMoVS]

I am currently trying out a lot of packages and thing with linuxbrew on lxss and am runnig into the "cannot enable executable stack as shared object requires: invalid argument" problem quite often (one occurence for reference: https://github.com/Linuxbrew/homebrew-core/issues/765). Is that something that is going to be implemented?

[andresau]

This also happens to me trying to run this example: http://docs.opencv.org/master/db/df5/tutorial_linux_gcc_cmake.html using OpenCV 3.1

$ ./DisplayImage lena.jpg
./DisplayImage: error while loading shared libraries: libopencv_core.so.3.1: cannot enable executable stack as shared object requires: Invalid argument

[Adnino]

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

[abodyai]

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

I'm having the same issue when trying to compile OpenCV with Bash On Windows. Please fix this soon. Thanks.

[burstingninja]

Hi there you need to install execstack
and run this command
execstack -c /usr/local/lib/opencv.so*

here is the source
http://stackoverflow.com/questions/39136040/python3-4-error-cannot-enable-executable-stack-as-shared-object-requires-inva

[ejoebstl]

Make sure to catch all opencv libraries:

sudo execstack -q /usr/local/lib/*opencv*.so*

[yamsergey]

Similar problem for Apple Swift:
swift-build: error while loading shared libraries: libFoundation.so: cannot enable executable stack as shared object requires: Invalid argument

[andresau]

Hi @andresau ,
I am having the same error when trying to import cv2 in Bash on windows. Did you find a solution ?

Hello @Adnino,
No solutions so far, I had to install a VM in order to run it.

[ghost]

I just ran into the executable stack issue when trying to get Swift 3.0.1 running under WSL on Windows 14965.

Had to clear the executable stack flag in libFoundation.so ("execstack -c <pathToSwift>/usr/lib/swift/linux/libFoundation.so"), but once I did that helloworld.swift demo ran using "swift helloworld.swift".

[metorm]

I encountered this issue today.

My solution is to #apt install execstack and execstack -s program_to_run

Then the program runs well

[thorsteneb]

Same issue for perl6 / rakudo *, unsurprisingly.

@stehufntdev Do you have a roadmap as to when this feature might be implemented? Is this targeted for the upcoming Creators Update?

@dheine Thank you! That allowed me to build perl6, as well.

• A brief description

Attempt to install perl6 using rakudobrew as per http://rakudo.org/how-to-get-rakudo/#Installing-Rakudo-Star-Source-Prerequisites-Debian

• Expected results

moar builds successfully

• Actual results (with terminal output if applicable)

This fails with an error message on libmoar.so:
"/home/tbehrens/.rakudobrew/moar-nom/install/bin/moar: error while loading shared libraries: libmoar.so: cannot enable executable stack as shared object requires: Invalid argument"

The relevant strace is in moar-strace.txt.21832, and the relevant lines are:

open("//home/tbehrens/.rakudobrew/moar-nom/install/lib/libmoar.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240r\25\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0666, st_size=4883504, ...}) = 0
mmap(NULL, 6843296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa619f70000
mprotect(0x7fa61a345000, 2093056, PROT_NONE) = 0
mmap(0x7fa61a544000, 729088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3d4000) = 0x7fa61a544000
mmap(0x7fa61a5f6000, 2976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa61a5f6000
mprotect(0x7fffe01a3000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = -1 EINVAL (Invalid argument)

I'm assuming the offender is PROT_EXEC, which is not (yet) supported by WSL.

• Your Windows build number

14986.1001

• Steps / All commands required to reproduce the error from a brand new installation

sudo apt-get install build-essential git libssl-dev
git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew
echo 'export PATH=~/.rakudobrew/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
rakudobrew build moar

After this failure, it is possible to successfully build moar, and the rest of perl6, by clearing the execstack flag on libmoar.so:

sudo apt-get install execstack
execstack -c ~/.rakudobrew/moar-nom/install/lib/libmoar.so
execstack -c ~/.rakudobrew/moar-nom/nqp/MoarVM/libmoar.so
rakudobrew build moar
rakudobrew build panda
panda install Task::Star

• Strace of the failing command

moar-strace.zip

[stehufntdev]

No current ETA on PROT_GROWSDOWN support. We've been prioritizing work by scenarios and feedback on uservoice. Please give us feedback for this scenario on the uservoice so we can prioritize - https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/.

[thorsteneb]

Thanks @stehufntdev . Given http://www.xinotes.net/notes/note/1030/ and https://news.ycombinator.com/item?id=11599909 , I am leaning towards "executable stack support is not critical".

The GNU assembler has a quirk: If you don't tell it .section .note.GNU-stack,"",@progbits in manually written ASM code (.S files), then it will assume execstack. Oops, what a trap for programmers.
Ulrich Drepper asserts that "Executable stack memory is one of the biggest security problems."

fis-gtm actually needs executable stack memory and so it's in a bit of a bind.

But Perl6 does not. The library that requests it, dyncall, is running into that GNU ASM quirk. This can (and I am hopeful it will) be solved by the dyncall devs upstream to rakudo Star, and then MoarVM/Perl6/Rakudo will build without issue.

Apple Swift is likely a similar situation: Requests execstack but doesn't need it. @dheine , if you'd like to collaborate with me on that, I'm game.

So for my particular itch, I'm good. No WSL changes needed.

[shabiel]

GT.M does not need an executable stack. I mistakenly thought that; but it turns out it doesn't.

…

On Wed, Jan 4, 2017 at 9:55 AM, Thorsten Behrens ***@***.***> wrote: Thanks @stehufntdev . Given http://www.xinotes.net/notes/note/1030/ and https://news.ycombinator.com/item?id=11599909 , I am leaning towards "executable stack support is not critical". The GNU assembler has a quirk: If you don't tell it .section .***@***.*** in manually written ASM code (.S files), then it will assume execstack. Oops, what a trap for programmers. Ulrich Drepper asserts that "Executable stack memory is one of the biggest security problems." fis-gtm actually needs executable stack memory and so it's in a bit of a bind. But Perl6 does not. The library that requests it, dyncall, is running into that GNU ASM quirk. This can (and I am hopeful it will) be solved by the dyncall devs upstream to rakudo Star, and then MoarVM/Perl6/Rakudo will build without issue. Apple Swift is likely a similar situation: Requests execstack but doesn't need it. @dheine , if you'd like to collaborate with me on that, I'm game. So for my particular itch, I'm good. No WSL changes needed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andrewfinnell]

@FelipeMartin Solution to what? Which package do you want to use?
You can clear the execstack bit, "execstack -c", on the offending bit of code (often a library), and that will allow it to run on WSL.
Executable stack is a seriously bad idea, and in all cases we've looked into so far, it being requested was an artifact of the GNU tool chain defaulting to it for assembly files, not a case of the code actually needing executable stack.

I'm confused as to the meaning of this comment. Does this mean WSL is NOT looking to support this feature as they deem it a 'bad idea'? Or does it mean that, while we think it's a bad idea, it's on the roadmap as many toolchains require it's support. e.g. certbot.. and all the other ones people have mentioned. Apparently even azure's cli was failing, which is ironic considering...

[thorsteneb]

@andrew-finnell That comment is my opinion as a user of WSL. I'm not employed by MS and whatever I'm saying has no bearing on the direction WSL is taking.

[therealkenc]

I'm confused as to the meaning of this comment. Does this mean WSL is NOT looking to support this feature as they deem it a 'bad idea'?

I asked that three months ago but got no response. But the public statement from MSFT wasn't actually confusing:

If you see "cannot enable executable stack" errors - please contact the owner of the affected component and ask them (politely, of course) to please double-check that they've not accidentally enabled stack-execution. Or if they've enabled it deliberately, please ask them to consider disabling stack execution, and using an alternative approach.

That position might be Right™ or Wrong™ depending on one's disposition, but not confusing. What I have been wondering, idly, is whether it is technically feasible, or whether it is just plain difficult to implement given the practical constraints they have to work with and competing priorities. I don't know the answer to that. But whether it is on the "roadmap" has been asked and answered (until someone says otherwise).

Anyway, like some dude on the Internet said:

Because in the end, those users really do matter. Without those users,
your system may be "secure", but all your security work was still just
masturbation. You didn't do anything useful at all in the end.

Which is to say, meh, you can always run Docker if WSL does not meet your requirements (certbot or otherwise). [In the context I personally take no position on a rehash of a 20 year old debate over whether "executable stack is a seriously bad idea", or not, because it was boooring 20 years ago and it is still boooring today.]

I'm not employed by MS and whatever I'm saying has no bearing on the direction WSL is taking.

What he said.⬆️

[FelipeMartin]

For me this is an old thread and I have no intention to extend this discussion (seriously !) but when I came here my thought was: "If this is possible in Linux, so maybe Microsoft will release it soon".
I wasn't questioning if this is right or wrong, bad or good idea.
And I see no reason to emphasize that it was a request of a homework or a real demand of an important project.
The reason I think most of people came here was to find a solution, not a sermon (no offense).
If you emulate a system, is natural to see people trying to do the same things they could in the real one.
That being said, let's move on guys.

[tiagogl]

Configuring the installer for this system's environment...

Launching installer...

failed to open </tmp/install.dir.30/Linux/resource/jre/jre/lib/amd64/default/libjvm.so> - reason: </tmp/install.dir.30/Linux/resource/jre/jre/lib/amd64/default/libjvm.so: cannot enable executable stack as shared object requires: Invalid argument>
Failed to find VM - aborting

I installed JVM , JDK and JRE. Tried install using root too. Anyone can help me?

[mrlifetime]

encountering same issue when using our 64-bit build of https:

/opt/bb/lib64/apt/methods/https: error while loading shared libraries: libcrypto.so.1.0.0: cannot enable executable stack as shared object requires: Invalid argument
/opt/bb/lib64/apt/methods/https: error while loading shared libraries: libcrypto.so.1.0.0: cannot enable executable stack as shared object requires: Invalid argument
E: Method https has died unexpectedly!

Let's give this the visibility it needs on uservoice, this is clearly affecting many different apps!
https://wpdev.uservoice.com/forums/266908-command-prompt-console-windows-subsystem-for-l/suggestions/13904454-mprotect-prot-growsdown-support

PS: #286 (comment) workaround does seem to work in my case though!

[thorsteneb]

@mrlifetime , that means this issue is upstream, in the libcrypto library, not in WSL. Likely, libcrypto has asm code and relies on standard GCC behavior, which flags for executable stack even when it's not needed.
If you'd like to point me to the repository / community for this project, I'm happy to help you fix that permanently. The includes necessary to do so have been thoroughly vetted by now.

[mrlifetime]

@yorickdowne Unfortunately, I can't provide access to this repo as it is not public but if you could please point me to either some docs or ref material that can help fix this, I would be more than happy to pass this on to responsible devs! I am suspecting this wasn't compiled properly and/or the code for libcrypto we are using is perhaps a bit old and needs updating.

[thorsteneb]

Sure thing! Here's a snippet on how dyncall handles it. In their case, this goes into a .S file, but you could also have a #define in a .h and then the .S just calls that #define. I like that better because it means changes to the method have to be made in only one section. What they're testing against here, the DC__ are custom defines, which you can look up at http://hg.dyncall.org/pub/dyncall/dyncall/file/03f0b683918a/dyncall/dyncall_macros.h

 /* Use .note.GNU-stack to explicitly indicate a non-exec stack, b/c of bad   */
 /* default behaviour when translating handwritten assembly files (needed on  */
 /* GNU/* platforms, Android and FreeBSD, as tests have shown).               */
 #if (defined(DC__C_CLANG) || defined(DC__C_GNU)) && defined(__ELF__) && (defined(DC__OS_Linux) || defined(DC__OS_FreeBSD))
 .section .note.GNU-stack,"",%progbits
 #endif

Here's how Apple's Swift handles it. They define in a .h and then call NO_EXEC_STACK_DIRECTIVE at the end of every .S. Note they're testing differently than dyncall on whether they need this. dyncall lives on more platforms, consider their tests to be the more portable version.

#if defined(__GNU__) || defined(__GNUC__) || defined(__ANDROID__) || defined(__FreeBSD__)
#define NO_EXEC_STACK_DIRECTIVE .section .note.GNU-stack,"",%progbits
#else
#define NO_EXEC_STACK_DIRECTIVE

In my mind, the best approach would be to use dyncall's tests and Apple's "define in a .h, then reference at the end of every .S" approach. That way, it's highly portable, and if you ever need to change the tests, you only need to do so in one location.

[thorsteneb]

dyncall 1.0 has been released 2018-04-23 and contains code to avoid setting execstack. I've updated MoarVM/MoarVM#470. There are other issues with dyncall on MoarVM, hopefully we'll see dyncall 1.0 pulled in MoreSoonerish(tm). perl6 on WSL. It'll happen. Eventually, but it'll happen :).

[uecker]

I have a project which started to use nested function. I will probably just tell people not to use WSL. This was a nice way to support windows... but it is probably not worth rewriting everything.

BTW: noexec stack is just pseudo security. It is based on the idea that code is fundamentally something else than data. But it is not! So it is not surprising that even with a non-executable stack you can exploit buffer overruns using return-oriented programming. Misguided people now conclude that return addresses are not really data and need to be protected. They we then learn that it is possible to exploit a program in different ways using buffer runs by exploiting control flow changes which depend on local variables... The only way to fix this is to protect against buffer overruns directly. Everything else is pseudo security.

[ksbhaskar]

On 08/06/2018 01:57 AM, Martin Uecker wrote: I have a project which started to use nested function. I will probably just tell people not to use WSL. This was a nice way to support windows... but it is probably not worth rewriting everything. BTW: noexec stack is just pseudo security. It is based on the idea that code is fundamentally something else than data. But it is not! So it is not surprising that even with a non-executable stack you can exploit buffer overruns using return-oriented programming. Misguided people now conclude that return addresses are not really data and need to be protected. They we then learn that it is possible to exploit a program in different ways using buffer runs by exploiting control flow changes which depend on local variables... The only way to fix this is to protect against buffer overruns directly. Everything else is pseudo security.

[KSB] Spot on. Regards – Bhaskar

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAiqeptE1tmKyx_iJwmFcyfc52hWVt7Cks5uN9rWgaJpZM4IRnk->.

-- YottaDB - Rock solid. Lightning fast. Secure. Pick any three.

[shoffmeister]

The only way

In security, there is no "only way".

Security (which is defensive) is all about putting layer on top of layer on top of aspect on top of concern, making it ever more difficult for unauthorized things to happen.

Lack of an executable stack reduces attack surface. That's good.

General reading suggestion would be the ever so technical https://en.wikipedia.org/wiki/Executable_space_protection#Linux

[thorsteneb]

Linus famously maintains that "vulnerabilities are just bugs", and security folk tend to go on about defense in depth. That seems like an intractable debate.

I'll offer this thought to appeal to software engineers who want their stuff to work cross-platform. Requiring an executable stack will break your code on NetBSD and OpenBSD (source: http://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/execstack/README), and in severely hardened SELinux environments (https://www.akkadia.org/drepper/selinux-mem.html).

The same way that I can't come into this thread and credibly tell a software engineer to stop using executable stack, as they may have good reasons and it may fit their deployment case, a software engineer can't tell OS designers or customers to stop using executable stack protection. They may have good reason, such as designing for defense in depth.

The dyncall and libffi libraries allow dynamic callbacks and the like without the need for execstack, that's worth a look.

Ultimately, if you want to use nested functions, go for it. Live with the fact it won't work on NetBSD, OpenBSD, SELinux with memprotect, and WSL. That may be acceptable, those might not be target environments.

For me personally, I'll keep going after the low-hanging fruit: The projects that require execstack only because GNU "as" has quirky behavior. I've updated my recommended code snippet that can be used for any project with .S files that doesn't actually need execstack. It combines the dyncall approach (maximum portability) with the Swift approach (minimal code to add to .S; most everything lives in .h). That's at https://yorickdowne.wordpress.com/2017/01/04/wsl-bash-on-windows-as-a-dev-environment/

[uecker]

The accepted trade-off is to have a non-executable stack be default but have an executable stack for programs which need them. Not supporting this is just a deficiency in WSL.