Mailing List Archive

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

2016.December 5.(H) 07:39 időpontban Andrew Savchenko ezt írta:
> 3) Can some hardware features like Intel TSX be used to protect
> from such race conditions?

Just a sidenote on TSX: although it sounds procmising, I've been seeing
multiple reports on Intel disabling the feature on several processors by
microcode update due to various bugs since its debut. Not just some
Haswell and Broadwell, but also some Skylake prcoessors are involved as
well.

https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions
"In August 2014, Intel announced that a bug exists in the TSX
implementation on Haswell, Haswell-E, Haswell-EP and early Broadwell CPUs,
which resulted in disabling the TSX feature on affected CPUs via a
microcode update.[9][10][21] The bug was fixed in F-0 steppings of the
vPro-enabled Core M-5Y70 Broadwell CPU in November 2014.[22]"

https://www.reddit.com/r/hardware/comments/44k218/intel_disables_tsx_transactional_memory_again_in/

BR: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

On Mon, Dec 5, 2016 at 1:45 AM, "Tóth Attila" <atoth@atoth.sote.hu> wrote:
> 2016.December 5.(H) 07:39 időpontban Andrew Savchenko ezt írta:
>> 3) Can some hardware features like Intel TSX be used to protect
>> from such race conditions?
>
> Just a sidenote on TSX: although it sounds procmising, I've been seeing
> multiple reports on Intel disabling the feature on several processors by
> microcode update due to various bugs since its debut. Not just some
> Haswell and Broadwell, but also some Skylake prcoessors are involved as
> well.

This is a good point - the hardware needs to be properly implemented
as well. There have already been cases where improper implementation
and unaccounted-for physical interactions have been used to elevate
permissions.


> BR: Dw.
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
>

Apologies, a combination of a different keyboard and gmail shortcuts
cut that off. I meant to link to:
https://en.wikipedia.org/wiki/Row_hammer.

I expect bugs similar to rowhammer and mad COW to become more
pervasive as architectures shift towards a combination of high core
count, application specific features, and more complicated memory
sharing and locking mechanisms. As far as I am aware no designs
receive a human audit and are all produced by automatic synthesis
tools. Certain older Intel parts are/were popular in aviation as they
were the last chips to be designed by hand.