Current CVEs in golang 1.21.12 used in Packer 1.11.2

[synergiator]

As it seems, Golang has recently patched a couple of CVEs, providing CVE-free updated releases 1.22.7 and 1.23.1.

Now as it seems Packer compiles the golang stdlib as of language level 1.21.12. I see similar issues also with Terraform and Vault, and of course all other golang based software in this world need soon to update.

A side question - isnt't it technically possible to link dynamically to Golang libs so that recompiling and rereleasing it in case of such CVE-based fixed is not (always) necessary? (sorry if this question does not make sense in world of Golang programming).

Proof:

1. Create an installer script
2. Use it in Dockerfile
3. Test local image with trivy

Installer script

#!/bin/sh

set -ex

echo "install packer $PACKER_VERSION" && \
# Filenames based on version
SHA_SUMS="packer_${PACKER_VERSION}_SHA256SUMS"
SHA_SIG="packer_${PACKER_VERSION}_SHA256SUMS.sig"
BINARY_ZIP="packer_${PACKER_VERSION}_linux_amd64.zip"

# Download files
wget -P "$DOWNLOAD_DIR" "https://releases.hashicorp.com/packer/${PACKER_VERSION}/${SHA_SUMS}"
wget -P "$DOWNLOAD_DIR" "https://releases.hashicorp.com/packer/${PACKER_VERSION}/${SHA_SIG}"
wget -P "$DOWNLOAD_DIR" "https://releases.hashicorp.com/packer/${PACKER_VERSION}/${BINARY_ZIP}"

save_cwd=$(pwd)
cd $DOWNLOAD_DIR

grep "$(basename $BINARY_ZIP)" "./$SHA_SUMS" > filtered_SHA_SUMS

# Verbose SHA256 checksum verification
echo "Verifying SHA256 checksums for downloaded file..."
if sha256sum -c filtered_SHA_SUMS; then
    echo "All relevant files are verified successfully."
else
    echo "Error: Checksum verification failed for relevant files."
    exit 1  # Exit the script if checksum verification fails
fi

# Unzip the binary package
ls -alh
unzip "$BINARY_ZIP"
chmod +x packer
mv packer /usr/local/bin/packer
cd $save_cwd
packer version

Dockerfile

FROM alpine:3.20.3
ARG PACKER_VERSION=1.11.2
ARG DOWNLOAD_DIR=/tmp
WORKDIR /root
COPY ./*.sh ./

ADD alpine-repositories /etc/apk/repositories
RUN set -ex && chmod +x ./*.sh && \
    ls -alh && \
    apk update --no-cache && \
    apk upgrade --no-cache && \
    apk add --no-cache \
        git gpg gpg-agent unzip openssh nmap \
        jq curl dpkg  \
        lvm2 py3-netaddr \
        gettext which aws-cli \
        py3-pip python3 && \
    ln -sf python3 /usr/bin/python && \
    pwd && ls -alh && \
    mkdir -p /root/.ssh && \
    touch /root/.ssh/known_hosts && \
    echo "Installed packages:" && \
    apk info -vv


# Test local image

docker run --rm
-v /var/run/docker.sock:/var/run/docker.sock
-v $TRIVY_DB:/root/.cache/trivy
aquasec/trivy:latest image "$1"

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬─────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼─────────────────────────────────────────────────────────────┤
│ stdlib │ CVE-2024-34156 │ HIGH │ fixed │ 1.21.12 │ 1.22.7, 1.23.1 │ encoding/gob: golang: Calling Decoder.Decode on a message │
│ │ │ │ │ │ │ which contains deeply nested structures... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34156 │
│ ├────────────────┼──────────┤ │ │ ├─────────────────────────────────────────────────────────────┤
│ │ CVE-2024-34155 │ MEDIUM │ │ │ │ go/parser: golang: Calling any of the Parse functions │
│ │ │ │ │ │ │ containing deeply nested literals... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34155 │
│ ├────────────────┤ │ │ │ ├─────────────────────────────────────────────────────────────┤
│ │ CVE-2024-34158 │ │ │ │ │ go/build/constraint: golang: Calling Parse on a "// +build" │
│ │ │ │ │ │ │ build tag line with... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34158 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴─────────────────────────────────────────────────────────────┘

[github-actions]

Hi 👋 thanks for reaching out.

For general questions we recommend reaching out to the [community forum](https://discuss.hashicorp.com/c/packer) for greater visibility.
As the GitHub issue tracker is only watched by a small subset of maintainers and is really reserved for bugs and enhancements, you'll have a better chance of finding someone who can help you in the forum.
We'll mark this issue as needs-reply to help inform maintainers that this question is awaiting a response.
If no activity is taken on this question within 30 days it will be automatically closed.

If you find the forum to be more helpful or if you've found the answer to your question elsewhere please feel free to post a response and close the issue.

[lbajolet-hashicorp]

Hi @synergiator,

To address your first question regarding linking Go libraries, technically it would be possible indeed, but that would imply the Go standard library is compiled separately, which is not the case by default (Go produces mostly statically linked executables, with the exception of anything injected through cgo, or low-level C libraries), so as it stands this is not something that we will address.

As for compiling with Go 1.22.7, @nywilken just pushed a PR to bump the Go version with which we compile Packer core, so the next version we release will be updated to not be vulnerable to those CVEs.

That said, could you link the problematic CVEs by any chance? We do bump dependencies and toolchain periodically, but in general we find that the vulnerabilities reported, while they trigger alerts by tooling, are not generally something we are particularly vulnerable to, though admittedly this could change depending on what's reported.

[github-actions]

Hi,

This issue has not received any update in the last 3 weeks, and will automatically be closed in 7 days if it does not receive any activity by then.

If you find the community forum to be more helpful or if you've found the answer to your question elsewhere please feel free to post a response and close the issue.

[harshavmb]

Hi @lbajolet-hashicorp ,

I see the go-version bumped in early September. Given the severity of this vulnerability, would it be possible to have a release version soon?

[lbajolet-hashicorp]

Hi @harshavmb,

We don't have a release planned soon, which CVEs are you more concerned about? As I mentioned in my earlier comment, chances are this gets flagged automatically, but more often than not, Packer is not (to my knowledge at least) impacted by those CVEs.

If we can confirm this is indeed a real problem we can make a case for a patch release, but otherwise I'd suggest we wait until we're ready to release a new version with more improvements, we're aiming to include a couple things with 1.12.0 later this year (likely December).

Thanks!

[harshavmb]

Hi @lbajolet-hashicorp ,

GO-2024-3106 is the severity flagged by our security scanner. The vulnerability seems to be flagged in early September but the packer binary version 1.11.2 seemed be released in July, that's why it's not flagged in your report?

At this point in time, I am not sure if the vulnerability is actually that serious for packer but it would be great to hear your feedback on that. A minor patch release compiled with or above 1.22.7 of go would be of great help.

Thanks for your quick reply.

[lbajolet-hashicorp]

Hi again @harshavmb,

Thanks for the precision; it seems to me that calling this a CVE might be a bit of a stretch from Packer's perspective, though I can imagine on other services it could turn into a DoS through an external attack, but since Packer runs locally and uses Gob only to serialise/deserialise cty objects to/from Packer and plugins (something we're actively trying to move away from to be clear), this seems very minor in our case, especially as it doesn't lead to data integrity/remote execution concerns.

I am not sure this would justify a new patch release to fix it before we're ready to release 1.12.0, but if you have a particularly problematic use-case I'd be willing to revisit my position.

Thanks!

[github-actions]

Hi,

This issue has not received any update in the last 3 weeks, and will automatically be closed in 7 days if it does not receive any activity by then.

If you find the community forum to be more helpful or if you've found the answer to your question elsewhere please feel free to post a response and close the issue.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.