drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sorabh Hamirwasia (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5582) [Threat Modeling] Drillbit may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Drillbit
Date Mon, 30 Oct 2017 22:06:00 GMT

    [ https://issues.apache.org/jira/browse/DRILL-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225828#comment-16225828

Sorabh Hamirwasia commented on DRILL-5582:

[~laurentgo] - This change exposed the issue with backward compatibility, In absence of this
change the old server (1.10) was treating new client (1.11) as 1.9 client and doing the authentication
successfully which is not a correct behavior. Reason being with 1.11 we added a new value
for SASL_SUPPORT field (SASL_PRIVACY) in Handshake message which is not known to the 1.10
server hence when it deserialize that field value it is evaluated to default one ([Based on
this post|http://androiddevblog.com/protocol-buffers-pitfall-adding-enum-values/]) which is
UNKNOWN_SASL_SUPPORT. [Since 1.10 UserServer|https://github.com/apache/drill/blob/1.10.0/exec/java-exec/src/main/java/org/apache/drill/exec/rpc/user/UserServer.java#L297]
treats the presence of that default value as an indication of older clients which is not correct.
We should treat absence of the entire field SASL_SUPPORT only to determine if client is old
or not. Presence of the default value should indicate client still support's SASL but at what
level is not known to this server. 

With this approach: 
* clients <= 1.9 will not set SASL_SUPPORT in handshake message and server should detect
it correctly and authenticate the way it was supported in 1.9
* clients > 1.9 will set SASL_SUPPORT field with their supported value and then server
on same or different will deserialize the value to be either UNKNOWN_SASL_SUPPORT or one of
SASL_AUTH/SASL_PRIVACY. In both cases server should still think client supports SASL and speak
it's protocol to require SASL handshake.

I will start a thread in Drill-Dev group.

As far as thread model is concerned, it won't affect much in case of plain authentication
but in cases like Kerberos or mechanisms which does mutual authentication, MITM Drillbit won't
be able to fake the authentication. But without this change MITM Drillbit can make client
to skip authentication totally.

> [Threat Modeling] Drillbit may be spoofed by an attacker and this may lead to data being
written to the attacker's target instead of Drillbit
> ---------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DRILL-5582
>                 URL: https://issues.apache.org/jira/browse/DRILL-5582
>             Project: Apache Drill
>          Issue Type: Bug
>    Affects Versions: 1.10.0
>            Reporter: Rob Wu
>            Assignee: Sorabh Hamirwasia
>            Priority: Minor
>              Labels: doc-impacting
>             Fix For: 1.12.0
> *Consider the scenario:*
> Alice has a drillbit (my.drillbit.co) with plain and kerberos authentication enabled
containing important data. Bob, the attacker, attempts to spoof the connection and redirect
it to his own drillbit (fake.drillbit.co) with no authentication setup. 
> When Alice is under attack and attempts to connect to her secure drillbit, she is actually
authenticating against Bob's drillbit. At this point, the connection should have failed due
to unmatched configuration. However, the current implementation will return SUCCESS as long
as the (spoofing) drillbit has no authentication requirement set.
> Currently, the drillbit <-  to  -> drill client connection accepts the lowest authentication
configuration set on the server. This leaves unsuspecting user vulnerable to spoofing. 

This message was sent by Atlassian JIRA

View raw message