271–280 of 282 posts
Earlier quoted context omitted.
Good question. Why don't phones have physical switches on GPS and microphones? In this case, the RSA sig is still better, though. Imagine that anyone sitting between the Intel plant and your local computer parts supplier could flip the switch. It's a weak argument, I admit. There should be both protections at the same time.
There are phones that do have these switches.
Asked from my N900, the only one I am aware of.
Earlier quoted context omitted.
Most are not enabled/activated or connected through the NIC.
OK (sources on that being the case?), but the issue then remains that we have no way of knowing whether it is activated or could be activated, is that correct?
[1] http://www.tomshardware.com/reviews/vpro-amt-management-kvm,... [2] http://www.howtogeek.com/56538/how-to-remotely-control-your-... [3] https://communities.intel.com/thread/21261
The lack of independent audit of this chip and firmware is legitimate concern. But as you can see, if you obtain a fresh computer with access to the BIOS/UEFI, you have control over whether this functionality is enabled. If you don't have access to your BIOS/UEFI then you're correct that you won't know if it's on.
Earlier quoted context omitted.
Though when the NSA has done things like this in the past, we've found their choices prevented implementation weaknesses that weren't found (by anyone else) for several more years.
Can you follow up on that? I've never heard that story and I'm really curious. On the narrower point, though, it's been shown that Dual_EC_DRBG is broken, and that the NSA values compromised the implementation instead of strengthening it.
Where can people go if they want a fully-libre machine and are willing to sacrifice x86?
Pi-top like laptop with your choice of pi3 or BeagleBone running Linux. The performance of a pi3 is actually decent. It's not perfect as there's a GPU BLOB in the pi3 and the BB also has some issue. It's my compromise for now, hoping the blob will be reversed/replaced eventually. Or anything that runs libreboot: https://libreboot.org/docs/hcl/ If OpenBSD runs on it that's also a good sign usually as they won't touch…
Not a ready drop-in replacement yet, but running ARM code with access to the SD card and the UART console is possible!
edit: By the way! The Pi loads all the firmware from the SD card — no reflashable memory on the board AFAIK – which would make it excellent from the "State considered harmful" perspective http://blog.invisiblethings.org/2015/12/23/state_harmful.htm...
Does this apply to Macs?
More precise question is: Is Intel CPU connected with 3G laptop modem on Mac? If YES: Data can be read/written remotely from/on your Mac (even if turned OFF - as long batteries are installed). If NO: Most probably it can not be done! (Source: http://www.intel.com/content/dam/doc/product-brief/mobile-co... )
Serious question: are AMD chips a viable alternative (from a security standpoint)? I hear their new Zen chips are coming soon.
Earlier quoted context omitted.
IPMI is equally scary: https://www.youtube.com/watch?v=GZeUntdObCA https://lwn.net/Articles/630778/ http://fish2.com/ipmi/
IPMI should always be used on a dedicated port, and on an isolated network with strict access control. Disclaimer: I run a dedicated server host.
Earlier quoted context omitted.
In fact, I still don't see much of a reason to upgrade quad core Yorkfield Q9xxx servers except for cheap SSD upgrades. An 8 year old desktop still compares favorably to a $700 laptop (except, of course, for electricity).
all intel chipsets since 2006 have had AMT/ME, including yours
Earlier quoted context omitted.
As stated in the article, some researchers have managed to unpack it, and it can now be dissembled. You can't (and hpefully won't) be able to execute your own code there. There are 2 good reasons for this: 1) As per the article, to actually prevent ring -3 malware. The implemented signature is the best way to do this. If we could run our own "libre" code there, so could the attacker. 2) I bet this firmware controlls…
IME is on the motherboard chipset, not the CPU. The i3 vs i5 is controlled by fuses set at manufacturing time on the CPU itself.
Earlier quoted context omitted.
Who does this give reason to move to ARM? End-users generally don't have a choice (good luck running AutoCAD on ARM) and OEMs either don't seem to care or list ME as one of the selling points of their systems. You could make the case that this might convince people to use AMD CPUs, but from what I hear AMD has all the same issues with worse performance to boot.
>AMD has all the same issues with worse performance to boot. AMD chips aren't just slower to boot, they're slower overall!