Re: [tor-relays] Exploiting firmware

[grarpamp]

On Fri, Dec 9, 2016 at 4:53 AM, Roman Mamedov  wrote:
> option available today, and you don't have to go back to Pentium 200 to avoid

Using such a relic as a scrub firewall might protect you from magic packets
launched by your adversaries towards one of those listening transistors
in your shiny new Skylake you'd otherwise have directly connected
to the net.

> It's not like they are auto-downloaded from
> the Internet directly by your CPU

Billions of transistors, billions of packets, billions of bits, billions
of broadcast internet 'scans', who's watching...

> Sure there still can be subtle bugs and backdoors, but those will need to be
> subtle, well hidden, likely more difficult to exploit, and likely having much
> less of a "feature set" when exploited. Not to mention the devastating
> reputation effect on the vendor if uncovered.

There may not be any evil silicon code, perhaps just an agnostic monitor
vm, external pushed codeload then exec trigger, they'll call it an undoc
engineering feature, AMT precursor, not meant for public use, tie it to
some other legit thing, whatever, no problem.

>> #OpenFabs printing #OpenDesigns
> As far as I know there's no fully free and open chip right now which provides

That's because no one's giving any significant their
free time / money / research to figure out how to do it,
let alone develop talk about it as a serious global concept
and goal and get it done. Always 'fab and open too costly'
end convo. Bullshit, not costly per interested capita.

What saying is in environment of secret HW no point in betting
hardware trust right now... for tor relays or anything else.
Lot of HW is proving to be so buggy, if not evil, that it's exploited
and exec'd to become evil.
So buy whatever's interesting, put opensource OS on it and
pray neither of them are fucked.
And hedge your future bet by figuring out #OpenFabs
hardware just like you figured out OpenSource software.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Roman Mamedov]

On Fri, 9 Dec 2016 04:17:49 -0500
grarpamp  wrote:

> >> Intel ME/AMT concerns me too
> 
> > AMD Family 15h itself is safe.
> 
> No one has any proof of that for any modern cpu from any
> maker, featureset irrelavant.

Sure, to clarify what's meant here is "it does not implement the actual
backdoor-like feature (separate CPU-within-CPU running proprietary code and
having super-user rights over the rest of the system and full access to
everything) in the form of 'Platform Security Processor' or 'Intel Management
Engine'". Point is if you wanted a desktop CPU without such feature, there's an
option available today, and you don't have to go back to Pentium 200 to avoid
it.

> They all accept microcode updates, which btw are all encrypted closed binary
> blobs.

Those are applied by your BIOS or your OS.
https://packages.debian.org/jessie/amd64-microcode
https://packages.debian.org/jessie/intel-microcode
You don't HAVE to install those. It's not like they are auto-downloaded from
the Internet directly by your CPU (at least if your CPU doesn't have those
AMT/PSP things :).

> And the chips themselves are fully closed source containing billions
> of transistors. You simply have no idea what's in there and no way to
> economically and publicly test or negotiate to find out and openly publish
> it all.

Sure there still can be subtle bugs and backdoors, but those will need to be
subtle, well hidden, likely more difficult to exploit, and likely having much
less of a "feature set" when exploited. Not to mention the devastating
reputation effect on the vendor if uncovered.

> Billions of secret transistors... billions.
> Not good, and not necessary.
> 
> #OpenFabs printing #OpenDesigns

As far as I know there's no fully free and open chip right now which provides
performance expected of a modern desktop or server. There is the TALOS
project[1], but for most people it'll be a non-starter due to price. And even
there from what I see you don't get it made on an open fab. So we need to
choose the least evil option from what we have available, and to me the AMD FX
appears to be a win in that regard.

[1]
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Rana]

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
grarpamp
Sent: Friday, December 09, 2016 11:18 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Exploiting firmware

>>> Intel ME/AMT concerns me too

>> AMD Family 15h itself is safe.

>No one has any proof of that for any modern cpu from any maker, featureset 
>irrelavant. They all accept microcode updates, which btw are all encrypted 
>closed binary blobs. And the chips themselves are fully closed >source 
>containing billions of transistors. You simply have no idea what's in there 
>and no way to economically and publicly test or negotiate to find out and 
>openly publish it all.

>Talking about known shit like advertised ME/AMT + LM-NIC's corp management 
>platform is fine, you might be able to mitigate.
>But it's the unknown that will kill you.

>Billions of secret transistors... billions.
>Not good, and not necessary.

Agreed. Effort spent on guessing which closed source processor is safe is a 
wasted effort, and any conclusion that a certain processor is "safe" is a 
dangerous delusion resulting in flawed threat models. Just modify your threat 
model with the compromised processor assumption, calculate the risk of your 
specific computer being targeted, mitigate to the extent possible and get on 
with your life.

Rana

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[grarpamp]

>> Intel ME/AMT concerns me too

> AMD Family 15h itself is safe.

No one has any proof of that for any modern cpu from any
maker, featureset irrelavant. They all accept microcode updates,
which btw are all encrypted closed binary blobs. And the
chips themselves are fully closed source containing billions
of transistors. You simply have no idea what's in there
and no way to economically and publicly test or negotiate
to find out and openly publish it all.

Talking about known shit like advertised ME/AMT + LM-NIC's
corp management platform is fine, you might be able to mitigate.
But it's the unknown that will kill you.

Billions of secret transistors... billions.
Not good, and not necessary.

#OpenFabs printing #OpenDesigns
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Roman Mamedov]

On Wed, 7 Dec 2016 22:50:39 +
Alex Haydock  wrote:

> Intel ME/AMT concerns me too, especially how unavoidable it seems to be
> on modern CPUs (AMD is no escape, as they have an equivalent in the form
> of their "Platform Security Processor").

On AMD that's been implemented only after "Family 15h"
https://libreboot.org/faq/#amdbastards
https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures

Family 15h itself is safe.

It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM:
https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29

So don't handwave-away AMD with "they are doing that too", today you CAN have
a non-backdoored modern high-performance CPU -- from AMD.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Tim Kuijsten]

Op 07-12-16 om 23:50 schreef Alex Haydock:

AMD is no escape, as they have an equivalent in the form
of their "Platform Security Processor"


I believe[1] the Athlon 5370 that AMD released this year is without PSP. 
Suits small form factors and has good performance for the mere 25 Watt 
that it uses.


[1] https://notabug.org/vimuser/libreboot-website/issues/10
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Alex Haydock]

On 07/12/16 23:15, diffusae wrote
> I am totally agree with you.
>
> One alternative would be to use coreboot on your machine. If you are
> good, than you will put your kernel into the flash chip and make it
> write protected.
As far as I know, Coreboot is merely an open source BIOS replacement and
doesn't act to disable the management engine as many Intel chips simply
won't boot without the ME firmware present and correct.

Libreboot might be the project you're thinking of, but it only works on
the small subset of (sadly usually quite old) CPUs that will actually
boot without Intel's firmware being present.

They are both fantastic projects, and I do have some Libreboot machines
at home, but the main concern I was raising was that: firstly, unless
you are colocating your own hardware or running your relay at home,
flashing a new BIOS to your relay's hardware is out of the question as
the hardware is under the control of your service provider.

The other thing I was noting was that the fact the hardware is under
control of your service provider is probably more of a threat than just
the ME would be. The service provider obviously needs access to the
machine, but they often expose quite low-level access either through web
consoles of unknown security, or to helpdesk techs working at the provider.

As a side note, there is one VPS provider I know of that are currently
in the preparation stages before launch, and who are intending to run
their entire infrastructure on Libreboot machines:
https://www.vikings.net/index.html

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Rana]

As long as CPU hardware is closed source, perfect privacy does not exist, full 
stop. Conspiracy theories are futile, the probability of microcode backdoor is 
1. So there is no need to "worry" about hardware blobs. There is NO way that 
processors made by US chip manufacturers do NOT contain a backdoor. The same 
goes for Raspberry Pi which is based on a Broadcom chip. 

Privacy is a therefore probabilistic entity.  Instead of worrying about 
hardware blobs, you should is try to estimate  the cost of intrusion, 
collection and analysis, divided by the probability of yourself being a target. 
This yields a weighted cost of spying on you. If the result is high enough, no 
problem, as the adversary's budget s always limited. Otherwise you are toast, 
Tor or no Tor, VM or no VM. What Tor hopefully does is raise the cost and thus 
minimize the probability of the Tor user being targeted, collected and 
analyzed, due to purely budgetary reasons.

I am happily using hardware based on Intel chips. If I were an ISIS ringleader, 
I wouldn't. Allahu Akbar but my ass is valuable, too.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[diffusae]

On 07.12.2016 23:50, Alex Haydock wrote:
> On 07/12/16 21:45, diffusae wrote:
>> Hmm, interesting subject ...
>>
>> On 07.12.2016 21:35, Gumby wrote:
>>>   Subject seems to have changed a bit, so not hijacking it.
>>> When thinking of any exploitation of firmware - should there be concerns
>>> of Intel's Management Engine in the CPU of any relays
>>>  running on "home hardware" in any common unused pc or laptop?
>>> Should that be a concern on ANY newer Intel hardware?
>>>
>>> Gumby
>> What do you think about Intel AMT, it's a part of the most modern PCs?
>>
> Intel ME/AMT concerns me too, especially how unavoidable it seems to be
> on modern CPUs (AMD is no escape, as they have an equivalent in the form
> of their "Platform Security Processor").
> 
> Though I this probably concerns me less than the fact that only the
> fastest relays are going to be deployed on colocated and fully
> owner-controlled hardware or under their own ASNs.
> 
> The rest are probably going to be VPS nodes or at least connected to
> some out-of-band network management interface for quick deployment and
> monitoring at the ISP-level. This can provide low-level access in a
> similar way to ME/AMT. I've seen many providers allowing access to
> management TTYs, or even raw disk management tools via HTTP web interfaces.
> 
> Abusing the ME/AMT would require some sort of co-operation on Intel's
> part, or stolen signing keys, but imagine if you could get access to
> some sort of administration panel for OVH/DigitalOcean etc. Co-opting a
> large number of relays/exits through that process might be a lot easier,
> so if I was going to worry about out-of-band management interfaces, I'd
> probably worry about those first.

I am totally agree with you.

One alternative would be to use coreboot on your machine. If you are
good, than you will put your kernel into the flash chip and make it
write protected.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Alex Haydock]

On 07/12/16 21:45, diffusae wrote:
> Hmm, interesting subject ...
>
> On 07.12.2016 21:35, Gumby wrote:
>>   Subject seems to have changed a bit, so not hijacking it.
>> When thinking of any exploitation of firmware - should there be concerns
>> of Intel's Management Engine in the CPU of any relays
>>  running on "home hardware" in any common unused pc or laptop?
>> Should that be a concern on ANY newer Intel hardware?
>>
>> Gumby
> What do you think about Intel AMT, it's a part of the most modern PCs?
>
Intel ME/AMT concerns me too, especially how unavoidable it seems to be
on modern CPUs (AMD is no escape, as they have an equivalent in the form
of their "Platform Security Processor").

Though I this probably concerns me less than the fact that only the
fastest relays are going to be deployed on colocated and fully
owner-controlled hardware or under their own ASNs.

The rest are probably going to be VPS nodes or at least connected to
some out-of-band network management interface for quick deployment and
monitoring at the ISP-level. This can provide low-level access in a
similar way to ME/AMT. I've seen many providers allowing access to
management TTYs, or even raw disk management tools via HTTP web interfaces.

Abusing the ME/AMT would require some sort of co-operation on Intel's
part, or stolen signing keys, but imagine if you could get access to
some sort of administration panel for OVH/DigitalOcean etc. Co-opting a
large number of relays/exits through that process might be a lot easier,
so if I was going to worry about out-of-band management interfaces, I'd
probably worry about those first.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[diffusae]

Which "other parts" do you mean? The GPU blob or Raspbian?
You don't need to use the stock distribution.

On 07.12.2016 23:10, Duncan Guthrie wrote:
> What I was originally getting at was that the parts of the Raspberry Pi
> that are completely proprietary - while there is a free software
> implementation of the GPU blob, most people don't use that, as they are
> on stock Rasbian, which includes all the nasty "other parts" - are a
> great possibility for hijacking, perhaps through malicious code running
> on the GPU, which controls the CPU in several ways. The problem with
> this isn't that this is unique (Intel computers having so much more
> attack surface) but that a flaw in lots of these small computers that
> power a portion of the network means that an exploit in them due to lack
> of diversity would be much more serious.

Better a lots of these small computers than none ...

> The management engine blob is also very serious. One possible mitigation
> might be to run the relays in VMs with good isolation, e.g. Xen on
> recent hardware which has good IOMMU. This makes it much harder to
> exploit the actual software that runs on the ME since the VMs would, in
> theory, have no access to hardware.
> 
> It should be of concern on any hardware that is being used for related
> purposes, I think. However, whether it works out in practice as a
> backdoor that is worth exploiting vs other methods is debatable.
> 
> Regardless, diversity is good.

That's true!

Regards,

> On 07/12/16 20:35, Gumby wrote:
>>   Subject seems to have changed a bit, so not hijacking it.
>> When thinking of any exploitation of firmware - should there be
>> concerns of Intel's Management Engine in the CPU of any relays
>>  running on "home hardware" in any common unused pc or laptop?
>> Should that be a concern on ANY newer Intel hardware?
>>
>> Gumby

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[Duncan Guthrie]

What I was originally getting at was that the parts of the Raspberry Pi 
that are completely proprietary - while there is a free software 
implementation of the GPU blob, most people don't use that, as they are 
on stock Rasbian, which includes all the nasty "other parts" - are a 
great possibility for hijacking, perhaps through malicious code running 
on the GPU, which controls the CPU in several ways. The problem with 
this isn't that this is unique (Intel computers having so much more 
attack surface) but that a flaw in lots of these small computers that 
power a portion of the network means that an exploit in them due to lack 
of diversity would be much more serious.


The management engine blob is also very serious. One possible mitigation 
might be to run the relays in VMs with good isolation, e.g. Xen on 
recent hardware which has good IOMMU. This makes it much harder to 
exploit the actual software that runs on the ME since the VMs would, in 
theory, have no access to hardware.


It should be of concern on any hardware that is being used for related 
purposes, I think. However, whether it works out in practice as a 
backdoor that is worth exploiting vs other methods is debatable.


Regardless, diversity is good.

On 07/12/16 20:35, Gumby wrote:

  Subject seems to have changed a bit, so not hijacking it.
When thinking of any exploitation of firmware - should there be 
concerns of Intel's Management Engine in the CPU of any relays

 running on "home hardware" in any common unused pc or laptop?
Should that be a concern on ANY newer Intel hardware?

Gumby

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware

[diffusae]

Hmm, interesting subject ...

On 07.12.2016 21:35, Gumby wrote:
>   Subject seems to have changed a bit, so not hijacking it.
> When thinking of any exploitation of firmware - should there be concerns
> of Intel's Management Engine in the CPU of any relays
>  running on "home hardware" in any common unused pc or laptop?
> Should that be a concern on ANY newer Intel hardware?
> 
> Gumby

What do you think about Intel AMT, it's a part of the most modern PCs?


> On 12/07/2016 02:35 PM, diffusae wrote:
>>
>> On 07.12.2016 01:36, Duncan Guthrie wrote:
>>> if some flaw was exploited in the various nasty proprietary bits that
>>> make up the Pi, much of the network might be compromised - due to large
>>> similarities across the different models, this would affect considerable
>>> numbers of devices. So using many different computer models with a large
>>> variety of operating systems is ideal for the network as a whole.
>>
>> Yes, there proprietary parts in the firmware, but also this firmware is
>> free and open source. And there are a lot of people who keep care on it.
>>
>> It's especially very easy to rewrite the boot partition.
>>
>> Regards,
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exploiting firmware (was: Unwarranted discrimination of relays with dynamic IP)

[Gumby]

  Subject seems to have changed a bit, so not hijacking it.
When thinking of any exploitation of firmware - should there be concerns 
of Intel's Management Engine in the CPU of any relays

 running on "home hardware" in any common unused pc or laptop?
Should that be a concern on ANY newer Intel hardware?

Gumby

On 12/07/2016 02:35 PM, diffusae wrote:


On 07.12.2016 01:36, Duncan Guthrie wrote:

if some flaw was exploited in the various nasty proprietary bits that
make up the Pi, much of the network might be compromised - due to large
similarities across the different models, this would affect considerable
numbers of devices. So using many different computer models with a large
variety of operating systems is ideal for the network as a whole.


Yes, there proprietary parts in the firmware, but also this firmware is
free and open source. And there are a lot of people who keep care on it.

It's especially very easy to rewrite the boot partition.

Regards,
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays