Here is the scenario:

You get to overwrite 4 (consecutive) Bytes of a Userland Remote Process in Linux without Exploit Mitigation and without the ability to inject any Shellcode and you know the Process Memory Layout. Is this Exploitable?

  • Do you mean on disk, or in memory? The answer is yes in both cases...
    – lynks
    Commented Apr 2, 2013 at 13:41
  • In the memory of the running process, and how would you exploit it? And how would you get arbritary code execution?
    – Rob
    Commented Apr 2, 2013 at 13:47

2 Answers 2


In the sense that you can cause the program to act in a way that it shouldn't, then yes this is exploitable. To exactly what degree you can exploit the process entirely depends on the process itself.

Causing the process to terminate with an error (Denial of Service) is easy, just write 4 random bytes to a random location and you'll probably trip it over.

A 4byte overwrite allows you to supplant a 32bit address value. The first thing that comes to mind is to subvert program flow, either a return, a call, or a jump.

If you can find a piece of code that does something useful to you, typically by looking at the libraries that are loaded, you can jump to that. You might even be able to make a system call if you can find a situation that has the correct arguments loaded onto the stack before a program flow instruction.

You could overwrite the value of a pointer on the stack to point at something else, this could easily lead to information disclosure. Such as altering the pointer that points to your username string so that it points to a secret key, or a password hash, and then interacting with the program such that it would usually echo out your username string.

You could alter an entry in the Global Offset Table to supplant one function call with another function call globally across the process. This would allow you to, for example, remove a wrapper function by making all calls to the wrapper actually calls to the inner function, potentially removing a security feature, such as a parameter check, which you could later exploit.

I could go on, but the idea is either to;

  • Make the program do something that is desirable to you.
  • Alter the program such that it is vulnerable to exploitation some other way.
  • Ok, so either overwriting GOT entry or .dtors or something similar, but there will be no generic way to get exactly the code to execute you want to, so it will depend on the process/application to how dangerous the vulnerability will be.
    – Rob
    Commented Apr 2, 2013 at 13:56
  • @Rob nowadays there is very rarely a 'generic' solution to any kind of memory-corruption exploit. The days of stack-smashing are over. Finely crafted exploits which are specific to process and machine are the new status quo.
    – lynks
    Commented Apr 2, 2013 at 13:58
  • I know that, but this is the reason i said there are no exploit mitigation techniques in this scenario ;). This is just something that came to my mind, and i thought maybe there is someway to get to rop the process but that will be difficult without controlling the stack.
    – Rob
    Commented Apr 2, 2013 at 14:02
  • @Rob you have no chance of building a RoP chain here, as that requires a decent chunk of stack control as you say. This is one of those 'use your imagination' scenarios that requires some creativity.
    – lynks
    Commented Apr 2, 2013 at 14:03

Just because you can't directly inject shellcode doesn't mean you can't inject it at all. Maybe there's a way to upload a file that the application will open. If the application is listening on the network, you can start communicating with it; even if it quickly drops the request because you can't authenticate, that still leaves your packet in memory. Injecting the shellcode can (and often has to) be done through legitimate means, with the vulnerability only letting you jump to it.

If the application performs an authentication step at any point, bypass it or negate it.

4 bytes lets you change one address. For example, you can substitute a function call for another. There may be an interesting string to call system on already in memory, or you may be able to supply one. If the application ever opens a socket, arrange to jump into the socket opening code (say, to a bind call) while registers are pointing to an unintended structure that causes it to listen to a connection coming from you. Changing AF_UNIX to AF_INET on a socket call (single-byte change) might be all it takes if you're lucky.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .