[coreboot] Anyone got an opinion, technical or otherwise, on this?
John Lewis
jlewis at johnlewis.ie
Wed May 3 11:17:33 CEST 2017
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-Utility
>> 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 at chromium.org <mailto:vbendeb at 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 at gmail.com
>> <mailto:rminnich at 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 at coreboot.org <mailto:coreboot at 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 at johnlewis.ie <mailto:jlewis at 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 at coreboot.org
>> <mailto:coreboot at 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 at coreboot.org
>> <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>> <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>> <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>> <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170503/83098fe0/attachment.html>
More information about the coreboot
mailing list