Return-Path: 
 <notifications-return-26720-apmail-accumulo-notifications-archive=accumulo.apache.org@accumulo.apache.org>
X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 0F6FA10B5E
	for <apmail-accumulo-notifications-archive@minotaur.apache.org>;
 Wed, 31 Dec 2014 21:53:13 +0000 (UTC)
Received: (qmail 79238 invoked by uid 500); 31 Dec 2014 21:53:13 -0000
Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org
Received: (qmail 79191 invoked by uid 500); 31 Dec 2014 21:53:13 -0000
Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@accumulo.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@accumulo.apache.org>
List-Post: <mailto:notifications@accumulo.apache.org>
List-Id: <notifications.accumulo.apache.org>
Reply-To: jira@apache.org
Delivered-To: mailing list notifications@accumulo.apache.org
Received: (qmail 79170 invoked by uid 99); 31 Dec 2014 21:53:13 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Dec 2014 21:53:13 +0000
Date: Wed, 31 Dec 2014 21:53:13 +0000 (UTC)
From: "Sean Busbey (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12764428.1420061961000.123271.1420062793152@Atlassian.JIRA>
In-Reply-To: <JIRA.12764428.1420061961000@Atlassian.JIRA>
References: <JIRA.12764428.1420061961000@Atlassian.JIRA>
 <JIRA.12764428.1420061961676@arcas>
Subject: [jira] [Commented] (ACCUMULO-3460) Monitor should not allow HTTP
 TRACE
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262454#comment-14262454 ] 

Sean Busbey commented on ACCUMULO-3460:
---------------------------------------

Here's a redacted version of me replicating the Nessus probe against an ssl-enabled monitor on a cluster running the current master branch.

{code}
[busbey@gateway ~]$ openssl s_client -connect monitor.example.com:50095
CONNECTED(00000003)
<snip server cert info>
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 1499 bytes and written 499 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: 54A465E965F7EF56A3A7FB43942B8EB0A8105E23EED078DA7AB8D15FC811F82C
    Session-ID-ctx:
    Master-Key: 75F2F0B204A4CF15A8020CE64DA44F78E2F7FE6D379EF5F42C3F6E8C68536CC55FD432962D4416F8F0176EF131807C9B
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1420060137
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
TRACE /Nessus1536302595.html HTTP/1.1
Connection: Close
Host: monitor.example.com
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Authorization: Basic YWRtaW46YWRtaW4=

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 371
Connection: close
Server: Jetty(9.1.5.v20140505)

TRACE /Nessus1536302595.html HTTP/1.1
Accept-Language: en
Authorization: Basic YWRtaW46YWRtaW4=
Host: monitor.example.com
Accept-Charset: iso-8859-1,*,utf-8
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
Connection: close
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Pragma: no-cache
closed
{code}

What we want is to not get a response of HTTP/1.1 200 OK with the contents echoed back. Ideally we'd get rejected with a message that TRACE isn't allowed, but an empty response would probably be fine.

> 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, 1.6.1, 1.6.2
>            Reporter: Sean Busbey
>            Priority: Minor
>              Labels: security
>             Fix For: 1.5.3, 1.7.0, 1.6.3
>
>
> 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)