This is an analysis of a vulnerability discovered by Juan Sacco. The vulnerability has no given CVE ID.
The interesting fact here is that at the time of writing, the latest version for linux-based systems is the vulnerable version.
This vulnerability is very easy to exploit as it has no restrictions in the code needed to bypass or any type of difficulties, it is just a simple buffer overflow that has no canary and as exploited in the statically-compiled jad version, is loaded on a fixed memory location, then no leaks are needed and for the exploitation we can just craft a file that contains the payload without having to interact with the program.
The exploit is not much useful in most of environments as it is just a local binary, without servers that allow us to exploit a remote code execution. It is not suid by default, and it does not require root permissions, so no EoP can be exploited by default.
Anyway, I found some web services that let you interact with jad to decompile a java-compiled file through a web interface. This could be an interesting attack vector to use for this exploit.
Also, if the binary is SUID, we could exploit an EoP to get root privileges (like I did for demonstrating the PoC).
The problem resides in the argv read in the jad binary, it does not check whether the data provided is bigger than the buffer where it copies into is.
That means an attacker can overflow not only internal data but also the saved EBP and EIP in the stack, allowing them to change the program control flow and execute code.
To make the exploit reliable, I used a “call esp” gadget, and as the data space before EIP is huge, I used it for shellcode, then after ESP I entered a trampoline that performs a “sub esp, 400 ; jmp esp”, then it will finally start executing the nopsled until the shellcode is reached.
The only restriction for this exploit to work is no NULL bytes in the payload, as we are passing them as program arguments.
PoC execution:
You can find the full working PoC here.