[SRU] revert security-regression in Focal's libcrypto++

[Mark Esler]

[ Impact ]

Focal's libcrypto++ 5.6.4-9 regresses elliptic curve generation. Uploading
this version from Debian appears to have been a mistake.

This is a security regression, but was not published through the security
pocket.

As far as I am aware, Debian only packaged 5.6.4-9 in sid. Buster's latest
version is 5.6.4-8: the version immediately before the regression.

This version includes an _incomplete_ security patch for CVE-2019-14318
which breaks elliptic curve arithmetic.
 - https://github.com/weidai11/cryptopp/issues/869 states that this 5.6
   security patch is incomplete.
 - https://github.com/weidai11/cryptopp/issues/994#issuecomment-752399981
   states that the 2019 patch (which 5.6 and 8.3.0 received) has a
   regression.

See https://github.com/weidai11/cryptopp/issues/1269 and LP#2060564 for a
deeper exploration of this Ubuntu Focal issue.

The root cause of LP#1893934 appears to be caused by this regression.
  - As reported on the urbackup forums, rolling back to the previous
    version solves this crash.
 - https://forums.urbackup.org/t/urbackupsrv-crashes-on-ubuntu-20-04/

[ Test Plan ]

1. To test the regression:

Compile and use @ekera[@]github.com's PoC (attached as main.cpp):
```
$ g++ main.cpp -lcryptopp -o test
$ ./test
```

The PoC will report `X is *NOT* as expected.` on miscomputations.

See https://github.com/weidai11/cryptopp/issues/1269

Both Bionic 18.04.06 (libcrypto++ version 5.6.4-8) and Jammy 22.04.04
(libcrypto++ version 8.6.0-2ubuntu1) had the expected result. Focal fails
with 5.6.4-8. Rolling back the version allows the PoC test to past. Using
a version built with the attached debdiff also passes the PoC.

2. Package tests:

All package build tests pass regardless of the regression. Checking that
new failures do not occur is a sanity test.

To test builtin tests run: `cd /usr/share/crypto++ && cryptest v`

X. Note:

Unfortunately there are no autopkgtests.

`reverse-depends -r focal src:libcrypto++` includes five, possibly minor,
reverse dependencies.

libcrypto++ is mostly used as a dependency outside of the Ubuntu Archive.
i.e., we have low visibility on how this package is used.

I am hoping that the PoC and built in tests are enough to prove the sanity
of this security regression SRU.

[ Other Info ]

A big thank you to Martin Ekerå (@ekera[@]github.com) for identifying this
issue and writing a thorough bug report and PoC on GitHub \o/

This is my first SRU. I need a sponsor and help tagging on LP.

I have performed the Test Plan.

The fix solely involves on removing a d/patch file.

Removing the patch causes the following (expected) symbol changes in
./usr/lib/x86_64-linux-gnu/libcrypto++.so.6.0.0:
```
+CryptoPP::ProjectivePoint::~ProjectivePoint() W
+std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> >::~vector() W
+void std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> >::_M_realloc_insert<CryptoPP::ProjectivePoint const&>(__gnu_cxx::__normal_iterator<CryptoPP::ProjectivePoint*, std::vector<CryptoPP::ProjectivePoint, std::allocator<CryptoPP::ProjectivePoint> > >, CryptoPP::ProjectivePoint const&) W
```

[ Where problems could occur ]

Two systems both using software based on the regressed version of Crypto++
*could possibly* communicate through incorrectly generated keys together.
This seems unlikely and, if it is even possible, we should discourage or
even break the use of miscalculated elliptic curves.

A regression in reverting the regressed patch is possible.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "libcrypto++_5.6.4-9ubuntu1.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Mark Esler (eslerm)]

Marking this as invalid, since devel is not affected. Only focal is affected.

[Mark Esler (eslerm)]

Andreas asked that I re-verify that Ubuntu Security wishes to make this change through SRU. We do.

Since the regression was inherited from sid, it feels most appropriate to SRU a change into -updates. Also, since a working 5.6 patch for CVE-2019-14318 does not exist we do not have a fix for the security pocket.

This SRU needs a sponsor.

[Dan Bungert (dbungert)]

Hi Mark,

Note that I made a small tweak to the changelog to close this bug.

This looks mostly good to me. The symbol change may make this more interesting. I learned enough about abi-compliance-checker to do some analysis there and it claims that the ABI is unchanged, but we would benefit from a second set of eyeballs on that. If I have that detail incorrect, the rdeps would need rebuilds.

Uploading to Focal.

[Andreas Hasenack (ahasenack)]

I spent a long time trying to understand what happened with this CVE.

- upstream's first attempt at a fix, which misses fixing "leak on binary fields (EC2N class)": https://github.com/weidai11/cryptopp/issues/869
- it also introduced a regression, so besides an incomplete fix, it introduces a bug

- three regressions were filed upstream:
  - https://github.com/weidai11/cryptopp/issues/994
  - https://github.com/weidai11/cryptopp/issues/1269 (this last one specifically about the library on ubuntu)
  - https://github.com/weidai11/cryptopp/issues/878

- we also have 3 launchpad bugs about this: #2064751 (this one), #2060564, and #1893934. Shouldn't all of these be mentioned in the changelog?

Then it gets confusing. I'm finding multiple references across all these bugs about either a revert, or a partial revert, or a revert plus a fix elsewhere (specially when they mention version 8.3.0).

In https://github.com/weidai11/cryptopp/issues/878#issuecomment-753375057, there is a commit range: https://github.com/weidai11/cryptopp/compare/38cff9aa59f299f7d1e802e614edc205ee2965fb...5dfc7e1c27d2d3225257f1458f0a5b3e623d08e7

Is that the same as reverting the original CVE fix? Is there any option to actually fixing the CVE in 5.6.4?

The proposal here is plainly reverting the patch added in 5.6.4-9, which will reintroduce the CVE, correct?

[Robie Basak (racb)]

This upload is blocked pending discussion in relation to Andreas' question above.