Bugzilla

Thanks. I confirmed both outcomes from the report.

To exploit we need two things then: 1) multi-part encryption, and 2) the property that a call can be made with `*pulEncryptedPartLen` (`maxout`) of less than one block, via attacker-control or a programming error. Webcrypto is not affected as neither condition holds. This leaves the following notable paths (among others that are more trivially unexploitable). 

1) [ssl3_MACEncryptRecord](https://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#2186): If p1Len is less than 256, it is moved to `oddLen` and encrypted with p2 (where `maxout` will be at least "MAC bytes" long). This should be safe.
2) [SRTP](https://searchfox.org/mozilla-central/source/netwerk/srtp/src/crypto/cipher/aes_icm_nss.c#308) calls this function for both encrypt and decrypt, but uses in-place operations (where outLen == inLen), so the arbitrary overwrite is not possible (`*pulEncryptedPartLen  < BLOCK_SIZE && *pulEncryptedPartLen == ulPartLen`). This still leaves the potential for an *up-to-blocksize* overrun. 

I'm only seeing a Firefox exploit path through #2, but I'd label this sec-high as: 1)  #2 suggests this is remotely exploitable since it's called to decrypt, and 2) the bug lies in a general-purpose function with many callers. If one fails to protect (or session is inappropriately reused), we could well be vulnerable to the arbitrary overwrite case. 

Let  me know if my analysis missed anything.

Thanks. I confirmed both outcomes from the report.

To exploit we need two things then: 1) multi-part encryption, and 2) the property that a call can be made with `*pulEncryptedPartLen` (`maxout`) of less than one block, via attacker-control or a programming error. Webcrypto is not affected as neither condition holds. This leaves the following notable paths (among others that are more trivially unexploitable). 

1) [ssl3_MACEncryptRecord](https://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#2186): If `p1Len` is less than 256, it is moved to `oddLen` and encrypted with `p2` (where `maxout` will be at least "MAC bytes" long). This should be safe.
2) [SRTP](https://searchfox.org/mozilla-central/source/netwerk/srtp/src/crypto/cipher/aes_icm_nss.c#308) calls this function for both encrypt and decrypt, but uses in-place operations (where outLen == inLen), so the arbitrary overwrite is not possible (`*pulEncryptedPartLen  < BLOCK_SIZE && *pulEncryptedPartLen == ulPartLen`). This still leaves the potential for an *up-to-blocksize* overrun. 

I'm only seeing a Firefox exploit path through #2, but I'd label this sec-high as: 1)  #2 suggests this is remotely exploitable since it's called to decrypt, and 2) the bug lies in a general-purpose function with many callers. If one fails to protect (or session is inappropriately reused), we could well be vulnerable to the arbitrary overwrite case. 

Let  me know if my analysis missed anything.