Re: CVE-2014-4699

On 07/11/14 14:00, Balint Szente wrote:
> Hello!
>
> On Fri, 11 Jul 2014 20:31:11 +0300
> Alex Efros <[email protected]> wrote:
>
>> There is a risk production won't boot or won't be stable with new
>> kernel. First one isn't risk at all, 'cos if it won't boot you'll
>> immediately notice this and just boot previous kernel instead - this
>> won't even result in noticeable interruption of your services (no
>> more than usual when you reboot to update kernel).
>
> It is not always possible to reboot with the previous kernel. There are
> datacenters (and not so few) who do not give you remote console access.
> So in case of boot issue or kernel panic you have to contact someone
> (who is not always available btw.) and ask nicely to reboot with the old
> kernel. It happened to me once with such a datacenter, that the new
> kernel version had some incompatibility with Hyper-V resulting in
> panic and the interruption was nasty.
>

Thank you for understanding.  This is precisely why I don't just jump to 
stabilizing even with major security bugs --- I don't believe in 
securing your severs by locking them up.  Let me describe how kernels go 
from the grsec/pax patches to stable: 0.  I have automatic scripts for 
watching upstream when it pushesout new patchsets.  1. After downloading 
a new grsec/pax patchset, I compare it to the old to see what's been 
added.  If its a minor fix, I will replace a previous hardened-sources 
version on the gentoo tree with the latest.  If its major, like when 
upstream merges a new PaX patchset into grsec, I keep the previous 
hardened-sources version around.  2. I do a test to make sure all the 
patches apply and play nicely with the gentoo specific patches --- 
hardened-sources includes genpatches and there are conflicts sometimes. 
  3. I do a compile test.  4. I do a boot/run test on amd64/i686 
hardware.  5. It goes on the tree ~arch.  6. I wait for 4 weeks and if 
there are no major bugs, I stabilize.

Rapid stabilization breaks this cycle.  Because I cannot test on all 
different hardware, I need community feedback whether some kernel which 
is marked ~arch is breaking.  We need time for this feedback.  I don't 
think it is wise securing people's servers by locking them up, so when I 
stabilize, I'm sending a message that I've done everything reasonable to 
make sure this kernel will work.  I want datacenters to be confident in 
these kernels.

>> Second is a real issue, of course, but chances are it will show itself
>> several days or even weeks later, and it's really questionable is it
>> good idea to spend so much time testing new kernel "just in case" in
>> this situation.
>>

It takes time before an exploit like this makes it to the wild.

>> At same time there is a FACT (i.e. risk with 100% chance to happens)
>> what your production is vulnerable, and any user (or even someone with
>> webshell) is able to crash it or even get root and own it.
>
> This is not a remote vulnerability. It is a local one
> (see <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4699>).
> Usually on production servers there is no local access anyway for
> arbitrary users. You do not let people to copy executables to your
> server and run it afterwards. So this vulnerability is not critical at
> all.
>
> You can any time unmask the newer kernel and use it if it fits better
> for you. There is no need to stabilize it blindly.

Correct.

>
> Regards,
> Balint
>

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : [email protected]
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA