[
https://issues.apache.org/jira/browse/DRILL-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225474#comment-16225474
]
Laurent Goujon commented on DRILL-5582:
---------------------------------------
It seems this change is backward incompatible (newer JDBC/C++ connector cannot
be used with an older server server). I'm not sure to follow the threat model
either: since there's no server authentication (something TLS would solve),
what prevents a MITM drillbit to just fake authentication?
> [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
(v6.4.14#64029)
