YHK - yet another hacker news clone

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.

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!

same reason i'd imagine that one might have wanted medical assistance be denied to covid deniers who inevitably did contract covid, and started experiencing the FO part of FAFO: retribution and consistency

because it's just some slop generated by a bunch of stochastic parrots and can't be taken seriously :-)

cough Zig... cough

> No LLMs for finding bugs.

> Depending on the context and content, I tend to be against AI pull requests that haven’t been edited by a human.

I've seen on a few open source projects I follow the 100% AI patch with notes to the effect of "I haven't compiled let alone tested these changes but AI said it's fine and my cursory glance agrees".

Like come on - I'm not going to judge using AI to make a useful change, but at least put in more than zero effort.

Depends on exactly what it is that a project is objecting to. For example, here's Nura:

> AI tools have several ethical issues. They require an unreasonable amount of energy[1] and water[2] to build and operate, their models are built in part with heavily exploited workers in unacceptable working conditions[3], usually without consent from or compensation for creators of the source material[4] and oftentimes causing DDoS attacks against FOSS infrastructure in the process[5] (which in turn force the deployment of challenge-based protections and increase cost and complexity of self-hosting for everybody[6]). Furthermore, they are being used to undermine labor and justify layoffs[7]. These are harms that we do not want to perpetuate, even if only indirectly.

( https://docs.nura.eco/policies-and-processes/development/ai-... )

If you really believe that AI tools are automatically unethical because they destroy the environment, harm workers, and constitute an attack on FOSS infrastructure, then it doesn't really matter how the tool is being used. If you just don't want to see code quality decline, then it's probably not a problem.

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?

It was a comment unrelated to this vulnerability

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.

MediaWiki also has it as a dependency OOTB.

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

That's interesting, I use a short bash script that shuts down apache, calls certbot (which starts apache just to get the certificates) then it restarts apache once certbot is done. This way, the certs are in the standard /etc/letsencrypt location in case I ever do switch web servers. I've run Apache since the 1990's so not likely but I like to keep concerns separated. It's still nice that there is an apache mod for it though.

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.

Indeed, but it's interesting how web serving in general has shifted away from files. In the original era of web servers, the path component of the URL was the filesystem path on the web server; these days, we expect to match it against a table of routes. Even most PHP apps use routing takes. If you want to bring things back to the filesystem you don't just need to bring back .htaccess - you need a whole new framework.

nginx is easier to configure.

For starters it doesn't have a Critical RCE Vulnerability.

Well there's HTTP/0.9. Can't get much simpler than that.

I'd argue that HTTP 1.1 is simpler than Thrift (especially if you include the serialization formats), but more underspecified. The underspecified-ness is where the complexity in handling HTTP 1.1 in correct and secure ways comes from.

That's crazy high.

Well, very high severity obviously indicates more urgency. For example, a significant number of organizations even shut their websites down while waiting for the PHP2Shell patch. Not many vulnerabilities provoke such drastic measures.

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.

Full disclosure has always been an option.

1. Don't disclose, ignore vuln. 2. Disclose to highest bidder, even criminals or state agencies. 3. Disclose to vendor, no follow up. 4. Disclose to vendor, release to public after a set delay. 5. Disclose to public.

4 & 5 are "responsible disclosure". 4 is also "coordinated disclosure". The other options ignore the ethical duty engineers have to the public.

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.

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

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.

> mod_http2 use external library nghttp2[.org] so Apache is dead shell at this point.

Edge, Brave, Opera, Vivaldi, Arc and Electron use Chromium, are those browsers dead shell?

Netflix, LinkedIn, and Uber, most major corporations as well as the desktop version of Minecraft use the JVM, are they dead shell?

> Apache is dead shell at this point

There's far more to HTTP than just the transport. There are, for example, 4 governing RFCs for modern HTTP implementations:

  RFC 9110 HTTP Semantics
  RFC 9111 HTTP Caching
  RFC 9112 HTTP/1.1
  RFC 9113 HTTP/2.0

The nghttp2 library is only going to cover 1/4 of those. Apache is directly responsible for implementing 2/4 of those, and since it provides its own HTTP/1.1 implementation as far as I know, it's actually 3/4 of those.