Monday, October 28, 2024

Bitnami Helm charts moving to OCI

In January 2022, we announced the general availability of Helm charts in OCI registries, coinciding with the release of Helm version 3.8.0. In January 2023, Bitnami began populating and distributing the largest and most up-to-date Open-Source catalog of Helm charts in OCI format in Docker Hub

Since then, the adoption of the Bitnami Helm charts in OCI format has proliferated. Because charts stored in container registries follow OCI standards, developers can use many of the same tools for Helm charts that they use with container images. This makes integrating Helm into automated pipelines easier and uses modern infrastructure-as-code and deployment techniques like GitOps.

We would like to go further and help the Helm community to continue adopting the OCI distribution format. Starting November the 18th, 2024, Bitnami Helm charts will default to OCI. All the charts will remain Open Source and publicly available at https://hub.docker.com/u/bitnamicharts.

Why OCI Format?

1. Standardization and Interoperability

The OCI format offers a standardized way to package and distribute container images and related artifacts. This standardization fosters interoperability across different tools and platforms, making it easier for developers and operators to collaborate. By adopting OCI, Helm charts can seamlessly integrate with existing container ecosystems, enhancing compatibility with tools like Docker and container registries.

2. Enhanced Security

The OCI format promotes best practices for image signing and verification, allowing users to validate the integrity of their deployments. By adopting OCI, the Bitnami Helm charts leverage these security features. This ensures that the charts we publish are trustworthy and resilient against vulnerabilities.

3. Improved Distribution

With OCI-compliant registries becoming increasingly prevalent, moving to the OCI format allows for more efficient distribution of Helm charts. Users can store and manage Helm charts alongside container images in a single repository, simplifying workflows and reducing the complexity of multi-repository management.

4. Future-Proofing Our Ecosystem

The cloud-native landscape is dynamic, with new technologies and practices constantly emerging. By transitioning to the OCI format, Bitnami Helm charts are delivered in a way that sets developers up for success in this ever-changing environment.


The move to OCI format is more than just a technical shift; it’s an opportunity for the Helm community to enhance its capabilities, improve security, and simplify our workflows.

What will happen to the current index.yaml stored at charts.bitnami.com?


In order to guarantee a smoother transition, the index.yaml will continue existing as an OCI artifact in Docker Hub. Any users who still use the helm repo add command can continue using this approach to maintain backward compatibility. The Helm tooling manages this in a transparent manner.

The index.yaml will change the “URL” option to point to the new OCI versions of Helm charts:

   urls:

-    - https://charts.bitnami.com/bitnami/airflow-18.3.2.tgz

+   - oci://registry-1.docker.io/bitnamicharts/airflow:18.3.2


Users should not see any change for deploying Helm charts. The requirement is to use a Helm CLI greater than 3.8.0 to deploy them.

What will happen to the Bitnami Helm charts in tgz format?

The Bitnami Helm charts in tgz format will no longer be updated. Previous versions since 2023 are available at Docker Hub and it is easy to get the tgz format via Helm command:


    $ helm pull oci://registry-1.docker.io/bitnamicharts/airflow –version 18.3.2


Older versions will continue to be available at the same URL for 6 months to ensure a smooth transition. Do not hesitate to contact us for any questions or suggestions at https://github.com/bitnami/charts/issues.


Thursday, September 26, 2024

Bitnami applications unaffected by recently announced CUPS server vulnerabilities

Several critical vulnerabilities for UNIX systems targeting the CUPS server were discovered and disclosed today. The researcher who discovered them published a technical report at https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/


The vulnerabilities are listed below:

- CVE-2024-47176 | cups-browsed <= 2.0.1 binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker controlled URL.

- CVE-2024-47076 | libcupsfilters <= 2.1b1 cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system.

- CVE-2024-47175 | libppd <= 2.1b1 ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD.

- CVE-2024-47177 | cups-filters <= 2.0.1 foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.


The impact is very high because a possible attacker can replace a printer resulting in arbitrary remote command execution (RCE).

Are Bitnami applications affected? Are Tanzu Application Catalog applications affected? No. 

No applications packaged by Bitnami or our enterprise version VMware Tanzu Application Catalog are affected: none of our containers, Helm charts, OVAs or Cloud Images ship the CUPS server or packages. For OVAs and Cloud Images, even the server is not installed by default, the firewall does not expose the CUPS default port.

Monday, July 1, 2024

regreSSHion: Code Execution Vulnerability in OpenSSH server (CVE-2024-6387)

The Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) on glibc-based Linux systems. This vulnerability has been assigned CVE-2024-6387.

The vulnerability, caused by a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems, presenting a significant security risk. This race condition affects sshd in its default configuration.


The Bitnami catalog is based on Debian, according to the Debian security tracker:

  • Debian 11 (bullseye) is not affected.

  • Debian 12 (bookworm) is affected up to version 1:9.2p1-2+deb12u3.


SSH server is installed and running in OVAs and Cloud Images for AWS, Google, and Azure Marketplaces. Bitnami Helm charts and container images are not affected. The Bitnami team is working on releasing new versions in all the Marketplaces.


See below some details about how the bundled SSH package can be upgraded to a patched version:


Fix/Mitigation

By default, OVAs and Cloud Images include the unattended-upgrades package that will try to install security updates automatically daily. However, it is possible to force the execution of the cronjob manually.


First of all, verify you are running an affected version of the openssh package as shown below


$ sudo dpkg -l | grep ssh

ii  libssh2-1:amd64                  1.10.0-3+b1                    amd64        SSH2 client-side library

ii  openssh-client                   1:9.2p1-2+deb12u2              amd64        secure shell (SSH) client, for secure access to remote machines

ii  openssh-server                   1:9.2p1-2+deb12u2              amd64        secure shell (SSH) server, for secure access from remote machines

ii  openssh-sftp-server              1:9.2p1-2+deb12u2              amd64        secure shell (SSH) sftp server module, for SFTP access from remote machines

ii  ssh                              1:9.2p1-2+deb12u2              all          secure shell client and server (metapackage)


In case you are affected, force the unattended-upgrade execution by running the command below


$ sudo apt-get update && sudo unattended-upgrade -d


This will log new information into the /var/log/unattended-upgrades/unattended-upgrades.log and /var/log/unattended-upgrades/unattended-upgrades-dpkg.log files, where you can check if the OpenSSH service has been updated and the new version it has installed


$ grep -i ssh /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

Preparing to unpack .../1-openssh-sftp-server_1%3a9.2p1-2+deb12u3_amd64.deb ...

Unpacking openssh-sftp-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...

Preparing to unpack .../2-openssh-server_1%3a9.2p1-2+deb12u3_amd64.deb ...

Unpacking openssh-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...

Preparing to unpack .../3-openssh-client_1%3a9.2p1-2+deb12u3_amd64.deb ...

Unpacking openssh-client (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...

Preparing to unpack .../5-ssh_1%3a9.2p1-2+deb12u3_all.deb ...

Unpacking ssh (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ...

Setting up openssh-client (1:9.2p1-2+deb12u3) ...

Setting up openssh-sftp-server (1:9.2p1-2+deb12u3) ...

Setting up openssh-server (1:9.2p1-2+deb12u3) ...


After that, you can check the new version has been installed


$ sudo dpkg -l | grep ssh

ii  libssh2-1:amd64                  1.10.0-3+b1                    amd64        SSH2 client-side library

ii  openssh-client                   1:9.2p1-2+deb12u3              amd64        secure shell (SSH) client...

ii  openssh-server                   1:9.2p1-2+deb12u3              amd64        secure shell (SSH) server...

ii  openssh-sftp-server              1:9.2p1-2+deb12u3              amd64        secure shell (SSH) sftp...

ii  ssh                              1:9.2p1-2+deb12u3              all          secure shell client and server (metapackage)


From the client side you can check the server is returning the updated package information by running the next command


$ ssh -v <user>@<ip-address> 2>&1 | grep -i openssh

OpenSSH_9.6p1, LibreSSL 3.3.6

debug1: Local version string SSH-2.0-OpenSSH_9.6

debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u3

debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u3 pat OpenSSH* compat 0x04000000

If you have any questions about this process, please create an issue in our GitHub repository. We will be happy to help!

Updates

  • [July 13, 2024, 10:05 AM (UTC)]:
    • 130 out of 132 (98%) OVAs released
    • 131 out of 133 (98%) AWS Images released
    • 79 out of 81 (98%) Azure Images released
    • 83 out of 84 (99%) Google Images released
  • [July 11, 2024, 05:37 AM (UTC)]:
    • 130 out of 132 (98%) OVAs released
    • 131 out of 133 (98%) AWS Images released
    • 78 out of 81 (96%) Azure Images released
    • 82 out of 84 (98%) Google Images released
  • [July 9, 2024, 06:12 AM (UTC)]:
    • 129 out of 132 (98%) OVAs released
    • 130 out of 133 (98%) AWS Images released
    • 77 out of 81 (95%) Azure Images released
    • 82 out of 84 (98%) Google Images released
  • [July 3, 2024, 11:30 AM (UTC)]:
    • 129 out of 132 (98%) OVAs released
    • 129 out of 133 (98%) AWS Images released
    • 76 out of 81 (94%) Azure Images released
    • 76 out of 84 (91%) Google Images released