maybe vuln in intel chipsets from 2008 to today
-
Remote security exploit in all 2008+ Intel platforms
The short version is that every Intel platform with AMT, ISM, and SBT from Nehalem in 2008 to Kaby Lake in 2017 has a remotely exploitable security hole in the ME (Management Engine) not CPU firmware.
Seems that the guy is not a cool sec-boy, but there is apparent (indirect) confirmation from Intel
-
From the reddit thread:
-
@hungrier Interesting. The bit you quoted claims that literally any Intel computer in the specified range is literally at risk from this literally horrible vulnerability. But the Intel bulletin states:
This vulnerability does not exist on Intel-based consumer PCs.
I wonder which one is correct?
-
@masonwheeler what is not(intel consumer-based PC) ? servers ? other things ?
-
The official Intel release says
Step 1: Determine if you have an Intel® AMT, Intel® SBA, or Intel® ISM capable system: https://communities.intel.com/docs/DOC-5693. If you determine that you do not have an Intel® AMT, Intel® SBA, or Intel® ISM capable system then no further action is required.
I'm assuming AMT, SBA and ISM are some fancy-pants above-consumer-grade technology.
-
@hungrier said in maybe vuln in intel chipsets from 2008 to today:
The official Intel release says
Step 1: Determine if you have an Intel® AMT, Intel® SBA, or Intel® ISM capable system: https://communities.intel.com/docs/DOC-5693. If you determine that you do not have an Intel® AMT, Intel® SBA, or Intel® ISM capable system then no further action is required.
Intel:
Intel Active Management Technology (Intel AMT) is the manageability part of Intel vPro Technology
@hungrier said in maybe vuln in intel chipsets from 2008 to today:
I'm assuming AMT, SBA and ISM are some fancy-pants above-consumer-grade technology.
I'm pretty sure vPro is in "consumer" offerings, so
FYI:
"In March, 2017 a security researcher identified and reported to Intel a critical firmware vulnerability in business PCs and devices that utilize Intel Active Management Technology (AMT), Intel Standard Manageability (ISM), or Intel Small Business Technology (SBT)," an Intel spokesperson told The Register in the past few minutes.
-
@Dreikin said in maybe vuln in intel chipsets from 2008 to today:
the manageability part
??? What does that even mean ???
-
@masonwheeler said in maybe vuln in intel chipsets from 2008 to today:
@Dreikin said in maybe vuln in intel chipsets from 2008 to today:
the manageability part
??? What does that even mean ???
Intel vPro technology is an umbrella marketing term used by Intel for a large collection of computer hardware technologies, including Hyperthreading, Turbo Boost 3.0, VT-x, VT-d, Trusted Execution Technology (TXT), and Intel Active Management Technology (AMT).
So presumably it's the subset of the vPro set that focuses on system management.
Intel Active Management Technology (AMT) is hardware and firmware technology for remote out-of-band management of personal computers,[1][2][3][4][5] in order to monitor, maintain, update, upgrade, and repair them.[1] Out-of-band (OOB) or hardware-based management is different from software-based (or in-band) management and software management agents.
-
Those three technologies are different flavors of Intel's remote management console, which can be used to monitor and restart a server over the network (IPMI, though I can't remember what the P stands for). It's a management interface that ships with little or no default password strength, and generally should never be made accessible outside of a hardened, trusted network (best practice is to even segregate the IPMI net from your standard client LAN, limiting access to trusted admin VMs or servers).
-
@Dreikin said in maybe vuln in intel chipsets from 2008 to today:
Intel Active Management Technology (AMT), Intel Standard Manageability (ISM), or Intel Small Business Technology (SBT)
Between their built-in backdoors and their enclave bullshit, Intel processors are just security nightmares.
Just run code and stop adding "clever" shit!
-
@anonymous234 said in maybe vuln in intel chipsets from 2008 to today:
@Dreikin said in maybe vuln in intel chipsets from 2008 to today:
Intel Active Management Technology (AMT), Intel Standard Manageability (ISM), or Intel Small Business Technology (SBT)
Between their built-in backdoors and their enclave bullshit, Intel processors are just security nightmares.
Just run code and stop adding "clever" shit!
DRM: Fucking over users in favor of corporations since 1983.
-
@anonymous234 said in maybe vuln in intel chipsets from 2008 to today:
Between their built-in backdoors and their enclave bullshit, Intel processors are just security nightmares.
Just run code and stop adding "clever" shit!
from the wikipedia pointed:
Intel SGX is a set of new instructions from Intel that allows user-level code to allocate private regions of memory, called enclaves, that unlike normal process memory is also protected from processes running at higher privilege levels.
and
On 27 March 2017 researches at Austria's Graz University of Technology developed a proof-of-concept that can grab RSA keys from SGX enclaves running on the same system within five minutes by using certain CPU instructions in lieu of a fine-grained timer to exploit cache DRAM side-channels
-
@hungrier said in maybe vuln in intel chipsets from 2008 to today:
Determine if
Why not just make an exploit checker program? Then the hackers could use it to swipe in their own exploit and fix all the things!
-
follow up
Rediscovering the Intel AMT VulnerabilityNext, we reduced the response hash to one hex digit and authentication still worked. Continuing to dig, we used a NULL/empty response hash (response="" in the HTTP Authorization header).
Authentication still worked. We had discovered a complete bypass of the authentication scheme.
Tenable reached out to Intel on May 3 with our proof-of-concept, asking if this was the same vulnerability previously disclosed by Intel on May 1. On May 4, Intel responded confirming that it was the same vulnerability
-
The Register is reporting the relevant code is:
if(strncmp(computed_response, user_response, response_length)) deny_access();
where
response_length
is computed fromuser_response
. There is not a headdesk meme big enough for this.
-
paging @RaceProUK ...
-
@Greybeard it looks like 99% of all security vulnerabilities in the world are caused by C library designers' assumption that developers know what they're doing so they can do those cool microoptimizations that aren't relevant to most people since the early 90s. In this case, passing a single string length to compare two separate strings - after all, we'd read up to the smaller one anyway, and people know that strings of inequal length are automatically inequal, right?
-
@Gąska I mean, using
strncmp()
there.There ain't no library designer nowhere can help with developers what don't know what they're doing.
-
@Greybeard said in maybe vuln in intel chipsets from 2008 to today:
@Gąska I mean, using
strncmp()
there.Same reason as using any other
n
function - either because you're not sure if there's a null terminator or not, or to work around compiler warning.
-
@Greybeard said in maybe vuln in intel chipsets from 2008 to today:
There ain't no library designer nowhere can help with developers what don't know what they're doing.
Most developers do the wrong thing because they're lazy. If you make the right thing easier to do than the wrong thing, almost no one will do the wrong thing. But for every programming task, there's ten right ways and million wrong ways - so it's significantly harder to make all the wrong ways harder than the chosen right way. And library developers are developers too - and developers are lazy.
-
@Gąska And if
strncmp()
had two length parameters the lazy programmer would have passedresponse_length
to both.
-
@Greybeard yeah, maybe. But it would be more obviously wrong.
/me remembers Apple's "goto fail" happened not that long ago.
...or maybe not. :s
-
@Gąska You are seriously overestimating the impact of API design. No alternate-universe API could have prevented my own security vulnerability.
C's susceptibility to vulnerabilities is far more fundamental than the design of its libraries.
-
@Greybeard said in maybe vuln in intel chipsets from 2008 to today:
@Gąska You are seriously overestimating the impact of API design. No alternate-universe API could have prevented my own security vulnerability.
There is one simple API design choice that would help for most problems with C: explicitly sized strings - either Pascal-style with length stored along string, or Rust-style with length stored along pointer. Unfortunately, it's over half a century too late to fix that.
-
@Gąska That's why in C++ you're supposed to use
std::string
now, right?Actually, has anyone made something like that for C yet?
-
@izzion said in maybe vuln in intel chipsets from 2008 to today:
Those three technologies are different flavors of Intel's remote management console, which can be used to monitor and restart a server over the network (IPMI, though I can't remember what the P stands for). It's a management interface that ships with little or no default password strength, and generally should never be made accessible outside of a hardened, trusted network (best practice is to even segregate the IPMI net from your standard client LAN, limiting access to trusted admin VMs or servers).
In another news Intel said they can use it to wipe clean and reinstall non-functional device remotely, so it's more than that. (i.e.: the firmware part can have direct access to NIC bypassing the operation system, the servicing processor sits on PCH and have direct access to the hardwares)
And btw, my motherboard is consumer grade Asus B85-PLUS and it also have SBT support.
-
@powerlord said in maybe vuln in intel chipsets from 2008 to today:
Actually, has anyone made something like that for C yet?
It's called "std::string". And "use a C++ compiler already".
-
@Gąska Let's look at the WTF chain here
-
Using a language that's absolutely terrible for handling strings and writing safe code, in a place where safety is critical that has to handle lots of strings
- C still being so universal that a lot of people won't even consider using anything else
- Complete lack of any languages other than C and C++ for embedded development
-
Having a massive glaring vulnerability, in the most critical line of an extremely critical piece of code, and no one in Intel noticing (no code reviews)
-
No one apart from one guy doing any penetration testing there for almost 10 years
-
Intel being repeatedly notified about it and ignoring it
It kinda sounds like Intel actually wanted that there as a backdoor.
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
/me remembers Apple's "goto fail" happened not that long ago.
Theory: both of them were NSA backdoors. They made them really obvious so, when found, people would automatically attribute them to human error and incompetence rather than sophisticated infiltration attempts.
-
-
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
In this case, passing a single string length to compare two separate strings - after all, we'd read up to the smaller one anyway, and people know that strings of inequal length are automatically inequal, right?
It's useful in other cases too, such as if you want to know if one string is a prefix of the other. Doesn't make it the right choice here though.
-
@anonymous234 said in maybe vuln in intel chipsets from 2008 to today:
Theory: both of them were NSA backdoors. They made them really obvious so, when found, people would automatically attribute them to human error and incompetence rather than sophisticate infiltration attempts.
Considering they were warned about this repeatedly for years and dismissed and bullshitted it away, I think you've nailed it.
-
@dkf said in maybe vuln in intel chipsets from 2008 to today:
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
In this case, passing a single string length to compare two separate strings - after all, we'd read up to the smaller one anyway, and people know that strings of inequal length are automatically inequal, right?
It's useful in other cases too, such as if you want to know if one string is a prefix of the other.
Or you could have another function entirely for that purpose. Single responsibility FFS!
-
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
Or you could have another function entirely for that purpose. Single responsibility FFS!
But that's exactly what
strncmp
does. It compares (up to) the first N chars of two strings, which is precisely what you need for prefix determination. What it doesn't do is what the idiots who used it here seemed to think; that appears to be more based on the thought thatstrcmp
is Bad and should be converted tostrncmp
in all cases. Which would still have been “fine” if they'd used the relevant buffer size for N… but they used the user-supplied string's length (which was smaller, much much smaller).Writing secure C code isn't exactly easy, but it sure isn't impossible either.
-
@dkf said in maybe vuln in intel chipsets from 2008 to today:
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
Or you could have another function entirely for that purpose. Single responsibility FFS!
But that's exactly what
strncmp
does. It compares (up to) the first N chars of two strings, which is precisely what you need for prefix determination. What it doesn't do is what the idiots who used it here seemed to think; that appears to be more based on the thought thatstrcmp
is Bad and should be converted tostrncmp
in all cases. Which would still have been “fine” if they'd used the relevant buffer size for N… but they used the user-supplied string's length (which was smaller, much much smaller).Writing secure C code isn't exactly easy, but it sure isn't impossible either.
Indeed.
strncmp
is not intended for use with non-null-terminated strings because the C standard library doesn't account for the possibility of strings that are not null-terminated. And if your buffer is ever too small you're screwed.The only comfort is that string handling code is slightly less hard to do yourself and get right than date handling code.
-
@PleegWat said in maybe vuln in intel chipsets from 2008 to today:
The only comfort is that string handling code is slightly less hard to do yourself and get right than date handling code.
It's much easier now that there's a moderately sane format you can convert everything into. UTF-8 (and a few slightly denormalized versions thereof) are hugely saner than some of the other blecherous horrors out there. However, there's a lot of badly-trained programmers too, which makes everything much worse. (We totally need to slaughter the character = byte brain-worm; anyone still thinking that is in for a world of trouble. And there's a lot of bad data out there. :()
Date handling is hard for other reasons. Notably
asshatspoliticians.
-
@dkf said in maybe vuln in intel chipsets from 2008 to today:
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
Or you could have another function entirely for that purpose. Single responsibility FFS!
But that's exactly what
strncmp
does. It compares (up to) the first N chars of two strings, which is precisely what you need for prefix determination.Everybody knows that
n
functions are just variants of non-n
functions that have exactly the same semantics and purpose, but check for overflows.strcmp
is for checking dictionary order of two null-terminated strings using C locale.strncmp
is for checking dictionary order of two null-terminated strings up to N bytes long using C locale. Claiming it was designed with any other purpose is intellectual dishonesty. The fact it can be used for other purposes is irrelevant. The specification literally sayingstrncmp
is comparing first N bytes is codifying implementation detail, which is just as wrong.A function for checking prefix would be named
strprfx
or something.
-
@Gąska said in maybe vuln in intel chipsets from 2008 to today:
function for checking prefix would be named strprfx or something
BeginsWith()
¿
-
@Tsaukpaetra CamelCase? Vowels? More than 8 characters? Obvious purpose? That's against all the C library style guidelines!