Re: [Cerowrt-devel] aarch64 exploit POC

Re: [Cerowrt-devel] aarch64 exploit POC

[dpreed]

Even the Intel meltdown cannot reach between VMs that use hardware virtual memory.

Relax, Dave.

The cloud now mostly uses hardware VMs. AWS old Xen instances, and containers are subject to bad meltdown  cloud attacks across containers.

Sad about ARM, but ARM servers are pretty rare at this time.

Attacking a PC to expose kernel data via Meltdown is fixed in Linux now. And a victim domain has to execute attacker chosen code and data to be Spectre vulnerable. So avoid running things as root or letting viruses run in protected domains.

It helps to try to figure out exactly what exploits can do. Broad generalities are insufficient.

It really bugs me that compiler writers are thinking that they are the solution.

It's a lot easier to fix Spectre in microcode, and Meltdown in the OS paging maps.
-----Original
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Sun, Jan 7, 2018 at 11:46 am
To: "Outback Dingo" <outbackdingo@gmail.com>
Cc: "Outback Dingo" <outbackdingo@gmail.com>, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] aarch64 exploit POC

On Sun, Jan 7, 2018 at 8:21 AM, Outback Dingo  wrote:
> yes but i would think you would post it to the LEDE / OpenWRT lists also

I'm not reading that email account of mine at the moment, and I'd hope
folk over there are already all over this.

I only logged in long enough to send out a happy new year to everyone.
I was prepping to spend a few days
finishing up the netem patches and maybe trying to submit cake again
before the submission window closed, and then I made the mistake of
inferring what the KPTI patches actually meant, and then this all
happened.

I'd like my vacation back, please.

> On Sun, Jan 7, 2018 at 11:10 AM, Dave Taht  wrote:
>> On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo  wrote:
>>> OH hell...  notifying all my "cohorts"...... thanks for the heads up
>>
>> Then go drinking.
>>
>> Aside from x86 arches (anyone have word on the x86 chip in the
>> pcengines?), it looks like the mips chips simply were not advanced
>> enough to have this level of speculation and out of order behavior.
>>
>> The turris omnia and a few other high end arm chips in this part of
>> the embedded router space are also vulnerable (I'm hoping that the
>> lede folk can compile a list) - but - if you can execute *any*
>> malicious code as root on embedded boxes - which is usually the case -
>> you've already won.
>>
>> The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
>> being assembled on wikipedia, reddit, and elsewhere.
>>
>> My own terror is primarily for stuff in the cloud. There IS a vendor
>> renting time on bare metal in-expensively, which I'm considering.
>>
>> (example: https://www.packet.net/bare-metal/servers/type-2a/)
>>
>> Ironically all the bufferbloat.net services used to run on bare metal,
>> until the competing lower costs of the cloud knocked isc.org out of
>> the business.
>>
>>
>>
>>>
>>> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht  wrote:
>>>> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>>>>
>>>> There comes a time after coping with security holes nonstop for 5 days
>>>> straight, when it is best to log off the internet entirely, stop
>>>> thinking, drink lots of rum, and go surfing.
>>>>
>>>> Today is that day, for me.
>>>>
>>>> --
>>>>
>>>> Dave Täht
>>>> CEO, TekLibre, LLC
>>>> http://www.teklibre.com
>>>> Tel: 1-669-226-2619
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] aarch64 exploit POC

[Dave Taht]

On Sun, Jan 7, 2018 at 11:03 AM, dpreed@deepplum.com
<dpreed@deepplum.com> wrote:
> Even the Intel meltdown cannot reach between VMs that use hardware virtual memory.

mmm... let me quote a something in a sec. My heads spins when vms are
inside of vms.

> Relax, Dave.

I did:

https://scontent.fsjo2-1.fna.fbcdn.net/v/t34.0-12/26793638_138885946783309_1475552364_n.jpg?oh=692de1a97ec9846dff12fe4a9656d8fc&oe=5A54B3ED

(not sure if that requires perms to see) I feel much better today.


>
> The cloud now mostly uses hardware VMs. AWS old Xen instances, and containers are subject to bad meltdown  cloud attacks across containers.

I am still waiting for official word and reboots from linode as to
what they will be doing. I think we're still on a mix of xen and kvm
substrates and have no insight into the underlying hardware either.

Can I get a discount for running stuff I don't care about on obsolete
hardware? The 5 dollar insecurity special? For test builds, having a
16 way xeon available for cheap would be helpful. Oh, wait, snapon
looks like that already...

>
> Sad about ARM, but ARM servers are pretty rare at this time.
>
> Attacking a PC to expose kernel data via Meltdown is fixed in Linux now.

For a definition of now that includes having a kernel that supports it.

>And a victim domain has to execute attacker chosen code and data to be Spectre vulnerable. So avoid running things as root or letting viruses run in protected domains.
>
> It helps to try to figure out exactly what exploits can do. Broad generalities are insufficient.
>
> It really bugs me that compiler writers are thinking that they are the solution.

Well, inside a protected domain (like the kernel) where you can
control compilation options completely, does help.

> It's a lot easier to fix Spectre in microcode, and Meltdown in the OS paging maps.

Concur, but i am worried about the interrupt code still living in KPTI
userspace.

One of the more insightful messages on lkml (cc'd netdev) is this one from:

- https://patchwork.kernel.org/patch/10147427/

"Reptolines alone are leaving a whole set of stuff unfixed: register
hygiene still missing, bios/firmware calls still require ibrs, all asm
has to be audited by hand as there's no sure asm scanner I know of
(grep can go somewhere though) and the gcc dependency isn't very
flexible to begin with, and they don't help with lfence/mfence across
bound checks, they still require IBPB and stuff_RSB() to avoid
guest/user mode against guest/user spectre variant#2 attacks."

"
"



> -----Original
> From: "Dave Taht" <dave.taht@gmail.com>
> Sent: Sun, Jan 7, 2018 at 11:46 am
> To: "Outback Dingo" <outbackdingo@gmail.com>
> Cc: "Outback Dingo" <outbackdingo@gmail.com>, cerowrt-devel@lists.bufferbloat.net
> Subject: Re: [Cerowrt-devel] aarch64 exploit POC
>
> On Sun, Jan 7, 2018 at 8:21 AM, Outback Dingo  wrote:
>> yes but i would think you would post it to the LEDE / OpenWRT lists also
>
> I'm not reading that email account of mine at the moment, and I'd hope
> folk over there are already all over this.
>
> I only logged in long enough to send out a happy new year to everyone.
> I was prepping to spend a few days
> finishing up the netem patches and maybe trying to submit cake again
> before the submission window closed, and then I made the mistake of
> inferring what the KPTI patches actually meant, and then this all
> happened.
>
> I'd like my vacation back, please.
>
>> On Sun, Jan 7, 2018 at 11:10 AM, Dave Taht  wrote:
>>> On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo  wrote:
>>>> OH hell...  notifying all my "cohorts"...... thanks for the heads up
>>>
>>> Then go drinking.
>>>
>>> Aside from x86 arches (anyone have word on the x86 chip in the
>>> pcengines?), it looks like the mips chips simply were not advanced
>>> enough to have this level of speculation and out of order behavior.
>>>
>>> The turris omnia and a few other high end arm chips in this part of
>>> the embedded router space are also vulnerable (I'm hoping that the
>>> lede folk can compile a list) - but - if you can execute *any*
>>> malicious code as root on embedded boxes - which is usually the case -
>>> you've already won.
>>>
>>> The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
>>> being assembled on wikipedia, reddit, and elsewhere.
>>>
>>> My own terror is primarily for stuff in the cloud. There IS a vendor
>>> renting time on bare metal in-expensively, which I'm considering.
>>>
>>> (example: https://www.packet.net/bare-metal/servers/type-2a/)
>>>
>>> Ironically all the bufferbloat.net services used to run on bare metal,
>>> until the competing lower costs of the cloud knocked isc.org out of
>>> the business.
>>>
>>>
>>>
>>>>
>>>> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht  wrote:
>>>>> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>>>>>
>>>>> There comes a time after coping with security holes nonstop for 5 days
>>>>> straight, when it is best to log off the internet entirely, stop
>>>>> thinking, drink lots of rum, and go surfing.
>>>>>
>>>>> Today is that day, for me.
>>>>>
>>>>> --
>>>>>
>>>>> Dave Täht
>>>>> CEO, TekLibre, LLC
>>>>> http://www.teklibre.com
>>>>> Tel: 1-669-226-2619
>>>>> _______________________________________________
>>>>> Cerowrt-devel mailing list
>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>>
>>> --
>>>
>>> Dave Täht
>>> CEO, TekLibre, LLC
>>> http://www.teklibre.com
>>> Tel: 1-669-226-2619
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] aarch64 exploit POC

[Jonathan Morton]

> On 8 Jan, 2018, at 5:49 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> Can I get a discount for running stuff I don't care about on obsolete
> hardware? The 5 dollar insecurity special?

You can pass command-line arguments to the kernel to turn off the retpoline and kpti patches.  Obviously, don't do that on a virtualised box, but you can do it on hardware you own and operate yourself with no untrusted code.

 - Jonathan Morton

Re: [Cerowrt-devel] aarch64 exploit POC

[Dave Taht]

On Mon, Jan 8, 2018 at 7:57 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>
>> On 8 Jan, 2018, at 5:49 pm, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Can I get a discount for running stuff I don't care about on obsolete
>> hardware? The 5 dollar insecurity special?
>
> You can pass command-line arguments to the kernel to turn off the retpoline and kpti patches.  Obviously, don't do that on a virtualised box, but you can do it on hardware you own and operate yourself with no untrusted code.

Not my point. it might be possible to buy time on hardware known to be
more secure, or (as I suggested)
get a discount for time on hardware known to insecure.

In other news:

https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00436.html

And I'm still waiting on a plan from linode.

https://blog.linode.com/

>  - Jonathan Morton
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

[Cerowrt-devel] aarch64 exploit POC

[Dave Taht]

https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd

There comes a time after coping with security holes nonstop for 5 days
straight, when it is best to log off the internet entirely, stop
thinking, drink lots of rum, and go surfing.

Today is that day, for me.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] aarch64 exploit POC

[Outback Dingo]

OH hell...  notifying all my "cohorts"...... thanks for the heads up

On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht <dave.taht@gmail.com> wrote:
> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>
> There comes a time after coping with security holes nonstop for 5 days
> straight, when it is best to log off the internet entirely, stop
> thinking, drink lots of rum, and go surfing.
>
> Today is that day, for me.
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] aarch64 exploit POC

[Dave Taht]

On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo <outbackdingo@gmail.com> wrote:
> OH hell...  notifying all my "cohorts"...... thanks for the heads up

Then go drinking.

Aside from x86 arches (anyone have word on the x86 chip in the
pcengines?), it looks like the mips chips simply were not advanced
enough to have this level of speculation and out of order behavior.

The turris omnia and a few other high end arm chips in this part of
the embedded router space are also vulnerable (I'm hoping that the
lede folk can compile a list) - but - if you can execute *any*
malicious code as root on embedded boxes - which is usually the case -
you've already won.

The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
being assembled on wikipedia, reddit, and elsewhere.

My own terror is primarily for stuff in the cloud. There IS a vendor
renting time on bare metal in-expensively, which I'm considering.

(example: https://www.packet.net/bare-metal/servers/type-2a/)

Ironically all the bufferbloat.net services used to run on bare metal,
until the competing lower costs of the cloud knocked isc.org out of
the business.



>
> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>>
>> There comes a time after coping with security holes nonstop for 5 days
>> straight, when it is best to log off the internet entirely, stop
>> thinking, drink lots of rum, and go surfing.
>>
>> Today is that day, for me.
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] aarch64 exploit POC

[Outback Dingo]

yes but i would think you would post it to the LEDE / OpenWRT lists also

On Sun, Jan 7, 2018 at 11:10 AM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo <outbackdingo@gmail.com> wrote:
>> OH hell...  notifying all my "cohorts"...... thanks for the heads up
>
> Then go drinking.
>
> Aside from x86 arches (anyone have word on the x86 chip in the
> pcengines?), it looks like the mips chips simply were not advanced
> enough to have this level of speculation and out of order behavior.
>
> The turris omnia and a few other high end arm chips in this part of
> the embedded router space are also vulnerable (I'm hoping that the
> lede folk can compile a list) - but - if you can execute *any*
> malicious code as root on embedded boxes - which is usually the case -
> you've already won.
>
> The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
> being assembled on wikipedia, reddit, and elsewhere.
>
> My own terror is primarily for stuff in the cloud. There IS a vendor
> renting time on bare metal in-expensively, which I'm considering.
>
> (example: https://www.packet.net/bare-metal/servers/type-2a/)
>
> Ironically all the bufferbloat.net services used to run on bare metal,
> until the competing lower costs of the cloud knocked isc.org out of
> the business.
>
>
>
>>
>> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>>>
>>> There comes a time after coping with security holes nonstop for 5 days
>>> straight, when it is best to log off the internet entirely, stop
>>> thinking, drink lots of rum, and go surfing.
>>>
>>> Today is that day, for me.
>>>
>>> --
>>>
>>> Dave Täht
>>> CEO, TekLibre, LLC
>>> http://www.teklibre.com
>>> Tel: 1-669-226-2619
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619

Re: [Cerowrt-devel] aarch64 exploit POC

[Dave Taht]

On Sun, Jan 7, 2018 at 8:21 AM, Outback Dingo <outbackdingo@gmail.com> wrote:
> yes but i would think you would post it to the LEDE / OpenWRT lists also

I'm not reading that email account of mine at the moment, and I'd hope
folk over there are already all over this.

I only logged in long enough to send out a happy new year to everyone.
I was prepping to spend a few days
finishing up the netem patches and maybe trying to submit cake again
before the submission window closed, and then I made the mistake of
inferring what the KPTI patches actually meant, and then this all
happened.

I'd like my vacation back, please.

> On Sun, Jan 7, 2018 at 11:10 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> On Sun, Jan 7, 2018 at 7:47 AM, Outback Dingo <outbackdingo@gmail.com> wrote:
>>> OH hell...  notifying all my "cohorts"...... thanks for the heads up
>>
>> Then go drinking.
>>
>> Aside from x86 arches (anyone have word on the x86 chip in the
>> pcengines?), it looks like the mips chips simply were not advanced
>> enough to have this level of speculation and out of order behavior.
>>
>> The turris omnia and a few other high end arm chips in this part of
>> the embedded router space are also vulnerable (I'm hoping that the
>> lede folk can compile a list) - but - if you can execute *any*
>> malicious code as root on embedded boxes - which is usually the case -
>> you've already won.
>>
>> The Mill, Itanium, MIPs, and older arms are ok. There are huge lists
>> being assembled on wikipedia, reddit, and elsewhere.
>>
>> My own terror is primarily for stuff in the cloud. There IS a vendor
>> renting time on bare metal in-expensively, which I'm considering.
>>
>> (example: https://www.packet.net/bare-metal/servers/type-2a/)
>>
>> Ironically all the bufferbloat.net services used to run on bare metal,
>> until the competing lower costs of the cloud knocked isc.org out of
>> the business.
>>
>>
>>
>>>
>>> On Sun, Jan 7, 2018 at 10:15 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
>>>>
>>>> There comes a time after coping with security holes nonstop for 5 days
>>>> straight, when it is best to log off the internet entirely, stop
>>>> thinking, drink lots of rum, and go surfing.
>>>>
>>>> Today is that day, for me.
>>>>
>>>> --
>>>>
>>>> Dave Täht
>>>> CEO, TekLibre, LLC
>>>> http://www.teklibre.com
>>>> Tel: 1-669-226-2619
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

Re: [Cerowrt-devel] aarch64 exploit POC

[Jonathan Morton]

> On 7 Jan, 2018, at 5:15 pm, Dave Taht <dave.taht@gmail.com> wrote:
> 
> https://plus.google.com/+KristianK%C3%B6hntopp/posts/6CduVXSy6Kd
> 
> There comes a time after coping with security holes nonstop for 5 days
> straight, when it is best to log off the internet entirely, stop
> thinking, drink lots of rum, and go surfing.

This is for Variant 3a, which is really not such a big deal, and only affects a few of ARM's cores.  Yes, you can read out privileged MSRs that way, but they generally don't contain directly-useful information.  ARM claims that the few CPUs where that *isn't* true are already immune to Variant 3a.

Only one of ARM's cores is vulnerable to Variant 3, ie. Meltdown, which can read privileged memory.  The same mitigation applies there as for x86 CPUs - unmap privileged memory completely, instead of just marking it inaccessible.

Variant 2 is a wider problem, for which ARM has produced mitigation strategies and patches, and Variant 1 is a near-universal problem for out-of-order CPUs running untrusted code.

Also, I think ARM is in a good position to remove or reduce exposure to these attacks in future core designs, including new revisions of existing cores.

 - Jonathan Morton