I wish that this security incident would get more attention. It seems fundamentally unfair that some projects that are essentially volunteer labor get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets mostly ignored.
The hijacking flaw that lurked in Intel chips is worse than anyone thought
51–60 of 96 posts
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#52Is the amount of attention this is getting commensurate with how interesting/surprising/consequential a security flaw it is?
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#53Surely a new one must have been created since NSA tools are out on the net
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#54I wish that this security incident would get more attention. It seems fundamentally unfair that some projects that are essentially volunteer labor get so much scrutiny, while Intel doing some so fundamentally asshole-ish gets mostly ignored.
If scrutiny improves the project it's ultimately a good thing.
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#55Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#56Earlier quoted context omitted.
"An authentication bypass is bad, but a full compromise would have been much worse." Given the authentication bypass essentially leads to full compromise, where's the difference, here?
The difference is, you are no longer limited to functionality normally provided by AMT. Maybe AMT doesn't offer the ability to download arbitrary memory locations from the running OS and applications, with remote code execution on the ME you could do that. You could modify code running on the CPU on-the-fly and make it read files from disk to memory for downloading too - again, I don't think AMT can read disks, espec…
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#57Is the amount of attention this is getting commensurate with how interesting/surprising/consequential a security flaw it is?
I don't think it's just that the flaw exists, which alone is pretty bad, but how widely deployed it is in large enterprise, coupled with Intel ignoring it after being given years of notice and also the unease about AMT in the OSS community since it's deployment. To be honest, I doubt 9/10 people who care about this are going to stop using Intel, but it's still a comedy of errors and I think everyone loves a spectacle…
Sure about that? From what I can tell, it's a recently discovered vulnerability that was promptly fixed.
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#58It just keeps getting better: Intel's diagnostic tool is published with an MD5 checksum.
That's fine. I will literally give you $10,000 if¹ you can give me a MD5 preimage attack. Take your attack vector to be that particular md5sum that you are making fun of. 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 securi…
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#59Earlier quoted context omitted.
I don't think it's just that the flaw exists, which alone is pretty bad, but how widely deployed it is in large enterprise, coupled with Intel ignoring it after being given years of notice and also the unease about AMT in the OSS community since it's deployment. To be honest, I doubt 9/10 people who care about this are going to stop using Intel, but it's still a comedy of errors and I think everyone loves a spectacle…
> Intel ignoring it after being given years of notice Sure about that? From what I can tell, it's a recently discovered vulnerability that was promptly fixed.
Re: The hijacking flaw that lurked in Intel chips is worse than anyone thought
#60Earlier quoted context omitted.
> In HTTP everything is a string. Once you parse it out of HTTP it is no longer as string (or at least it should no longer be a string). >HTTP, again. Browser sends MD5 whether you like it or not. They are quite clearly doing verification themselves. They can use whatever algorithm they want.
It has to be MD5. They use HTTP digest auth, which uses MD5. You send a nonce, the browser throws a popup asking for password and returns md5(nonce+pass). No way around it.