Is this Scenario Exploitable?

Question

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?

Answer 1

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.

Answer 2

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.