CVE-2015-5568 : Détail

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 pour un CVE
Restez informé de toutes modifications pour un CVE spécifique.
Gestion des notifications

Descriptions du CVE

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.

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse 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.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V2 10 AV:N/AC:L/Au:N/C:C/I:C/A:C nvd@nist.gov

EPSS

EPSS est un modèle de notation qui prédit la probabilité qu'une vulnérabilité soit exploitée.

Score EPSS

Le modèle EPSS produit un score de probabilité compris entre 0 et 1 (0 et 100 %). Plus la note est élevée, plus la probabilité qu'une vulnérabilité soit exploitée est grande.

Percentile EPSS

Le percentile est utilisé pour classer les CVE en fonction de leur score EPSS. Par exemple, une CVE dans le 95e percentile selon son score EPSS est plus susceptible d'être exploitée que 95 % des autres CVE. Ainsi, le percentile sert à comparer le score EPSS d'une CVE par rapport à d'autres CVE.
EPSS First.org

Informations sur l'Exploit

Exploit Database EDB-ID : 38348

Date de publication : 2015-09-27 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : 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 *

Références

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