replace RET wit JMP

[yazriel]

I am working on a code-modifying package for reducing vulnerabilities.
The package will probably modify the code segment when the PE when it is loaded.

right now, i want to remove all RET instructions, and replace them with a JMP

JMP securelocation   ; probably a long jump

securelocation:
; check that return address on stack is "sensible" and points to existing legal code
; if not raise alarm
RET

Obviously there are implementations details with OPCODE length and popping the stack

But can anyone see a fundamental problem with such a markup ?
I hope to support a wide range of existing PEs which probably do all sort of crazy stuff

Thank you
p.s. I used to do MASM in my university days but i am kind of rusty ... doing kernel work these days

[dedndave]

this subject is against forum policy
read the rules...

http://www.masm32.com/board/index.php?topic=31.0

anyways, replacing a ret with a jmp doesn't seem very viable

[hutch--]

The problem is replacing a RET with a direct JMP is lousy code design, processors match CALL / RET and when you use this technique you mess it up and slow down the app.

[redskull]

But can anyone see a fundamental problem with such a markup ?

How exactly do you know what constitutes "sensible" code for any given program?  More to the point, what's stopping anyone from just cracking YOUR program and exploiting the same vulnerability?

-r

[yazriel]

But can anyone see a fundamental problem with such a markup ?

How exactly do you know what constitutes "sensible" code for any given program?  More to the point, what's stopping anyone from just cracking YOUR program and exploiting the same vulnerability?

-r

"sensible" in our case is a any previously-loaded code page which is from the original PE image..

Not sure what you mean by "crack"....
I am protecting against malware which is trying to exploit a buffer overflow vulnerabilities in existing code...

A stack overflow for example is likely to overwrite the RET address on the stack
Any buffer overflow is unlikely to overwrite any code area.

[yazriel]

The problem is replacing a RET with a direct JMP is lousy code design, processors match CALL / RET and when you use this technique you mess it up and slow down the app.

I agree that performance will suffer. But i can accept that.

Btw, can you explain "processors match CALL / RET" ?

In "Agner Optimizing Assembler" p.67 he does a related optimization of removing a CALL which is followed by RET

[hutch--]

This is exactly what DEP was written to do, make stack exploits fail on DEP enabled machines. Some of the later OS design allows for randomisation of the stack address for each application started to further complicate attempted stack exploits.

Just note Dave's original warning, this is not a security forum but an assembler programmers forum and while you may have a valid security task in mind, we do not allow viral technology or related tasks here as there is no safe way to control the contents.

[hutch--]

RE the question on CALL / RET matching, just look it up in a current Intel manual.

[dedndave]

since we seem to be allowing this line of discussion....

a better approach may be to retrieve the return address from the stack
replace that address (on the stack) with the address of your code
when your code is finished, then branch to the original address that you retrieved from the stack
you had better realize that the ret may pop some stuff off the stack   :P
i.e., you may have to modify the operand of the ret instruction
and make an adjustment prior to returning control to the normal flow
but, there is no problem with trying to jam a 10 pound jmp instruction into a 5 pound ret location

another way to go - insert an INT3 at the ret location
very similar, however you have to deal with debug stuff

as for your comment on buffer overflow, i doubt that they overwrite any code or stack data
if they did, the program would crash - not what they are after
the overflow exploits rely on the error handling mechanism to catch the overflow and execute exception code
that is where the injection is made

i suggest you copy/paste the text of this thread into a file and save it, as boggie will send it to the round file

[redskull]

"sensible" in our case is a any previously-loaded code page which is from the original PE image..

Like Hutch said, it's already built into the O/S..

I am protecting against malware which is trying to exploit a buffer overflow vulnerabilities in existing code...

Except that same malware that can overwrite the original exe can probably overwrite your 'safe' code that protects it, since it's in the same process

A stack overflow for example is likely to overwrite the RET address on the stack

So even if you could safely and reliably do this, what did you plan on doing to correct it?  The only thing you can do is crash the program, which is what would happen anyway.

-r

[hutch--]

I think the members have made it clear that,

(a) The task is not technically feasible.
(b) The rules of the forum exclude security based issues.

This topic is closed and no other of its type should be started again.