On Sat, Nov 11, 2023 at 08:51:30AM +0100, Salvatore Bonaccorso wrote: > The following vulnerability was published for esptool. > > CVE-2023-46894[0]: > | An issue discovered in esptool 4.6.2 allows attackers to view > | sensitive information via weak cryptographic algorithm. > > If I undestand the upstream discussion[1] correctly this is not > something hich is going to be fixed until the oldest earliest chips > are not supported anymore. So this bug is merely for documentation > purpose and can be closed once this support vanishes (or feel free to > aswer the above, we might then simply mark it as unimportant in the > security-tracker.
I'd go one step further, and express that IMHO this is not a security vulnerability and that it shouldn't have been assigned a CVE in the first place. As you mentioned, based on upstream's comment above, old revisions of one of the supported chipsets were using AES ECB for secure boot and flash encryption, but newer ones have switched to newer cryptographic algorithms. esptool has kept support for the older algorithms, in order to keep the ability to work with older revisions of the hardware. Obviously software shouldn't default or recommend broken cryptographic ciphers, when it can be avoided. But I don't think it constitutes a vulnerability to merely implement them, when they are used to interface with the world as it exists outside of your software, such as for compatibility with hardware, network protocols etc. This is the equivalent of saying that coreutils is vulnerable because it ships md5sum, an implementation of a broken digest, or that browsers need a CVE for supporting older TLS ciphers, etc. Or perhaps even that python-cryptography itself needs a CVE because it ships an implementation of AES-ECB (or 3DES or whatever) :) Let me know if you disagree! Keeping the bug open until I hear from you. Thanks, Faidon
