ID CVE-2016-3829
Summary The ih264d decoder in mediaserver in Android 6.x before 2016-08-01 does not initialize certain structure members, which allows remote attackers to cause a denial of service (device hang or reboot) via a crafted media file, aka internal bug 29023649.
References
Vulnerable Configurations
  • cpe:2.3:o:google:android:6.0:*:*:*:*:*:*:*
    cpe:2.3:o:google:android:6.0:*:*:*:*:*:*:*
  • cpe:2.3:o:google:android:6.0.1:*:*:*:*:*:*:*
    cpe:2.3:o:google:android:6.0.1:*:*:*:*:*:*:*
CVSS
Base: 7.1 (as of 28-11-2016 - 20:12)
Impact:
Exploitability:
CWE CWE-172
CAPEC
  • Leverage Alternate Encoding
    This attack leverages the possibility to encode potentially harmful input and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult.
  • Using Leading 'Ghost' Character Sequences to Bypass Input Filters
    An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targeted, ignores the leading "ghost" characters, and therefore processes the attackers' input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API. Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes. One commonly used possibility involves adding ghost characters--extra characters that don't affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations.
  • Embedding NULL Bytes
    An attacker embeds one or more null bytes in input to the target software. This attack relies on the usage of a null-valued byte as a string terminator in many environments. The goal is for certain components of the target software to stop processing the input when it encounters the null byte(s).
  • Postfix, Null Terminate, and Backslash
    If a string is passed through a filter of some kind, then a terminal NULL may not be valid. Using alternate representation of NULL allows an attacker to embed the NULL mid-string while postfixing the proper data so that the filter is avoided. One example is a filter that looks for a trailing slash character. If a string insertion is possible, but the slash must exist, an alternate encoding of NULL in mid-string may be used.
  • Using Slashes and URL Encoding Combined to Bypass Validation Logic
    This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
  • Using Unicode Encoding to Bypass Validation Logic
    An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.
  • URL Encoding
    This attack targets the encoding of the URL. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc. The attacker could also subvert the meaning of the URL string request by encoding the data being sent to the server through a GET request. For instance an attacker may subvert the meaning of parameters used in a SQL request and sent through the URL string (See Example section).
  • Using Escaped Slashes in Alternate Encoding
    This attack targets the use of the backslash in alternate encoding. An attacker can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the attacker tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
  • Using UTF-8 Encoding to Bypass Validation Logic
    This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters.
Access
VectorComplexityAuthentication
NETWORK MEDIUM NONE
Impact
ConfidentialityIntegrityAvailability
NONE NONE COMPLETE
cvss-vector via4 AV:N/AC:M/Au:N/C:N/I:N/A:C
refmap via4
bid 92221
confirm
Last major update 28-11-2016 - 20:12
Published 05-08-2016 - 20:59
Back to Top