We recently learned that the NVD database entry for CVE-2021-36751 about the ciphertext malleability issue was updated: a CVSS vector and resultant score was added. Unfortunately, while this update was no doubt made with the best of intentions, we find that it does not do justice to the actual situation and cause unnecessary concern. In particular, the resultant CVSS score of 9.1 (“critical”) may raise a lot of concern for users, yet we believe this vastly overstates the actual severity. We propose a different CVSS vector which we think is more realistic and results in a score of 4.2 (“medium”).
Let’s analyse this CVSS vector. First we provide some context, about our product and then about the ciphertext malleability issue. After that, we can use this knowledge to look at the individual metrics of the CVSS vector.
DataVault and its related OEM software (for SANDISK, in the past also SONY and LEXAR) are primarily used to encrypt data on USB storage devices (USB sticks and SSDs). All OEM software exclusively works on vendor-specific USB devices; it will not encrypt data on other devices. ENC DataVault is also able to create and use Vaults on local laptop- or PC drives. The software is not aware or capable of working with network- or cloud storage. Cloud- or network use cases require additional effort from users and are not natively supported by our software. This makes the basis of our software work local-only. That means that the most common attack scenarios involve stealing or "borrowing" the USB storage device, PC or laptop where the Vault is stored. This type of attack scenario is what we assume for the rest of this analysis. For different scenarios, we urge readers to fill in the Environmental Score Metrics according to their own environment.
A ciphertext malleability weakness is a weakness where an attacker can manipulate the ciphertext and reliably make deliberate corresponding changes in the plaintext without knowing the key. In the case of DataVault and related products, this weakness exists because counter mode is used as a blockcipher mode. Counter (CTR) mode is highly efficient and simple to implement when you want to do random access on files, which is why it was selected in the first place.
In order to perform a ciphertext malleability attack, the attacker needs the following:
- A plaintext copy of the targeted files, or at least deep knowledge of the content and the position of the individual bits to be manipulated.
- Write access to the storage medium.
- In the most common attack scenarios, the user needs to trust and open the files after manipulation.
In practice, given that the software works local-only, this means that the most common attack scenarios require the opportunity and effort to steal or "borrow" the physical device, in addition to having a plaintext copy of at least one target file. But once those non-trivial conditions are fulfilled, a moderately technically skilled attacker can reliably perform this attack with ease.
Knowing this context we can take a look at NVD's original CVSS 3.0 vector. This vector is:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
The individual metrics have the following meaning:
- AV:N means the weakness is categorized as a network-exploitable weakness. However, the most common attack scenario requires physical access. We think it should be AV:P.
- AC:L means the weakness is categorized as a low-complexity to exploit, where there are no or few conditions that are beyond the attacker's control. Given how ciphertext malleability works, this assessment is debatable. While stealing or "borrowing" the device is often not trivial, the physical access requirement is essentially covered by the metric "AV:P” above. However, having access to some plaintext without having full access to the original Vault is not covered by AV:P and is certainly not a trivial condition. We think it should be AC:H.
- PR:N means the attacker does not need special permissions once they have physical control of the device. This is correct.
- UI:N means the attack does not require user interaction, which we consider correct. One might argue that this is not entirely true in "Evil Maid"-style attacks, where the device is "borrowed" without knowledge (and consent) of the victim, modified, then returned. In this case, it may be possible that the victim notices that something is off which can be seen as “user interaction” (e.g. device is placed differently in the room, laptop is closed while it was last left open, scratch marks from the attempts to open the device etc.). We think however that most users won't notice the difference or just shrug it off and use the device anyway. We consider "no user interaction needed" the best fit for this metric.
- S:U means in this case that the scope is limited to the Vault being attacked, and does not easily affect other components in the victim's IT landscape. This is correct.
- C:H means that the confidentiality impact is categorized as "high". This is not correct since the confidentiality is not in danger when a ciphertext malleability attack is performed. It only concerns integrity. We think it should be C:N.
- I:H means that the integrity impact is categorized as "high". This is correct.
- A:N means that the availability impact is categorized as "none". This is correct.
Summarizing, we propose the following CVSS 3.0 vector:
AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
This CVSS vector leads to an overall score of 4.2. In our opinion, this overall score much better represents the severity of the issue than the original CVSS vector.