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