Ruby/yard/0.9.0

yard: Possible arbitrary path traversal and file access via yard server

Impact

A path traversal vulnerability was discovered in YARD <= 0.9.41 when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions.

The original patch in GHSA-xfhh-rx56-rxcr was incorrectly applied.

Patches

Please upgrade to YARD v0.9.42 immediately if you are relying on yard server to host documentation in any untrusted environments without WEBrick and rely on --docroot.

Workarounds

For users who cannot upgrade, it is possible to perform path sanitization of HTTP requests at your webserver level. WEBrick, for example, can perform such sanitization by default (which you can use via yard server -s webrick), as can certain rules in your webserver configuration.

YARD's default template vulnerable to Cross-site Scripting in generated frames.html

Summary

The frames.html file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the frames.erb template file.

Details

The vulnerability stems from mishandling user-controlled data retrieved from the URL hash in the embedded JavaScript code within the frames.erb template file. Specifically, the script lacks proper sanitization of the hash data before utilizing it to establish the top-level window's location. This oversight permits an attacker to inject malicious JavaScript payloads through carefully crafted URLs.

Snippet from frames.erb: (v0.9.34) erb <script type="text/javascript"> var match = unescape(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^(\w+):\/\//, '').replace(/^\/\//, ''); window.top.location = name; </script>

(v0.9.35) erb <script type="text/javascript"> var match = decodeURIComponent(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^((\w*):)?[\/\\]*/gm, '').trim(); window.top.location.replace(name) </script>

PoC (Proof of Concept)

To exploit this vulnerability: 1. Gain access to the generated Yard Doc. 2. Locate and access the frames.html file. 3. Construct a URL containing the malicious payload in the hash segment, for instance: #!javascript:xss for v0.9.34, and #:javascript:xss for v0.9.35

Impact

This XSS vulnerability presents a substantial threat by enabling an attacker to execute arbitrary JavaScript code within the user's session context. Potential ramifications include session hijacking, theft of sensitive data, unauthorized access to user accounts, and defacement of websites. Any user visiting the compromised page is susceptible to exploitation. It is critical to promptly address this vulnerability to mitigate potential harm to users and preserve the application's integrity.

Arbitrary file read vulnerability in yard server

lib/yard/core_ext/file.rb in the server in YARD before 0.9.11 does not block relative paths with an initial ../ sequence, which allows attackers to conduct directory traversal attacks and read arbitrary files.

YARD static cache reads raw traversal paths before router sanitization

Summary

YARD's static cache lookup reads a request path before the router's path cleanup runs. When a server is configured with a document root, a traversal path such as /../yard-cache-secret.html is joined against that root and can return a readable sibling .html file outside the intended static tree.

The potential security risk seems low, as only html-ending files can be read, but still the risk of reading arbitrary html files is a confiendtiality issue in itself, which is why we decided to report. Please let us know if this is out of your project's scope.

Details

The --docroot CLI option stores the configured directory in server_options[:DocumentRoot] at lib/yard/cli/server.rb:198, and adapter initialization copies that value into adapter.document_root at lib/yard/server/adapter.rb:76. For Rack requests, RackAdapter#call builds a request object from the Rack environment at lib/yard/server/rack_adapter.rb:58 and passes it to router.call(request) at lib/yard/server/rack_adapter.rb:60. Router#call then stores the incoming request at lib/yard/server/router.rb:55 and invokes check_static_cache before normal routing at lib/yard/server/router.rb:56. Inside check_static_cache, the only initial guard is that adapter.document_root is present at lib/yard/server/static_caching.rb:35; the cache path is built from File.join(adapter.document_root, request.path.sub(/\.html$/, '') + '.html') at lib/yard/server/static_caching.rb:36, without cleaning .. components first. If that resolved path is a regular file, File.file? accepts it at lib/yard/server/static_caching.rb:38 and the file bytes are returned as a 200 HTML response at lib/yard/server/static_caching.rb:40. The later route sanitizer in final_options uses File.cleanpath(...).gsub(...) at lib/yard/server/router.rb:181 and lib/yard/server/router.rb:182, but a static-cache hit returns before that code is reached.

PoC

poc.zip

bash ./poc/run.sh

expected output: text run 1: exit=0 timed_out=False duration=0.08s matched=True phase=oracle fingerprint='YARD_STATIC_CACHE_PATH_TRAVERSAL' run 2: exit=0 timed_out=False duration=0.08s matched=True phase=oracle fingerprint='YARD_STATIC_CACHE_PATH_TRAVERSAL' run 3: exit=0 timed_out=False duration=0.08s matched=True phase=oracle fingerprint='YARD_STATIC_CACHE_PATH_TRAVERSAL'

The YARD_STATIC_CACHE_PATH_TRAVERSAL fingerprint is emitted only after the PoC observes a 200 static-cache response whose body contains the sibling file outside the configured document root. A setup failure, syntax failure, or cache miss would not print this oracle and would not demonstrate this traversal read.

Impact

A remote unauthenticated HTTP client who can reach a YARD documentation server with DocumentRoot/--docroot enabled can request .html paths containing parent-directory components and receive readable matching files outside the configured document root. The required guards are narrow: adapter.document_root must be set, the traversed target must exist as a regular readable file, and the target must be reachable through the implementation's forced .html suffix. Those requests bypass the later final_options path cleanup because the cache check runs first. The resulting severity class is information disclosure: response bodies can contain off-root .html file contents, but this path does not show write access, code execution, or arbitrary files without the .html constraint.

Potential arbitrary file read vulnerability in yard server

lib/yard/core_ext/file.rb in the server in YARD before 0.9.11 does not block relative paths with an initial ../ sequence, which allows attackers to conduct directory traversal attacks and read arbitrary files.

Arbitrary path traversal and file access via `yard server`

A path traversal vulnerability was discovered in YARD <= 0.9.19 when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions.

The issue is resolved in v0.9.20 and later.

YARD's default template vulnerable to Cross-site Scripting in generated frames.html

Summary

The frames.html file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the frames.erb template file.

Details

The vulnerability stems from mishandling user-controlled data retrieved from the URL hash in the embedded JavaScript code within the frames.erb template file. Specifically, the script lacks proper sanitization of the hash data before utilizing it to establish the top-level window's location. This oversight permits an attacker to inject malicious JavaScript payloads through carefully crafted URLs.

Snippet from frames.erb: (v0.9.34) erb <script type="text/javascript"> var match = unescape(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^(\w+):\/\//, '').replace(/^\/\//, ''); window.top.location = name; </script>

(v0.9.35) erb <script type="text/javascript"> var match = decodeURIComponent(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^((\w*):)?[\/\\]*/gm, '').trim(); window.top.location.replace(name) </script>

Impact

This XSS vulnerability presents a substantial threat by enabling an attacker to execute arbitrary JavaScript code within the user's session context. Potential ramifications include session hijacking, theft of sensitive data, unauthorized access to user accounts, and defacement of websites. Any user visiting the compromised page is susceptible to exploitation. It is critical to promptly address this vulnerability to mitigate potential harm to users and preserve the application's integrity.

Possible arbitrary path traversal and file access via yard server

Impact

A path traversal vulnerability was discovered in YARD <= 0.9.41 when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions.

The original patch in GHSA-xfhh-rx56-rxcr was incorrectly applied.

Patches

Please upgrade to YARD v0.9.42 immediately if you are relying on yard server to host documentation in any untrusted environments without WEBrick and rely on --docroot.

Workarounds

For users who cannot upgrade, it is possible to perform path sanitization of HTTP requests at your webserver level. WEBrick, for example, can perform such sanitization by default (which you can use via yard server -s webrick), as can certain rules in your webserver configuration.

YARD static cache reads raw traversal paths before router sanitization

Summary

YARD's static cache lookup reads a request path before the router's path cleanup runs. When a server is configured with a document root, a traversal path such as /../yard-cache-secret.html is joined against that root and can return a readable sibling .html file outside the intended static tree.

The potential security risk seems low, as only html-ending files can be read, but still the risk of reading arbitrary html files is a confiendtiality issue in itself, which is why we decided to report. Please let us know if this is out of your project's scope.

Possible arbitrary path traversal and file access via `yard server`

A path traversal vulnerability was discovered in YARD <= 0.9.19 when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions.