bugtraq - CVE-2017-5887: Starscream library before 2.0.4 SSL pinning not applied for websocket handshake

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: <CAC5Led+ipO1LDrU7EkwRTj4ouPaBk78JBhaaUUNuDjqUXUa8iQ@mail.gmail.com>
Date: Fri, 21 Apr 2017 18:14:20 +0200
From: Security Advisories <security.advisories@...tralway.com>
To: bugtraq@...urityfocus.com
Subject: CVE-2017-5887: Starscream library before 2.0.4 SSL pinning not
 applied for websocket handshake

Product: Starscream websocket library
Severity: LOW
CVE Reference: CVE-2017-5887
Type: SSL Pinning bypass

Abstract
--------

WebSocket.swift in Starscream before 2.0.4 allows an SSL Pinning
bypass because pinning occurs in the stream function (this is too
late; pinning should occur in the initStreamsWithData function).

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 information disclosure due to an
incorrect implementation of SSL pinning during the websocket
handshake.

Impact
------

An attacker can intercept the initial websocket handshake GET request,
which may potentially contain sensitive information (e.g. session
tokens, cookies). An attacker could possibly misuse this information
to attack the target application.

Cause
-----

The code of the library contains a vulnerability whereby the SSL
pinning is executed only on the websocket TCP connection itself, but
not for the initial handshake request.

Solution
--------

Upgrade to version 2.0.4.

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

The cause of the problem was in the implementation of the initial
connection (referencing initStreamsWithData version 1.1.4 where we
first discovered the issue). After configuring the streams with the
SSL context, the method proceeds to open the connection and writes the
initial upgrade connection directly to the stream as soon as
hasSpaceAvailable returns true. The actual pinning is done only after
the initial connection is established.
The fix consisted in checking the pinned certificates BEFORE any byte
is sent through the stream and closing the connection immediately if
the check fails.

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.