Regression finding system certificates
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| curl (Debian) |
Fix Released
|
Unknown
|
|||
| curl (Ubuntu) |
Fix Released
|
High
|
Sergio Durigan Junior | ||
| Lunar |
Fix Released
|
High
|
Sergio Durigan Junior | ||
| Mantic |
Fix Released
|
High
|
Sergio Durigan Junior | ||
Bug Description
[ Impact ]
Users of applications that link against libcurl's NSS flavour might experience issues when trying to contact HTTPS servers. This can lead to scenarios where the application is unable to connect.
[ Test Plan ]
First, let's verify that the GNUTLS flavour of libcurl does the right thing:
$ lxc launch ubuntu-daily:lunar curl-bug2016439
$ lxc shell curl-bug2016439
# apt update && apt install -y libcurl4-gnutls-dev gcc
# cat > curl-test.c << __EOF__
#include <stdio.h>
#include <curl/curl.h>
int main(void)
{
CURL *curl;
CURLcode res;
curl = curl_easy_init();
if(curl) {
curl_
/* example.com is redirected, so we tell libcurl to follow redirection */
curl_
/* Perform the request, res will get the return code */
res = curl_easy_
/* Check for errors */
if(res != CURLE_OK)
fprintf(
/* always cleanup */
curl_
}
return 0;
}
__EOF__
# gcc curl-test.c -o curl-test -lcurl
# ./curl-test
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
#
You should see the HTML dump of example.com. Now, let's install the NSS flavour of libcurl and recompile the test program against it:
# apt install -y libcurl4-nss-dev
# gcc curl-test.c -o curl-test -lcurl
# ./curl-test
curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
As we can see, there was an error when validating the TLS certificate.
[ Where problems could occur ]
The adjustment needed to the downstream patch is pretty simple and has been tested extensively. The original reporter mentioned that the issue did not happen before this patch was applied, so in the unlikely event of a regression the best route would be to revert the patch entirely.
[ More Info ]
This happens because of an error in one of our patches (authored by me) to teach libcurl where to properly find libnsspem.so and libnssckbi.so. The problem is that libnsspem.so is installed under /usr/lib/
[ Original Description ]
[ Clone of https:/
Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:
curl (7.88.1-4) unstable; urgency=medium
* d/p/Use-
Prepend "/nss/" before the library name.
Before the change to the load path, curl could find
/lib/x86_
/lib/x86_
reverse.
libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.
Here is a way to test the regression:
debbisect -v --cache=./cache \
--depends=
\
20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https:/
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/
"'
| Changed in curl (Debian): | |
| status: | Unknown → Fix Released |
| tags: | added: server-todo |
| description: | updated |
| Changed in curl (Ubuntu): | |
| status: | Triaged → In Progress |
| description: | updated |
| Andreas Hasenack (ahasenack) wrote | #1 |
| Andreas Hasenack (ahasenack) wrote | #2 |
| Changed in curl (Ubuntu Lunar): | |
| assignee: | nobody → Sergio Durigan Junior (sergiodj) |
| importance: | Undecided → High |
| status: | New → In Progress |
| Andreas Hasenack (ahasenack) wrote | #3 |
| Changed in curl (Ubuntu Lunar): | |
| status: | In Progress → Fix Committed |
| tags: | added: verification-needed verification-needed-lunar |
| Andreas Hasenack (ahasenack) wrote Please test proposed package | #4 |
| Sergio Durigan Junior (sergiodj) wrote | #5 |
| Sergio Durigan Junior (sergiodj) wrote | #6 |
| tags: |
added: verification-done verification-done-lunar removed: verification-needed verification-needed-lunar |
| Changed in curl (Ubuntu Mantic): | |
| status: | In Progress → Fix Released |
| Ubuntu SRU Bot (ubuntu-sru-bot) wrote Autopkgtest regression report (curl/7.88.1-8ubuntu2) | #7 |
| Sergio Durigan Junior (sergiodj) wrote | #8 |
| Andreas Hasenack (ahasenack) wrote | #9 |
| Launchpad Janitor (janitor) wrote | #10 |
| Changed in curl (Ubuntu Lunar): | |
| status: | Fix Committed → Fix Released |
| Andreas Hasenack (ahasenack) wrote Update Released | #11 |
As I understand it, libnsspem.so is the one in the "wrong" place:
/usr/lib/
A quick apt-file search on lunar shows that is the only package that puts something in /usr/lib/$ARCH/nss.
I appended this config to my ~/.pki/
library=
name=PEM_plugin
And ran this test command with strace:
certutil -d ~/.pki/nssdb -U
It shows the search path for the library:
143458 openat(AT_FDCWD, "/lib/x86_
143458 openat(AT_FDCWD, "/usr/lib/
143458 openat(AT_FDCWD, "/lib/libnsspem
143458 openat(AT_FDCWD, "/usr/lib/
So yes, /usr/lib/$ARCH/nss is not searched for. Which means it's an odd placement choice decision from the src:nss-pem package. Or maybe src:nss should include that nss/ subdirectory in its search path.
In any case, back to the current bug.
It looks like a minimal patch would be to leave libnssckbi.so alone, as that will be found in the standard paths if I define it without an absolute path in pkcs11.txt:
library=
name=Mozilla Root Certs
NSS=trustOrde
And strace:
143993 openat(AT_FDCWD, "/lib/x86_
So how about just patching the libnsspem.so path? And reverting the change to the
`static const char *trust_library` path all the way back so it's just "libnssckbi.so"?
On a second note, has this been tested in other architectures, to be sure the _DEB_HOST_ARCH replacement is correct there as well? I'm thinking ppc64el vs ppc64le, for example, and whether the linux-gnu suffix is always used correctly.