Fwd: Intel's Management Technology is indeed vulnerable
Firmware remote vulnerability in Intel business products -------- Forwarded Message -------- Subject: Intel's Management Technology is indeed vulnerable Date: Tue, 2 May 2017 19:49:54 +0200 (CEST) From: I love OpenBSD <lampshade@poczta.fm> To: misc@openbsd.org INTEL-SA-00075 There is an escalation of privilege vulnerability in Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology versions firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 that can allow an unprivileged attacker to gain control of the manageability features provided by these products. Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin... Arstechnica: http://bit.ly/2qyHCQn Semiaccurate: http://bit.ly/2pB2MjO Intel's PDF: http://intel.ly/2qAK4G0
On 03/05/17 23:59, Douglas Ray via luv-talk wrote:
Firmware remote vulnerability in Intel business products
Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin...
Yeah, but using bit.ly has other problems -- not least of which is they track the s*** out of them...
Arstechnica: http://bit.ly/2qyHCQn
https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution...
Semiaccurate: http://bit.ly/2pB2MjO
https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platf...
Intel's PDF: http://intel.ly/2qAK4G0
I'm sure it's ditto for Intel on the tracking too. https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075 Mitigation%20Guide%20-%20Rev%201.1.pdf Sorry, you might need to do a little work to get that final link to be clickable or otherwise usable. ;-) Cheers AndrewM
Andrew McGlashan via luv-talk wrote:
On 03/05/17 23:59, Douglas Ray via luv-talk wrote:
Firmware remote vulnerability in Intel business products
Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin...
Yeah, but using bit.ly has other problems -- not least of which is they track the s*** out of them...
$ curl -so/dev/null -Iw'%{redirect_url}\n' http://bit.ly/2qyHCQn https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution... Then browse to that link directly, which will bypass (some) of the tracking. If this is a common task for you, you can wrap it into a shell function or whatever. #!/bin/sh -e xdg-open "$(curl -so/dev/null -Iw'%{redirect_url}\n' "$1")"
Hi, On 04/05/17 10:48, Trent W. Buck via luv-talk wrote:
Andrew McGlashan via luv-talk wrote:
On 03/05/17 23:59, Douglas Ray via luv-talk wrote:
Firmware remote vulnerability in Intel business products
Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin...
Yeah, but using bit.ly has other problems -- not least of which is they track the s*** out of them...
$ curl -so/dev/null -Iw'%{redirect_url}\n' http://bit.ly/2qyHCQn https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution...
Then browse to that link directly, which will bypass (some) of the tracking.
If this is a common task for you, you can wrap it into a shell function or whatever.
#!/bin/sh -e xdg-open "$(curl -so/dev/null -Iw'%{redirect_url}\n' "$1")"
Thanks, that's an interesting method, but sometimes you get redirect after redirect [and maybe a bunch more] .... This is due to extra methods used in tracking; so I have a script for that too. I'm sure it isn't perfect either, but it works well most of the time, some links fail to give me the /right/ end link for some reason (it might be user agent strings). Oh and yes, my script follows the redirects via socks5 proxy, but the final URL is clean and the browser has less information as to how the link was gotten too when it gets to load the URL; there will be exceptions when the final URL is actually one that looks normal, but is actually specific due to how it was gotten -- that is, you would never get to that link without following the path of the initial tracked link. $ cat get-real-url #!/bin/bash set -u get_link_base() { echo "${1}"|awk -F/ '{print $1"//"$3}' } LINK="${1}" [ -z "${LINK}" ] && { echo bad link; exit; } # PRE Adjust domains for .onion addresses where possible # (some links are better changed immediately, others POST work) ALT_LINK="${LINK/facebook.com/facebookcorewwwi.onion/}" # IF link adjusted above, use new link [[ "${LINK}" = "${ALT_LINK}" ]] || { echo -e "\nNew alternate link: ${ALT_LINK}" LINK="${ALT_LINK}" } link_base=$(get_link_base "${LINK}") echo -e "\nFirst Link Base: ${link_base}" loc_lnk='not yet' while : do echo '------------------------------' # If download link redirects to a new Location, use that echo -en "\nGet location at $(date)\t\t" loc_lnk=$( curl -Is "${LINK}" | \ awk '/^[Ll]ocation:/{$1="";gsub(/^[ \t]+|[\r]/, "");print}' ) # the following doesn't keep following the redirects #loc_lnk=$(curl -so/dev/null -Iw'%{redirect_url}\n' "${LINK}") [ -z "${loc_lnk}" ] && { echo -e "no more redirects" break } echo -e "${loc_lnk}" # fix relative link to full link if we've lost base link if [[ "${loc_lnk:0:1}" = "/" ]] then loc_lnk="${link_base}${loc_lnk}" else link_base=$(get_link_base "${loc_lnk}") echo -e "\nNew Link Base: ${link_base}" fi echo -e "\nlocation link: ${loc_lnk}" LINK="${loc_lnk}" done # POST Adjust domains for other special .onion addresses where possible # - done here as post processing because in this case, # it is cleaner then pre-processing and gives a better result ALT_LINK="${LINK/propublica.org/propub3r6espa33w.onion/}" # IF link adjusted above, use new link [[ "${LINK}" = "${ALT_LINK}" ]] || { echo -e "\nNew alternate link: ${ALT_LINK}" LINK="${ALT_LINK}" } echo echo '------------------------------' echo echo "${LINK}" echo # Now remove all parameters passed with the URL LINK=${LINK%%[?]*} echo "${LINK}" echo echo firefox \""${LINK}"\" echo echo Cheers A.
Hi, Just notices this old email when I did a search for other emails.... On 4/5/17 10:48 am, Trent W. Buck wrote:
Andrew McGlashan via luv-talk wrote:
On 03/05/17 23:59, Douglas Ray via luv-talk wrote:
Firmware remote vulnerability in Intel business products
Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin...
Yeah, but using bit.ly has other problems -- not least of which is they track the s*** out of them...
$ curl -so/dev/null -Iw'%{redirect_url}\n' http://bit.ly/2qyHCQn https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution...
Then browse to that link directly, which will bypass (some) of the tracking.
Not sure it stops the tracking because you've got to get the redirect from it....
If this is a common task for you, you can wrap it into a shell function or whatever.
#!/bin/sh -e xdg-open "$(curl -so/dev/null -Iw'%{redirect_url}\n' "$1")"
Just add a "+" to the end of bit.ly links and you can see the reporting of link usage and see the actual link it points to as well. In this case, a tiny 69 clicks. https://bitly.com/2qyHCQn+ If you don't want any tracking bit.ly -- then don't use them at all. The attached script /might/ be useful for some. NB: Sometimes there are multiple redirects.... - and quite often there is junk at the end of a URL. Oh and my script has an added advantage of converting a couple of URLs to Tor network address (.onion) to keep off exit nodes where possible; there could easily be more .onion addresses added though. My script shows transition of links and defaults to having clean links to use with a chosen browser from a list of browsers. If a determined link is not useful, one of the transitional ones (with what may have been junk), may work. Output from a sample run is attached as well. Cheers AndrewM
Quoting Douglas Ray (dougray@cpan.org):
Firmware remote vulnerability in Intel business products
Forwarding from my local LUG: Date: Wed, 3 May 2017 23:08:47 -0700 From: Rick Moen <rick@linuxmafia.com> To: conspire@linuxmafia.com Subject: Intel Active Management Technology (AMT): not necessarily your friend Organization: If you lived here, you'd be $HOME already. X-Mas: Bah humbug. X-Clacks-Overhead: GNU Terry Pratchett LWN.net covers the below-cited matter in its usual crystal-clear way. Normally, that would be subscriber-only for another week (because it's an article in this week's Linux Weekly News), but as a subscriber I am allowed to offer y'all a special URL to read this one article: https://lwn.net/SubscriberLink/721586/7a5e4348f30c07ee/ That having been said, if you can afford to subscribe to LWN and are interested in Linux, you should subscribe. It's a uniquely valuable periodical. ----- Forwarded message from Rick Moen <rick@linuxmafia.com> ----- Date: Wed, 3 May 2017 17:20:42 -0700 From: Rick Moen <rick@linuxmafia.com> To: svlug@lists.svlug.org Subject: [svlug] Intel Active Management Technology (AMT): not necessarily your friend Pitfall inside. A decade-plus ago, Intel started building embedded control structures deep into its chipsets. One, present in many but not all Intel x86 motherboard chipset since 2008 starting with 'Nehalem', is the Active Management Technology (AMT) out-of-band network service, intended to permit out-of-band system management on one out of network ports 16992i-16995[1] (over ethernet)[2], to remotely reboot, repair, and tweak hosts, and has total control of the host from ring -2, below the level of the normal hardware (ring 0). It's supposed to require an access password, and then provide remote serial console or VNC Gosh, what could possibly go wrong? Enter CVE-2017-5689). Um, yes, they messed that up, not counting the entire thing being a bad idea, anyway. (Details are not yet fully released, and it's best to check links such as those I give below, in case I've gotten something wrong or there are new developments.) AMT is built atop a slightly earlier feature called Management Engine ('ME', introduced with the Core 2 in 2006), and on current systems is said to run on SPARC core circuitry (yes, on your Intel-based motherboard). With some Intel circuitry, there are ways that have been discovered to wipe out the ME, which seems a fabulous idea to me. On any local system with AMT drivers installed (a root operation), unprivileged local users can also connect to the AMT with full administrative privilege, in addition to the remote risk. Some Intel systems ship with AMT, others don't. Most that ship with it don't have it turned on by default. But, if yours does, it has a big security problem. (AMT can still be exploited locally even if it's defaulted to shut off, as a local user can switch it on.) https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platf... https://www.embedi.com/news/mythbusters-cve-2017-5689 https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/ http://mjg59.dreamwidth.org/48429.html https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Gui... Bottom link is the mitigation guide, telling you how to use MS-Windows's built in command line program 'SC' to deal with the problem. As usual, they assume everyone runs MS-Windows, but an open-source tool for *ix that seems to offer the same functionality is here: https://software.intel.com/en-us/articles/download-the-latest-intel-amt-open... First link in the above set (the one to read even if you read nothing else) is particularly damning, as it says researcher Charlie Demerjian has been trying to take the security problem seriously for years. Demerjian claims you should disable or install Local Manageability Service (LMS) to block access to AMT, and that related features ISM (Intel System Management) and SBT (Small Business Technology) are also problems. (See link for more.) [1] Intel's mitigation guide also says ports 623 and 664. [2] Commenters on Matthew Garrett's blog (see link) claim AMT is also reachable over Intel wifi interfaces. ----- End forwarded message -----
-------- Forwarded Message -------- Subject: Intel's Management Technology is indeed vulnerable Date: Tue, 2 May 2017 19:49:54 +0200 (CEST) From: I love OpenBSD <lampshade@poczta.fm> To: misc@openbsd.org
INTEL-SA-00075 There is an escalation of privilege vulnerability in Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology versions firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 that can allow an unprivileged attacker to gain control of the manageability features provided by these products.
Can I preview a bitlink before clicking on it? https://support.bitly.com/hc/en-us/articles/230650447-Can-I-preview-a-bitlin...
Arstechnica: http://bit.ly/2qyHCQn
Semiaccurate: http://bit.ly/2pB2MjO
Intel's PDF: http://intel.ly/2qAK4G0
_______________________________________________ luv-talk mailing list luv-talk@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-talk
participants (4)
-
Andrew McGlashan -
Douglas Ray -
Rick Moen -
Trent W. Buck