11–20 of 96 posts
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?
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?
What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings. Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you...
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 fro…
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 fro…
Could you elaborate on why "treating the pointer to a string and the string length as separate vars" is dangerous to someone who hasn't done a lot of C?
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?
From the comment: What the programmer should have done is check if the hash coming from the browser has the correct length, 32 characters, before attempting to compare the two strings. Or even better, the programmer should have used the proper string comparing function, strcmp, that already does that for you...
Also, fixed length hashes aren't strings. They shouldn't use the same functions as strings.
Edit: Using a proper cryptography library also might have saved them from using MD5. At the very least, most modern libraries have a warning that is is deprecated and should not be used for new projects.
Earlier quoted context omitted.
Could you elaborate on why "treating the pointer to a string and the string length as separate vars" is dangerous to someone who hasn't done a lot of C?
If you access a memory location beyond the end of the string, you can get all sorts of unexpected behavior. The string's length is something you'll pretty much always need to take into account.
It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.
MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security.
In addition to the fundamental technical deficiency you've demonstrated, people who opine on security threads while not quite understanding anything about computer security allow charlatans to sell "computer security". Every single comment like this lends credence to literal scam artists.
¹note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)
Interesting how this article steadfastly refers to the subsystem as AMT and never mentions Management Engine/ME. A deliberate ploy to redirect people away from discovering all the ME-disabling research and tech? Perhaps. This is what happens when "journalists" post copypasta from publicists.
I quote: "When AMT is enabled, all network packets are redirected to the Intel Management Engine"
It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.
Which means, the published MD5 on on the Intel site would have to be the hash that the attacker created.
Though I'm sure there are better methods that Intel could implement.