Conversation

nginx 😱 seriously ffs if you want to write C, stop making these bloated NIH'd libc replacement frameworks that get everything wrong (unsafely wrong even)

Quote Tweet

Daniel Micay

@DanielMicay

Sep 7, 2021

Replying to @DanielMicay @saleemrash1d and 3 others

I think they got tired of people still using LAMP and decided outdo Apache by turning nginx into an in-process library/framework for a bunch of different languages. Basically the unikernel thing but with web servers. They just need to make it an OS now for maximum hype.

Replying to

They want performance at all costs and apparently that includes avoiding anything from libc and making a whole bunch of hand-rolled sketchy performance-oriented code full of free lists, arenas, lock-free data structures, custom threading, etc. Lots wrong from glancing over it.

Replying to

and

File some bugs?

Replying to

and

I don't generally file bugs in software that I don't use. Have no plans to use NGINX Unit and ideally in the long term there will be something better than nginx. nginx itself is pretty stagnant even though there's a lot to improve when it comes to latency and safety/security.

Replying to

and

Are there any companies that use NGINX and have a bug bounty program? Because NGINX is practically *the* static file server nowadays, and is used as a reverse proxy by Cloudflare too.

Replying to

and

nginx itself is a lot more mature and far less ambitious than the newer NGINX Unit. It still has a similar approach to rolling everything themselves but they aren't trying to provide nearly as much functionality in their traditional / legacy web server vs. the new web/app server.

Replying to

and

It's hard not to get the impression that they increasingly see nginx as a legacy product and don't find it to be a particularly compelling place to invest resources. They're slowly working on HTTP/3 support but it's pretty stagnant and even small improvements tend to rot.

Replying to

and

At least as an outsider, my impression is that NGINX Unit is intended to displace many of the use cases. It moves to a far more declarative configuration model and has proper dynamic reconfiguration via an API and other features normally gated behind the NGINX Plus product.

Replying to

and

It's not really a complete replacement for nginx as a static web server and reverse proxy right now... but it seems like that's the intention, and that they're a lot more interested in NGINX Unit performance, latency, scalability, etc. going forward than the traditional project.

Replying to

and

The code style and NIH approach in both is pretty much the same. They write highly optimized low-level code to the extreme across the board, with performance clearly as the top concern far above correctness/safety/security.

Replying to

and

Boggles my mind that github.com/yandex/gixy/bl is an issue for nginx and it stresses me out dealing with the configuration since so much of it is a trap allowing cookie injection or worse via URLs. I don't get why they don't at least sanity check the input to those directives.

github.com

gixy/httpsplitting.md at master · yandex/gixy

Nginx configuration static analyzer. Contribute to yandex/gixy development by creating an account on GitHub.

7:50 AM · Sep 7, 2021Twitter Web App

Replying to

and

nginx has location blocks with regular expressions including captures but if you use those directly and pass the captures to regular directives like return, you're permitting attackers to inject HTTP headers since location blocks unescape output and directives don't escape it.

Replying to

and

You can cause problems other ways, but that's the typical way. They basically invented a whole completely unnecessary class of vulnerability simply by using the configuration in the obvious way. Other stuff like Apache has even worse problems in some ways. Still inexcusable IMO.

Show replies