OSDev.org

You can never call a function in another process, since in the virtual address space of a process, only the modules that have been loaded into that process are present, and the same module may even be mapped at different virtual addresses in the two processes.

Ok , so that is the reason I cann't get my shellcode that is injected on the exploit.exe stack to call my print function
in my test_exploit.exe.

So then all shellcode can do is execute a function/module in the current exploit.exe program or any function/dll that was imported into the exploit.exe address space.

I would think if shellcode tried to load a dll/lib into memory that wasn't in the .import section it won't work...
So it could only load a dll/lib that are in the import table. (correct me if I am wrong )

As well as your shellcode is restricted to write sections , like .data ,.text ,...etc can not be overflowed since they are not writeable sections. But the stack , bss, and heap are writeable... their are a few other sections that are writtable but you are pretty restricted in keeping the shellcode with in these section limits. (correct me if I am wrong.)

No, you can load any DLL. If it is listed in the import table of a loaded module, it will be already loaded. Kernel32 should in most cases be at the same address in both processes, so you can count on the location of LoadLibraryA being where you think it is.

.text is usually not a writeable section (although in programs compiled with NASM on Windows, it is), but the .data section is writeable. Uninitialized data is usually placed at the end of the .data section on Windows (in MASM, using the .data? directive).

Today's processors support non-executable pages, and many programs have their data sections, the heap and the stack marked as non-executable, making buffer overflows harder to take advantage of.

OK , but you cann't load a dll that is not in at least one imported table of some loaded program/module.
Meaning if the dll isn't loaded by another process or exe then your shellcode cann't manual load the non loaded dll.
Correct? So you are restricted to the dll that are loaded or in at least one import table of a loaded exe/module.
Is their away you can turn this on or off in a compiler like gcc or something.
As well if the stack is not executeable how could you ever get shellcode to run?
I guess what I am trying to find out is how the operating system keeps track of and cancels somebody from executing something on a non-executable section... (in your exe )
I get how it works if you go outside your privlage level , or outside something that the GDT,LDT had setup.
But when you are locally in your own exe address space? Does the os have a built in interrupt telling the operating system when it is trying to execute on the stack...etc

Thanks
And is their away to disable this protection thru the compiler or linker gcc to beable not to have those issues with my shellcode.
I.e not have to worry about the stack not being executable ,...etc

Sam111 wrote:Is their away you can turn this on or off in a compiler like gcc or something.

Probably.

Sam111 wrote:As well if the stack is not executeable how could you ever get shellcode to run?

Isn't the point that you *don't* want shellcode or other exploits to work?
Basically, if you want to test methods of doing exploits, you'll (for very good reasons) have to do it on a program which you've deliberately compromised.

Sam111 wrote:I guess what I am trying to find out is how the operating system keeps track of and cancels somebody from executing something on a non-executable section... (in your exe )

Generally, by using the various hardware mechanisms to prevent execution of certain pages (apart from the execute-disable bit, think about if the code was always in low memory and the kernel set CS.top != 0xFFFFFFFF)

As I said, you can load any DLL. There would be no point in only being able to load a DLLs that were already loaded, would it?

With Microsoft Link, the /NXCOMPAT switch activates Data Execution Prevention, and /NXCOMPAT:NO disables it. The executable attribute can be specified for each individual section using /SECTION. Attempting to execute an instruction within a page that has the NX bit set causes an exception.

With DEP enabled, buffer overflows must try to cause the program to end up in a function that does what you want, for example by causing it to return to LoadLibraryA such that after the return, [esp+4] points to the name of your DLL. This is often much harder than it would be if you could execute arbitrary code.

This kind of exploit is why all OSes now have address space layout randomization.

So if DEP is enabled then you must overflow the stack so that the return address returns you to something in the exploited exe address space (either a function in that program or a library function )
Correct me if I am wrong.

You mentioned that you could load any dll but if the DEP was enabled then you couldn't execute the code to load your library on the stack with shellcode so you would be stuck with already loaded libararies or the functions with the exploited programs address space... thats it.
So I would think for bufferoverflows to be useful they must find a program that isn't DEP protected then if you are good you can craft your own dll with what you want to execute ,load it /call it from the executable stack shellcode. <--- then you would have complete control


Also does anybody know if gcc uses DEP by default if so how would you do the equivalent /NXCOMPAT:NO for gcc?

Realistically if I am correct bufferoverflows won't really be of much use if DEP is implemented.
The worst you could do is jump to another function/ or already load dll in the same address space which would probably crash any way because the parameters won't be correct,...etc etc

I can see big security issues if DEP is not on though.

Is their also away to use objdump or some other tool that would allow you to check if the stack is DEP protected or not?
objdump seems to only give the attributes for the sections in the exe file not the stack or heap that is created automatically by the Os. Wondering where in the elf header the attrubites for read/write but not execute the stack/heap would be. Something must provided this.

Sometimes, one can redirect execution to LoadLibraryA such that the parameter points to an area on the stack that is under your control, so that you can specify the name of a DLL without executing any shellcode, but it's uncommon.

As far as I know, ELF does not have an option to specify if the program is compatible with DEP. This option exists only on Windows.

GCC has something called "ProPolice" or SSP in GCC4, a lot of operating systems are implementing additional "security" these days (..like DEP), but.. have existed in OpenBSD long before it was considered "cool".

Sometimes, one can redirect execution to LoadLibraryA such that the parameter points to an area on the stack that is under your control, so that you can specify the name of a DLL without executing any shellcode, but it's uncommon.

As far as I know, ELF does not have an option to specify if the program is compatible with DEP. This option exists only on Windows.

Ya, but that would be almost next to impossible. And even if you did get it to work on your computer it probably wouldn't work on somebody else computer...

So where in what header is the DEP settings for the PE .exe windows version.
I guess what I am asking is does anybody know where the complier sets this DEP option in the PE file.

And if ELF doesn't support DEP then how does OpenBSD have this ability since on BSD systems correct me if I am wrong.
They use a.out , coff , or elf or some variant of them. none of these exe file formats contains any security parameter for making the stack r/w but not executable... that I know of (looking at the formats I don't see any of them)

Seems to me bufferoverflows are dieing out..... But their are still exploits that give people viruses and I thought 90% of exploits (other then DOS attacks ) relied on bufferoverflows.

I mean how else does those virus writers ,...etc ect get exe to randomly execute on your machine without you clicking run. ( has to be some bufferoverflow exploit ) And it seems viruses are not really dieing out for microsoft computers.
You still see them poping up here and their but with DEP I would think they should be completely gone.......
I have to ask how long ago was DEP being used in windows os's because once every application/compiler has the DEP on by default I would think bufferoverflows would be pretty much died.

I am using this gcc So is this DEP on by default or not if so how do I turn it off?

Also do they use DEP on the heap as well? because if not then their is still the ability to do heap overflows (however they are usually harder to do because the heap is not as predictable as the stack.)

DEP appears to be similar to OpenBSD's W^X, where either a memory page is writable or executable, but not both (write XOR execute).. this has nothing to do with the compiler, and is implemented in the kernel (..using architectural dependant features, like AMD64's NX bit, or line in the sand segmentation tricks).

ProPolice/SSP as I mentioned previously is a stack protector, it works by adding a special "canary" on the stack and if it gets trampled (..by overflowing a variable), it's detected and the process is terminated.

http://en.wikipedia.org/wiki/Data_Execution_Prevention
http://en.wikipedia.org/wiki/W%5EX
http://en.wikipedia.org/wiki/Buffer_ove ... oPolice.29

Brynet-Inc wrote:GCC has something called "ProPolice" or SSP in GCC4, a lot of operating systems are implementing additional "security" these days (..like DEP), but.. have existed in OpenBSD long before it was considered "cool".

So have Linux and Solaris, and many other operating systems, on platforms with page level execution control.

Of course, OpenBSD's W^X may have prior to AMD adding it to PAE paging been implemented with that aforementioned line in the sand.

Sam111: "Return to Libc" attacks, as they are called, have historically been very successful, because system libraries tended to be located at the same address all the time. Getting appropriate addresses for pointer parameters has always been difficult, but never overtly so. It must be noted that, if one controls the x86 stack, they can implement any sequence of function calls they want; this is made somewhat difficult on platforms which use the C calling convention for libraries (due to a lack of stack cleaning), but Windows makes this very easy with __stdcall. One can, from top to bottom, place the function address and then its arguments; the attack smashes the return address and replaces it with the desired function.

As it cannot be predicted exactly how the stack will differ across versions of a program, it is somewhat conventional to include a bunch of nonce function addresses in order to align the attack with the return address on the stack; this nonce function must take no arguments (or use the C calling convention) to ensure things align correctly. This is similar in principle to a "nop slide".

In a Windows PE executable, NX compatibility is indicated in bit 8 of DllCharacteristics. This is bit 0 of the byte at offset 95 starting from the "PE" signature.

When talking about DEP on Windows, they mean hardware DEP. It's not the same as W^X, it just means that execute permissions of pages are honoured. All pages can be specified as writeable and/or executable independently.

The reason that it must be enabled explicitly using the NX compatibility bit is that many old programs from before PAE was introduced were written under the assumption that execute permissions do not matter on x86 systems.