Bug#1006169: bullseye-pu: package mbedtls/2.16.12-0+deb11u1

[Andrea Pappacoda]

Hi!

I'm bumping this thread because I believe that this has never reached
the debian-release mailing list, as the original report contained a big
debdiff and elbrus told me that reports with big attachments get
dropped by the mailing list. I'm not going to attach a diff in this
email, I'll do in another one so that this message doesn't get deleted.

I've been discussing this stable update with a couple of DDs at
Debconf, and while we're not 100% happy with how upstream polluted
their LTS branch with cosmetic changes we think that upgrading to the
latest 2.16 LTS version is worth it.

As I mentioned in the original report, the 2.16.12 (and also 2.16.11
and 2.16.10) release(s) fixes a couple of CVEs, but it also fixes a lot
of security issues that are not associated to any CVE, so
cherry-picking just a couple of commits wouldn't really be enough, and
fixing all of them would basically mean cherry-picking all non-cosmetic
changes.

To make reviewing easier, I've filtered the previous debdiff to
(mostly) only include non-cosmetic changes, with this command:

debdiff mbedtls_2.16.9-0.1.dsc mbedtls_2.16.12-0+deb11u1.dsc |
filterdiff -p 1 -x 'tests/*' -x 'visualc/*' -x 'programs/*' -x
'.travis.yml' -x '.gitignore' -x 'include/mbedtls/aes.h' -x
'include/mbedtls/arc4.h' -x 'include/mbedtls/aria.h' -x
'include/mbedtls/asn1.h' -x include/mbedtls/base64.h -x
include/mbedtls/bignum.h -x include/mbedtls/blowfish.h -x
include/mbedtls/camellia.h -x include/mbedtls/ccm.h -x
include/mbedtls/chacha20.h -x include/mbedtls/chachapoly.h -x
include/mbedtls/cipher.h -x include/mbedtls/cmac.h -x
include/mbedtls/config.h -x include/mbedtls/ctr_drbg.h -x
include/mbedtls/des.h -x include/mbedtls/dhm.h -x
include/mbedtls/entropy.h -x include/mbedtls/gcm.h -x
include/mbedtls/hkdf.h -x include/mbedtls/hmac_drbg.h -x
include/mbedtls/md2.h -x include/mbedtls/md4.h -x include/mbedtls/md5.h
-x include/mbedtls/md.h -x include/mbedtls/net_sockets.h -x
include/mbedtls/oid.h -x include/mbedtls/padlock.h -x
include/mbedtls/pem.h -x include/mbedtls/pkcs12.h -x
include/mbedtls/pkcs5.h -x include/mbedtls/pk.h -x
include/mbedtls/platform.h -x include/mbedtls/poly1305.h -x
include/mbedtls/ripemd160.h -x include/mbedtls/rsa.h -x
include/mbedtls/sha1.h -x include/mbedtls/sha256.h -x
include/mbedtls/sha512.h -x include/mbedtls/ssl.h -x
include/mbedtls/ssl_ticket.h -x include/mbedtls/threading.h -x
include/mbedtls/x509.h -x include/mbedtls/x509_crt.h -x
include/mbedtls/xtea.h -x Makefile -x '*/Makefile'

Please take a look at the original bug report, as it contains a lot of
additional information. Thanks!

[Jonathan Wiltshire]

Control: tag -1 moreinfo

Hi,

Sorry about the long delay to this.

This upstream release only contains fixes anyway,
+Default behavior changes
+ * In mbedtls_rsa_context objects, the ver field was formerly documented
+ as always 0. It is now reserved for internal purposes and may take
+ different values.
+Changes
+ * Improve the performance of base64 constant-flow code. The result is still
+ slower than the original non-constant-flow implementation, but much faster
+ than the previous constant-flow implementation. Fixes #4814.

(not a functional change, but one with some risk).

In any case, I'm not sure that CVE-2021-44732 is as serious as you make
out. It's impactful yes, but doesn't the out-of-memory condition mean
another exploit or outrageous good fortune is also required to trigger
this?

Thanks,

[Andrea Pappacoda]

Hi Jonathan!

Post by Jonathan Wiltshire
Sorry about the long delay to this.

No worries :)

Post by Jonathan Wiltshire

This upstream release only contains fixes anyway,
+Default behavior changes
+ * In mbedtls_rsa_context objects, the ver field was formerly documented
+ as always 0. It is now reserved for internal purposes and may take
+ different values.

Yeah, back when I was working on this I was a bit scared by this
changelog entry, but if I recall correctly there was nothing that was
actually depending on this "ver" field. And I honestly cannot think of
useful piece of user code that would depend on having a certain struct
member being zero.

Post by Jonathan Wiltshire

+Changes
+ * Improve the performance of base64 constant-flow code. The result is still
+ slower than the original non-constant-flow implementation, but much faster
+ than the previous constant-flow implementation. Fixes #4814.

(not a functional change, but one with some risk).

This is a performance improvement relative to an MbedTLS 2.16.10
regression. In MbedTLS 2.16.10, some base64 code was made constant-flow,
leading to a noticeable performance hit. In MbedTLS 2.16.12, this
constant-flow code was improved. This isn't relevant for us though,
since Debian Bullseye ships 2.16.9, i.e. the non-constant-flow
implementation. Since a secure implementation needs to be constant-flow,
we might as well choose the faster constant-flow one :)

Post by Jonathan Wiltshire
In any case, I'm not sure that CVE-2021-44732 is as serious as you make
out. It's impactful yes, but doesn't the out-of-memory condition mean
another exploit or outrageous good fortune is also required to trigger
this?

I honestly do not remember what this CVE is about, but I see it has
a 9.8 CRITICAL score, so it might make sense to fix it anyway. I know
CVE scores are often a joke, but still.

Would you be able to accept this proposed update into bullseye? If yes,
I could resume my work on this.

Thanks! Bye :)

[Andrea Pappacoda]

Control: tag -1 wontfix

We regret that your request could not be reviewed in time for the
final point release of bullseye (11.11).

That's sad. I've put a lot of efforts in this over a long period of
time, but I'm happy I've learned someting. Hope it'll go better next
time!