Nethammer and kernel network drivers

Nethammer and kernel network drivers

[procmem]

Hello. I wanted to get your attention about a new, more serious
reincarnation of rowhammer called nethammer that doesn't need to execut
any code on the system like in the past nor does it leave a trace.

The summary of the paper is that rowhammer can be
remotely triggered by feeding susceptible* network driver crafted
traffic. This attack can do all kinds of nasty things such as modifying
SSL certs on the victim system.

* Susceptible drivers are those relying on Intel CAT, uncached memory or
the clflush instruction.

In absence of hardware mitigations, please identify and disable/fix
susceptible network drivers to avoid this type of attack. Thanks.

**

[0] https://arxiv.org/abs/1805.04956

Re: Nethammer and kernel network drivers

[Greg KH]

On Sat, Jun 02, 2018 at 03:46:19AM +0000, procmem wrote:
> Hello. I wanted to get your attention about a new, more serious
> reincarnation of rowhammer called nethammer that doesn't need to execut
> any code on the system like in the past nor does it leave a trace.
> 
> The summary of the paper is that rowhammer can be
> remotely triggered by feeding susceptible* network driver crafted
> traffic. This attack can do all kinds of nasty things such as modifying
> SSL certs on the victim system.
> 
> * Susceptible drivers are those relying on Intel CAT, uncached memory or
> the clflush instruction.
> 
> In absence of hardware mitigations, please identify and disable/fix
> susceptible network drivers to avoid this type of attack. Thanks.

Any hint as to how to identify such drivers?  Have you looked into what
this would entail?

thanks,

greg k-h

Re: Nethammer and kernel network drivers

[procmem]

Hi. I asked one of the authors (Daniel Gruss) to give you more
insightful feedback as its more helpful in the matter.


Greg KH:
> On Sat, Jun 02, 2018 at 03:46:19AM +0000, procmem wrote:
>> Hello. I wanted to get your attention about a new, more serious
>> reincarnation of rowhammer called nethammer that doesn't need to execut
>> any code on the system like in the past nor does it leave a trace.
>>
>> The summary of the paper is that rowhammer can be
>> remotely triggered by feeding susceptible* network driver crafted
>> traffic. This attack can do all kinds of nasty things such as modifying
>> SSL certs on the victim system.
>>
>> * Susceptible drivers are those relying on Intel CAT, uncached memory or
>> the clflush instruction.
>>
>> In absence of hardware mitigations, please identify and disable/fix
>> susceptible network drivers to avoid this type of attack. Thanks.
> 
> Any hint as to how to identify such drivers?  Have you looked into what
> this would entail?
> 
> thanks,
> 
> greg k-h
> 

Re: Nethammer and kernel network drivers

[procmem]

Hello. Daniel provided more details on the problematic areas of the
kernel and I quote what he said verbatim:


> We have only found very outdated network drivers using clflush (old
> windows ndis code). On ARM there are many drivers using uncached memory.
> However, we have so far failed to produce enough memory traffic on ARM
> to trigger a bit flip with Nethammer on any ARM device.
> It should be possible though if you can make the ARM device handle
>> =300MBit/s.
> And that's the most plausible scenario.
>
> Anyway, searching for clflush or use of uncached memory is a good idea
> to locate the critical spots.
>
> Intel CAT is (we believe) not used anywhere yet. And we must be careful
> when it gets to the point where we introduce usage of CAT for QoS
> mechanisms.
>
> However, my intuition tells me that most systems are not even vulnerable
> to Rowhammer in the first place. Although the only prevalence studies we
> have suggest otherwise (they find 60-80% are affected).
>

Re: Nethammer and kernel network drivers

[Greg KH]

On Sat, Jun 02, 2018 at 05:41:09PM +0000, procmem wrote:
> Hello. Daniel provided more details on the problematic areas of the
> kernel and I quote what he said verbatim:
> 
> 
> > We have only found very outdated network drivers using clflush (old
> > windows ndis code). On ARM there are many drivers using uncached memory.
> > However, we have so far failed to produce enough memory traffic on ARM
> > to trigger a bit flip with Nethammer on any ARM device.
> > It should be possible though if you can make the ARM device handle
> >> =300MBit/s.
> > And that's the most plausible scenario.
> >
> > Anyway, searching for clflush or use of uncached memory is a good idea
> > to locate the critical spots.
> >
> > Intel CAT is (we believe) not used anywhere yet. And we must be careful
> > when it gets to the point where we introduce usage of CAT for QoS
> > mechanisms.
> >
> > However, my intuition tells me that most systems are not even vulnerable
> > to Rowhammer in the first place. Although the only prevalence studies we
> > have suggest otherwise (they find 60-80% are affected).

So Linux is not vulnerable to this at all?  That's good to know, thanks
for following up with this.

greg k-h

Re: Nethammer and kernel network drivers

[procmem]

Greg KH:
> On Sat, Jun 02, 2018 at 05:41:09PM +0000, procmem wrote:
>> Hello. Daniel provided more details on the problematic areas of the
>> kernel and I quote what he said verbatim:
>>
>>
>>> We have only found very outdated network drivers using clflush (old
>>> windows ndis code). On ARM there are many drivers using uncached memory.
>>> However, we have so far failed to produce enough memory traffic on ARM
>>> to trigger a bit flip with Nethammer on any ARM device.
>>> It should be possible though if you can make the ARM device handle
>>>> =300MBit/s.
>>> And that's the most plausible scenario.
>>>
>>> Anyway, searching for clflush or use of uncached memory is a good idea
>>> to locate the critical spots.
>>>
>>> Intel CAT is (we believe) not used anywhere yet. And we must be careful
>>> when it gets to the point where we introduce usage of CAT for QoS
>>> mechanisms.
>>>
>>> However, my intuition tells me that most systems are not even vulnerable
>>> to Rowhammer in the first place. Although the only prevalence studies we
>>> have suggest otherwise (they find 60-80% are affected).
>
> So Linux is not vulnerable to this at all?  That's good to know, thanks
> for following up with this.
>
> greg k-h
>

I interpreted this to mean that there is a major problem with ARM
drivers but the only backstop is the current gen of hardware being
underpowered. Also it would be best to put a kernel comment about sec
implications of Intel CAT for those who want to enable/use it IMHO.

Re: Nethammer and kernel network drivers

[Greg KH]

On Sun, Jun 03, 2018 at 01:23:28PM +0000, procmem wrote:
> 
> 
> Greg KH:
> > On Sat, Jun 02, 2018 at 05:41:09PM +0000, procmem wrote:
> >> Hello. Daniel provided more details on the problematic areas of the
> >> kernel and I quote what he said verbatim:
> >>
> >>
> >>> We have only found very outdated network drivers using clflush (old
> >>> windows ndis code). On ARM there are many drivers using uncached memory.
> >>> However, we have so far failed to produce enough memory traffic on ARM
> >>> to trigger a bit flip with Nethammer on any ARM device.
> >>> It should be possible though if you can make the ARM device handle
> >>>> =300MBit/s.
> >>> And that's the most plausible scenario.
> >>>
> >>> Anyway, searching for clflush or use of uncached memory is a good idea
> >>> to locate the critical spots.
> >>>
> >>> Intel CAT is (we believe) not used anywhere yet. And we must be careful
> >>> when it gets to the point where we introduce usage of CAT for QoS
> >>> mechanisms.
> >>>
> >>> However, my intuition tells me that most systems are not even vulnerable
> >>> to Rowhammer in the first place. Although the only prevalence studies we
> >>> have suggest otherwise (they find 60-80% are affected).
> >
> > So Linux is not vulnerable to this at all?  That's good to know, thanks
> > for following up with this.
> >
> > greg k-h
> >
> 
> I interpreted this to mean that there is a major problem with ARM
> drivers but the only backstop is the current gen of hardware being
> underpowered.

Really?  There are ARM servers now that can do really fast networking,
yet those drivers do not seem to have this problem from what I can see.
Am I missing something here?

> Also it would be best to put a kernel comment about sec implications
> of Intel CAT for those who want to enable/use it IMHO.

Patches are always gladly accepted :)

thanks,

greg k-h