flat assembler
Message board for the users of flat assembler.

Index > Linux > Need to defeat NX (Exec Shield?) for a program on a server

Author
Thread Post new topic Reply to topic
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
ronware
I'm tracking down why my Reva Forth doesn't build on my "hostmysite" web-server.

It seems they are running Redhat Enterprise AS 4, which has various security enhancements. Among them, it apparently takes advantage of the NX CPU bit.

Does anyone know how I can defeat this protection for my application? Is that even possible, or do I have to beg the sysadmin to let my program run?
Post 29 Aug 2006, 17:46
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Does Linux provides an equivalent for VirtualProtect of Windows? If it does then you can set execute permission for the allocated pages (which should disable the NX bit).
Post 29 Aug 2006, 18:02
View user's profile Send private message Reply with quote
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
ronware
I tried using "mprotect" to set all the areas to read/write/execute, but it didn't have the effect I need.
Post 29 Aug 2006, 18:05
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
crc



Joined: 21 Jun 2003
Posts: 637
Location: Penndel, PA [USA]
crc
On the 3.x line of Redhat Enterprise Server, using "setarch i386 <binary>" would disable the exec-shield for that binary. I'm not sure if this works on 4.x though.
Post 29 Aug 2006, 22:11
View user's profile Send private message Visit poster's website Reply with quote
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
ronware
Nice try - but "setarch" doesn't exist on this server.
Post 29 Aug 2006, 22:14
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
ronware, do you execute from memory from malloc() (or whatever equivalent you're using)? Or even, shudder, from the stack?

If that's the problem, you might want to try changing the memory allocation to mmap(), where you can specify PROT_READ|PROT_WRITE|PROT_EXEC...
Post 29 Aug 2006, 23:10
View user's profile Send private message Visit poster's website Reply with quote
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
ronware
The program is written in FASM, it doesn't even do memory management. Code is not executed off the stack, but it does use self-modifying code to some extent
Post 29 Aug 2006, 23:16
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Just to clear up something from your original post - do you mean "Doesn't build" or "Doesn't run"?

I can see your '.flat' section is writable/executable (hm, why not readable as well?), so perhaps the linux distro takes it upon itself to enforce read-only for code sections?

Or perhaps the syscall interface has changed? (seems unlikely, but still needs to be considered)

And obviously you *do* some memory management, at least I see references to malloc and friends, so the question re-appears: do you ever execute from dynamically allocated memory?
Post 30 Aug 2006, 11:16
View user's profile Send private message Visit poster's website Reply with quote
ronware



Joined: 08 Jan 2004
Posts: 179
Location: Israel
ronware
To clarify: it doesn't build. The build is in two stages: 1) build "revacore" and 2) build "reva" using "revacore".

The first step is fine. "revacore" even runs, and works "ok" until you try to create a new word (which the build of "reva" does almost exclusively). To see what I mean, do:

bin/revacore
234 4 (.r) type

You should see " 234" print out. This indicates that the interpreter portion works fine. Now type:

: a ;
a

Trying to execute the new "a" word will cause a SIGSEGV. So until I spend some serious time trying to debug this, I will just be guessing.

Yes, I thought that perhaps they are enforcing read-only code, in which case I'm probably out of luck because changing that would be a major rewrite (e.g. only compiling into allocated memory, then changing the permissions to 'execute', etc.). Trying "mprotect" didn't help, though perhaps I invoked it incorrectly.

OK, you're right - I do actually use "malloc" in the "revacore" - but not for executing, just for read/write.
Post 30 Aug 2006, 15:50
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.