[Cerowrt-devel] aarch64 exploit POC

Mon Jan 8 10:49:29 EST 2018

On Sun, Jan 7, 2018 at 11:03 AM, dpreed at deepplum.com
<dpreed at 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 at gmail.com>
> Sent: Sun, Jan 7, 2018 at 11:46 am
> To: "Outback Dingo" <outbackdingo at gmail.com>
> Cc: "Outback Dingo" <outbackdingo at gmail.com>, cerowrt-devel at 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 at 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 at 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