The hijacking flaw that lurked in Intel chips is worse than anyone thought

It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.

There is a great comment linked at the bottom of the article that explains what exactly caused the authentication bug (it was strncmp!). Is there somehow a law that states that the higher the severity of a software bug, the simpler the reason behind it?

AMT's an optional component of the ME, it's the part that enables remote management, and it's a flaw in AMT that they're describing. It seems reasonable to talk about the part that has a problem (although it wouldn't have been unreasonable for them to mention that it's part of the IME, of course).

From the article:

> When AMT is enabled, all network packets are redirected to the Intel Management Engine and from there to the AMT. The packets bypass the OS completely. The vulnerable management features were made available in some but not all Intel chipsets starting in 2010, Embedi has said.

The vulnerability is in AMT, not ME (though I agree that the ME is an unnecessary security risk, and am well behind the current research to disable it).

At what point does it become reasonable to conclude that strncmp, and every other string API that treats the pointer to the string and its length as separable variables, are too dangerous to be used in security-sensitive software? I feel like I've seen another vulnerability this week from someone sending the wrong length to a standard C string function.

If you want to fix this, there's no strict need to move away from C (not that I'd particularly encourage you to stay, but if you have some reason to prefer C, you can solve this in C). There are a number of C libraries that give you a struct string {char *ptr; int len;} of some sort, from bstring to GLib. And there's always C++, too.

What need does the Intel AMT firmware have for compatibility with POSIX string APIs? It's not running a POSIX OS, is it?