Semper vigilans: how Platform.sh stays ahead of emerging cybersecurity threats (so you don’t have to)

October is Cybersecurity Awareness month. So, we’ve asked Diogo Sousa, Platform.sh Security team manager to share how his team contributes to helping customers protect their websites and applications from external threats, 24x7. 

Part of the Platform.sh Security team’s day-to-day work is to monitor for any vulnerabilities that might impact our customers. We do this by combining information from various sources—including CVE feeds, blogs, social media accounts—then evaluate if any of these vulnerabilities are capable of affecting our infrastructure and the services we provide. Because Platform.sh offers a depth and breadth of languages and frameworks, we might be analyzing advisories for Golang in the morning, Drupal in the afternoon, and Linux kernel bugs in the evening. In 2022 alone, the Security team reviewed and advised on more than 300 CVEs across a dozen technologies. 

These past weeks of autumn have brought a bountiful crop of high-profile vulnerabilities in popular libraries and tools: libwebp (CVE-2023-4863), libvpx (CVE-2023-5217), glibc (CVE-2023-4911), HTTP/2 (CVE-2023-44487) and, culminating with a big one, libcurl (CVE-2023-38545).

To avoid burying the lede, here’s our current situation:

We’ve made updated versions of all the library CVEs noted above, accessible to Platform.sh customers via a redeploy. The HTTP/2 issue has been mitigated at our edge layer.

Our service continues to operate securely.  
 

So, what exactly are these vulnerabilities?

libwebp

Let’s start with libwebp. As the name suggests, it’s a library used to process images in the WebP format, developed by Google for a faster web experience. Faster load times, no loss of quality, smaller file sizes through better compression—all benefits realized by using the webp format. However, I’m certainly not alone in saying that it’s a slight annoyance when right-clicking an image to expect a transparent PNG, but getting a .webp file back.  

WebP can compress files without any loss of quality, and it’s in that compression that this vulnerability was discovered.

To achieve the compression, WebP uses a method called Huffman coding. A Huffman code is generated from the image and used to efficiently store information on a special table data structure, producing a smaller file with no loss of quality, something very important for images on the web. We’ve all seen a JPEG full of compression artifacts, and it isn’t pretty.

It was found that by using a specially crafted image file, you could bypass a size check and trigger a heap overflow that you could, then, chain into other attacks. This payload, a singular image, made for an interesting delivery mechanism: if your web application didn’t accept and process webp files, delivering a malicious payload was pretty much blocked. But if your application merely displayed the webp image, like a browser or a messaging app, then visiting a website or receiving a file would be enough to trigger it.

Fortunately, creating those files required a high degree of sophistication. They had to represent a valid encoding, with enough additional data hidden to deliver a payload. And that limited the exploitation until patches were made available. Vendors like Apple and Google promptly made the patches available to users once the issue became known. (Hope everyone has the good habit of always keeping your OS and browser up to date.)

HTTP/2: Rapid Reset

The HTTP/2 vulnerability, named Rapid Reset, is interesting as it’s a part of the HTTP/2 protocol itself. In essence, it wasn’t added to the code via a faulty commit; it’s baked in.

HTTP/2 allows for multiple data streams when accessing data, increasing the capability of the connection by prioritizing what gets retrieved. One of those optimizations is the ability for the client to cancel an ongoing stream, similar to saying to the server that it doesn’t need to send over every image on the page because they’re now outside the viewport. This is an inexpensive process for the client, which can move on to other requests; it’s up to the server to honor that cancellation and keep an accurate tally of requests to process, and that’s where the issue lies.

Keeping accurate counts of what requests are in what state and are still needed to be processed is important to avoid getting overwhelmed by requests. The protocol sets a number for the maximum number of concurrent streams, but only streams in certain stages of their lifecycle count against this number. The Rapid Reset attack takes advantage of this by creating a backlog of reset streams that need to be cleaned up by the server. And since they’re not in one of the lifecycle states that counts against the limit, this backlog can grow very quickly, leading to a DoS. With HTTP/2 being common fare—and the attack having a very low complexity—it makes for an ample choice of targets and has already broken some infamous records.

Now, to our main course, libcurl.

libcurl

The issue in libcurl should be familiar to anyone who’s written C code. When connecting to a SOCKS5 proxy, it was possible that the buffer allocated for the hostname was too small and, under specific circumstances, it could be overwritten into a heap overflow.

Noticing a pattern here? As with libwebp, this vulnerability’s impact is limited by its requirements: if using version 8.x, the user needs to purposely override the default configuration (which is safe) to use a lower value for the limit rate. By itself, this vulnerability causes a crash. To leverage it for further compromise, the user must use unsafe options, like forcing cURL to follow redirects (-L), so a payload can be delivered (example). If you’re not in the habit of connecting to unknown (potentially malicious) servers, this should have little to no impact on your usage.

The biggest vulnerability issue here? libcurl is used by a vast number of companies; it’s not an easy task (particularly if you’re doing it on your own) to ensure that all these products, which you may be using directly or indirectly, are using safe configurations.

Next steps: what you can do

If you’re a Platform.sh customer, our teams have already overseen the patching and rollout of the updated versions I’ve just discussed. After evaluating the vulnerabilities’ impact and manner of operation, we decided against forcing a redeployment, leaving it for each customer to schedule and minimize the disruption to their workflows. When clear indicators of active exploitation happen, our customers can rest assured we’ll force an update to keep their projects safe.

To ensure your project remains protected, all you need to do is redeploy. That will trigger an automated check for any changes, and your project will update itself to the latest version with all the necessary patches. We know it’s Friday, but you don’t need to worry: Deploy Friday is our mantra for a reason.

If you’re not currently a Platform.sh customer, vendors have made patches available, together with some recommendations about how to mitigate the impact of these vulnerabilities. 

libwebp 
https://blog.isosceles.com/the-webp-0day/
https://github.com/advisories/GHSA-j7hp-h8jx-5ppr

HTTP/2 
https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/   
https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

libcurl 
https://curl.se/docs/CVE-2023-38545.html

Finally, if you’re looking for a fully managed PaaS, including security and compliance, we hope you’ll give Platform.sh a try.