dunglas / frankenphp

🧟 The modern PHP app server
https://frankenphp.dev
MIT License
6.67k stars 220 forks source link

Security issues of bookworm from AWS #897

Closed alucard001 closed 2 months ago

alucard001 commented 2 months ago

Describe you feature request

Is your feature request related to a problem? Please describe. While I am trying to deploy frankenphp to AWS using your docker image, in the Security report under ECR, I got the following: image

Here is the Dockerfile I am currently using:

ARG DOCKER_PHP_TAG=php8.3
FROM dunglas/frankenphp:${DOCKER_PHP_TAG}

ARG BUILD_ENV=local
ENV ENV=${BUILD_ENV}

RUN echo "Current ENV: $BUILD_ENV"

RUN apt update -y && apt upgrade -y

RUN pecl install redis && docker-php-ext-enable redis
RUN docker-php-ext-install opcache && docker-php-ext-enable opcache
RUN docker-php-ext-install pdo pdo_mysql
RUN docker-php-ext-install mysqli && docker-php-ext-enable mysqli
RUN docker-php-ext-install sockets && docker-php-ext-enable sockets

RUN apt install -y \
    git\
    zip unzip \
    autoconf \
    awscli \
    openssl \
    libfreetype-dev \
    libjpeg62-turbo-dev \
    libpng-dev \
    imagemagick \
    libmagickwand-dev \
    openssl libssl-dev libcurl4-openssl-dev \
    zlib1g-dev \
    && pecl install imagick \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install -j$(nproc) gd

# https://github.com/viest/php-ext-xlswriter
RUN pecl install xlswriter

RUN pecl install apcu
RUN echo "extension=apcu.so" >> /usr/local/etc/php/conf.d/apcu.ini

# https://dev.to/kakisoft/php-docker-how-to-enable-pcntlprocess-control-extensions-1afk
RUN docker-php-ext-configure pcntl --enable-pcntl && docker-php-ext-install pcntl

# Install Cloudwatch Agent
# https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/download-cloudwatch-agent-commandline.html
RUN curl -L -o ./amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-ap-east-1.s3.ap-east-1.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb
RUN dpkg -i -E ./amazon-cloudwatch-agent.deb
RUN rm -f ./amazon-cloudwatch-agent.deb

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

RUN rm -rf /var/cache/apt/lists

RUN apt autoremove && apt clean

COPY build/php/php.ini $PHP_INI_DIR/php.ini

COPY src/composer.json /tmp
COPY src/composer.lock /tmp
WORKDIR /tmp

# https://stackoverflow.com/a/76530153/1802483
ENV COMPOSER_ALLOW_SUPERUSER=1
RUN composer install --no-scripts --no-interaction

RUN mv /tmp/vendor /var/www/html
RUN cp /tmp/composer.* /var/www/html

WORKDIR /var/www/html
COPY src/. /var/www/html
COPY build/system-config/backstage/.env.$ENV /var/www/html/.env

RUN php artisan octane:install --server=frankenphp
COPY src/config/. /var/www/html/config
RUN php artisan vendor:publish --tag=telescope-migrations

EXPOSE 8000

ENTRYPOINT ["php", "artisan", "octane:frankenphp", "--host=0.0.0.0", "--port=8000", "--admin-port=2019", "--log-level=debug"]

While I am reading some CVE report it seems that most of the vulnerabilities are solved when using Debian sid (or trixie), is it possible to switch the base OS to those systems?

Thank you very much.

withinboredom commented 2 months ago

If I am reading the report correctly, most of these vulnerabilities are related to system packages, and nothing to do with the base image. Git, for instance is needed for composer.

So unless you are installing composer packages or doing git operations, etc, during the normal course of production execution, these CVEs are meaningless to you. Most of these tools just tell you what exists, but you have to use your brain to figure out if they even mean anything to your application.

FWIW, there is no "secure" base image, there are just base images where we don't know what is insecure about them, yet. (For example, the latest ssh vulnerability was around for nearly 4 years before it was discovered).

dunglas commented 2 months ago

We're rebuilding fresh images using fresh official PHP images every night. These CVE are false positives, and anyway, there are nothing we can do about them, this should be handled by Debian and/or PHP.