Tag: vulnerable

Categories
Linux Security

Mooooo linux Dirty cow vulnerbility cve-2016-5195

What is Dirty Cow

CVE-2016-5195 is a bug in the Copy On Write mechanism of the Kernel. Any user or user owned process can gain write access to memory mappings which should be read only for the end user. This allows them to interact with otherwise root only files. Should you worry about it? YES. you should jpatch your system(s) right away!

Who found CVE-2016-5195?

Who cares? ITS BAD PATCH NOW!! ok just kidding, security researcher Phil Oester was the first one to publically release info about this exploit. He found it via a http packet capture setup.

Is this related to SSL / OpenSSL?

No, unlike heartbleed, poodle etc this is not related to SSL.

Where can I get some official info about this exploit?

Not sure what you mean by official but check at mitre and Redhat

How to find out if I am affected?

Ubuntu / Debian

type as root  or with sudo
uname -rv

sample outputs :

4.4.13-1-pve #1 SMP Tue Jun 28 10:16:33 CEST 2016
2.6.32-openvz-042stab104.1-amd64 #1 SMP Thu Jan 29 13:06:16 MSK 2015
4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016
3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

List of kernel numbers which need to be updated.

  • 4.8.0-26.28 for Ubuntu 16.10
  • 4.4.0-45.66 for Ubuntu 16.04 LTS
  • 3.13.0-100.147 for Ubuntu 14.04 LTS
  • 3.2.0-113.155 for Ubuntu 12.04 LTS
  • 3.16.36-1+deb8u2 for Debian 8
  • 3.2.82-1 for Debian 7
  • 4.7.8-1 for Debian unstable

Redhat / Centos / Fedora

wget the test file directly from redhat access :

wget https://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh
CHmod +x rh-cve-2016-5195_1.sh
bash rh-cve-2016-5195_1.sh

If you are vulnerable you will get a result such as :

Your kernel is X.X.X.X.X.x86_64 which IS vulnerable.
Red Hat recommends that you update your kernel. Alternatively, you can apply partial mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .

update your kernel and reboot.

How do I upgrade my kernel?

Debian: sudo apt-get update && sudo apt-get dist-upgrade
Redhat: sudo yum update kernel

now sudo reboot and you are in happy land. if you are paranoid like me just run uname -rv again and test.

[/et_pb_text]

[et_pb_text admin_label=”Text” background_layout=”light” text_orientation=”left” use_border_color=”off” border_color=”#ffffff” border_style=”solid”]

Original and new git commit messages to Linux Kernel regarding this exploit :

commit 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Author: Linus Torvalds <[email protected]>
Date: Mon Aug 1 11:14:49 2005 -0700

Fix get_user_pages() race for write access

There’s no real guarantee that handle_mm_fault() will always be able to
break a COW situation – if an update from another thread ends up
modifying the page table some way, handle_mm_fault() may end up
requiring us to re-try the operation.

That’s normally fine, but get_user_pages() ended up re-trying it as a
read, and thus a write access could in theory end up losing the dirty
bit or be done on a page that had not been properly COW’ed.

This makes get_user_pages() always retry write accesses as write
accesses by making “follow_page()” require that a writable follow has
the dirty bit set. That simplifies the code and solves the race: if the
COW break fails for some reason, we’ll just loop around and try again.

commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
Author: Linus Torvalds <[email protected]>
Date: Thu Oct 13 20:07:36 2016 GMT

This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a (“Fix
get_user_pages() race for write access”) but that was then undone due to
problems on s390 by commit f33ea7f404e5 (“fix get_user_pages bug”).

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in abf09bed3cce (“s390/mm: implement
software dirty bits”) which made it into v3.9. Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the “yes,
we already did a COW” rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.