CVE-2015-5568 : Detail

CVE-2015-5568

A03-Injection
22.22%V4
Network
2015-09-22
08h00 +00:00
2017-02-16
09h57 +00:00
CVE.org
NVD
Notifications for a CVE
Stay informed of any changes for a specific CVE.
Notifications manage

CVE Descriptions

Adobe Flash Player before 18.0.0.241 and 19.x before 19.0.0.185 on Windows and OS X and before 11.2.202.521 on Linux, Adobe AIR before 19.0.0.190, Adobe AIR SDK before 19.0.0.190, and Adobe AIR SDK & Compiler before 19.0.0.190 allow attackers to cause a denial of service (vector-length corruption) or possibly have unspecified other impact via unknown vectors.

CVE Informations

Related Weaknesses

CWE-ID Weakness Name Source
CWE-20 Improper Input Validation
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Metrics

Metrics Score Severity CVSS Vector Source
V2 10 AV:N/AC:L/Au:N/C:C/I:C/A:C nvd@nist.gov

EPSS

EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.

EPSS Score

The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.

EPSS Percentile

The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
EPSS First.org

Exploit information

Exploit Database EDB-ID : 38348

Publication date : 2015-09-27 22h00 +00:00
Author : Google Security Research
EDB Verified : No

Source: https://code.google.com/p/google-security-research/issues/detail?id=504 The latest version of the Vector.<primitive> length check in Flash 18,0,0,232 is not robust against memory corruptions such as heap overflows. While it’s no longer possible to obviously bypass the length check there’s still unguarded data in the object which could be corrupted to serve as a useful primitive. To better describe this currently the Vector primitive object (at least on 32 bit) looks something like: | unguarded length | unguarded capacity | xored length | ... | data | The problem arises because the capacity is not guarded by the xor, and it’s before the xored length which is guarded. As we know the unguarded length value then if we have a suitable memory corruption vulnerability we could corrupt only the length and the capacity fields leaving the xored length alone. Of course we’d need to corrupt the length back to the same value (otherwise the length guard check would fail). If we set the capacity to be greater than that originally allocated then when a call is made to set the length (using the length Vector property) the runtime will assume the allocation is larger than it is and extend the vector over the end of the original allocation. This in itself is not enough to serve as a useful primitive as extending the vector also 0’s any data afterwards so it’s not an information leak. However we’ve now got a vector which aliases some other part of the heap. If for example something else was allocated immediately after the vector which we can influence then it’d be possible to write data to that and read it out from the vector, and vice versa. Also depending on the heap type it might be possible to reconstruct heap headers, but it probably isn’t on Windows. As vector objects are now on the system heap it’s a lot harder to exploit. It’s likely that an attacker would need to utilize browser specific heap allocations rather than another flash allocation. One way of fixing this, at least against buffer overflows, would be to move the xored length before the capacity. In this case the act of overflowing the capacity value would corrupt the guard length leading to the check failure when setting the new length to exceed the existing capacity. This wouldn’t do anything against a heap relative overwrite or a buffer underflow. In that case you could also apply the guard to the capacity field as well. If Vectors are completely moved out from the heap with other objects, as planned, exploiting this would probably be very difficult. On a related note, it’s still possible to read the length of the vector without triggering the guard check. The length is whatever the unguarded length is set to. This could be used as a way of checking which vector objects have been corrupted by an overflow. I’ve provided a simple example which allocates a 16k UInt vector. Using a debugger you can modify the capacity then press a key to show that the process doesn’t crash (at least doesn’t crash due to a length corruption). The following instructions are for IE11 with 32 bit tabs (the default even on x64 builds). 1. Load the swf file into IE 2. Attach WinDBG to the IE tab process 3. Search for the data pattern to find the vector using the command “s 0 L?10000000 78 56 34 12 f0 de bc 9a 00 00 00 00”. There should only be one hit. 4. Modify the capacity using the command “ed <address>-0xC 5000” replacing <address> with that found in step 3. Also look at <address>+0n64*0n1024 which will should show other data on the heap. 5. Resume execution in the debugger. 6. Select the flash object in the browser and press the ‘=’ key, you should see a trace message printing the new length. 7. If you return to the debugger and dump the data at <addresss>+0n64*0n1024 you’ll find the memory has been zeroed. Also at <addresss>+0n64*0n1024+3C you should find that the value 0x88888888 has been written to existing allocated memory. The source is a HAXE file, you need to compile with the command line “haxe -main Test -swf output.swf -swf-version 10” Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38348.zip

Products Mentioned

Configuraton 0

Adobe>>Flash_player >> Version To (including) 11.2.202.508

Linux>>Linux_kernel >> Version -

Configuraton 0

Adobe>>Flash_player >> Version To (including) 13.0.0.289

Adobe>>Flash_player >> Version 14.0.0.125

Adobe>>Flash_player >> Version 14.0.0.145

Adobe>>Flash_player >> Version 14.0.0.176

Adobe>>Flash_player >> Version 14.0.0.179

Adobe>>Flash_player >> Version 15.0.0.152

Adobe>>Flash_player >> Version 15.0.0.167

Adobe>>Flash_player >> Version 15.0.0.189

Adobe>>Flash_player >> Version 15.0.0.223

Adobe>>Flash_player >> Version 15.0.0.239

Adobe>>Flash_player >> Version 15.0.0.246

Adobe>>Flash_player >> Version 16.0.0.235

Adobe>>Flash_player >> Version 16.0.0.257

Adobe>>Flash_player >> Version 16.0.0.287

Adobe>>Flash_player >> Version 16.0.0.296

Adobe>>Flash_player >> Version 17.0.0.134

Adobe>>Flash_player >> Version 17.0.0.169

Adobe>>Flash_player >> Version 17.0.0.188

Adobe>>Flash_player >> Version 17.0.0.190

Adobe>>Flash_player >> Version 17.0.0.191

Adobe>>Flash_player >> Version 18.0.0.160

Adobe>>Flash_player >> Version 18.0.0.194

Adobe>>Flash_player >> Version 18.0.0.203

Adobe>>Flash_player >> Version 18.0.0.209

Adobe>>Flash_player >> Version 18.0.0.232

Apple>>Mac_os_x >> Version -

Microsoft>>Windows >> Version -

Configuraton 0

Adobe>>Air >> Version To (including) 18.0.0.199

Adobe>>Air_sdk >> Version To (including) 18.0.0.199

Adobe>>Air_sdk_\&_compiler >> Version To (including) 18.0.0.180

Apple>>Mac_os_x >> Version -

Microsoft>>Windows >> Version -

Configuraton 0

Adobe>>Air >> Version To (including) 18.0.0.143

Google>>Android >> Version *

References

http://rhn.redhat.com/errata/RHSA-2015-1814.html
Tags : vendor-advisory, x_refsource_REDHAT
https://www.exploit-db.com/exploits/38348/
Tags : exploit, x_refsource_EXPLOIT-DB
http://www.securityfocus.com/bid/76798
Tags : vdb-entry, x_refsource_BID
http://www.securitytracker.com/id/1033629
Tags : vdb-entry, x_refsource_SECTRACK
https://security.gentoo.org/glsa/201509-07
Tags : vendor-advisory, x_refsource_GENTOO
The information presented on CVE Find originates from several carefully selected reference sources. CVE data is provided by MITRE Corporation and the National Vulnerability Database (NVD). The Known Exploited Vulnerabilities (KEV) catalog is sourced from the Cybersecurity and Infrastructure Security Agency (CISA), while EPSS scores come from FIRST.org. Additionally, data regarding software weaknesses (CWE) and common attack patterns (CAPEC) is maintained by MITRE Corporation, and information on hardware and software configurations (CPE) is provided by the NVD.