<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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?<br>
</p>
<p>John.<br>
</p>
<br>
<div class="moz-cite-prefix">On 03/05/17 10:09, John Lewis wrote:<br>
</div>
<blockquote
cite="mid:2f243142-8062-ffa6-5916-6f53bc7b8be1@johnlewis.ie"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p>Thanks everyone for the responses.</p>
<p>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 @ <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.embedi.com/news/mythbusters-cve-2017-5689">https://www.embedi.com/news/mythbusters-cve-2017-5689</a>
it sounds like it could be every board since 2010.</p>
<p>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.</p>
<p>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?<br>
</p>
<p>John.<br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
</p>
<br>
<div class="moz-cite-prefix">On 03/05/17 05:37, Zoran
Stojsavljevic wrote:<br>
</div>
<blockquote
cite="mid:CAGAf8Lx6bz0hRG5d0hsh68mUeb_ktSuiLYe50K_4euxbTHYxLA@mail.gmail.com"
type="cite">
<div dir="ltr">I also read in details some of the emails from
the previous threads. I downloaded SCSDiscovery tool:
<div><a moz-do-not-send="true"
href="https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-Utility">https://downloadcenter.intel.com/download/26691/Intel-SCS-System-Discovery-Utility</a><br>
</div>
<div>and ran it on my notebook.<br>
</div>
<div>
<div><br>
</div>
<div>I got as response a bunch of nonsense info (basically,
it failed everywhere) :</div>
<div><br>
</div>
<div>
<div>C:\Program
Files\Intel_SCS_Discovery_11.1.0.75>type <a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log">SCSDiscoverylog_DESKTOP-@@@@@@@_2017-05-03-06-15-18.Log</a></div>
<div>2017-05-03 06:15:19:(INFO) : ACU Configurator ,
Category: HandleOutPut: Starting log 2017-05-03 06:15:19</div>
<div>2017-05-03 06:15:19:(INFO) : SCSDiscovery, Category:
-SystemDiscovery-: DESKTOP-@@@@@@@: Discovering the
System information...</div>
<div>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).</div>
<div>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).</div>
<div><br>
</div>
<div>C:\Program Files\Intel_SCS_Discovery_11.1.0.75></div>
</div>
<div><br>
</div>
<div>Not surprised, since I do NOT have AMT capabilities (I
have 1.5MB ME series 9).</div>
<div><br>
</div>
<div>Zoran</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 2, 2017 at 11:56 PM,
Vadim Bendebury <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:vbendeb@chromium.org" target="_blank">vbendeb@chromium.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I wonder if anyone ever completely trusted
AMT - maybe some naive excessive cool-aid drinkers :)<span
class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-vb</div>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, May 2, 2017 at
11:27 AM, ron minnich <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:rminnich@gmail.com"
target="_blank">rminnich@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">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?
<div><br>
</div>
<div>It's a worrisome situation.</div>
<span class="m_-5932888364768504086HOEnZb"><font
color="#888888">
<div><br>
</div>
<div>ron</div>
</font></span></div>
<div class="m_-5932888364768504086HOEnZb">
<div class="m_-5932888364768504086h5"><br>
<div class="gmail_quote">
<div dir="ltr">On Tue, May 2, 2017 at
11:01 AM Patrick Georgi via coreboot
<<a moz-do-not-send="true"
href="mailto:coreboot@coreboot.org"
target="_blank">coreboot@coreboot.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Semi-Accurate
only claims accuracy according to what's
on the box. The<br>
official documentation of the issue can
be found at<br>
<a moz-do-not-send="true"
href="https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075"
rel="noreferrer" target="_blank">https://security-center.intel.<wbr>com/advisory.aspx?intelid=INTE<wbr>L-SA-00075</a><br>
<br>
It looks like a software bug in the AMT
firmware. Therefore:<br>
- No AMT (eg on non-business consumer
devices) -> no (bug | exploit).<br>
- Present but disabled AMT (eg. on
business devices without AMT<br>
enrollment) -> no (bug | exploit).
(although there's apparently a way<br>
to enable AMT unsupervised under some
circumstances with some level of<br>
local access. or something.)<br>
<br>
<br>
Patrick<br>
<br>
2017-05-02 19:31 GMT+02:00 John Lewis
<<a moz-do-not-send="true"
href="mailto:jlewis@johnlewis.ie"
target="_blank">jlewis@johnlewis.ie</a>>:<br>
> <a moz-do-not-send="true"
href="https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/"
rel="noreferrer" target="_blank">https://semiaccurate.com/2017/<wbr>05/01/remote-security-exploit-<wbr>2008-intel-platforms/</a><br>
><br>
> The article says "all" Intel boards
since 2008 are locally vulnerable<br>
> (ME exploit), but the Intel
advisory (linked within) says consumer<br>
> devices are okay.<br>
><br>
> What the article says about even
low end devices still having the<br>
> features albeit turned "off" rings
true to me, based on stuff I've read<br>
> here and elsewhere. What's your
take (bearing in mind the technical<br>
> details aren't available, yet)?<br>
><br>
><br>
> --<br>
> coreboot mailing list: <a
moz-do-not-send="true"
href="mailto:coreboot@coreboot.org"
target="_blank">coreboot@coreboot.org</a><br>
> <a moz-do-not-send="true"
href="https://mail.coreboot.org/mailman/listinfo/coreboot"
rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br>
<br>
<br>
<br>
--<br>
Google Germany GmbH, ABC-Str. 19, 20354
Hamburg<br>
Registergericht und -nummer: Hamburg,
HRB 86891, Sitz der Gesellschaft:
Hamburg<br>
Geschäftsführer: Matthew Scott
Sucherman, Paul Terence Manicle<br>
<br>
--<br>
coreboot mailing list: <a
moz-do-not-send="true"
href="mailto:coreboot@coreboot.org"
target="_blank">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true"
href="https://mail.coreboot.org/mailman/listinfo/coreboot"
rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a></blockquote>
</div>
</div>
</div>
<br>
--<br>
coreboot mailing list: <a
moz-do-not-send="true"
href="mailto:coreboot@coreboot.org"
target="_blank">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true"
href="https://mail.coreboot.org/mailman/listinfo/coreboot"
rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
--<br>
coreboot mailing list: <a moz-do-not-send="true"
href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a moz-do-not-send="true"
href="https://mail.coreboot.org/mailman/listinfo/coreboot"
rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>