Nginx alias path traversal allows unauthenticated attackers to read all files on /label_studio/core/
Date: 2023-03
Affected: pip/label-studio
Attack vector: path-traversal
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2022-36551
CWE: CWE-918
CVSS: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

### Summary The vulnerability resides on the Nginx config file: https://github.com/heartexlabs/label-studio/blob/53944e6bcede75ca5c102d655013f2e5238e85e6/deploy/default.conf#L119 The pattern on location /static indicates a popular misconfiguration on Nginx servers presented in 2018 originally by Orange Tsai. This vulnerability allows an attacker to use a single path traversal payload in the matched location to traverse one directory above. This vulnerability only happens due to the location /static directive not having a slash `/` at the end, the following code shows an example of a safe configuration: ```nginx location /static/ { [...] ``` The vulnerability works because Nginx will think that `/static../` is a directory that should also be aliased to the folder, allowing /static/../ to be reached. In Label Studio's case, this means all files on /label_studio/core/ are exposed. Of course, this means that only Label Studio instances that were deployed using the default nginx files introducted at Mar 31, 2021. This is a very easy vulnerability to fix, and just a lesser-known configuration mistake on nginx files. It's very easy to happen because all is needed is for one slash to be missing. (Off-By-One) ** Proof-of-Concept (Leaking Secret Keys): ** Exploiting this vulnerability usually depends on what's on the parent folder, in Label Studio's case the most interesting file I could find that's on there by default is /label_studio/core/ . We can fetch it by simply making a requ


Mitigations:

Architectural layers (MAESTRO):