Re: [gentoo-hardened] Any hardened features to protect from CVE-2016–5195 like vulnerabilities?

[R0b0t1]

On Mon, Dec 5, 2016 at 12:39 AM, Andrew Savchenko <bircoph@g.o> wrote:
> Hi all,
>
> I'd like to know is there any way to protect from kernel
> vulnerabilities like CVE-2016–5195 (mad COW) using hardened
> technologies. (I'm not talking about how to fix this exact CVE, but
> how to protect from similar failures in future.)
>

In the strictest interpretation of your question, no, as once write
permission to arbitrary memory is gained it would in principle be
possible to subvert any other security mechanisms in place.
Randomizing the address space goes a long way to making such attempts
intractable, but if nothing is done to limit the number of attempts
success is inevitable.

> Based on exploit published I can think of the following approaches:
>
> 1) Exploit runs enormous amounts of madvise() calls, any way to
> rate limit it or block after some threshold is reached? I doubt
> there is any legitimate use case for calling madvise() that often.
>

Yes. They all involve SELinux/RBAC and grsecurity extensions. Every
facet of the kernel dealing with permissions, real hardware, and
memory management has been instrumented and some default safeguards
added. It can't be foolproof but the goal isn't to be foolproof. It is
to construct as tortuous a path as possible for any potential
attacker.

With SELinux/RBAC, most exploits cease to have any effect -
permissions can be elevated but potential accesses would be against
policy and are so denied.

> 2) Exploits uses huge rate of write() calls and most the fails due
> to access restrictions. This is definitely suspicious. Can such
> behaviour be spotted and blocked by some security feature?
>

Yes, see above (this is probably the easier choice as it is more general).

> 3) Can some hardware features like Intel TSX be used to protect
> from such race conditions?
>

Yes, but this would require code to take advantage of such mechanisms
and for that code to be properly written - and since we're talking
about mitigating bugs, we're back to square one. There are some
features in this vein that could be used in critical sections of the
kernel and the problem would be over and done. On the other hand, an
exploit could target the interaction of two kernel mechanisms which
could not be synchronized in any reasonable way.

> Best regards,
> Andrew Savchenko

In addition to instrumenting your kernel, you need to actually *look*
at the information that that instrumentation produces. Monitoring your
system for suspicious activity is probably the best thing you can do.