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