71–80 of 116 posts
Wow, coming from the webdev world. It is so funny seeing NGINX, one of the widest used web servers in the world, on version 1.x. React is on version 19. Really shows how differently new vs. old software is designed and built, and not necessarily in a good way. https://world.hey.com/dhh/finished-software-8ee43637 https://josem.co/the-beauty-of-finished-software/
The venerable unix tool "less" is on v701 and was probably already over 300 before react was born
Earlier quoted context omitted.
So you're not vulnerable to script-kiddies running the published PoC. Still probably vulnerable to to a sufficiently-motivated attacker.
I doubt it: aslr is not as easy to break on modern Linux as everyone in this thread wants to pretend it is. And anybody who actually cares so much about security that a compromised web frontend is the end of the world should be doing other things which would additionally mitigate this... I know they claimed they can bypass it: if that's true, they should publish it. The forking nature of nginx is uniquely bizarre and…
Memory corruption vulnerabilities are possible whenever a language is used that performs copies of data across buffers without in-language guards.
This vulnerability does not require knowledge of the memory layout to generate worker crashes against a system with vulnerable configurations.
The vulnerability is not the end of the world. System administrators will upgrade nginx with the security patch when it's released across most distribution paths (right now it's available only on unstable Debian for example). In the meantime sysadmins will likely remove the vulnerable directives from nginx configs.
As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence. ASLR is a defense-in-depth technique intended to mak…
You can safely assume a 1:1 overlap between the people that claim "AI will solve cyber" (and they always say 'cyber') and the people saying this.
Is there a good alternative to Apache and Nginx that's written in a memory-safe language and not full of security holes? I briefly looked at Jetty (written in Java) and Caddy (written in Go) but they seem to have a history of vulnerabilities of other types (e.g. shell injection in Jetty) so I'm not sure they would be any better.
This one's pretty bad but there are some preconditions. Requires a "rewrite" directive with a questionmark in the replacement string, and then a subsequent "set" directive that references a regex capture group (e.g. set $var $1). Also the POC assumes ASLR is disabled.
I think "rewrite" is rarely used nowadays? Isn't it something from old days of PHP and Apache?
Apache still runs about 23-28% of websites (with some measurements suggesting it is pretty close to equal with nginx). PHP is still in use by 70-80% of websites (numbers vary depending on where you look).
You make it sound like both pieces of tech are irrelevant. Nothing could be further from the truth.
some quick googled examples (like I said other sites' numbers vary, but you get the general idea):
https://www.wappalyzer.com/technologies/web-servers/ https://kinsta.com/php-market-share/
Earlier quoted context omitted.
I doubt it: aslr is not as easy to break on modern Linux as everyone in this thread wants to pretend it is. And anybody who actually cares so much about security that a compromised web frontend is the end of the world should be doing other things which would additionally mitigate this... I know they claimed they can bypass it: if that's true, they should publish it. The forking nature of nginx is uniquely bizarre and…
Apache used forked processes; I don't think that's unique or a particular issue. NGINX uses async io to handle requests, which is a substantial upgrade from Apache; that's why it's performant. Memory corruption vulnerabilities are possible whenever a language is used that performs copies of data across buffers without in-language guards. This vulnerability does not require knowledge of the memory layout to generate w…
Of course it is... in a typical threaded daemon, the threads have randomized stack addresses. Exactly as you observed, you get unlimited tries because nginx dutifully restarts the worker process with the same literal stack address every time it segfaults. I'm willing to bet the ASLR break they claim to have relies on that, but I'd be happy to be proven wrong if they publish it :)
Wow, coming from the webdev world. It is so funny seeing NGINX, one of the widest used web servers in the world, on version 1.x. React is on version 19. Really shows how differently new vs. old software is designed and built, and not necessarily in a good way. https://world.hey.com/dhh/finished-software-8ee43637 https://josem.co/the-beauty-of-finished-software/
Earlier quoted context omitted.
Apache used forked processes; I don't think that's unique or a particular issue. NGINX uses async io to handle requests, which is a substantial upgrade from Apache; that's why it's performant. Memory corruption vulnerabilities are possible whenever a language is used that performs copies of data across buffers without in-language guards. This vulnerability does not require knowledge of the memory layout to generate w…
> Apache used forked processes; I don't think that's unique or a particular issue. Of course it is... in a typical threaded daemon, the threads have randomized stack addresses. Exactly as you observed, you get unlimited tries because nginx dutifully restarts the worker process with the same literal stack address every time it segfaults. I'm willing to bet the ASLR break they claim to have relies on that, but I'd be h…
First time I’ve seen feng shui used in this manner..?
As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence. ASLR is a defense-in-depth technique intended to mak…
> ASLR is a defense-in-depth technique intended to make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private. I disagree with…