It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.
replyGiven the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
The article has a screenshot of the decompiled code showing that they're just running the downloaded executable immediately, without any additional checks on the content.
replyA manager somewhere made the embarrassingly wrong decision to not fix this, and they’re too egotistical to correct their mistake.
replyThat’s my take.
Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.
replyMore specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.
replyComputing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.
replyThey should have done base64 encryption before the crc32. noobs
reply