Thanks everyone for the responses.
The thing that bothers me, is if you take a possibly extreme interpretation of "There is also a chance of attacks performed on Intel systems without Intel AMT support." from the people who reported the vuln @ https://www.embedi.com/news/mythbusters-cve-2017-5689 it sounds like it could be every board since 2010.
I understand that Intel have a vested interest in this being (or at least appearing to be) as small as possible, whereas the reporter's interest is for it to be as big as possible. I suspect the truth might end up to be somewhere in between, e.g. that there is technically something which may apply to all boards under certain circumstances, but may not be considered realistically practicable on a large/significant scale.
Still, I think this does make a case for using ME cleaning of some description, regardless of where this ends up, but presumably that might not be entirely successful unless flashing externally? Is there some form of ME cleaning available for all the chipsets up to Kabylake?
John.
On 03/05/17 05:37, Zoran Stojsavljevic wrote:
I also read in details some of the emails from the previous threads. I downloaded SCSDiscovery tool: https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-U... and ran it on my notebook.
I got as response a bunch of nonsense info (basically, it failed everywhere) :
C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log 2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: HandleOutPut: Starting log 2017-05-03 06:15:19 2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: -SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the System information... 2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System Discovery: System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836). 2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: ***********Exit with code 32 - Intel(R) AMT operation completed with warnings: Details: Success. System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836).
C:\Program Files\Intel_SCS_Discovery_11.1.0.75>
Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME series 9).
Zoran
On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury <vbendeb@chromium.org mailto:vbendeb@chromium.org> wrote:
I wonder if anyone ever completely trusted AMT - maybe some naive excessive cool-aid drinkers :) -vb On Tue, May 2, 2017 at 11:27 AM, ron minnich <rminnich@gmail.com <mailto:rminnich@gmail.com>> wrote: I wonder if anyone is going to completely trust AMT after this problem. It goes back almost 10 years. So for all those users who had it on for almost 10 years, the question becomes, how much did we lose and when did we lose it? The answer? We'll never know. Are we still owned? We don't know. Can we actually trust any reflash procedure, if the ME is owned while we try to reflash? Well, I hope so, but how can we know? It's a worrisome situation. ron On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot <coreboot@coreboot.org <mailto:coreboot@coreboot.org>> wrote: Semi-Accurate only claims accuracy according to what's on the box. The official documentation of the issue can be found at https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 <https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075> It looks like a software bug in the AMT firmware. Therefore: - No AMT (eg on non-business consumer devices) -> no (bug | exploit). - Present but disabled AMT (eg. on business devices without AMT enrollment) -> no (bug | exploit). (although there's apparently a way to enable AMT unsupervised under some circumstances with some level of local access. or something.) Patrick 2017-05-02 19:31 GMT+02:00 John Lewis <jlewis@johnlewis.ie <mailto:jlewis@johnlewis.ie>>: > https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ <https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/> > > The article says "all" Intel boards since 2008 are locally vulnerable > (ME exploit), but the Intel advisory (linked within) says consumer > devices are okay. > > What the article says about even low end devices still having the > features albeit turned "off" rings true to me, based on stuff I've read > here and elsewhere. What's your take (bearing in mind the technical > details aren't available, yet)? > > > -- > coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
I think I've answered my own questions by checking out the menuconfig options, it looks to me as though up to and including Skylake is possible, and flashing internally *should* be okay?
John.
On 03/05/17 10:09, John Lewis wrote:
Thanks everyone for the responses.
The thing that bothers me, is if you take a possibly extreme interpretation of "There is also a chance of attacks performed on Intel systems without Intel AMT support." from the people who reported the vuln @ https://www.embedi.com/news/mythbusters-cve-2017-5689 it sounds like it could be every board since 2010.
I understand that Intel have a vested interest in this being (or at least appearing to be) as small as possible, whereas the reporter's interest is for it to be as big as possible. I suspect the truth might end up to be somewhere in between, e.g. that there is technically something which may apply to all boards under certain circumstances, but may not be considered realistically practicable on a large/significant scale.
Still, I think this does make a case for using ME cleaning of some description, regardless of where this ends up, but presumably that might not be entirely successful unless flashing externally? Is there some form of ME cleaning available for all the chipsets up to Kabylake?
John.
On 03/05/17 05:37, Zoran Stojsavljevic wrote:
I also read in details some of the emails from the previous threads. I downloaded SCSDiscovery tool: https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-U... and ran it on my notebook.
I got as response a bunch of nonsense info (basically, it failed everywhere) :
C:\Program Files\Intel_SCS_Discovery_11.1.0.75>type SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log 2017-05-03 06:15:19:(INFO) : ACU Configurator , Category: HandleOutPut: Starting log 2017-05-03 06:15:19 2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category: -SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the System information... 2017-05-03 06:15:33:(WARN) : SCSDiscovery.exe, Category: System Discovery: System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836). 2017-05-03 06:15:33:(INFO) : SCSDiscovery, Category: Exit: ***********Exit with code 32 - Intel(R) AMT operation completed with warnings: Details: Success. System Discovery finished with warnings: System Discovery failed to get data from some of the interfaces on this system. (0xc00027ff). Failed to get data from the OS Registry interface. (0xc0002840). Failed to read the registry value (Primary DNS suffix). (0xc0001f52). Failed to open the registry Key (SYSTEM\CurrentControlSet\Services\LMS). The system cannot find the file specified. (0xc0001f50). The registry key not found.(SYSTEM\CurrentControlSet\Services\LMS) (0xc0001f58). Failed to get data from the GetDNSLookupName interface. (0xc0002842). Failed to retrieve the host onboard IPv4 IP (please check the LAN settings). (0xc0002836).
C:\Program Files\Intel_SCS_Discovery_11.1.0.75>
Not surprised, since I do NOT have AMT capabilities (I have 1.5MB ME series 9).
Zoran
On Tue, May 2, 2017 at 11:56 PM, Vadim Bendebury <vbendeb@chromium.org mailto:vbendeb@chromium.org> wrote:
I wonder if anyone ever completely trusted AMT - maybe some naive excessive cool-aid drinkers :) -vb On Tue, May 2, 2017 at 11:27 AM, ron minnich <rminnich@gmail.com <mailto:rminnich@gmail.com>> wrote: I wonder if anyone is going to completely trust AMT after this problem. It goes back almost 10 years. So for all those users who had it on for almost 10 years, the question becomes, how much did we lose and when did we lose it? The answer? We'll never know. Are we still owned? We don't know. Can we actually trust any reflash procedure, if the ME is owned while we try to reflash? Well, I hope so, but how can we know? It's a worrisome situation. ron On Tue, May 2, 2017 at 11:01 AM Patrick Georgi via coreboot <coreboot@coreboot.org <mailto:coreboot@coreboot.org>> wrote: Semi-Accurate only claims accuracy according to what's on the box. The official documentation of the issue can be found at https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 <https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075> It looks like a software bug in the AMT firmware. Therefore: - No AMT (eg on non-business consumer devices) -> no (bug | exploit). - Present but disabled AMT (eg. on business devices without AMT enrollment) -> no (bug | exploit). (although there's apparently a way to enable AMT unsupervised under some circumstances with some level of local access. or something.) Patrick 2017-05-02 19:31 GMT+02:00 John Lewis <jlewis@johnlewis.ie <mailto:jlewis@johnlewis.ie>>: > https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ <https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/> > > The article says "all" Intel boards since 2008 are locally vulnerable > (ME exploit), but the Intel advisory (linked within) says consumer > devices are okay. > > What the article says about even low end devices still having the > features albeit turned "off" rings true to me, based on stuff I've read > here and elsewhere. What's your take (bearing in mind the technical > details aren't available, yet)? > > > -- > coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot> -- coreboot mailing list: coreboot@coreboot.org <mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
On Wed, May 3, 2017 at 4:17 AM, John Lewis jlewis@johnlewis.ie wrote:
I think I've answered my own questions by checking out the menuconfig options, it looks to me as though up to and including Skylake is possible, and flashing internally *should* be okay?
Since writing to the ME region is protected by the IFD configuration, the possibility of internal flashing would be dependent on the current configuration of the board's IFD. I suspect most non-ChromeOS hardware will have it unlocked (default config) as their initial flash was likely with an external programmer. ChromeOS hardware will have a locked IFD and require external flashing to clean the ME (unless previously externally flashed with a ROM w/unlocked IFD).
-
John Lewis -
Matt DeVillier