| 2024-05-03 17:08:27 |
Mark Esler |
bug |
|
|
added bug |
| 2024-05-03 17:09:18 |
Mark Esler |
attachment added |
|
main.cpp https://bugs.launchpad.net/ubuntu/+source/libcrypto++/+bug/2064751/+attachment/5774479/+files/main.cpp |
|
| 2024-05-03 17:10:09 |
Mark Esler |
attachment added |
|
libcrypto++_5.6.4-9ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/+source/libcrypto++/+bug/2064751/+attachment/5774481/+files/libcrypto++_5.6.4-9ubuntu1.debdiff |
|
| 2024-05-03 17:10:33 |
Mark Esler |
nominated for series |
|
Ubuntu Focal |
|
| 2024-05-03 17:10:33 |
Mark Esler |
bug task added |
|
libcrypto++ (Ubuntu Focal) |
|
| 2024-05-03 17:37:45 |
Mark Esler |
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.
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 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. |
[ 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.
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. |
|
| 2024-05-03 19:08:37 |
Mark Esler |
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.
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. |
[ 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. |
|
| 2024-05-03 20:19:14 |
Ubuntu Foundations Team Bug Bot |
tags |
regression-update |
patch regression-update |
|
| 2024-05-03 20:19:20 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors |
