Buffer overflows in packed code
 

Hi,

I have doubts about my understanding how/if packers protect against injecting shellcode. Take for example this analysis of the SKYPE software:
http://www.secdev.org/conf/skype_BHEU06.handout.pdf

As far as I understood this paper, those guys found a buffer overflow in the unpacked SKYPE code in the RAM. Apparently, they could exploit it and were able to inject shell code.

Of course, some chunks of code have to be unpacked in RAM. And as you do not need to inject packed shell code, you can do it. Seems to be clear to me.

So, packing does not complicate the exploitation of buffer overflows? It just complicates to find the buffer overflows?

Or am I wrong somehow?

boeser.hacker

>>Or am I wrong somehow?
No, you are right, "packing does not complicate the exploitation of buffer overflows".

This is a rather strange question, where did you hear that simple packing may prevent buffer overflow exploitation? You can read about some existing protection types at wikipedia:

hxxp://en.wikipedia.org/wiki/Buffer_overflow_protection
hxxp://en.wikipedia.org/wiki/Executable_space_protection

some packers make more easy the explotation. (let the code section with writable and execution permission etc)

ricnar

Thanks for your answer. While testing software, I frequently find buffer overflows. Instead of fixing the problem, people often try to complicate things (e.g. installing Address space layout randomization software).

The newest trick one of the programmers suggested was using UPX, because "the hacker needs encrypted shellcode" :rolleyes:

I doubt it, but as I am not too experienced in these topics, I just wanted some backup opinion. Thanks for it!

boeser.hacker

upx don't affect the explotation, the program when unpacked have the same code in memory when unpacked and executed, and upx let the code section with writable and execution permission.
If you cannot execute your shellcode for the DEP activated (stack and heap non executables) you can ret2libc to repmovs in code section, and copy the stack (or part) to the code section (this section have writable and execution permission, and jump to execute easy, only ret2libc to code).

Remember main executable 90% of the times have not asdlr, and with UPX you have a section with RWE and is a non moveable target.

Sorry for my bad english.

ricnar

Thanks for your thoughts. Can you explain then a bit more for me, as I am a n00b:
-If DEP is activated (like in XP SP2), a normal/unpacked program is a bit protected, because the stack/heap is not executable (return to libc still works). Now, you write "with UPX you have a section with RWE". Does this mean that without UPX you have some protection with DEP, but with UPX you do not?
-What do you mean with "non movable target"?

You see: My English is even worse :cool:


boeser.hacker

the code section of a unpacked program is only RE not W, with upx will be RWE, you can copy your shellcode to this section easily and execute, with ret2libc.

If ASLR code moves, the address is diferent, in diffferents machines, and in you machine change when restart, the code section of high percent of main executable are not affected by ASLR, by example if in your machine start in 401000 in all machines will start in the same address, and is more easy for explotation.

ricnar

sorry for my english again

the packer change the code section permission with VirtualProtect and put W for unpack the code and write, but when finish the unpacking forget change the permision to RE only and quit W, and jump to execute the code.

All code of the process will be writable if are NOT executable (RE only o viceversa RW only), but the code section will be writable and executable REW, the DEP is bypassed by the packer using VirtualProtect for write the code section, and let the code easy for copy and execute.

ricnar

Hi, thanks a lot for this is awful news :eek:
Like so often, if people use some "security tool" without understanding it, they become less secure. I have seen this pattern of behaviour with quite a few tools like AV or personal firewalls.

Are all packers like this or is it just UPX?

boeser.hacker

ah and is not really the sentence

the shellcode must be encoded if i use a packer

the program can be packed but the entry of bytes is encoded or undecoded independent of this, is a program feature not packer feature.

i see some packers with this problem upx, aspack some free packers
And if a better packer change the code section to RW only, explotation will be the same difficult to the same program unpacked.

Resuming packed program can be worst or equal not better.

ricnar