On 05/01/2017 05:14 PM, Reg Tiangha wrote: > On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote: >> *Sigh*... Yep. We were right to be concerned (of course). And now we >> have something other than our tin foil hats to point at too: >> >> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ >> >> I want my RISC-V laptop already! >> > I don't know if it helps things, but I recently disabled the > CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel > options in my kernel branches as soon as I was made aware of their > existence. My hope is that the ME hardware can't be exploited using > those methods if they don't exist in the kernel in the first place; that > someone would have to find another way. But again, I have no idea if > that's useful or not. For what it's worth, my systems still boot and run > properly, but the newest machine I have access to is of the Sandy Bridge > era; I have no idea if newer machines actually need those options baked > into the kernel in order to run. Can anyone advise?
Local exploit can talk to the ME via PCI and SMBus. Only from dom0. Remote exploit only good against machines with vPro (check your CPU SKU at the Intel database — I explicitly bought systems without that shit) because vPro is the prerequisite technology for AMT. If your machine does not have AMT / vPro, it cannot be exploited remotely because it is not listening over network cards. A quick test: connect your machine physically to a router, start tcpdumping on the router, then power it off. Do you see DHCP requests being emitted on the port of the router where your machine is connected? If so, then you're screwed. > > https://github.com/rtiangha/qubes-linux-kernel > > Also, if anyone has any other ideas on kernel options to disable for > various security concerns (ME related or not), let me know. For the > moment, I've implemented almost all of the KSPP's recommended settings > that are applicable to a certain kernel branch, except for the ones > about loadable modules since I don't know how it affect u2mfn or any > other user-compiled kernel modules a Qubes user may want to install. I > haven't encountered any issues on my machines (or at least, any that > I've noticed), but those could use more testing as well: > > https://github.com/rtiangha/qubes-linux-kernel > KSPP is good, but it will not protect you from the attack, because the attack runs *on a different CPU within your machine, which is always on, even when the machine is off*. Yes, it's THAT bad. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0361826c-468c-74a5-bd75-0701cd022ab1%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
