Lucene search

K
hackeroneLautisH1:3370
HistoryMar 06, 2014 - 11:13 a.m.

Ruby on Rails: Directory traversal attack in view resolver

2014-03-0611:13:20
lautis
hackerone.com
717

4.3 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

NONE

Availability Impact

NONE

AV:N/AC:M/Au:N/C:P/I:N/A:N

0.003 Low

EPSS

Percentile

67.6%

There seems to be two cases that allow directory traversal when using wildcard URL segments that allow rendering view outside view paths.

For example, let say there is a route

get '/help/(*action)’, controller: ‘help’

and a matching controller

class HelpController < ApplicationController
end

This renders all views that are in 'app/views/help’ (assuming default view paths) even when matching action method is not defined.

If an attacker made a request GET /help/../../../Gemfile, ActionView::FileSystemResolver returns Gemfile from project root as the matching view. This simple case can be prevented using Rack::Protection::PathTraversal middleware, but it is not enabled by default in Rails. Also, there could be other mechanisms that may result in rendering views that are outside view path. Not sure if that’s the expected behaviour, but this surprised me.

However, Rack::Protection::PathTraversal can be bypassed using backslashes: GET /help/%5c../%5c../%5c../Gemfile. The resolver uses Dir.glob, which escapes backslashes unless File::FNM_NOESCAPE flag is used. Rack::Protection::PathTraversal won’t intercept '\../' and the resolver treats '\../’ as '../'.

Attached are fixes for the mentioned vulnerabilities with test cases.

4.3 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

MEDIUM

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

NONE

Availability Impact

NONE

AV:N/AC:M/Au:N/C:P/I:N/A:N

0.003 Low

EPSS

Percentile

67.6%