Bug 2005874
Summary: | Limit protocols supported by (lib)curl-minimal for security hardening | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Jan Pazdziora <jpazdziora> |
Component: | curl | Assignee: | Kamil Dudka <kdudka> |
Status: | CLOSED ERRATA | QA Contact: | Daniel Rusek <drusek> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 9.0 | CC: | fedoraproject, jpazdziora, kdudka |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | curl-7.76.1-14.el9 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-05-17 15:47:48 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jan Pazdziora
2021-09-20 11:43:40 UTC
As for Features, GSS-API, SPNEGO, Kerberos, HTTP2, IDN, IPv6, Largefile, and SSL (in case that means TLS and not SSL) should likely stay. The proposal makes sense to me. I am not sure about FTP though. The protocol still seems to be used. Approximately 30% users of upstream curl claim to use FTP, according to the following survey (see page 9): https://daniel.haxx.se/media/curl-user-poll-2020-analysis.pdf We can try removing it from curl-minimal anyway. However, if more people upgrade to libcurl-full because of FTP, it will make this change less effective. I have prepared a Fedora pull request (so far with FTP kept): https://src.fedoraproject.org/rpms/curl/pull-request/10 ... and Fedora COPR based on the above pull request: https://copr.fedorainfracloud.org/coprs/kdudka/curl-minimal/ Some feedback would be appreciated. I gave it a try on Fedora 34 after doing ( cd /etc/yum.repos.d && curl -O https://copr.fedorainfracloud.org/coprs/kdudka/curl-minimal/repo/fedora-34/kdudka-curl-minimal-fedora-34.repo ) dnf install -y --setopt=install_weak_deps=False --allowerasing libcurl-minimal.$( rpm --eval '%{_arch}' ) curl-minimal.$( rpm --eval '%{_arch}' ) which gave me libcurl-minimal-7.79.0-5.fc34.x86_64 curl-minimal-7.79.0-5.fc34.x86_64 and it works as expected. The protocols reported are # curl --version curl 7.79.0 (x86_64-redhat-linux-gnu) libcurl/7.79.0 OpenSSL/1.1.1l-fips zlib/1.2.11 nghttp2/1.43.0 Release-Date: 2021-09-15 Protocols: file ftp ftps http https Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz SPNEGO SSL UnixSockets Thank you for testing it! I went ahead and put the change to curl-7.79.1-2.fc36: https://src.fedoraproject.org/rpms/curl/c/c2f61abc1cb764ad2cbf865d4e61da84c55a8183?branch=rawhide https://src.fedoraproject.org/rpms/curl/c/54117120e4ddaabc1d456a8857552625bffa81b9?branch=rawhide https://src.fedoraproject.org/rpms/curl/c/5ebead952bed4dce9ceefb8fc307b168b9154ad6?branch=rawhide https://src.fedoraproject.org/rpms/curl/c/d4c5b54bf3629397059785612bf16cb2e63999c9?branch=rawhide Probably worth keeping hsts since it's a security feature. I have no strong opinion about HSTS. Most users will not use it because the feature needs to be explicitly enabled at run-time. PSL is also a security feature and we do not want it in libcurl-minimal, although PSL implies a big chain of run-time dependencies, unlike HSTS. Jan, what do you think about HSTS? Should we put it back to libcurl-minimal in Fedora? I am not sure about RHEL though. The feature was considered experimental by curl upstream not so long ago: https://github.com/curl/curl/pull/6700 Anyway, thank you for pointing it out! Now I see that the fix for this bug enabled HSTS in libcurl-full in RHEL-9 as a side effect (unlike in Fedora, where it had already been enabled). I'm confused -- I don't see HSTS listed on the --version output of the full curl either. Is that currently not present in either, or present in the non-minimal curl, just not advertized? Where does curl store the information that the server returned Strict-Transport-Security before? Is it persisted somewhere, or just kept in runtime memory? (In reply to Jan Pazdziora from comment #10) > I'm confused -- I don't see HSTS listed on the --version output of the full > curl either. Is that currently not present in either, or present in the > non-minimal curl, just not advertized? Which build of curl did you try it with? curl-7.76.1-12.el9 has HSTS disabled for both the variants. curl-7.76.1-13.el9 has HSTS enabled in libcurl-full only (more or less unintentionally, see comment #9). > Where does curl store the information that the server returned > Strict-Transport-Security before? Is it persisted somewhere, or just kept in > runtime memory? I have not tried HSTS myself but libcurl seems to support both the variants. CURLOPT_HSTS or `curl --hsts ...` specifies a file to read/write the HSTS cache from/to. CURLOPT_HSTS_CTRL can enable in-memory HSTS cache. CURLOPT_HSTS{READ,WRITE}FUNCTION can be used to set custom callbacks to read/write the cache. The current curl/HSTS documentation [1] says: Added as experimental in curl 7.74.0. Supported "for real" since 7.77.0. We have curl-7.76.1 in RHEL-9. [1] https://curl.se/docs/hsts.html Ah, I have curl-7.76.1-12.el9.s390x here, so one release older. I think it's really up-to-you to decide if you want to support the experimental feature in RHEL 9, and be potentially on the hook of fixing it if needed. I am a bit scared now. Let's disable HSTS completely in RHEL-9 for now and re-enable it in libcurl-minimal in Fedora only. Thank you both for feedback! I have re-enabled HSTS in curl-7.79.1-3.fc36 in Fedora: https://src.fedoraproject.org/rpms/curl/c/94a3e807 I double-checked the changes in libcurl-full between curl-7.76.1-1{2,3}.el9 and HSTS was the only difference, which is going to be reverted in a subsequent build. (In reply to Kamil Dudka from comment #15) > I double-checked the changes in libcurl-full between curl-7.76.1-1{2,3}.el9 > and HSTS was the only difference, which is going to be reverted in a > subsequent build. CentOS Stream merge request: https://gitlab.com/redhat/centos-stream/rpms/curl/-/merge_requests/13 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: curl), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:3909 |