Bringing You a Faster, More Secure Web: HTTP/3 Is Now Enabled for All Automattic Services

HTTP/3 is the third major version of the Hypertext Transfer Protocol used to exchange information on the web. It is built on top of a new protocol called QUIC, which is set to fix some limitations of the previous protocol versions. Without getting into technical details—though feel free to do so in the comments if you have questions—our users should see performance improvements across all metrics:

Reduced latency. Due to faster connection establishment (i.e. fewer round-trips), latency from connection setup is lower.

Multiplexing. That is, using a single connection for multiple resources. While this feature is present in HTTP/2, HTTP/3 has improved on it and fixed a problem called “head of line blocking.” This is a deficiency of the underlying protocol HTTP/2 was built on top, which requires packets to be in order before relaying them for processing.

Reliability. Designed to perform better in varying network environments, HTTP/3 uses modern algorithms to help it recover faster from lost data and busy networks.

Improved security. QUIC uses the latest cryptography protocols (TLSv1.3) to encrypt and secure data. More of the data is encrypted, which makes it harder for an attacker to tamper with or listen in on web requests.

Ultimately, HTTP/3 (on top of QUIC) has been designed to be updated in software, which allows for quicker improvements that don’t depend on underlying network infrastructure.

After about a month of preparing our infrastructure—including fixing bugs and upgrading our CDN—HTTP/3 was enabled for all of Automattic’s services on December 27th, 2023. It currently serves between ~25-35% of all traffic.

And now for some stats. For each of these, we want numbers to be lower after the switch, which ultimately means faster speeds across the board for our customers. Let’s look at three metrics in particular:

Time to First Byte (TTFB) measures the time between the request for a resource and when the first byte of a response arrives. 

Largest Contentful Paint (LCP) represents how quickly the main content of a web page is loaded.

Last Resource End (LRE) measures the time between the request for a resource and when the whole response has arrived.

Results for fast connections—low latency and high bandwidth

Improvements look pretty good for fast connections:

TTFB: 7.3%

LCP: 20.9%

LRE: 24.4%

Results for slow connections—high latency or low bandwidth

For slow connections, the results are even better:

TTFB: 27.4%

LCP: 32.5%

LRE: 35%

We are dedicated to providing our customer’s websites with the best possible performance. Enabling HTTP/3 is a step in that direction. See you on the QUIC side!

Automattic’s mission is to democratize publishing. To accomplish that, we’re hiring systems engineers to join the best infrastructure team on the planet. Learn more here.
Quelle: RedHat Stack

Docker Security Advisory: Multiple Vulnerabilities in runc, BuildKit, and Moby

We at Docker prioritize the security and integrity of our software and the trust of our users. Security researchers at Snyk Labs recently identified and reported four security vulnerabilities in the container ecosystem. One of the vulnerabilities, CVE-2024-21626, concerns the runc container runtime, and the other three affect BuildKit (CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653). We want to assure our community that our team, in collaboration with the reporters and open source maintainers, has been diligently working on coordinating and implementing necessary remediations.

We are committed to maintaining the highest security standards. We will publish patched versions of runc, BuildKit, and Moby on January 31 and release an update for Docker Desktop on February 1 to address these vulnerabilities.  Additionally, our latest Moby and BuildKit releases will include fixes for CVE-2024-23650 and CVE-2024-24557, discovered respectively by an independent researcher and through Docker’s internal research initiatives.

 Versions impactedrunc<= 1.1.11BuildKit<= 0.12.4Moby (Docker Engine)<= v25.0.1 and <= v24.0.8Docker Desktop<= 4.27.0

These vulnerabilities can only be exploited if a user actively engages with malicious content by incorporating it into the build process or running a container from a suspect image (particularly relevant for the CVE-2024-21626 container escape vulnerability). Potential impacts include unauthorized access to the host filesystem, compromising the integrity of the build cache, and, in the case of CVE-2024-21626, a scenario that could lead to full container escape. 

We strongly urge all customers to prioritize security by applying the available updates as soon as they are released. Timely application of these updates is the most effective measure to safeguard your systems against these vulnerabilities and maintain a secure and reliable Docker environment.

What should I do if I’m on an affected version?

If you are using affected versions of runc, BuildKit, Moby, or Docker Desktop, make sure to update to the latest versions as soon as patched versions become available:

 Patched versionsrunc>= 1.1.11BuildKit>= 0.12.5Moby (Docker Engine)>= v25.0.2 and >= v24.0.9Docker Desktop>= 4.27.1

If you are unable to update to an unaffected version promptly after it is released, follow these best practices to mitigate risk: 

Only use trusted Docker images (such as Docker Official Images).

Don’t build Docker images from untrusted sources or untrusted Dockerfiles.

If you are a Docker Business customer using Docker Desktop and unable to update to v4.27.1 immediately after it’s released, make sure to enable Hardened Docker Desktop features such as:

Enhanced Container Isolation, which mitigates the impact of CVE-2024-21626 in the case of running containers from malicious images.

Image Access Management, and Registry Access Management, which give organizations control over which images and repositories their users can access.

For CVE-2024-23650, CVE-2024-23651, CVE-2024-23652, and CVE-2024-23653, avoid using BuildKit frontend from an untrusted source. A frontend image is usually specified as the #syntax line on your Dockerfile, or with –frontend flag when using the buildctl build command.

To mitigate CVE-2024-24557, make sure to either use BuildKit or disable caching when building images. From the CLI this can be done via the DOCKER_BUILDKIT=1 environment variable (default for Moby >= v23.0 if the buildx plugin is installed) or the –no-cache flag. If you are using the HTTP API directly or through a client, the same can be done by setting nocache to true or version to 2 for the /build API endpoint.

Technical details and impact

CVE-2024-21626 (High)

In runc v1.1.11 and earlier, due to certain leaked file descriptors, an attacker can gain access to the host filesystem by causing a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, or by tricking a user to run a malicious image and allow a container process to gain access to the host filesystem through runc run. The attacks can also be adapted to overwrite semi-arbitrary host binaries, allowing for complete container escapes. Note that when using higher-level runtimes (such as Docker or Kubernetes), this vulnerability can be exploited by running a malicious container image without additional configuration or by passing specific workdir options when starting a container. The vulnerability can also be exploited from within Dockerfiles in the case of Docker.

The issue has been fixed in runc v1.1.12.

CVE-2024-23651 (High)

In BuildKit <= v0.12.4, two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition, leading to files from the host system being accessible to the build container. This will only occur if a user is trying to build a Dockerfile of a malicious project.

The issue will be fixed in BuildKit v0.12.5.

CVE-2024-23652 (High)

In BuildKit <= v0.12.4, a malicious BuildKit frontend or Dockerfile using RUN –mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container from the host system. This will only occur if a user is using a malicious Dockerfile.

The issue will be fixed in BuildKit v0.12.5.

CVE-2024-23653 (High)

In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. In BuildKit <= v0.12.4, it is possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request.

The issue will be fixed in BuildKit v0.12.5.

CVE-2024-23650 (Medium)

In BuildKit <= v0.12.4, a malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

The issue will be fixed in BuildKit v0.12.5.

CVE-2024-24557 (Medium)

In Moby <= v25.0.1 and <= v24.0.8, the classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered a valid cache candidate for some build steps.

The issue will be fixed in Moby >= v25.0.2 and >= v24.0.9.

How are Docker products affected? 

The following Docker products are affected. No other products are affected by these vulnerabilities.

Docker Desktop

Docker Desktop v4.27.0 and earlier are affected. Docker Desktop v4.27.1 will be released on February 1 and includes runc, BuildKit, and dockerd binaries patches. In addition to updating to this new version, we encourage all Docker users to diligently use Docker images and Dockerfiles and ensure you only use trusted content in your builds.

Docker Build Cloud

Any new Docker Build Cloud builder instances will be provisioned with the latest Docker Engine and BuildKit versions after fixes are released and will, therefore, be unaffected by these CVEs. Docker will also be rolling out gradual updates to any existing builder instances.

Security at Docker

At Docker, we know that part of being developer-obsessed is providing secure software to developers. We appreciate the responsible disclosure of these vulnerabilities. If you’re aware of potential security vulnerabilities in any Docker product, report them to security@docker.com. For more information on Docker’s security practices, see our website.

Advisory links

Runc

CVE-2024-21626

BuildKit

CVE-2024-23650

CVE-2024-23651

CVE-2024-23652

CVE-2024-23653

Moby

CVE-2024-24557

Quelle: https://blog.docker.com/feed/

Amazon ECS Service Connect bietet Unterstützung für die automatische Verschlüsselung des Datenverkehrs mit TLS-Zertifikaten

Amazon Elastic Container Service (Amazon ECS) bietet jetzt Unterstützung für automatische Datenverkehrsverschlüsselung mit Transport Layer Security (TLS)-Zertifikaten für seine Netzwerkfunktion namens ECS Service Connect an. Mit dieser Unterstützung ermöglicht ECS Service Connect Ihren Anwendungen, eine sichere Verbindung herzustellen, indem Ihr Netzwerkverkehr verschlüsselt wird. Die automatische Verkehrsverschlüsselung mit ECS Service Connect nutzt branchenführende Verschlüsselungsfunktionen, um Ihre dienstübergreifende Kommunikation zu sichern und so Ihre Sicherheitsanforderungen zu erfüllen.
Quelle: aws.amazon.com

Amazon RDS Custom für SQL-Server unterstützt SQL Server 2022

Amazon RDS Custom für SQL-Server unterstützt jetzt Microsoft SQL Server 2022 CU9 in der Web-, Standard-, Enterprise- und Developer-Edition. Sie können jetzt Funktionen von SQL Server 2022 wie Query Store-Optimierungen, parameterabhängige Planoptimierung und SQL Server Ledger auf Ihren Amazon RDS für SQL Server-DB-Instances nutzen. Weitere Informationen zur Version SQL Server 2022 finden Sie in den Versionshinweisen zu Microsoft SQL Server 2022. Weitere Informationen zu Fehlerbehebung und Optimierung für SQL Server 2022 CU9 finden Sie in den Versionshinweisen von Microsoft.
Quelle: aws.amazon.com

Amazon ECS unterstützt die Konfiguration von Timeout für Services, die mit Service Connect ausgeführt werden

Ab sofort unterstützt Amazon Elastic Container Services (Amazon ECS) die Konfiguration von Timeout für Service-to-Service-Kommunikation mit der Netzwerkfunktion ECS Service Connect. Diese Funktion ermöglicht es Ihnen, benutzerdefinierte Timeouts für Amazon-ECS-Services, die mit Service Connect ausgeführt werden, festzulegen und Anwendungen zu unterstützen, die Anfragen mit langer Laufzeit bearbeiten. Amazon ECS ist ein vollständig verwalteter Container-Orchestrierungsservice, der es Ihnen leichter macht, containerisierte Anwendungen bereitzustellen, zu verwalten und zu skalieren. Kunden können mithilfe der ECS Service Connect-Funktionalität, Serviceerkennung, Konnektivität und Beobachtbarkeit von Datenverkehr für Services, die in Amazon ECS ausgeführt werden, einfach konfigurieren. Damit können Sie Anwendungen schneller erstellen, da Sie sich statt auf die Netzwerkinfrastruktur auf den Anwendungscode konzentrieren können. 
Quelle: aws.amazon.com

Verkäufer können jetzt Professional Services von Drittanbietern im AWS Marketplace weiterverkaufen

AWS-Marketplace-Verkäufer, wie unabhängige Softwareanbieter (ISVs), Beratungspartner und Vertriebspartner, können jetzt Professional Services von Drittanbietern im AWS Marketplace weiterverkaufen. Die Services können Implementierung, Bewertungen, Managed Services, Schulungen oder Premium-Support umfassen. Mit dieser Version können AWS-Marketplace-Verkäufer andere Verkäufer autorisieren, Großhandelspreise für Professional Services zu erhalten, sodass Verkäufer zusätzlich zur Software im AWS Marketplace Support- oder Implementierungsservices anbieten können. Der autorisierte Partner kann dann die Wiederverkaufsgenehmigung verwenden, um Preise, Laufzeit und rechtliche Bedingungen anzupassen, um Professional Services anzubieten, die den Anforderungen der Kunden am besten entsprechen.
Quelle: aws.amazon.com