Re: [tor-relays] Exploiting firmware
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
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
-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
>> 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
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
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
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
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
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
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
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
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
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)
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