Updater - fixed signature verification for compressed binaries #9109
Conversation
|
...or it can be swapped with u8 flashRead variant that does this? The gist of the issue here is that flashRead cannot use unaligned flash size, which fails? |
Yes.
If there is one that would also work. EDIT: yep looks promising, let me test it. |
|
So far it seems like @mcspr's take on this is correct, simply dropping the I'm somewhat inexperienced with pull requests on such a large project, what's the next step here? |
Your last commit is enough. |
|
just realised that the |
This reverts commit a6fd582.
|
@mcspr thank you for pointing it out |
mcspr
changed the title
|
tnx! |
…66#9109) Previously, Arduino Core attempted to read from flash memory without proper consideration for the 4-byte alignment requirement when calculating the hash for the signature verification. This did not present an issue when uncompressed binaries are checked as all compiled binaries are 4-aligned (unconfirmed, just an educated guess), and signature verification appears to work well in these cases. When uploading a compressed binary (based on this) the gzip algorithm makes no attempt to produce a 4-aligned file. The rest of the signing results in a valid signed binary regardless, however when calculating the hash for the verification process there is a ~75% chance that the hash will include some bytes from the signature, thus compromising the whole signature verification process. editorial note: ESP.flashRead for u8 arrays (aka byte arrays) was already updated to properly handle both aligned and unaligned target buffer and / or length, while u32 expects that its arguments are already aligned. Since array pointer in Updater is already aligned, this properly handles unaligned size case.
Overview
This pull request introduces a fix to the signature verification, ensuring that the hash for compressed signed binaries is correctly calculated.
Problem Description
Previously, Arduino Core attempted to read from flash memory without proper consideration for the 4-byte alignment requirement when calculating the hash for the signature verification. This did not present an issue when uncompressed binaries are checked as all compiled binaries are 4-aligned (unconfirmed, just an educated guess), and signature verification appears to work well in these cases.
When uploading a compressed binary (based on this) the gzip algorithm makes no attempt to produce a 4-aligned file. The rest of the signing results in a valid signed binary regardless, however when calculating the hash for the verification process there is a ~75% chance that the hash will include some bytes from the signature, thus compromising the whole signature verification process.
Solution