Fixing stdlib 1.18.2 Vulnerabilities in Docker Images: A PostgreSQL Implementation Guide

Don’t Let Vulnerabilities Sink Your Docker Containers: Fixing stdlib 1.18.2 in PostgreSQL

When I encountered a mini-project that required a quick PostgreSQL implementation with an emphasis on speed, efficiency, and security, Docker emerged as the ideal solution. The urgency of the project demanded a rapid development approach, making Docker’s containerization capabilities particularly valuable.

fix vulnerability stdlib 1.18.2

Using Docker allowed me to bypass the time-consuming traditional PostgreSQL setup process while maintaining robust security measures. This approach significantly reduced the setup time and complexity, enabling me to focus on the core development tasks rather than getting caught up in database configuration details.

PostgreSQL

Even though the process is fast for development we also need to ensure the security based on vulnerability in docker hub official images. And it’s true that the vulnerability is shown on a massive number which I discovered 3 Critical, 35 High, 18 Medium, and 1 Low vulnerabilities on PostgreSQL version 17.2. It was shocking to see such a high number of vulnerabilities in an official image. How can I mitigate this? 🤯

Therefore, in this article, I will share my experience in addressing those vulnerabilities so that we can prevent potential cyberattacks in our systems.

1. Introduction
2. Vulnerabilities
3. Solutions

Introduction

Information from Docker Hub on PostgreSQL Docker Official Image as you can see on the image below [1].

[1] Informations based on docker official image

As you know that Docker official images are curated, optimized, and secure container images created by Docker Inc. or in collaboration with the software’s maintainers. They’re hosted on Docker Hub (a public registry) and are the go-to choice for running popular software like MySQL, Python, Node.js, or even Ubuntu.

Upon conducting a deeper and more critical analysis to find the root cause, I discovered that the issue stems from golang/stdlib/1.18.2. This finding is supported by evidence, as shown in the image below [2]. The vulnerability was specifically found in the gosu command location.

[2] Evidence of the root cause

What is actually gosu?, Imagine you’re throwing a party 🎉, and you want everyone to have fun, but you also need to make sure no one spills drinks on your fancy carpet. You could run around controlling everything yourself (like running your Docker container as the root user), but that’s exhausting and risky. Instead, you hire a bouncer (that’s gosu!) to make sure everyone behaves properly. gosu is a simple tool that lets you run commands as a specific user in your Docker container, without the overhead or complexity of something like sudo. It’s lightweight, secure, and perfect for Docker environments.

Vulnerabilities

The highest score of this vulnerabilities is 9.8 which the latest update on 03 September 2024 ( CVE-2024–24790 ). The problem of this security is the Is methods (such as IsPrivate, IsLoopback, etc.) did not function correctly for IPv4-mapped IPv6 addresses. Instead of returning true for addresses that would typically be valid in their standard IPv4 format, these methods incorrectly returned false.

GitHub - tianon/gosu: Simple Go-based setuid+setgid+setgroups+exec

Based on the documentations repository gosu the latest releases is on 03 November 2023. And the latest golang version on that repository is 1.20. Because there is no update dan upgrade that’s why the solutions for vulnerabilities doesn’t close.

Solutions

On that repository, there are several people who have forked it. Then, I tried to custom it with more secure and clean gosu from vulnerabilities with increase it into golang 1.23.5.

GitHub - sadewa25/gosu: Fork of Simple Go-based setuid+setgid+setgroups+exec

With that gosu we can rebuild the postgresql image using the docker official image repository.

postgres/17/alpine3.20/Dockerfile at 0b87a9bbd23f56b1e9e863ecda5cc9e66416c4e0 ·…

Download files that inside the folder alpine3.20 in your local PC. Then, you just need to change the gosu download file binary. As you can see on the image below the default download is using tianon/gosu.

tianon/gosu from postgresql docker official image

So we need to change the gosu root repository to one of the clean gosu on my forked repository. I just simple update that code into one of this new in the below

ENV GOSU_VERSION 1.17.2
RUN set -eux; \
    \
    apk add --no-cache --virtual .gosu-deps \
        ca-certificates \
        dpkg \
        gnupg \
    ; \
    \
    wget -O /usr/local/bin/gosu "https://github.com/sadewa25/gosu/releases/download/$GOSU_VERSION/gosu-amd64"; \
    \
# skip the signature verification
    \
# clean up fetch dependencies
    apk del --no-network .gosu-deps; \
    \
    chmod +x /usr/local/bin/gosu; \
# verify that the binary works
    gosu --version; \
    gosu nobody true

Finally, just build the image as usual for example I build it with my name is postgresql:clean but you can change it as what you want.

docker build -t postgres:clean -f Dockerfile.PostgresClean .

For make this informations more clear I’ll screenshot my folder to build the docker image.

folder structure to build the PostgreSQL

For completed code I’ll attach on the below

completed code

I’ll show you the results for that implementations on the image below

Docker Image PostgreSQL

Thank you for taking the time to read my article. If you have any questions, need further clarification, or wish to discuss technology-related topics, feel free to reach out to me via email. I’m always open to sharing insights, collaborating on projects, or offering guidance on your tech journey. Let’s connect and build something amazing together! wicaksanasadewa@proton.me

Let’s Explore IT! 😁😁