Vulnerabilities > CVE-2018-3925 - Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability in Samsung Sth-Eth-250 Firmware 0.20.17
Attack vector
NETWORK Attack complexity
LOW Privileges required
LOW Confidentiality impact
HIGH Integrity impact
HIGH Availability impact
HIGH Summary
An exploitable buffer overflow vulnerability exists in the remote video-host communication of video-core's HTTP server of Samsung SmartThings Hub STH-ETH-250 devices with firmware version 0.20.17. The video-core process insecurely parses the AWSELB cookie while communicating with remote video-host servers, leading to a buffer overflow on the heap. An attacker able to impersonate the remote HTTP servers could trigger this vulnerability.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| OS | 1 | |
| Hardware | 1 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Buffer Overflow via Environment Variables This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
- Overflow Buffers Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an attacker. As a consequence, an attacker is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the attackers' choice.
- Client-side Injection-induced Buffer Overflow This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service.
- Filter Failure through Buffer Overflow In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered).
- MIME Conversion An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back.
Seebug
| bulletinFamily | exploit |
| description | ### Summary An exploitable buffer overflow vulnerability exists in the remote video-host communication of `video-core`'s HTTP server of Samsung SmartThings Hub. The `video-core` process insecurely parses the AWSELB cookie while communicating with remote video-host servers, leading to a buffer overflow on the heap. An attacker able to impersonate the remote HTTP servers could 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](https://www.smartthings.com/products/smartthings-hub) ### CVSSv3 Score 8.5 - CVSS:3.0/AV:N/AC:H/PR:L/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 request that can be exploited to achieve code execution on the `video-core` process, which is running as root. By sending a PUT request for the `/cameras/<camera-id>/streams/<stream-type>` path, it's possible to make the hub to start streaming the camera's video (specified by the "camera-id") towards the remote servers. The "stream-type" can have multiple values and represent the kind of stream requested, for example it could be set to "hls1080p". The following is an example of such request: $ curl "http://127.0.0.1:3000/cameras/<camera-id>/streams/hls1080p" -d '{"streamClass":"hls2segs","oauthToken":"Bearer <oauth-token>"}' Note that the "oauth-token" is an OAuth 2.0 Bearer Token (canonical UUID), provided by auth-global.api.smartthings.com. Such a request is handled by function `sub_4B078`, which in turn calls `sub_4CDC4` for setting up the communication with a remote video-host server and providing the remote streaming feature: .text:0004CDC4 sub_4CDC4 .text:0004CDC4 .text:0004CDC4 var_228= -0x228 .text:0004CDC4 var_224= -0x224 .text:0004CDC4 var_220= -0x220 .text:0004CDC4 var_21C= -0x21C .text:0004CDC4 var_218= -0x218 .text:0004CDC4 var_214= -0x214 .text:0004CDC4 var_210= -0x210 .text:0004CDC4 ptr = -0x20C .text:0004CDC4 s = -0x208 .text:0004CDC4 .text:0004CDC4 000 STMFD SP!, {R4-R11,LR} .text:0004CDC8 024 MOV R3, #0 .text:0004CDCC 024 SUB SP, SP, #0x204 .text:0004CDD0 228 MOV R7, R1 .text:0004CDD4 228 MOV R4, R0 .text:0004CDD8 228 STR R2, [SP,#0x228+var_220] .text:0004CDDC 228 STR R3, [SP,#0x228+var_210] .text:0004CDE0 228 STR R3, [SP,#0x228+ptr] .text:0004CDE4 228 BL http_resp_packer__buffer_init .text:0004CDE8 228 MOV R1, #:lower16:aStreamclassHls ; "{\"streamClass\": \"hls2segs\"}" .text:0004CDEC 228 MOV R9, R0 .text:0004CDF0 228 MOVT R1, #:upper16:aStreamclassHls ; "{\"streamClass\": \"hls2segs\"}" .text:0004CDF4 228 BL http_build_answer ; [1] ... .text:0004CE98 228 BL http_stream_curl_request ; [2] ... .text:0004CEDC 228 ADD R1, R7, #0x1200 .text:0004CEE0 228 STR R3, [R4,#0x8F4] .text:0004CEE4 228 ADD R2, R7, #0xC .text:0004CEE8 228 ADD R1, R1, #0x10 .text:0004CEEC 228 LDR R0, [SP,#0x228+var_218] .text:0004CEF0 228 BL sub_4C570 ; [3] At [1], the function starts to build an answer for the request that is being handled. The answer is composed by a JSON string, which will be filled by the answer from the request at [2]. The request [2] is a remote request toward a video-host server: the server's address is stored in `video-core`'s database, and in the hub that we tested this address is "https://vh-na04-useast2.connect.smartthings.com:8300". The communication generated at [2] is the following: - video-core --> https://vh-na04-useast2.connect.smartthings.com:8300 PUT /cameras/<camera-id>/streams/hls1080p HTTP/1.1 Host: vh-na04-useast2.connect.smartthings.com:8300 Accept: */* Content-Type: application/json Authorization: Bearer <oauth-token> Content-Length: 27 Connection: close {"streamClass": "hls2segs"} - https://vh-na04-useast2.connect.smartthings.com:8300 --> video-core HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept Access-Control-Allow-Methods: GET, POST, PUT, PATCH, OPTIONS, DELETE Access-Control-Allow-Origin: * Cache-control: no-cache="set-cookie" Content-Type: text/html; charset=utf-8 ETag: W/"5T7hZ36v7ulr9v0HTY4E2g==" Server: nginx/1.12.0 Set-Cookie: AWSELB=4D83E80E23DA7677A73134EC01A12610C0D45FFDF9389B9D15CD82A43087013F829D09859E3CA0909290FDFFE8AEEB654FC7CEE34F9A088ABB9A8D69753700706BCB37AE10;PATH=/;MAX-AGE=1800 X-Powered-By: Express Content-Length: 1288 Connection: Close <json-with-streaming-information> The HTTP body in the response contains a series of parameters that allow for pushing the camera stream remotely. Moreover, we can see that a cookie with name "AWSELB" is set. At [3], function `sub_4C570` parses the cookies, extracting the value of "AWSELB" if present. .text:0004C570 sub_4C570 .text:0004C570 .text:0004C570 var_210= -0x210 .text:0004C570 var_20C= -0x20C .text:0004C570 var_208= -0x208 .text:0004C570 save_ptr= -0x204 .text:0004C570 s = -0x200 .text:0004C570 .text:0004C570 000 STMFD SP!, {R4-R9,LR} .text:0004C574 01C MOV R8, #debug_log .text:0004C57C 01C MOV R9, R2 .text:0004C580 01C MOV R2, #0 .text:0004C584 01C SUB SP, SP, #0x1F4 .text:0004C588 210 LDR R3, [R8] .text:0004C58C 210 MOV R4, R0 .text:0004C590 210 MOV R6, R1 .text:0004C594 210 STR R2, [R9] .text:0004C598 210 CMP R3, #2 .text:0004C59C 210 BHI loc_4C6CC .text:0004C5A0 .text:0004C5A0 loc_4C5A0 .text:0004C5A0 210 MOV R1, #:lower16:0x40001C .text:0004C5A4 210 MOV R0, R4 .text:0004C5A8 210 MOVT R1, #:upper16:0x40001C ; CURLINFO_COOKIELIST .text:0004C5AC 210 ADD R2, SP, #0x210+var_208 .text:0004C5B0 210 BL curl_easy_getinfo ; [4] .text:0004C5B4 210 CMP R0, #0 .text:0004C5B8 210 BNE loc_4C71C .text:0004C5BC 210 LDR R7, [SP,#0x210+var_208] .text:0004C5C0 210 CMP R7, #0 .text:0004C5C4 210 BEQ loc_4C6A4 .text:0004C5C8 .text:0004C5C8 loc_4C5C8 .text:0004C5C8 210 MOV R1, #:lower16:asc_C6C8C ; " \t" .text:0004C5CC 210 LDR R0, [R7] .text:0004C5D0 210 MOVT R1, #:upper16:asc_C6C8C ; " \t" .text:0004C5D4 210 ADD R2, SP, #0x210+save_ptr .text:0004C5D8 210 BL __strtok_r ; [5] .text:0004C5DC 210 SUBS R4, R0, #0 .text:0004C5E0 210 BEQ loc_4C698 .text:0004C5E4 .text:0004C5E4 loc_4C5E4 .text:0004C5E4 210 MOV R0, R4 .text:0004C5E8 210 BL strlen .text:0004C5EC 210 CMP R0, #6 .text:0004C5F0 210 MOV R1, R4 .text:0004C5F4 210 MOVCC R2, R0 .text:0004C5F8 210 MOV R0, #:lower16:aAwselb ; "AWSELB" .text:0004C5FC 210 MOVCS R2, #6 .text:0004C600 210 MOVT R0, #:upper16:aAwselb ; "AWSELB" .text:0004C604 210 BL strncmp ; [6] .text:0004C608 210 MOV R1, #:lower16:asc_C6C8C ; " \t" .text:0004C60C 210 MOV R5, R0 .text:0004C610 210 ADD R2, SP, #0x210+save_ptr .text:0004C614 210 MOV R0, #0 .text:0004C618 210 MOVT R1, #:upper16:asc_C6C8C ; " \t" .text:0004C61C 210 BL __strtok_r .text:0004C620 210 SUBS R4, R0, #0 .text:0004C624 210 BEQ loc_4C698 .text:0004C628 210 CMP R5, #0 .text:0004C62C 210 BNE loc_4C5E4 .text:0004C630 210 MOV R1, R4 .text:0004C634 210 MOV R0, R6 .text:0004C638 210 BL strcpy ; [7] .text:0004C63C 210 MOV R0, R6 .text:0004C640 210 BL strlen .text:0004C644 210 LDR R3, [R8] .text:0004C648 210 STR R0, [R9] .text:0004C64C 210 CMP R3, #2 .text:0004C650 210 BLS loc_4C5E4 At [4] the function `curl_easy_getinfo` is called for extracting the list of cookies, which will be stored in `var_208`. Then, by using `strtok` [5], the function loops over all the cookies' values in the response, and if any one of them starts with the string "AWSELB" [6], its value is copied using `strcpy` [7] into the heap buffer passed as parameter, which has a size of 512 bytes. Since the cookies are controlled by the remote server and there is no restriction on the length of the copy operation, anyone able to impersonate a video-host server could be able to overflow the heap buffer and execute arbitrary code. ### 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 |
| id | SSV:97448 |
| last seen | 2018-07-31 |
| modified | 2018-07-30 |
| published | 2018-07-30 |
| reporter | My Seebug |
| title | Samsung SmartThings Hub video-core AWSELB Cookie Code Execution Vulnerability(CVE-2018-3925) |
Talos
| id | TALOS-2018-0591 |
| last seen | 2019-05-29 |
| published | 2018-07-26 |
| reporter | Talos Intelligence |
| source | http://www.talosintelligence.com/vulnerability_reports/TALOS-2018-0591 |
| title | Samsung SmartThings Hub video-core AWSELB Cookie Code Execution Vulnerability |