[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)
