[nSLUG] BIOS updating

Joel Maxuel j.maxuel at gmail.com
Wed Jun 14 20:17:41 ADT 2017


Realizing it would be different for everyone, I figured it out.  It
maintains an independent password, so I changed it to one strong enough
(default "admin" was set before) before disabling the IME controls.  I did
all this in the MEBx section.  It is now disabled to the point that I
cannot access the companion section in the BIOS - I would have to remember
the password (which 10 minutes later I am fuzzy on the details regarding)
and go back into MEBx setup to change anything first.

Outputs of the tools read the same though, but at least it's now tougher
for any abuse to occour.


--
Cheers,
Joel Maxuel

"One should strive to achieve, not sit in bitter regret."
 - Ronan Harris / Mark Jackson

On Wed, Jun 14, 2017 at 7:10 PM, Joel Maxuel <j.maxuel at gmail.com> wrote:

> Would that be the IME side or the regular BIOS side?
>
> https://support.lenovo.com/ca/en/product_security/len_3556
>
>
> --
> Cheers,
> Joel Maxuel
>
> "One should strive to achieve, not sit in bitter regret."
>  - Ronan Harris / Mark Jackson
>
> On Wed, Jun 14, 2017 at 7:05 PM, Dave Flogeras <dflogeras2 at gmail.com>
> wrote:
>
>> AFAICT, if you are enabled, but unprovisioned, you are OK.
>>
>> If you want to be double sure, go into your BIOS and find the option to
>> unprovision (if it exists; of my three affected systems, they all had
>> options to un-provision.  Only one had an option to disable MEI/AMT
>> altogether. YMMV).
>>
>> d
>>
>> On Wed, Jun 14, 2017 at 7:00 PM, Joel Maxuel <j.maxuel at gmail.com> wrote:
>>
>>> In that case, I should be fine?
>>>
>>> joel at cybaryme ~/B/g/mei-amt-check> sudo ./mei-amt-check
>>> [sudo] password for joel:
>>> Intel AMT is present
>>> AMT is unprovisioned
>>> joel at cybaryme ~/B/g/mei-amt-check>
>>>
>>>
>>> --
>>> Cheers,
>>> Joel Maxuel
>>>
>>> "One should strive to achieve, not sit in bitter regret."
>>>  - Ronan Harris / Mark Jackson
>>>
>>> On Wed, Jun 14, 2017 at 6:42 PM, Dave Flogeras <dflogeras2 at gmail.com>
>>> wrote:
>>>
>>>> There is also this project
>>>>
>>>> https://github.com/mjg59/mei-amt-check/
>>>>
>>>> On Wed, Jun 14, 2017 at 6:40 PM, Joel Maxuel <j.maxuel at gmail.com>
>>>> wrote:
>>>>
>>>>> Well then...
>>>>>
>>>>> INTEL-SA-00075-Discovery-Tool -- Release 0.8
>>>>> Copyright (C) 2003-2012, 2017 Intel Corporation.  All rights reserved
>>>>>
>>>>>
>>>>> ------------------Firmware Information--------------------
>>>>>
>>>>> Intel(R) AMT: ENABLED
>>>>> Flash:    8.1.0
>>>>> Netstack:    8.1.0
>>>>> AMTApps:    8.1.0
>>>>> AMT:    8.1.0
>>>>> Sku:    24584
>>>>> VendorID:    8086
>>>>> Build Number:    1265
>>>>> Recovery Version:    8.1.0
>>>>> Recovery Build Num:    1265
>>>>> Legacy Mode:    False
>>>>>
>>>>> -----------------SKU Information-----------------
>>>>>          Corporate SKU
>>>>>          Intel(R) Anti-Theft Technology (Intel(R) AT)
>>>>>          Intel(R) Active Management Technology
>>>>> -------------------------------------------------
>>>>>
>>>>> PROVISIONING_STATE = PRE
>>>>>
>>>>> ------------------Vulnerability Status--------------------
>>>>> Based on the version of the Intel(R) MEI, the System is Vulnerable.
>>>>> If Vulnerable, contact your OEM for support and remediation of this
>>>>> system.
>>>>> For more information, refer to CVE-2017-5689 at:
>>>>> https://nvd.nist.gov/vuln/detail/CVE-2017-5689 or the Intel security
>>>>> advisory
>>>>> Intel-SA-00075 at:
>>>>> https://security-center.intel.com/advisory.aspx?intelid=INTE
>>>>> L-SA-00075&languageid=en-fr
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Joel Maxuel
>>>>>
>>>>> "One should strive to achieve, not sit in bitter regret."
>>>>>  - Ronan Harris / Mark Jackson
>>>>>
>>>>> On Wed, Jun 14, 2017 at 4:10 PM, D G Teed <donald.teed at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I was puzzled by the whole thing when I read up on it a couple of
>>>>>> weeks ago.
>>>>>>
>>>>>> It is enabled on the BIOS of many systems, even if you don't have a
>>>>>> vPro sticker.
>>>>>> However, it won't be listening unless the IP had been configured on
>>>>>> the system
>>>>>> to offer the management services.  Once it is configured, that IP is
>>>>>> alive
>>>>>> even when the system is powered off.  Some newer systems have removed
>>>>>> the
>>>>>> option from the BIOs to disable IME.  It is like lights out or
>>>>>> baseboard management
>>>>>> built-in to the main ethernet interface on the mainboard.
>>>>>>
>>>>>> Big risk for anyone who has configured it, but just something
>>>>>> to be aware of for the rest of us.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 14, 2017 at 11:00 AM, George N. White III <
>>>>>> gnwiii at gmail.com> wrote:
>>>>>>
>>>>>>> On 14 June 2017 at 08:16, Joel Maxuel <j.maxuel at gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Dave.  I missed the memo on the active IME exploit.
>>>>>>>>
>>>>>>>> May not be much help to me anyway, based on the summary of changes
>>>>>>>> for my latest MoBo update:
>>>>>>>> http://support.lenovo.com/ca/en/downloads/ds029265
>>>>>>>>
>>>>>>>> I can check to see how bad it is, and what steps I can take tonight:
>>>>>>>> https://github.com/intel/INTEL-SA-00075-Linux-Detection-And-
>>>>>>>> Mitigation-Tools
>>>>>>>>
>>>>>>>> Thank you again.
>>>>>>>>
>>>>>>>
>>>>>>> Some US Government employees were told to get rid of their Lenovo
>>>>>>> laptops last fall.  Then in
>>>>>>> May Lenovo released Intel Management Engine Firmware 9.5 for my SSC
>>>>>>> issued
>>>>>>> laptop -- makes me wonder if US Gov't knew about IME exploits before
>>>>>>> they were made public,
>>>>>>> and if there are active exploits that still aren't public.
>>>>>>>
>>>>>>> Some articles suggest IME isn't an issue for linux users unless you
>>>>>>> use a high-end server
>>>>>>> farm that uses Intel's management tools, (possibly Google apps).
>>>>>>> That doesn't mean high-end
>>>>>>> malware won't leverage IME, but probably only after gaining full
>>>>>>> control of the system.   For
>>>>>>> home linux systems there may not be much to be gained from IME based
>>>>>>> exploits, but it
>>>>>>> sounds like something TLA agencies would use, so will probably
>>>>>>> escape to malware
>>>>>>> sooner or later.
>>>>>>>
>>>>>>> --
>>>>>>> George N. White III <aa056 at chebucto.ns.ca>
>>>>>>> Head of St. Margarets Bay, Nova Scotia
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> nSLUG mailing list
>>>>>>> nSLUG at nslug.ns.ca
>>>>>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> nSLUG mailing list
>>>>>> nSLUG at nslug.ns.ca
>>>>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nSLUG mailing list
>>>>> nSLUG at nslug.ns.ca
>>>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> nSLUG mailing list
>>>> nSLUG at nslug.ns.ca
>>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>>
>>>>
>>>
>>> _______________________________________________
>>> nSLUG mailing list
>>> nSLUG at nslug.ns.ca
>>> http://nslug.ns.ca/mailman/listinfo/nslug
>>>
>>>
>>
>> _______________________________________________
>> nSLUG mailing list
>> nSLUG at nslug.ns.ca
>> http://nslug.ns.ca/mailman/listinfo/nslug
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20170614/07459f74/attachment.html>


More information about the nSLUG mailing list