-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification regarding the curl version in your Docker image (CVE-2023-38545) #2420
Comments
Hi @mig5, thanks for pointing this out. Reminds me that sometime back I thought the best would be a trivy check in CI. Did that manually now though (CVE DB is recent): In fact the curl release date sounds fishy though. One possibility would be to clarify the package from the vendor in the repo or I'll get back later on this |
TL;DR: curl in the docker images wasn't designed to accept socks5 proxy commands and in fact does not do so Quick look at the code: The arguments for curl in testssl.sh are partly user determinable only: It depends solely on the PROXYIP variable whose input in turn is being strongly validated: Despite that it can't hurt to look at the image and find out why curl probably hasn't been updated. |
A Leap 15.4 system (no container) looked like it was patched ~a week ago: The leap image from the repo however is not up to date. That would be no problem but...
Now comes the first zypper command from Dockerfile (leaving out the options):
From the repo it's old:
Here comes the install command as in the Dockerfile which waits for a prompt despite
All is fine if one just allows deinstallation of util-linux:
@polarathene : can we just remove util-linux w/o affecting the image? |
Also it looks to me like the EOL date is immanent: I would just switch to 15.5 . |
I doubt they will have patched the specific curl vulnerability a week ago as that would have broken the embargo (the curl vuln was only announced to Linux distributions on Wednesday this week). But it is true that often most OSs don't change the actual version number when they patch, they just apply the patch, so the version number might not be enough to go on. I don't know about SuSE but usually there are security bulletins/mailing lists that mention security updates, and the corrected SuSE-specific version number for curl (e.g in the package metadata) would be mentioned there.
Unfortunately with this vulnerability, it is not the input of the SOCKS parameters that is the problem (and the SOCKS proxy doesn't even need to be malicious) - it's that if using a SOCKS proxy (even a friendly one), the URL that you are accessing, if that turns out to be maliciously controlled, it can cause remote code execution on the client that requested it. Anyway, glad to have got it on your radar, I imagine the update will trickle down from the parent image. |
IIRC I should have documented the need of each package somewhere in the past contributions to Lines 29 to 34 in b21c5ee
If you don't use busybox, the size will go up which was a concern for you at the time vs the Alpine image size. Another alternative was to use the IMO you could adjust the That said, I had identified some compatibility issues with the suse base paired with the Fedora didn't have those concerns for installing affected packages, but I believe was a fair bit larger as a base image due to less granular packages (in particular for
I assume that's not happening during the image build, which would then probably be the difference of using
I'm curious what happens in the
I have heard that there may be a There was a recent announcement of a new offering called SlowRoll, which is meant to be a slower release snapshot of TumbleWeed. It is aimed at releasing every 1-2 months with bugfixes and CVE backports AFAIK. Might be worthwhile to switch to that? EDIT: I don't see any offering on DockerHub or the SUSE container registry. Might not be offered as a base image, there are container focused images like Upgrading to |
Also possibly worth noting, I believe I raised this concern in the past: testssl.sh/.github/workflows/docker-3.2.yml Lines 58 to 59 in b21c5ee
The caching is useful for speeding up CI builds of the image, but if you don't have a scheduled build (eg: weekly) that ignores the cache and uploads the new cache, then you may have builds with the base image cached until that cache becomes stale / removed. There is a scheduled build workflow (only valid for Alternatively you could probably remove the build Line 6 in b21c5ee
and have one of those dependency actions open PRs managing updates to a pinned digest instead of tag. Either way, users won't get the update though if they just pull the same tag and a local copy exists, despite different digests. They have to force pull ( |
The changelog says so. I suppose they got the patch before. Strange because Debian was later. Maybe it has something to do that leap 15.4 is coupled to SLES 15 SP4 (suse linux enterprise 15, service pack 4). |
done via PR #2423 |
For opensuse/sles and RHEL+clones you can't tell by the version banner. That's a thing where some pen testing tools and n00bs stumble over when doing banner grabbing remotely. But locally as for Debian packets you have the version of the package and in addition for RPMs there's a changelog included (rpm -qi --changelog) -- see above. |
Slowrool is IMO still rolling too fast. I am sick of Tumbleweed on one end device -- not bc of suse -- but because of recent Linux changes which made one end device unusable (wireless doesn't work on one access point, hibernation doesn't work, somtimes even not suspend, ...). Also if that has zero to do with the docker image: I rather prefer stability for this project. |
There were some discussions in #2420 whether the zypper install commend worked as intended. While there's liitle doubt that those packages weren't installed this PR makes really sure that this is the case. Also it does an update via ``zypper up`` as the image provided from dockerhub seemed to be somewhat behind.
Long story short:
More see PR #2424. Thus I am closing this. Any improvements discussions are welcome though in a separate issue/PR> |
? |
@polarathene : you didn't get my point here. I am copying from above:
|
I did as I'm referencing what you changed in the PR. Please pay attention to what my comment stated. $ docker run --rm -it opensuse/leap:15.5 bash
# Setup default options for commands, and refresh repos + auto import gpg keys:
$ export ZYPPER_OPTIONS=( --releasever 15.5 --installroot /rootfs --cache-dir /tmp/cache/zypper )
$ zypper "${ZYPPER_OPTIONS[@]}" --gpg-auto-import-keys refresh # Optional removing the repos not in use:
$ zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh
---+-----------------------------+---------------------------------------------+---------+-----------+--------
1 | repo-backports-debug-update | Update repository with updates for openSU-> | No | ---- | ----
2 | repo-backports-update | Update repository of openSUSE Backports | Yes | ( p) Yes | Yes
3 | repo-debug | Debug Repository | No | ---- | ----
4 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ----
5 | repo-debug-update | Update Repository (Debug) | No | ---- | ----
6 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ----
7 | repo-non-oss | Non-OSS Repository | Yes | ( p) Yes | Yes
8 | repo-openh264 | Open H.264 Codec (openSUSE Leap) | Yes | ( p) Yes | Yes
9 | repo-oss | Main Repository | Yes | ( p) Yes | Yes
10 | repo-sle-debug-update | Update repository with debuginfo for upda-> | No | ---- | ----
11 | repo-sle-update | Update repository with updates from SUSE -> | Yes | ( p) Yes | Yes
12 | repo-source | Source Repository | No | ---- | ----
13 | repo-update | Main Update Repository | Yes | ( p) Yes | Yes
14 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | ( p) Yes | Yes
$ zypper removerepo repo-openh264 repo-non-oss repo-update-non-oss
Removing repository 'Non-OSS Repository' ...............................................................[done]
Repository 'Non-OSS Repository' has been removed.
Removing repository 'Open H.264 Codec (openSUSE Leap)' .................................................[done]
Repository 'Open H.264 Codec (openSUSE Leap)' has been removed.
Removing repository 'Update Repository (Non-Oss)' ......................................................[done]
Repository 'Update Repository (Non-Oss)' has been removed. # The package install (no conflict exists with `util-linux`):
$ zypper "${ZYPPER_OPTIONS[@]}" --non-interactive install --download-in-advance --no-recommends \
bash procps grep gawk sed coreutils busybox-util-linux busybox-vi ldns libidn2-0 socat openssl curl
Warning: Enforced setting: $releasever=15.5
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 68 NEW packages are going to be installed:
bash bash-sh busybox busybox-util-linux busybox-vi coreutils crypto-policies curl filesystem gawk glibc grep info krb5 ldns libacl1 libattr1 libbrotlicommon1 libbrotlidec1 libbz2-1 libcap2 libcom_err2 libcrypt1
libcurl4 libdbus-1-3 libgcc_s1 libgcrypt20 libgmp10 libgpg-error0 libidn2-0 libjitterentropy3 libkeyutils1
libldap-2_4-2 libldap-data libldns2 liblz4-1 liblzma5 libncurses6 libnghttp2-14 libnl-config libnl3-200
libopenssl1_1 libpcap1 libpcre1 libprocps7 libpsl5 libreadline7 libsasl2-3 libselinux1 libsepol1
libssh-config libssh4 libstdc++6 libsystemd0 libunistring2 libverto1 libwrap0 libz1 libzio1 libzstd1 openssl openssl-1_1 procps sed socat system-user-root terminfo-base update-alternatives
68 new packages to install.
Overall download size: 16.7 MiB. Already cached: 0 B. After the operation, additional 47.5 MiB will be used. # Now check the curl package installed to `/rootfs` (_not the containers root_)
rpm --root /rootfs -qi curl | grep -Ei 'install|build'
Install Date: Sat Oct 14 08:57:40 2023
Build Date : Wed Oct 4 10:11:55 2023
Build Host : h01-ch4c Notice that:
Please revert the change and remove the unwanted repos correctly as shown above. If you want inline documentation for the Dockerfile (since you added some of that via that PR), you may be interested in the original commit proposed (which also clarifies the options + repo updating). |
Which version are you referring to
3.2 from
drwetter/testssl.sh:latest
Docker image IDDigest: sha256:98c43b1877453edfcdee9e5a48b3b8ef37277b2a098550d88bb575960f2d6f0e
Hi @drwetter,
I have been reviewing Docker images I use that have curl installed, in light of https://curl.se/docs/CVE-2023-38545.html - and that includes testssl.sh
I especially note that testssl.sh has support for passing proxy args to curl. Although I don't use that, that's especially interesting in light of the nature of this vulnerability.
Entering the Docker container from your latest image, I can see this is the curl version:
I am not so familar with your image and its parent dependencies (SuSE?) and was wondering how I might tell if this version of curl is patched (or not) against the vulnerability (please see 'Affected versions' at https://curl.se/docs/CVE-2023-38545.html) ? I come from a Debian world where it is possible to check the changelog on the filesystem itself, but not sure if that exists in this image. I think it's because you explicitly remove
/usr/share/doc
when building your image (makes sense, keeping it light!).Thanks for any assurance you can provide re: the curl version here! Cheers for making testssl.sh :)
The text was updated successfully, but these errors were encountered: