Welcome! Log In Create A New Profile

Advanced

Re: Fixing the well Documented Nginx Alias Traversal Vulnerability?

Maxim Dounin
July 07, 2023 07:22PM
Hello!

On Thu, Jul 06, 2023 at 12:05:25PM -0400, Jonathan Leitschuh wrote:

> Hi Nginx Team,
>
> My name is Jonathan Leitschuh. I'm a Senior Software Security Researcher
> for the Open Source Security Foundation: Project Alpha-Omega
> https://openssf.org/community/alpha-omega/. “Alpha” works with the
> maintainers of the most critical open source projects to help them identify
> and fix security vulnerabilities, and improve their security posture.
> “Omega” identified at least 10,000 widely deployed OSS projects where it
> can apply automated security analysis, scoring, and remediation guidance to
> their open source maintainer communities.
>
> Earlier today, on Twitter, I saw this discussion regarding
> the long-standing the NGinx Alias traversal vulnerability:
> https://twitter.com/infosec_au/status/1676072447156834304?s=20
>
> In particular, this discussion centered on this, this recent blog post
> published on the 3rd of this month.
> https://labs.hakaioffsec.com/nginx-alias-traversal/
>
> In that blog post, the researchers detail how, due to misconfiguration and
> failing to specify the `/` character in the correct place can lead to path
> traversal vulnerabilities.
>
>
>
> This vulnerability was previously discussed by Detectify in a blog post in
> 2020:
> https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/
>
> This research originated with Orange Tsai back in 2018:
> https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf
>
> The recent hakaioffsec blog also identifies this case where the
> vulnerability also appears:
>
>
> My question to both the Nginx Security team, and the Nginx Developers, why
> not fix this vulnerability in Nginx itself such that it's safe by default,
> but users can opt-in to the vulnerable behaviour if they so desire through
> an explicit flag? Surely it would be fairly straightforward to identify
> these vulnerable configurations and fix them for the user, or fail closed
> (safe)?
>
> If you need evidence of the impact this vulnerability can have, the
> above hakaioffsec blog post details how this vulnerability resulted in
> a US$6000 bounty from BitWarden.
>
> This GitHub search, proposed by the above blog post, returns 2.2k results
> on GitHub:
>
> https://github.com/search?q=%2Flocation+%5C%2F%5B_.a-zA-Z0-9-%5C%2F%5D*%5B%5E%5C%2F%5D%5B%5Cs%5D%5C%7B%5B%5Cs%5Cn%5D*alias+%5C%2F%5B_.a-zA-Z0-9-%5C%2F%5D*%5C%2F%3B%2F+&type=code
>
> I'm curious what is currently preventing this from being fixed upstream to
> prevent end-users from accidentally implementing vulnerable configurations
> like this.

Thank you for your message.

Indeed, the misconfiguration in question is a well-known one.
Gixy, a tool to detect various nginx misconfigurations, tries to
detect it at least since 2017:

https://github.com/yandex/gixy/blob/master/docs/en/plugins/aliastraversal.md

The root cause as I see it is that nginx locations (and alias)
work with prefix strings, while unaware people often expect them
to work with path components (directories) instead. Note the
"Achieving Impact Without a Slash on Alias" section in the article
you've referenced: a configuration like

location /img {
alias /var/images;
}

makes it possible to access "/var/images_confidential" via a
request to "/img_confidential". This is because locations works
on prefix strings, and due to lack of trailing "/" in the location
prefix it does match "/img_confidential" request, and maps it to
the file system according to the configuration.

Similarly, the same misconfiguration can happen even without the
"alias" directive at all. Consider the configuration:

location / { deny all; }
location /images { allow all; }

In contrast to some might (incorrectly) assume, a request to
"/images_confidential" will be allowed, and will return content as
per the configuration.

Unfortunately, I don't think there is an easy fix. Changing the
way how nginx locations work would be a major change, and will
break a lot of valid configurations where prefix matching is
intentionally used.

Meanwhile, it surely deserves some additional warnings/notes in
the documentation, to emphasize the actual behaviour and potential
pitfalls. Hopefully it would be enough to at least reduce the
amount of such misconfigurations.

If you think there is an easy fix, feel free to provide
suggestions.

(It looks like you aren't subscribed to nginx-devel@, so the
message did not reach the mailing list: it only accepts messages
from subscribers. I've preserved it in Cc: though, so we can
continue discussion there, with more developers involved.)

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

Re: Fixing the well Documented Nginx Alias Traversal Vulnerability?

Maxim Dounin 480 July 07, 2023 07:22PM

Re: Fixing the well Documented Nginx Alias Traversal Vulnerability?

Maxim Dounin 72 July 13, 2023 11:36AM

Re: Fixing the well Documented Nginx Alias Traversal Vulnerability?

Jonathan Leitschuh 72 July 14, 2023 06:52PM

Re: Fixing the well Documented Nginx Alias Traversal Vulnerability?

Maxim Dounin 112 July 14, 2023 11:14PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 247
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready