SSD Advisory – Linux BlueZ Information Leak and Heap Overflow

(This advisory follows up on a presentation provided during our offensive security event in 2018 in Hong Kong – come join us at TyphoonCon –  June 2019 in Seoul for more offensive security lectures and training)
Vulnerabilities Summary
The following advisory discuss about two vulnerabilities found in Linux BlueZ bluetooth module.
One of the core ideas behind Bluetooth is allowing interoperability
between a wide range of devices from different manufacturers. This is one
of the reasons that the Bluetooth specification is extremely long and complex.
Detailed descriptions of a wide range of protocols that support all common use-cases ensure that different Bluetooth implementations can work together. However, from an attackers point of view this also means that there is a lot of unneeded complexity in the Bluetooth stack which provides a large attack surface. Due to the modular nature of Bluetooth, some critical features such as packet fragmentation are found redundantly in multiple protocols that are part of the Bluetooth core specification. This makes correct implementation very complicated and increases the likelihood of security issues.
Vendor Response
We have contacted the Bluez maintainer on 23/8/2018 and sent a report describing the two vulnerabilities. The vendor responded “I got the message and was able to decrypt it, but frankly I don’t know when I get to look at it at confirm the issue.”. We have sent few more emails to the vendor since the first report and also proposed patches for the vulnerabilities but no fix has been issued until the day of writing this post. Proposed patches have been provided by, Luiz Augusto von Dentz, at the bottom of this advisory.
An independent security researcher, Julian Rauchberger, has reported this vulnerability to SSD Secure Disclosure program.

Affected systems
Linux systems with BlueZ module with versions 5.17-5.48 (latest at the time of writing this advisory)
Vulnerability Details
To support the huge range of potential use cases for Bluetooth, the specification describes many different protocols. For the vulnerabilities detailed in this advisory, we will focus on two core protocols: L2CAP and SDP.
Simply speaking, L2CAP can be seen as the TCP layer of Bluetooth. It is
responsible for implementing low-level features such as multiplexing and
flow control. What would be called a “port” in TCP is the “Protocol/Service
Multiplexer” (PSM) value in L2CAP. Authentication and Authorization is
generally handled on higher layers, meaning that an attacker can open a
L2CAP connection to any PSM they want and send whatever crafted packets
they wish. From a technical point of view, BlueZ implements L2CAP inside
the kernel as a module.
SDP is the Service Discovery Protocol. It is implemented above L2CAP as a
“service” running on PSM 0x0001. Since the PSM is only a 16-bit number, it is not possible to assign a unique PSM to every Bluetooth service imaginable. SDP can translate globally unique UUIDs to a dynamic PSM used on a specific device.
For instance, a vendor specific service has the same UUID on all devices but
might run on PSM 0x0123 on device A and PSM 0x0456 on device B. It is the job of SDP to provide this information to devices that wish to connect to the service.
* Device A opens a L2CAP connection to PSM 0x0001 (SDP) on device B
* Device A asks “what is the PSM for the service with UUID 0x12345678?”
* Device B responds with “PSM 0x1337”
* Device A opens an L2CAP connection to PSM 0x1337
SDP is also used to advertise all the Bluetooth Profiles (services/features) a
device supports. It can be queried to send a list of all services running
on the device as well as their attributes (mostly simple key/value pairs).
The SDP protocol is implemented in a userspace daemon by BlueZ. Since it
requires high privileges, this daemon normally runs as root, meaning
vulnerabilities should result in full system compromise in most cases.
PoC’s and Testing Environment
The PoC’s attached at the end of this advisory have been tested against
BlueZ 5.48 (the newest version at the time of writing), BlueZ 5.17 (a very old version from 2014), as well as a few in between.
The PoC’s have been written for Python 2.7 and have two dependencies, please install them first:
* pybluez (to send Bluetooth packets)
* pwntools (for easier crafting of packets and hexdump())
run them with:
(where XX:XX:XX:XX:XX:XX is the Bluetooth MAC address of the victim device)
Please ensure that the Bluetooth is activated and the device is discoverable (called “visible” in most of the GUIs)
It might be necessary to update the SERVICE_REC_HANDLE and/or SERVICE_ATTR_ID to get the PoC’s to work. These values can differ between devices. They are advertised by SDP so it could be automated to find them but we didn’t implemented that. Detailed information is inside the comments of the PoC’s.
Vulnerability 1: SDP infoleak
Note: All line numbers and filenames referenced here were taken from BlueZ 5.48 which is the newest version at the time of writing.
The vulnerability lies in the handling of a SVC_ATTR_REQ by the SDP implementation of BlueZ. By crafting a malicious CSTATE, it is possible to trick the server into returning more bytes than the buffer actually holds, resulting in leaking arbitrary heap data.
This vulnerability demonstrates very well issues arising due to the
aforementioned complexity caused by the redundant implementation of some features in multiple protocols.
Even though L2CAP already provides sufficient fragmentation features, SDP
defines its own. However, incorrect implementation in BlueZ leads to a
significant information leak.
One of the features of SDP is to provide the values of custom attributes a
service might have. The client sends the ID of an attribute and SDP responds with the corresponding value.
If the response to an attribute request is too large to fit within a single
SDP packet, a “Continuation State” (cstate) is created.
Here is how it should work in theory:


SSD Advisory – iOS/macOS Safari Sandbox Escape via QuartzCore Heap Overflow

Vulnerabilities Summary
QuartzCore ( ), also known as CoreAnimation, is a framework use by macOS and iOS to build an animatable scene graph. CoreAnimation uses a unique rendering model where the grapohics operations are run in a separate process. On macOS, the process is WindowServer and on iOS the name is backboardd. Both of these process are out of sandbox and have the right to call setuid. The service name QuartzCore is usually referenced as CARenderServer. This service exists on both macOS and iOS and can be accessed from the Safarisandbox and therefore has been used for Pwn2Own on many occasions. There exists an integer overflow which can lead to heap over flow in QuartzCore on latest macOS/iOS.
Vendor Response
“CoreAnimation Impact: An application may be able to execute arbitrary code with system privileges Description: A memory corruption issue was addressed with improved memory handling. CVE-2018-4415: Beyond Security’s SecuriTeam Secure Disclosure”
An independent Security Researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

SSD Advisory – Python Bytecode Disassembler and Decompiler (pycdc) Multiple Vulnerabilities

Vulnerabilities summary
The following advisory describes 12 (twelve) vulnerabilities found in Python Bytecode Disassembler and Decompiler (pycdc).
Python Bytecode Disassembler and Decompiler (pycdc) “aims to translate compiled Python byte-code back into valid and human-readable Python source code. While other projects have achieved this with varied success, Decompyle++ is unique in that it seeks to support byte-code from any version of Python.”
The vulnerabilities found are:

  • Heap buffer overflow (2)
  • Null pointer (8)
  • Global buffer overflow
  • Singed integer overflow

An independent security researcher from Geeknik Labs has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
Michael Hansen was informed of the vulnerability and release a patches to address them.
For more details:
At this time we will not disclose PoC – we may release these later when users of the python code have updated their systems.


GraphicsMagick是“图像处理方面的瑞士军刀。 基础包中的源码共有267K行(根据David A. Wheeler统计),它提供了强大而有效的工具和库,支持读,写超过88种主要图像处理格式,包括DPX,GIF,JPEG,JPEG-2000,PNG,PDF,PNM和TIFF等重要格式。

  • 内存信息泄露
  • 堆溢出

一位独立的安全研究人员Jeremy Heng(@nn_amon)和Terry Chia(Ayrx)向 Beyond Security 的 SSD 报告了该漏洞
厂商已经发布了这些漏洞的补丁(15237:e4e1c2a581d8 and 15238:7292230dd18)。获取更多信息:

SSD Advisory – GraphicsMagick Multiple Vulnerabilities

Vulnerabilities summary
The following advisory describes two (2) vulnerabilities found in GraphicsMagick.
GraphicsMagick is “The swiss army knife of image processing. Comprised of 267K physical lines (according to David A. Wheeler’s SLOCCount) of source code in the base package (or 1,225K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 88 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, and TIFF.”
The vulnerabilities found are:

  • Memory Information Disclosure
  • Heap Overflow

An independent security researchers, Jeremy Heng (@nn_amon) and Terry Chia (Ayrx), has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program
Vendor response
The vendor has released patches to address these vulnerabilities (15237:e4e1c2a581d8 and 15238:7292230dd18).
For more details:
CVE-2017-16352, CVE-2017-16353