From: shibata.hiroshi@... Date: 2014-01-30T06:16:31+00:00 Subject: [ruby-core:60261] [ruby-trunk - Bug #5418] Some properties of WEBrick::HTTPRequest could be malformed Issue #5418 has been updated by Hiroshi SHIBATA. Target version changed from 2.1.0 to current: 2.2.0 ---------------------------------------- Bug #5418: Some properties of WEBrick::HTTPRequest could be malformed https://bugs.ruby-lang.org/issues/5418#change-44740 * Author: Hiroshi Nakamura * Status: Assigned * Priority: Normal * Assignee: Hiroshi Nakamura * Category: lib * Target version: current: 2.2.0 * ruby -v: - * Backport: ---------------------------------------- Original reported issue: CVE-2011-3187 Users may expect that properties of WEBrick::HTTPRequest to be not malformed/faked. But at the fact, in current implementation, following properties can be malformed and faked by HTTP header sent by attacker. - HTTPRequest#host - can be malformed/faked by 'x-forwarded-host' - can be faked by 'Host' - HTTPRequest#port - can be faked by 'Host' - HTTPRequest#server_name - can be malformed/faked by 'x-forwarded-server' - HTTPRequest#remote_ip - can be malformed/faked by 'x-forwarded-for' and 'client-ip' - HTTPRequest#ssl? - can be faked by 'Host' - HTTPRequest#meta_vars (Hash of meta vars such as 'REQUEST_URI') - can be malformed/faked by some HTTP headers Here's the list of reason why we're thinking it's not a high-priority security bug at this moment. - For faked data issue, we don't have a way to guarantee that it's not faked. So developers of HTTPRequest must aware of that. - For malformed data issue, it should be a bug of HTTPRequest to be fixed, but it's the same problem for x-forwarded-host, x-forwarded-server and client-ip. We're offering those data in as-is basis from HTTP header so we can expect users handle the data properly for their purpose (for dumping to xterm, embedding to HTML, etc.) - And the fix for this bug would be a little complex for quick-fix because it's not only x-forwarded-for which causes this issue. 'client-ip' needs care, too. Documentation would be enough for server_name. We think we need general development cycle for fixing it. ref: https://bugzilla.novell.com/show_bug.cgi?id=673010 http://webservsec.blogspot.com/2011/02/ruby-on-rails-vulnerability.html -- http://bugs.ruby-lang.org/