Fix preopen path traversal in WASI 0.2 descriptor.open-at

[Luca388]

Fixes a path traversal issue in WASI 0.2 descriptor.open-at.

Fix

Prevents .. and symbolic links from escaping the preopen boundary.

Note

The Unix implementation uses openat() and readlinkat() and is still being completed.

Windows support will be implemented separately.

Progress

Completed

• Reject absolute paths and prevent .. from escaping the preopen root
• Traverse path components relative to directory file descriptors with openat()
• Resolve relative symbolic links safely with readlinkat()
• Reject absolute symbolic-link targets and prevent multi-level symlink escapes
• Limit symbolic-link resolution depth
• Clean up opened file descriptors on failure paths
• Complete the Unix implementation

Remaining

• Fix final . / .. handling and trailing-slash semantics
• Implement Windows support

[zherczeg]

Do we need to duplicate these strings? Could we use substrings for this purpose?

[kulcsaradam]

I am unsure about changing these functions. We use libuv and uvwasi for maximum portability between platforms as it supports both windows and linux. Dealing directly with system calls might introduce lots of things to maintain.

I think only implementing correct path resolution would be sufficient enough.

[Luca388]

I understand that libuv doesn’t provide an openat()-style API for resolving paths relative to a directory FD.

Following your suggestion, I could use uv_fs_realpath() to resolve the path, verify that it remains within the preopen directory, and then open it with uv_fs_open(). However, I think this approach could introduce a TOCTOU vulnerability if the path or a symbolic link changes between the resolution and open operations.

Would this limitation be acceptable here, or is there another mechanism in uvwasi that should be used to avoid it?

[zherczeg]

The wasi 0.1 implementation uses this code:
https://github.com/nodejs/uvwasi/blob/main/src/path_resolver.c#L417

It is partly custom, partly uw. Would be good if we could use only one code path, but this might be too difficult.