Yesterday a guy with his name written in Cyrillic letters ("Марк Коренберг") and a @gmail.com email address posted a kernel exploit to the Linux kernel mailing list (aka LKML). This morning one brave guy from our team tried to run it on his desktop -- and had to reboot it after a few minutes of total system unresponsiveness.
The bad news are the exploit is pretty serious and causes Denial of Service. It looks like most kernels are indeed vulnerable.
The good news is OpenVZ is not vulnerable. Why? Because of user beancounters.
The nature of exploit is to create an unlimited number of sockets, thus rendering the whole system unusable so you need to power-cycle it to bring it back to life. Now, if you run this exploit in an OpenVZ container, you will hit the
As you can see, current usage is 9, while peak usage is 360, same as limit. Finally,
I went further and set
Now, this is how
As you can see, even with numothersock set to unlimited, another beancounter,
Of course, if you set all beancounters to unlimited, exploit will work. So don't do that, unless your CT is completely trusted. Those limits are there for a reason, you know.
The bad news are the exploit is pretty serious and causes Denial of Service. It looks like most kernels are indeed vulnerable.
The good news is OpenVZ is not vulnerable. Why? Because of user beancounters.
The nature of exploit is to create an unlimited number of sockets, thus rendering the whole system unusable so you need to power-cycle it to bring it back to life. Now, if you run this exploit in an OpenVZ container, you will hit the
numothersock beancounter limit pretty soon and the script will exit. This is an except from /proc/user_beancounters after the run:
cat /proc/user_beancounters
uid resource held maxheld barrier limit failcnt
.....
numothersock 9 360 360 360 1
.....
As you can see, current usage is 9, while peak usage is 360, same as limit. Finally,
failcnt is 1 meaning there was once a situation when the limit was hit.I went further and set
numothersock limit to 'unlimited', and re-run the exploit. The situation is much worse in that case (don't try it at home, you've been warned), system slows down considerably, but I was still able to login to the physical server using ssh and kill the offending task from the host system using SIGTERM.Now, this is how
/proc/user_beancounters look after the second run:
uid resource held maxheld barrier limit failcnt
111: kmemsize 1237973 14372344 14372700 14790164 80
.....
numothersock 9 2509 9223372036854775807 9223372036854775807 1
As you can see, even with numothersock set to unlimited, another beancounter,
kmemsize, is working to save the system.Of course, if you set all beancounters to unlimited, exploit will work. So don't do that, unless your CT is completely trusted. Those limits are there for a reason, you know.


Comments
Do you still stand by your opinions above now in 2016?…