bugtraq - CVE-2017-7192: Starscream library before 2.0.4 allows SSL pinning bypass

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAC5LedKzFANjTM5GnBjtVMU5N_azwC5C6iAHjj6-wesmTttLYA@mail.gmail.com>
Date: Fri, 21 Apr 2017 14:52:36 +0200
From: Security Advisories <security.advisories@...tralway.com>
To: bugtraq@...urityfocus.com
Subject: CVE-2017-7192: Starscream library before 2.0.4 allows SSL pinning bypass

Product: Starscream websocket library
Severity: LOW
CVE Reference: CVE-2017-7192
Type: SSL Pinning bypass / Information disclosure

Abstract
--------

WebSocket.swift in Starscream before 2.0.4 allows an SSL Pinning
bypass because of incorrect management of the certValidated variable
(it can be set to true but cannot be set to false).

Description
-----------

The open-source Starscream library provides a SWIFT implementation of
the websocket framework. It allows iOS applications to send and
receive messages via a dedicated websocket channel.
Applications using the Starscream library (up to and including version
2.0.3) were vulnerable to potential SSL pinning bypass. If an attacker
in a man-in-the-middle position is able to reset an established TCP
connection between the client and server, the subsequent re-connection
will not pin the SSL certificate, allowing traffic interception.

Impact
------

An attacker can achieve traffic interception from a man-in-the-middle
position, first by resetting the TCP connection between the client and
server, and afterwards by injecting an SSL server certificates they
control.

Cause
-----

The code of the library contains a vulnerability whereby the state of
the connection (isValidated) is not properly updated after a
re-connection.
That creates a situation whereby pinning works properly only for the
initial connection.

Solution
--------

Upgrade to version 2.0.4.

Technical details
-----------------

The cause of the problem was incorrect management of the certValidated
variable. The variable starts out with a default value of false after
the class is instantiated, and can be set to true if an HTTP/WS schema
is used OR if the check against the pinned certificates succeeds. The
problem was that the variable was never set to false after a
disconnection if a HTTPS/WS schema is used.
The fix consisted of resetting the variable to false when a connection
is initiated and a secure schema is used.

Credits
-------

Vulnerability was discovered by Lukas Futera and Giuliano Galea of
Centralway Numbrs AG.

Disclosure timeline
-------------------

28.2.2017 Vulnerability reported to vendor
07.3.2017 Vulnerability acknowledgment by vendor
14.3.2017 Vendor published initial patch
28.3.2017 New version released
21.4.2017 Advisory published

-- 
This message is for the attention of the intended recipient(s) only. It may 
contain confidential, proprietary and/or legally privileged information. 
Use, disclosure and/or retransmission of information contained in this 
email may be prohibited. If you are not an intended recipient, you are 
kindly asked to notify the sender immediately (by reply e-mail) and to 
permanently delete this message. Thank you.