[jira] [Resolved] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
[ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-3460. - Resolution: Fixed Fix Version/s: 1.7.1 1.8.0 1.6.3 Okay, [~busbey], this should be fixed now. > Monitor should not allow HTTP TRACE > --- > > Key: ACCUMULO-3460 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3460 > Project: Accumulo > Issue Type: Bug > Components: monitor >Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 >Reporter: Sean Busbey >Assignee: Christopher Tubbs >Priority: Minor > Labels: security > Fix For: 1.6.3, 1.8.0, 1.7.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP > TRACE requests. (ref: [an overview of the general problem > class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf]) > The issue isn't bad unless > * there's a same-origin-policy bypass for the user browser > * there's an auth token we care about > Exploits the bypass the same-origin-policy happen, so it's best to clean up > server side if possible. > The only auth tokens present in the Monitor are when we make use of the > ShellServlet from ACCUMULO-196. We rely on the session state for auth, so > there isn't a risk of leaking auth info directly, but we would leak the > session id. > The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough > for impersonation, but if an attacker can read one requested page we have to > presume they can read another. > We should clean up our configs to disallow HTTP TRACE as a proactive measure. > Marking minor since an attack vector would need an enabling vulnerability on > the client side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-3460) Monitor should not allow HTTP TRACE
[ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-3460. - Resolution: Not A Problem Fix Version/s: (was: 1.7.1) (was: 1.8.0) (was: 1.6.3) Assignee: Christopher Tubbs It looks like this isn't a problem as of 1.6.1. Switching to Jetty 8 and 9 in ACCUMULO-2934 and ACCUMULO-2808, respectively, fixed the issue. Jetty 8 and later disable TRACE by default. > Monitor should not allow HTTP TRACE > --- > > Key: ACCUMULO-3460 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3460 > Project: Accumulo > Issue Type: Bug > Components: monitor >Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0 >Reporter: Sean Busbey >Assignee: Christopher Tubbs >Priority: Minor > Labels: security > > A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP > TRACE requests. (ref: [an overview of the general problem > class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf]) > The issue isn't bad unless > * there's a same-origin-policy bypass for the user browser > * there's an auth token we care about > Exploits the bypass the same-origin-policy happen, so it's best to clean up > server side if possible. > The only auth tokens present in the Monitor are when we make use of the > ShellServlet from ACCUMULO-196. We rely on the session state for auth, so > there isn't a risk of leaking auth info directly, but we would leak the > session id. > The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough > for impersonation, but if an attacker can read one requested page we have to > presume they can read another. > We should clean up our configs to disallow HTTP TRACE as a proactive measure. > Marking minor since an attack vector would need an enabling vulnerability on > the client side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
