On Mon, Dec 5, 2016 at 12:39 AM, Andrew Savchenko <birc...@gentoo.org> 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.
