Critical RCE Vulnerability in Apache HTTP Server (wiz.io)

One should stop using SAML anyway as that has its own collection of problems. We learned a lot about problems with cryptographic protocols in the last 30 years that cannot be fixed in SAML.

i mostly use nginx lua to patch on some feature i had even on bare Apache, let alone all the core modules.

> (No built-in Lua though.)

I thought mod_lua was an official module. I've just checked with Debian stable, and their "apache2-bin" package depends on liblua5.

> Apache has plenty of life left

I would expect a project with "plenty of life left" to support HTTP3. And to use Git (or some modern DVCS) instead of Subversion.

BTW, a co-worker has to maintain an Apache server because its shibboleth mod is mandatory for that project, and he often complains about it, and so do I when they ask for help. Performance is worse than nginx, configuration is awful, documentation is uneven, some features (like .htaccess) are dangerous, etc.

Apache http is the only project that I know that still uses Subversion. They have published a Git clone on Github, but their main source is still svn. It's a bit worrying, because they won't attract new developers with that technical stack. Last I checked, the 2.5 branch looked dead, and the dev-list was barely active.

> (No built-in Lua though.)

* https://httpd.apache.org/docs/2.4/mod/mod_lua.html

?

nginx has that too https://blog.nginx.org/blog/native-support-for-acme-protocol

Exactly the same for me! I could switch to Nginx, it's one prompt away probably, but why?

PHP can go to hell. My hair is gray because of it. Nginx is superior, and I can get anything imaginable done with config files. And not to mention, it's much faster.

Eh. You can use .htaccess in nginx too. I use that everyday.

Does not Microsoft's IIS also have that with web.config files?

I would say that's actually a misfeature as it requires too many additional filesystem lookups to fulfil requests.

Modifying the web server config is a nonissue outside of shared hosting, which should have died out with the advent of VMs/containers.

Ah yes, htaccess. Another lovely source of security bugs for the past 30 years and may it continue to bear skiddie fruit for another 300.

Its model is fundamentally flawed precisely because it was based on the fundamentally flawed PHP model (website assets and code are stored and hosted from the same webroot). This allowed for shared hosting to exist but containers and reverse proxies are a far better way of organising such sites today.

The fact that in other webservers the server's configuration is configured through its configuration file and not the content of its webroot is a feature.

> Apache has a feature that no other http server has replicated: .htaccess files.

That can expose your files for such a trivial reason as different end of line sequence than what it expects. Instead of shutting down the access, it just happily ignores .htaccess and enables DirectoryIndex.

This is the software that's responsible for majority of data leaks in the world.

Stop using it.

nginx is easier to configure.

HTTP/3 was the real mistake. It basically reimplements TCP on top of UDP and from my testing (at least the existing implementations) it generally performs worser then HTTP/2. Even when testing on somewhat a bit lossy connection.

You'd think they'd have an LLM reviewing this by now. On the up side, it is refreshing to see good ol' human error still around on the surface!

IIRC popular apache/php platforms such as cpanel, official wordpress docker container image, etc use mpm_prefork by default.

At least wrt the linux kernel, Greg kh explained that there's no point in delayed disclosures anymore, one LLM reporting a bug is often followed by several more reporting the same bug on the same day. So you can assume it's public knowledge by the time it's reported.

That's crazy high.

But it's not a given that memory corruption is exploitable as an RCE specifically. I thought to call something an RCE you need a working exploit?

Another comment says it has a CVSS score of 9.8 which means CVE, easy to exploit, and an exploit gives LOTS of access.

Before we get too whiny about "it's only memory corruption without any RCE PoC", let's wait until the CVE is unembargoed.

It was a comment unrelated to this vulnerability

If I understand correctly that only affects reverse proxy chains, which people might just not have. Or not have in a way that is vulnerable to that?

I guess it makes sense that "the cloud" moves to it, but beyond that, it might be fine?

They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.

https://xin.dev/blog/multiple-nginx-vulnerabilities/

One of the core claims of the language is data race safety because in safe rust, no memory location can be written by two or more owners at the same time. (see https://doc.rust-lang.org/nomicon/races.html for a more detailed discussion) Consequently, the kind of memory corruptions that this vulnerability seems to exploit are not possible in safe rust. Now, we don't know if a hypothetical rust-based apache implementation would have reached for unsafe in this context or done any other wild thing, but it's fair to assume that the likelihood of an exploitable RCE through memory corruption trends towards zero in programs written in Rust.

> > a concurrent execution race condition within the assign_headers() function when handling shared resources [...] can corrupt heap memory to achieve arbitrary code execution (RCE)

To my understanding, in safe Rust to share between threads the compiler will require something like Arc<Mutex<...>> - which prevents unsynchronized access or freeing while another thread is still using it.

The details I've seen are too sparse to say with certainty, but it seems like the issue is concurrent access to the same value through a pointer.

In particular it's `req` in the function with this signature:

    static void assign_headers(request_rec *r, const h2_request *req,
                               int no_body, int is_connect)

The fix being:

                - apr_table_setn(req->headers, "Content-Length", "0");
                + apr_table_setn(r->headers_in, "Content-Length", "0");

My read on this is that `req` is meant to be a readonly value in this function, which is why it's marked `const`. And being readonly, it would be safe to access concurrently. However, someone accidentally wrote through this pointer.

In Rust this would've been `req: &h2_request` and the accidental write wouldn't have been possible (barring interior mutability). Even with interior mutability there is no thread interleaving during the write, which happens through a `&mut h2_request` probably obtained through a lock.