Kernel region URL filtering vulnerability affects Samsung Note 3, Galaxy S6 (CVE-2016-2036)

Kernel region URL filtering vulnerability affects Samsung Note 3, Galaxy S6 (CVE-2016-2036)

A Bug that affects Samsung Note 3 and Galaxy S6 mobile phones-what is the problem with URL filtering in the kernel? Author: Robert Paleari (@ rpaleari) and Aristide Fattori (@ joystick) ID: CVE-2016-2036 notification date: Release Date: When studying Samsung's Android kernel, we found a module named secfilter. The initialization program of this module attracts our attention because some Netfilter hooks are registered in this module.
...
Static struct nf_queue_handler sec_url_queue_handler = {
. Name = SEC_MODULE_NAME,
. Outfn = sec_url_filter_slow
};
Static struct nf_hook_ops sec_url_filter = {
. Hook = sec_url_filter_hook,
. Pf = PF_INET,
. Hooknum = NF_INET_LOCAL_OUT,
. Priority = NF_IP_PRI_FIRST
};
Static struct nf_hook_ops sec_url_recv_filter = {
. Hook = sec_url_filter_recv_hook,
. Pf = PF_INET,
. Hooknum = NF_INET_LOCAL_IN,
. Priority = NF_IP_PRI_FIRST
};
...
If (add_send_hook = nf_register_hook (& sec_url_filter ))
These hooks are configured to block all incoming (NF_INET_LOCAL_IN) and all outgoing (NF_INET_LOCAL_OUT) packages. After being intercepted, the TCP packet that matches the output of a specific condition eventually reaches an internal function named getURL (). This function checks whether the TCP data is similar to an HTTP request, and parse the included URL. Why does Samsung send URL parameters to the Android kernel? This is part of the application access mechanism from the user space. Possible exploitation applications include parent-controlled applications that require system-level URL filtering. How does it work? The Netfilter hook always exists, but the URL filtering mechanism is enabled only after the appropriate ioctl () request is sent to the user space device/dev/url. In our test machine, this device is an access Member of the secnetfilter group:
Shell @ hlte:/$ ls-l/dev/url
Crw-rw ---- secnetfilter 226, 0 url
In turn, the permission to access the secnetfilter group is granted to the application through the com. sec. andtroid. SAMSUNG_GET_URL permission and a protection-level signature is created. An app with this permission can configure devices to use different monitoring modes:
FILTER_MODE_ON_BLOCK: Standard blocking mode. Check whether the URL's outgoing data packet is blocked.
FILTER_MODE_ON_RESPONSE: extracts the URL from the outgoing packet instead of the blocking mode, but the response is blocked and replaced with a custom HTTP/404.
FILTER_MODE_ON_BLOCK_REFER: Same as FILTER_MODE_ON_BLOCK, but check the Referer header instead of the requested URL.
FILTER_MODE_ON_RESPONSE_REFER: Same as FILTER_MODE_ON_RESPONSE, but check the Referer header instead of the request URL.
If any blocking mode is implemented, each accessed URL will be put into the queue and blocked until the app stops blocking it. An app that wants to use the RUL filtering function should implement the following logic: first, the app can use a blocking mode, such as writing the following binary data to/dev/rul:
Then, the app polls at/dev/url until some data is readable. The format for reading data is as follows:
Finally, the app checks the URL and makes a decision based on some specific application logic. It tells the driver of the decision and writes the following bytes to/dev/url:
The kernel module reads integers (for example, filterMode = * (int *) data) from the cache by referencing them directly. Therefore, the data must be in little-endian format. When the kernel module receives a SET_USER_SELECT command, it checks whether it receives the ID of the corresponding blocked request (for example, corresponding to a blocked TCP stream) and acts on it according to the app's decision. At present, we have only determined the name of com. symantec. the familysatety application uses this permission, so all URL filtering mechanisms may not be very extensive, or it is still in the early stages of development.
As described above, only some applications in the Samsung app store can obtain the SAMSUNG_GET_URL permission. This module should attract the attention of Samsung users. He put on the coat of "Protecting Children", but it is still a URL that allows "authorized" applications to monitor all access. In short, in addition to morality and privacy, this module is quite worrying from the technical point of view. Indeed, after the URL filtering mechanism has been started by the "authorized" app, any user space application can trigger a null pointer reference in the HTTP parsing code, leading to system crash. It is very easy to trigger this bug. You only need to use an HTTP request without a URL, for example:
Gethttp/1.1
Host: www.google.com
The actual purpose of such a request is irrelevant, because when URL filtering can be implemented, all outgoing HTTP traffic needs to be checked. From a technology perspective, Samsung uses its open-source release center to open up their Android kernel code. For the NULL pointer reference mentioned above, the vulnerability code is in drivers/secfilter/urlparser. c, function getURL (). In summary, this module extracts the HTTP request path through the following calls:
FindStringByTag (node, & (node-> url), dataStart, "HTTP /");
DataStart is a char string that points to it after the token of the http request method. However, when findStringByTag () processes harmful requests, it finds a string with a zero length for the HTTP path and leaves uninitialized node-> url. After a few lines, the node-> url is discarded and empty at this time.
Affected device we confirm that this problem affects the following device models. Other models and firmware versions may also be affected, but we have not tested them yet. SM-N9005, Build N9005XXUGBOB6 (Note 3) SM-G920F, Build G920FXXU2COH2 (Galaxy S6)