Thanks much.
Ying

On Tue, May 30, 2017 at 1:07 PM, Thejas Nair <thejas.n...@gmail.com> wrote:

> It went in under guise of the jira - HIVE-13390.
> Commit - https://github.com/apache/hive/commit/
> 3b2ea248078bdf3a8372958cf51a989dc3883bcc
>
> On Tue, May 30, 2017 at 12:35 PM, Ying Chen <ying.in...@gmail.com> wrote:
>
>> Hello -
>> Was there a particular JIRA(s) that went into Hive 1.2.2 that fixed this
>> issue?
>> Thanks much.
>> Ying
>>
>>
>> On Wed, May 24, 2017 at 3:56 PM, Vaibhav Gumashta <
>> vgumas...@hortonworks.com> wrote:
>>
>>> Severity: Important
>>>
>>> Vendor: The Apache Software Foundation
>>>
>>> Versions Affected:
>>> Apache Hive 0.13.x
>>> Apache Hive 0.14.x
>>> Apache Hive 1.0.0 - 1.0.1
>>> Apache Hive 1.1.0 - 1.1.1
>>> Apache Hive 1.2.0 - 1.2.1
>>> Apache Hive 2.0.0
>>>
>>> Description:
>>>
>>> Apache Hive (JDBC + HiveServer2) implements SSL for plain TCP and HTTP
>>> connections (it supports both transport modes). While validating the
>>> server’s certificate during the connection setup, the client doesn’t seem
>>> to be verifying the common name attribute of the certificate. In this way,
>>> if a JDBC client sends an SSL request to server abc.com, and the server
>>> responds with a valid certificate (certified by CA) but issued to
>>> xyz.com, the client will accept that as a valid certificate and the SSL
>>> handshake will go through.
>>>
>>> Mitigation:
>>>
>>> Upgrade to Apache Hive 1.2.2 for 1.x release line, or to Apache Hive
>>> 2.0.1 or later for 2.0.x release line, or to Apache Hive 2.1.0 and later
>>> for 2.1.x release line.
>>>
>>> Credit: This issue was discovered by Branden Crawford from Inteco
>>> Systems Limited (inetco.com).
>>>
>>
>>
>

Reply via email to