[Bug 2064751] Re: [SRU] revert security-regression in Focal's libcrypto++

[Dan Bungert]

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.

** Changed in: libcrypto++ (Ubuntu Focal)
     Assignee: Dan Bungert (dbungert) => (unassigned)

** Changed in: libcrypto++ (Ubuntu Focal)
       Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2064751

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

Status in libcrypto++ package in Ubuntu:
  Invalid
Status in libcrypto++ source package in Focal:
  Fix Committed

Bug description:
  [ 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libcrypto++/+bug/2064751/+subscriptions