[Cerowrt-devel] aarch64 exploit POC

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

Post by 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
_______________________________________________
Cerowrt-devel mailing list
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Dave Taht

2018-01-07 16:10:28 UTC

Post by Outback Dingo
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.

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

Outback Dingo

2018-01-07 16:21:34 UTC

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

Post by Outback Dingo
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.

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

Dave Taht

2018-01-07 16:46:24 UTC

Post by Outback Dingo
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.

Post by Outback Dingo
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.

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

Jonathan Morton

2018-01-07 16:22:33 UTC

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

d***@deepplum.com

2018-01-07 19:03:39 UTC

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" <***@gmail.com>
Sent: Sun, Jan 7, 2018 at 11:46 am
To: "Outback Dingo" <***@gmail.com>
Cc: "Outback Dingo" <***@gmail.com>, cerowrt-***@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] aarch64 exploit POC

Post by Outback Dingo
yes but i would think you would post it to the LEDE / OpenWRT lists also

Post by Outback Dingo
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.

Post by 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
_______________________________________________
Cerowrt-devel mailing list
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-***@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Dave Taht

2018-01-08 15:49:29 UTC

Post by d***@deepplum.com
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.

Post by d***@deepplum.com
Relax, Dave.

I did:

Loading Image...

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

Post by d***@deepplum.com
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...

Post by d***@deepplum.com
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.

Post by d***@deepplum.com
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.

Post by d***@deepplum.com
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."

"
"

Post by d***@deepplum.com
-----Original
Sent: Sun, Jan 7, 2018 at 11:46 am
Subject: Re: [Cerowrt-devel] aarch64 exploit POC

Post by Outback Dingo
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.

Post by Outback Dingo
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.

Post by 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
_______________________________________________
Cerowrt-devel mailing list
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
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

Jonathan Morton

2018-01-08 15:57:13 UTC

Post by Dave Taht
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

Dave Taht

2018-01-09 18:19:56 UTC