Conversation

twitter.com/DanielMicay/st Most of these security issues are indirectly resolved in a stable nginx release with 1.22.0. Most fixes are from the 1.21.1 mainline release in July 2021. However, they weren't marked or treated as security fixes so the 1.20 branch didn't get backports.

Quote Tweet

Daniel Micay

@DanielMicay

Feb 14, 2021

I love how using `return $uri` instead of `return $request_uri` is a vulnerability for nginx configuration since they don't sanitize the input and allow it to inject data into the headers via newlines. Alternatively, capturing/using any variables in location blocks with newlines.

Show this thread

Daniel Micay

@DanielMicay

Jun 3

The configuration directives are still vulnerable and can still be easily used in a way that allows an attacker to inject headers for HTTP/1.1. Their fixes forbid spaces and control characters in request URI, header names and Host header so most sources of tainted data are gone.

Daniel Micay

@DanielMicay

Jun 3

Previously, incredibly pervasive nginx configurations simply using a regex location block with a capture like (.*) and then passing it to one of many directives like return were vulnerable to header injection. Many answers on Stack Overflow, blog posts, etc. have vulnerable code.

Daniel Micay

@DanielMicay

Jun 3

You can find many examples of Stack Overflow answers proposing vulnerable configurations with simple searches: "return 301 $uri" site:stackoverflow.com These vulnerabilities are pervasive in nginx configurations and they strangely don't mention this in any official docs.

Replying to

So imo it's insane that this even needed to be developed, but Yandex made a static analysis tool for Nginx configurations, and one of its rules spots and warns against this:

github.com

gixy/httpsplitting.md at master · yandex/gixy

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

Replying to

Yeah, we use it for GrapheneOS. It's unfortunately not maintained anymore and bitrotted due to a major pyparsing update. It doesn't work anymore unless you force holding back the update. It'll be a bit annoying to use now that the main tainted input sources have strict checks.

Replying to

and

It's unfortunate directives like return are still vulnerable. Most vulnerable configuration will be fixed by people updating to 1.21 / 1.22 but there will still be plenty of vulnerabilities. It's unfortunate they don't even mention those directives don't do escaping in docs.

Replying to

> It'll be a bit annoying to use now that the main tainted input sources have strict checks. What do you mean, how does that make Gixy more annoying to use? Do you mean that it would now have false positives due to better Nginx behavior?

Daniel Micay

@DanielMicay

Replying to

@winter_queue_t

There will be substantially more false positives. I don't want to have to use ([^\s]*) instead of (.*) when it's not required. I want nginx to fix the main issue of directives like return not working in a reasonable way at which point I don't want to be warned about that anymore.

3:36 AM · Jun 3, 2022Twitter Web App

Replying to

and

Holding out hope that nginx is finally going to relent and fix most of the issues and then it becomes increasingly annoying to use gixy. Some of the warnings like the one about add_header discarding configuration from all outer scopes are already quite annoying when you want it.

Replying to

> Some of the warnings like the one about add_header discarding configuration from all outer scopes are already quite annoying when you want it. Definitely a valid point, yeah. Curious: when exactly do you want it, at least in the GrapheneOS/etc configurations, for example?

Show replies