Alternatives Approaches for Secure libcrypto and libssl Management in Vulnerability Mitigation (CVE-2024–9143)
Security is paramount when building and deploying applications on the internet. For systems supporting essential business functions, even a single vulnerability can compromise efficiency, reliability, and trust. Ensuring robust security requires a strategic approach to mitigate risks, especially when applications serve as foundational components for other critical processes.
But what exactly does it mean to address ‘low vulnerability’ issues effectively? And what characteristics define a truly secure system? These questions are crucial for developing an environment that minimizes risks and maximizes operational resilience. In this exploration, I’ll break down the background of this issues, the justifications in the current industry, comparisons for alternative tools, and our solutions to closed that issues.
Background
The story begins with vulnerability findings from a security scan on Harbor using Trivy by Aqua Security. Trivy, an open-source, all-in-one vulnerability scanner, assists developers and security teams in identifying security issues across various application components. Known for its efficiency, ease of use, and adaptability, Trivy is commonly employed to scan container images, file systems, code repositories, and Kubernetes clusters for vulnerabilities. In this Harbor scan, Trivy detected two vulnerabilities, both classified as low severity, as shown in the image below.
The vulnerability identified, CVE-2024–9143, which published on 16 October 2024, and modified on 18 October 2024, involves using low-level GF(2^m) elliptic curve APIs with untrusted field polynomial values. This can lead to out-of-bounds memory access, potentially causing application crashes or even remote code execution. However, protocols using Elliptic Curve Cryptography (ECC) typically support only named curves or safe encodings that prevent such issues. As a result, the risk of this vulnerability being exploited in real applications is low.
At the image above explain how this vulnerabilities is found. That start from web applications which used base image from node:20-alpine. In the other hand, node:20-alpine is used alpine:3.20. That informations you can found on this link repository. The latest versions on the alpine is versions 3.20.3, and the latest updated is 2 months ago.
Why alpine?, Alpine Linux has become a go-to choice as a base OS for containerized applications, and for good reason. Known for its minimalistic design, Alpine’s base image is a mere 5 MB, making it exceptionally lightweight and reducing network transfer times, storage needs, and memory usage. This streamlined foundation is particularly advantageous in environments where resources are limited and efficient scaling is essential.
Who is used Alpine?, Almost all the applications used alpine. I’ll give some example applications which is used alpine as their os in the docker image.
a. PostgreSQL
b. Golang
c. NodeJs
d. Python
e. Nginx
f. Redis
g. RabbitMQ
h. Apache HTTP Server
And the others cannot be mentioned one by one.
If the vulnerabilities of the alpine is a mandatory cases we had to solved, so the others images like i mentioned in the above will be had a security concern to hack by someone.
Justifications
Based on the previous statements, that there are a lot of applications which is used alpine as their OS. So, they actually had a clear vulnerabilities?, We’ll break it down in the list below.
Docker Scout is like a security guard for your container images. It will be scan for security issues, show dependencies, real-time monitoring, and integrations with development tools. Based on security reports docker scout i’ll give some detail informations about versions tag i’ll used to compare it you can see on the list below.
From the chart, we observe that three applications have just one medium-severity issue. Meanwhile, Redis and PostgreSQL are the two applications with the most vulnerabilities, totaling 3 critical, 35 high, 17 medium, and 1 low. If you’re still cautious about vulnerabilities, what’s your perspective on this?, Still want to use an official docker image?, 😁
Comparisons
There are several list OS which had a none found from vulnerabilities, and i sort the OS based on the compressed size image.
The charts show that Archlinux has the largest compressed size at 144.28MB, while Ubuntu and Almalinux have the smallest sizes. However, the size difference between Ubuntu and Almalinux is minimal, with only a 0.59MB gap. Therefore, if you want to find another OS options than alpine, Ubuntu or AlmaLinux is the best options.
Solutions
To solve issue on CVE-2024–9143 there are 2 options, you can approach
- Upgrade the library only with alpine-3.19. I’ll give you my sample dockerfile code to solve that issues
# Use Node.js base image for building
FROM node:20-alpine3.19 AS base
# Install dependencies only when needed
FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat python3 make g++ cairo-dev pango-dev giflib-dev
WORKDIR /app
# Install dependencies based on the preferred package manager
COPY package.json yarn.lock ./
RUN \
if [ -f yarn.lock ]; then yarn install --frozen-lockfile; \
else echo "Lockfile not found." && exit 1; \
fi
# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN \
if [ -f yarn.lock ]; then yarn build; \
else echo "Lockfile not found." && exit 1; \
fi
# Final stage: Create a minimal Alpine image with updated OpenSSL
FROM node:20-alpine3.19 AS runner
# Update libcrypto3 and libssl3 to the latest patched versions
RUN apk update && \
apk add --no-cache libcrypto3=3.1.7-r1 libssl3=3.1.7-r1
WORKDIR /app
ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
ENV NEXT_TELEMETRY_DISABLED 1
ENV PORT 3000
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
# Set the correct permission for prerender cache
RUN mkdir .next
RUN chown nextjs:nodejs .next
RUN mkdir ./logs && chown nextjs:nodejs ./logs
# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nextjs --chmod=755 /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nextjs --chmod=755 /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
# server.js is created by next build from the standalone output
# https://nextjs.org/docs/pages/api-reference/next-config-js/output
CMD ["node", "server.js"]2. Change the OS from alpine to ubuntu
FROM ubuntu:24.10 AS base
# Install Node.js and other necessary packages
RUN apt-get update && apt-get install -y \
curl \
python3 \
make \
g++ \
libcairo2-dev \
libpango1.0-dev \
libgif-dev \
&& curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \
&& apt-get install -y nodejs \
&& npm install -g yarn \
&& rm -rf /var/lib/apt/lists/*
# Install dependencies only when needed
FROM base AS deps
WORKDIR /app
# Install dependencies based on the preferred package manager
COPY package.json yarn.lock ./
RUN \
if [ -f yarn.lock ]; then yarn install --frozen-lockfile; \
else echo "Lockfile not found." && exit 1; \
fi
# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN \
if [ -f yarn.lock ]; then yarn build; \
else echo "Lockfile not found." && exit 1; \
fi
# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app
ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
ENV NEXT_TELEMETRY_DISABLED 1
ENV PORT 3000
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
# Set the correct permission for prerender cache
RUN mkdir .next
RUN chown nextjs:nodejs .next
RUN mkdir ./logs && chown nextjs:nodejs ./logs
# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nextjs --chmod=755 /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nextjs --chmod=755 /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
# server.js is created by next build from the standalone output
# https://nextjs.org/docs/pages/api-reference/next-config-js/output
CMD ["node", "server.js"]I’m just share about my opinion, still learn, and feel free to discussions. :)
Let’s Explore It
