| Summary: | SubtleCrypto.decrypt() - Decrypting with wrong AES-CBC key succeeds instead throwing an error | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Pavel Bednar <pavel.bednar> | ||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED INVALID | ||||||
| Severity: | Critical | CC: | jiewen_tan, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 13 | ||||||
| Hardware: | Mac | ||||||
| OS: | macOS 10.15 | ||||||
| Attachments: |
|
||||||
|
Description
Pavel Bednar
2020-05-12 04:38:46 PDT
That's the design of the AES-CBC. Decryptions are designed to fail silently. Otherwise, attackers don't even need to examine the content the decrypted message to determine if the brute force attack succeeds or not. For integration protection, either adding HMAC to your cipher or using AES-GCM. I cannot agree, few months it was working as expected. I dont see why decrypt method should behave inconsistently based on selected algorithm. AES-GCM in same repro throws an error. All major browsers throws an error (tested in Chrome, Firefox, Opera, Edge). Documentation says it should throw an error. Only webkit started to fail silently but just only for this particular algorithm. Unfortunately we are not able to upgrade AES-GCM or simply add HMAC since our custumers already have encrypted data in production and we have to maintain compatibility. (In reply to Pavel Bednar from comment #3) > I cannot agree, few months it was working as expected. I dont see why > decrypt method should behave inconsistently based on selected algorithm. > AES-GCM in same repro throws an error. All major browsers throws an error > (tested in Chrome, Firefox, Opera, Edge). Documentation says it should throw > an error. Only webkit started to fail silently but just only for this > particular algorithm. > > Unfortunately we are not able to upgrade AES-GCM or simply add HMAC since > our custumers already have encrypted data in production and we have to > maintain compatibility. If you think this is a regression, then please provide information on when it works and when it starts failing. (In reply to Pavel Bednar from comment #3) > I cannot agree, few months it was working as expected. I dont see why > decrypt method should behave inconsistently based on selected algorithm. > AES-GCM in same repro throws an error. All major browsers throws an error > (tested in Chrome, Firefox, Opera, Edge). Documentation says it should throw > an error. Only webkit started to fail silently but just only for this > particular algorithm. > > Unfortunately we are not able to upgrade AES-GCM or simply add HMAC since > our custumers already have encrypted data in production and we have to > maintain compatibility. BTW, MDM is not the spec. This is: https://www.w3.org/TR/WebCryptoAPI/#aes-cbc-operations. I don't think it suggests anything about throwing an error when decryptions fail. Ok, can you please explain me, why decrypt() behaves differently for AES-GCM ? Why this algorithm throws an error. Is is not the same vulnerability? (In reply to Pavel Bednar from comment #6) > Ok, can you please explain me, why decrypt() behaves differently for AES-GCM > ? Why this algorithm throws an error. Is is not the same vulnerability? AES-GCM throws exceptions because of integrity not decryption. It first checks the integrity of the cipher. If it fails, then it throws error. Once this point is passed, it behaves more or less the same as AES-CBC. |