<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="https://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:openvz</id>
  <title>OpenVZ</title>
  <subtitle>OpenVZ</subtitle>
  <author>
    <name>OpenVZ</name>
  </author>
  <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/"/>
  <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom"/>
  <updated>2010-11-26T15:37:24Z</updated>
  <lj:journal userid="9392309" username="openvz" type="community"/>
  <link rel="service.feed" type="application/x.atom+xml" href="https://openvz.livejournal.com/data/atom" title="OpenVZ"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:34694</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/34694.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=34694"/>
    <title>On kernel exploits and OpenVZ user beancounters</title>
    <published>2010-11-26T15:37:24Z</published>
    <updated>2010-11-26T15:37:24Z</updated>
    <content type="html">Yesterday a guy with his name written in Cyrillic letters ("Марк Коренберг") and a @gmail.com email address &lt;a href="http://lkml.org/lkml/headers/2010/11/25/8" target="_blank" rel="nofollow"&gt;posted&lt;/a&gt; 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.&lt;br /&gt;&lt;br /&gt;The bad news are the exploit is pretty serious and causes Denial of Service. It looks like most kernels are indeed vulnerable.&lt;br /&gt;&lt;br /&gt;The good news is OpenVZ is not vulnerable. Why? Because of &lt;a href="http://wiki.openvz.org/UBC" target="_blank" rel="nofollow"&gt;user beancounters&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;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 &lt;code&gt;numothersock&lt;/code&gt; beancounter limit pretty soon and the script will exit. This is an except from /proc/user_beancounters after the run:&lt;br /&gt;&lt;br /&gt;&lt;small&gt;&lt;pre&gt;
 cat /proc/user_beancounters 
       uid  resource                     held              maxheld              barrier                limit              failcnt
.....
            numothersock                    9                  360                  360                  360                    1
.....
&lt;/pre&gt;&lt;/small&gt;&lt;br /&gt;&lt;br /&gt;As you can see, current usage is 9, while peak usage is 360, same as limit. Finally, &lt;code&gt;failcnt&lt;/code&gt; is 1 meaning there was once a situation when the limit was hit.&lt;br /&gt;&lt;br /&gt;I went further and set &lt;code&gt;numothersock&lt;/code&gt; 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.&lt;br /&gt;&lt;br /&gt;Now, this is how &lt;code&gt;/proc/user_beancounters&lt;/code&gt; look after the second run:&lt;br /&gt;&lt;small&gt;&lt;pre&gt;
       uid  resource                     held              maxheld              barrier                limit              failcnt
      111:  kmemsize                  1237973             14372344             14372700             14790164                   80
.....
            numothersock                    9                 2509  9223372036854775807  9223372036854775807                    1
&lt;/pre&gt;&lt;/small&gt;&lt;br /&gt;&lt;br /&gt;As you can see, even with numothersock set to unlimited, another beancounter, &lt;code&gt;kmemsize&lt;/code&gt;, is working to save the system.&lt;a name='cutid1-end'&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;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.</content>
  </entry>
</feed>
