You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There have been a few instances of this reported through security channels. Given that this is a fairly low-risk vulnerability (it isn't a direct vulnerability but could be used by another vulnerability), I'm reporting is as a regular issue.
The idea is that there are several mechanisms in mcuboot, where an attacker could inject data into the upgrade slot that would then be copied into the primary slot when the upgrade is used. These areas are not part of the data where the signature is checked, and could allow for an ROP attack to make use of the additional code.
For many uses of mcuboot, this isn't an additional risk, as the upgrade slot is also in addressable flash, and is likely also executable. One mitigation of this would be to configure an MPU to prevent execution from the upgrade slot. In the case of an external slot 1, it may be less likely to be executed, and code placed.
There are several potential ways this data could be injected:
Data after the TLV. The current code appears to copy the entire sector after the TLV, which could result in some amount of data being copied.
Various TLV entries. There are currently no checks on the TLV with custom and other entries placed into the unprotected TLV section. These could contain code.
The text was updated successfully, but these errors were encountered:
There have been a few instances of this reported through security channels. Given that this is a fairly low-risk vulnerability (it isn't a direct vulnerability but could be used by another vulnerability), I'm reporting is as a regular issue.
The idea is that there are several mechanisms in mcuboot, where an attacker could inject data into the upgrade slot that would then be copied into the primary slot when the upgrade is used. These areas are not part of the data where the signature is checked, and could allow for an ROP attack to make use of the additional code.
For many uses of mcuboot, this isn't an additional risk, as the upgrade slot is also in addressable flash, and is likely also executable. One mitigation of this would be to configure an MPU to prevent execution from the upgrade slot. In the case of an external slot 1, it may be less likely to be executed, and code placed.
There are several potential ways this data could be injected:
The text was updated successfully, but these errors were encountered: