backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openssl (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Jammy |
In Progress
|
High
|
Adrien Nader | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
=== SRU information ===
[Meta]
(This bug was once the fourth in a series of bugs grouped for a single SRU, with
the "central" bug with the global information and debdiff being http://
[Impact]
Decryption for Blowfish with OFB and CFB modes fails due to using a key shorter than expected by default.
Encryption will also use a key shorter than expected.
Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead to decryption issues.
[Test plan]
On Focal, run the following and copy the output to your clipboard
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}" | openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
tar c pouet.bf-* | xz | base64 -w 60
You can also run this on Lunar or Mantic if you add "-provider legacy -provider default" to the "openssl enc" invocation.
On Jammy, run the following and paste your clipboard
base64 -d | xz -d | tar x
for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; done
Only "Test with bf-cbc" and "Test with bf-ecb" will be properly decrypted: the other two will result in garbage on screen.
Here is the result of the enc + tar + xz + base64 on Focal (works with Lunar/Mantic too but you need to added ):
/Td6WFoAAAT
8pbqQTu5j8S
hCgU1BIr/
m9CJMzi6LQO
D/4AJikrU9i
ecFb0mACF/
GL64VhX568O
AoBQAACjzq5
Here is the same but from Jammy if you want to test encryption on Jammy and decryption on Lunar/Mantic:
/Td6WFoAAAT
8pbqQTu5j8S
HySjdDOFRfj
jrFv871QAbm
2qQf60hP/
k0nEYlDbl5/
/5J4layZdFl
1AABrQKAUAA
The contents are expected to be different due to the use of randomness. Don't try to compare the base64 outputs: I'm only using them to ease testing across containers.
[Where problems could occur]
This patch makes openssl match the documented default (see "man openssl-enc" and search for "Blowfish" for instance) and fixes decryption from an up-to-date Jammy to pretty much everything else, but it also create an issue for data encrypted on Jammy without this patch and Jammy with this patch.
There are two possible cases: encrypted data being streamed across this boundary or data at rest being transferred or read later.
Streaming is probably not an issue in practice because it's rather the current situation that has been an issue and it's easy to remedy by updating everything (which is relatively few machines since that's only Jammy and not any other OS or distribution).
Data at rest is more annoying since updating Jammy will make it impossible to read the data again without updates to other pieces of software. That sounds like a really bad thing and it kind of is but at the same, the benefits are much larger than the issues. Indeed, there is already an incompatibility at the moment between Jammy and everything else and the more time passes by, the more such problematic files can be created. Luckily very few people are using blowfish nowadays and it's not even enabled by default anymore in openssl. Moreover the software update to work around the issue should be a single API call which is documented in the upstream bug report ( https:/
[Patches]
The patches come directly from upstream and apply cleanly.
https:/
* https:/
* https:/
=== Original description ===
OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes"
https:/
as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic).
Could this fix be backported to libssl3 in Jammy?
Changed in openssl (Ubuntu): | |
status: | New → Confirmed |
Changed in openssl (Ubuntu Jammy): | |
status: | New → Confirmed |
Changed in openssl (Ubuntu): | |
importance: | Undecided → Medium |
Changed in openssl (Ubuntu Jammy): | |
importance: | Undecided → Medium |
Changed in openssl (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in openssl (Ubuntu Jammy): | |
importance: | Medium → High |
Changed in openssl (Ubuntu Jammy): | |
status: | Triaged → In Progress |
Changed in openssl (Ubuntu Lunar): | |
status: | New → Fix Released |
Changed in openssl (Ubuntu Jammy): | |
milestone: | none → jammy-updates |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
If I read upstream correctly, a fix for this regression was put in master over a year ago (May 2022). Any update to when this will be rolled out on Jammy/current LTS?