diff options
Diffstat (limited to 'chromium/docs/website/site/Home/chromium-security')
.png.sha1?id=7d2c5d177e9813077a621df8d18c0deda73099b3){kind=link}
.png.sha1?id=7d2c5d177e9813077a621df8d18c0deda73099b3){kind=link}
.png.sha1?id=7d2c5d177e9813077a621df8d18c0deda73099b3){kind=link}
96 files changed, 0 insertions, 13741 deletions
diff --git a/chromium/docs/website/site/Home/chromium-security/OWNERS b/chromium/docs/website/site/Home/chromium-security/OWNERS deleted file mode 100644 index c58a112f042..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/OWNERS +++ /dev/null @@ -1,8 +0,0 @@ -adetaylor@google.com -awhalley@google.com -eisinger@google.com -estark@google.com -jclinton@google.com -mkwst@google.com -nasko@google.com -nparker@google.com
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/adding-permissions/index.md b/chromium/docs/website/site/Home/chromium-security/adding-permissions/index.md deleted file mode 100644 index c510b87f70a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/adding-permissions/index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: adding-permissions -title: So you want to add a new permission? ---- - diff --git a/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/decode-mitigation-flags.html b/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/decode-mitigation-flags.html deleted file mode 100644 index cae3befd8fa..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/decode-mitigation-flags.html +++ /dev/null @@ -1,232 +0,0 @@ -<!doctype html> -<html> - <head> - <meta charset="utf-8"> - <title>View mitigation flags</title> - </head> - <body> - Paste mitigation values from chrome://sandbox output. - <form> - Chrome (desiredMitigations): <input type="text" id="chrome"><br> - Platform (platformMitigations): <input type="text" id="platform"><br> - <input type="button" value="Expand" OnClick="work()"> - </form> - <pre id="output"></pre> - <script type="text/javascript"> - /* - See //sandbox/win/src/security_level.h. This is a bitfield so is - easy to process. - */ - const ChromeMitigationFlags = [ - 'MITIGATION_DEP', // 0x00000001; - 'MITIGATION_DEP_NO_ATL_THUNK', // 0x00000002; - 'MITIGATION_SEHOP', // 0x00000004; - 'MITIGATION_RELOCATE_IMAGE', // 0x00000008; - 'MITIGATION_RELOCATE_IMAGE_REQUIRED', // 0x00000010; - 'MITIGATION_HEAP_TERMINATE', // 0x00000020; - 'MITIGATION_BOTTOM_UP_ASLR', // 0x00000040; - 'MITIGATION_HIGH_ENTROPY_ASLR', // 0x00000080; - 'MITIGATION_STRICT_HANDLE_CHECKS', // 0x00000100; - 'MITIGATION_DLL_SEARCH_ORDER', // 0x00000200; - 'MITIGATION_HARDEN_TOKEN_IL_POLICY', // 0x00000400; - 'MITIGATION_WIN32K_DISABLE', // 0x00000800; - 'MITIGATION_EXTENSION_POINT_DISABLE', // 0x00001000; - 'MITIGATION_DYNAMIC_CODE_DISABLE', // 0x00002000; - 'MITIGATION_DYNAMIC_CODE_DISABLE_WITH_OPT_OUT', // 0x00004000; - 'MITIGATION_DYNAMIC_CODE_OPT_OUT_THIS_THREAD', // 0x00008000; - 'MITIGATION_NONSYSTEM_FONT_DISABLE', // 0x00010000; - 'MITIGATION_FORCE_MS_SIGNED_BINS', // 0x00020000; - 'MITIGATION_IMAGE_LOAD_NO_REMOTE', // 0x00040000; - 'MITIGATION_IMAGE_LOAD_NO_LOW_LABEL', // 0x00080000; - 'MITIGATION_IMAGE_LOAD_PREFER_SYS32', // 0x00100000; - 'MITIGATION_RESTRICT_INDIRECT_BRANCH_PREDICTION', // 0x00200000; - ]; - - /* Defined in Windows.h -> Winbase.h These are not just bitflields but - masked bitfields. |offset| indicates the shift within the 64bit - field indicated by the |type| entry. |mask| and |value| are then - used to compare the 64bit field to determine if an option is set. - |mask| and |value| must be <256 because of how bits are tested - later. - */ - const WindowsMitigations = [ - // basic (pc0) mitigations in {win7},{lsb of pc1}. - {'type': 'pc0', 'mitigation': 'DEP_ENABLE', 'value': 0x1, 'mask': 0x01, 'offset':0}, - {'type': 'pc0', 'mitigation': 'DEP_ATL_THUNK_ENABLE', 'value': 0x2, 'mask': 0x02, 'offset':0}, - {'type': 'pc0', 'mitigation': 'SEHOP_ENABLE', 'value': 0x4, 'mask': 0x04, 'offset':0}, - - // pc1 mitigations in {lsb of pc1}. PROCESS_CREATION_MITIGATION_POLICY. - {'type': 'pc1', 'mitigation': 'FORCE_RELOCATE_IMAGES_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset':8}, - {'type': 'pc1', 'mitigation': 'FORCE_RELOCATE_IMAGES_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset':8}, - {'type': 'pc1', 'mitigation': 'FORCE_RELOCATE_IMAGES_ALWAYS_ON_REQ_RELOCS', 'value': 0x3, 'mask': 0x03, 'offset':8}, - - {'type': 'pc1', 'mitigation': 'HEAP_TERMINATE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 12}, - {'type': 'pc1', 'mitigation': 'HEAP_TERMINATE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 12}, - {'type': 'pc1', 'mitigation': 'HEAP_TERMINATE_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 12}, - - {'type': 'pc1', 'mitigation': 'BOTTOM_UP_ASLR_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 16}, - {'type': 'pc1', 'mitigation': 'BOTTOM_UP_ASLR_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 16}, - {'type': 'pc1', 'mitigation': 'BOTTOM_UP_ASLR_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 16}, - - {'type': 'pc1', 'mitigation': 'HIGH_ENTROPY_ASLR_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 20}, - {'type': 'pc1', 'mitigation': 'HIGH_ENTROPY_ASLR_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 20}, - {'type': 'pc1', 'mitigation': 'HIGH_ENTROPY_ASLR_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 20}, - - {'type': 'pc1', 'mitigation': 'STRICT_HANDLE_CHECKS_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 24}, - {'type': 'pc1', 'mitigation': 'STRICT_HANDLE_CHECKS_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 24}, - {'type': 'pc1', 'mitigation': 'STRICT_HANDLE_CHECKS_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 24}, - - {'type': 'pc1', 'mitigation': 'WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 28}, - {'type': 'pc1', 'mitigation': 'WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 28}, - {'type': 'pc1', 'mitigation': 'WIN32K_SYSTEM_CALL_DISABLE_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 28}, - - {'type': 'pc1', 'mitigation': 'EXTENSION_POINT_DISABLE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 32}, - {'type': 'pc1', 'mitigation': 'EXTENSION_POINT_DISABLE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 32}, - {'type': 'pc1', 'mitigation': 'EXTENSION_POINT_DISABLE_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 32}, - - {'type': 'pc1', 'mitigation': 'PROHIBIT_DYNAMIC_CODE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 36}, - {'type': 'pc1', 'mitigation': 'PROHIBIT_DYNAMIC_CODE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 36}, - {'type': 'pc1', 'mitigation': 'PROHIBIT_DYNAMIC_CODE_ALWAYS_ON_ALLOW_OPT_OUT', 'value': 0x3, 'mask': 0x03, 'offset': 36}, - - {'type': 'pc1', 'mitigation': 'CONTROL_FLOW_GUARD_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 40}, - {'type': 'pc1', 'mitigation': 'CONTROL_FLOW_GUARD_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 40}, - {'type': 'pc1', 'mitigation': 'CONTROL_FLOW_GUARD_EXPORT_SUPPRESSION', 'value': 0x3, 'mask': 0x03, 'offset': 40}, - - {'type': 'pc1', 'mitigation': 'BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 44}, - {'type': 'pc1', 'mitigation': 'BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 44}, - {'type': 'pc1', 'mitigation': 'BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE', 'value': 0x3, 'mask': 0x03, 'offset': 44}, - - {'type': 'pc1', 'mitigation': 'FONT_DISABLE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 48}, - {'type': 'pc1', 'mitigation': 'FONT_DISABLE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 48}, - {'type': 'pc1', 'mitigation': 'AUDIT_NONSYSTEM_FONTS', 'value': 0x3, 'mask': 0x03, 'offset': 48}, - - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_REMOTE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 52}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_REMOTE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 52}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_REMOTE_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 52}, - - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_LOW_LABEL_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 56}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_LOW_LABEL_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 56}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_NO_LOW_LABEL_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 56}, - - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_PREFER_SYSTEM32_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 60}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_PREFER_SYSTEM32_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 60}, - {'type': 'pc1', 'mitigation': 'IMAGE_LOAD_PREFER_SYSTEM32_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 60}, - - // pc2: in second 64bit block only. (PROCESS_CREATION_MITIGATION_POLICY2). - {'type': 'pc2', 'mitigation': 'LOADER_INTEGRITY_CONTINUITY_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 4}, - {'type': 'pc2', 'mitigation': 'LOADER_INTEGRITY_CONTINUITY_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 4}, - {'type': 'pc2', 'mitigation': 'LOADER_INTEGRITY_CONTINUITY_AUDIT', 'value': 0x3, 'mask': 0x03, 'offset': 4}, - - {'type': 'pc2', 'mitigation': 'STRICT_CONTROL_FLOW_GUARD_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 8}, - {'type': 'pc2', 'mitigation': 'STRICT_CONTROL_FLOW_GUARD_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 8}, - {'type': 'pc2', 'mitigation': 'STRICT_CONTROL_FLOW_GUARD_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 8}, - - {'type': 'pc2', 'mitigation': 'MODULE_TAMPERING_PROTECTION_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 12}, - {'type': 'pc2', 'mitigation': 'MODULE_TAMPERING_PROTECTION_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 12}, - {'type': 'pc2', 'mitigation': 'MODULE_TAMPERING_PROTECTION_NOINHERIT', 'value': 0x3, 'mask': 0x03, 'offset': 12}, - - {'type': 'pc2', 'mitigation': 'RESTRICT_INDIRECT_BRANCH_PREDICTION_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 16}, - {'type': 'pc2', 'mitigation': 'RESTRICT_INDIRECT_BRANCH_PREDICTION_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 16}, - {'type': 'pc2', 'mitigation': 'RESTRICT_INDIRECT_BRANCH_PREDICTION_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 16}, - - {'type': 'pc2', 'mitigation': 'ALLOW_DOWNGRADE_DYNAMIC_CODE_POLICY_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 20}, - {'type': 'pc2', 'mitigation': 'ALLOW_DOWNGRADE_DYNAMIC_CODE_POLICY_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 20}, - {'type': 'pc2', 'mitigation': 'ALLOW_DOWNGRADE_DYNAMIC_CODE_POLICY_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 20}, - - {'type': 'pc2', 'mitigation': 'SPECULATIVE_STORE_BYPASS_DISABLE_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 24}, - {'type': 'pc2', 'mitigation': 'SPECULATIVE_STORE_BYPASS_DISABLE_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 24}, - {'type': 'pc2', 'mitigation': 'SPECULATIVE_STORE_BYPASS_DISABLE_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 24}, - - {'type': 'pc2', 'mitigation': 'CET_USER_SHADOW_STACKS_ALWAYS_ON', 'value': 0x1, 'mask': 0x03, 'offset': 28}, - {'type': 'pc2', 'mitigation': 'CET_USER_SHADOW_STACKS_ALWAYS_OFF', 'value': 0x2, 'mask': 0x03, 'offset': 28}, - {'type': 'pc2', 'mitigation': 'CET_USER_SHADOW_STACKS_RESERVED', 'value': 0x3, 'mask': 0x03, 'offset': 28}, - ]; - - // Returns a byte vector (in ints). - function parseHexString(str) { - let buffer = new ArrayBuffer(str.length / 2); - let bytes = new Uint8Array(buffer); - let idx = 0; - while (str.length >= 2) { - bytes[idx] = parseInt(str.substring(0, 2), 16); - str = str.substring(2, str.length); - idx++; - } - return bytes; - } - - // Bits are msb..lsb. - function isBitSet(bytes, bit) { - if (bit > bytes.length * 8) { - return false; - } - const idx = bytes.length - 1 - Math.floor(bit / 8); - const ibit = bit % 8; - return (bytes[idx] & (1 << ibit)) == (1<<ibit); - } - - // |mask| & |value| must be 0<=x<=255. Bits are msb..lsb. - function areMaskedBitsEqual(bytes, offset, mask, value) { - if (offset > bytes.length * 8) { - return false; - } - const idx = bytes.length - 1 - Math.floor(offset / 8); - const ibit = offset % 8; - return (bytes[idx] & (mask << ibit)) == (value<<ibit); - } - - function selectSetItems(items, bytes) { - let output = []; - for (let i = 0; i<items.length; i++) { - if (isBitSet(bytes, i)) { - output.push(items[i]); - } - } - return output; - } - - function selectWindowsMitgations(items, bytes) { - let output = []; - // Default to DWORD version, if longer assume 1 or 2 64bit fields. - let offsets = {'pc0': 0}; - if (bytes.length == 8) { - offsets['pc1'] = 0; - } - else if (bytes.length == 16) { - offsets['pc0'] = 64; - offsets['pc1'] = 64; - offsets['pc2'] = 0; - } - for (const item of items) { - if (item.type == 'pc1' && bytes.length < 8) - continue; - if (item.type == 'pc2' && bytes.length < 16) - continue; - // Must be valid to use offset of type now. - if (areMaskedBitsEqual(bytes, item['offset'] + offsets[item['type']], - item['mask'], item['value'])) { - output.push(item['mitigation']); - } - } - return output; - } - - function work(){ - let chrome = parseHexString(document.getElementById('chrome').value); - let platform = parseHexString(document.getElementById('platform').value); - document.getElementById('output').innerText = - selectSetItems(ChromeMitigationFlags, chrome).join('\n') + '\n\n' - + selectWindowsMitgations(WindowsMitigations, platform).join('\n'); - } - - // Listen for pasted input. - const $cr = document.querySelector('#chrome'); - const $pl = document.querySelector('#platform'); - function changedHandler() { - work(); - } - $cr.addEventListener('input', changedHandler); - $pl.addEventListener('input', changedHandler); - </script> - </body> -</html> diff --git a/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/index.md b/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/index.md deleted file mode 100644 index 4400b9f33b0..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows/index.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/articles - - Articles -page_name: chrome-sandbox-diagnostics-for-windows -title: chrome://sandbox Diagnostics for Windows ---- - -## You are adequately sandboxed - -February 2020 - -The latest Chrome stable release for Windows, [Chrome -80](https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html) -(early February 2020) provides detailed debugging information on how Chromium’s -processes are sandboxed. You can access this by typing chrome://sandbox into the -url-bar (Omnibox). The output is mainly of interest to Chromium developers but, -along with chrome://conflicts, could be helpful when troubleshooting -incompatibility between misbehaving software and the sandbox. This post will -outline how the sandbox works on Windows and the information that is displayed. - -Chrome, and all web browsers, have a difficult job. Users visit sites that store -sensitive information, serve complex data formats and run JavaScript code. Users -visit more than one site in each browsing session, and each site might include -components from a range of third parties. Chromium has to protect itself from -malicious sites, and protect each site’s data from being accessed by other -sites. Chromium developers mainly achieve this by writing secure code, testing, -and fuzzing. However, Chrome has a JavaScript engine and parsers for complex -data formats written in C/C++ for performance, which may have bugs that a -malicious attacker can exploit to run arbitrary code. This, in turn, could allow -an attacker to do anything Chrome can, such as accessing a user’s files, or -calling Windows APIs, which may themselves have exploitable bugs. To provide a -secondary layer of defense Chrome restricts what it can do by containing sites -and services in sandboxed processes. - -Chrome uses a [multi-process -architecture](https://www.google.com/googlebooks/chrome/small_04.html) for -security and stability. This way, a bug or a crash in the process running one -site will not bring down other sites, and data in one process can be made -inaccessible to other processes. Chrome calls the processes running sites -renderers and its main coordinating process the browser. The browser is -supported by network, audio and gpu processes, and uses short-lived data-decoder -and utility processes to parse and verify complex data formats. The goal of the -[sandbox](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md) -is to allow these processes the level of access to the operating system they -need to do their jobs, and nothing more. Below, we’ll use the output of -chrome://sandbox to show some of these restrictions. - -## chrome://sandbox - -First you’ll see a table of active processes (excluding the browser process, as -that is not sandboxed) and some summary information:- - -<table> -<tr> -<td> Process </td> -<td> Type </td> -<td> Name</td> -<td> Sandbox</td> -<td> Integrity</td> -<td> Mitigations</td> -</tr> -<tr> -<td> 42152</td> -<td> GPU </td> -<td> GPU </td> -<td> Limited </td> -<td> S-1-16-4096 Low</td> -<td> 01111001010110000000000000010000</td> -</tr> -<tr> -<td> 28388</td> -<td> Utility</td> -<td> Network Service </td> -<td> Not Sandboxed </td> -</tr> -<tr> -<td> 43376</td> -<td> Utility</td> -<td> V8 Proxy Resolver </td> -<td> Lockdown </td> -<td> S-1-16-0 Untrusted</td> -<td> 01111001010110000000000000010000</td> -</tr> -<tr> -<td> 4880</td> -<td> Utility</td> -<td> Audio Service</td> -<td> Restricted Non Admin</td> -<td> S-1-16-4096 Low</td> -<td> 01111011010110000000000000010000</td> -</tr> -<tr> -<td> 13892</td> -<td> Native Client module</td> -<td> https://earth.google.com/static/9.3.100.2/earthnacl_pexe.nmf</td> -<td> Lockdown</td> -<td> S-1-16-0 Untrusted</td> -<td> 01111001010110000000000000010000</td> -</tr> -<tr> -<td> 25980</td> -<td> Renderer </td> -<td> Lockdown</td> -<td> S-1-16-0 Untrusted</td> -<td> 01111001110110000000000000010000</td> -</tr> -<tr> -<td> 35952</td> -<td> Renderer </td> -<td> Lockdown</td> -<td> S-1-16-0 Untrusted</td> -<td> 01111001110110000000000000010000</td> -</tr> -</table> - -Followed by a raw dump of every process’s detailed sandbox configuration in -JSON, which we’ll look at later. - -Depending on how many tabs you have open, and which plugins or extensions you’re -running, you’ll see something similar. First you’ll see the various utility and -plugin host processes, followed by a long list of renderer processes which host -sites. Utility processes have different sandbox configurations, while every -renderer process has the same sandbox configuration. For information on which -renderer process hosts which site, see the Task Manager (Shift+Esc). - -[Sandbox -Type](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md) -ranges from ‘No Sandbox’ (the most permissive), via ‘Limited’ and ‘Restricted’ -to ‘Lockdown’ (the least permissive). The main browser process runs without a -sandbox, and some supporting processes might do so, especially if the services -they contain have only recently been moved out of the browser process. Our goal -is to gradually tighten these sandboxes. Renderers are locked down so that they -have only very limited access to the operating system, file system and other -objects. - -Sandboxing is mainly achieved by dropping privileges and applying operating -system mitigations. Privileges are controlled by [restricting the -token](https://docs.microsoft.com/en-us/windows/win32/secauthz/restricted-tokens) -and [Integrity -Level](https://docs.microsoft.com/en-us/windows/win32/secauthz/mandatory-integrity-control) -of a sandboxed process. Most things a process can interact with on Windows, like -desktops, files, and pipes are [securable -objects](https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects). -Windows checks a process’s token against access control lists before allowing a -process to access or modify an object. Chrome’s browser process starts running -with the same token as the user that launched it, which, for instance, can -access all the user’s files. Renderers shed every privilege possible and limit -their token to only the S-1-16-0 Untrusted integrity level significantly -reducing the number of objects they can interact with. Services such as the GPU -process, which interacts with the Windows graphics system, may need more access -so run at higher integrity levels. - -The final column of the table shows the operating system mitigations which are -applied to the process. This will vary based on the version and architecture of -Windows that you are using. On the latest iteration of Windows 10 renderer -processes will have:- - -01111001110110000000000000010000 - -This is a hex representation of the [Windows process mitigation -options](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocessmitigationpolicy). -You can decode this [using the attached -decoder](https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo3MDg0MDMzODNjODgzMDMy), -which will show that the following process mitigations are enabled: -HEAP_TERMINATE, BOTTOM_UP_ASLR, STRICT_HANDLE_CHECKS, -WIN32K_SYSTEM_CALL_DISABLE, EXTENSION_POINT_DISABLE, -BLOCK_NON_MICROSOFT_BINARIES, FONT_DISABLE, IMAGE_LOAD_NO_REMOTE, -IMAGE_LOAD_NO_LOW_LABEL and RESTRICT_INDIRECT_BRANCH_PREDICTION. - -Other processes are similar (or not sandboxed). The audio process also has -PROHIBIT_DYNAMIC_CODE enabled but, along with the data decoder and other utility -processes, is missing WIN32K_SYSTEM_CALL_DISABLE. Dynamic code is required in -the renderer as this is used by v8 to compile JavaScript to native code. If you -have a PDF open you will see that its process does not require dynamic code. -While PDFs can include JavaScript it is run in interpreted mode. - -On Windows 7 in 32-bit mode the story is quite different. The mitigations are -0000000000000005 which corresponds to only DEP_ENABLE and SEHOP_ENABLE. These -are not even indicated on 64-bit Windows 10 as they are always enabled there. -This reduced set of mitigations means that a renderer compromise on Windows 7 is -much more serious than on Windows 10. More of the operating system can be -reached from a compromised process, allowing a malicious site more avenues to -access data outside of their own site’s process. This is why we encourage our -users to run the latest version of Windows so that they can benefit from the -latest security technologies. - -Below the summary table you’ll see JSON showing more detailed output for the -same processes: - -"NtCreateFile": \[ - -"!(p\[1\] & 1) && !(prefix(p\[0\], '\\\\??\\\\')) -> askBroker", - -"!(p\[1\] & 1) && scan(p\[0\], '~') -> askBroker", - -"!(p\[2\] & 5fedff56) && p\[3\] == 1 && exact_i(p\[0\], -'\\\\??\\\\C:\\\\Windows\\\\Fonts') -> askBroker", - -"!(p\[2\] & 5fedff56) && p\[3\] == 1 && prefix_i(p\[0\], -'\\\\??\\\\C:\\\\Windows\\\\Fonts\\\\') -> askBroker", - -"prefix_i(p\[0\], '\\\\??\\\\pipe\\\\chrome.') -> askBroker" - -\], - -The desiredMitigations field is defined by Chromium and shows which mitigations -and options we would set if they were supported by the operating system. These -map closely to the platform mitigations and can be decoded using the same tool. -There are also a set of policy rules which are used when system calls are -intercepted in a child process. The WIN32K_SYSTEM_CALL_DISABLE mitigation, and -the reduced token of the child process, prevents renderers from calling various -functions or from opening files or pipes they may need to do their job. The -sandbox intercepts these functions as the child process starts and uses an IPC -mechanism to forward calls that match a policy rule to the browser. These rules -are evaluated again in the browser and, if allowed, the call is made and the -results passed back into the renderer for it to use. The rule above allows -renderer processes to read system fonts and connect to pipes matching -\\??\\pipe\\chrome.\*. Any other attempts to open files are blocked. The first -two rules are special and apply only in the renderer but are skipped in the -browser process. This is because short names must be normalised before being -tested, and this must occur in the browser process. - -New sandbox rules and policies are introduced to the Canary, Beta and Dev -channels of Chrome before being enabled on the Stable channel so the output of -chrome://sandbox might be different depending on which channel you are running. -Rarely, other software may be incompatible with the sandbox, and you may see -advice to run with the ‘--no-sandbox’ flag or to use Windows 7 compatibility -mode. We do not encourage this as it will significantly reduce your security, -and may prevent Chromium from working properly. Instead we encourage you to -search the [Chrome community support -forum](https://support.google.com/chrome/community?hl=en) and to report problems -to your suppliers. We encourage software vendors and enterprises to test their -applications and sites with Chrome’s Beta and Dev channels to uncover -incompatibilities before they might affect their products or business. The -output of chrome://sandbox, in combination with chrome://conflicts, might help -when diagnosing incompatibilities or failures and might be useful when added to -any bug reports. The output of these special pages contains system information -which may include sensitive data such as usernames so we advise you to be -careful if sharing it.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/diag4.png.sha1 b/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/diag4.png.sha1 deleted file mode 100644 index bc8d7af551a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/diag4.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -4f91b27b6833783d436f298c467d8fd2c6c91aca
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram1.png.sha1 b/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram1.png.sha1 deleted file mode 100644 index fb1487219f2..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram1.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -adcc2b846e021cfdae91edd65676b531d12b61bf
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram2.png.sha1 b/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram2.png.sha1 deleted file mode 100644 index 6c9a818f149..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram2.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -5c7a1d30190ca217feb9984709d518192fa1e9c5
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram3.png.sha1 b/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram3.png.sha1 deleted file mode 100644 index 58829b3ac71..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram3.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -fb47aa118192c4e85332b6da4047e4630157f438
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/index.md b/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/index.md deleted file mode 100644 index d82347bf30b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/gwp-asan/index.md +++ /dev/null @@ -1,431 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/articles - - Articles -page_name: gwp-asan -title: 'GWP-ASan: Sampling heap memory error detection in-the-wild' ---- - -By Vlad Tsyrklevich, Dynamic Tools Teams — November 2019 - -Memory safety errors, like use-after-frees and out-of-bounds reads/writes, are a -leading source of vulnerabilities in C/C++ applications. Despite investments in -preventing and detecting these errors in Chrome, over 60% of high severity -vulnerabilities in Chrome are memory safety errors. Some memory safety errors -don’t lead to security vulnerabilities but simply cause crashes and instability. - -Chrome uses state-of-the-art techniques to prevent these errors, including: - - [Coverage-guided](https://llvm.org/docs/LibFuzzer.html) - [fuzzing](https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)) with - [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html) (ASan) - - Unit and integration testing with ASan - - Defensive programming, like custom libraries to perform safe math or provide - bounds checked containers - - Mandatory code review - -Chrome also makes use of sandboxing and exploit mitigations to complicate -exploitation of memory errors that go undetected by the methods above. - -AddressSanitizer is a compiler instrumentation that finds memory errors -occurring on the heap, stack, or in globals. ASan is highly effective and one of -the lowest overhead instrumentations available that detects the errors that it -does; however, it still incurs an average 2-3x performance and memory overhead. -This makes it suitable for use with unit tests or fuzzing, but not deployment to -end users. Chrome used to deploy [SyzyASAN instrumented -binaries](https://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html) -to detect memory errors. SyzyASAN had a similar overhead so it was only deployed -to a small subset of users on the canary channel. It was discontinued after the -Windows toolchain switched to LLVM. - -GWP-ASan, also known by its recursive backronym, GWP-ASan Will Provide -Allocation Sanity, is a sampling allocation tool designed to detect heap memory -errors occurring in production with negligible overhead. Because of its -negligible overhead we can deploy GWP-ASan to the entire Chrome user base to -find memory errors happening in the real world that are not caught by fuzzing or -testing with ASan. Unlike ASan, GWP-ASan can not find memory errors on the stack -or in globals. - -GWP-ASan is currently enabled for all Windows and macOS users for allocations -made using malloc() and PartitionAlloc. It is only enabled for a small fraction -of allocations and processes to reduce performance and memory overhead to a -negligible amount. At the time of writing it has found [over sixty -bugs](https://bugs.chromium.org/p/chromium/issues/list?q=Hotlist%3DGWP-ASan&can=1) -(many are still restricted view). About 90% of the issues GWP-ASan has found are -use-after-frees. The remaining are out-of-bounds reads and writes. - -Design - -Overview - -GWP-ASan is conceptually similar to -[ElectricFence](https://en.wikipedia.org/wiki/Electric_Fence) or -[PageHeap](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap). -GWP-ASan installs an allocator instrumentation that samples allocations to a -debug allocator that places allocations on their own page, buttressed on both -sides by guard pages. New allocations are randomly either left- or right-aligned -within the page so that accessing the allocation below or above its bounds -causes a crash. When the allocation is freed, the page is unmapped so that a -use-after-free also immediately crashes. The allocator limits itself to a fixed -amount of memory to control memory overhead and samples allocation to the debug -allocator to reduce its high performance overhead. - -Use-after-frees and out-of-bounds accesses are often hard to debug because they -corrupt unrelated memory which can lead to crashes in unrelated code. GWP-ASan -simplifies debugging by causing a crash immediately at the site of the invalid -memory access. Furthermore, when a crash occurs a special crash handler hook -reports additional information, like allocation and deallocation stack traces, -to aid debugging. This metadata is similar to what AddressSanitizer provides and -has been shown to be very useful in identifying and fixing memory errors. - -GWP-ASan is a heap-only instrumentation so it does not find memory errors on the -stack or in globals that AddressSanitizer would; however, it can find some -memory errors that ASan would not. ASan works by instrumenting memory accesses -during compilation and makes use of ‘interceptors’ to detect misuse of common -library functions. Because GWP-ASan uses native memory management to detect -memory errors it doesn’t require interceptors to detect invalid memory use in -system libraries. This means it can identify API misuse for uncommon APIs that -don’t have interceptors, or even detect memory errors that occur due to bugs in -system libraries—something ASan can’t do without recompiling those potentially -proprietary libraries. - -GWP-ASan is only as effective as the number of allocation call sites it -instruments. For an internal Chrome allocator like PartitionAlloc it is possible -to intercept all uses; however, for malloc/free we may only be able to -instrument a subset of allocations. For example, on Windows we instrument malloc -and free by overriding the symbols for modules we build linked against //base, -so some DLLs shipped with Chrome—let alone Windows system code—may not be -instrumented. On macOS however the system allocator allows adding global hooks -meaning we can -([and](https://bugs.chromium.org/p/chromium/issues/list?q=Hotlist%3DGWP-ASan%20Component%3DInternals%3EPlatformIntegration&can=1) -[do](https://support.apple.com/en-us/HT210634)) detect memory errors from -allocations originating in code we don’t control, like Apple system libraries. - -Allocator - -The GWP-ASan allocator reserves a fixed range of memory at initialization that -it uses to service allocations to limit memory overhead. The memory range -consists of pages intended to be used to return allocations, called slots, -buttressed by guard pages as shown below. - -[<img alt="image" -src="/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram1.png">](/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram1.png) - -Allocations are randomly left- or right-aligned to help detect both underflows -and overflows. Like a traditional allocator, the GWP-ASan allocator always -suitably aligns allocations for any object of that size. This means that -right-aligned allocations are not always directly adjacent to the following -guard page, so small out-of-bounds accesses may go undetected. - -[<img alt="image" -src="/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram2.png">](/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram2.png) - -An array of allocation metadata is also maintained on the side to store stack -traces and other metadata for individual slots. - -The allocator has three primary tunable parameters: MaxSimultaneousAllocations, -MaxMetadata, and ReservedSlots. MaxSimultaneousAllocations controls the maximum -number of allocations that can be simultaneously allocated. - -Once every usable slot has been allocated and deallocated, they are reused to -service new allocations. When a use-after-free occurs the use may not occur -immediately after deallocation. If the slot has been reallocated then the -use-after-free will not behave as expected. If the slot is still allocated then -the use won’t crash, but if it is deallocated then it will cause a crash but the -metadata for the slot will have the wrong allocation/deallocation stack traces. - -Like ASan, GWP-ASan also makes use of a quarantine to help improve -use-after-free detection. ReservedSlots is always greater than or equal to -MaxSimultaneousAllocations and controls the number of slots we allocated virtual -memory for. If ReservedSlots > MaxSimultaneousAllocations, then not all slots -can be simultaneously allocated. If slots are allocated in a round-robin fashion -then a slot will not be re-used until at least (ReservedSlots - -MaxSimultaneousAllocations) allocations have taken place, forming a rudimentary -quarantine. This delays the amount of time until a slot is re-used, improving -use-after-free detection at the expense of using more memory. The allocator -consumes more virtual memory for the additional quarantine slots and more -physical memory storing allocation metadata about those quarantine slots. Each -slot’s metadata consumes about 400 bytes, primarily to store compressed -allocation/deallocation stack traces, compared to 4 kilobytes for every -allocation. As a result, setting ReservedSlots to be slightly greater than -MaxSimultaneousAllocations doesn’t significantly increase the amount of memory -used. - -The rudimentary quarantine described above is sufficient to delay slot re-use to -accurately detect use-after-frees occurring shortly after deallocation; however, -use-after-frees that occur long after deallocation are likely to access slots -that have already been reallocated. This can lead to long-lived use-after-frees -causing reports with numerous different stack traces for unrelated allocations -and deallocations, making it difficult to identify the real -allocation/deallocation call sites. This could be improved by making -ReservedSlots orders of magnitude larger than MaxSimultaneousAllocations; -however, the amount of additional allocation metadata that this would require -allocating would significantly increase GWP-ASan’s memory profile. - -To address this, GWP-ASan makes use of a third MaxMetadata parameter to limit -the number of slots for which we store metadata. We tune the allocator such that -ReservedSlots >= MaxMetadata >= MaxSimultaneousAllocations. GWP-ASan keeps -metadata for all currently allocated slots as well as some previously -deallocated slots. Because we discard metadata for some deallocated slots, we -can not always report allocation metadata if those slots are accessed because of -a use-after-free. By setting ReservedSlots to be an order of magnitude or more -greater than MaxMetadata and MaxSimultaneousAllocations, we make the quarantine -so large that many allocations have to occur before a slot is reused. This -ensures that even long-lived use-after-frees are not likely to be reallocated -before they’re accessed. If no metadata for the slot is available, then a useful -report can’t be sent; however, we eliminate many false reports. Short-lived -use-after-frees are still likely to be accessed before the metadata for the slot -is eliminated. Using random eviction to purge old metadata entries allows -metadata for old allocations to sometimes survive long enough to be reported for -long-lived use-after-frees. - -[<img alt="image" -src="/Home/chromium-security/articles/gwp-asan/diag4.png">](/Home/chromium-security/articles/gwp-asan/diag4.png) - -The debug allocator currently only services allocations less than or equal to a -single page in size. This is not a fundamental limitation in the design--it’s -possible to service larger allocations by increasing the size of a slot to be -multiple pages. It simply hasn’t been addressed yet because allocations larger -than a page are relatively rare. - -Unactionable crash reports can occur when a pointer is corrupted and the -overwritten value happens to accidentally point to a guard page or deallocated -slot in the GWP-ASan region. When such a wild pointer is accessed, it causes a -GWP-ASan report to be sent but it’s not actionable because the crash is caused -by an unrelated bug that corrupted the pointer value to point to an unrelated -allocation. In practice, such unactionable reports tend to occur on 32-bit -devices because the address space is smaller and the probability of a wild -pointer access touching the GWP-ASan region is much higher. GWP-ASan was -disabled for 32-bit desktop builds in order to eliminate these unactionable -reports. The allocator also explicitly maps the GWP-ASan memory region in high -memory locations to avoid the operating system choosing to place GWP-ASan region -in the bottom 32-bits of memory on 64-bit devices. - -Allocator Hooks - -GWP-ASan instruments an allocator’s allocation and deallocation routines. The -allocation instrumentation performs sampling to only route a fraction of -allocation requests to the debug allocator. The deallocation instrumentation -determines if the given allocation was allocated by the debug allocator and -routes the request to the debug allocator if so. Determining if an allocation -was returned by GWP-ASan is as simple as checking that the address is in -GWP-ASan’s fixed memory region and matching the address to the slot’s allocation -metadata. - -Production allocators are normally highly optimized so adding additional -instrumentation to the allocation/deallocation hot paths can easily introduce -significant performance regressions. While the debug allocator’s overhead can be -reduced to an arbitrary amount by adjusting the sampling probability, the -overhead of the instrumentation itself introduces a constant overhead. Some -allocation-heavy microbenchmarks regressed up to 5% when introducing allocator -instrumentation no matter how low the sampling probability was made. - -The instrumentation regression stems from the allocator hot-paths being very -performance sensitive and that instrumenting those hot-paths in Chrome requires -introducing a costly indirect call. GWP-ASan uses process sampling, only -enabling instrumentation for a fraction of processes, to reduce the -instrumentation overhead. This allows reducing the instrumentation overhead -arbitrarily and using more memory per-enabled process. - -Crash Handler - -Chrome is migrating to using crashpad for crash handling. Unlike its predecessor -breakpad, crashpad works almost entirely out-of-process. GWP-ASan registers a -hook in the crashpad process to inspect crashing processes in order to determine -if the crashes are related to GWP-ASan. On initialization, GWP-ASan saves the -address of the internal allocator object in a crashpad annotation so that the -crash handler can access it in the event of a crash. If the crashpad hook finds -this annotation, it reads the GWP-ASan allocator information to determine if the -crash occurred due to an access to a GWP-ASan allocation. If so, it attaches -[metadata](https://chromium.googlesource.com/chromium/src/+/refs/tags/79.0.3924.1/components/gwp_asan/crash_handler/crash.proto) -for the associated allocation to the crash report. - -# Tuning - -Chrome uses a multi-process model with different types of processes with varying -lifetimes and allocator demands. For example, there is a single browser process -for the entire lifetime of a given browser window while many renderer processes -can be launched and destroyed in a single tab. A browser process could be active -for weeks and make tens of billions of allocations while other processes may -live for milliseconds and make thousands of allocations. Accommodating both -types of processes is tricky because there is a tension between GWP-ASan -regularly sampling allocations and exhausting its fixed supply of memory. - -GWP-ASan exhausts its memory when all MaxSimultaneousAllocations slots are taken -and new allocations can’t be serviced. This can occur when all of the -allocations are long-lived, e.g. freed long after allocation or never freed at -all. If GWP-ASan runs out of allocations early in a process’ lifetime then the -majority of the process’ allocations go unsampled. - -In order to better understand allocation behavior we analyze heap traces for -different runs of Chromium. The following trace comes from opening a browser, -playing a YouTube video for ten seconds, and then closing the browser. The -following visualization shows allocation lifetimes for malloc() allocations in -the GPU process. - -<img alt="image" -src="https://lh3.googleusercontent.com/zNvAZs5kvLi3pWg95qzTx44-YEnV_cPhxUz5Zis7N3PHz3O8mTUl8AmyHRq4mBTyHlKLoHt8W4Ho-I4Ir8-mgShjxJBbBt4m0GMjUIOBPpf-paaeHpQcrjwLapXkHlvyK23uYzU-"> - -Every vertical bar represents two thousand allocations subdivided into different -allocation lifetimes. The horizontal axis is the process lifetime. This process -makes approximately 250,000 allocations. Most allocations are freed within 25 -milliseconds, and only 4% of allocations are never freed during the process’ -lifetime. - -The following graph is for allocations made using PartitionAlloc in the YouTube -renderer process: - -<img alt="image" -src="https://lh3.googleusercontent.com/DMRz54twMEpT7jM1N5YRptzCIbhaXXU3aAIfZ4cFbxEa47OcXLg6SosZJ4SN-TNEVkK8aVAv_jGzgdOvs18H8Bwatn0GdjLoswBywWCl83ON4fzTG8jpMoAJm0uJ-9firc5-7NtY"> - -This process makes about 1.1 million allocations and about 7% go unfreed. In -both examples, unfreed allocations cluster at the beginning of the process’ -lifetime. Because of the difference in number of total and long-lived -allocations, the renderer process may exhaust GWP-ASan allocations early with -the same parameters that would sample the GPU process without exhaustion. - -Long lifetime allocations can also lead to temporary allocator exhaustion, for -example if the allocations are not freed until right before process destruction. -Modeling simulated runs with different GWP-ASan configurations over different -heap traces best illustrates what allocator behavior can occur in practice. The -following is a simulated run for the renderer trace above with sampling -probability 1/1000 and 16 simultaneous allocations: - -<img alt="image" -src="https://lh3.googleusercontent.com/443plq4yGGNrGszyiQZqIye4zoN-pb09q0qAUzz5qOtatSNKuFzI8sz29Ehlsr_EQHRlfgk0hWRY1gpgoeLXB6gSrSgKqJ9crm3XztePIEYnKWY7w1-lYkWh6Z_85W_snmZYLGqF" -height=365 width=730.311111111111> - -The bars represent allocation lifetimes, with the vertical axis being time. In -the simulation above GWP-ASan runs out of allocations for most of the process -lifetime with occasional bursts of sampling as long-lived allocations are freed -and re-used until they are replaced by new long-lived allocations. - -To avoid allocator exhaustion, the allocator must use more memory per process or -reduce the sampling probability. The following is a simulation run with sampling -probability 1/8000 and 64 simultaneous allocations: - -<img alt="image" -src="https://lh6.googleusercontent.com/64as-cfN6-NoQqkrvxQ3bzziNscyMgOB56gqaqpaayVAcMHRxdTH_aCc5cg42k02T4xW8JXgojEWl9RZZNIGwCNK1X19lvWflOSc_Mgfg-tVEssi_BuJs35Xdl9dBXzvAOmYjVRS" -height=360 width=719.7338262476894> - -In this simulation GWP-ASan is able to evenly sample the entire process’ -lifetime despite the presence of long-lived and unfreed allocations. Some runs -may still be unlucky and run out of allocations early, but it’s far less common. - -In practice, because of process sampling we can allocate more memory per enabled -process. GWP-ASan’s production settings only sample a small fraction of -processes, so it’s safe to allocate more memory for every enabled process. - -Instead of uniformly reducing the sampling probability for all processes, -GWP-ASan picks a sampling probability from a range of probabilities at -initialization. The sampling probability may sometimes be more frequent (and -lead to early allocator exhaustion), or less frequent (and lead to fewer -detected errors), than optimal. However, it allows accommodating different -allocation behavior in different processes. - -# Results - -The Chrome project makes extensive use of ASan in unit tests and during fuzzing -with [ClusterFuzz](https://google.github.io/clusterfuzz/) to detect memory -errors early. As a result, the bugs GWP-ASan finds tend to be where our current -fuzzing and test infrastructure don't sufficiently test the underlying error -conditions. Unit and integration tests typically tend to only test expected -success and failure conditions. Fuzzers test a wider variety of inputs, but -coverage isn’t universal. Furthermore, fuzzing is well suited for testing -specific narrowly-scoped components like parsers and other input processors, but -not all memory safety errors in Chrome fit that description. - -Some of the types of bugs that GWP-ASan has been successful in finding include: - - Race conditions. These may manifest as races between two threads freeing an - allocation and using it, or an event firing at an inopportune time such that - an allocation used by the parent event loop is freed by the event. - ClusterFuzz may not be able to exercise the correct conditions to trigger - the race or may not reproduce the racy crash reliably enough to satisfy a - heuristic to avoid reporting false positives. - - Chrome- or OS-specific configuration bugs. Some bugs may only manifest in - configurations that are not exercised by Chrome’s testing and fuzzing - infrastructure. - - Bugs in UI code. Unit tests and fuzzers tend not to exercise UI code. UI - code is also susceptible to lifetime and bounds-related errors though they - are more likely to be stability issues instead of security issues. - -One example issue is [this](https://crbug.com/977341) bug in Skia. The -underlying memory error is a racy use-after-free where two threads -near-simultaneously free and access an allocation. This bug had been causing -crashes on macOS for a while, but it was difficult to spot the issue because the -crashes occurred in different places depending on which underlying allocation -was corrupted. With GWP-ASan it was immediately clear where the error occurred, -but both threads freeing and accessing the allocation were doing so after -locking the same mutex so it should have been impossible. With the use and -deallocation stack traces proving that this was occurring despite the mutex, it -was easy to track the bug down to the Skia mutex class. The macOS implementation -did not account for spurious wake-ups and could violate mutual exclusion. -Without the information provided by GWP-ASan, it would be difficult to debug -such an issue. - -As GWP-ASan was progressively rolled out to wider audiences, it detected rarer -and rarer bugs. Frequently occurring bugs may be detected within hours of a new -canary release while some rarely-occurring bugs have only been detected in the -stable population once so far. It’s possible to find these rare errors because -GWP-ASan is deployed widely and designed to minimize unactionable reports, but -there are likely to be rare errors that we don’t catch because increasing -sampling to detect them would require unacceptable memory and performance -overhead. The [ARM Memory Tagging -Extension](https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety) -and similar hardware-assisted memory tagging schemes would allow implementing a -[similar error -detector](https://github.com/google/sanitizers/blob/master/hwaddress-sanitizer/login_summer19_03_serebryany.pdf) -with much lower memory and performance overhead and a much higher probability of -detecting errors. Such memory tagging schemes also allow detecting stack bounds -and use-after-return errors and may even be useful as exploit mitigations. - -# Future Improvements - -GWP-ASan has a high memory overhead per allocation. Every allocation is stored -on its own page but Chrome’s median allocation size is only 32 bytes. It’s -possible to place multiple allocations on a single physical page and maintain -the ability to detect use-after-frees using a special virtual memory -configuration. The approach reduces GWP-ASan’s memory overhead at the cost of -reducing out-of-bounds error detection. - -Placing multiple allocations on the same virtual memory page would reduce -use-after-free detection because the page could not be unmapped until all of the -allocations on the page were deallocated. If a single allocation on that page -were to never be freed then use-after-free detection would be completely lost. - -It is possible to use the operating system’s shared memory facilities to work -around this constraint. It is possible to map shared memory multiple times in -the same process. This allows multiple virtual memory pages to point to the same -backing physical page. Multiple allocations can be placed on the same backing -physical page but every allocation can be given it’s own unique slot/virtual -page. This way, once an allocation is freed, the slot can be unmapped to detect -use-after-frees without interfering with the other allocations. Only a fraction -of allocations will be able to be left- or right-aligned within the page so -out-of-bounds errors detection would suffer with this scheme; however, in -practice use-after-free exceptions are much more common. - -[<img alt="image" -src="/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram3.png">](/Home/chromium-security/articles/gwp-asan/gwp-asan-diagram3.png) - -This approach allows significantly increasing memory density and therefore the -number of simultaneous allocations. It’s conceivable that the memory overhead of -allocation metadata like stack traces would come to dominate GWP-ASan’s memory -usage instead of the wasted page overhead. - -Increasing the number of simultaneous allocations helps prevent allocator -exhaustion. Mobile platforms especially tend to be much more memory constrained -so deploying GWP-ASan in those environments may necessitate use of this -approach. - -Thanks to Matthew Denton, Adrian Taylor, Chris Palmer, Kostya Serebryany, Matt -Morehouse, and Mitch Phillips for their feedback.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/articles/index.md b/chromium/docs/website/site/Home/chromium-security/articles/index.md deleted file mode 100644 index b3ac7140303..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/articles/index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: articles -title: Articles ---- - -Technical articles about Chrome Security. - -* [GWP-ASan: Sampling heap memory error detection - in-the-wild](/Home/chromium-security/articles/gwp-asan) — November - 2019 -* [chrome://sandbox - Sandbox Diagnostics for - Windows](/Home/chromium-security/articles/chrome-sandbox-diagnostics-for-windows) - — February 2020
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/binding-integrity/index.md b/chromium/docs/website/site/Home/chromium-security/binding-integrity/index.md deleted file mode 100644 index 2982982a2eb..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/binding-integrity/index.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: binding-integrity -title: Binding Integrity ---- - -Binding Integrity Project - -Motivation - -One of the reasons that browsers are easier to compromise than other kinds of -client software is that they provide scripting capabilities to a potential -attacker. As such, many of the exploits we’ve seen begin with a JavaScript -program obtaining and manipulating a freed block of C++ memory. Although the -Chrome sandboxing architecture provides excellent protection in this situation, -we’d like to prevent JavaScript from getting freed blocks of memory in the first -place, so as to make the full exploitation of Chrome even harder than it already -is. - -Approach - -At the time a C++ object is created, we know the corresponding V8 type with -which it will be later wrapped for use by V8. We devise an unguessable (by the -attacker) representation for each type and put it into the C++ object when it is -constructed. We similarly zero out this information at destruction time. - -At the time of a method callback into the C++ object, V8 happens to know the -type that is expected to be associated with it. It can then determine what type -representation should have been set into the block of memory at creation time, -and check that it is still valid. Free blocks will have zeros (or will have been -clobbered by heap freelists), and will fail the check. Mis-typed blocks will -have different values, and will fail the check. Blocks crafted by the attacker -won’t have valid values because the type information representation is -unguessable, and will fail the check. At this point the renderer can shoot -itself, rather than proceeding into C++ with corrupted memory. - -But these method invocation calls are very hot code paths, and we don’t want to -introduce the overhead of another test and branch here. - -As it turns out, the V8 wrapper objects contain reference pointers back to the -blocks of C++ memory, and these do a good job of keeping the memory alive. Once -wrapped, a block is unlikely to be freed. Hence, most of the cases involve -wrapping a block that is already free, and we get nearly the full benefit by -doing the check at wrapper creation time only, where performance is not -important. - -Implementation - -It is important that we do not bloat the size of the objects in order to hold -this type representation. - -Many (but not all) objects wrapped by V8 inherit somewhere from a class called -ScriptWrappable, which is a single pointer wide. It holds a pointer to the C++ -object’s wrapper when it is wrapped, or NULL otherwise. We can re-use the slot -that holds the the wrapper pointer (which would otherwise be NULL for an -unwrapped object) to hold the type information, because we only need the type -information for unwrapped objects. Masking in a 1 in the bottom bit (otherwise -unused due to aligned pointers) allows us to distinguish between the two cases. - -Hence, for objects that are to be checked in this manner, they must inherit -somewhere from the ScriptWrappable class (which need not be a common base -class). - -This implies that all objects that inherit from ScriptWrappable and have their -own .idl files will have to call - -ScriptWrappable::init(this); - -as part of their constructors. Passing “this” is necessary to select between N -overloaded versions of ScriptWrappable::init() based upon the type of the -object. - -The implementations of the N overloaded versions of ScriptWrappable::init() are -automatically generated by the .idl compiler (CodeGeneratorV8.pm at present) -from the .idl files. The .idl files need not specify which objects are -scriptwrappable, as the compiler can deduce this from type inheritance via -partially specialized template tricks. - -The unguessable nature of the type representation is achieved by relying on ASLR -to randomize the address of a per-type instance of an existing V8 data structure -called WrapperTypeInfo. The address of the WrapperTypeInfo structure for a given -type thus already provides what is required here. - -Note that ScriptWrappable was originally invented to provide a performance -improvement. One additional benefit of this change is that making more objects -ScriptWrappable makes chrome faster.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/boringssl/contributing/index.md b/chromium/docs/website/site/Home/chromium-security/boringssl/contributing/index.md deleted file mode 100644 index 2749000269f..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/boringssl/contributing/index.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/boringssl - - BoringSSL -page_name: contributing -title: Contributing to BoringSSL ---- - -## Location of the code - -The [BoringSSL](/Home/chromium-security/boringssl) code lives at -<https://boringssl.googlesource.com/boringssl.git>. - -It is mapped into the Chromium tree via -[src/DEPS](https://chromium.googlesource.com/chromium/src/+/HEAD/DEPS) to -[src/third_party/boringssl](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boringssl/&sq=package:chromium) - -## Filing bugs - -Bugs are filed under the [BoringSSL issue -tracker](https://bugs.chromium.org/p/boringssl/issues/list). - -## Building - -Refer to -[BUILDING.md](https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md) -for the canonical build instructions. Assuming those haven't changed, set things -up to build through ninja by executing: - -```none -cd src/third_party/boringssl/src -cmake -GNinja -B build -ninja -C build -``` - -Once the ninja files are generated you can re-build from other directories -using: - -```none -ninja -C <path-to-boringssl-src-build> -``` - -## Running the tests - -See -[instructions](https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md#Running-tests) -in BUILDING.md to run the tests. From a Chromium checkout, this incantation may -be used: - -```none -cd src/third_party/boringssl/src -ninja -C build run_tests -``` - -## Uploading changes for review - -See -[CONTRIBUTING.md](https://boringssl.googlesource.com/boringssl/+/HEAD/CONTRIBUTING.md) -in the BoringSSL repository. - -## Rolling DEPS into Chromium - -Because BoringSSL lives in a separate repository, it must be "rolled" into -Chromium to get the updates. - -To roll BoringSSL create a changelist in the Chromium repository that modifies -[src/DEPS](https://chromium.googlesource.com/chromium/src/+/HEAD/DEPS) and -re-generates the gn and asm files: - -* Simple example: <https://codereview.chromium.org/866213002> (Just - modifies DEPS): -* More complicated example: - <https://codereview.chromium.org/693893006> (ASM changed and test - added) - -There is a script to automate all these steps: - -```none -python3 third_party/boringssl/roll_boringssl.py -``` diff --git a/chromium/docs/website/site/Home/chromium-security/boringssl/index.md b/chromium/docs/website/site/Home/chromium-security/boringssl/index.md deleted file mode 100644 index 69dec66f60c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/boringssl/index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: boringssl -title: BoringSSL ---- - -We have used a number of patches on top of OpenSSL for many years. Some of them -have been accepted into the main OpenSSL repository, but many of them don’t mesh -with OpenSSL’s guarantee of API and ABI stability and many of them are a little -too experimental. - -But as Android, Chrome and other products have started to need some subset of -these patches, things have grown very complex. The effort involved in keeping -all these patches (and there are more than 70 at the moment) straight across -multiple code bases is getting to be too much. - -So we’re switching models to one where we import changes from OpenSSL rather -than rebasing on top of them. The -[result](https://boringssl.googlesource.com/boringssl/) (at the time of writing) -is used in Chrome on Android, OS X, and Windows. Over time we hope to use it in -Android and internally too. - -There are no guarantees of API or ABI stability with this code: we are not -aiming to replace OpenSSL as an open-source project. We will still be sending -them bug fixes when we find them and we will be importing changes from upstream. -Also, we will still be funding the Core Infrastructure Initiative and the -OpenBSD Foundation. - -But we’ll also be more able to import changes from LibreSSL and they are welcome -to take changes from us. We have already relicensed some of our prior -contributions to OpenSSL under an ISC license at their request and completely -new code that we write will also be so licensed. - -(Note: the name is aspirational and not yet a promise.)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/brag-sheet/index.md b/chromium/docs/website/site/Home/chromium-security/brag-sheet/index.md deleted file mode 100644 index 3a9fbcfd98c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/brag-sheet/index.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: brag-sheet -title: Security Brag Sheet ---- - -### Our Team and Resources - -* Our team includes some of the best security professionals in the - business. -* We work closely with top researchers like Michal Zalewski (lcamtuf) - and Tavis Ormandy (taviso). -* We contract with experts like iSec Partners and Chris Rohlf for - targeted assessments. -* We dedicate thousands of CPU cores to fuzz projects such as - [WebKit](http://blog.chromium.org/2012/04/fuzzing-for-security.html), - [Adobe - Flash](http://googleonlinesecurity.blogspot.com/2011/08/fuzzing-at-scale.html) - or [Chrome's PDF viewer](http://j00ru.vexillium.org/?p=1175). - -**White Papers** - -* Chrome leads in [white papers from 2 different security - firms](https://www.blog.google/products/chrome-enterprise/2-new-white-papers-examine-enterprise-web-browser-security/). -* Chrome leads in [white paper from respected security firm - Accuvant](http://www.accuvant.com/sites/default/files/AccuvantBrowserSecCompar_FINAL.pdf). -* Chrome leads in response time and reward program effectiveness in - [this independent study from - Berkeley](https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_finifter.pdf). -* Chrome leads in [recommendations from respected German government - organization, the - BSI](https://www.bsi-fuer-buerger.de/SharedDocs/Downloads/DE/BSIFB/Publikationen/BSI-E-CS_001.pdf). - -### Containing Attacks - -* We have an [integrated sandbox](/Home/chromium-security/guts) that - reduces the impact of most common vulnerabilities, and is much - stronger than approaches used by other browsers. -* We have [Site Isolation](/Home/chromium-security/site-isolation) to - protect website data from compromised renderer processes and side - channel attacks like Spectre. -* We have [critical](/developers/severity-guidelines) security - vulnerabilities relatively infrequently compared to other browsers. -* We have [leading sandbox protection for the Adobe Flash - plug-in](http://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html). -* We have [unique - techniques](http://blog.chromium.org/2010/06/improving-plug-in-security.html) - for significantly mitigating the security risks posed by plug-ins. -* We have a robust built-in [sandboxed PDF - viewer](http://chrome.blogspot.com/2010/11/pdf-goodness-in-chrome.html) - which has leading security. -* We implement [Strict Transport - Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) - and [preloaded public key - pinning](http://www.imperialviolet.org/2011/05/04/pinning.html), - which protected our users against the [fraudulent Diginotar - certificate](https://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/) - for \*.google.com. -* We implement [root CA verification by the underlying operating - system](/Home/chromium-security/root-ca-policy). -* We have leading HTTPS security through features such as [mixed - script - blocking](http://blog.chromium.org/2012/08/ending-mixed-scripting-vulnerabilities.html). - -### Vulnerability Response - -* We are committed to releasing a fix for any - [critical](/developers/severity-guidelines) security vulnerabilities - in [under 60 - days](http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html). -* On average, we release fixes for [high and - critical](/developers/severity-guidelines) severity vulnerabilities - in about 30 days. -* We have a demonstrated ability to get fixes to users [in - under](http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates.html) - [24 hours](http://twitter.com/VUPEN/status/46391969903161345). -* We ensure updates are deployed in a [timely - manner](http://www.techzoom.net/publications/silent-updates/), and - invest in [new - technologies](/developers/design-documents/software-updates-courgette) - to do so. -* We have a [Vulnerability Rewards - Program](http://www.chromium.org/Home/chromium-security/vulnerability-rewards-program) - to encourage third-party researchers to report vulnerabilities they - discover. -* We work with the security community and have a [Security Hall of - Fame](http://www.chromium.org/Home/chromium-security/hall-of-fame) - to acknowledge third-parties that materially contribute to improving - our security. -* We have the [successful Pwnium - competition](http://chrome.blogspot.com/2012/03/pwnium-great-exploits-fast-patches.html), - with large prizes, to keep us up to date with the latest, most - advanced attacks. - -### Advanced Anti- Phishing and Malware defenses - -* We [warn - you](http://www.google.com/support/chrome/bin/answer.py?answer=99020&hl=en) - when you're about to visit a website we've previously identify as a - malware or phishing site. -* We keep the user better informed against phishing and similar - attacks by [presenting the most relevant - information](http://chrome.blogspot.com/2010/10/understanding-omnibox-for-better.html). -* We implement new, [browser-based security - enhancements](http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html) - to protect you against malicious sites. - -### High profile researchers and publications say nice things about us - -* A [Fortune - article's](http://tech.fortune.cnn.com/2011/03/21/google-fixes-flashs-security-issues-ahead-of-adobe/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+fortunebrainstormtech+%28Fortune+Brainstorm+Tech%29) - headline subtext: "Google's record on Chrome browser security is - impressive, and that is important." -* An [interview with Dino Dai Zovi and Charlie - Miller](http://www.h-online.com/security/features/Hackers-versus-Apple-1202598.html): - "I recommend that users surf the web with Google Chrome, disable - unnecessary plug-ins, and use site-based plug-in security settings - for the plug-ins that they do need." -* An article noting [Chrome's unique 3-years-in-a-row - survival](http://www.computerworld.com/s/article/9214022/Google_s_Chrome_untouched_at_Pwn2Own_hack_match) - at the Pwn2Own competition: "the browser will have survived three - consecutive Pwn2Owns, a record." -* An article [noting our agility and fast security - updates](http://www.h-online.com/security/news/item/Google-closes-Flash-hole-faster-than-Adobe-1209932.html): - "Google has once again reacted faster than Adobe itself" -* A more mainstream publication [interviews HD - Moore](http://content.usatoday.com/communities/technologylive/post/2011/03/20-grand-not-enough-to-entice-hackers-to-crack-google-chrome/1), - who calls Chrome the toughest browser: "Chrome was likely the most - difficult target due to the extensive sandboxing." -* An [article in the very mainstream Washington - Post](http://www.washingtonpost.com/business/apples-taking-30-percent-of-app-store-subscriptions-is-an-unkind-cut/2011/02/14/ABbMfvH_story.html) - notes that whilst other browsers are starting to chase Chrome's - speed, Chrome is still the choice of the security conscious: "Both - IE 9 and Firefox 4 look like major, welcome advances. But each falls - short of Chrome in one key aspect: security." -* A [TIME - article's](http://techland.time.com/2011/03/14/pwn2own-roundup-apple-fails-google-stays-strong/) - headline includes: "Google Stays Strong" -* An [interesting interview with John Wilandar and Chaouki - Bekrar](http://www.securityvibes.com/community/en/blog/2011/03/25/firefox-4-and-the-state-of-browser-security--the-expert-view) - (VUPEN CEO). The interview is nominally about Firefox 4 but includes - quotes such as "I'd say Chrome's sandboxing model still beats all - the other browsers from an end user perspective.", "At VUPEN, we - measure the security of web browsers not by counting the number of - their vulnerabilities, but by counting the number of days, weeks, or - months that the vendor is taking to fix vulnerabilities affecting - their browsers... Today, Google is fixing Chrome vulnerabilities - much faster than any other vendor – usually one or two security - updates each month. Microsoft, Mozilla, and Apple are are usually - releasing security updates for their browsers every 3 months, which - is too long.", "Relying on third-party auditor through reward and - bounty programs is the most effective way to improve the security of - browsers".
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/automated-triage/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/automated-triage/index.md deleted file mode 100644 index 620d1e340dc..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/automated-triage/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/bugs - - Security Bugs-- -page_name: automated-triage -title: automated triage ---- - diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/automatic-filing/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/automatic-filing/index.md deleted file mode 100644 index 23fb7aacc36..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/automatic-filing/index.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/bugs - - Security Bugs-- -page_name: automatic-filing -title: Clusterfuzz automatic bug filing ---- - -**This page is still under construction.** - -ClusterFuzz will file certain issues automatically. Currently, this is only done -for reproducible security bugs for which it does not seem like a similar issue -has been filed already. - -If you have a concern, please file a bug using [this -template](https://bugs.chromium.org/p/chromium/issues/entry?components=Tools%3EStability%3EClusterFuzz).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/developing-fuzzers-for-clusterfuzz/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/developing-fuzzers-for-clusterfuzz/index.md deleted file mode 100644 index 9fedf893bb3..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/developing-fuzzers-for-clusterfuzz/index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/bugs - - Security Bugs-- -page_name: developing-fuzzers-for-clusterfuzz -title: Developing Fuzzers for ClusterFuzz ---- - -**[ClusterFuzz documentation has moved](https://google.github.io/clusterfuzz/)**
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/index.md deleted file mode 100644 index 4b2b350ea7e..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/index.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: bugs -title: Security Bugs-- ---- - -Bugs happen. We know this to be as true as other fundamental laws of physics so -long as we have humans writing code to bring new features and improvements to -Chromium. We also know some of these bugs will have security consequences, so we -do a number of things to prevent, identify, and fix Chromium security bugs. - -[TOC] - -## Security fuzzing - -We've build fuzzing infrastructure that automatically and continuously security -["fuzz" test](http://en.wikipedia.org/wiki/Fuzz_testing) Chrome to find new bugs -and help engineers patch and test fixes. -[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz), as the system is -affectionately named, consists of 12000+ cores and fuzzes hundreds of millions -of test cases each day to produce de-duplicated security bugs with small -reproducible test cases. Since it was built (in 2009), ClusterFuzz has helped us -find and fix [roughly two thousand security bugs in -Chromium](https://code.google.com/p/chromium/issues/list?can=1&q=label%3AClusterFuzz+-status%3AWontFix%2CDuplicate+Type%3DBug-Security+&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -and other third party software. - -## Vulnerability Response and Remediation - -The [security sheriff](/Home/chromium-security/security-sheriff) is a rotating -role that handles all incoming and open security bugs. to all reported security -bugs. We are committed to releasing a fix for any -[critical](/developers/severity-guidelines) security vulnerabilities in [under -60 -days](http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html). - -## Rewarding Vulnerability Research - -We try to reward awesome security research from external folks in a few ways: -[Chromium Vulnerability -Rewards](http://www.chromium.org/Home/chromium-security/vulnerability-rewards-program)is -our ongoing program to reward security bug reports in Chrome and Chrome OS. -**Pwnium** is a contest we run semi-regularly for proof-of-concept Chrome -exploits. Our motivation is simple: we have a big learning opportunity when we -receive full end-to-end exploits. Not only can we fix the bugs, but by studying -the vulnerability and exploit techniques we can enhance our mitigations, -automated testing, and sandboxing. This enables us to better protect our users. - -* [Pwnium - 4](http://blog.chromium.org/2014/01/show-off-your-security-skills.html) - at CanSecWest in March, 2014. - [results](https://docs.google.com/presentation/d/1c90yZXNHs7w8oi7uXveEOCx5-8O_NZIxolEKalscuAQ/view). -* [Pwnium - 3](http://blog.chromium.org/2013/01/show-off-your-security-skills-pwn2own.html) - at CanSecWest in 2013: - [results](http://blog.chromium.org/2013/03/pwnium-3-and-pwn2own-results.html) -* [Pwnium - 2](http://blog.chromium.org/2012/08/announcing-pwnium-2.html) at - Hack in the Box in 2012: - [results](http://blog.chromium.org/2012/10/pwnium-2-results-and-wrap-up_10.html) -* [Pwnium - 1](http://blog.chromium.org/2012/02/pwnium-rewards-for-exploits.html) - at CanSecWest in 2012: results ([Part - 1](http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html), - [Part - 2](http://blog.chromium.org/2012/06/tale-of-two-pwnies-part-2.html)) - -**Pwn2Own** is an independent contest that similarly awards proof-of-concept -exploits. We support these contests with sponsorships. - -* Pwn2Own at CanSecWest 2014: - [results](https://docs.google.com/presentation/d/1c90yZXNHs7w8oi7uXveEOCx5-8O_NZIxolEKalscuAQ/view). -* Pwn2Own at PacSec 2013: [Chrome on Android exploit - writeup](https://docs.google.com/document/d/1tHElG04AJR5OR2Ex-m_Jsmc8S5fAbRB3s4RmTG_PFnw/edit?usp=sharing) -* Pwn2Own at CanSecWest 2013: - [results](http://blog.chromium.org/2013/03/pwnium-3-and-pwn2own-results.html), - MWR labs' write up of their Chrome exploit ([Part - 1](https://labs.mwrinfosecurity.com/blog/2013/04/19/mwr-labs-pwn2own-2013-write-up---webkit-exploit/)) - ([Part - 2](https://labs.mwrinfosecurity.com/blog/2013/09/06/mwr-labs-pwn2own-2013-write-up---kernel-exploit/)) - -## Presentations - -* [Detect bad-casting at runtime with UndefinedBehavior - Sanitizer](https://drive.google.com/file/d/0Bxvv8gduedamTEJCUlN6eERtWUE/view?usp=sharing) - -## Links - -* [Bug Fix Times - Statistics](https://docs.google.com/spreadsheets/d/1XyFE36AZFpbPkhu-fQO_Yu8R_eU_7IvsRWSHWXnX7hI/edit#gid=2094956046)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs/index.md deleted file mode 100644 index b9e2ee82a41..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs/index.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/bugs - - Security Bugs-- -page_name: reproducing-clusterfuzz-bugs -title: Reproducing ClusterFuzz bugs ---- - -If you've been assigned a ClusterFuzz bug but aren't sure what to do next, -you're in the right place. If you want to help catch more bugs, you should also -read up on [developing new -fuzzers](/Home/chromium-security/bugs/developing-fuzzers-for-clusterfuzz) and -[using ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz). - -Noticed a problem? File a bug using [this -template](https://bugs.chromium.org/p/chromium/issues/entry?components=Tools%3EStability%3EClusterFuzz). - -[TOC] - -## Getting started - -In the best case scenario, downloading the minimized test case and running it in -chrome (or whatever binary you are testing) will be enough to reproduce the -issue. Usually, you will also need to include the command line flags specified -in the report as well. - -When this doesn't work, you can also try downloading the exact build that the -crash was found in via the "build" link in the ClusterFuzz report. If you are -able to reproduce the issue using that, but not in your build, it may be a sign -that you need to enable some kind of memory debugging tool, such as -[AddressSanitizer](/developers/testing/addresssanitizer). The tool that you -should will depend on the type of bug. See the common problems section for more -information. - -More complicated cases, such as test cases with gestures, may require you to use -the ClusterFuzz local reproduction script. There are several quirks about that -bot environment that this script is able to emulate which may also help you -reproduce the crash consistently. Download the "local reproduction config" file -from the report, and pass it as the --config argument to the script. If you -haven't installed the script yet, see the instructions below. Unfortunately, it -is Googler-only at the moment :( - -If you still aren't able to reproduce the issue, you have a few options. For -certain job types such as -[SyzyASan](https://code.google.com/p/syzygy/wiki/SyzyASanBug) ones, a minidump -may also be available. The report itself also includes some information about -what may have gone wrong. If this is enough to work with, you could attempt a -speculative fix. If there is nothing actionable in the report, simply mark it as -WontFix. - -## Common problems - -* Test cases with gestures tend to be very difficult to reproduce. If - you notice that a test case has gestures (look for the "interaction - gestures" section at the top of the report), you should try using - the local reproduction script. -* Some test cases do not reproduce correctly unless served over HTTP. - Look for a "requires" section in the report, or a notification that - the test case requires HTTP on the bug. -* You may not be able to reproduce all issues in a normal chromium - build since ClusterFuzz makes heavy use of various memory debugging - tools. Try using - [AddressSanitizer](/developers/testing/addresssanitizer), - [SyzyASan](https://code.google.com/p/syzygy/wiki/SyzyASanBug), - [MemorySanitizer](/developers/testing/memorysanitizer), - [LeakSanitizer](/developers/testing/leaksanitizer), - [ThreadSanitizer](/developers/testing/threadsanitizer-tsan-v2), - [UndefinedBehaviorSanitizer](/developers/testing/undefinedbehaviorsanitizer), - or whichever tool is being used in the report that has been assigned - to you. -* Sometimes, a crash just isn't reproducible. If a crash is marked as - unreproducible in ClusterFuzz and you're seeing similar results, - don't spend too long re-running it. If the information in the report - isn't enough to work with, don't be afraid to mark the bug as - WontFix. -* Some tools, like the IPC fuzzer, have a more complicated setup - process. In these cases, we try to provide additional help links in - the report itself to documentation which may be useful. - -## Setting up the local reproduction script (Googler only) - -If you weren't able to reproduce the issue using only the minimized test case -and command line arguments from the report, you may want to try using the local -reproduction script. It attempts to mimic the environment on the ClusterFuzz -bots as closely as possible, and will attempt to run the test multiple times in -case it's flaky. - -See -[goto.google.com/clusterfuzz-repro](http://goto.google.com/clusterfuzz-repro) -for setup details.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/bugs/using-clusterfuzz/index.md b/chromium/docs/website/site/Home/chromium-security/bugs/using-clusterfuzz/index.md deleted file mode 100644 index 0174a805c69..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/bugs/using-clusterfuzz/index.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/bugs - - Security Bugs-- -page_name: using-clusterfuzz -title: Using ClusterFuzz ---- - -**[ClusterFuzz documentation has moved](https://google.github.io/clusterfuzz/)**
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/index.md b/chromium/docs/website/site/Home/chromium-security/certificate-transparency/index.md deleted file mode 100644 index a8abe8bfdd7..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: certificate-transparency -title: Certificate Transparency ---- - -This paged has moved to -<https://goo.gl/chrome/ct-policy#chromium-certificate-transparency-policy>
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/index.md b/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/index.md deleted file mode 100644 index d8e7860906a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/index.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/certificate-transparency - - Certificate Transparency -page_name: log-policy -title: Certificate Transparency Log Policy ---- - -Please see -<https://goo.gl/chrome/ct-policy#chromium-certificate-transparency-policy> for -details on the Certificate Transparency Log Policy.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/mmd_monitor_root.crt b/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/mmd_monitor_root.crt deleted file mode 100644 index 66299dd2bdf..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/certificate-transparency/log-policy/mmd_monitor_root.crt +++ /dev/null @@ -1,34 +0,0 @@ ------BEGIN CERTIFICATE----- -MIIFzTCCA7WgAwIBAgIJAJ7TzLHRLKJyMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV -BAYTAkdCMQ8wDQYDVQQIDAZMb25kb24xFzAVBgNVBAoMDkdvb2dsZSBVSyBMdGQu -MSEwHwYDVQQLDBhDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3kxITAfBgNVBAMMGE1l -cmdlIERlbGF5IE1vbml0b3IgUm9vdDAeFw0xNDA3MTcxMjA1NDNaFw00MTEyMDIx -MjA1NDNaMH0xCzAJBgNVBAYTAkdCMQ8wDQYDVQQIDAZMb25kb24xFzAVBgNVBAoM -Dkdvb2dsZSBVSyBMdGQuMSEwHwYDVQQLDBhDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVu -Y3kxITAfBgNVBAMMGE1lcmdlIERlbGF5IE1vbml0b3IgUm9vdDCCAiIwDQYJKoZI -hvcNAQEBBQADggIPADCCAgoCggIBAKoWHPIgXtgaxWVIPNpCaj2y5Yj9t1ixe5Pq -jWhJXVNKAbpPbNHA/AoSivecBm3FTD9DfgW6J17mHb+cvbKSgYNzgTk5e2GJrnOP -7yubYJpt2OCw0OILJD25NsApzcIiCvLA4aXkqkGgBq9FiVfisReNJxVu8MtxfhbV -QCXZf0PpkW+yQPuF99V5Ri+grHbHYlaEN1C/HM3+t2yMR4hkd2RNXsMjViit9qCc -hIi/pQNt5xeQgVGmtYXyc92ftTMrmvduj7+pHq9DEYFt3ifFxE8v0GzCIE1xR/d7 -prFqKl/KRwAjYUcpU4vuazywcmRxODKuwWFVDrUBkGgCIVIjrMJWStH5i7WTSSTr -VtOD/HWYvkXInZlSgcDvsNIG0pptJaEKSP4jUzI3nFymnoNZn6pnfdIII/XISpYS -Veyl1IcdVMod8HdKoRew9CzW6f2n6KSKU5I8X5QEM1NUTmRLWmVi5c75/CvS/PzO -MyMzXPf+fE2Dwbf4OcR5AZLTupqp8yCTqo7ny+cIBZ1TjcZjzKG4JTMaqDZ1Sg0T -3mO/ZbbiBE3N8EHxoMWpw8OP50z1dtRRwj6qUZ2zLvngOb2EihlMO15BpVZC3Cg9 -29c9Hdl65pUd4YrYnQBQB/rn6IvHo8zot8zElgOg22fHbViijUt3qnRggB40N30M -XkYGwuJbAgMBAAGjUDBOMB0GA1UdDgQWBBTzX3t1SeN4QTlqILZ8a0xcyT1YQTAf -BgNVHSMEGDAWgBTzX3t1SeN4QTlqILZ8a0xcyT1YQTAMBgNVHRMEBTADAQH/MA0G -CSqGSIb3DQEBBQUAA4ICAQB3HP6jRXmpdSDYwkI9aOzQeJH4x/HDi/PNMOqdNje/ -xdNzUy7HZWVYvvSVBkZ1DG/ghcUtn/wJ5m6/orBn3ncnyzgdKyXbWLnCGX/V61Pg -IPQpuGo7HzegenYaZqWz7NeXxGaVo3/y1HxUEmvmvSiioQM1cifGtz9/aJsJtIkn -5umlImenKKEV1Ly7R3Uz3Cjz/Ffac1o+xU+8NpkLF/67fkazJCCMH6dCWgy6SL3A -OB6oKFIVJhw8SD8vptHaDbpJSRBxifMtcop/85XUNDCvO4zkvlB1vPZ9ZmYZQdyL -43NA+PkoKy0qrdaQZZMq1Jdp+Lx/yeX255/zkkILp43jFyd44rZ+TfGEQN1WHlp4 -RMjvoGwOX1uGlfoGkRSgBRj7TBn514VYMbXu687RS4WY2v+kny3PUFv/ZBfYSyjo -NZnU4Dce9kstgv+gaKMQRPcyL+4vZU7DV8nBIfNFilCXKMN/VnNBKtDV52qmtOsV -ghgai+QE09w15x7dg+44gIfWFHxNhvHKys+s4BBN8fSxAMLOsb5NGFHE8x58RAkm -IYWHjyPM6zB5AUPw1b2A0sDtQmCqoxJZfZUKrzyLz8gS2aVujRYN13KklHQ3EKfk -eKBG2KXVBe5rjMN/7Anf1MtXxsTY6O8qIuHZ5QlXhSYzE41yIlPlG6d7AGnTiBIg -eg== ------END CERTIFICATE----- diff --git a/chromium/docs/website/site/Home/chromium-security/chromium-and-emet/index.md b/chromium/docs/website/site/Home/chromium-security/chromium-and-emet/index.md deleted file mode 100644 index bae2f403c0a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/chromium-and-emet/index.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: chromium-and-emet -title: Chromium and EMET ---- - -[EMET](http://technet.microsoft.com/en-us/security/jj653751) is a security tool -provided by Microsoft to improve exploit-resistance of software running on -Windows. Enterprises and users can deploy EMET on systems and configure which -applications are protected by it. [EMET then injects code into the selected -processes that adds protection against common exploit -techniques](http://support.microsoft.com/kb/2909257), typically causing the -process to terminate if behavior is detected that appears to indicate an attack. - -**Google Chrome 35+** is built for Windows using VS 2013 and is not compatible -with EMET's **ROP chain detection**, and **Google Chrome 53+** built with PGO -optimizations is not compatible with EMET's **EAF+** mitigation. - -# Specific Compatibility issues - -Some applications cannot run with EMET protections because they have internal -behavior that, to EMET, resembles an exploit in progress. This does not mean the -applications are dangerous or are doing anything harmful to the user. In this -case EMET causes the application to unexpectedly terminate even though no actual -attack conditions are present. - -Two specific incompatibilities have been found with EMET: - -## ROP chain detection and prevention (Chrome 35+) - -After [Chromium revision -254340](http://src.chromium.org/viewvc/chrome?view=revision&revision=254340), -Visual Studio 2013 is the only supported build chain for Chromium on Windows. -Unfortunately, we have observed compatibility problems with Microsoft’s Enhanced -Mitigation Experience Toolkit (EMET) and Chromium compiled on Windows using -Visual Studio 2013. - -One specific issue we have encountered with Chromium compiled using VS 2013 -relates to [tail-call optimizations](http://en.wikipedia.org/wiki/Tail_call) in -wrapper functions for Windows APIs. By using jmp to enter the Windows API call -from the wrapper, the Visual Studio compiler avoids an additional call/ret pair, -and the API would return directly into the wrapper function’s caller rather than -the wrapper function itself. However, EMET protects various ‘critical’ Windows -APIs against an exploit technique known as Return-Oriented Programming (ROP), -and one of these protections is incompatible with tail-call optimization. EMET’s -code checks that the return address from the API call is immediately preceded by -a call to that API, since in ROP exploits this will typically not be the case -but in normal function calls it will. The tail-call optimization violates EMET’s -assumption and causes a false positive result for exploit detection. - -## EAF (Export Address Table Filtering) and EAF+ (Chrome 53+ 64-bit) - -The [Chromium -sandbox](/developers/design-documents/sandbox#TOC-The-broker-process) uses an -interception layer to allow the sandboxed process to still access a limited set -of Windows APIs. These interceptions are achieved by the interception manager -whose job it is to patch the windows API calls that should be forwarded via IPC -to the browser process. Chrome 53 added Profile Guided Optimization -([PGO](https://blogs.msdn.microsoft.com/vcblog/2013/04/04/build-faster-and-high-performing-native-applications-using-pgo/)) -to our build process and this seems to have an incompatibility with EMET's EAF+. - -EMET subsequently incorrectly falsely detects our optimizations as an exploit -attempting to patch system DLLs and as a result will not allow any sandboxed -processes to start. The bug tracking this is [643775](https://crbug.com/643775). -A current workaround is to remove chrome_child.dll from the EAF+ DLL allowlist. - -# Fix and Workarounds - -We are in contact with Microsoft to investigate and address these problems. -Microsoft currently is already recommending that the EMET caller mitigation not -be enabled for Chrome. Google recommend that EAF+ protection be disabled for -Chrome, and we are working with Microsoft to update their guidance. - -## Users - -In the meantime, users experiencing this problem with Chrome or Chromium-based -browsers can resolve the issue by either: - - Removing the browser from the list of applications monitored by EMET, and/or - - Disabling the caller mitigation setting and EAF+ specifically for - chrome_child.dll. - -The Chrome security team does not generally recommend the use of EMET with -Chromium because it has negative performance impact and adds no security benefit -in most situations. The most effective anti-exploit techniques that EMET -provides are already built into Chromium or superseded by stronger mitigations. - -<table> -<tr> - -<td>EMET Protection</td> - -<td>Benefit to Chromium</td> - -</tr> -<tr> - -<td>Forcing Data Execution Prevention</td> - -<td>None, Chromium builds with this already enabled.</td> - -</tr> -<tr> - -<td>Forcing Address Space Layout Randomization</td> - -<td>None, Chromium builds with this already enabled.</td> - -</tr> -<tr> - -<td>Structured Exception Handling Overwrite Protection</td> - -<td>None, Chromium enables OS SEHOP on all versions of Windows where supported. EMET can add SEHOP on Windows Vista, however as of Chrome 50 Windows Vista is no longer supported.</td> - -</tr> -<tr> - -<td>Heap Spray Page Reservation</td> - -<td>This can protect Chromium from some exploits, but can also be trivially bypassed by exploit writers who are aware of EMET protections.</td> - -</tr> -<tr> - -<td>Export Address Table (EAF and EAF+) access filtering</td> - -<td>This can protect Chromium from some exploits, but can also be bypassed by exploit writers who are aware of EMET protections.</td> - -</tr> -<tr> - -<td>ROP chain detection and prevention</td> - -<td>This can protect Chromium from some exploits, but can also be bypassed by exploit writers who are aware of EMET protections.</td> - -</tr> -</table>
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/clean-software-alliance/index.md b/chromium/docs/website/site/Home/chromium-security/clean-software-alliance/index.md deleted file mode 100644 index 2501a1c48ce..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/clean-software-alliance/index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: clean-software-alliance -title: Clean Software Alliance (CSA) ---- - -Chrome is participating in a pilot test of the [Clean Software -Alliance](http://www.cs-alliance.org/) (CSA), and provides a feature by which -CSA Installer Members can record information about what has been installed on -the system. These records consist of the following information: - - <vendor_id> - unique identifier of the installation vendor. - - <install_id> - unique installation ID (per vendor). - - <publisher_id> - unique identifier of the publisher (or main product) - being installed. - - <install_time_client> - installation start time as per the user’s - machine. - - <install_time_server> - installation start time as per the server - time. - - <advertisers_id> - a comma-delimited list of unique advertiser IDs - accepted by the user and installed in addition to the main product. - - <hmac_sha256_validation> - hmacSHA256 hash of a string containing all - the entry fields using a private salt provided by every vendor. This field - is used to validate the entry data and to prevent abuse. - -If Chrome detects a [security -incident](https://www.google.ca/chrome/browser/privacy/whitepaper.html#malware), -some of this data may be reported as part of its environmental data collection.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/client-identification-mechanisms/index.md b/chromium/docs/website/site/Home/chromium-security/client-identification-mechanisms/index.md deleted file mode 100644 index 4db961813bc..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/client-identification-mechanisms/index.md +++ /dev/null @@ -1,764 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: client-identification-mechanisms -title: Technical analysis of client identification mechanisms ---- - -*Written by Artur Janc <[aaj@google.com](mailto:aaj@google.com)> and -Michal Zalewski <[lcamtuf@google.com](mailto:lcamtuf@google.com)>* - -In common use, the term “web tracking” refers to the process of calculating or -assigning unique and reasonably stable identifiers to each browser that visits a -website. In most cases, this is done for the purpose of correlating future -visits from the same person or machine with historical data. - -Some uses of such tracking techniques are well established and commonplace. For -example, they are frequently employed to tell real users from malicious bots, to -make it harder for attackers to gain access to compromised accounts, or to store -user preferences on a website. In the same vein, the online advertising industry -has used cookies as the primary client identification technology since the -mid-1990s. Other practices may be less known, may not necessarily map to -existing browser controls, and may be impossible or difficult to detect. Many of -them - in particular, various methods of client fingerprinting - have garnered -concerns from software vendors, standards bodies, and the media. - -To guide us in improving the range of existing browser controls and to highlight -the potential pitfalls when designing new web APIs, we decided to prepare a -technical overview of known tracking and fingerprinting vectors available in the -browser. Note that we describe these vectors, but do not wish this document to -be interpreted as a broad invitation to their use. Website owners should keep in -mind that any single tracking technique may be conceivably seen as -inappropriate, depending on user expectations and other complex factors beyond -the scope of this doc. - -We divided the methods discussed on this page into several categories: -explicitly assigned client-side identifiers, such as HTTP cookies; inherent -client device characteristics that identify a particular machine; and measurable -user behaviors and preferences that may reveal the identity of the person behind -the keyboard (or touchscreen). After reviewing the known tracking and -fingerprinting techniques, we also discuss potential directions for future work -and summarize some of the challenges that browser and other software vendors -would face trying to detect or prevent such behaviors on the Web. - -[TOC] - -## Explicitly assigned client-side identifiers - -The canonical approach to identifying clients across HTTP requests is to store a -unique, long-lived token on the client and to programmatically retrieve it on -subsequent visits. Modern browsers offer a multitude of ways to achieve this -goal, including but not limited to: - - Plain old [HTTP cookies](http://tools.ietf.org/html/rfc6265), - - Cookie-equivalent plugin features - most notably, Flash [Local Shared - Objects](http://en.wikipedia.org/wiki/Local_shared_object). - - HTML5 client storage mechanisms, including - [*localStorage*](https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage), - [*File*](https://developer.mozilla.org/en-US/docs/Web/API/File), and - [*IndexedDB*](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) - APIs, - - Unique markers stored within locally cached resources or in cache metadata - - e.g., [Last-Modified and - ETag](http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), - - Bits encoded in [HTTP Strict Transport - Security](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) pin - lists across several attacker-controlled host names, - - ...and more. - -We believe that the availability of any one of these mechanisms is sufficient to -reliably tag clients and identify them later on; in addition to this, many such -identifiers can be deployed in a manner that conceals the uniqueness of the ID -assigned to a particular client. On the flip side, browsers provide users with -some degree of control over the behavior of at least some of these APIs, and -with several exceptions discussed later on, the identifiers assigned in this -fashion do not propagate to other browser profiles or to private browsing -sessions. - -The remainder of this section provides a more in-depth overview of several -notable examples of client tagging schemes that are within the reach of web -apps. - -### *HTTP cookies* - -[HTTP cookies](http://tools.ietf.org/html/rfc6265) are the most familiar and -best-understood method for persisting data on the client. In essence, any web -server may issue unique identifiers to first-time visitors as a part of a HTTP -response, and have the browser play back the stored values on all future -requests to a particular site. - -All major browsers have for years been equipped with UIs for managing cookies; a -large number of third-party cookie management and blocking software is -available, too. In practice, however, external research has implied that only a -minority of users regularly review or purge browser cookies. The reasons for -this are probably complex, but one of them may be that the removal of cookies -tends to be disruptive: contemporary browsers do not provide any heuristics to -distinguish between the session cookies that are needed to access the sites the -user is logged in, and the rest. - -Some browsers offer user-configurable restrictions on the ability for websites -to set “third-party” cookies (that is, cookies coming from a domain other than -the one currently displayed in the address bar - a behavior most commonly -employed to serve online ads or other embedded content). It should be noted that -the existing implementations of this setting will assign the “first-party” label -to any cookies set by documents intentionally navigated to by the user, as well -as to ones issued by content loaded by the browser as a part of full-page -interstitials, HTTP redirects, or click-triggered pop-ups. - -Compared to most other mechanisms discussed below, overt use of HTTP cookies is -fairly transparent to the user. That said, the mechanism may be used to tag -clients without the use of cookie values that obviously resemble unique IDs. For -example, client identifiers could be encoded as a combination of several -seemingly innocuous and reasonable cookie names, or could be stored in metadata -such as paths, domains, or cookie expiration times. Because of this, we are not -aware of any means for a browser to reliably flag HTTP cookies employed to -identify a specific client in this manner. - -Just as interestingly, the abundance of cookies means that an actor could even -conceivably rely on the values set by others, rather than on any newly-issued -identifiers that could be tracked directly to the party in question. We have -seen this employed for some rich content ads, which are usually hosted in a -single origin shared by all advertisers - or, less safely, are executed directly -in the context of the page that embeds the ad. - -### *Flash LSOs* - -[Local Shared Objects](http://www.adobe.com/security/flashplayer/articles/lso/) -are the canonical way to store client-side data within Adobe Flash. The -mechanism is designed to be a direct counterpart to HTTP cookies, offering a -convenient way to maintain session identifiers and other application state on a -per-origin basis. In contrast to cookies, LSOs can be also used for structured -storage of data other than short snippets of text, making such objects more -difficult to inspect and analyze in a streamlined way. - -In the past, the behavior of LSOs within the Flash plugin had to be configured -separately from any browser privacy settings, by visiting a lesser-known [Flash -Settings -Manager](http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html) -UI hosted on macromedia.com (standalone installs of Flash 10.3 and above -supplanted this with a Control Panel / System Preferences dialog available -locally on the machine). Today, most browsers offer a degree of integration: for -example, clearing cookies and other site data will generally also remove LSOs. -On the flip side, more nuanced controls may not be synchronized: say, the -specific setting for third-party cookies in the browser is not always reflected -by the behavior of LSOs. - -From a purely technical standpoint, the use of Local Shared Objects in a manner -similar to HTTP cookies is within the apparent design parameters for this API - -but the reliance on LSOs to recreate deleted cookies or bypass browser cookie -preferences has been subject to public scrutiny. - -### *Silverlight Isolated Storage - Update: Silverlight and other plugins were removed years ago.* - -Microsoft Silverlight is a widely-deployed applet framework bearing many -similarities to Adobe Flash. The Silverlight equivalent of Flash LSOs is known -as [Isolated -Storage](http://msdn.microsoft.com/en-us/library/bdts8hk0(v=vs.95).aspx). - -The privacy settings in Silverlight are typically not coupled to the underlying -browser. In our testing, values stored in Isolated Storage survive clearing -cache and site data in Chrome, Internet Explorer and Firefox. Perhaps more -surprisingly, Isolated Storage also appears to be shared between all -non-incognito browser windows and browser profiles installed on the same -machine; this may have consequences for users who rely on separate browser -instances to maintain distinct online identities. - -As with LSOs, reliance on Isolated Storage to store session identifiers and -similar state information does not present issues from a purely technical -standpoint. That said, given that the mechanism is not currently managed via -browser controls, its use of for client identification is not commonplace and -thus may be viewed as less transparent than standard cookies. - -### *HTML5 client-side storage mechanisms* - -HTML5 introduces a range of structured data storage mechanisms on the client; -this includes -[localStorage](https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage), -the [*File* API](https://developer.mozilla.org/en-US/docs/Web/API/File), and -[*IndexedDB*](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API). -Although semantically different from each other, all of them are designed to -allow persistent storage of arbitrary blobs of binary data tied to a particular -web origin. In contrast to cookies and LSOs, there are no significant size -restrictions on the data stored with these APIs. - -In modern browsers, HTML5 storage is usually purged alongside other site data, -but the mapping to browser settings isn’t necessarily obvious. For example, -Firefox will retain localStorage data unless the user selects “offline website -data” or “site preferences” in the deletion dialog and specifies the time range -as “everything” (this is not the default). Another idiosyncrasy is the behavior -of Internet Explorer, where the data is retained for the lifetime of a tab for -any sites that are open at the time the operation takes place. - -Beyond that, the mechanisms do not always appear to follow the restrictions on -persistence that apply to HTTP cookies. For example, in our testing, in Firefox, -localStorage can be written and read in cross-domain frames even if third-party -cookies are disabled. - -Due to the similarity of the design goals of these APIs, the authors expect that -the perception and the caveats of using HTML5 storage for storing session -identifiers would be similar to the situation with Flash and Silverlight. - -### *Cached objects* - -For performance reasons, all mainstream web browsers maintain a global cache of -previously retrieved HTTP resources. Although this mechanism is not explicitly -designed as a random-access storage mechanism, it can be easily leveraged as -such. To accomplish this, a cooperating server may return, say, a JavaScript -document with a unique identifier embedded in its body, and set Expires / -max-age= headers to a date set in the distant future. - -Once this unique identifier is stored within a script subresource in the browser -cache, the ID can be read back on any page on the Internet simply by loading the -script from a known URL and monitoring the agreed-upon local variable or setting -up a predefined callback function in JavaScript. The browser will periodically -check for newer copies of the script by issuing a conditional request to the -originating server with a suitable If-Modified-Since header; but if the server -consistently responds to such check with HTTP code 304 (“Not modified”), the old -copy will continue to be reused indefinitely. - -There is no concept of blocking “third-party” cache objects in any browser known -to the authors of this document, and no simple way to prevent cache objects from -being stored without dramatically degrading performance of everyday browsing. -Automated detection of such behaviors is extremely difficult owing to the sheer -volume and complexity of cached JavaScript documents encountered on the modern -Web. - -All browsers expose the option to manually clear the document cache. That said, -because clearing the cache requires specific action on the part of the user, it -is unlikely to be done regularly, if at all. - -Leveraging the browser cache to store session identifiers is very distinct from -using HTTP cookies; the authors are unsure if and how the cookie settings - the -convenient abstraction layer used for most of the other mechanisms discussed to -date - could map to the semantics of browser caches. - -### *Cache metadata: ETag and Last-Modified* - -To make implicit browser-level document caching work properly, servers must have -a way to notify browsers that a newer version of a particular document is -available for retrieval. The HTTP/1.1 standard specifies two methods of document -versioning: one based on the date of the most recent modification, and another -based on an abstract, opaque identifier known as ETag. - -In the ETag scheme, the server initially returns an opaque “version tag” string -in a response header alongside with the actual document. On subsequent -conditional requests to the same URL, the client echoes back the value -associated with the copy it already has, through an If-None-Match header; if the -version specified in this header is still current, the server will respond with -HTTP code 304 (“Not Modified”) and the client is free to reuse the cached -document. Otherwise, a new document with a new ETag will follow. - -Interestingly, the behavior of the ETag header closely mimics that of HTTP -cookies: the server can store an arbitrary, persistent value on the client, only -to read it back later on. This observation, and its potential applications for -browser tracking [date back at least to -2000](http://seclists.org/bugtraq/2000/Mar/331). - -The other versioning scheme, Last-Modified, suffers from the same issue: servers -can store at least 32 bits of data within a well-formed date string, which will -then be echoed back by the client through a request header known as -If-Modified-Since. (In practice, most browsers don't even require the string to -be a well-formed date to begin with.) - -Similarly to tagging users through cache objects, both of these “metadata” -mechanisms are unaffected by the deletion of cookies and related site data; the -tags can be destroyed only by purging the browser cache. - -As with Flash LSOs, use of ETag to allegedly skirt browser cookie settings has -been subject to scrutiny. - -### *HTML5 AppCache* - -[Application -Caches](http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#appcache) -allow website authors to specify that portions of their websites should be -stored on the disk and made available even if the user is offline. The mechanism -is controlled by [cache -manifests](http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#manifests) -that outline the rules for storing and retrieving cache items within the app. - -Similarly to implicit browser caching, AppCaches make it possible to store -unique, user-dependent data - be it inside the cache manifest itself, or inside -the resources it requests. The resources are retained indefinitely and not -subject to the browser’s usual cache eviction policies. - -AppCache appears to occupy a netherworld between HTML5 storage mechanisms and -the implicit browser cache. In some browsers, it is purged along with cookies -and stored website data; in others, it is discarded only if the user opts to -delete the browsing history and all cached documents. - -Note: AppCache is likely to be succeeded with [Service -Workers](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html); -the privacy properties of both mechanisms are likely to be comparable. - -### *Flash resource cache* - -Flash maintains its own internal store of resource files, which can be probed -using a variety of techniques. In particular, the internal repository includes -an asset cache, relied upon to store [Runtime Shared -Libraries](http://help.adobe.com/en_US/Flex/4.0/UsingSDK/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html) -signed by Adobe to improve applet load times. There is also [Adobe Flash -Access](http://www.adobe.com/support/documentation/en/flashaccess/), a mechanism -to store automatically acquired licenses for DRM-protected content. - -As of this writing, these document caches do not appear to be coupled to any -browser privacy settings and can only be deleted by making several independent -configuration changes in the [Flash Settings -Manager](http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html) -UI on macromedia.com. We believe there is no global option to delete all cached -resources or prevent them from being stored in the future. - -Browsers other than Chrome appear to share Flash asset data across all -installations and in private browsing modes, which may have consequences for -users who rely on separate browser instances to maintain distinct online -identities. - -### *SDCH dictionaries - Removed from Chrome 59+* - -[SDCH](http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf) -is a Google-developed compression algorithm that relies on the use of -server-supplied, cacheable dictionaries to achieve compression rates -considerably higher than what’s possible with methods such as gzip or deflate -for several common classes of documents. - -The site-specific dictionary caching behavior at the core of SDCH inevitably -offers an opportunity for storing unique identifiers on the client: both the -dictionary IDs (echoed back by the client using the Avail-Dictionary header), -and the contents of the dictionaries themselves, can be used for this purpose, -in a manner very similar to the regular browser cache. - -In Chrome, the data does not persist across browser restarts; it was, however, -shared between profiles and incognito modes and was not deleted with other site -data when such an operation is requested by the user. Google addressed this in -bug [327783](https://code.google.com/p/chromium/issues/detail?id=327783). - -### *Other script-accessible storage mechanisms* - -Several other more limited techniques make it possible for JavaScript or other -active content running in the browser to maintain and query client state, -sometimes in a fashion that can survive attempts to delete all browsing and site -data. - -For example, it is possible to use window.name or sessionStorage to store -persistent identifiers for a given window: if a user deletes all client state -but does not close a tab that at some point in the past displayed a site -determined to track the browser, re-navigation to any participating domain will -allow the window-bound token to be retrieved and the new session to be -associated with the previously collected data. - -More obviously, the same is true for active JavaScript: any currently open -JavaScript context is allowed to retain state even if the user attempts to -delete local site data; this can be done not only by the top-level sites open in -the currently-viewed tabs, but also by “hidden” contexts such as HTML frames, -web workers, and pop-unders. This can happen by accident: for example, a running -ad loaded in an <iframe> may remain completely oblivious to the fact that -the user attempted to clear all browsing history, and keep using a session ID -stored in a local variable in JavaScript. (In fact, in addition to JavaScript, -Internet Explorer will also retain session cookies for the currently-displayed -origins.) - -Another interesting and often-overlooked persistence mechanism is the caching of -[RFC 2617](http://tools.ietf.org/html/rfc2617) HTTP authentication credentials: -once explicitly passed in an URL, the cached values may be sent on subsequent -requests even after all the site data is deleted in the browser UI. - -In addition to the cross-browser approaches discussed earlier in this document, -there are also several proprietary APIs that can be leveraged to store unique -identifiers on the client system. An interesting example of this are the -proprietary [persistence -behaviors](http://msdn.microsoft.com/en-us/library/ms533007(v=vs.85).aspx) in -some versions of Internet Explorer, including the [*userData* -API](http://msdn.microsoft.com/en-us/library/ms531424(VS.85).aspx). - -Last but not least, a variety of other, less common plugins and plugin-mediated -interfaces likely expose analogous methods for storing data on the client, but -have not been studied in detail as a part of this write-up; an example of this -may be the -*[PersistenceService](http://docs.oracle.com/javase/7/docs/jre/api/javaws/jnlp/javax/jnlp/PersistenceService.html) -API* in Java, or the DRM license management mechanisms within Silverlight. - -### *Lower-level protocol identifiers* - -On top of the fingerprinting mechanisms associated with HTTP caching and with -the purpose-built APIs available to JavaScript programs and plugin-executed -code, modern browsers provide several network-level features that offer an -opportunity to store or retrieve unique identifiers: - - [Origin Bound - Certificates](http://www.browserauth.net/origin-bound-certificates) (aka - *ChannelID*) **were** persistent self-signed certificates identifying the - client to an HTTPS server, envisioned as the future of session management on - the web. A separate certificate is generated for every newly encountered - domain and reused for all connections initiated later on. - By design, OBCs function as unique and stable client fingerprints, - essentially replicating the operation of authentication cookies; they are - treated as “site and plug-in data” in Chrome, and can be removed along with - cookies. - Uncharacteristically, sites can leverage OBC for user tracking without - performing any actions that would be visible to the client: the ID can be - derived simply by taking note of the cryptographic hash of the certificate - automatically supplied by the client as a part of a legitimate SSL - handshake. - ChannelID is currently suppressed in Chrome in “third-party” scenarios - (e.g., for different-domain frames). **NOTE**: **this feature and its - successor, TLS Token Binding, were removed years ago.** - - The set of supported ciphersuites can be used to fingerprint [a TLS/SSL - handshake](http://whatever-will-be-que-sera-sera.tumblr.com). Note that - clients have been actively deprecating various ciphersuites in recent years, - making this attack even more powerful. - - In a similar fashion, two separate mechanisms within TLS - [session - identifiers](http://tools.ietf.org/html/rfc5246) and [session - tickets](http://tools.ietf.org/html/rfc5077) - allow clients to resume - previously terminated HTTPS connections without completing a full handshake; - this is accomplished by reusing previously cached data. These session - resumption protocols provide a way for servers to identify subsequent - requests originating from the same client for a short period of time. - - [HTTP Strict Transport Security](http://tools.ietf.org/html/rfc6797) is a - security mechanism that allows servers to demand that all future connections - to a particular host name need to happen exclusively over HTTPS, even if the - original URL nominally begins with “http://”. - It follows that a fingerprinting server could set long-lived HSTS headers - for a distinctive set of attacker-controlled host names for each newly - encountered browser; this information could be then retrieved by loading - faux (but possibly legitimately-looking) subresources from all the - designated host names and seeing which of the connections are automatically - switched to HTTPS. - In an attempt to balance security and privacy, any HSTS pins set during - normal browsing \[were\*\] carried over to the incognito mode in Chrome; - there is no propagation in the opposite direction, however. \***Update:** - Behavior was [changed in Chrome 64](https://crbug.com/774643), such that - Chrome won't use on-disk HSTS information for incognito requests. It is - worth noting that leveraging HSTS for tracking purposes requires - establishing log(n) connections to uniquely identify n users, which makes it - relatively unattractive, except for targeted uses; that said, creating a - smaller number of buckets may be a valuable tool for refining other - imprecise fingerprinting signals across a very large user base. - - Last but not least, virtually all modern browsers maintain internal DNS - caches to speed up name resolution (and, in some implementations, to - mitigate the risk of [DNS rebinding - attacks](http://crypto.stanford.edu/dns/dns-rebinding.pdf)). - Such caches can be easily leveraged to store small amounts of information - for a configurable amount of time; for example, with 16 available IP - addresses to choose from, around 8-9 cached host names would be sufficient - to uniquely identify every computer on the Internet. On the flip side, the - value of this approach is limited by the modest size of browser DNS caches - and the potential conflicts with resolver caching on ISP level. - -## Machine-specific characteristics - -With the notable exception of Origin-Bound Certificates, the techniques -described in section 1 of the document rely on a third-party website explicitly -placing a new unique identifier on the client system. - -Another, less obvious approach to web tracking relies on querying or indirectly -measuring the inherent characteristics of the client system. Individually, each -such signal will reveal just several bits of information - but when combined -together, it seems probable that they may uniquely identify almost any computer -on the Internet. In addition to being harder to detect or stop, such techniques -could be used to **cross-correlate user activity across various browser profiles -or private browsing sessions.** Furthermore, because the techniques are -conceptually very distant from HTTP cookies, the authors find it difficult to -decide how, if at all, the existing cookie-centric privacy controls in the -browser should be used to govern such practices. - -EFF [Panopticlick](https://panopticlick.eff.org/browser-uniqueness.pdf) is one -of the most prominent experiments demonstrating the principle of combining -low-value signals into a high-accuracy fingerprint; there is also some evidence -of [sophisticated passive -fingerpri](http://www.ieee-security.org/TC/SP2013/papers/4977a541.pdf)[nts being -used](http://www.ieee-security.org/TC/SP2013/papers/4977a541.pdf) by commercial -tracking services. - -### *Browser-level fingerprints* - -The most straightforward approach to fingerprinting is to construct identifiers -by actively and explicitly combining a range of individually non-identifying -signals available within the browser environment: - - User-Agent string, identifying the browser version, OS version, and some of - the installed browser add-ons. - (In cases where User-Agent information is not available or imprecise, - browser versions can be usually inferred very accurately by examining the - structure of other headers and by testing for the availability and semantics - of the features introduced or modified between releases of a particular - browser.) - - Clock skew and drift: unless synchronized with an external time source, most - systems exhibit clock drift that, over time, produces a fairly unique time - offset for every machine. Such offsets can be measured with microsecond - precision using JavaScript. In fact, even in the case of NTP-synchronized - clocks, ppm-level skews may be possible to [measure - remotely](http://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf). - - Fairly fine-grained information about the underlying CPU and GPU, either as - exposed directly (GL_RENDERER) or as measured by executing [Javascript - benchmarks](http://w2spconf.com/2011/papers/jspriv.pdf) and testing for - driver- or GPU-specific [differences in WebGL - rendering](http://cseweb.ucsd.edu/~hovav/dist/canvas.pdf) or the application - of ICC color profiles to *<canvas>* data. - - Screen and browser window resolutions, including parameters of secondary - displays for multi-monitor users. - - The window-manager- and addon-specific “thickness” of the browser UI in - various settings (e.g., window.outerHeight - window.innerHeight). - - The list and ordering of installed system fonts - enumerated directly or - inferred with the help of an API such as getComputedStyle. - - The list of all installed plugins, ActiveX controls, and Browser Helper - Objects, including their versions - queried or brute-forced through - navigator.plugins\[\]. (Some add-ons also announce their existence in HTTP - headers.) - - Information about installed browser extensions and other software. While the - set cannot be directly enumerated, many extensions include [web-accessible - resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) - that aid in fingerprinting. In addition to this, add-ons such as popular ad - blockers make detectable modifications to viewed pages, revealing - information about the extension or its configuration. Using browser “sync” - features may result in these characteristics being identical for a given - user across multiple devices. A similar but less portable approach specific - to Internet Explorer allows websites to [enumerate locally - installed](http://www.alienvault.com/open-threat-exchange/blog/attackers-abusing-internet-explorer-to-enumerate-software-and-detect-securi) - software by attempting to load DLL resources via the *res://* - pseudo-protocol. - - Random seeds reconstructed from the output of non-cryptosafe PRNGs (e.g. - Math.random(), multipart form boundaries, etc). In some browsers, the PRNG - is initialized only at startup, or reinitialized using values that are - system-specific (e.g., based on system time or PID). - -According to the EFF, their Panopticlick experiment - which combines only a -relatively small subset of the actively-probed signals discussed above - is able -to uniquely identify [95% of desktop -users](http://hostmaster.freehaven.net/anonbib/cache/pets2010:eckersley2010unique.pdf) -based on system-level metrics alone. Current commercial fingerprinters are -reported to be [considerably more -sophisticated](http://www.ieee-security.org/TC/SP2013/papers/4977a541.pdf) and -their developers might be able to claim significantly higher success rates. - -Of course, the value of some of the signals discussed here will be diminished on -mobile devices, where both the hardware and the software configuration tends to -be more homogenous; for example, measuring window dimensions or the list of -installed plugins offers very little data on most Android devices. Nevertheless, -we feel that the remaining signals - such as clock skew and drift and the -network-level and user-specific signals described later on - are together likely -more than sufficient to uniquely identify virtually all users. - -When discussing potential mitigations, it is worth noting that restrictions such -as disallowing the enumeration of navigator.plugins\[\] generally do not prevent -fingerprinting; the set of all notable plugins and fonts ever created and -distributed to users is relatively small and a malicious script can conceivably -test for every possible value in very little time. - -### *Network configuration fingerprints* - -An interesting set of additional device characteristics is associated with the -architecture of the local network and the configuration of lower-level network -protocols; such signals are disclosed independently of the design of the web -browser itself. These traits covered here are generally shared between all -browsers on a given client and cannot be easily altered by common -privacy-enhancing tools or practices; they include: - - The external client IP address. For IPv6 addresses, this vector is even more - interesting: in some settings, the last octets may be derived from the - device's MAC address and preserved across networks. - - A broad range of TCP/IP and TLS stack fingerprints, obtained with passive - tools such as [*p0f*](http://lcamtuf.coredump.cx/p0f3/). The information - disclosed on this level is often surprisingly specific: for example, TCP/IP - traffic will often reveal high-resolution system uptime data through TCP - timestamps. - - Ephemeral source port numbers for outgoing TCP/IP connections, generally - selected sequentially by most operating systems. - - The local network IP address for users behind network address translation or - HTTP proxies ([via - WebRTC](http://www.thousandparsec.net/~tim/webrtc-myip.html)). Combined with - the external client IP, internal NAT IP uniquely identifies most users, and - is generally stable for desktop browsers (due to the tendency for DHCP - clients and servers to cache leases). - - Information about proxies used by the client, as detected from the presence - of extra HTTP headers (Via, X-Forwarded-For). This can be combined with the - client’s actual IP address revealed when making proxy-bypassing connections - using one of several available methods. - - With active probing, the [list of open ports on the local - host](http://www.slideshare.net/amiable_indian/javascript-malware-spi-dynamics) - indicating other installed software and firewall settings on the system. - Unruly actors may also be tempted to [probe the systems and services in the - visitor’s local network](http://www.andlabs.org/tools/jsrecon/jsrecon.html); - doing so directly within the browser will circumvent any firewalls that - normally filter out unwanted incoming traffic. - -## User-dependent behaviors and preferences - -In addition to trying to uniquely identify the device used to browse the web, -some parties may opt to examine characteristics that aren’t necessarily tied to -the machine, but that are closely associated with specific users, their local -preferences, and the online behaviors they exhibit. Similarly to the methods -described in section 2, such patterns would persist across different browser -sessions, profiles, and across the boundaries of private browsing modes. - -The following data is typically open to examination: - - Preferred language, default character encoding, and local time zone (sent in - HTTP headers and visible to JavaScript). - - Data in the client cache and history. It is possible to detect items in the - client’s cache by performing simple timing attacks; for any long-lived cache - items associated with popular destinations on the Internet, a fingerprinter - could detect their presence simply by measuring how quickly they load (and - by aborting the navigation if the latency is greater than expected for local - cache). - (It is also possible to directly extract URLs stored in the browsing - history, although such an attack requires [some user - interaction](http://lcamtuf.coredump.cx/yahh/) in modern browsers.) - - Mouse gesture, keystroke timing and velocity patterns, and [accelerometer - readings](http://www.theregister.co.uk/2013/01/31/smartphone_accelerometer_data_leak/) - (ondeviceorientation) that are unique to a particular user or to particular - surroundings. There is a - [considerable](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.310.4320&rep=rep1&type=pdf) - [body](http://www.csis.pace.edu/~ctappert/it691-13spring/projects/mouse-pusara.pdf) - [of](http://www.cs.wm.edu/~hnw/paper/ccs11.pdf) - [scientific](http://www.computer.org/csdl/mags/it/2013/04/mit2013040012-abs.html) - [research](http://www.octaviogutierrez.net/docs/Gutierrez-ConferencePaper-SAM.pdf) - suggesting that even relatively trivial interactions are deeply - user-specific and highly identifying. - - Any changes to default website fonts and font sizes, website zoom level, and - the use of any accessibility features such as text color, size, or CSS - overrides (all indirectly measurable with JavaScript). - - The state of client features that can be customized or disabled by the user, - with special emphasis on mechanisms such as DNT, third-party cookie - blocking, changes to DNS prefetching, pop-up blocking, Flash security and - content storage, and so on. (In fact, users who extensively tweak their - settings from the defaults may be actually making their browsers - considerably easier to uniquely fingerprint.) - -On top of this, user fingerprinting can be accomplished by interacting with -third-party services through the user’s browser, using the ambient credentials -(HTTP cookies) maintained by the browser: - - Users logged into websites that offer collaboration features can be - de-anonymized by covertly instructing their browser to navigate to a set of - distinctively ACLed resources and then examining which of these navigation - attempts result in a new collaborator showing up in the UI. - - Request timing, onerror and onload handlers, and similar measurement - techniques can be used to detect which third-party resources return HTTP 403 - error codes in the user’s browser, thus constructing an accurate picture of - which sites the user is logged in; in some cases, finer-grained insights - into user settings or preferences on the site can be obtained, too. - (A similar but possibly more versatile login-state attack can be also - mounted with the help of Content Security Policy, a new security mechanism - introduced in modern browsers.) - - Any of the explicit web application APIs that allow identity attestation may - be leveraged to confirm the identity of the current user (typically based on - a starting set of probable guesses). - -## Fingerprinting prevention and detection challenges - -In a world with no possibility of fingerprinting, web browsers would be -indistinguishable from each other, with the exception of a small number of -robustly compartmentalized and easily managed identifiers used to maintain login -state and implement other essential features in response to user’s intent. - -In practice, the Web is very different: browser tracking and fingerprinting are -attainable in a large number of ways. A number of the unintentional tracking -vectors are a product of implementation mistakes or oversights that could be -conceivably corrected today; many others are virtually impossible to fully -rectify without completely changing the way that browsers, web applications, and -computer networks are designed and operated. In fact, some of these design -decisions might have played an unlikely role in the success of the Web. - -In lieu of eliminating the possibility of web tracking, some have raised hope of -detecting use of fingerprinting in the online ecosystem and bringing it to -public attention via technical means through browser- or server-side -instrumentation. Nevertheless, even this simple concept runs into a number of -obstacles: - - Some fingerprinting techniques simply leave no remotely measurable - footprint, thus precluding any attempts to detect them in an automated - fashion. - - Most other fingerprinting and tagging vectors are used in fairly evident - ways, but could be easily redesigned so that they are practically - indistinguishable from unrelated types of behavior. This would frustrate any - programmatic detection strategies in the long haul, particularly if they are - attempted on the client (where the party seeking to avoid detection can - reverse-engineer the checks and iterate until the behavior is no longer - flagged as suspicious). - -* The distinction between behaviors that may be acceptable to the user - and ones that might not is hidden from view: for example, a cookie - set for abuse detection looks the same as a cookie set to track - online browsing habits. Without a way to distinguish between the two - and properly classify the observed behaviors, tracking detection - mechanisms may provide little real value to the user. - -## Potential directions for future work - -There may be no simple, universal, technical solutions to the problem of -tracking on the Web by parties who are intent on doing so with no regard for -user controls. That said, the authors of this page see some theoretical room for -improvement when it comes to building simpler and more intuitive privacy -controls to provide a better framework for the bulk of interactions with -responsible sites and parties on the Internet: - - The current browser privacy controls evolved almost exclusively around the - notion of HTTP cookies and several other very specific concepts that do not - necessarily map cleanly to many of the tracking and fingerprinting methods - discussed in this document. In light of this, to better meet user - expectations, it may be beneficial for in-browser privacy settings to focus - on clearly explaining practical privacy outcomes, rather than continuing to - build on top of narrowly-defined concepts such as "third-party cookies". - - We worry that in some cases, interacting with browser privacy controls can - degrade one’s browsing experience, discouraging the user from ever touching - them. A canonical example of this is trying to delete cookies: reviewing - them manually is generally impractical, while deleting all cookies will kick - the user out of any sites he or she is logged into and frequents every day. - Although fraught with some implementation challenges, it may be desirable to - build better heuristics that distinguish and preserve site data specifically - for the destinations that users frequently log into or meaningfully interact - with. - - Even for extremely privacy-conscious users who are willing to put up with - the inconvenience of deleting one’s cookies and purging other session data, - resetting online fingerprints can be difficult and fail in unexpected ways. - An example of this is discussed in section 1: if there are ads loaded on any - of the currently open tabs, clearing all local data may not actually result - in a clean slate. Investing in developing technologies that provide more - robust and intuitive ways to maintain, manage, or compartmentalize one's - online footprints may be a noble goal. - - Today, some privacy-conscious users may resort to tweaking multiple settings - and installing a broad range of extensions that together have the - paradoxical effect of facilitating fingerprinting - simply by making their - browsers considerably more distinctive, no matter where they go. There is a - compelling case for improving the clarity and effect of a handful of - well-defined privacy settings as to limit the probability of such outcomes. - -We present these ideas for discussion within the community; at the same time, we -recognize that although they may sound simple when expressed in a single -paragraph, their technical underpinnings are elusive and may prove difficult or -impossible to fully flesh out and implement in any browser.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/corb-for-developers/index.md b/chromium/docs/website/site/Home/chromium-security/corb-for-developers/index.md deleted file mode 100644 index 233766fb522..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/corb-for-developers/index.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: corb-for-developers -title: Cross-Origin Read Blocking for Web Developers ---- - -**Cross-Origin Read Blocking (CORB)** is a new web platform security feature -that helps mitigate the threat of side-channel attacks (including Spectre). It -is designed to prevent the browser from delivering certain cross-origin network -responses to a web page, when they might contain sensitive information and are -not needed for existing web features. For example, it will block a cross-origin -text/html response requested from a <script> or <img> tag, replacing -it with an empty response instead. This is an important part of the protections -included with [Site Isolation](/Home/chromium-security/site-isolation). - -This document aims to help web developers know what actions they should take in -response to CORB. For more information about CORB in general, please see the -[CORB -explainer](https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/cross_origin_read_blocking_explainer.md), -the [specification](https://fetch.spec.whatwg.org/#corb), the ["Site Isolation -for web developers" -article](https://developers.google.com/web/updates/2018/07/site-isolation), or -the following [talk](https://youtu.be/dBuykrdhK-A) from Google I/O 2018. (The -CORB discussion starts at [around 23:20 -mark](https://youtu.be/dBuykrdhK-A?t=1401).) - -#### Lessons from Spectre and Meltdown, and how the whole web is getting safer - -## How can I ensure CORB protects resources on my website? - -To make sure that sensitive resources on your website (e.g. pages or JSON files -with user-specific information, or pages with CSRF tokens) will not leak to -other web origins, please take the following steps to distinguish them from -resources that are allowed to be embedded by any site (e.g., images, JavaScript -libraries). - -### For HTML, JSON, and XML resources: - -Make sure these resources are served with a correct "Content-Type" response -header from the list below, as well as a "X-Content-Type-Options: nosniff" -response header. These headers ensure Chrome can identify the resources as -needing protection, without depending on the contents of the resources. - -* [HTML MIME type](https://mimesniff.spec.whatwg.org/#html-mime-type) - - "text/html" -* [XML MIME type](https://mimesniff.spec.whatwg.org/#xml-mime-type) - - "text/xml", "application/xml", or any MIME type whose subtype ends - in "+xml" -* [JSON MIME type](https://mimesniff.spec.whatwg.org/#json-mime-type) - - "text/json", "application/json", or any MIME type whose subtype - ends in "+json" - -Note that we recommend not supporting **multipart** [range -requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests) for -sensitive resources, because this changes the MIME type to multipart/byteranges -and makes it harder for Chrome to protect. Typical range requests are not a -problem and are treated similarly to the nosniff case. - -In addition to the recommended cases above, Chrome will also do its best to -protect responses labeled with any of the MIME types above and without a -"nosniff" header, but this has limitations. Many JavaScript files on the web are -unfortunately labeled using some of these MIME types, and if Chrome blocked -access to them, existing websites would break. Thus, when the "nosniff" header -is not present, Chrome first looks at the start of the file to try to confirm -whether it is HTML, XML, or JSON, before deciding whether to protect it. If it -cannot confirm this, it allows the response to be received by the cross-site -page's process. This is a best-effort approach which adds some limited -protection while preserving compatibility with existing sites. We recommend that -web developers include the "nosniff" header to protect their resources, to avoid -relying on this "confirmation sniffing" approach. - -### For other resource types (e.g., PDF, ZIP, PNG): - -Make sure these resources are served only in response to requests that include -an unguessable CSRF token (which should be distributed via resources protected -via the HTML, JSON, or XML steps above). - -## What should I do about CORB warnings reported by Chrome? - -When CORB blocks a HTTP response, it emits the following warning message to the -DevTools console in Chrome: - -> Cross-Origin Read Blocking (CORB) blocked cross-origin response -> https://www.example.com/example.html with MIME type text/html. See -> <https://www.chromestatus.com/feature/5629709824032768> for more details. - -> (In Chrome 66 and earlier, this message was slightly different: Blocked -> current origin from receiving cross-site document at -> https://www.example.com/example.html with MIME type text/html.) - -In most cases, the blocked response should not affect the web page's behavior -and the CORB error message can be safely ignored. For example, the warning may -occur in cases when the body of the blocked response was empty already, or when -the response was going to be delivered to a context that can't handle it (e.g., -a HTML document such as a 404 error page being delivered to an <img> tag). -***Note:** Chrome will stop showing warning messages for empty or error -responses in Chrome 69, since these are false positives that do not affect site -behavior. If you see CORB warnings in Chrome 67 or 68, please test the site in -Chrome 69 to see if any warnings remain.* - -In rare cases, the CORB warning message may indicate a problem on a website, -which may disrupt its behavior when certain responses are blocked. For example, -a response served with a "X-Content-Type-Options: nosniff" response header and -an incorrect "Content-Type" response header may be blocked. This could, for -example, block an actual image which is mislabeled as "Content-Type: text/html" -and "nosniff." If this occurs and interferes with a page's behavior, we -recommend informing the website and requesting that they correct the -"Content-Type" header for the response. - -If you suspect Chrome is incorrectly blocking a response and that this is -disrupting the behavior of a website, [please file a Chromium -bug](https://goo.gl/XBoKtY) describing the incorrectly blocked response (both -the headers and body) and/or the URL serving it. You can confirm if a problem is -due to CORB by temporarily disabling it, by starting Chrome with the following -command line flag: - ---disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/core-principles/index.md b/chromium/docs/website/site/Home/chromium-security/core-principles/index.md deleted file mode 100644 index 2bc18f25ad2..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/core-principles/index.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: core-principles -title: Core Principles ---- - -### Help users safely navigate the web. - -Ensuring user safety means carefully balancing usability, capability and -security. If we’re doing it right, these aspects should all work hand-in-hand. -In most cases, we want security to be nearly invisible to the user. We update -transparently and try to provide safe defaults without asking users to make -security decisions. When [security -indicators](http://support.google.com/chrome/bin/answer.py?hl=en&answer=95617) -are surfaced, we aim to clearly explain the situation and highlight the most -important information, such as the hostname and SSL state in the address bar. - -### Design for defense in depth (and more depth). - -Our goal in designing Chrome’s security architecture was to layer defenses, and -avoid single points of failure. Chrome’s sandbox architecture represents one of -the most effective parts of this strategy, but it’s far from the only piece. We -also employ the best available anti-exploit technologies—including -[ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization), -[DEP](http://en.wikipedia.org/wiki/Data_Execution_Prevention), [JIT -hardening](http://www.matasano.com/research/Attacking_Clientside_JIT_Compilers_Paper.pdf#page=24), -and [SafeSEH](http://msdn.microsoft.com/en-us/library/9a89h429.aspx)—along with -custom technologies like [Safe -Browsing](http://code.google.com/apis/safebrowsing/), [out-of-date plugin -blocking](http://support.google.com/chrome/bin/answer.py?hl=en&answer=1181003), -silent auto-update, and [verified -boot](/chromium-os/chromiumos-design-docs/verified-boot) on Chrome OS. And we -continue to work towards advancing the state of the art with research into areas -like per-origin sandboxing and control flow integrity. - -### Security is a team responsibility. - -There’s a common misconception that security can be handled as a feature or -add-on component. The fact is that security of any complex piece of software is -a cross-cutting concern, determined by millions of seemingly innocuous decisions -being made by developers every day. That’s why it’s essential for every team -member to be aware of secure development practices, and work with their security -team throughout the lifecycle of the project. This general awareness helps -supplement our normal security review process of auditing, regression testing, -and fuzzing. - -### Speed matters. - -User safety depends on quickly turning around security issues, regardless of -whether a vulnerability is discovered internally or reported by a third party. -We are committed to promptly addressing all security issues, and delivering -fixes to our users via our fast automatic update process. This approach has -allowed us to maintain an [industry-leading response -time](http://www.accuvant.com/sites/default/files/images/webbrowserresearch_v1_0.pdf#page=24) -to security vulnerabilities—even when dealing with such a complex and -politically charged issue as an irresponsible root Certificate Authority. - -### Be transparent. - -We do not downplay security impact or bury vulnerabilities with silent fixes, -because doing so serves users poorly. Instead, we provide users and -administrators with the information they need to accurately assess risk. We -publicly document our [security handling -proces](/Home/chromium-security/security-bug-lifecycle)[s](/Home/chromium-security/security-bug-lifecycle), -and we disclose all vulnerabilities fixed in Chrome and its dependencies—whether -discovered internally or externally. Whenever possible, we list all fixed -security issues in our [release -notes](http://googlechromereleases.blogspot.com/), and make the underlying -details public as soon as other affected projects have an adequate amount of -time to respond. When we do not control the disclosure timeline for a security -issue and cannot list it at the time of release, we make the details of the -issue public as soon as disclosure occurs. - -### Engage the community. - -No software is perfect, and security bugs slip through even the best development -and review processes. That’s why we’re grateful for the work of the independent -security research community in helping us find and fix vulnerabilities. In -response, we do our best to [acknowledge](/Home/chromium-security/hall-of-fame) -and [reward](/Home/chromium-security/vulnerability-rewards-program) their -contributions by ensuring proper attribution, paying out bounties, and -sponsoring security conferences. We leverage the community to even greater -extent where we can, by hiring members directly onto our team and contracting -with industry leading, independent security consultancies. - -### Make the web safer for everyone. - -Security is not a zero-sum game. One browser does not succeed in security at the -cost of others, and we’re all better off when the best security technologies and -techniques are employed by everyone. To that end, we work closely with standards -bodies and other browser makers to raise the bar by collaborating on various -standards, including [public key -pinning](http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01), [Content -Security Policies](http://www.w3.org/TR/CSP/), and [SPDY](/spdy). We also open -source or otherwise make our security technologies widely available (e.g. -[Native Client](/nativeclient) / Pepper, [Open Type -Sanitizer](https://code.google.com/p/ots/), [application -sandboxing](/developers/design-documents/sandbox), and [Safe -Browsing](https://code.google.com/apis/safebrowsing/)).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/crlsets/CRLSetComponents.png.sha1 b/chromium/docs/website/site/Home/chromium-security/crlsets/CRLSetComponents.png.sha1 deleted file mode 100644 index 4fad02b7a84..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/crlsets/CRLSetComponents.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -499428fe4e368c0e859e10c37be5c60d102b4715
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/crlsets/index.md b/chromium/docs/website/site/Home/chromium-security/crlsets/index.md deleted file mode 100644 index 156a9fbdb64..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/crlsets/index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: crlsets -title: CRLSets ---- - -(This page is intended for Certificate Authorities who wish to know about -Chromium's certificate revocation behaviour.) - -CRLSets ([background](https://www.imperialviolet.org/2012/02/05/crlsets.html)) -are primarily a means by which Chrome can quickly block certificates in -emergency situations. As a secondary function they can also contain some number -of non-emergency revocations. These latter revocations are obtained by crawling -CRLs published by CAs. - -Online (i.e. OCSP and CRL) checks are not, generally, performed by Chrome. They -can be enabled by policy and, in some cases, the underlying system certificate -library always performs these checks no matter what Chromium does. - -The Chromium source code that implements CRLSets is, of course, -[public](https://chromium.googlesource.com/chromium/src/+/HEAD/net/cert/crl_set.cc). -But the process by which they are generated is not. - -We maintain an internal list of crawled CRLs which are intended to cover -intermediate revocations. The CRLs from that set go to make up the published -CRLSet. CRLs on the list are fetched infrequently (at most once every few hours) -and verified against the correct signing certificate for that CRL. - -The current CRLSet can be fetched and dumped out using the code at -<https://github.com/agl/crlset-tools>. - -The version of CRLSet being used by Chrome can be inspected by navigating to -chrome://components: - -[<img alt="image" -src="/Home/chromium-security/crlsets/CRLSetComponents.png">](/Home/chromium-security/crlsets/CRLSetComponents.png)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes/index.md b/chromium/docs/website/site/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes/index.md deleted file mode 100644 index 52a85f1686b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes/index.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: deprecating-permissions-in-cross-origin-iframes -title: Deprecating Permissions in Cross-Origin Iframes ---- - -**Contents** - -[TOC] - -## Proposal - -It’s proposed that by default the following permissions cannot be requested or -used by content contained in cross-origin iframes: - -* Geolocation (getCurrentPosition and watchPosition) -* Midi (requestMIDIAccess) -* Encrypted media extensions (requestMediaKeySystemAccess) -* Microphone, Camera (getUserMedia) - -In order for a cross-origin frame to use these features, the embedding page must -specify a Permission Policy enables the feature for the frame. For example, to -enable geolocation in an iframe, the embedder could specify the iframe tag as: - -```html -<iframe src="<https://example.com>" allow="geolocation"></iframe> -``` - -You can find the original blink [intent to deprecate thread -here](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/mG6vL09JMOQ). - -**This is a living document** — as we learn more, we'll probably need to change -this page. - -## Motivation - -Untrusted third-party content, such as ads, are frequently embedded in iframes -on websites. Currently, permissions like geolocation, midi, etc. can be directly -requested and used by this content. - -UI for displaying permission prompts that are triggered by iframes can be very -confusing. Often permission prompts appear to be coming from the top-level -origin. As a result, users can be misled into granting permission to third-party -content that they did not intend to. At the very least, third-party content has -the ability to annoy users by displaying prompts even if they are undesired by -the embedding page. - -Furthermore, even if a user has previously granted persistent permission to an -origin, they are unlikely to be aware when that origin is loaded in an iframe on -a website on the drive-by-web. This may result in unexpected and unwanted access -a user’s camera, location, etc. - -The goal of this proposal is to protect users by disabling permissions by -default in iframes. Embedding websites would have the ability to re-enable -features for trusted content. This means that in order for a site to request -permission, the embedding website must express trust in the origin, in addition -to the user’s trust expressed through a permission grant. - -It should also be noted that several new features being implemented (e.g. -Payment request, WebVR) are adopting the model of disabling sensitive features -in cross-origin iframes from the beginning. This change will bring older -features into line with the direction the web is heading. - -## To continue to use permissions from iframes on your website... - -This deprecation is expected to ship in Chrome M64 (around January 2018). At -that time, if a cross-origin iframe attempts to use permission without the -feature being explicitly allowed, a console warning will be logged and the -feature will fail in a similar way as it would if a user had denied a permission -prompt. - -If you are a developer of a website which uses cross-origin iframes and you want -those iframes to continue to be able to request/use one of the above features, -the page that embeds the iframe will need to be changed. The simplest way to do -that is to modify the <iframe> tag to include an allow attribute which -specifies the name of the permission. For example, to enable geolocation and -mic/camera for an iframe, the following would be specified: - -```html -<iframe src="<https://example.com>" allow="geolocation; microphone; -camera"></iframe> -``` - -Note that the above will grant geolocation, microphone and camera access to the -origin specified in the "src" attribute, i.e. in this case it would be -https://example.com. In some cases, other origins will be loaded in the iframe -that you may also wish to grant access to. In those cases you can explicitly -specify the origins to grant access to: - -```html -<iframe src="<https://example.com>" allow="geolocation https://example.com -https://foo.com;"></iframe> -``` - -The above example would grant geolocation to https://example.com as well as -https://foo.com when they are loaded in the iframe. To grant access to all -origins that might be loaded in the iframe, the \* syntax can be used. This -should be used carefully as it means that any page that gets loaded in the -iframe can request geolocation, which is often not the intent. The code would -look as follows: - -```html -<iframe src="<https://example.com>" allow="geolocation *;"></iframe> -``` - -Valid values for allow include: - -* geolocation -* microphone -* camera -* midi -* encrypted-media - -Note that if the iframe which is using the permission has the same origin as the -top level page, then no changes have to be made. - -## More Information - -To find more information about Permissions Policy, take a look at the following -resources: - -* [The permissions policy - specification](https://w3c.github.io/webappsec-permissions-policy/) -* [The permissions policy - explainer](https://github.com/w3c/webappsec-permissions-policy/blob/main/permissions-policy-explainer.md) -* [chromestatus.com entry for this - change](https://www.chromestatus.com/feature/5023919287304192)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/deprecating-powerful-features-on-insecure-origins/index.md b/chromium/docs/website/site/Home/chromium-security/deprecating-powerful-features-on-insecure-origins/index.md deleted file mode 100644 index c6b474d79bc..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/deprecating-powerful-features-on-insecure-origins/index.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: deprecating-powerful-features-on-insecure-origins -title: Deprecating Powerful Features on Insecure Origins ---- - -[TOC] - -## Proposal - -As browser users manage more and more of their day-to-day lives online, we -(Chrome Security) believe they should reasonably expect that browsing and -interacting with the web is secure and protects their sensitive information -across their entire browsing experience. Protecting users’ privacy and security -requires connecting to secure origins wherever possible. Practically speaking, -this means restricting features to HTTPS in lieu of HTTP, especially for -powerful web platform features. - -While [strong progress](https://transparencyreport.google.com/https/overview) -has been made in increasing HTTPS adoption on the web over the past several -years, there are still millions of sites that do not support secure connections -over HTTPS, which means that support for HTTP isn’t going away in the -foreseeable future. As long as a significant portion of browsing the web can -only happen over HTTP, it’s important that we take steps to protect and inform -users whenever we cannot guarantee that their connections are secure. - -Continuing from our past efforts to [restrict new features to secure -origins](/Home/chromium-security/prefer-secure-origins-for-powerful-new-features), -we are taking further steps on our path of deprecating powerful features on -insecure origins in order to mitigate the most privacy- and security-sensitive -risks of using HTTP in Chrome. To guide our efforts going forward, we have -created the following principles, which we will use to prioritize future work in -this area: - -- **Better inform users when making trust decisions about sites over - insecure connections** Over time, Chrome users are making an - increasingly large amount of trust decisions when interacting with - websites, whether by granting permissions for powerful web features, - submitting personal information to a website, or downloading - executable code. However, when the connection to a website is - unauthenticated and unencrypted, these trust decisions aren’t bound - to the intended site in a meaningful way. When Chrome presents users - with such a trust decision, we plan on ramping up warnings to users - when these features are being used over connections to insecure - origins. - -- **Limit the ability for sites to circumvent security policies over - insecure connections** The [same-origin-policy - (SOP)](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) - is an important security policy that limits a website’s ability to - interact with resources from other origins. Several powerful web - platform features (such as - [postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) - and [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) - allow for websites to exempt domains from this policy to provide a - more feature-rich experience. Our goal for future versions of Chrome - to gradually limit the ability for insecure origins to be expressed - in policy exceptions like these. - -- **Change how, and for how long, Chrome stores site content provided - over insecure connections** When browsing to a site over HTTP today, - Chrome will both [cache site - content](/developers/design-documents/network-stack/http-cache) for - future use as well as providing access to persistent [local - storage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage). - When this content is provided over insecure and unauthenticated - connections, the value of this persistent storage is significantly - reduced and we are exploring ways to limit the duration this content - will persist on user devices between visits to insecure origins. - -## Powerful Features restricted to Secure Origins - -A (non-exhaustive) list of powerful features we have already restricted to -secure origins includes: - -- Geolocation -- Device motion / orientation -- EME -- getUserMedia -- AppCache -- Notifications - -## Testing Powerful Features - -If you are a developer that needs to keep testing a site using a powerful -feature that has been restricted to secure origins, [this -article](https://web.dev/how-to-use-local-https/) provides helpful instructions -for a variety of options for local development, including testing on -<http://localhost> where possible, creating and using self-signed certificates, -as well as creating, installing, and managing self-signed CAs to issue testing -and development certificates. - -In addition to this guidance, there are some Chrome and Android-specific tips -that can help when developing and testing features restricted to secure origins: - -1. You can use `chrome://flags/#unsafely-treat-insecure-origin-as-secure` to run - Chrome, or use the - `--unsafely-treat-insecure-origin-as-secure="http://example.com"` flag - (replacing "example.com" with the origin you actually want to test), which - will treat that origin as secure for this session. Note that on Android and - ChromeOS the command-line flag requires having a device with root access/dev - mode. - -2. On a local network, you can test on your Android device using [port - forwarding](https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server) - to access a remote host as localhost. - -We continue to invest in improved methods for testing powerful features on -insecure origins, and we'll update this page once we've developed them. Feel -free to contribute ideas to -[security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/education/index.md b/chromium/docs/website/site/Home/chromium-security/education/index.md deleted file mode 100644 index 62b474ff5e0..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/education/index.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: education -title: Education ---- - -Security is a core principle and shared responsibility for everyone contributing -to Chromium. Here are some docs that can help an engineer get ramped up to -Chrome-specific security best practices, pitfalls, or relevant background. Send -your comments, questions, or additional security education needs to -security-dev@chromium.org - -* [IPC Security - Tips](/Home/chromium-security/education/security-tips-for-ipc), a - thrilling read about how to avoid introducing an IPC vulnerability - and feature in the next - [Pwnium](http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html) - contest. -* Security tips for avoiding common vulnerabilities and abuse vectors - when [developing extensions and - apps](/Home/chromium-security/education/security-tips-for-crx-and-apps). -* [Everything you wanted to know about TLS/SSL in - Chrome](/Home/chromium-security/education/tls) -* If you are implementing a Chrome Extension/App API, read the - [security guidelines for Chrome Extension & App API - developers](https://docs.google.com/document/d/1RamP4-HJ7GAJY3yv2ju2cK50K9GhOsydJN6KIO81das/pub). -* Do not implement your own allocator. Custom allocators are a major - source of [security - vulnerabilities](https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=437). - Chrome's existing allocators (e.g. - [Tcmalloc](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmalloc/chromium/src/&q=tcmalloc&sq=package:chromium), - [PartitionAlloc](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/wtf/PartitionAlloc.h&q=PartitionAlloc&sq=package:chromium&type=cs&l=1)) - and resillient to security issues. If you absolutely need to - implement some form of custom allocator, make sure to get a thorough - review from the security team. -* When manipulating buffers in trusted memory, do not implement your - own code for handling [integer - overflows](http://en.wikipedia.org/wiki/Integer_overflow#Security_ramifications), - truncations, or other integral boundary conditions. Instead use - [base/numerics](https://code.google.com/p/chromium/codesearch#chromium/src/base/numerics/&ct=rc&cd=1&q=base/numerics&sq=package:chromium) - templates which are already used in several parts of Chrome. The - following refernces are also good resources on integer security - issues: - * CERT C++ [Secure Coding - Standard](https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637). - * Mark Dowd, John McDonald, Justin Schuh, [The Art of Software - Security Assessment: Identifying and Preventing Software - Vulnerabilities](http://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426/ref=sr_1_1?s=books&ie=UTF8&qid=1402949525&sr=1-1&keywords=The+Art+of+Software+Security+Assessment). - * Robert C. Seacord, [Secure Coding in C and - C++](http://www.amazon.com/Secure-Coding-Robert-C-Seacord/dp/0321335724).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-crx-and-apps/index.md b/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-crx-and-apps/index.md deleted file mode 100644 index b2398b7be6b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-crx-and-apps/index.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/education - - Education -page_name: security-tips-for-crx-and-apps -title: Security Tips for Developing CRX ---- - -*(Note: Content adapted from an [earlier blog post on this -topic](http://blog.chromium.org/2011/07/writing-extensions-more-securely.html).)* - -Chrome extensions (CRX) are powerful pieces of software in modern browsers, and -as such, you should help ensure that your extensions are not susceptible to -security exploits. If an attacker manages to exploit a vulnerability in a CRX, -they may gain access to the same privileges that the extension has. The Chrome -extensions system has a number of [built-in -protections](http://blog.chromium.org/2009/12/security-in-depth-extension-system.html) -to make it more difficult to introduce exploitable code, but certain coding -patterns can still introduce common web vulnerabilities like cross-site -scripting (XSS). - -## **Minimize your permissions** - -The most important thing to consider is whether you’re declaring the minimal set -of permissions that you need to function. That way, if you do have a security -bug in your code, the amount of permissions you’re exposing to the attacker is -minimal as well. Avoid requesting (\*/\*) permissions for hosts if you only need -to access a couple, and don’t copy and paste your manifest from example code -blindly. Review your manifest to make sure you’re only declaring what you need. -This applies to permissions like tabs, history, cookies, etc. in addition to -host permissions. For example, if all you’re using is -[chrome.tabs.create](http://code.google.com/chrome/extensions/tabs.html#method-create), -you don’t actually need the tabs permission. - -Another way of minimizing install time permissions is to use [optional -permissions](https://developer.chrome.com/extensions/permissions). Using -chrome.permissions API, you can request permissions only when you need them -during runtime. - -## **Use content_security_policy in your manifest** - -[Content Security -Policy](http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html) -is supported in extensions via the -[content_security_policy](http://code.google.com/chrome/extensions/trunk/manifest.html#content_security_policy) -manifest field. This allows you to control where scripts can be executed, and it -can be used to help reduce your exposure to XSS. For example, to specify that -your extension loads resources only from its own package, use the following -policy: -"content_security_policy": "default-src 'self'" -If you need to include scripts from specific hosts, you can add those hosts to -this property. - -## **Don’t use <script src> with an HTTP URL** - -When you include javascript into your pages using an HTTP URL, you’re opening -your extension up to man-in-the-middle (MITM) attacks. When you do so in a -content script, you have a similar effect on the pages you’re injected into. An -attacker on the same network as one of your users could replace the contents of -the script with content that they control. If that happens, they could do -anything that your page can do. -If you need to fetch a remote script, always use HTTPS from a trusted source. - -## **Don’t use eval()** - -The eval() function is very (too!) powerful, and you should avoid using it -unless absolutely necessary. Where did the code come from that you passed into -eval()? If it came from an HTTP URL, you’re vulnerable to a MITM attack. If any -of the content that you passed into eval() is based on content from a random web -page the user visits, you’re vulnerable to content escaping bugs. For example, -let’s say that you have some code that looks like this: -function displayAddress(address) { // address was detected and grabbed from the -current page -eval("alert('" + address + "')"); -} -If it turned out that you had a bug in your parsing code, the address might wind -up looking something like this: -'); dosomethingevil(); -There’s almost always a better alternative to using eval(). For example, you can -use JSON.parse if you want to parse JSON (with the added benefit that it runs -faster). - -## **Don’t use innerHTML or document.write()** - -It’s really tempting to use innerHTML because it’s much simpler to generate -markup dynamically than to create DOM nodes one at a time. However, this sets -you up for XSS bugs. For example: -function displayAddress(address) { // address was detected and grabbed from the -current page -myDiv.innerHTML = "<b>" + address + "</b>"); -} -This would allow an attacker to make an address like the following and once -again run some script in your page: -<script>dosomethingevil();</script> -Instead of innerHTML, you can manually create DOM nodes and use innerText to -insert dynamic content. - -## **Beware of external content** - -In general, if you’re generating dynamic content based on data from outside of -your extension (such as something you fetched from the network, something you -parsed from a page, or a message you received from another extension, etc.), you -should be extremely careful about how you use and display it. If you use this -data to generate content within your extension, you might be opening your users -up to increased risk. - -## **Additional Resources** - -* Additional security tips and examples for Content Scripts in our - [Extension Developer - Docs](https://developer.chrome.com/extensions/content_scripts.html#security-considerations) -* [Advanced Chrome Extension Exploitation Leveraging API powers for - Better - Evil](http://kyleosborn.com/bh2012/advanced-chrome-extension-exploitation-WHITEPAPER.pdf) - (by krzysztof@kotowicz.net and kos@kos.io) -* [Security guidelines for Chrome Extension & App API - developers](https://docs.google.com/document/d/1RamP4-HJ7GAJY3yv2ju2cK50K9GhOsydJN6KIO81das/pub)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-ipc/index.md b/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-ipc/index.md deleted file mode 100644 index c42772419b7..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/education/security-tips-for-ipc/index.md +++ /dev/null @@ -1,219 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/education - - Education -page_name: security-tips-for-ipc -title: Security Tips for IPC ---- - -**Note: This document is for legacy IPC. For Mojo IPC, please refer to -<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/mojo.md>** - -**The [Integer Semantics section has moved to Markdown -too](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/integer-semantics.md).** - -Chrome's[inter-process communication -(IPC)](http://www.chromium.org/developers/design-documents/inter-process-communication) -layer is the communication channel supporting our [multi-process -architecture](http://www.chromium.org/developers/design-documents/multi-process-architecture). -Security bugs in IPC can have [nasty -consequences](http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html), -but sticking to these tips should help you avoid most pitfalls. Questions, -feedback, or suggestions to security@chromium.org. - -**[TOC]** - -## Trust only the browser process. - -**Generally, privileged processes must set all policy. In Chromium, this means -the browser process. "Policy" means: sizes, addresses, object names, filesystem -pathnames, permissions/ACLs, specific implementations of interfaces, etc. In -practice, this is how it should work:** - - ******Unprivileged process asks for capability.****** - - ******Privileged process applies policy to find an implementation for the - capability.****** - - ******Unprivileged process receives it and performs constrained operations - on it.****** - - ******Privileged process owns the capability lifecycle.****** - -## **Do not trust renderer, PPAPI, or GPU processes.** - -IPC messages from the renderers must be viewed with the same skepticism as one -would apply to user input. These messages are untrustworthy input. - -## Sanitize and validate untrustworthy input. - -If you're handling filenames or paths derived from untrustworthy input, make -sure to avoid [directory traversal -attacks](http://en.wikipedia.org/wiki/Directory_traversal_attack) by sanitizing -(e.g. by using a FilePath rather than a string, because FilePath implicitly -checks for ".." traversal sequences and other unanticipated platform behavior) -and ensuring the resulting path is within your base directory. - -To construct a valid pathname, apply a function like FilePath::BaseName() to the -untrustworthy pathnames; now it's a basename for sure, and not a full pathname -or a sneaky trick. Then prefix the basename with a static directory name. Also -apply simple, "obviously-correct" lexical checks such as an RE match for -/^\\w{8,16}$/. - -## Allowing is better than blocking. - -If you know the full set of valid data, then compare against that rather than -checking for occurrences of known-bad data. - -## **Safely handle known-bad input.** - -When validating untrustworthy input, don't simply use CHECK. We do not want the -input validation mechanism to become an easy way for a malicious renderer to -kill the browser process. It's usually better to ignore the bad input, or for -the privileged process to immediately kill the sender of invalid inputs. - -To terminate a malfunctioning IPC sender, see -BrowserChildProcessHostImpl::TerminateOnBadMessageReceived. - -## **Use and validate specific, constrained types; let the compiler work for you.** - -Use the most specific data type you can to enable the type system to do part of -your data validation. In other words, do you really need to use a string? Using -more constrained types (e.g. primitives, enum, GURL instead of std::string that -is "supposed to be a URL", etc.) lets the compiler do the type checking for you -and leads to faster, often smaller, and safer code that is easier for -maintainers and reviewers to understand. The most common pattern we see -violating this is unnecessary use of strings, which are essentially "blob types" -that are often slow (copying, lexing/parsing, used as keys in maps), and "vague" -in API contracts. The caller has to know how the callee is going to parse the -string, and the callee has to parse and validate it correctly (see the next -section). - -Some other specific tips: - -* Use integer types for ids (e.g. audio device IDs: - <https://codereview.chromium.org/12440027>). -* Use pre-defined styles instead of allowing arbitrary CSS injection - with strings, which could lead to XSS (e.g. - <https://codereview.chromium.org/11413018/diff/8041/chrome/browser/ui/browser_instant_controller.cc#newcode252>). -* If you must pass filesystem pathnames and path components over IPC, - use FilePath and check for path traversal using - FilePath::ReferencesParent. -* IPC_ENUM_TRAITS() is deprecated (it generates unchecked enums). - IPC_ENUM_TRAITS_MAX_VALUE and friends in ipc/param_traits_macros.h - can help you make a constrained enum. Keep in mind that it takes the - range min..max *inclusive*. - -More generally, don't implement your own serialization mechanism -(std::vector<char>, protobufs) on top of the Chrome IPC system. Break up -your structs and use the primitives provided by Chrome IPC. - -## **Keep it simple.** - -**Send limited capabilities (e.g. file descriptors -but not directory -descriptors-), not open-ended, complex objects (e.g. pathnames). For example, to -write a temporary file, the renderer should ask the browser for a file -descriptor/HANDLE; the browser should create one entirely according to its own -policy; and then the browser should pass the descriptor to the renderer.** - -## Be aware of the subtleties of integer types. - -First read about the scary security implications of[ integer arithmetic. -](http://en.wikipedia.org/wiki/Integer_overflow)Adhere to these best practices: - -* **Use unsigned types for values that shouldn't be negative or where - defined overflow behavior is required.** -* Use explicitly sized integer types, such as int32, int64, or uint32, - since sender and receiver could potentially use different - interpretations of implicit types. -* Use the integer templates and cast templates in - [base/numerics](https://code.google.com/p/chromium/codesearch#chromium/src/base/numerics/) - to avoid overflows, *especially when calculating the size or offset - of memory allocations.* - -## **Be aware of the subtleties of integer types across C++ and Java, too.** - -When writing code for Chromium on Android, you will often need to marshall -arrays, and their sizes and indices, across the language barrier (and possibly -also across the IPC barrier). The trouble here is that the Java integer types -are well-defined, but the C++ integer types are whimsical. A Java int is a -signed 32-bit integer with well-defined overflow semantics, and a Java long is a -signed 64-bit integer with well-defined overflow semantics. in C++, only the -explicitly-sized types (e.g. int32_t) have guaranteed exact sizes, and only -unsigned integers (of any size) have defined overflow semantics. - -Essentially, Java integers *actually are* what people often (incorrectly) -*assume* C++ integers are. Furthermore, Java Arrays are indexed with Java ints, -whereas C++ arrays are indexed with size_t (often implicitly cast, of course). -Note that this also implies a 2 Gig limit on the number of elements in an array -that is coming from or going to Java. That Should Be Enough For Anybody, but -it's good to keep in mind. - -You need to make sure that every integer value survives its journey across -languages intact. That generally means explicit casts with range checks; the -easiest way to do this is with the base::checked_cast cast or -base::saturated_cast templates in -[safe_conversions.h](https://code.google.com/p/chromium/codesearch#chromium/src/base/numerics/safe_conversions.h). -Depending on how the integer object is going to be used, and in which direction -the value is flowing, it may make sense to cast the value to jint (an ID or -regular integer), jlong (a regular long integer), size_t (a size or index), or -one of the other more exotic C++ integer types like off_t. - -## **Don't leak information, don't pass information that would be risky to use.** - -**In particular, don't leak addresses/pointers over the IPC channel, either -explicitly or accidentally. (Don't defeat our -[ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization)!) Worse: -sending pointers over the IPC is almost certainly a sign of something very wrong -and could easily lead to memory corruption.** - -Do not pass child_id, that is [the ID of child processes as viewed by the -browser](https://code.google.com/p/chromium/codesearch#chromium/src/content/common/child_process_host_impl.h&l=54) -(which are not the same as the OS PIDs), from the browser via IPC. This -construct is risky because it would be tempting to send back this ID to the -browser and mistakenly use it as an authentication token, which it is not. - -## **Avoid Unsafe (Common) Coding Patterns** - -* Avoid accessing underlying string or array data via - std::string::c_str or std::vector::data. If you do, make sure to - stay in bounds. Note that std::string::operator\[\] and - std::vector::operator\[\] are not required to do bounds checking. -* Databases: When storing together both user data and metadata, make - sure that the renderer can't directly read/write metadata via some - sort of corrupted access of user data. -* Databases: Assume that the database might be corrupted. Integers - might have become large or negative, filesystem paths might have - changed to "../../../../etc/passwd", etc. Do some validation. -* Don't validate inputs with DCHECKs (and WebKit ASSERTs) in the - high-privilege process that fail with invalid input from the - lower-privilege process. Instead, explicitly validate each input and - fail fast on any invalid input. Using the macros alone leads to a - false sense of security since they aren't compiled into release - builds. -* Be careful with shared memory mappings (specifically tracking their - sizes on either side of the IPC channel). Do not store and trust - sizes on one side of the channel. Avoid specifying the size when - calling Map. -* Keep serializers/deserializers within ParamTraits Read and Write - methods. -* If your design requires you to serialize a structure into a string - you are doing it wrong. Look at the IPC_STRUCT_ macros. -* Use ReadLength wherever possible in deserializers instead of - ReadInt, et c. -* Avoid using ReadData within deserializers. If your design requires - this it is almost certainly wrong. -* Remember that, when specifying an ID in a message, a compromised - process on the less privileged end can can specify another valid ID. - Code should not assume that objects looked up by ID match other - local state. - -## What About Mojo? - -The underlying principles are exactly the same whether reviewing a Mojo-based CL -vs. a Chromium IPC CL. A short presentation can be found at -<https://docs.google.com/a/google.com/presentation/d/1uo8WAD6Hgq_gjlODb2ioUNGQs9RGlUYSQywxZOwCzcE/edit?usp=sharing>
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/education/tls/index.md b/chromium/docs/website/site/Home/chromium-security/education/tls/index.md deleted file mode 100644 index 28e09fc0fd8..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/education/tls/index.md +++ /dev/null @@ -1,349 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/education - - Education -page_name: tls -title: TLS / SSL ---- - -Data delivered over an unencrypted channel (e.g. HTTP) is insecure, -untrustworthy, and trivially intercepted. **TLS can help!** - -[TOC] - -## What's TLS? - -TLS (also known as SSL) is the industry standard for providing communication -security over the Internet. - -### **What security properties does TLS give me?** - -TLS guarantees identification, confidentiality, and integrity between a client -(a computer) and a server. - -* Server identification means that the user is talking to the right - server — i.e., your bank's server, and not someone on the network - pretending to be your bank's server. -* Confidentiality (via encryption) ensures that no one with access to - the data going over the connection can understand the contents of - the communication. -* Integrity means that no one can tamper with the data in transit. - -In other words, TLS ensures that a [Man-in-the-Middle -(MitM)](/Home/chromium-security/education/tls) can't snoop or tamper with an -Internet connection between a user and website. A [man-in-the-middle -(MiTM)](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) is a term used to -describe a third party that can passively monitor and/or actively tamper with a -connection between two unknowing parties. A MiTM attacker relays messages -between two parties, making them believe that they are talking directly to each -other, when in fact the entire conversation is controlled by the attacker. - -MiTM attacks happen in real life! Here are some recent examples: - -* Opportunistic attacks on wifi networks are easy to conduct via - freely available tools like - [sslstrip](http://www.thoughtcrime.org/software/sslstrip/) or - [firesheep](http://codebutler.com/firesheep/) -* [NSA MiTM monitoring](https://www.eff.org/nsa-spying) of email, - chat, and other Internet communication -* [ISPs collecting - data](http://www.dslreports.com/shownews/Bell-Dramatically-Ramps-Up-Consumer-Data-Collection-Efforts-126375) - via MiTM sniffing for marketing purposes -* [ISPs modifying web - pages](http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-for-hs-ok/) - (adding ads) via MiTM tampering -* Chinese hackers [targeting - github](https://en.greatfire.org/blog/2013/jan/china-github-and-man-middle) - -### **What security properties does TLS *not* give me?** - -TLS only protects the connection between your computer and the server. It does -not protect data on the client or data on the server. This means: - -* If malware is installed on your computer, it will be able to see and - modify your web traffic. -* If your system administrator has installed local trust anchors or a - local proxy (for example, on a company computer), then the system - administrator may be able to see and modify your web traffic. -* If malware is installed on the server, your data on the server may - be at risk. -* TLS does not stop compromised or rogue servers from trying to - install malware on your computer. Instead, [Google Safe - Browsing](https://www.google.com/transparencyreport/safebrowsing/) - scans websites and files for signs of malware. If Google Safe - Browsing flags a website or file as malicious, you will see a - separate malware warning for the website or file. This is unrelated - to TLS. - -## **TLS in Chrome** - -### **HTTP Strict Transport Security (HSTS)** - -HSTS is a mechanism enabling web sites to declare themselves accessible only via -secure connections and/or for users to be able to direct their user agent to -interact with given sites only over secure connections. Chrome supports HSTS and -comes preloaded with a set of domains that use HSTS by default. More details, -including how to add a site to Chrome's preloaded HSTS list, [here](/hsts). - -### **Certificates** - -TLS relies on websites serving authenticated (X.509) certificates to prove their -identities, which prevents an attacker from pretending to be the website. -Certificates bind a public key and an identity (commonly a DNS name) together -and are typically issued for a period of several years. Ensure that your CA -gives you a SHA-256 certificate, as SHA-1 certificates are deprecated (see -below). - -#### **Certificate Pinning** - -Chrome has HTTPS "pins" for most Google properties — i.e. certificate chains for -Google properties must have a explicitly listed public key, or it will result in -a fatal error. This feature helped Google [detect a widespread MITM attack to -Gmail users in -2011](http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html). -You can read more about pinning -[here](https://www.imperialviolet.org/2011/05/04/pinning.html). There's also an -[Internet-Draft for HTTP-based public key -pinning](http://tools.ietf.org/html/draft-ietf-websec-key-pinning). - -#### **Certificate Revocation** - -Sometimes events occur that invalidate the binding of public key and name, and -the certificate needs to be revoked. For example, a [major flaw in the -implementation of OpenSSL](http://heartbleed.com/) left site operators' private -key vulnerable to theft, so operators needed to invalidate their certificates. -Revocation is the process of invalidating a certificate before its expiry date. -Chrome uses [CRLSets](https://www.imperialviolet.org/2012/02/05/crlsets.html) to -implement certificate revocation. You can read about the how and why of Chrome's -certificate revocation in our [Security -FAQ](/Home/chromium-security/security-faq). - -#### **Certificate Errors** - -If there is an error in the certificate, Chrome can’t distinguish between a -configuration bug in the site and a real MiTM attack, so Chrome takes proactive -steps to protect users. - -If a site has elected to use HSTS, all certificate errors are fatal. Certificate -pinning errors are also fatal. Otherwise, users are shown a full-screen warning -interstitial they can elect to bypass. - -### Cipher Suites - -TLS connections negotiate a *cipher suite* which determines how data is -encrypted and authenticated. Server products typically leave configuring this to -the administrator. Many cipher suites available in TLS are obsolete and, while -currently supported by Chrome, are not recommended. If an obsolete cipher suite -is used, Chrome may display this message when clicking the lock icon: - -> *“Your connection to example.com is encrypted with obsolete cryptography.”* - -To avoid this message, use TLS 1.2 and prioritize an ECDHE cipher suite with -AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate -TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. - -### **Deprecated and Removed Features** - -#### SHA-1 Certificate Signatures - -You may see this message when you click on the lock icon in Chrome: - -> *"This site uses a weak security configuration (SHA-1 signatures), so your -> connection may not be private."* - -This means that the certificate chain for the current page is contains a -certificate using a SHA-1-based signature, which is -[outdated](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html) -and [deprecated in -Chrome](https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html). -There are two criteria that determine which lock icon is shown in Chrome: - -* the **expiration date of the leaf certificate** and -* whether there is a **SHA-1-based signature in the certificate - chain** (leaf certificate OR intermediate certificate). - -Note that the expiration dates of the intermediate certificate do not matter. -Also, SHA-1-based signatures for root certificates are not a problem because -Chrome trusts them by their identity, rather than by the signature of their -hash. -Starting in Chrome 42, the following logic applies: - -* If a leaf certificate **expires in 2016** and the chain **contains a - SHA-1 signature**, the page will be marked as "secure, but with - minor errors" (yellow icon). -* If a leaf certificate **expires in 2017 or later** and the chain - **contains a SHA-1 signature**, the page will be treated as - "affirmatively insecure" (red icon). - -Note that this use of SHA-1 is not related to TLS message authentication (*“The -connection is using \[cipher\], with HMAC-SHA1 for message authentication.”*). - -Please see [this page](/Home/chromium-security/education/tls/sha-1) for more -details on deprecation dates and private enterprise PKIs. - -#### Weak Ephemeral Diffie-Hellman Key Exchange (ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY) - -Chrome requires a minimum DHE group size of 1024-bits. See [this -announcement](https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/WyGIpevBV1s) -and [this -page](https://support.google.com/chrome/answer/6098869?p=dh_error&rd=1#DHkey) -for more details. Affected sites will fail to load with -ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY. - -#### SSLv3 - -SSLv3 is no longer supported in Chrome. See [this -announcement](https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/Vnhy9aKM_l4) -for more details. - -#### RC4 - -Chrome will remove support for the RC4 cipher in a future release around January -or February 2016. Server operations should tweak their configuration to support -other cipher suites. If available, TLS 1.2 with -TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is recommended. See [this -announcement](https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/kVfCywocUO8) -for more details. - -#### Insecure Version Fallback (ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION) - -Historically, some buggy servers have required an insecure version fallback to -function. This has been partially removed in Chrome and will be fully removed at -a later date. See [this -announcement](https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/F6ZjP6FnyRE/bK7TKtvnHYsJ) -for more details. Affected sites will fail to load with -ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION. - -### **TLS Resources for Developers and Site Operators** - -#### TLS Myths - -#### **The only security guarantee TLS provides is confidentiality.** - -When properly deployed, TLS provides three guarantees: **authentication of the -server**, **data integrity** (tamper-evidence), and **data confidentiality**. -People often think TLS and HTTPS only apply in threat scenarios where data -confidentiality is needed, but in fact they apply when any (or, most often, all -3) guarantees are beneficial. - -* Authentication and integrity: The authors and readers of a news site - want the news to be the true news that the authors intended. (See - [the *New York Times*’ statement about - this](http://open.blogs.nytimes.com/2014/11/13/embracing-https/).) -* Authentication and integrity: The users of a financial information - site very much need the facts and figures to be true. -* Confidentiality: You could be just browsing the web, and a pervasive - passive monitor could use this to build a profile of you, to track - your related experiences on a variety of sites, to cross-reference - your interactions, and then declare you a “threat” for otherwise - benign interactions. -* Confidentiality: You might be reading an article on reproductive - health or religious beliefs that are contrary to local norms. - Revealing this information could get you in “trouble”, for some - definition of trouble. -* Integrity: You could be reading a website supported by advertising, - but that advertising might be rewritten to credit the attacker, - rather than the site you're reading. Over time, the site you're - reading may need to shut down, because all of their revenue has been - stolen by attackers. -* Integrity: You could be reading a blog, but which an attacker - changes the content to suggest the blogger is endorsing or holding - views contrary to what they really hold. - -**My site doesn't need TLS. I'm not a bank.** - -More people are connected to the web than ever before and from more places and -more devices (laptops, phones, tablets, and [other -things](http://en.wikipedia.org/wiki/Internet_of_Things)). Very often, this -access is over untrusted or hostile networks. Data delivered over a clear text -protocol, like HTTP, is insecure, untrustworthy, and trivially intercepted. -Neither the user / user-agent nor the web server / application can trust that -the data was not tampered with or snooped by some third party - that's a -terrible situation for both users and web site operators! - -With so much of people's lives moving online, it’s imperative developers take -steps to protect their sites' and users' data, which can even include the *mere -usage* of a web site. By analyzing and correlating the sites and pages a user -visits, observers like schools, ISPs, and governments can learn quite a bit -about a user that the user would wish to keep confidential, such as a users' -sexual orientation -(<http://blogs.wsj.com/digits/2010/03/12/ftcs-privacy-worries-prompt-netflix-to-cancel-contest/>) -or physical location -(<http://www.theregister.co.uk/2009/05/21/geo_location_data/>). - -#### **TLS is too slow.** - -Historically, TLS used to have a significant performance on web applications. -So, [istlsfastyet.com](http://istlsfastyet.com/)? (Spoiler: Yes!) Check out -<https://istlsfastyet.com/> for more details and a performance checklist. - -#### TLS is too expensive. - -[The Let’s Encrypt project](https://letsencrypt.org/) offers free certificates. - -[SSLs.com offers certificates for a very low price](https://www.ssls.com/), as -low as $5. - -[SSLmate.com is cheap and easy to use](https://sslmate.com/) — you can buy -certificates from the command line. - -#### TLS is a privacy / security silver bullet. - -TLS does ==not== guarantee perfect privacy or solve all security problems. - -For example, when used to secure HTTP traffic (i.e. HTTPS), we’re piggybacking -HTTP entirely on top of TLS. This means the entirety of the HTTP protocol can be -encrypted (request URL, query parameters, headers, and cookies), however, -because host IP addresses and port numbers are necessarily part of the -underlying TCP/IP protocols, a third party can still infer these. Also, while -you can’t infer the contents of the communication, you can infer the amount and -duration of the communication. For specific applications, it’s been demonstrated -that this can leak useful information for an attacker, and services have added -padding to counter the timing or pattern analysis. - -The identity of the site you are visiting is still (unfortunately) pretty -visible to passive eavesdroppers. For example, the IP addresses of client and -server are shown in the clear on the network, and the hostname(s) of the sites -you are visiting are transmitted in the clear in DNS requests, in the [Server -Name Indication portion of a TLS -handshake](http://en.wikipedia.org/wiki/Server_Name_Indication), and in the -server's certificate(s). -Also, since TLS is a transport protocol, attacks at other layers of the network -stack remain. In particular, IP-level threats (e.g. spoofing, SYD floods, DDoS -by data flood) are not protected and TLS doesn’t address common web application -vulnerabilities, like cross-site scripting or cross-site request forgery. - -### Common Pitfalls - -#### Deploying TLS - -SSL Labs puts out a great [Deployment Best Practice -Guide](https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices) -that should help site operators avoid the most common deployment mistakes. You -can also test your setup via <https://www.ssllabs.com/ssltest/>. - -#### Mixed Content (HTTP / HTTPS) Vulnerabilities - -A mixed content vulnerability refers to a page served over HTTPS that includes -content served over HTTP, making the page vulnerable to MitM attacks. This is -especially problematic when the HTTP resources are active content (e.g. -Javascript, plug-in content, CSS, or iframes). To protect users, Chrome will -block mixed-content iframes, Javascript, CSS and plug-in loads by default. So -beyond the security risk, mixed content bugs may degrade your page for users in -unintended ways. -To fix mixed content issues, make sure that all the resources loaded by an HTTPS -page are also sent over HTTPS. If the resources are available on the same -domain, you can use hostname-relative URLs (e.g. <img -src="something.png">). You can also use scheme-relative URLs (e.g. <img -src="//example.com/something.png">) — the browser will use the same scheme as -the enclosing page to load these subresources. If the server does not serve -these resources over HTTPS, you may have to serve them from elsewhere or enable -HTTPS on that server. - -You may also want to consider the -[upgrade-insecure-requests](http://www.w3.org/TR/upgrade-insecure-requests/) CSP -directive.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/education/tls/sha-1/index.md b/chromium/docs/website/site/Home/chromium-security/education/tls/sha-1/index.md deleted file mode 100644 index 356c2570ec4..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/education/tls/sha-1/index.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/education - - Education -- - /Home/chromium-security/education/tls - - TLS / SSL -page_name: sha-1 -title: A further update on SHA-1 certificates in Chrome ---- - -We’ve previously made -[several](https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html)[ -announcements](https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html) -about Google Chrome's deprecation plans for SHA-1 certificates. This post -provides an update on the final removal of support. - -The SHA-1 cryptographic hash algorithm first [showed signs of -weakness](https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html) -over eleven years ago and [recent research](https://eprint.iacr.org/2015/967) -points to the imminent possibility of attacks that could directly impact the -integrity of the Web PKI. To protect users from such attacks, Chrome will stop -trusting certificates that use the SHA-1 algorithm, and visiting a site using -such a certificate will result in an interstitial warning. - -Release schedule - -We are planning to remove support for SHA-1 certificates in Chrome 56, which -will be released to the stable channel [around the end of January -2017](/developers/calendar). The removal will follow the [Chrome release -process](/getting-involved/dev-channel), moving from Dev to Beta to Stable; -there won't be a date-based change in behaviour. - -Website operators are urged [to check](https://www.ssllabs.com/ssltest/) for the -use of SHA-1 certificates and immediately contact their CA for a SHA-256 based -replacement if any are found. - -SHA-1 use in private PKIs - -Previous posts made a distinction between certificates which chain to a public -CA and those which chain to a locally installed trust anchor, such as those of a -private PKI within an enterprise. We recognise there might be rare cases where -an enterprise wishes to make their own risk management decision to continue -using SHA-1 certificates. - -Starting with [Chrome -54](https://googlechromereleases.blogspot.com/2016/10/stable-channel-update-for-desktop.html) -we provide the -[EnableSha1ForLocalAnchors](/administrators/policy-list-3#EnableSha1ForLocalAnchors)[ -policy](https://support.google.com/chrome/a/answer/187202) that allows -certificates which chain to a locally installed trust anchor to be used after -support has otherwise been removed from Chrome. Features which[ require a secure -origin](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins), -such as geolocation, will continue to work, and SHA-1 client certificates will -still be presented to websites requesting client authentication, however pages -will be displayed as “neutral, lacking security”. Without this policy set, SHA-1 -certificates that chain to locally installed roots will not be trusted starting -with Chrome 57, which will be released to the stable channel in March 2017. - -Since this policy is intended only to allow additional time to complete the -migration away from SHA-1, it will eventually be removed in the first Chrome -release after January 1st 2019. - -As Chrome makes use of certificate validation libraries provided by the host OS -when possible, this option will have no effect if the underlying cryptographic -library disables support for SHA-1 certificates; at that point, they will be -unconditionally blocked. We may also remove support before 2019 if there is a -catastrophic cryptographic break of SHA-1. Enterprises are encouraged to make -every effort to stop using SHA-1 certificates as soon as possible and to consult -with their security team before enabling the policy.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/enamel/goals-for-the-origin-info-bubble/index.md b/chromium/docs/website/site/Home/chromium-security/enamel/goals-for-the-origin-info-bubble/index.md deleted file mode 100644 index c82f324b470..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/enamel/goals-for-the-origin-info-bubble/index.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/enamel - - Security UX -page_name: goals-for-the-origin-info-bubble -title: Goals For The Origin Info Bubble ---- - -## Introduction - -This is the Origin Info Bubble (OIB): - -<img alt="pib.png" -src="https://lh3.googleusercontent.com/Mer74TWIss5I4pOWvFO5ctkZMqgOXElTD5J6opl3IF1cE_oWe2xI2yRIXk4E8_odc6UsJWQ58N0klaWMcEnau1_GnGPSlFP6lFYUUm-5Jnqz-GPWXeJqJWXK4simmsgpN6U" -height=523px; width=329px;> - -As you can see, it has a lot of stuff in it, with 2 tabs to hold 2 (arguably 3: -site data, permissions, and connection state) broad categories of information -and controls about what the origin is and what it can do. - -We are pretty sure the OIB does not show all and only the information and -controls that users need to understand and control an origin. - -I believe the purpose of the OIB is to allow users to understand and control the -origin. It was previously called the Page Info Bubble (PIB), but in this -document I’ll use the more accurate name. - -Since the OIB is the primary UI surface for control of an origin’s power, it -enables the increased appification of the web platform. It is thus very -important that we make it readily understandable and usable. See also -<https://code.google.com/p/chromium/issues/detail?id=421248>. - -## Possible Goals - -One can imagine the OIB serving a variety of purposes, including at least -display or control of: - - Information about the permissions/capability grants/special powers an origin - has - - Information about the transport security state of the origin - - Authenticated + confidential; partially authenticated + confidential; - unauthenticated or broken authentication or not confidential - - If authenticated: the certificate chain - - Or a control to launch the certificate viewer or other - developer/operator debugging information - - If authenticated: extra authentication information - - Certificate Transparency status - - Key pinning information - - Controls to set user-defined authentication policy: - - Accept this certificate - - Pin to the key(s) in this certificate chain - - … - - The origin’s name - - Historical context for the user’s past interaction with the origin - - # times visited in some period - - downloads - - bookmarks - - when or how often the origin has invoked powerful grants/APIs - - … - - Data the browser is storing locally for the origin - - cookies - - LocalStorage - - … - - Summary (storage quota, et c.) - - Processes the browser is running locally for the origin - - Service Workers - - Geofences - - Total/average/peak battery cost of this origin - - … - - Which extensions (if any) can access the origin - - Others? Surely I’m forgetting something. - -Obviously there’s no way we can really show/afford control of all that -information. That is especially true on small screens, but even on a large -screen it would be a crowded and overwhelming interface. (It already is.) -Therefore, we have to pick the most important and contextually-relevant -information and controls. - -We could and should choose what to show in the OIB based on context. For -example, we could only show those grants that differ from the profile-wide -defaults; we might never show certain marginal grants or content settings in the -OIB; we might treat local storage quotas as a grant (iff the origin is about to -exceed some profile-wide default); and so on. - -## Non-Goals - -It is a non-goal to show all possible information and controls about an origin -in the OIB. We are assuming, probably correctly, that the OIB cannot be both -complete and usable. Since the OIB is so important, we should trade off in favor -of usability over completeness where there is a conflict. - -## Current Goals - -This section describes the current goals for Chrome on desktop platforms -(including ChromeOS, but possibly not Athena). For information about the OIB on -non-desktop platforms, see [Non-Desktop -Platforms](https://docs.google.com/document/d/12PoBVo0D331RqnzVJwI8zbFU1hMs-ZcXcjqqwkG-6nc/edit#heading=h.fumazaednf88), -below. - -### Show The Origin Name - -We should use the OIB to show the origin name in an unambiguous, -human-meaningful way. (As described in [Presenting Origins To -Users](http://www.chromium.org/Home/chromium-security/enamel).) - -For origins whose hostnames have many labels we should show at least the -effective TLD + 1 label. (We call this “eTLD + 1”.) For example if the full -hostname is “a.b.c.pants.shoes.socks.wrists.co.jp” the eTLD (as determined by -the [Public Suffix List](https://publicsuffix.org/)) is co.jp; that + 1 label -(“wrists”) yields “wrists.co.jp”. Although not technically exact — -a.b.c.pants.shoes.socks.wrists.co.jp is distinct from -a.b.c.skirts.shoes.socks.wrists.co.jp — eTLD + 1 strikes a reasonable balance -between correctness and understandability. - -For origins whose hostnames are very long, due to a proliferation of labels or -of extremely long labels, we should again the show eTLD + 1. If there is not -room enough to show eTLD + 1, we should label the origin as possibly phishy -and/or having broken authentication. (Rationale: Even if the authentication is -perfectly good from a certificate or cryptographic perspective, it’s not good -enough if we can’t show it to users on the screen.) - -### Show The Summarized Origin Security State - -We assume that only developers and operators are likely to be interested in the -page-load’s complete security state. - -The complete security state of a page-load is: - - X.509 certificate chain; - - Certificate Transparency status; - - TLS and X.509 cryptographic parameters; and - - key pinning status. - -Since the OIB should be a primary UX surface for normal users, it should show -only: - - a tri-state security indicator (“Good”: authenticated + confidential; - “Dubious”: partially authenticated + confidential; “Bad”: unauthenticated or - broken authentication or not confidential); and - - a control to launch a full view of the security state. - -The full view of the security state must show the complete security state as -defined above. It may also afford users control over key pinning and HSTS policy -(currently available only in chrome://net-internals/#hsts) and control over -trust in invalid certificate chains (as becomes necessary when a user opts to -proceed through a CERT_INVALID warning). - -### Afford Control Of The Origin’s Special Grants - -By special grants, I mean grants that the user has affirmatively changed from -the profile-wide defaults. - -Note that if the profile-wide defaults change — because the user changed them in -chrome://settings/content or some future equivalent interface — then previously -“non-special” grants become effectively special, and we should consider showing -them in the OIB. For example, in a fresh profile the default grant for -geolocation is Ask. If a user visits maps.google.com and opts to Always give -that origin full access to the geolocation API, maps.google.com now has a -special grant. Assuming the user has not changed it, -[www.bing.com](http://www.bing.com) has the default grant and we might not show -it in the OIB. If the user later changes the default to always allow origins -full access to the geolocation API, the special grant to maps.google.com becomes -effectively non-special, and we might choose not to show it in the OIB. The -default grant to [www.bing.com](http://www.bing.com) remains non-special (even -though the actual grant has changed), and we might choose to continue not to -show it in the OIB. - -Full control over all grants to the origin probably cannot fit in the OIB. -Therefore it should be relegated to a secondary interface such as -chrome://settings/content (or some future equivalent interface).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/enamel/index.md b/chromium/docs/website/site/Home/chromium-security/enamel/index.md deleted file mode 100644 index 42eca1f574a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/enamel/index.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: enamel -title: Security UX ---- - -Online security is more than just eliminating buffer overflows from software. -One of our biggest security challenges is helping people make safe decisions -while they surf the web. Here are some of the things we're doing to make -security on the web easier for everyone — both people who use browsers and web -apps, and web app developers. Some of these points are discussed in more detail -in [Improving Chrome’s Security -Warnings](https://docs.google.com/presentation/d/16ygiQS0_5b9A4NwHxpcd6sW3b_Up81_qXU-XY86JHc4/edit?usp=sharing) -by Adrienne Porter Felt. - -[TOC] - -## Anti-malware - -### Malicious Websites - -Malicious or compromised websites try to attack visitors. To protect people from -these threats, Chrome uses [Safe -Browsing](/developers/design-documents/safebrowsing) to identify attack -websites. If Safe Browsing tells Chrome that a website is malicious, Chrome -shows a full-screen warning. Despite the fact that our warnings are rarely -wrong, people ignore the warnings nearly a fifth of the time. We are actively -running experiments with the goal of decreasing how many people ignore the -warnings. - -### Malware Downloads - -Shady websites also try to trick people into installing malicious programs on -their computers. By default, Chrome blocks known malware downloads. Chrome also -warns people about potentially dangerous files that have not been scanned; we -are trying to improve this generic warning with new security measures. For -example, we want to make it easier for people to view PDFs more safely without -needing to show warnings about PDFs. - -## Passwords And Phishing - -Password management is hard. Sometimes people choose weak passwords, re-use -passwords inappropriately, or type passwords into phishing websites. The browser -currently offers people minimal assistance in choosing good passwords or knowing -when to enter them. We're currently using [Safe Browsing to help warn people -about phishing pages](https://support.google.com/chrome/answer/99020?hl=en), but -we're also working on other ways to make authentication on the web easier and -safer. - -## Website Authentication - -Website authentication is paramount to online security. We know that current -HTTPS indicators and warnings are confusing, and they are often false positives. -The browser’s lack of confidence about the authenticity of a given TLS -connection forces it to offer people a choice that they are not likely to -understand, so we're working on ways to improve website authentication and -protect users from inadvertently visiting or interacting with sites they don't -intend to. Here are some of the things we're currently working on: - -* [HTTP Strict Transport Security (HSTS)](/hsts) adoption and - pre-loading -* Developing a standard for [SSL certificate public key - pinning](https://www.imperialviolet.org/2011/05/04/pinning.html) -* SSL evangelism, support, and other odds n' ends (e.g. ["got TLS?" - tech - talk](https://docs.google.com/presentation/d/1G1286W5_VdsBBJo9PjQ6uN78djFupO-Bn4RUlFu3Tng/edit), - [blocking HTTP basic - auth](http://blog.chromium.org/2011/06/new-chromium-security-features-june.html)) -* Making the warning more understandable - -Read more about TLS support in Chromium on [our TLS education -page](/Home/chromium-security/education/tls). - -## **Presenting Origins** - -The fundamental security boundary on the web is the -*[origin](https://code.google.com/p/browsersec/wiki/Part2)*, defined as the -tuple (*scheme*, *hostname*, *port*). For example, (https, www.example.com, -443). We must surface this boundary to people during browsing, in -permissions/capabilities dialogs, and so on, so that they can know whom they are -talking to. In particular, it is important to note that unauthenticated origins -(e.g. (http, www.example.com, 80)) are entirely observable and malleable by -attackers who can control the network (often, even just a little bit of control -is enough). - -Because people (including developers!) tend not to understand the concept of the -origin, but do tend to understand the concept of the hostname, we'd like to -simplify origin names when we can. Ideally we could reduce the origin name to -just the much more understandable hostname. For example, we could elide the -scheme or replace it with a meaningful icon, if doing so did not prevent people -from understanding whether or not an origin is authenticated. And if the port is -the default port for the given scheme, we can elide it, too. - -If the feature or behavior we are trying to protect is available *only* on -authenticated origins — which we strongly suggest — you could leave off the -scheme or the icon. Otherwise, it might be better to highlight the -non-authenticated nature of the origin when presenting it. - -In addition, we strongly recommend that UIs clearly mark unauthenticated origins -as such. - -A good utility function to use for presenting URLs in security decision contexts -is url_formatter::FormatUrlForSecurityDisplay. - -### Eliding Origin Names And Hostnames - -[<img alt="image" src="/Home/chromium-security/enamel/origins.png" height=240 -width=320>](/Home/chromium-security/enamel/origins.png) - -The effective top-level domain (eTLD) of a hostname is the TLD as found in the -[Public Suffix List](https://publicsuffix.org/) (PSL), which is not necessarily -guaranteed to be a single label like "com". Some eTLDs found in the PSL have -more than one label, e.g. .co.jp, and others are the names of web sites that -give out subdomains for user content and code from many sources, like -.appspot.com and .github.io. For many purposes, these multi-label names are -effectively TLDs, hence the name. - -At a minimum, we would like to show users the eTLD + 1 label, e.g. -pumpkins.co.jp, google.com, noodles.appspot.com, or example.org. Where possible, -it is best to show the entire hostname, however. If the hostname is too long, -and/or if it has too many labels underneath the eTLD, that may be a sign that it -is a phishing host. - -Although domain name labels are limited to 63 octets and the entire name is -limited to 255 octets (see <https://www.ietf.org/rfc/rfc1035.txt>, section -2.3.4), on small screens or small windows on large screens, even eTLD + 1 might -be too long. In such a case, we should elide from the left. for example, -www.reallyannoying.goats.example.com should display as "...oats.example.com" -instead of "www.reallyanno...". - -## Permissions - -The browser grants privileges to apps, extensions, and websites after asking the -person for permission. In some cases, the browser also uses status indicators to -indicate when an origin is accessing a granted permission. We currently don’t -have quantitative data on how well these pieces of UI work, but we have -anecdotal evidence suggesting they fail to capture people's attention and/or -explain the situation. Thus, they aren't being totally effective at achieving -their original purpose. This is what we're doing to improve things: - -* Creating experiments and collecting data to quantify how effective - Chrome's permissions systems are -* Designing new types of analyses to measure the threat of extensions, - apps, and websites -* Designing new ways to communicate permission information to end - users - -[Goals For The Origin Info -Bubble](/Home/chromium-security/enamel/goals-for-the-origin-info-bubble) -discusses a way to make permissions easier for people to manage. - -## **Usability Measurement Tools** - -Calculate the effective contrast ratio of text on its background: -<http://webaim.org/resources/contrastchecker/> - -Another contrast checking tool: [Contraster](https://gh.ada.is/contrast-widget/) - -Flesch-Kincaid (and other) readability calculator: -<http://www.readability-score.com/> - -Simulate the effects of colorblindness: -<http://www.etre.com/tools/colourblindsimulator/> and -<http://www.color-blindness.com/coblis-color-blindness-simulator/> - -## **Documents** - -* [Chrome Security UX (Enamel) Public - Folder](https://drive.google.com/open?id=0B6FmQe6bc6yVZ012REktU09NOEE&authuser=0) - * [Chrome Security - UI](https://docs.google.com/a/chromium.org/document/d/11-SXwzCGBlk8q1cNtb7peZjb2UjRPrKSFhOfZhTOz24/edit) -* [Security guidelines for Chrome Extension & App API - developers](https://docs.google.com/document/d/1RamP4-HJ7GAJY3yv2ju2cK50K9GhOsydJN6KIO81das/pub) - -If you are a Googler, you can access the folder of Google-internal Enamel -documents at [go/enamel-folder](https://goto.google.com/enamel-folder) (using -your corp account).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/enamel/origins.png.sha1 b/chromium/docs/website/site/Home/chromium-security/enamel/origins.png.sha1 deleted file mode 100644 index d2c870d728e..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/enamel/origins.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -7692aba020ce591208f1a2a49ea45055a0af601b
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/enamel/permissions/index.md b/chromium/docs/website/site/Home/chromium-security/enamel/permissions/index.md deleted file mode 100644 index 5c3735f75d8..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/enamel/permissions/index.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/enamel - - Security UX -page_name: permissions -title: Permissions ---- - -## Testing New Permissions - -It's important to test new permissions adequately to ensure they behave as -expected and regressions are caught. Features that have permissions tend to be -privacy or security sensitive and if there are circumstances where a malicious -website can access the feature without adequate user approval it can have a -particularly negative impact. Please see [Testing New -Permissions](https://docs.google.com/a/chromium.org/document/d/1daQk9A05T0BcSMO9KQQN8x0TdT2a23KqAkS7maIUJT0/edit?usp=drive_web) -for important test cases to consider when adding new permissions.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/enamel/restricting-iframe-permissions/index.md b/chromium/docs/website/site/Home/chromium-security/enamel/restricting-iframe-permissions/index.md deleted file mode 100644 index a50a0e6cf92..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/enamel/restricting-iframe-permissions/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/enamel - - Security UX -page_name: restricting-iframe-permissions -title: Restricting IFrame Permissions ---- - diff --git a/chromium/docs/website/site/Home/chromium-security/extension-content-script-fetches/index.md b/chromium/docs/website/site/Home/chromium-security/extension-content-script-fetches/index.md deleted file mode 100644 index 20d0bf4327e..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/extension-content-script-fetches/index.md +++ /dev/null @@ -1,352 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: extension-content-script-fetches -title: Changes to Cross-Origin Requests in Chrome Extension Content Scripts ---- - -*tl;dr: To improve security, cross-origin fetches will soon be disallowed from -content scripts in Chrome Extensions. Such requests can be made from extension -background pages instead, and relayed to content scripts when needed. **\[The -document has been edited on 2020-09-17 to reflect that CORS-for-content-scripts -has successfully launched in Chrome 85****.\]*** - -## Overview - -When web pages request cross-origin data with -[fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) or -[XHR](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) APIs, the -response is denied unless -[CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) headers allow it. -In contrast, extension content scripts have traditionally been able to [fetch -cross-origin data](https://developer.chrome.com/apps/xhr) from any origins -listed in their extension's -[permissions](https://developer.chrome.com/extensions/declare_permissions), -regardless of the origin that the content script is running within. As part of a -broader [Extension Manifest -V3](https://docs.google.com/document/d/1nPu6Wy4LWR66EFLeYInl3NzzhHzc-qnk4w4PX-0XMw8/edit?usp=sharing) -effort to improve extension security, privacy, and performance, these -cross-origin requests in content scripts will soon be disallowed. Instead, -content scripts will be subject to the same request rules as the page they are -running within. Extension pages, such as background pages, popups, or options -pages, are unaffected by this change and will continue to be allowed to bypass -CORS for cross-origin requests as they do today. - -Our data shows that most extensions will not be affected by this change. -However, any content scripts that do need to make cross-origin requests can do -so via an extension background page, which can relay the data to the content -script. We have a migration plan below to help affected extension developers -make the transition to the new model. - -## Problems with Cross-Origin Requests - -To prevent leaks of sensitive information, web pages are generally not allowed -to fetch cross-origin data. Unless a valid CORS header is present on the -response, the page's request will fail with an error like: - -> Access to fetch at 'https://another-site.com/' from origin -> 'https://example.com' has been blocked by CORS policy: No -> 'Access-Control-Allow-Origin' header is present on the requested resource. If -> an opaque response serves your needs, set the request's mode to 'no-cors' to -> fetch the resource with CORS disabled. - -Chrome has recently launched a new security feature called [Site -Isolation](https://developers.google.com/web/updates/2018/07/site-isolation) -which enforces this type of restriction in a more secure way. Specifically, Site -Isolation not only blocks the response, but prevents the data from ever being -delivered to the Chrome renderer process containing the web page, using a -feature called [Cross-Origin Read -Blocking](https://developers.google.com/web/updates/2018/07/site-isolation#corb) -(CORB). This helps prevent the data from leaking even if a malicious web page -were to attack a security bug in Chrome's renderer process, or if it tried to -access the data in its process with a [Spectre -attack](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html). - -Content scripts pose a challenge for Site Isolation, because they run in the -same Chrome renderer process as the web page they operate on. This means that -the renderer process must be allowed to fetch data from any origin for which the -extension has permissions, which in many cases is *all* origins. In such cases, -Site Isolation would have less effectiveness when content scripts are present, -because a compromised renderer process could hijack the content scripts and -request (and thus leak) any data from the origins listed in the extension. -(Thankfully, this is not a problem for Spectre attacks, which cannot take -control of content scripts. It is a problem if an attacker can exploit a -security bug in Chrome's renderer process, though, allowing the attacker to -issue arbitrary requests as if they came from the content script.) - -To mitigate these concerns, future versions of Chrome will limit content scripts -to the same fetches that the page itself can perform. Content scripts can -instead ask their background pages to fetch data from other origins on their -behalf, where the request can be made from an extension process rather than a -more easily exploitable renderer process. - -## Planned Restrictions - -As described above, content scripts will lose the ability to fetch cross-origin -data from origins in their extension's permissions, and they will only be able -to fetch data that the underlying page itself has access to. To fetch additional -data, content scripts can send messages to their extension's background pages, -which can relay data from sources that the extension author expects. - -This transition will occur in stages, to try to minimize disruption to extension -developers. - -Stage #1: Remove ability to bypass CORB from content scripts - -**In Q1 2019**, Chrome removed the ability to make cross-origin requests in -content scripts for new and previously unaffected extensions, while maintaining -an "allowlist" of affected extensions that may continue to make such requests -for the time being. This change started in Chrome 73. - -We continue to work with developers of extensions on the allowlist to migrate to -the new method of requesting cross-origin data, to help them prepare for -Extension Manifest V3. We remove such extensions from the allowlist as they -migrate, helping to improve the security of Chrome and the effectiveness of Site -Isolation against advanced attackers. - -Stage #2: Remove ability to bypass CORS from content scripts **\[edited on -2020-09-17\]** - -In **Q2 2020**, Chrome removed the ability to bypass CORS in cross-origin -requests from content scripts, subject to the same “allowlist” as above. This -change started in Chrome 85. - -The changes means that cross-origin fetches initiated from content scripts will -have an Origin request header with the page's origin, and the server has a -chance to approve the request with a matching Access-Control-Allow-Origin -response header. - -Extensions that were previously added to the “allowlist” will be unaffected by -the changes in Chrome 85. However, the new CORS behavior for content scripts may -actually make it easier for some extensions to move off of the allowlist, if -their fetches would now be approved by the server with an -Access-Control-Allow-Origin response header. We know this is the case for -several extensions that were included on the allowlist. - -Stage #3: Deprecating and removing the “allowlist” **\[edited on 2020-09-17\]** - -\[edited on 2020-05-28\] **In October 2020**, we will publish the allowlist of -extensions, to inform users of the security risks of using any extensions still -on the list. We hope to shrink the list as quickly as possible, because using -these extensions will weaken Chrome's defenses against cross-site attacks. -Before publishing or deprecating the allowlist, we'll send an advance notice to -the -[chromium-extensions@](https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions) -discussion list. - -\[added on 2020-09-17\] In Chrome 87 we have deprecated and removed the -CORB/CORS allowlist. According to [the Chrome -dashboard](https://chromiumdash.appspot.com/schedule), this Chrome release is -tentatively planned to ship to the Beta channel around October 15th 2020 and to -the Stable channel around November 17th 2020. Extensions that haven’t migrated -to the new security model may be broken in Chrome 87 and above. - -## Recommended Developer Actions - -To prepare for Extension Manifest V3 and avoid being on the allowlist of -extensions that pose a cross-site security risk, we recommend that affected -extension developers take the following actions: - -### 1. Determine if Your Extension is Affected \[edited on 2020-03-09\] - -You can test whether your extension is affected by the planned CORB and CORS -changes by running Chrome 81 or later (starting with version 81.0.4035.0) with -the following [command line flags](/developers/how-tos/run-chromium-with-flags) -to enable the planned behavior: - -> --force-empty-corb-allowlist -> --enable-features=OutOfBlinkCors,CorbAllowlistAlsoAppliesToOorCors - -Alternatively (starting with version 85.0.4175.0) opt into the changes by -setting chrome://flags/#cors-for-content-scripts to “Enabled” and -chrome://flags/#force-empty-CORB-and-CORS-allowlist to “Enabled”: - -> [<img alt="image" -> src="https://drive.google.com/uc?id=1xPpHGMmjgMOYDEZH1U02XvAxDHDPMwoc&export=download">](https://drive.google.com/file/d/1xPpHGMmjgMOYDEZH1U02XvAxDHDPMwoc/view?usp=drive_web) - -If your extension makes cross-origin fetches from content scripts, then your -extension may be broken and you may observe one of the following errors in the -DevTools console: - -> Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> -> with MIME type <type>. See -> https://www.chromestatus.com/feature/5629709824032768 for more details. - -**\[added on 2020-03-09\]**: - -> Access to fetch at 'https://another-site.com/' from origin -> 'https://example.com' has been blocked by CORS policy: No -> 'Access-Control-Allow-Origin' header is present on the requested resource. If -> an opaque response serves your needs, set the request's mode to 'no-cors' to -> fetch the resource with CORS disabled. - -If you see the errors above, you can verify whether the changes described on -this page are the cause by temporarily disabling the planned behavior. (It is -possible that the errors might appear for other reasons.) To test with the -planned behavior disabled, run Chrome 81 or later (starting with version -81.0.4035.0) with the following [command line -flags](/developers/how-tos/run-chromium-with-flags): - -> --disable-features=CorbAllowlistAlsoAppliesToOorCors -> --enable-features=OutOfBlinkCors - -### 2. Avoid Cross-Origin Fetches in Content Scripts - -When cross-origin fetches are needed and the server does not provide an -Access-Control-Allow-Origin response header for the page's origin, perform them -from the [extension background -page](https://developer.chrome.com/extensions/background_pages) rather than in -the content script. Relay the response to the content scripts as needed (e.g., -using [extension messaging -APIs](https://developer.chrome.com/extensions/messaging)). For example: - -> **Old content script, making a cross-origin fetch:** - -> > var itemId = 12345; - -> > var url = "https://another-site.com/price-query?itemId=" + - -> > encodeURIComponent(request.itemId); - -> > fetch(url) - -> > .then(response => response.text()) - -> > .then(text => parsePrice(text)) - -> > .then(price => ...) - -> > .catch(error => ...) - -> **New content script, asking its background page to fetch the data instead:** - -> > chrome.runtime.sendMessage( - -> > {contentScriptQuery: "queryPrice", itemId: 12345}, - -> > price => ...); - -> **New extension background page, fetching from a known URL and relaying -> data:** - -> > chrome.runtime.onMessage.addListener( - -> > function(request, sender, sendResponse) { - -> > if (request.contentScriptQuery == "queryPrice") { - -> > var url = "https://another-site.com/price-query?itemId=" + - -> > encodeURIComponent(request.itemId); - -> > fetch(url) - -> > .then(response => response.text()) - -> > .then(text => parsePrice(text)) - -> > .then(price => sendResponse(price)) - -> > .catch(error => ...) - -> > return true; // Will respond asynchronously. - -> > } - -> > }); - -### 3. Limit Cross-Origin Requests in Background Pages - -If an extension's background page simply fetches and relays *any* URL of a -content script's choice (effectively acting as an open proxy), then similar -security problems occur. That is, a compromised renderer process can hijack the -content script and ask the background page to fetch and relay sensitive URLs of -the attacker's choosing. Instead, background pages should only fetch data from -URLs the extension author intends, which is ideally a small set of URLs which -does not put the user's sensitive data at risk. - -> **Good message example:** - -> { - -> contentScriptQuery: "queryPrice", - -> itemId: 12345 - -> } - -> This approach limits which URLs can fetched in response to the message. Here, -> only the itemId is provided by the content script that is sending the message, -> and not the full URL. - -> **Bad message example:** - -> { - -> contentScriptQuery: "fetchUrl", - -> url: "https://example.com/any/path/or/site/allowed/here" - -> } - -> In this approach the content script may cause the background page to fetch any -> URL. A malicious website may be able to forge such messages and trick the -> extension to get access to any cross-origin resources. - -### 4. Keep in Touch if Needed \[edited on 2020-05-28\] - -We have reached out to developers whose extensions are on the allowlist. - -If your extension is on the allowlist and no longer needs to be, please [**file -a bug -here**](https://bugs.chromium.org/p/chromium/issues/entry?template=Defect+report+from+user&components=Internals%3ESandbox%3ESiteIsolation&blocking=846346&cc=lukasza@chromium.org&summary=Remove+extension+%3Cextension+id%3E+from+the+CORB+allowlist) -to have it removed. You may verify that your extension no longer needs to be on -the allowlist by testing that it continues to work after launching Chrome -81.0.4035.0 or higher with the following [command line -flags](/developers/how-tos/run-chromium-with-flags): - -> --force-empty-corb-allowlist -> --enable-features=OutOfBlinkCors,CorbAllowlistAlsoAppliesToOorCors - -Alternatively (starting with version 85.0.4175.0) opt into the changes by -setting chrome://flags/#cors-for-content-scripts to “Enabled” and -chrome://flags/#force-empty-CORB-and-CORS-allowlist to “Enabled”: - -> [<img alt="image" -> src="https://drive.google.com/uc?id=1xPpHGMmjgMOYDEZH1U02XvAxDHDPMwoc&export=download">](https://drive.google.com/file/d/1xPpHGMmjgMOYDEZH1U02XvAxDHDPMwoc/view?usp=drive_web) - -If your extension is not yet on the allowlist and still depends on cross-origin -requests, these requests may stop working and you may observe the following -errors in the DevTools console: - -> Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> -> with MIME type <type>. See -> https://www.chromestatus.com/feature/5629709824032768 for more details. - -or **\[added on 2020-03-09\]**: - -> Access to fetch at 'https://another-site.com/' from origin -> 'https://example.com' has been blocked by CORS policy: No -> 'Access-Control-Allow-Origin' header is present on the requested resource. If -> an opaque response serves your needs, set the request's mode to 'no-cors' to -> fetch the resource with CORS disabled. - -If this happens, please update your extension as described above. - -\[edited on 2019-09-21\] Under exceptional circumstances, we may still consider -adding an extension to the allowlist, but we're now generally avoiding this when -possible, because users of allowlisted extensions are vulnerable to additional -security attacks. To report issues encountered during the Chrome 87 deprecation -of the allowlist, please [open a Chromium -bug](https://bugs.chromium.org/p/chromium/issues/entry?template=Defect+report+from+user&components=Internals%3ESandbox%3ESiteIsolation&blocking=846346&cc=lukasza@chromium.org&summary=CORB/CORS+allowlist+deprecation+in+Chrome+87). - -## Summary - -Removing cross-origin fetches from content scripts is an important step in -improving the security of Chrome, since it helps prevent leaks of sensitive data -even when Chrome's renderer process might be compromised. We apologize for the -inconvenience of the migration, but we appreciate your help in keeping Chrome's -users as secure as possible.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/guts/Chrome Security Architecture.png.sha1 b/chromium/docs/website/site/Home/chromium-security/guts/Chrome Security Architecture.png.sha1 deleted file mode 100644 index e6fdca50629..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/guts/Chrome Security Architecture.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -91c1746bc3bfb37095dd5910b56e1235ad155051
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/guts/index.md b/chromium/docs/website/site/Home/chromium-security/guts/index.md deleted file mode 100644 index 0a720c54aeb..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/guts/index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: guts -title: Secure Architecture ---- - -One of our [core security principles](/Home/chromium-security/core-principles) -is, "Design for defense in depth." Some of the things we've done or are working -on to live up to this principle include: - -## Background - -* <http://seclab.stanford.edu/websec/chromium/> -* [A color-by-risk component diagram of - Chrome](https://docs.google.com/a/chromium.org/drawings/d/1TuECFL9K7J5q5UePJLC-YH3satvb1RrjLRH-tW_VKeE/edit) - -## Sandboxing - -### Platform-specific sandboxing - -* [Chrome on Windows (sandbox) design and - implementation](/developers/design-documents/sandbox) and the - [Sandboxing FAQ (mostly Windows - specific](/developers/design-documents/sandbox/Sandbox-FAQ)) -* [Chrome on Linux and Chrome OS (sandbox) - overview](https://code.google.com/p/chromium/wiki/LinuxSandboxing) - (including the most current [seccomp-bpf - layer](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html)) - * [bpf_dsl - presentation](https://drive.google.com/file/d/0B9LSc_-kpOQPVHhvcVBza3NWR0k/view?usp=sharing) - (Sep 2014) -* [Chrome on OSX (sandbox) - overview](/developers/design-documents/sandbox/osx-sandboxing-design) - and the [second-layer bootstrap - sandbox](https://docs.google.com/a/chromium.org/document/d/108sr6gBxqdrnzVPsb_4_JbDyW1V4-DRQUC4R8YvM40M/edit#) - -### Plugin sandboxing - -* [Flash sandboxing - (PPAPI)](http://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html) - -### Site Isolation - -We're currently working on using Chrome's sandbox to isolate websites from each -other via the [Site Isolation project](/Home/chromium-security/site-isolation), -which will help to mitigate cross-site information leaks (among other threats) -in the presence of a vulnerability in the renderer process. - -## Anti-Exploitation Technologies and Tactics - -* We use industry best practices - [ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization), - [DEP](http://en.wikipedia.org/wiki/Data_Execution_Prevention), [JIT - hardening](http://www.matasano.com/research/Attacking_Clientside_JIT_Compilers_Paper.pdf#page=24), - and - [SafeSEH](http://msdn.microsoft.com/en-us/library/9a89h429.aspx). -* We block [out-of-date or unpopular - plugins](http://support.google.com/chrome/bin/answer.py?hl=en&answer=1181003) - by default and support work toward [NPAPI - deprecation](http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html). -* We implement memory hardening features, like [Binding - Integrity](/Home/chromium-security/binding-integrity).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/hall-of-fame/index.md b/chromium/docs/website/site/Home/chromium-security/hall-of-fame/index.md deleted file mode 100644 index 238536e7d1c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/hall-of-fame/index.md +++ /dev/null @@ -1,1157 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: hall-of-fame -title: Security Hall of Fame ---- - -## The following bugs qualified for a Chromium Security Reward, or represent a win at our Pwnium competition. On behalf of our millions of users, we thank the named researchers for helping make Chromium safer. - -**This information is historical and isn't being updated**. - -* $60000 to Sergey Glazunov for [bug - 117226](http://code.google.com/p/chromium/issues/detail?id=117226) -* $60000 to PinkiePie for [bug - 117620](http://code.google.com/p/chromium/issues/detail?id=117620) -* $40000 to PinkiePie for [bug - 181083](http://code.google.com/p/chromium/issues/detail?id=181083) - and others -* $31336 to Ralf-Philipp Weinmann for [bug 227181](http://code.google.com/p/chromium/issues/detail?id=227181) and others -* $30000 to someone who wishes to remain anonymous -* $30000 to someone who wishes to remain anonymous -* $21500 to Andrey Labunets for [bug 252062](http://code.google.com/p/chromium/issues/detail?id=252062) and others -* $10000 to miaubiz for [bug - 116661](http://code.google.com/p/chromium/issues/detail?id=116661) -* $10000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 116662](http://code.google.com/p/chromium/issues/detail?id=116662) -* $10000 to Arthur Gerkis for [bug - 116663](http://code.google.com/p/chromium/issues/detail?id=116663) -* $10000 to Sergey Glazunov for [bug - 143439](http://code.google.com/p/chromium/issues/detail?id=143439) -* $10000 to miaubiz for [bug - 157047](http://code.google.com/p/chromium/issues/detail?id=157047) -* $10000 to Atte Kettunen for [bug - 157048](http://code.google.com/p/chromium/issues/detail?id=157048) -* $10000 to Christian Holler for [bug - 157049](http://code.google.com/p/chromium/issues/detail?id=157049) -* $7331 to PinkiePie for [bug - 162835](http://code.google.com/p/chromium/issues/detail?id=162835) -* $5000 to João Lucas Melo Brasio from [White Hat Hackers Consultoria - de Segurança da Informação LTDA](http://www.whitehathackers.com.br/) - for [bug - 321940](http://code.google.com/p/chromium/issues/detail?id=321940) - and others -* $4000 + $500 to Sergey Glazunov for [bug - 143437](http://code.google.com/p/chromium/issues/detail?id=143437) -* $3133.7 to Atte Kettunen for bug 179522 -* $3133.7 to Atte Kettunen for bug 147499 -* $3133.7 to Collin Payne for [bug - 242762](https://code.google.com/p/chromium/issues/detail?id=242762) -* $3133.7 to Collin Payne for [bug - 244746](https://code.google.com/p/chromium/issues/detail?id=244746) -* $3133.7 to Sergey Glazunov for [bug - 68666](http://code.google.com/p/chromium/issues/detail?id=68666) -* $3133.7 to Sergey Glazunov for [bug - 83275](http://code.google.com/p/chromium/issues/detail?id=83275) -* $3133.7 to miaubiz for [bug - 88944](http://code.google.com/p/chromium/issues/detail?id=88944) -* $3133.7 to Chamal de Silva for [bug - 107182](http://code.google.com/p/chromium/issues/detail?id=107182) -* $3133.7 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 108071](http://code.google.com/p/chromium/issues/detail?id=108071) -* $3133.7 to Arthur Gerkis for [bug - 128178](http://code.google.com/p/chromium/issues/detail?id=128178) -* $3133.7 to Arthur Gerkis for [bug - 135043](http://code.google.com/p/chromium/issues/detail?id=135043) -* $3133.7 to miaubiz for [bug - 141901](http://code.google.com/p/chromium/issues/detail?id=141901) -* $2000 + $500 to Sergey Glazunov for [bug - 98053](http://code.google.com/p/chromium/issues/detail?id=98053) -* $2000 + $500 to Sergey Glazunov for [bug - 99512](http://code.google.com/p/chromium/issues/detail?id=99512) -* $2000 + $500 to Sergey Glazunov for [bug - 99750](http://code.google.com/p/chromium/issues/detail?id=99750) -* $2337 to Sergey Glazunov for [bug - 93906](http://code.google.com/p/chromium/issues/detail?id=93906) -* $2337 to Sergey Glazunov for [bug - 96047](http://code.google.com/p/chromium/issues/detail?id=96047) -* $2337 to Sergey Glazunov for [bug - 96885](http://code.google.com/p/chromium/issues/detail?id=96885) -* $2000 to Atte Kettunen for bug 279277 -* $2000 to Atte Kettunen for bug 265838 -* $2000 to Sergey Glazunov for [bug - 93416](http://code.google.com/p/chromium/issues/detail?id=93416) -* $2000 to Sergey Glazunov for [bug - 95671](http://code.google.com/p/chromium/issues/detail?id=95671) -* $2000 to Daniel Divricean for [bug - 93416](http://code.google.com/p/chromium/issues/detail?id=93416) -* $2000 to Sergey Glazunov for [bug - 117550](http://code.google.com/p/chromium/issues/detail?id=117550) -* $2000 to Chamal de Silva for [bug - 139814](http://code.google.com/p/chromium/issues/detail?id=139814) -* $2000 to Christian Schneider for [bug - 380885](https://bugs.chromium.org/p/chromium/issues/detail?id=380885) - ([writeup](https://christian-schneider.net/ChromeSopBypassWithSvg.html#main)) -* $1500 to Atte Kettunen for bug 150729 -* $1337 to Sergey Glazunov for [bug - 35724](http://code.google.com/p/chromium/issues/detail?id=35724) -* $1337 to Sergey Glazunov for [bug - 45400](http://code.google.com/p/chromium/issues/detail?id=45400) -* $1337 to Sergey Glazunov for [bug - 50553](http://code.google.com/p/chromium/issues/detail?id=50553) -* $1337 to Keith Campbell for [bug - 51630](http://code.google.com/p/chromium/issues/detail?id=51630) -* $1337 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 59036](http://code.google.com/p/chromium/issues/detail?id=59036) -* $1337 to Sergey Glazunov for [bug - 65764](http://code.google.com/p/chromium/issues/detail?id=65764) -* $1337 to Sergey Glazunov for [bug - 70165](http://code.google.com/p/chromium/issues/detail?id=70165) -* $1337 to Daniel Divricean for [bug - 69187](http://code.google.com/p/chromium/issues/detail?id=69187) -* $1337 to Daniel Divricean for [bug - 70877](http://code.google.com/p/chromium/issues/detail?id=70877) -* $1337 to Vincenzo Iozzo, Ralf Philipp Weinmann and Willem Pinckaers, - through ZDI, for [bug - 75712](http://code.google.com/p/chromium/issues/detail?id=75712) -* $1337 to kuzzcc for [bug - 77026](http://code.google.com/p/chromium/issues/detail?id=77026) -* $1337 to Michael Braithwaite of Turbulenz Limited for [bug - 89836](http://code.google.com/p/chromium/issues/detail?id=89836) -* $1337 to miaubiz for [bug - 100059](http://code.google.com/p/chromium/issues/detail?id=100059) -* $1000 + $1000 to Sergey Glazunov for [bug - 73196](http://code.google.com/p/chromium/issues/detail?id=73196) -* $1000 + $1000 to Sergey Glazunov for [bug - 73595](http://code.google.com/p/chromium/issues/detail?id=73595) -* $1000 + $1000 to Sergey Glazunov for [bug - 74991](http://code.google.com/p/chromium/issues/detail?id=74991) -* $1000 + $1000 to Sergey Glazunov for [bug - 77463](http://code.google.com/p/chromium/issues/detail?id=77463) -* $1000 + $500 to Sergey Glazunov for [bug - 73746](http://code.google.com/p/chromium/issues/detail?id=73746) -* $1000 + $500 to Sergey Glazunov for [bug - 74562](http://code.google.com/p/chromium/issues/detail?id=74562) -* $1000 + $500 to Sergey Glazunov for [bug - 75170](http://code.google.com/p/chromium/issues/detail?id=75170) -* $1000 + $500 to Sergey Glazunov for [bug - 79199](http://code.google.com/p/chromium/issues/detail?id=79199) -* $1000 + $500 to Sergey Glazunov for [bug - 89520](http://code.google.com/p/chromium/issues/detail?id=89520) -* $1000 + $500 to Sergey Glazunov for [bug - 90222](http://code.google.com/p/chromium/issues/detail?id=90222) -* $1000 + $500 to Sergey Glazunov for [bug - 91598](http://code.google.com/p/chromium/issues/detail?id=91598) -* $1000 + $500 to Sergey Glazunov for [bug - 97451](http://code.google.com/p/chromium/issues/detail?id=97451) -* $1000 + $500 to Sergey Glazunov for [bug - 97520](http://code.google.com/p/chromium/issues/detail?id=97520) -* $1000 + $500 to Sergey Glazunov for [bug - 97615](http://code.google.com/p/chromium/issues/detail?id=97615) -* $1000 + $500 to Sergey Glazunov for [bug - 97784](http://code.google.com/p/chromium/issues/detail?id=97784) -* $1000 + $500 to Sergey Glazunov for [bug - 98407](http://code.google.com/p/chromium/issues/detail?id=98407) -* $1000 + $500 to Chamal de Silva for [bug - 171951](https://code.google.com/p/chromium/issues/detail?id=171951) -* $1000 to Atte Kettunen for bug 235733 -* $1000 to Atte Kettunen for bug 292422 -* $1000 to Atte Kettunen for bug 271939 -* $1000 to Atte Kettunen for bug 223238 -* $1000 to Atte Kettunen for bug 172926 -* $1000 to Atte Kettunen for bug 172342 -* $1000 to Atte Kettunen for bug 172331 -* $1000 to Atte Kettunen for bug 172243 -* $1000 to Atte Kettunen for bug 168768 -* $1000 to Atte Kettunen for bug 162551 -* $1000 to Atte Kettunen for bug 162494 -* $1000 to Atte Kettunen for bug 161077 -* $1000 to Atte Kettunen for bug 159338 -* $1000 to Atte Kettunen for bug 156231 -* $1000 to Atte Kettunen for bug 154055 -* $1000 to Atte Kettunen for bug 152707 -* $1000 to Atte Kettunen for bug 151008 -* $1000 to Atte Kettunen for bug 138208 -* $1000 to Atte Kettunen for bug 133571 -* $1000 to Atte Kettunen for bug 133214 -* $1000 to Atte Kettunen for bug 130240 -* $1000 to Tokuji Akamine for [bug - 30660](http://code.google.com/p/chromium/issues/detail?id=30660) -* $1000 to kuzzcc for [bug - 37383](http://code.google.com/p/chromium/issues/detail?id=37383) -* $1000 to Jordi Chancel for [bug - 40445](http://code.google.com/p/chromium/issues/detail?id=40445) -* $1000 to Sergey Glazunov for [bug - 39985](http://code.google.com/p/chromium/issues/detail?id=39985) -* $1000 to Sergey Glazunov for [bug - 39047](http://code.google.com/p/chromium/issues/detail?id=39047) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 45983](http://code.google.com/p/chromium/issues/detail?id=45983) -* $1000 to Mike Taylor for [bug - 49964](http://code.google.com/p/chromium/issues/detail?id=49964) -* $1000 to Sergey Glazunov for [bug - 50515](http://code.google.com/p/chromium/issues/detail?id=50515) -* $1000 to Sergey Glazunov for [bug - 51835](http://code.google.com/p/chromium/issues/detail?id=51835) -* $1000 to kuzzcc for [bug - 51654](http://code.google.com/p/chromium/issues/detail?id=51654) -* $1000 to kuzzcc for [bug - 51670](http://code.google.com/p/chromium/issues/detail?id=51670) -* $1000 to Sergey Glazunov for [bug - 48437](http://code.google.com/p/chromium/issues/detail?id=48437) -* $1000 to kuzzcc for [bug - 52204](http://code.google.com/p/chromium/issues/detail?id=52204) -* $1000 to Sergey Glazunov for [bug - 50386](http://code.google.com/p/chromium/issues/detail?id=50386) -* $1000 to Ashutosh Mehra and Vineet Batra of the Adobe Reader Sandbox - Team for [bug - 52682](http://code.google.com/p/chromium/issues/detail?id=52682) -* $1000 to kuzzcc for [bug - 50712](http://code.google.com/p/chromium/issues/detail?id=50712) -* $1000 to Stefano Di Paola of MindedSecurity for [bug - 55350](http://code.google.com/p/chromium/issues/detail?id=55350) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 54691](http://code.google.com/p/chromium/issues/detail?id=54691) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 56760](http://code.google.com/p/chromium/issues/detail?id=56760) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 61338](http://code.google.com/p/chromium/issues/detail?id=61338) -* $1000 to wushi of team509 for [bug - 55257](http://code.google.com/p/chromium/issues/detail?id=55257) -* $1000 to kuzzcc for [bug - 58657](http://code.google.com/p/chromium/issues/detail?id=58657) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 59320](http://code.google.com/p/chromium/issues/detail?id=59320) -* $1000 to Christoph Diehl for [bug - 60055](http://code.google.com/p/chromium/issues/detail?id=60055) -* $1000 to wushi of team509 for [bug - 60688](http://code.google.com/p/chromium/issues/detail?id=60688) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 62623](http://code.google.com/p/chromium/issues/detail?id=62623) -* $1000 to miaubiz for [bug - 62127](http://code.google.com/p/chromium/issues/detail?id=62127) -* $1000 to Sławomir Błażek for [bug - 62401](http://code.google.com/p/chromium/issues/detail?id=62401) -* $1000 to Chris Rohlf for [bug - 63866](http://code.google.com/p/chromium/issues/detail?id=63866) -* $1000 to Sergey Glazunov for [bug - 64959](http://code.google.com/p/chromium/issues/detail?id=64959) -* $1000 to Sławomir Błażek for [bug - 64945](http://code.google.com/p/chromium/issues/detail?id=64945) -* $1000 to Sergey Glazunov for [bug - 66560](http://code.google.com/p/chromium/issues/detail?id=66560) -* $1000 to Jared Allar of [CERT](http://www.cert.org/) for [bug - 67208](http://code.google.com/p/chromium/issues/detail?id=67208) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 67303](http://code.google.com/p/chromium/issues/detail?id=67303) -* $1000 to kuzzcc for [bug - 67393](http://code.google.com/p/chromium/issues/detail?id=67393) -* $1000 to David Warren of [CERT](http://www.cert.org/) for [bug - 68115](http://code.google.com/p/chromium/issues/detail?id=68115) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 68170](http://code.google.com/p/chromium/issues/detail?id=68170) -* $1000 to Sergey Glazunov for [bug - 68178](http://code.google.com/p/chromium/issues/detail?id=68178) -* $1000 to Sergey Glazunov for [bug - 68181](http://code.google.com/p/chromium/issues/detail?id=68181) -* $1000 to Martin Barbella for [bug - 68439](http://code.google.com/p/chromium/issues/detail?id=68439) -* $1000 to Sergey Glazunov for [bug - 68558](http://code.google.com/p/chromium/issues/detail?id=68558) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 63248](http://code.google.com/p/chromium/issues/detail?id=63248) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 55831](http://code.google.com/p/chromium/issues/detail?id=55831) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 64051](http://code.google.com/p/chromium/issues/detail?id=64051) -* $1000 to Sergey Glazunov for [bug - 65577](http://code.google.com/p/chromium/issues/detail?id=65577) -* $1000 to Sergey Glazunov for [bug - 68641](http://code.google.com/p/chromium/issues/detail?id=68641) -* $1000 to miaubiz for [bug - 68120](http://code.google.com/p/chromium/issues/detail?id=68120) -* $1000 to Martin Barbella for [bug - 69556](http://code.google.com/p/chromium/issues/detail?id=69556) -* $1000 to David Warren of [CERT](http://www.cert.org/) for [bug - 70456](http://code.google.com/p/chromium/issues/detail?id=70456) -* $1000 to Jordi Chancel for [bug - 54262](http://code.google.com/p/chromium/issues/detail?id=54262) -* $1000 to Sergey Glazunov for [bug - 68263](http://code.google.com/p/chromium/issues/detail?id=68263) -* $1000 to Sergey Glazunov for [bug - 68741](http://code.google.com/p/chromium/issues/detail?id=68741) -* $1000 to Sławomir Błażek for [bug - 70244](http://code.google.com/p/chromium/issues/detail?id=70244) -* $1000 to Martin Barbella for [bug - 71114](http://code.google.com/p/chromium/issues/detail?id=71114) -* $1000 to Martin Barbella for [bug - 71115](http://code.google.com/p/chromium/issues/detail?id=71115) -* $1000 to miaubiz for [bug - 71296](http://code.google.com/p/chromium/issues/detail?id=71296) -* $1000 to wushi of team509 for [bug - 71386](http://code.google.com/p/chromium/issues/detail?id=71386) -* $1000 to wushi of team509 for [bug - 71388](http://code.google.com/p/chromium/issues/detail?id=71388) -* $1000 to Sergey Glazunov for [bug - 71595](http://code.google.com/p/chromium/issues/detail?id=71595) -* $1000 to miaubiz for [bug - 71855](http://code.google.com/p/chromium/issues/detail?id=71855) -* $1000 to Chamal de Silva for [bug - 72437](http://code.google.com/p/chromium/issues/detail?id=72437) -* $1000 to Martin Barbella for [bug - 73235](http://code.google.com/p/chromium/issues/detail?id=73235) -* $1000 to Martin Barbella for [bug - 70027](http://code.google.com/p/chromium/issues/detail?id=70027) -* $1000 to Sergey Glazunov for [bug - 70442](http://code.google.com/p/chromium/issues/detail?id=70442) -* $1000 to miaubiz for [bug - 71763](http://code.google.com/p/chromium/issues/detail?id=71763) -* $1000 to Martin Barbella for [bug - 72028](http://code.google.com/p/chromium/issues/detail?id=72028) -* $1000 to Sergey Glazunov for [bug - 73066](http://code.google.com/p/chromium/issues/detail?id=73066) -* $1000 to miaubiz for [bug - 73134](http://code.google.com/p/chromium/issues/detail?id=73134) -* $1000 to Sergey Glazunov for [bug - 74030](http://code.google.com/p/chromium/issues/detail?id=74030) -* $1000 to Christian Holler for [bug - 74662](http://code.google.com/p/chromium/issues/detail?id=74662) -* $1000 to Christian Holler for [bug - 74675](http://code.google.com/p/chromium/issues/detail?id=74675) -* $1000 to Sławomir Błażek for [bug - 73216](http://code.google.com/p/chromium/issues/detail?id=73216) -* $1000 to Christian Holler for [bug - 74660](http://code.google.com/p/chromium/issues/detail?id=74660) -* $1000 to Christian Holler for [bug - 74665](http://code.google.com/p/chromium/issues/detail?id=74665) -* $1000 to Christian Holler for [bug - 74666](http://code.google.com/p/chromium/issues/detail?id=74666) -* $1000 to Christian Holler for [bug - 74669](http://code.google.com/p/chromium/issues/detail?id=74669) -* $1000 to Christian Holler for [bug - 74671](http://code.google.com/p/chromium/issues/detail?id=74671) -* $1000 to Christian Holler for [bug - 74672](http://code.google.com/p/chromium/issues/detail?id=74672) -* $1000 to Christian Holler for [bug - 74673](http://code.google.com/p/chromium/issues/detail?id=74673) -* $1000 to Christian Holler for [bug - 74678](http://code.google.com/p/chromium/issues/detail?id=74678) -* $1000 to Christoph Diehl for [bug - 78524](http://code.google.com/p/chromium/issues/detail?id=78524) -* $1000 to miaubiz for [bug - 73526](http://code.google.com/p/chromium/issues/detail?id=73526) -* $1000 to kuzzcc for [bug - 74653](http://code.google.com/p/chromium/issues/detail?id=74653) -* $1000 to Jose A. Vazquez for [bug - 75186](http://code.google.com/p/chromium/issues/detail?id=75186) -* $1000 to Sergey Glazunov for [bug - 75801](http://code.google.com/p/chromium/issues/detail?id=75801) -* $1000 to Martin Barbella for [bug - 76001](http://code.google.com/p/chromium/issues/detail?id=76001) -* $1000 to kuzzcc for [bug - 76666](http://code.google.com/p/chromium/issues/detail?id=76666) -* $1000 to kuzzcc for [bug - 77507](http://code.google.com/p/chromium/issues/detail?id=77507) -* $1000 to kuzzcc for [bug - 78031](http://code.google.com/p/chromium/issues/detail?id=78031) -* $1000 to miaubiz for [bug - 76966](http://code.google.com/p/chromium/issues/detail?id=76966) -* $1000 to wushi of team509 for [bug - 77130](http://code.google.com/p/chromium/issues/detail?id=77130) -* $1000 to Marek Majkowski for [bug - 77346](http://code.google.com/p/chromium/issues/detail?id=77346) -* $1000 to miaubiz for [bug - 72340](http://code.google.com/p/chromium/issues/detail?id=72340) -* $1000 to miaubiz for [bug - 78071](http://code.google.com/p/chromium/issues/detail?id=78071) -* $1000 to Christian Holler for [bug - 78270](http://code.google.com/p/chromium/issues/detail?id=78270) -* $1000 to Sławomir Błażek for [bug - 76059](http://code.google.com/p/chromium/issues/detail?id=76059) -* $1000 to Martin Barbella for [bug - 72387](http://code.google.com/p/chromium/issues/detail?id=72387) -* $1000 to miaubiz for [bug - 73962](http://code.google.com/p/chromium/issues/detail?id=73962) -* $1000 to miaubiz for [bug - 79746](http://code.google.com/p/chromium/issues/detail?id=79746) -* $1000 to miaubiz for [bug - 81949](http://code.google.com/p/chromium/issues/detail?id=81949) -* $1000 to Vladislavas Jarmalis for [bug - 83010](http://code.google.com/p/chromium/issues/detail?id=83010) -* $1000 to Sergey Glazunov for [bug - 83743](http://code.google.com/p/chromium/issues/detail?id=83743) -* $1000 to Martin Barbella for [bug - 84452](http://code.google.com/p/chromium/issues/detail?id=84452) -* $1000 to Martin Barbella for [bug - 82546](http://code.google.com/p/chromium/issues/detail?id=82546) -* $1000 to Christian Holler for [bug - 84234](http://code.google.com/p/chromium/issues/detail?id=84234) -* $1000 to Philippe Arteau for [bug - 77493](http://code.google.com/p/chromium/issues/detail?id=77493) -* $1000 to miaubiz for [bug - 84355](http://code.google.com/p/chromium/issues/detail?id=84355) -* $1000 to miaubiz for [bug - 85003](http://code.google.com/p/chromium/issues/detail?id=85003) -* $1000 to miaubiz for [bug - 85211](http://code.google.com/p/chromium/issues/detail?id=85211) -* $1000 to miaubiz for [bug - 85418](http://code.google.com/p/chromium/issues/detail?id=85418) -* $1000 to Chamal de Silva for [bug - 88850](http://code.google.com/p/chromium/issues/detail?id=88850) -* $1000 to the Microsoft Java Team and Microsoft Vulnerability - Research (MSVR) for [bug - 88093](http://code.google.com/p/chromium/issues/detail?id=88093) -* $1000 to miaubiz for [bug - 78841](http://code.google.com/p/chromium/issues/detail?id=78841) -* $1000 to Martin Barbella for [bug - 78841](http://code.google.com/p/chromium/issues/detail?id=78841) -* $1000 to miaubiz for [bug - 86502](http://code.google.com/p/chromium/issues/detail?id=86502) -* $1000 to miaubiz for [bug - 87148](http://code.google.com/p/chromium/issues/detail?id=87148) -* $1000 to miaubiz for [bug - 87227](http://code.google.com/p/chromium/issues/detail?id=87227) -* $1000 to miaubiz for [bug - 87729](http://code.google.com/p/chromium/issues/detail?id=87729) -* $1000 to miaubiz for [bug - 87925](http://code.google.com/p/chromium/issues/detail?id=87925) -* $1000 to Christian Holler for [bug - 88591](http://code.google.com/p/chromium/issues/detail?id=88591) -* $1000 to miaubiz for [bug - 88846](http://code.google.com/p/chromium/issues/detail?id=88846) -* $1000 to Martin Barbella for [bug - 88889](http://code.google.com/p/chromium/issues/detail?id=88889) -* $1000 to Vladimir Vorontsov, [ONsec company](http://onsec.ru) for - [bug - 72492](http://code.google.com/p/chromium/issues/detail?id=72492) -* $1000 to miaubiz for [bug - 88216](http://code.google.com/p/chromium/issues/detail?id=88216) -* $1000 to Sergey Glazunov for [bug - 87453](http://code.google.com/p/chromium/issues/detail?id=87453) -* $1000 to miaubiz for [bug - 90668](http://code.google.com/p/chromium/issues/detail?id=90668) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 91665](http://code.google.com/p/chromium/issues/detail?id=91665) -* $1000 to Arthur Gerkis for [bug - 89219](http://code.google.com/p/chromium/issues/detail?id=89219) -* $1000 to miaubiz for [bug - 89330](http://code.google.com/p/chromium/issues/detail?id=89330) -* $1000 to Sławomir Błażek for [bug - 92651](http://code.google.com/p/chromium/issues/detail?id=92651) -* $1000 to Arthur Gerkis for [bug - 92959](http://code.google.com/p/chromium/issues/detail?id=92959) -* $1000 to miaubiz for [bug - 93420](http://code.google.com/p/chromium/issues/detail?id=93420) -* $1000 to miaubiz for [bug - 93587](http://code.google.com/p/chromium/issues/detail?id=93587) -* $1000 to Christian Holler for [bug - 95920](http://code.google.com/p/chromium/issues/detail?id=95920) -* $1000 to miaubiz for [bug - 93788](http://code.google.com/p/chromium/issues/detail?id=93788) -* $1000 to miaubiz for [bug - 95072](http://code.google.com/p/chromium/issues/detail?id=95072) -* $1000 to miaubiz for [bug - 95672](http://code.google.com/p/chromium/issues/detail?id=95672) -* $1000 to Christian Holler for [bug - 98773](http://code.google.com/p/chromium/issues/detail?id=98773) -* $1000 to Christian Holler for [bug - 99167](http://code.google.com/p/chromium/issues/detail?id=99167) -* $1000 to miaubiz for [bug - 97599](http://code.google.com/p/chromium/issues/detail?id=97599) -* $1000 to miaubiz for [bug - 98064](http://code.google.com/p/chromium/issues/detail?id=98064) -* $1000 to miaubiz for [bug - 98556](http://code.google.com/p/chromium/issues/detail?id=98556) -* $1000 to miaubiz for [bug - 99294](http://code.google.com/p/chromium/issues/detail?id=99294) -* $1000 to miaubiz for [bug - 99880](http://code.google.com/p/chromium/issues/detail?id=99880) -* $1000 to miaubiz for [bug - 96902](http://code.google.com/p/chromium/issues/detail?id=96902) -* $1000 to miaubiz for [bug - 99138](http://code.google.com/p/chromium/issues/detail?id=99138) -* $1000 x2 to miaubiz for [bug - 99211](http://code.google.com/p/chromium/issues/detail?id=99211) -* $1000 to miaubiz for [bug - 100464](http://code.google.com/p/chromium/issues/detail?id=100464) -* $1000 to Sławomir Błażek for [bug - 97092](http://code.google.com/p/chromium/issues/detail?id=97092) -* $1000 to kuzzcc for [bug - 62925](http://code.google.com/p/chromium/issues/detail?id=62925) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 101458](http://code.google.com/p/chromium/issues/detail?id=101458) -* $1000 to Christian Holler for [bug - 103259](http://code.google.com/p/chromium/issues/detail?id=103259) -* $1000 to miaubiz for [bug - 103058](http://code.google.com/p/chromium/issues/detail?id=103058) -* $1000 to miaubiz for [bug - 102810](http://code.google.com/p/chromium/issues/detail?id=102810) -* $1000 to miaubiz for [bug - 102628](http://code.google.com/p/chromium/issues/detail?id=102628) -* $1000 to Arthur Gerkis for [bug - 102359](http://code.google.com/p/chromium/issues/detail?id=102359) -* $1000 to Arthur Gerkis for [bug - 103921](http://code.google.com/p/chromium/issues/detail?id=103921) -* $1000 to Sławomir Błażek for [bug - 104011](http://code.google.com/p/chromium/issues/detail?id=104011) -* $1000 to Sławomir Błażek for [bug - 104859](http://code.google.com/p/chromium/issues/detail?id=104859) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 104056](http://code.google.com/p/chromium/issues/detail?id=104056) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 103239](http://code.google.com/p/chromium/issues/detail?id=103239) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 104529](http://code.google.com/p/chromium/issues/detail?id=104529) -* $1000 to Luka Treiber of ACROS Security for [bug - 99016](http://code.google.com/p/chromium/issues/detail?id=99016) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 106441](http://code.google.com/p/chromium/issues/detail?id=106441) -* $1000 to Shawn Goertzen for [bug - 108871](http://code.google.com/p/chromium/issues/detail?id=108871) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 109716](http://code.google.com/p/chromium/issues/detail?id=109716) -* $1000 to Arthur Gerkis for [bug - 109743](http://code.google.com/p/chromium/issues/detail?id=109743) -* $1000 to Arthur Gerkis for [bug - 110112](http://code.google.com/p/chromium/issues/detail?id=110112) -* $1000 to Arthur Gerkis for [bug - 110374](http://code.google.com/p/chromium/issues/detail?id=110374) -* $1000 x2 to miaubiz for [bug - 105459](http://code.google.com/p/chromium/issues/detail?id=105459) -* $1000 to Arthur Gerkis for [bug - 106484](http://code.google.com/p/chromium/issues/detail?id=106484) -* $1000 to miaubiz for [bug - 108605](http://code.google.com/p/chromium/issues/detail?id=108605) -* $1000 to Arthur Gerkis for [bug - 109556](http://code.google.com/p/chromium/issues/detail?id=109556) -* $1000 to Boris Zbarsky of Mozilla for [bug - 106672](http://code.google.com/p/chromium/issues/detail?id=106672) -* $1000 to miaubiz for [bug - 108695](http://code.google.com/p/chromium/issues/detail?id=108695) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 110172](http://code.google.com/p/chromium/issues/detail?id=110172) -* $1000 to Arthur Gerkis for [bug - 111779](http://code.google.com/p/chromium/issues/detail?id=111779) -* $1000 to miaubiz for [bug - 112847](http://code.google.com/p/chromium/issues/detail?id=112847) -* $1000 to Chamal de Silva for [bug - 105867](http://code.google.com/p/chromium/issues/detail?id=105867) -* $1000 to Arthur Gerkis for [bug - 111748](http://code.google.com/p/chromium/issues/detail?id=111748) -* $1000 to Arthur Gerkis for [bug - 108037](http://code.google.com/p/chromium/issues/detail?id=108037) -* $2000 to Arthur Gerkis for [bug - 112212](http://code.google.com/p/chromium/issues/detail?id=112212) -* $1000 to Arthur Gerkis for [bug - 116093](http://code.google.com/p/chromium/issues/detail?id=116093) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 108406](http://code.google.com/p/chromium/issues/detail?id=108406) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 115471](http://code.google.com/p/chromium/issues/detail?id=115471) -* $1000 to miaubiz for [bug - 113258](http://code.google.com/p/chromium/issues/detail?id=113258) -* $1000 to miaubiz for [bug - 113439](http://code.google.com/p/chromium/issues/detail?id=113439) -* $1000 to miaubiz for [bug - 114924](http://code.google.com/p/chromium/issues/detail?id=114924) -* $1000 to miaubiz for [bug - 115028](http://code.google.com/p/chromium/issues/detail?id=115028) -* $1000 to miaubiz for [bug - 113497](http://code.google.com/p/chromium/issues/detail?id=113497) -* $1000 to miaubiz for [bug - 113707](http://code.google.com/p/chromium/issues/detail?id=113707) -* $1000 to miaubiz for [bug - 114068](http://code.google.com/p/chromium/issues/detail?id=114068) -* $1000 to miaubiz for [bug - 114219](http://code.google.com/p/chromium/issues/detail?id=114219) -* $1000 to miaubiz for [bug - 115681](http://code.google.com/p/chromium/issues/detail?id=115681) -* $1000 to miaubiz for [bug - 113902](http://code.google.com/p/chromium/issues/detail?id=113902) -* $1000 to miaubiz for [bug - 116746](http://code.google.com/p/chromium/issues/detail?id=116746) -* $1000 to Arthur Gerkis for [bug - 116461](http://code.google.com/p/chromium/issues/detail?id=116461) -* $1000 to miaubiz for [bug - 104863](http://code.google.com/p/chromium/issues/detail?id=104863) -* $1000 to miaubiz for [bug - 107758](http://code.google.com/p/chromium/issues/detail?id=107758) -* $1000 to miaubiz for [bug - 108207](http://code.google.com/p/chromium/issues/detail?id=108207) -* $1000 to Chamal de Silva for [bug - 108544](http://code.google.com/p/chromium/issues/detail?id=108544) -* $1000 to miaubiz for [bug - 107244](http://code.google.com/p/chromium/issues/detail?id=107244) -* $1000 to miaubiz for [bug - 110764](http://code.google.com/p/chromium/issues/detail?id=110764) -* $1000 to miaubiz for [bug - 112151](http://code.google.com/p/chromium/issues/detail?id=112151) -* $1000 to miaubiz for [bug - 112833](http://code.google.com/p/chromium/issues/detail?id=112833) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 111467](http://code.google.com/p/chromium/issues/detail?id=111467) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 112411](http://code.google.com/p/chromium/issues/detail?id=112411) -* $1000 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 114342](http://code.google.com/p/chromium/issues/detail?id=114342) -* $1000 to Arthur Gerkis for [bug - 113837](http://code.google.com/p/chromium/issues/detail?id=113837) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 117471](http://code.google.com/p/chromium/issues/detail?id=117471) -* $1000 to Omair for [bug - 117588](http://code.google.com/p/chromium/issues/detail?id=117588) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 135432](http://code.google.com/p/chromium/issues/detail?id=135432) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 140803](http://code.google.com/p/chromium/issues/detail?id=140803) -* $1000 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 143609](http://code.google.com/p/chromium/issues/detail?id=143609) -* $1000 to miaubiz for [bug - 143656](http://code.google.com/p/chromium/issues/detail?id=143656) -* $1000 to Sławomir Błażek for [bug - 144899](http://code.google.com/p/chromium/issues/detail?id=144899) -* $1000 to miaubiz for [bug - 145544](http://code.google.com/p/chromium/issues/detail?id=145544) -* $1000 to miaubiz for [bug - 134897](http://code.google.com/p/chromium/issues/detail?id=134897) -* $1000 to Arthur Gerkis for [bug - 136235](http://code.google.com/p/chromium/issues/detail?id=136235) -* $1000 to Jüri Aedla for [bug - 136894](http://code.google.com/p/chromium/issues/detail?id=136894) -* $1000 to miaubiz for [bug - 129898](http://code.google.com/p/chromium/issues/detail?id=129898) -* $1000 to miaubiz for [bug - 130595](http://code.google.com/p/chromium/issues/detail?id=130595) -* $1000 to miaubiz for [bug - 120222](http://code.google.com/p/chromium/issues/detail?id=120222) -* $1000 to miaubiz for [bug - 120944](http://code.google.com/p/chromium/issues/detail?id=120944) -* $1000 to miaubiz for [bug - 124356](http://code.google.com/p/chromium/issues/detail?id=124356) -* $1000 to miaubiz for [bug - 125374](http://code.google.com/p/chromium/issues/detail?id=125374) -* $1000 to miaubiz for [bug - 129947](http://code.google.com/p/chromium/issues/detail?id=129947) -* $1000 to miaubiz for [bug - 129951](http://code.google.com/p/chromium/issues/detail?id=129951) -* $1000 to miaubiz for [bug - 130356](http://code.google.com/p/chromium/issues/detail?id=130356) -* $1000 to Jüri Aedla for [bug - 132779](http://code.google.com/p/chromium/issues/detail?id=132779) -* $1000 to Collin Payne for [bug - 150737](https://code.google.com/p/chromium/issues/detail?id=150737) -* $509 to wushi of team509 for [bug - 34978](http://code.google.com/p/chromium/issues/detail?id=34978) -* $500 to Hironori Tokuta for bug 169401 -* $500 to Atte Kettunen for bug 284785 -* $500 to Atte Kettunen for bug 271161 -* $500 to Atte Kettunen for bug 270758 -* $500 to Atte Kettunen for bug 223962 -* $500 to Atte Kettunen for bug 152569 -* $500 to Atte Kettunen for bug 253550 -* $500 to Atte Kettunen for bug 167069 -* $500 to Atte Kettunen for bug 148638 -* $500 to Atte Kettunen for bug 142169 -* $500 to Isaac Dawson for [bug - 21338](http://code.google.com/p/chromium/issues/detail?id=21338) -* $500 to Billy Rios for [bug - 26129](http://code.google.com/p/chromium/issues/detail?id=26129) -* $500 to Timothy D. Morgan of [VSR](http://www.vsecurity.com/) for - [bug - 32718](http://code.google.com/p/chromium/issues/detail?id=32718) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 35732](http://code.google.com/p/chromium/issues/detail?id=35732) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 37061](http://code.google.com/p/chromium/issues/detail?id=37061) -* $500 to kuzzcc for [bug - 39443](http://code.google.com/p/chromium/issues/detail?id=39443) -* $500 to kuzzcc for [bug - 40635](http://code.google.com/p/chromium/issues/detail?id=40635) -* $500 to wushi of team509 for [bug - 42294](http://code.google.com/p/chromium/issues/detail?id=42294) -* $500 to wushi of team509 for [bug - 42723](http://code.google.com/p/chromium/issues/detail?id=42723) -* $500 to Rodrigo Marcos of SECFORCE for [bug - 46126](http://code.google.com/p/chromium/issues/detail?id=46126) -* $500 to wushi of team509 for [bug - 44424](http://code.google.com/p/chromium/issues/detail?id=44424) -* $500 to wushi of team509 for [bug - 46360](http://code.google.com/p/chromium/issues/detail?id=46360) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 48115](http://code.google.com/p/chromium/issues/detail?id=48115) -* $500 to Michail Nikolaev for [bug - 42736](http://code.google.com/p/chromium/issues/detail?id=42736) -* $500 to sp3x of [SecurityReason.com](http://securityreason.com/) for - [bug - 43813](http://code.google.com/p/chromium/issues/detail?id=43813) -* $500 to [Jose A. Vazquez](http://spa-s3c.blogspot.com/) for [bug - 47866](http://code.google.com/p/chromium/issues/detail?id=47866) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 48284](http://code.google.com/p/chromium/issues/detail?id=48284) -* $500 to wushi of team509 for [bug - 49596](http://code.google.com/p/chromium/issues/detail?id=49596) -* $500 to wushi of team509 for [bug - 49628](http://code.google.com/p/chromium/issues/detail?id=49628) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 45331](http://code.google.com/p/chromium/issues/detail?id=45331) -* $500 to kuzzcc for [bug - 51653](http://code.google.com/p/chromium/issues/detail?id=51653) -* $500 to Isaac Dawson for [bug - 53001](http://code.google.com/p/chromium/issues/detail?id=53001) -* $500 to David Weston of Microsoft Vulnerability Research (MSVR) for - [bug - 50250](http://code.google.com/p/chromium/issues/detail?id=50250) -* $500 to kuzzcc for [bug - 51252](http://code.google.com/p/chromium/issues/detail?id=51252) -* $500 to kuzzcc for [bug - 51919](http://code.google.com/p/chromium/issues/detail?id=51252) -* $500 to Sergey Glazunov for [bug - 53361](http://code.google.com/p/chromium/issues/detail?id=53361) -* $500 to remy.saissy for [bug - 53361](http://code.google.com/p/chromium/issues/detail?id=53361) -* $500 to kuzzcc for [bug - 53394](http://code.google.com/p/chromium/issues/detail?id=53394) -* $500 to wushi of team509 for [bug - 55114](http://code.google.com/p/chromium/issues/detail?id=55114) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 57501](http://code.google.com/p/chromium/issues/detail?id=57501) -* $500 to kuzzcc for [bug - 51680](http://code.google.com/p/chromium/issues/detail?id=51680) -* $500 to Simon Schaak for [bug - 54500](http://code.google.com/p/chromium/issues/detail?id=54500) -* $500 to "vkouchna" for [bug - 58741](http://code.google.com/p/chromium/issues/detail?id=58741) -* $500 to "gundlach" / various for [bug - 60238](http://code.google.com/p/chromium/issues/detail?id=60238) -* $500 to "fam.lam" for [bug - 60327](http://code.google.com/p/chromium/issues/detail?id=60327) -* $500 to Stefan Troger for [bug - 59554](http://code.google.com/p/chromium/issues/detail?id=59554) -* $500 to kuzzcc for [bug - 63051](http://code.google.com/p/chromium/issues/detail?id=63051) -* $500 to Sławomir Błażek for [bug - 62956](http://code.google.com/p/chromium/issues/detail?id=62956) -* $500 to Chamal de Silva for [bug - 65299](http://code.google.com/p/chromium/issues/detail?id=65299) -* $500 to Jan Tošovský for [bug - 66748](http://code.google.com/p/chromium/issues/detail?id=66748) -* $500 to *anonymous* for [bug - 67363](http://code.google.com/p/chromium/issues/detail?id=67363) -* $500 to Sergey Radchenko for [bug - 63732](http://code.google.com/p/chromium/issues/detail?id=63732) -* $500 to Stefan van Zanden for [bug - 70078](http://code.google.com/p/chromium/issues/detail?id=70078) -* $500 to Martin Barbella for [bug - 69628](http://code.google.com/p/chromium/issues/detail?id=69628) -* $500 to Daniel Divricean for [bug - 70336](http://code.google.com/p/chromium/issues/detail?id=70336) -* $500 to Alex Turpin for [bug - 72517](http://code.google.com/p/chromium/issues/detail?id=72517) -* $500 to Christian Holler for [bug - 74670](http://code.google.com/p/chromium/issues/detail?id=74670) -* $500 to Yuri Ko for [bug - 70070](http://code.google.com/p/chromium/issues/detail?id=70070) -* $500 to Aki Helin for [bug - 71586](http://code.google.com/p/chromium/issues/detail?id=71586) -* $500 to Michael Griffiths for [bug - 75347](http://code.google.com/p/chromium/issues/detail?id=75347) -* $500 to Dan Rosenberg for [bug - 76542](http://code.google.com/p/chromium/issues/detail?id=76542) -* $500 to Jordi Chancel for [bug - 77786](http://code.google.com/p/chromium/issues/detail?id=77786) -* $500 to Collin Payne for [bug - 81916](http://code.google.com/p/chromium/issues/detail?id=81916) -* $500 to Aki Helin from - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 85177](http://code.google.com/p/chromium/issues/detail?id=85177) -* $500 to miaubiz for [bug - 85102](http://code.google.com/p/chromium/issues/detail?id=85102) -* $500 to Mario Gomes for [bug - 85808](http://code.google.com/p/chromium/issues/detail?id=85808) -* $500 to kuzzcc for [bug - 85808](http://code.google.com/p/chromium/issues/detail?id=85808) -* $500 to miaubiz for [bug - 87298](http://code.google.com/p/chromium/issues/detail?id=87298) -* $500 to Shih Wei-Long for [bug - 87339](http://code.google.com/p/chromium/issues/detail?id=87339) -* $500 to Juho Nurminen for [bug - 88337](http://code.google.com/p/chromium/issues/detail?id=88337) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 89142](http://code.google.com/p/chromium/issues/detail?id=89142) -* $500 to Mario Gomes for [bug - 78639](http://code.google.com/p/chromium/issues/detail?id=78639) -* $500 to Jordi Chancel for [bug - 89564](http://code.google.com/p/chromium/issues/detail?id=89564) -* $500 to miaubiz for [bug - 89991](http://code.google.com/p/chromium/issues/detail?id=89991) -* $500 to Christian Holler for [bug - 91120](http://code.google.com/p/chromium/issues/detail?id=91120) -* $500 to Jordi Chancel for [bug - 86758](http://code.google.com/p/chromium/issues/detail?id=86758) -* $500 to Simon Sarris for [bug - 91016](http://code.google.com/p/chromium/issues/detail?id=91016) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 100465](http://code.google.com/p/chromium/issues/detail?id=100465) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 98809](http://code.google.com/p/chromium/issues/detail?id=98809) -* $500 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 104959](http://code.google.com/p/chromium/issues/detail?id=104959) -* $500 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 105714](http://code.google.com/p/chromium/issues/detail?id=105714) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 108416](http://code.google.com/p/chromium/issues/detail?id=108416) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 108901](http://code.google.com/p/chromium/issues/detail?id=108901) -* $500 to Aki Helin of [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 110277](http://code.google.com/p/chromium/issues/detail?id=110277) -* $500 to miaubiz for [bug - 106336](http://code.google.com/p/chromium/issues/detail?id=106336) -* $500 to pa_kt for [bug - 112259](http://code.google.com/p/chromium/issues/detail?id=112259) -* $500 to Sławomir Błażek for [bug - 112670](http://code.google.com/p/chromium/issues/detail?id=112670) -* $500 to Sławomir Błażek for [bug - 114054](http://code.google.com/p/chromium/issues/detail?id=114054) -* $500 to miaubiz for [bug - 108467](http://code.google.com/p/chromium/issues/detail?id=108467) -* $500 to Masato Kinugawa for [bug - 109574](http://code.google.com/p/chromium/issues/detail?id=109574) -* $500 to Arthur Gerkis for [bug - 112317](http://code.google.com/p/chromium/issues/detail?id=112317) -* $500 to miaubiz for [bug - 114056](http://code.google.com/p/chromium/issues/detail?id=114056) -* $500 to Christian Holler for [bug - 117794](http://code.google.com/p/chromium/issues/detail?id=117794) -* $500 to Nir Moshe for [bug - 137707](http://code.google.com/p/chromium/issues/detail?id=137707) -* $500 to pawlkt for [bug - 139168](http://code.google.com/p/chromium/issues/detail?id=139168) -* $500 to Atte Kettunen of - [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for [bug - 141651](http://code.google.com/p/chromium/issues/detail?id=141651) -* $500 to miaubiz for [bug - 121347](http://code.google.com/p/chromium/issues/detail?id=121347) -* $500 to miaubiz for [bug - 136881](http://code.google.com/p/chromium/issues/detail?id=136881) -* $500 to Emmanuel Bronshtein for [bug - 142956](http://code.google.com/p/chromium/issues/detail?id=142956) -* $500 to Takeshi Terada for [bug - 144813](http://code.google.com/p/chromium/issues/detail?id=144813) -* $500 to Takeshi Terada for [bug - 144820](http://code.google.com/p/chromium/issues/detail?id=144820) -* $500 to Takeshi Terada for [bug - 137532](http://code.google.com/p/chromium/issues/detail?id=137532) -* $500 to Takeshi Terada for [bug - 144866](http://code.google.com/p/chromium/issues/detail?id=144866) -* $500 to Takeshi Terada for [bug - 141889](http://code.google.com/p/chromium/issues/detail?id=141889) -* $500 to Artem Chaykin for [bug - 138210](http://code.google.com/p/chromium/issues/detail?id=138210) -* $500 to Artem Chaykin for [bug - 138035](http://code.google.com/p/chromium/issues/detail?id=138035) -* $500 to Ayush Jindal for [bug - 68342](https://code.google.com/p/chromium/issues/detail?id=68342) - -The following special-case rewards were issued for bugs in components external -to the Chromium project. We sometimes issue rewards for bugs in external -components where information of the bug enabled us to proactively protect our -users. - -* $5000 to Eetu Luodemaa and Joni Vähämäki, both from Documill, for - [bug - 146254](http://code.google.com/p/chromium/issues/detail?id=146254) -* $4000 to Jüri Aedla for [bug - 107128](http://code.google.com/p/chromium/issues/detail?id=107128) -* $3000 to Jüri Aedla for [bug - 129930](http://code.google.com/p/chromium/issues/detail?id=129930) -* $1337 to Marc Schoenefeld for [bug - 48283](http://code.google.com/p/chromium/issues/detail?id=48283) -* $1337 to Simon Berry-Byrne for [bug - 48733](http://code.google.com/p/chromium/issues/detail?id=48733) -* $1337 to Marc Schoenefeld for [bug - 51070](http://code.google.com/p/chromium/issues/detail?id=51070) -* $1337 to Jüri Aedla for [bug - 112822](http://code.google.com/p/chromium/issues/detail?id=112822) -* $1000 to Bui Quang Minh from Bkis - ([www.bkis.com](http://www.bkis.com)) for [bug - 58731](http://code.google.com/p/chromium/issues/detail?id=58731) -* $1000 to Yang Dingning from NCNIPC, Graduate University of Chinese - Academy of Sciences for [bug - 63444](http://code.google.com/p/chromium/issues/detail?id=63444) -* $1000 to Yang Dingning from NCNIPC, Graduate University of Chinese - Academy of Sciences for [bug - 86900](http://code.google.com/p/chromium/issues/detail?id=86900) -* $1000 to Yang Dingning from NCNIPC, Graduate University of Chinese - Academy of Sciences for [bug - 89402](http://code.google.com/p/chromium/issues/detail?id=89402) -* $1000 to Yang Dingning from NCNIPC, Graduate University of Chinese - Academy of Sciences for [bug - 93472](http://code.google.com/p/chromium/issues/detail?id=93472) -* $1000 to Nicolas Gregoire for [bug - 138673](http://code.google.com/p/chromium/issues/detail?id=138673) -* $500 to Nicolas Gregoire for [bug - 127417](http://code.google.com/p/chromium/issues/detail?id=127417) - -(Note that some of the above individuals elected to donate the rewards to -charity. In these cases, Google often increased the value of the donation beyond -the stated reward amount.) - -### **Honorable mention** - -The following lower severity or duplicate bugs were responsibly reported to the -Chromium project. Thanks to these named individuals for helping Chromium -security! - -* Mike Dougherty of dotSyntax, LLC for [bug - 33572](http://code.google.com/p/chromium/issues/detail?id=33572) -* kuzzcc for [bug - 37007](http://code.google.com/p/chromium/issues/detail?id=37007) -* RSnake of [ha.ckers.org](http://ha.ckers.org/) for [bug - 33445](http://code.google.com/p/chromium/issues/detail?id=33445) -* Tobias Klein ([www.trapkit.de](http://www.trapkit.de/)) for [bug - 38845](http://code.google.com/p/chromium/issues/detail?id=38845) -* Carlos Ghan for [bug - 33952](http://code.google.com/p/chromium/issues/detail?id=33952) -* WHK <elhacker.net> and The-0utl4w From Aria-Security for [bug - 34721](http://code.google.com/p/chromium/issues/detail?id=34721) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 35979](http://code.google.com/p/chromium/issues/detail?id=35979) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 36976](http://code.google.com/p/chromium/issues/detail?id=36976) -* Jordi Chancel for [bug - 37447](http://code.google.com/p/chromium/issues/detail?id=37447) -* kuzzcc for [bug - 39277](http://code.google.com/p/chromium/issues/detail?id=39277) -* Florent, Skyrecon systems for [bug - 40801](http://code.google.com/p/chromium/issues/detail?id=40801) -* kuzzcc for [bug - 41778](http://code.google.com/p/chromium/issues/detail?id=41778) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 42538](http://code.google.com/p/chromium/issues/detail?id=42538) -* kuzzcc for [bug - 40628](http://code.google.com/p/chromium/issues/detail?id=40628) -* kuzzcc for [bug - 41447](http://code.google.com/p/chromium/issues/detail?id=41447) -* Florian Rienhardt, BSI for [bug - 36553](http://code.google.com/p/chromium/issues/detail?id=36553) -* Ben Davis and Emanuele Gentili for [bug - 38105](http://code.google.com/p/chromium/issues/detail?id=38105) -* Sergey Glazunov for [bug - 42396](http://code.google.com/p/chromium/issues/detail?id=42396) -* Jose A. Vazquez for [bug - 45164](http://code.google.com/p/chromium/issues/detail?id=45164) -* Mats Ahlgren for [bug - 46575](http://code.google.com/p/chromium/issues/detail?id=46575) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 47056](http://code.google.com/p/chromium/issues/detail?id=47056) -* Lostmon for [bug - 28001](http://code.google.com/p/chromium/issues/detail?id=28001) -* "ironfist99" for [bug - 34414](http://code.google.com/p/chromium/issues/detail?id=34414) -* Chris Weber from Casaba Security for [bug - 37201](http://code.google.com/p/chromium/issues/detail?id=37201) -* Brook Novak for [bug - 41654](http://code.google.com/p/chromium/issues/detail?id=41654) -* Lostmon for [bug - 45876](http://code.google.com/p/chromium/issues/detail?id=45876) -* Keith Campbell for [bug - 51846](http://code.google.com/p/chromium/issues/detail?id=51846) -* [VUPEN Vulnerability Research Team](http://www.vupen.com/) - (VUPEN-SR-2010-249) for [bug - 52443](http://code.google.com/p/chromium/issues/detail?id=52443) -* "magnusmorton" for [bug - 51709](http://code.google.com/p/chromium/issues/detail?id=51709) -* kuzzcc for [bug - 53176](http://code.google.com/p/chromium/issues/detail?id=53176) -* "adriennefelt" for [bug - 54006](http://code.google.com/p/chromium/issues/detail?id=54006) -* Jordi Chancel for [bug - 51680](http://code.google.com/p/chromium/issues/detail?id=51680) -* kuzzcc for [bug - 53002](http://code.google.com/p/chromium/issues/detail?id=53002) -* Dan Rosenberg, Virtual Security Research for [bug - 54132](http://code.google.com/p/chromium/issues/detail?id=54132) -* Nirankush Panchbhai and Microsoft Vulnerability Research (MSVR) for - [bug - 55745](http://code.google.com/p/chromium/issues/detail?id=55745) -* Cezary Tomczak for [bug - 58319](http://code.google.com/p/chromium/issues/detail?id=58319) -* Mohammed Bouhlel for [bug - 61701](http://code.google.com/p/chromium/issues/detail?id=61701) -* kuzzcc for [bug - 62168](http://code.google.com/p/chromium/issues/detail?id=62168) -* David Weston of Microsoft Vulnerability Research (MSVR) for [bug - 60055](http://code.google.com/p/chromium/issues/detail?id=60055) -* kuzzcc for [bug - 60761](http://code.google.com/p/chromium/issues/detail?id=60761) -* Marius Wachtler for [bug - 62276](http://code.google.com/p/chromium/issues/detail?id=62276) -* Chamal de Silva for [bug - 65299](http://code.google.com/p/chromium/issues/detail?id=65299) -* Chamal de Silva for [bug - 66591](http://code.google.com/p/chromium/issues/detail?id=66591) -* David Warren of [CERT](http://www.cert.org/) for [bug - 67303](http://code.google.com/p/chromium/issues/detail?id=67303) -* miaubiz for [bug - 67363](http://code.google.com/p/chromium/issues/detail?id=67363) -* Brian Kirchoff for [bug - 62791](http://code.google.com/p/chromium/issues/detail?id=62791) -* Dan Morrison for [bug - 66931](http://code.google.com/p/chromium/issues/detail?id=66931) -* Matthew Heidermann for [bug - 68244](http://code.google.com/p/chromium/issues/detail?id=68244) -* [Reddit](http://www.reddit.com) for [bug - 69195](http://code.google.com/p/chromium/issues/detail?id=69195) -* Rik Cabanier for [bug - 67234](http://code.google.com/p/chromium/issues/detail?id=67234) -* miaubiz for [bug - 71717](http://code.google.com/p/chromium/issues/detail?id=71717) -* Louis Lang for [bug - 49747](http://code.google.com/p/chromium/issues/detail?id=49747) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 66962](http://code.google.com/p/chromium/issues/detail?id=66962) -* David Weston of Microsoft and Microsoft Vulnerability Research - (MSVR) for [bug - 71788](http://code.google.com/p/chromium/issues/detail?id=71788) -* Martin Barbella for [bug - 61502](http://code.google.com/p/chromium/issues/detail?id=61502) -* Chamal de Silva for [bug - 70538](http://code.google.com/p/chromium/issues/detail?id=70538) -* Cole Snodgrass for [bug - 72523](http://code.google.com/p/chromium/issues/detail?id=72523) -* miaubiz for [bug - 72910](http://code.google.com/p/chromium/issues/detail?id=72910) -* wushi of team509 for [bug - 75801](http://code.google.com/p/chromium/issues/detail?id=75801) -* wushi of team509 for [bug - 76646](http://code.google.com/p/chromium/issues/detail?id=76646) -* kuzzcc for [bug - 77349](http://code.google.com/p/chromium/issues/detail?id=77349) -* Sergey Glazunov for [bug - 75821](http://code.google.com/p/chromium/issues/detail?id=75821) -* kuzzcc for [bug - 79266](http://code.google.com/p/chromium/issues/detail?id=79266) -* kuzzcc for [bug - 79426](http://code.google.com/p/chromium/issues/detail?id=79426) -* Sergey Glazunov for [bug - 83273](http://code.google.com/p/chromium/issues/detail?id=83273) -* kuzzcc for [bug - 83841](http://code.google.com/p/chromium/issues/detail?id=83841) -* kuzzcc for [bug - 84402](http://code.google.com/p/chromium/issues/detail?id=84402) -* Olli Pettay of Mozilla for [bug - 84600](http://code.google.com/p/chromium/issues/detail?id=84600) -* kuzzcc for [bug - 84805](http://code.google.com/p/chromium/issues/detail?id=84805) -* Mikołaj Małecki for [bug - 85559](http://code.google.com/p/chromium/issues/detail?id=85559) -* Collin Payne for [bug - 84933](http://code.google.com/p/chromium/issues/detail?id=84933) -* miaubiz for [bug - 82552](http://code.google.com/p/chromium/issues/detail?id=82552) -* wushi of team509 (reported through ZDI) for [bug - 88670](http://code.google.com/p/chromium/issues/detail?id=88670) -* miaubiz for [bug - 88670](http://code.google.com/p/chromium/issues/detail?id=88670) -* electronixtar for [bug - 51464](http://code.google.com/p/chromium/issues/detail?id=51464) -* wbrana for [bug - 57908](http://code.google.com/p/chromium/issues/detail?id=57908) -* kuzzcc for [bug - 78427](http://code.google.com/p/chromium/issues/detail?id=78427) -* kuzzcc for [bug - 83031](http://code.google.com/p/chromium/issues/detail?id=83031) -* Aaron Sigel of [vtty.com](http://vtty.com) for [bug - 80680](http://code.google.com/p/chromium/issues/detail?id=80680) -* Mario Gomes for [bug - 85041](http://code.google.com/p/chromium/issues/detail?id=85041) -* Arthur Gerkis for [bug - 89795](http://code.google.com/p/chromium/issues/detail?id=89795) -* miaubiz for [bug - 90134](http://code.google.com/p/chromium/issues/detail?id=90134) -* miaubiz for [bug - 94800](http://code.google.com/p/chromium/issues/detail?id=94800) -* Bernhard 'Bruhns' Brehm of Recurity Labs for [bug - 93497](http://code.google.com/p/chromium/issues/detail?id=93497) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 93596](http://code.google.com/p/chromium/issues/detail?id=93596) -* Nishant Yadant of VMware and Craig Chamberlain for [bug - 95917](http://code.google.com/p/chromium/issues/detail?id=95917) -* Chu for [bug - 101010](http://code.google.com/p/chromium/issues/detail?id=101010) -* Aki Helin from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) for - [bug - 100863](http://code.google.com/p/chromium/issues/detail?id=100863) -* Collin Payne for [bug - 92550](http://code.google.com/p/chromium/issues/detail?id=92550) -* Devdatta Akhawe, UC Berkeley for [bug - 103630](http://code.google.com/p/chromium/issues/detail?id=103630) -* Atte Kettunen from [OUSPG](https://www.ee.oulu.fi/research/ouspg/) - for [bug - 109094](http://code.google.com/p/chromium/issues/detail?id=109094) -* Code Audit Labs of VulnHunt.com for [bug - 109245](http://code.google.com/p/chromium/issues/detail?id=109245) -* Sławomir Błażek for [bug - 109664](http://code.google.com/p/chromium/issues/detail?id=109664) -* Ben Carrillo for [bug - 109717](http://code.google.com/p/chromium/issues/detail?id=109717) -* chrometot for [bug - 112451](http://code.google.com/p/chromium/issues/detail?id=112451) -* Michael Gundlach for [bug - 108648](http://code.google.com/p/chromium/issues/detail?id=108648) -* Glenn Randers-Pehrson for [bug - 116162](http://code.google.com/p/chromium/issues/detail?id=116162)
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/index.md b/chromium/docs/website/site/Home/chromium-security/index.md deleted file mode 100644 index fb39ba290f2..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/index.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -page_name: chromium-security -title: Chromium Security ---- - -The Chromium security team aims to provide Chrome and Chrome OS users with the -most secure platform to navigate the web, and just generally make the Internet a -safer place to hang out. We work on solutions for the [biggest user / ux -security problems](/Home/chromium-security/enamel), drive [secure architecture -design and implementation projects for the Chromium -platform](/Home/chromium-security/guts), [find and help fix security -bugs](/Home/chromium-security/bugs), [help developers to create more secure -apps](/Home/chromium-security/owp), and act as a [general security consulting / -review group](/Home/chromium-security/reviews-and-consulting) for the larger -Chromium project. - -To learn more: - -* Read our [core security - principles](/Home/chromium-security/core-principles), which we try - to follow in all security work we do. -* Check out our [security brag - sheet](/Home/chromium-security/brag-sheet), which lists some of the - technologies and recognition we're most proud of. -* Check out some of the work we're doing to [detect and prevent - security bugs](/Home/chromium-security/bugs), ensure that Chromium - is [secure by design and resilient to - exploitation](/Home/chromium-security/guts), and [make security - easier for users and developers](/Home/chromium-security/enamel). -* Peruse the [Security - FAQ](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md) - for answers to common questions. -* Learn about how [Security - Reviews](/Home/chromium-security/security-reviews) work in Chrome. -* Check out some of our [Chrome-specific security - education](/Home/chromium-security/education) documentation. -* Check out the [PDFium - Security](/Home/chromium-security/pdfium-security) page, too. -* Here is the canonical "[prefer secure origins for powerful new - features](/Home/chromium-security/prefer-secure-origins-for-powerful-new-features)" - proposal text. -* Here is the canonical "[Marking HTTP As - Non-Secure](/Home/chromium-security/marking-http-as-non-secure)" - proposal text. -* Have a look at our public [Chrome Security Google Drive - folder](https://drive.google.com/open?id=0B_KwtdC2J1Q6fjFNRElHUHhmLUlNbktKbFVkRXBlVGp0NkZvTDJvZVRZLXozOVFqTWtzM1E&authuser=0), - which contains a whole bunch of useful documents as well. -* We provide [quarterly - updates](/Home/chromium-security/quarterly-updates) to what we're - working on, if anything piques your interest get in touch! -* Find out about [our memory - safety](/Home/chromium-security/memory-safety) work. - -### How can I get involved? - -**Find bugs** - -One of the quickest ways to get involved is finding and [reporting security -bugs](/Home/chromium-security/reporting-security-bugs). It will get prompt -attention from a [security -sheriff](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/sheriff.md), -be kept private until we coordinate disclosure, and possibly qualify for a cash -reward through our [Vulnerability Rewards -Program](/Home/chromium-security/vulnerability-rewards-program). We occasionally -run security contests outside of our regular reward program (e.g. -[Pwnium2](/Home/chromium-security/pwnium-2), -[Pwnium3](/Home/chromium-security/pwnium-3)) too. - -For any issues other than a specific bug, email us at -[security@chromium.org](mailto:security@chromium.org). For non-confidential -discussions, please post to the [technical discussion -forums](/developers/technical-discussion-groups), including the public -[security-dev](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev) -list for technical discussions. - -**Become a committer** - -We encourage interested parties to work towards [becoming a -committer](/getting-involved/become-a-committer). There are many types of -security related patch that we're excited to collaborate on: - -* Fixes for any security bugs you discover. -* Implementing or improving security features, including - security-related web platform features (examples: iframe sandbox, - XSS auditor, CSP). -* Implementing or improving security hardening measures (examples: - defensive checks, allocator improvements, ASLR improvements). - -**Become an IPC reviewer** - -Bugs in IPC can have nasty consequences, so we take special care to make sure -additions or changes to IPC avoid [common security -pitfalls](/Home/chromium-security/education/security-tips-for-ipc). If you want -to get involved, check out how to become an IPC reviewer -[here](/Home/chromium-security/ipc-security-reviews). - -**Join the team** - -Access to Chromium security bugs and our team mailing list is restricted, for -obvious reasons. Before applying to join the team, applicants must be committers -and are expected to have made and continue to make active and significant -contributions to Chromium security. You should demonstrate some of the following -before applying: - -* Relevant technical expertise and a history of patches that improve - Chromium security. -* A history of identifying and responsibly reporting Chromium security - vulnerabilities. -* Other expertise and/or roles that would allow the applicant to - significantly contribute to Chromium security on a regular basis. -* \[required\]: Be a committer, and have no personal or professional - association that is an ethical conflict of interest (e.g. keeping - vulnerabilities or exploits private, or sharing with parties other - than the vendor). - -To apply for membership, please email -[security@chromium.org](mailto:security@chromium.org). - -### How can I get access to Chromium vulnerabilities? - -A history of fixed Chromium security bugs is best found via [security notes in -Stable Channel updates on the Google Chrome releases -blog](https://googlechromereleases.blogspot.com/search/label/Stable%20updates). -You can also find fixed, publicly visible Type=Bug-Security bugs in the [issue -tracker](https://crbug.com/) (note: security bugs automatically become publicly -visible 14 weeks after they are fixed). All security bugs are rated according to -our [severity -guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md), -which we keep in line with industry standards. - -Advance notice of (fixed) Chromium security vulnerabilities is restricted to -those actively building significantly deployed products based upon Chromium, or -including Chromium as part of bundled software distributions. If you meet the -criteria, and require advanced notice of vulnerabilities, request access via -[security@chromium.org](mailto:security@chromium.org). Your email should explain -your need for access (embedder, Linux distribution, etc.) and your continued -access will require that you follow the terms of list membership. - -### There is one simple rule for any party with advance access to security vulnerabilities in Chromium: any details of a vulnerability should be considered confidential and only shared on a need to know basis until such time that the vulnerability is responsibly disclosed by the Chromium project. Additionally, any vulnerabilities in third-party dependencies (e.g. Blink, open source parser libraries, etc.) must be treated with the same consideration. Access will be terminated for any member who fails to comply with this rule in letter or spirit.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/ipc-security-reviews/index.md b/chromium/docs/website/site/Home/chromium-security/ipc-security-reviews/index.md deleted file mode 100644 index 904bb9a61ae..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/ipc-security-reviews/index.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: ipc-security-reviews -title: IPC Security Reviews ---- - -**So, you want to help with IPC reviews?** Fantastic! Security bugs in IPC have -nasty consequences, so we have a little background check and ramp up process: - -**First, tell [us](mailto:security@chromium.org) a bit about your security -interest and experience and confirm you've done your homework.** Entrusting you -with this responsibility only makes sense if you care about Chromium security, -so tell us why you want to do this. Do you have a history of helping find / fix -security bugs? Have you helped with security-relevant software design or -projects? Tell us a bit about your security interests and experience. - -You should also confirm that you've read and understand all of our doc on -[security tips for -IPC](/Home/chromium-security/education/security-tips-for-ipc).Is anything -unclear? Can you suggest or make improvements? Docs have a tendency of going -stale. - -**Next, we'll partner you up on some reviews.** We'll typically have you do ~3 -IPC reviews yourself with an existing reviewer doing a second pass. - -If all that looks good, you're on board!
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/malicious-extensions-protection/index.md b/chromium/docs/website/site/Home/chromium-security/malicious-extensions-protection/index.md deleted file mode 100644 index 4fba2d13c11..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/malicious-extensions-protection/index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: malicious-extensions-protection -title: Malicious Extensions Protection ---- - -http://blog.chromium.org/2013/11/protecting-windows-users-from-malicious.html
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages with User Input.gif.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages with User Input.gif.sha1 deleted file mode 100644 index 77963b3f231..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages with User Input.gif.sha1 +++ /dev/null @@ -1 +0,0 @@ -9856c4425ff1c40d33c0e6f85241d9e86f0f3ae0
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages@1x.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages@1x.png.sha1 deleted file mode 100644 index d7c9fd05439..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/Treatment of HTTP Pages@1x.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -af0a46ad9f5fc6b5ddc92e401f01fd48fa1aff28
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 1.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 1.png.sha1 deleted file mode 100644 index cacb4fc1462..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 1.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -965471ca717b325ee4b3298e9569e2b76eb400ee
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 2.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 2.png.sha1 deleted file mode 100644 index e8074b21cdd..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/blog image 2.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -90d8f3a756084bc6cd204f80dd8385e62e25412d
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/form-and-incognito-http-bad-verbose.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/form-and-incognito-http-bad-verbose.png.sha1 deleted file mode 100644 index d6ebd3bb0b9..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/form-and-incognito-http-bad-verbose.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -fc08b30a4f39f9859a34a1e66478cb79da793eab
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/http-bad-sep-2018.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/http-bad-sep-2018.png.sha1 deleted file mode 100644 index bba461f924c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/http-bad-sep-2018.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -7003b4743000d675e6ae442b4596b3e6263e0937
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/index.md b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/index.md deleted file mode 100644 index 4bf40abd736..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/index.md +++ /dev/null @@ -1,329 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: marking-http-as-non-secure -title: Marking HTTP As Non-Secure ---- - -This page contains the original proposal for marking HTTP as non-secure (see -Original Proposal below). - -Since then, the [Chrome usable security team](/Home/chromium-security/enamel) -has announced the following phases towards this goal. - -For more information see, the WebFundamentals article: [Avoiding the Not Secure -Warning in -Chrome](https://developers.google.com/web/updates/2016/10/avoid-not-secure-warn) - ---- - -Timeline - -**January 2017 (Phase 1)** - -Takes effect: January 2017 (Chrome 56) - -Announcement: [Moving towards a more secure -web](https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html) -(September 8, 2016) - -In this phase, HTTP pages will be marked with "Not Secure" in the URL bar under -the following conditions: - -* The page **contains a password field**. -* The user **interacts with a credit card field**. - -[<img alt="image" -src="/Home/chromium-security/marking-http-as-non-secure/blog%20image%201.png" -height=156 -width=400>](/Home/chromium-security/marking-http-as-non-secure/blog%20image%201.png) - -**October 2017 (Phase 2)** - -Takes effect: October 2017 (Chrome 62) - -Announcement: [Next Steps Toward More Connection -Security](https://security.googleblog.com/2017/04/next-steps-toward-more-connection.html) -(April 27, 2017) - -In this phase, HTTP pages will be marked with "Not Secure" in the URL bar under -the following conditions: - -* The user is browsing in Chrome [**incognito - mode**](https://support.google.com/chromebook/answer/95464). -* The page **contains a password field**. -* The user **interacts with any input field**. - -[<img alt="image" -src="/Home/chromium-security/marking-http-as-non-secure/form-and-incognito-http-bad-verbose.png" -height=150 -width=400>](/Home/chromium-security/marking-http-as-non-secure/form-and-incognito-http-bad-verbose.png) - -On mobile, there is no room for the string, so only the icon animates out for -user entered data: - -<img alt="image" -src="https://lh6.googleusercontent.com/o8gRCMfszCh_ut-ED6vM_GwprRwi5bi3uvdOgVbCZr74N6ZahKXN4IgtkGB9lGVa6dJOPC6HRdMwHHv0Dpaq-0QmEcHFeOza4I4Av8fSYA5eYD3qKG960hb5msau5DSG8zhJtKsSexk" -height=320 width=180> - -**July 2018 (Phase 3)** - -Takes effect: July 2018 (Chrome 68) - -Announcement: [A secure web is here to -stay](https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html) -(February 8, 2018) - -In this phase, all HTTP pages will be marked with "Not Secure": - -[<img alt="image" -src="/Home/chromium-security/marking-http-as-non-secure/phase-3-wide.png" -height=141 -width=400>](/Home/chromium-security/marking-http-as-non-secure/phase-3-wide.png) - -On mobile, there is no room for the string. The (i) icon will show on all HTTP -pages: - -<img alt="image" -src="https://lh6.googleusercontent.com/WLxC0fxWjNDw524vjorHcqnSSzR_hkJqZVogkFpka9fut6J_BS9UBip4BGPNWicQTH52A8Diae2j67JcziEJ8XrpHmLXnKagCLOZLvWAEHJ33ftTBVe9ZjurdLMw-kbnAbFcWkBE6bg" -height=80 width=400> - -**September 2018** - -Takes effect: September 2018 (Chrome 69) - -Announcement: [Evolving Chrome's security -indicators](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html) -(May 17, 2018) - -In this phase, secure pages will be marked more neutral instead of affirmatively -secure: - -[<img alt="image" -src="/Home/chromium-security/marking-http-as-non-secure/http-bad-sep-2018.png">](/Home/chromium-security/marking-http-as-non-secure/http-bad-sep-2018.png) - -**October 2018** - -Takes effect: October 2018 (Chrome 70) - -Announcement: [Evolving Chrome's security -indicators](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html) -(May 17, 2018) - -In this phase, HTTP pages will be marked as affirmatively "Not Secure" using red -color and the non-secure icon in the URL bar if the user **interacts with any -input field**. - -[<img alt="image" -src="https://3.bp.blogspot.com/-MkJEkHnXcXc/Wv181DQednI/AAAAAAAAA6E/95MwjxqK7awaCgr_Z6xRNWVi0Ztf0-ncACLcBGAs/s1600/Treatment%2Bof%2BHTTP%2BPages%2Bwith%2BUser%2BInput.gif">](https://3.bp.blogspot.com/-MkJEkHnXcXc/Wv181DQednI/AAAAAAAAA6E/95MwjxqK7awaCgr_Z6xRNWVi0Ztf0-ncACLcBGAs/s1600/Treatment%2Bof%2BHTTP%2BPages%2Bwith%2BUser%2BInput.gif) - -**Eventual** - -There is no target date for the final state yet, but we intend to mark all HTTP -pages as affirmatively non-secure in the long term (the same as other non-secure -pages, like pages with broken HTTPS): - -**[<img alt="image" -src="/Home/chromium-security/marking-http-as-non-secure/blog%20image%202.png" -height=194 -width=400>](/Home/chromium-security/marking-http-as-non-secure/blog%20image%202.png)** - -On mobile: - -<img alt="image" -src="https://lh3.googleusercontent.com/U3QsL4ZZlAZOBejvGlmo0RMgZpnXEmzj_JZDcZoqUeX7q9UTHCLlRxoweNKY9F8lNj3h9GzrwaSKIaxOI0pRzmZ60X7N6taxTsw_ygpI5HobP0DEOzDnhwGLxn9kmgjUNSI6-CakhFg" -height=81 width=320> - ---- - -Original Proposal - -Proposal - -We, the Chrome Security Team, propose that user agents (UAs) gradually change -their UX to display non-secure origins as affirmatively non-secure. - -The goal of this proposal is to more clearly display to users that HTTP provides -no data security. - -Request - -We’d like to hear everyone’s thoughts on this proposal, and to discuss with the -web community about how different transition plans might serve users. - -Background - -We all need data communication on the web to be secure (private, authenticated, -untampered). When there is no data security, the UA should explicitly display -that, so users can make informed decisions about how to interact with an origin. - -Roughly speaking, there are three basic transport layer security states for web -origins: - - Secure (valid HTTPS, other origins like (\*, localhost, \*)); - - Dubious (valid HTTPS but with mixed passive resources, valid HTTPS with - minor TLS errors); and - - Non-secure (broken HTTPS, HTTP). - -For more precise definitions of secure and non-secure, see [Requirements for -Powerful Features](http://www.w3.org/TR/powerful-features/) and [Mixed -Content](http://www.w3.org/TR/mixed-content/). - -We know that active tampering and surveillance attacks, as well as passive -surveillance attacks, are not theoretical but are in fact commonplace on the -web. - -[RFC 7258: Pervasive Monitoring Is an -Attack](https://tools.ietf.org/html/rfc7258) - -[NSA uses Google cookies to pinpoint targets for -hacking](http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) - -[Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing -Machine](http://www.wired.com/2014/10/verizons-perma-cookie/) - -[How bad is it to replace adSense code id to ISP's adSense ID on free -Internet?](http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet) - -[Comcast Wi-Fi serving self-promotional ads via JavaScript -injection](http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/) - -[Erosion of the moral authority of transparent -middleboxes](https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01) - -[Transitioning The Web To HTTPS](https://w3ctag.github.io/web-https/) - -We know that people do not generally perceive the absence of a warning sign. -(See e.g. [The Emperor's New Security -Indicators](http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf).) -Yet the only situation in which web browsers are guaranteed not to warn users is -precisely when there is no chance of security: when the origin is transported -via HTTP. Here are screenshots of the status quo for non-secure domains in -Chrome, Safari, Firefox, and Internet Explorer: - -<img alt="Screen Shot 2014-12-11 at 5.08.48 PM.png" -src="https://lh3.googleusercontent.com/iqplifxSx_wSl7SIq6UVlYg6PdxJxgCAoF-6D06PPfC3CN9GZE0NzeWF72jRa4wi2E2ACnt9L24-sv69phA8WCBhVQGlYqlV1YUxlaJU3_8OwQNxzM4AJK6dE4k_-X8n5g" -height=71px; width=243px;> - -<img alt="Screen Shot 2014-12-11 at 5.09.55 PM.png" -src="https://lh5.googleusercontent.com/YJAUDzAEAiaRpWRKa9qVaPly5eb6uwy909VH3OoINMwub7fz_KHrrPrLjHIi42KUt8l-VSmrFpjeTN5xTaZskhfsIoldczpw5eJNY6yLMYoA4wa2Ij-_rGz6oNM5mSVerA" -height=77px; width=254px;> - -<img alt="Screen Shot 2014-12-11 at 5.11.04 PM.png" -src="https://lh6.googleusercontent.com/QuA9DeqhXn8Cx9gTRBfYZmseK1Qz53apbMSylUgAcJCCzBsZ55pLllipWZxK9e4yQ_zJbFEuDJPnbJzMZxe59FCfMEqWPC0HDNfq3-65ebsbQ344n6U16PpXYc3cZ_sKkg" -height=86px; width=328px;> - -<img alt="ie-non-secure.png" -src="https://lh6.googleusercontent.com/0R7HobJqifX3DqOAMzKcfb72lbyJbew5H3VWGLijftRNuEM76cwRzQAX_Zk461w6dVjFNXGf7nQ0J8uOrIsSTmsUaaauNZGtV2CEEXJZkY7ncw75y8N8si1LcK6JOjxofg" -height=61px; width=624px;> - -Particulars - -UA vendors who agree with this proposal should decide how best to phase in the -UX changes given the needs of their users and their product design constraints. -Generally, we suggest a phased approach to marking non-secure origins as -non-secure. For example, a UA vendor might decide that in the medium term, they -will represent non-secure origins in the same way that they represent Dubious -origins. Then, in the long term, the vendor might decide to represent non-secure -origins in the same way that they represent Bad origins. - -Ultimately, we can even imagine a long term in which secure origins are so -widely deployed that we can leave them unmarked (as HTTP is today), and mark -only the rare non-secure origins. - -There are several ways vendors might decide to transition from one phase to the -next. For example, the transition plan could be time-based: - - T0 (now): Non-secure origins unmarked - - T1: Non-secure origins marked as Dubious - - T2: Non-secure origins marked as Non-secure - - T3: Secure origins unmarked - -Or, vendors might set thresholds based on telemetry that measures the ratios of -user interaction with secure origins vs. non-secure. Consider this strawman -proposal: - - Secure > 65%: Non-secure origins marked as Dubious - - Secure > 75%: Non-secure origins marked as Non-secure - - Secure > 85%: Secure origins unmarked - -The particular thresholds or transition dates are very much up for discussion. -Additionally, how to define “ratios of user interaction” is also up for -discussion; ideas include the ratio of secure to non-secure page loads, the -ratio of secure to non-secure resource loads, or the ratio of total time spent -interacting with secure vs. non-secure origins. - -We’d love to hear what UA vendors, web developers, and users think. Thanks for -reading! We are discussing the proposal on web standards mailing lists: - -* [public-webappsec@w3.org](http://lists.w3.org/Archives/Public/public-webappsec/) -* [blink-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev) -* [security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev) -* [dev-security@lists.mozilla.org](https://groups.google.com/forum/#!forum/mozilla.dev.security) - -**FAQ** - -We have fielded various reasonable concerns about this proposal, but most of -them have a good answer. Here is a brief selection. - -(Please consider any external links to be examples, not endorsements.) - -* **Will this break plain HTTP sites?** - * No. HTTP sites will continue to work; we currently have no plans - to block them in Chrome. All that will change is the *security - indicator(s)*. -* **Aren't certificates expensive/difficult to obtain?** - * A few providers currently provide free/cheap/bundled - certificates right now. The [Let's - Encrypt](https://letsencrypt.org/) project makes it easy to - obtain free certificates (even for many subdomains at once, or - with wildcards). -* **Aren't certificates difficult to set up?** - * Let's Encrypt has developed a [simple, open-source - protocol](https://letsencrypt.org/howitworks/) for setting up - server certificates. [SSLMate](https://sslmate.com/) currently - provides a similar service for a fee. Services like - [Cloudflare](http://blog.cloudflare.com/introducing-universal-ssl/) - currently provide free SSL/TLS for sites hosted through them, - and hosting providers may start automating this for all users - once free certificates become common. - * For people who are happy without a custom domain, there are - various hosting options that support HTTPS with a free tier, - e.g. [GitHub Pages](https://pages.github.com/), blogging - services, [Google Sites](https://sites.google.com/), and [Google - App Engine](https://cloud.google.com/appengine/). As of 2018, - many hosting providers even support turning on HTTPS using a - single checkbox. -* **Isn't SSL/TLS slow?** - * [Not really](https://istlsfastyet.com/) (for almost all sites, - if they are following good practices). -* **Doesn't this break caching? Filtering?** - * If you're a site operator concerned about site load, there are - various secure CDN options available, starting as cheap as - [Cloudflare's free - tier](http://blog.cloudflare.com/introducing-universal-ssl/). - * For environments that need tight control of internet access, - there are several client-side/network solutions. For other - environments, we consider this kind of tampering a violation of - SSL/TLS security guarantees. -* **What about test servers/self-signed certificates?** - * Hopefully, free/simple certificate setup will be able to help - people who had previously considered it inconvenient. Also note - that [localhost is considered - secure](http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features), - even without HTTPS. - * As mentioned above, plain HTTP will continue to work. - -Also see [Mozilla's -FAQ](https://blog.mozilla.org/security/files/2015/05/HTTPS-FAQ.pdf) on this -topic for longer answers.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-narrow.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-narrow.png.sha1 deleted file mode 100644 index 093b1412032..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-narrow.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -01a0b44621eda085bc745e38b567a0346b8f4673
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-wide.png.sha1 b/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-wide.png.sha1 deleted file mode 100644 index 5e9a71fe401..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/marking-http-as-non-secure/phase-3-wide.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -cfa8f918d6561b8582c41f10c4a0e34494881a0d
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/mds/index.md b/chromium/docs/website/site/Home/chromium-security/mds/index.md deleted file mode 100644 index 5a7a3e68093..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/mds/index.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: mds -title: Microarchitectural Data Sampling ---- - -Microarchitectural Data Sampling - -# (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, and CVE-2019-11091) - -# Summary - -Microarchitectural Data Sampling (MDS) refers to a set of speculative execution -side-channel vulnerabilities which potentially allow results from previous -execution on a core to be observed across security boundaries via -microarchitectural state, on certain Intel CPUs. They are described in [Intel's -announcement](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html), -and referred to as -MSBDS/[CVE-2018-12126](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12126), -MLPDS/[CVE-2018-12127](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12127), -MFBDS/[CVE-2018-12130](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12130), -and -MDSUM/[CVE-2019-11091](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-11091). - -An attacker successfully exploiting these vulnerabilities could read sensitive -data from other processes running on the system, breaking the isolation between -processes provided by modern operating systems. If Chrome processes are -attacked, these sensitive data could include website contents as well as -passwords, credit card numbers, or cookies. - -Chrome, like all programs, relies on the operating system to provide isolation -between processes. Operating system vendors may release updates to improve -isolation, so users should ensure they install any updates and follow any -additional guidance from their operating system vendor in relation to MDS -mitigation. - -Some operating system mitigations will also require changes in Chrome which we -shall include in subsequent Chrome releases. Users should ensure their version -of Chrome is [always up to -date](https://support.google.com/chrome/answer/95414?co=GENIE.Platform%3DDesktop). - -## Response - -The Chrome team investigated various mitigation options Chrome could take -independently of the OS, but none were sufficiently complete or performant. -Users should rely on operating system level mitigations. - -### Android - -On the Android platform, the vast majority of devices are not affected, as these -issues only apply to some Intel-based systems. - -As always, Android users should apply updates for their devices as soon as they -are available from their OEM. - -### Chrome OS - -Chrome OS has disabled Hyper-Threading on Chrome OS 74 and subsequent versions. -This provides protection against attacks using MDS. [More details on Chrome OS's -response](/chromium-os/mds-on-chromeos). - -### macOS - -macOS Mojave 10.14.5 [includes MDS -mitigations](https://support.apple.com/en-us/HT210107). These have been adopted -by Chrome and will be included in Chrome 75 which will be released to the Stable -channel on or around the 4th of June. - -### Windows - -Windows users should apply updates with MDS mitigations as soon as they are -available, and [follow any guidance to adjust system settings if -appropriate](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190013). - -### iOS - -Apple iOS devices use CPUs not known to be vulnerable to MDS. - -### Linux - -Linux users should apply kernel and CPU microcode updates as soon as they are -available from their distribution vendor, and follow any guidance to adjust -system settings.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/memory-safety/index.md b/chromium/docs/website/site/Home/chromium-security/memory-safety/index.md deleted file mode 100644 index b04a7787718..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/memory-safety/index.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: memory-safety -title: Memory safety ---- - -The Chromium project finds that around 70% of our serious security bugs are -[memory safety -problems](https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/). -Our next major project is to prevent such bugs at source. - -## The problem - -Around 70% of our high severity security bugs are memory unsafety problems (that -is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. - -[<img alt="Pie chart of uses-after-free, other memory safety, other security -bug, security asserts" -src="/Home/chromium-security/memory-safety/piechart.png">](/Home/chromium-security/memory-safety/piechart.png) - -(Analysis based on 912 high or critical -[severity](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md) -security bugs since 2015, affecting the Stable channel.) - -These bugs are spread evenly across our codebase, and a high proportion of our -non-security stability bugs share the same types of root cause. As well as -risking our users’ security, these bugs have real costs in how we fix and ship -Chrome. - -## The limits of sandboxing - -Chromium’s [security architecture](/Home/chromium-security/guts) has always been -designed to assume that these bugs exist, and code is sandboxed to stop them -taking over the host machine. Over the past years that architecture has been -enhanced to [ensure that websites are isolated from one -another](/Home/chromium-security/site-isolation). That huge effort has allowed -us — just — to stay ahead of the attackers. But we are reaching the limits of -sandboxing and site isolation. - -A key limitation is that the process is the smallest unit of isolation, but -processes are not cheap. Especially on Android, using more processes impacts -device health overall: background activities (other applications and browser -tabs) get killed with far greater frequency. - -We still have processes sharing information about multiple sites. For example, -the network service is a large component written in C++ whose job is parsing -very complex inputs from any maniac on the network. This is what we call “the -doom zone” in our [Rule Of -2](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/rule-of-2.md) -policy: the network service is a large, soft target and -[vulnerabilities](https://googleprojectzero.blogspot.com/2020/02/several-months-in-life-of-part1.html) -there are of -[Critical](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md#TOC-Critical-severity) -severity. - -Just as Site Isolation improved safety by tying renderers to specific sites, we -can imagine doing the same with the network service: we could have many network -service processes, each tied to a site or (preferably) an origin. That would be -beautiful, and would hugely reduce the severity of network service compromise. -However, it would also explode the number of processes Chromium needs, with all -the efficiency concerns that raises. - -Meanwhile, our insistence on the [Rule Of -2](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/rule-of-2.md) -is preventing Chrome developers from shipping features, as it’s already -sometimes just too expensive to start a new process to handle untrustworthy -data. - -## Staying still is not an option - -We believe that: - - Attackers innovate, so defenders need to innovate just to keep pace. - - We can no longer derive sufficient innovation from more processes or - stronger sandboxes (though such things continue to be necessary). - - Therefore the cheapest way to maintain the advantage is to squash bugs at - source instead of trying to contain them later. - -## What we’re trying - -We’re tackling the memory unsafety problem — fixing classes of bugs at scale, -rather than merely containing them — by any and all means necessary, including: - -* Custom C++ libraries - * //base is already getting into shape for spatial memory safety. - * std and [Abseil](https://abseil.io/) assume correct callers ‘for - speed’, but can be modified to do basic checking with - implementation changes (Abseil) and compile-time flags (LLVM - libcxx). - * Generalizing [Blink’s C++ garbage - collector](https://docs.google.com/document/d/1Cv2IcsiokkGc2K_5FBTDKekNzTn3iTEUyi9fDOud9wU/edit#heading=h.i5ibcxqde9h2), - and using it more widely (starting with PDFium). -* Hardware mitigations, e.g. - [MTE](https://llvm.org/devmtg/2018-10/slides/Serebryany-Stepanov-Tsyrklevich-Memory-Tagging-Slides-LLVM-2018.pdf). - * Custom C++ dialect(s) - * Defined and enforced by LLVM plugins and presubmit checks. In - particular, we feel it [may be necessary to ban raw pointers - from - C++](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit#heading=h.jx7cpliyfer). -* Using safer languages anywhere applicable - * Java and Kotlin - * JavaScript - * [Rust](https://chromium-review.googlesource.com/c/chromium/src/+/2084087) - [(see our notes on C++ interoperability - here)](/Home/chromium-security/memory-safety/rust-and-c-interoperability) - * [Swift](https://chromium-review.googlesource.com/c/chromium/src/+/1904747) - * Others…? - -These options lie on a spectrum: - -[<img alt="Spectrum of options from lower cost & less improvement (e.g. C++ -library improvements) to higher cost and more improvement (e.g. Rust)" -src="/Home/chromium-security/memory-safety/sat3CHOc8lXZbGicChW6w5Q.png">](/Home/chromium-security/memory-safety/sat3CHOc8lXZbGicChW6w5Q.png) - -We expect this strategy will boil down to two major strands: - - Significant changes to the C++ developer experience, with some performance - impact. (For instance, no raw pointers, bounds checks, and garbage - collection.) - - An option of a programming language designed for compile-time safety checks - with less runtime performance impact — but obviously there is a cost to - bridge between C++ and that new language.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/memory-safety/piechart.png.sha1 b/chromium/docs/website/site/Home/chromium-security/memory-safety/piechart.png.sha1 deleted file mode 100644 index be8b06c8cd9..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/memory-safety/piechart.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -ea1b0e3fc4dd638d946bee931998373b7f17f884
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/memory-safety/rust-and-c-interoperability/index.md b/chromium/docs/website/site/Home/chromium-security/memory-safety/rust-and-c-interoperability/index.md deleted file mode 100644 index c7494d55782..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/memory-safety/rust-and-c-interoperability/index.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/memory-safety - - Memory safety -page_name: rust-and-c-interoperability -title: Rust and C++ interoperability ---- - -(written August 2020) - -Chrome engineers are experimenting with Rust. For the foreseeable future, C++ is -the reigning monarch in our codebase, and any use of Rust will need to fit in -with C++ — not the other way around. This seems to present some C++/Rust -interoperability challenges which nobody else has faced. - -We'd need to solve these before considering Rust as (nearly) a first-class -citizen in our codebase. If we can’t solve these, Rust would at best be isolated -to “leaf nodes” which don’t interact much with the rest of our codebase. And if -that’s all we can use Rust for, that calls into question whether the costs of an -extra language are justified in the first place. - -As C++ is the ruler, we are primarily concerned with the ability for new Rust -code to call into existing C++ code, rather than C++ to Rust calls. - -We think it’s important for Rust to be able to call C++ functions in a way that -meets the following **criteria**: - -**No need for the “unsafe” keyword unless something is known to be less safe than normal C++** - -For a Rustacean, this is controversial - all C++ is unsafe! But “unsafe” -should be a really bad code smell. If “unsafe” is needed for all C++ calls, -there will be thousands of them, and the “unsafe” keyword will lose its -meaning. Where objects are simply passed backwards and forwards between Rust -and C++, we must avoid the word ‘unsafe’. It should be restricted to patches -of genuinely unsafe Rust code, and for C++ interoperability code where -there’s shared ownership or other complexities. -This particular property is satisfied by dtolnay’s marvellous -[cxx](https://github.com/dtolnay/cxx) library already. - -**No overhead in the general case** - -LTO and [cross-language -inlining](http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html) -already solve this in principle. There are cases where overhead is necessary -at the C++ boundary — especially, the UTF check required when strings are -passed from C++ to Rust. This can be dealt with by handling such strings as -&\[u8\] in Rust code, until string manipulation is really necessary, so we -do not need any further innovations here. This box is checked. - -**No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist** - -If a C++ API exists, Rust should be able to call it. It’s that simple. The -declaration in C++ should be sufficient. There should be no need for an -allowlist, a redeclaration in Rust, or any Rust shim. Rare exceptions will -exist (e.g. overloaded functions) and in some cases we’ll want to make an -idiomatic Rust wrapper, but in general, that shouldn’t be necessary. -This is not just aesthetic preference. Our codebase is complex and polluting -it with extra annotations would be a small, but noticeable, tax on how -everyone works. - -**Broad type support - with safety** - -[cxx](https://github.com/dtolnay/cxx) is the current state-of-the-art for -safely exchanging data between C++ and Rust. Our -“[base](https://source.chromium.org/chromium/chromium/src/+/HEAD:base/)” -library exposes 1768 APIs which are used by other parts of Chrome. 1052 of -those functions only take parameters which are types that can already be -supported by cxx. 12 more are planned in the near term for cxx (e.g. more -flexible slices). -That’s ~60% of our APIs, which is good but not great. -Another 12% can be supported if we are able to pass std::string and similar -string types into existing C++ APIs. These can’t be represented in a Rust -struct due to an internal pointer, but as cxx generates code on both the C++ -and Rust side, it should be possible to own a UniquePtr<CxxString> on -the Rust side, yet [pass it into an existing C++ -API](https://github.com/dtolnay/cxx/issues/250) which takes a std::string by -value. -(That sounds fairly straightforward, but it becomes much more complex when -you’re talking about structs containing std::strings, such as -[url::Origin](https://source.chromium.org/chromium/chromium/src/+/HEAD:url/origin.h;l=141?q=url::Origin&ss=chromium%2Fchromium%2Fsrc). -Such a struct could only be owned as a UniquePtr<opaque type> from the -Rust side, which would prevent field access. Solutions can be imagined but -need more thought.) -Another ~20% are functions which take pointer parameters - in our case, -these are very often [out -parameters](https://source.chromium.org/chromium/chromium/src/+/HEAD:base/rand_util.h;l=40?q=base::RandBytes&sq=). -We need to see how we can programmatically identify those which are ‘simple’ -out parameters and allow Rust to populate them safely. -The good news is that this leaves just 8% of our functions which can’t be -supported by the cxx model of interop. Most of these are passing C++ structs -(by value) which have [raw pointers within -them](https://source.chromium.org/chromium/chromium/src/+/HEAD:base/memory/shared_memory_mapping.h;l=169?q=base::WritableSharedMemoryMapping). -This seems largely insoluble in Rust but they’re so rare that we can create -case-by-case idiomatic wrappers. -There are some caveats here: this analysis is based on symbols exported by -the binary, rather than source code analysis. In some cases these APIs would -be wrapped by inline functions, templates or macros, which this analysis -ignores. It also ignores return values and direct field access. And of -course, “base” isn’t the only set of APIs which our code would need to call -- it’s probably that higher-level functions would have [more complex -arguments on -average](https://source.chromium.org/chromium/chromium/src/+/HEAD:content/public/browser/render_frame_host.h;bpv=1;bpt=1;l=88?q=RenderFrameHost&gsn=RenderFrameHost&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_frame_host.h%23G1w6QPBQL82Xkcn4l7LDpzClmBPa_c18lFVVZbHK5h0&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fcontent_browser_client.h%23q1iJpNllgNKY5mVu_-89ZVL29Rk5wCUukrTj6kdjLOA&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fnavigation_controller.h%23xJPcd1uTfK8sLQidlLN1nkzka5MM8UOqJQ-vd1RMLUI&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fnavigation_handle.h%23Cla5SVTQ5b0yHjvdzazehvdZiPAwZPiL7hw9jGrMBMg&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_frame_host.h%23RenderFrameHost%253Acontent%2523c%2523dhOuyZmgB2x&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fweb_contents.h%23XrbufdRG9Y--Dfi3iq7WkPh30Aby0bBIixBApZ1fXG4&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fweb_contents_delegate.h%23xPu14kaNu58lQUD_9A9MEXyxUFs8Jibf73XNjZze6zM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fweb_contents_observer.h%23Gc6rUNIeosEK0hOGxwCGtN3e4cQRlW1pbI9SJnAffaY&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Ftest%2Fcontent_browser_test_utils.h%23KxzkBqHDzmvePnTKOrHQpGDfOD2Oy4yWL0xQ17sxS7g&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Ftest%2Ftest_utils.h%23EVUuAhYNNhFIy0tQc4euuLdHh_H2gYKx6Cde5mGUDdw&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fshell%2Fbrowser%2Fshell_platform_delegate.h%23JlDkk2QY2af2K98dJC7keSobXw9Lm7Vvr2DnHqWQpGM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_frame_host.h%23_RceGKzxaDRVeDDFRGV34cgVys-lQ22yR_wwBOBzXkI&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Fchromeos%2Flogin%2Ftest%2Fjs_checker.h%23r_Gj569ozVIUJq-1POIJ4-qqNaRvHC-N7_01P9qsSSc&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Ftask_manager%2Fproviders%2Fweb_contents%2Fweb_contents_task_provider.h%23m8QtJrZjgtNRJveh4olsmT3NIvAFrJmS62j1jaLIjVk&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Fui%2Fexclusive_access%2Ffullscreen_controller.h%232v5FtWIP5lic0jku3uPv0aA35WhmxS5zkZ32A3UXfsc&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fblocked_content%2Fpopup_blocker_tab_helper.h%23ZAwLD36-n3HV1_IIGmPbytosIMmfek4iFBO1CLfnwAI&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fpage_load_metrics%2Fbrowser%2Fobservers%2Flargest_contentful_paint_handler.h%23MGktmDqVePSQ5i5YsOaSyZQO_PsptqLzf_yMxl4Dyuk&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fpage_load_metrics%2Fbrowser%2Fpage_load_metrics_observer.h%23lb9A7wZugxQD54-kaHBU9xBztc_qtW0v7d_yxHFitMo&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fperformance_manager%2Fpublic%2Fperformance_manager.h%237RnPbKgruVz8UTqkRkQA5AJD6a87ucr-9eRsxXEQR_U&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fsubresource_filter%2Fcontent%2Fbrowser%2Fsubresource_filter_observer.h%23TXHYSiScLwmoB1m4zPDJABkqvxFdAWfy1Ex2IFX_daM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fbrowser%2Fcontent_index%2Fcontent_index_service_impl.h%23MhjsqAeDxF0FYJo_wllpmTcv6tuLPn_nPnwDJtbrGzs&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_document_host_user_data.h%23QFc-GZRe6mkj2fUPpd_OOzdlMfR9TPXA7kdFH2P0y0c&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_frame_host.h%23RenderFrameHost%253Acontent%2523c%2523bJIWE93K2Uw&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Frender_view_host.h%23j-yNEITJJhL9H_N7SAWIFM00eSi9Do5KqVHnnw6-wYY&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Ftest%2Fnavigation_simulator.h%23LdLUS0zBCndDaYelBCIrAtQAP5CjgrKoBWc4UkaDpPE&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fextensions%2Fbrowser%2Fapp_window%2Fapp_window.h%23cLpWpVzgBXk0gZyi-2THfz57SRACA-LHUveF0YbUgCg&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fextensions%2Fbrowser%2Fextension_function.h%23_Ogl2-DYz2iqCw9dhPLcqQwcXfV194_P3uWT2Fnkj-4&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fextensions%2Fbrowser%2Fprocess_manager.h%23fdDKt3wBoBo8B9ujQiKlNlTWllc9d6Nucx_LH5PyFg4&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Fbanners%2Fapp_banner_manager.h%236njZ8hjl2ANDhn7cc2_h2Obhvi0hty24_cozfCfXvP4&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Fdevtools%2Fdevtools_window.h%23UvVTsinMZfkvO_28gCFM_S742snUFO4dF9lUEBCOOzA&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Fbrowser%2Fui%2Fsearch%2Flocal_ntp_test_utils.h%23MFOhcxTDmwcb9ct68b2WSzYF6YDjdalt24KDHCBega8&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fautofill%2Fcontent%2Fbrowser%2Fcontent_autofill_driver_factory.h%232_1CXjN2hUKgzzlJeHBUY-03W_tFo-iunU62bByBM6s&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fpage_load_metrics%2Fbrowser%2Fobservers%2Fpage_load_metrics_observer_tester.h%23ek2Ilzd8IEKzZMxB7pfXiVtl3hub7QKlESaQXb9wefE&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fpayments%2Fcontent%2Fpayment_app_factory.h%23UXMzp2clHfiq_I9jqU5EYPV35LFAS4Qeb30UgiYYmPM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fbrowser%2Fweb_contents%2Fweb_contents_impl.h%23bGo7lh_Cz-AMlV0vnrg7N1hekIc2k69yWIXNjppwLvM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fdevtools_agent_host.h%23MVlcGNudSwRbhwAb7qjmDJ5EIF5RuWjJo6dcUqHEdwE&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fdevtools_manager_delegate.h%23fUonhxAGMNCMCnWgzJszvsBnMePO8z2cucV5m0H1gig&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fmedia_player_id.h%237GEQk0IkYgezyBz93D_esGwqUhoYfor4M2JjgzOkHKY&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fweb_ui_controller.h%23iktvwQuWbLO8hlEAR-DJYt9o0xju62S_9nfg7R7j2Kc&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Ftest%2Fweb_contents_tester.h%23zPltnaBNY45XLxRyREmM8T-NumTILcwnWNRC8FiI-ug&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fchrome%2Ftest%2Fpayments%2Fpayment_request_platform_browsertest_base.h%23H2AtSVUS0Q9k7jDXyRtrFB1Po_9evqkWUVvvo7NB6oM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fautofill%2Fcore%2Fbrowser%2Fautofill_client.h%2356w8agBOZjtRclF5Wfl-QJmO500HiS1mPke0i1kt91s&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcomponents%2Fpermissions%2Fpermission_request_id.h%23TutwfaiAmQOM6OkwwuX-_Hdp-H4pq5HSE0N5mqrhrxg&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fbrowser%2Fmedia%2Fforwarding_audio_stream_factory.h%23KgICheBanWRA3eZKFVxi-8bxZCOO4ujLJ-uUMvvordk&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fbrowser%2Frenderer_host%2Fmedia%2Frender_frame_audio_output_stream_factory.h%23kXXZI4k7E_bVhhmyaIbCYnCIOsddZlredLwzqVUEl14&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fbrowser%2Frenderer_host%2Frender_widget_host_owner_delegate.h%23KEHWC06-LjLVJcNPotW9smK0WoGIjQcjFcs3m6c3Jdw&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fcontent%2Fpublic%2Fbrowser%2Fback_forward_cache.h%23KU6Chs-FixtEn-uy4ELETeGq_e5amqVQ51_xw8jmwP4&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fextensions%2Fbrowser%2Fextension_function_dispatcher.h%23NlU0-Xo74M-G5-Eq_D2VfP9PAf4UX6pBv8o202lwdR8&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dsrc%2Fextensions%2Fbrowser%2Fprocess_manager_observer.h%23ypSAGYvQtRkkYdE3rjreepcXMaKO7JxH13lwLq6DGKQ) -so be less likely to fall in the ‘good’ bucket. - -**Ergonomics - with safety** - -From Rust code, we need to be able to instantiate C++ objects, safely pass -around ownership (there are no significant problems with cxx’s -[UniquePtr](https://docs.rs/cxx/0.3.4/cxx/struct.UniquePtr.html) here), call -methods on them (both plain and virtual). For “plain old data” types in C++, -containing simple, cxx-compatible fields, we need to be able to manipulate -those fields. Most of this can be achieved with cxx already (though we need -a way to call through to -[std::make_unique](https://github.com/dtolnay/cxx/issues/228) from Rust code -for a type that’s opaque to Rust). -We need this to be smooth enough that we do not need to wrap a typical C++ -type in a Rust wrapper. -So far, so good. But we also need: to act (at Rust build time) upon #defines -set up by our C++ headers and build-time rules, figure out a plan for -calling C++ overloaded functions and operators, call macros (e.g. LOG(ERROR) -<< “eek”), make templated functions and types available (possibly very -hard, though bindgen does a remarkably good job here), and probably many -other things we haven’t yet thought of. -It may be that the best way to handle some of these cases is some inline C++ -code within Rust (like the [cpp crate](https://crates.io/crates/cpp) but -with the benefit of cxx’s safety). -One specific challenge is [reference-counted -objects](https://source.chromium.org/chromium/chromium/src/+/HEAD:base/memory/scoped_refptr.h;l=175?q=scoped_refptr). -We need the reference count to be shared between referees on the Rust and -Chrome side. The bigger challenge here is how to deal with the prevalence of -multiple mutable references on the C++ side, without the ability to do -something like a -[RefCell::borrow_mut](https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.borrow_mut) -to ensure even runtime safety. It may be that we need to mark involvement -with all such reference-counted objects as truly ‘unsafe’ from the Rust -side. -In general we think we can live without Rust types inheriting from C++ -types, but there’s one exception: pure virtual observers. cxx provides the -ability to [pass function pointers from Rust to -C++](https://github.com/dtolnay/cxx#builtin-types), so it’s quite possible -for us to make wrapper types here. Ideally, though, this becomes ergonomic -and seamless as well. More investigation is needed here. - -**What we don’t need** - -We believe we can live without: self-referential C++ types being passed by value -into Rust (except for strings), Rust types inheriting from non-pure-virtual C++ -types; variadic arguments, “safe” reference counting. (There will be cases where -the absence of these features is annoying, but hopefully rare.) All this may be -wrong: we still have much learning to do. - -**Our plan** - -We think the hardest part of this is imagining a safe way to pass types between -Rust and C++. That requires auto-generated shim code on both the Rust and C++ -side. That’s already achieved by cxx with terrific emergent safety properties. -And so that’s our basic model. - -But, we don’t want to specify a cxx::bridge section for every API. We therefore -[need the cxx::bridge to be generated using a bindgen-like -tool](https://github.com/dtolnay/cxx/issues/235). - -We don’t believe Rust language changes are needed. Some C++ types can’t be owned -by value in Rust — for example std::string with its self-referential pointer — -but we believe that good C++ interoperability can be achieved even if Rust can -only own such objects by pointer. We may be wrong here as well! - -For now, Chrome investment in Rust will remain a background investigation -(mostly directed towards prototyping these tools and techniques). If we become -convinced this sort of interoperability is possible, we’ll revisit widespread -use of Rust in Chrome, and at that point we plan to work hard to achieve this -with robust production-quality solutions. - -(update September 2021) There's progress across the Rust community in solving -many of these problems - see for example -[moveit](https://crates.io/crates/moveit), -[autocxx](https://crates.io/crates/autocxx) and -[mosaic](https://github.com/google/mosaic/). diff --git a/chromium/docs/website/site/Home/chromium-security/memory-safety/sat3CHOc8lXZbGicChW6w5Q.png.sha1 b/chromium/docs/website/site/Home/chromium-security/memory-safety/sat3CHOc8lXZbGicChW6w5Q.png.sha1 deleted file mode 100644 index 0323cf48a8c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/memory-safety/sat3CHOc8lXZbGicChW6w5Q.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -2d2f7ec41a96280f6f0a0d5b389ce34c1b2c82b3
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/owp/index.md b/chromium/docs/website/site/Home/chromium-security/owp/index.md deleted file mode 100644 index 95457fa0a66..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/owp/index.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: owp -title: Web Platform Security ---- - -Developers should have the tools necessary to defend their creations against the -wide spectrum of maliciousness thrown at them on a daily basis. We design and -implement platform-level features that enable a robust defense, and work in -standards bodies to get them in front of as many developers as possible. - -[TOC] - -## Features we're working on - -### Content Security Policy - -We've shipped [Content Security Policy Level 2](http://www.w3.org/TR/CSP2/) as -of Chrome 42, and we're starting to put together the vision for the next -iteration of the standard. You can follow along at -<https://github.com/w3c/webappsec-csp>. Firefox has support for most of CSP2 as -well. - -### Subresource Integrity - -We've shipped [Subresource Integrity](http://www.w3.org/TR/SRI/) as of Chrome -46. This feature should also be shipping in Firefox ~43, which is exciting to -see. - -### Upgrade Insecure Requests - -We've shipped [Upgrade Insecure -Requests](http://www.w3.org/TR/upgrade-insecure-requests/) as of Chrome 44. This -feature should also be shipping in Firefox 42, which will give us a fairly broad -base of support. - -### Mixed Content - -We've been steadily tightening our [Mixed -Content](http://www.w3.org/TR/mixed-content/) blocking over the last ~18 months. -The specification has broad approval from other vendors, who are generally -aligning with Chrome's behavior over time. - -### Cookies - -We have a number of cookie-related proposals floating around that we're building -support for in the IETF's HTTPbis group: - - [Deprecating modification/creation of "Secure" cookies on non-secure - origins](https://tools.ietf.org/html/draft-west-leave-secure-cookies-along) - strengthen the security properties of cookies with the Secure attribute. - - [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) - cookies provide a defense against various forms of CSRF - - [Cookie Prefixes](https://tools.ietf.org/html/draft-west-cookie-prefixes) - might provide a mitigation for the integrity and confidentiality limitations - of cookies' delivery model. - - [Origin cookies](https://tools.ietf.org/html/draft-west-origin-cookies) are - a slightly more robust model than the prefix proposal, but also seem less - likely to be adopted, so. Belts and suspenders. - -### Credential Management - -We're working with Chrome's password manager team to define an imperative API -for interaction with the browser's stored credentials. The spec is progressing -nicely at <https://w3c.github.io/webappsec-cred» and the feature is mostly -implemented behind `chrome://flags/#enable-credential-manager-api`. > - -### Referrer Policy - -[Referrer Policy](https://w3c.github.io/webappsec-referrer-policy/) shipped in -Chrome a long time ago, and the new bits we've added to the spec are trickling -out over time. - -We need to do some refactoring in order to consistently apply referrer policy -for redirects (basically hoisting the parsing and processing up out of Blink and -into the network stack). Hopefully we'll get that done in Q4 (2015). - -### Secure Contexts - -[Secure Contexts](https://w3c.github.io/webappsec-secure-contexts/) underlies -our commitment to [prefer secure origins for powerful new -features](/Home/chromium-security/prefer-secure-origins-for-powerful-new-features). -We've shipped the concept of a "secure context" in Chrome, and are working over -time to [deprecate a set of APIs in insecure -contexts](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins). -`getUserMedia()` is unavailable over HTTP as of Chrome 47, and we've got our eye -on geolocation next. - -### Clear Site Data - -We've specified and implemented a feature to allow developers to clear out the -data a browser has stored for their origin at -<https://w3c.github.io/webappsec-clear-site-data/>. - -### Entry Point Regulation - -We've specified EPR as a defense against CSRF, and hope to get to a prototype -implementation soonish.(this hasn't made progress in a few years) - -## Come work with us! - -If any of the above work resonates with you, come help us! We're hiring in -Munich, Germany, which is [a wonderful place to work -indeed](https://www.google.com/about/careers/locations/munich/). There's a -[generic software engineering job -description](https://www.google.com/about/careers/search#!t=jo&jid=43144&), but -the best way to get noticed is probably to ping -[@mikewest](https://twitter.com/mikewest) on Twitter, or drop him an email at -[mkwst@google.com](mailto:mkwst@google.com).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/owp/web-platform-security-backlog/index.md b/chromium/docs/website/site/Home/chromium-security/owp/web-platform-security-backlog/index.md deleted file mode 100644 index 4d7368e1953..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/owp/web-platform-security-backlog/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/owp - - Web Platform Security -page_name: web-platform-security-backlog -title: Web Platform Security backlog ---- - diff --git a/chromium/docs/website/site/Home/chromium-security/pdfium-security/index.md b/chromium/docs/website/site/Home/chromium-security/pdfium-security/index.md deleted file mode 100644 index a2a0250a6c1..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/pdfium-security/index.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: pdfium-security -title: PDFium Security ---- - -Welcome to PDFium Security! - -## Basic Info - -* [PDFium project page](https://code.google.com/p/pdfium/) -* [PDFium Git repository](https://pdfium.googlesource.com/) -* [Known PDFium security - issues](https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3DInternals-Plugins-PDF+Type%3DBug-Security+&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&cells=tiles) - (Please pick 1 and fix it!) - -## Integer Overflow - -We want to standardize on handling integer overflows by: - -1. Preferring new\[\] and new instead of calloc, wherever possible. -2. In places where the code is not ready to be turned into idiomatic - C++, preferring calloc to malloc; definitely prefer calloc to malloc - + memset. -3. Preferring CheckedNumeric<T> to ad hoc checks. - * For convenience, use the existing typedefs for clarity, e.g. - typedef base::CheckedNumeric<FX_DWORD> FX_SAFE_DWORD;. If - you need more typedefs like this, or if you need them more - widely visible, don't hesitate to make the change. - -Yes, that might look odd. Currently, the codebase mixes C++ and C memory -allocation, and ultimately, we'd like to get the code to idiomatic C++11, but -we're going to get there incrementally. - -## Uninitialized Memory References - -We want to standardize on handling uninitialized memory references with: - -1. Default constructors that do the right thing. -2. Explicit initial values for all POD members in header files. - -## Git Workflow - -* The top line/subject line of the commit message should always be as - explicit as possible. Not just "fix bug", but "Fix UAF in - ModulateFooContainer" or "Fix UMR in thing::DoStuff". - -## Future Desiderata - -* No more non-const references (especially when used as - out-parameters). -* Use std::unique_ptr and pdfium::RetainPtr. No more naked new.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/pgp-key/index.md b/chromium/docs/website/site/Home/chromium-security/pgp-key/index.md deleted file mode 100644 index ae662d1eee3..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/pgp-key/index.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: pgp-key -title: PGP Key ---- - -Sensitive security bug reports should be filed on the [Chromium bug -tracker](https://bugs.chromium.org/p/chromium/issues/entry?template=Security+Bug). -Please make sure to select the Security template, as this will ensure the -correct access controls are in place. However, if you must use email to reach us -and wish to protect the message in transit, you can use this PGP key and send to -security@chromium.org - ------BEGIN PGP PUBLIC KEY BLOCK----- - -mQINBF+mFE8BEACiTDxAa0XtYKJrUc9WAnWKrDOHa8aC/aUNekS7fD64VqW6Y6Pf - -R60QRpcmlbeMBzPmSy9zosUjiTz/8qdd9cFscCA47OrU/9MV+tCXg3hWIeFH5d/o - -pDZ9pzzbuOGIVn0bgTjPuiA1IcK0o/bSbAv/fxAsnfhAyDnMLRXMtfviatczs4RA - -0WZwzkWR0VcNKKq17PW7EscMjQzuabbOnkzLmVgqphXRokwObT0++VwIaJV3lLNF - -B2rIyXXRM295Nm9JXgzi9/84jZNOzuKWqMNkMGxwLgLu4quACNHE5gvMn8d32UIn - -W34INIYp6OXECk3vfjXiQw6NrAqrmHw1+4AFEEqx29J3D1u0iiVzjvmKkOnaHSJZ - -PTyrZhwwesWIga2Q4v7TekLScMYEFhErxF+Hy9gMR+vIQ/kJHM8HT+mI5ws1sS0C - -FqlE8NhP4kRV4ktS6VnIynyrTarqp4mlQIsBwe+++fQLGruURjXQ8IlTesyVqV3n - -0hcCRWwym5+dmCMAqLCv25/Knqan6ENVbIevNys/4IJ+hBeQ2BZN15ZppN2fPP/3 - -k08hxXQT00L0KN2AXz1KkEg1t2A4zUyPG3Y+iTAwr/983HYrbvwxjU1ltBmZjFBf - -9lgUASGOzzdCjt1Eg2yqh4vCz/MKbK+Qs1E2CHWXsCXKkhHqFe7lX+mfewARAQAB - -tIRHb29nbGUgQ2hyb21lIFNlY3VyaXR5IFRlYW0gKFBsZWFzZSBwcmVmZXIgZmls - -aW5nIGEgc2VjdXJpdHkgYnVnIGF0IGNyYnVnLmNvbS9uZXcgb3ZlciB1c2luZyBQ - -R1AgYW5kIGVtYWlsLikgPHNlY3VyaXR5QGNocm9taXVtLm9yZz6JAlQEEwEKAD4W - -IQTXudUVq4807pWu3DxkbOcVMWuGOAUCX6YUTwIbAwUJBrxqAAULCQgHAwUVCgkI - -CwUWAgMBAAIeAQIXgAAKCRBkbOcVMWuGOMKyD/9Sd6KneK53YSq8+ThowntP95aF - -hC6fekIUit3pz8Z+fXUewaEvH1Q+pNiwIIIEsnsG0yUGl3Xq7WTWM3HrlfEvJL7v - -7ynlxwzN/1z9EviIlGIeNm4VkcrVEE5Gh1FR6Gyi+m/YXhMQlU6JLGJjF4VY37Cp - -3lEyb4R+7/7YCH307F5uoWRILWfyeJwTAVs8AFJne3J9ghVbWkIMvuTaL0JWzWnS - -+YhSE62THyXoi2OBj6ytW1gfiP3akJzYvfAlKjx2rbzGtVXsvrjRHJ87S8x7J0JM - -YoityTAcHqHuIYJnBnm0GIl1jFNMnGel+3W/2X6nfiIDCR0zP2YHH2FVRm1TSwh1 - -PEcPpEM2L/6h9F3niZ2HXLGGo+9R40dPUaapg4atU9qerqMHsXblv8c+lh2sgyNb - -MJtn6vRamh7MFRIel66WxTgvkWH3FWmB4XfGI+OCY0T7PU7EHp5CjrCaUosxnVa0 - -HRMkOGCEasYZTogM1Mzdqti6LcFUCEA7JFw2AZli7LG06vbCF9OOvmEgjWd7t1gC - -/GUS8iOrxoEjjyDrbkemz0fhNiiZLgCCveHUVHKsjZXd8qgFasUC3a+ISwd7h7/C - -YhEQFUzZvPzxJ5GFbY8n8rDsTMGkpT2UNI2FzZtlmFd1DVZUi8K5ZHHlCNrrZ/Ry - -a4cv3Z0lUTpS+in53YkCMwQQAQoAHRYhBIFN5ONXuKtQChzP96c4UdUywga2BQJf - -qtl5AAoJEKc4UdUywga2a6sP/2D3UCJvmCX+G+u//3q3D68i101X1EPfNix4Dlez - -FdUMD1mO3U3Xl0d42o9bJdJZrxmEuHpw4JAPB5jbGthJpgFdOl+ho50kt8ZI208C - -O2W+gJUdTb5NGV6g1rWR0EL+Gxtw+NgXDu8tmgQ7z4fzzuDnb2PFWPzS2o3+SnBI - -i1HNq/t+6bfUWtxe3XelPhaMLO12o52EOPTc2RB5JN7MMBR7510JmooUlQc6FJCl - -zGyhP6Aml7yNRkeGbVwBfh91jzDHrEUMClQ80pCO7Xa4sgjek3tajKC6EmE3UmPN - -u6T1MbEHCB9SCZZRWCg0Vjg5pHYLhAMxWAxiY4+kmDwVsBiWFwqKQ/tQj8tuTdl7 - -MMt7Ql+GWKs7PUEymhDRLn0V5ZL1goekXQnZ47nZ86v/JhGN87QH2x3R1JSdOufq - -i2FJQz8q7uLKAztp4SHTD9K/M2GYBdjlULHxeG7ROlQhDLE6YH+jSCnSBhDJvfHI - -LhwExNfUF6SadOD4cKjndiMqeo5UbQlqndy+ozLRVTOxgbT3UI+4hfv+twUDgRsH - -50D6ADKQ+n1BK45NzpSV0MV4EPUkQvG1TDE6bvVx9GBDlkE7IROTJT7N3pimtnwR - -IZ2q1hk7g+qsDH/29oaZRlWYwdA0Z1096Vt+ShaTO0mEf8CiAiHDSQgx5hWWQ2Cp - -70QPuQINBF+mFE8BEADYmBFQPhIgR8b97VXAm/El7/aPQ2p5d+G9qfh4x/VLycLN - -hMM5DHK0dR5JkzrT5LUPTYCaoKFH6GiKkTpw7iUc6BQjxdndrBjDuzaN9/Fhxqrf - -DllYZFCSNa1ezLeJNmnXZ/lBFtC6H6fyoWEbfwL08cCXc69XTh3+DLLCapfAkw7D - -QHrUvYFqIEiMen+Bj1xNPUlVuzOfjhxhjxeaaxmeBrTZF/zwZkB0NHUi43fHbf2A - -121rfqg4Banazzf/jgSxdUb8XnHDGqXrBq7sCXBpDHeHCJVqiY7r6DtBgeVbkoX/ - -uHowGaZ2UFlSlZwCBIdTe6rjcQt+eAOm/aV3W+Vl2sBjSD1XleLSGdzp2LXx7HLd - -53Er/vIe3di4Q5m9zQikML4Qvw/z0x/glDZc5aHoWlhOsqHUUOeExRfl+gaE3xOy - -xOQQYuy63+C3U++mi6qkYUEtpRoMFcJrkWuPNl4O7ldMLrUcEu7lGWCEptckpmZp - -yeX7XLH4VkkBGwXqYHA3pDSqpnoCA/UGhNO4mdQdU+I8cKrYitlAo9rNaLDxFgt7 - -BvOLwp215D37rOTnOOhovPhSImQsOSS9rZLW3tWAc+zmInBpAJK5V9S5AccuHXNr - -INymLBRGSSC/qYrluCSklAoCfmBETdWQwlPIf3FwxWkpcTGmapqd9mbm9AMe/wAR - -AQABiQI8BBgBCgAmFiEE17nVFauPNO6Vrtw8ZGznFTFrhjgFAl+mFE8CGwwFCQa8 - -agAACgkQZGznFTFrhjhE1g//Rbm1dVwTzado9AfGt5vhNGfkcBPW0e3S96JsYNU/ - -Fl2RE1iGAuFYq7YYmV+/Ha3g75sYzycWWbpV+6fie8ZGaWx5VRcaTrflajpbe7Nf - -Gku7XxZg7sDuoYeDtwgkORIxYBhKykbLlQGvSTdj+6PGs1cwmdKa+ENf/nJKWbnY - -Ow2Ua6EOL064x0Owkcy6Btig+VFxP92RvYqLGvTVPGUuojy9Oqp6pzpY7HglrBj5 - -WCVt06T86dL4Ua2Oaqr5gngntK7jbKkWCMzr6/A/t1zKj4c2ihYQspYFRt/llzxQ - -kwi9bOKi1RlqQPRp6b/VttNHbZ9F52Q/dKeCU1CN7K5CbcdL1w0ktPMOnIpiIc87 - -wtd4dNqKBImc3rDf+dMP95HdJGznHg37Tzosukj4ocHEsNoi3JoXbbbHjFMuSqgI - -+72IGvc8r1PkpBMfYjQeLWCdntreE/kfmADCW6XmdVdzb7bMmA7ez6hofWbyhjTy - -LRugMg669WQi4r4NnTudSgXcMWJbwI69UIrWKVeBFHQlR4TXymSD1hrEWsFz0e6r - -Ta+ekKm2nFiUgh2JdzFiQe4Uf9/nGcLgIQAKZQ1q7VV5lN6J6hjCCyr0RxReuYy9 - -EvceYjRLs1bP3DKliHVyMmcNMU7u8GuSCMU8Tb3T4WlGDhsxyieeabGPkj8XZE3O - -ZF0= - -=8ojo - ------END PGP PUBLIC KEY BLOCK-----
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/prefer-secure-origins-for-powerful-new-features/index.md b/chromium/docs/website/site/Home/chromium-security/prefer-secure-origins-for-powerful-new-features/index.md deleted file mode 100644 index 998207fafd2..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/prefer-secure-origins-for-powerful-new-features/index.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: prefer-secure-origins-for-powerful-new-features -title: Prefer Secure Origins For Powerful New Features ---- - -We (Chrome Security) originally sent this out to various browser development -mailing lists. Here is the canonical location for the original proposal. See -[this link](https://www.w3.org/TR/powerful-features/) for the current public -draft spec. - -**This is a living document** — as we learn more, we'll probably need to change -this page. - -## Proposal - -The Chrome Security team and I propose that, for new and particularly -powerful web platform features, browser vendors tend to prefer to make -the the feature available only to secure origins by default. - -## Definitions - -“Particularly powerful” would mean things like: features that handle -personally-identifiable information, features that handle high-value information -like credentials or payment instruments, features that provide the origin with -control over the UA's trustworthy/native UI, access to sensors on the user's -device, or generally any feature that we would provide a user-settable -permission or privilege to. Please discuss! - -“Particularly powerful” would **not** mean things like: new rendering and layout -features, CSS selectors, innocuous JavaScript APIs like *showModalDialog*, or -the like. I expect that the majority of new work in HTML5 fits in this category. -Please discuss! - -“Secure origins” are origins that match at least one of the following (scheme, -host, port) patterns: - -* `(https, *, *)` -* `(wss, *, *)` -* `(*, localhost, *)` -* `(*, 127/8, *)` -* `(*, ::1/128, *)` -* `(file, *, —)` -* `(chrome-extension, *, —)` - -This list may be incomplete, and may need to be changed. Please discuss! -A bug to define “secure transport” in Blink/Chromium: -<https://code.google.com/p/chromium/issues/detail?id=362214> - -## For Example - -For example, Chrome is going to make Service Workers available only to secure -origins, because it provides the origin with a new, higher degree of control -over a user's interactions with the origin over an extended period of time, and -because it gives the origin some control over the user's device as a background -task. - -Consider the damage that could occur if a user downloaded a service worker -script that had been tampered with because they got it over a MITM’d or spoofed -cafe wifi connection. What should have been a nice offline document editor could -be turned into a long-lived spambot, or maybe even a surveillance bot. If the -script can only run when delivered via authenticated, integrity-protected -transport like HTTPS, that particular risk is significantly mitigated. - -## Background - -Legacy platforms/operating systems have a 1-part principal: the user. When a -user logs in, they run programs that run with the full privilege of the user: -all of a user’s programs can do anything the user can do on all their data and -with all their resources. This has become a source of trouble since the rise of -mobile code from many different origins. It has become less and less acceptable -for a user’s (e.g.) word processor to (e.g.) read the user’s private SSH keys. - -Modern platforms have a 2-part security principal: the user, and the origin of -the code. Examples of such modern platforms include (to varying degrees) the -web, Android, and iOS. In these systems, code from one origin has (or, should -have) access only to the resources it creates and which are explicitly given to -it. - -For example, the Gmail app on Android has access only to the user’s Gmail and -the system capabilities necessary to read and write that email. Without an -explicit grant, it does not have access to resources that other apps (e.g. -Twitter) create. It also does not have access to system capabilities unrelated -to email. Nor does it have access to the email of another user on the same -computer. - -In systems with 2-part principals, it is crucial to strongly authenticate both -parts of the principal, not just one part. (Otherwise, the system essentially -degrades into a 1-part principal system.) This is why, for example, both Android -and iOS require that every vendor (i.e. origin) cryptographically sign its code. -That way, when a user chooses to install Twitter and to give Twitter powerful -permissions (such as access to the device’s camera), they can be sure that they -are granting such capability only to the Twitter code, and not to just any code. - -By contrast, the web has historically made origin authentication optional. On -the web, origins are defined as having 3 parts: (scheme, host, port), e.g. -(HTTP, [example.com](http://example.com/), 80) or (HTTPS, -[mail.google.com](http://mail.google.com/), 443). Many origins use -unauthenticated schemes like HTTP, WS, or even FTP. - -Granting permissions to unauthenticated origins is, in the presence of a network -attacker, equivalent to granting the permissions to any origin. The state of the -internet is such that we must indeed assume that a network attacker is present. - -## Thank You For Reading This Far! - -We welcome discussion, critique, and cool new features!
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/pwnium-2/index.md b/chromium/docs/website/site/Home/chromium-security/pwnium-2/index.md deleted file mode 100644 index 6b572ba3c7f..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/pwnium-2/index.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: pwnium-2 -title: Pwnium 2 ---- - -**Chromium Security Reward Program** - -**Pwnium2@HITBSecConf2012 Official Rules** - -**The Pwnium2@HITBSecConf2012 Chromium Security Reward Program ("Program") is designed to encourage involvement in improving the security of the Chromium project. Participants submit original and unreported exploits relying on security bugs in Chrome alone, or Chrome coupled with Flash / Windows / other software like drivers (an “Exploit”). Rewards will be awarded to participants who submit full and reliable Exploits (or Incomplete Exploits as described below) with critical impact as determined in the sole discretion of the Judges. NO PURCHASE NECESSARY TO ENTER OR WIN. VOID WHERE PROHIBITED.** -**SPONSOR: The Program is sponsored by Google Inc. (“Google” or "Sponsor"), a Delaware corporation with principal place of business at 1600 Amphitheatre Parkway, Mountain View, CA, 94043, USA.** -**BINDING AGREEMENT: In order to enter the Program, you must agree to these Official Rules (“Rules”). Therefore, please read these Rules prior to entry and submission to ensure you understand and agree. You agree that submission of an Exploit in the Program constitutes agreement to these Rules. You may not submit an Exploit to the Program and are not eligible to receive the rewards described in these Rules unless you agree to these Rules. These Rules form a binding legal agreement between you and Google with respect to the Program.** -**ELIGIBILITY: To be eligible to enter the Program, you must be above the age of majority in the country, state, province or jurisdiction of residence (or at least twenty years old in Taiwan) at the time of submission (“You” or “Entrant”). The Program is void in, and not open to residents of, Cuba, Iran, Syria, North Korea or Sudan or to individuals and entities restricted by U.S. export controls and sanctions, and is void in any other nation, state, or province where prohibited or restricted by U.S. or local law.** -**Employees, interns, contractors, and official office-holders of Google and their subsidiaries, affiliates, and their respective directors, officers, employees, advertising and promotion agencies, representatives, and agents (“Program Entities”), and members of the Program Entities’ and their immediate families (parents, siblings, children, spouses, and life partners of each, regardless of where they live) and members of the households (whether related or not) of such employees, officers and directors are ineligible to participate in the Program. Google reserves the right to verify eligibility and to adjudicate on any dispute at any time. If you are entering as part of a company or on behalf of your employer, these rules are binding on you, individually, and/or your employer. If you are acting within the scope of your employment, as an employee, contractor, or agent of another party, you warrant that such party has full knowledge of your actions and has consented thereto, including your potential receipt of a reward. You further warrant that your actions do not violate your employer’s or company’s policies and procedures.** -**PROGRAM PERIOD: The Program begins at 10:00 A.M. local time (in Kuala Lumpur, Malaysia) at the HITBSecConf2012 on October 10, 2012 and ends at 2:00 P.M. local time on October 10, 2012 (“Program Period”). Google may extend the Program Period in its sole discretion. ENTRANTS ARE RESPONSIBLE FOR DETERMINING THE CORRESPONDING TIME ZONE IN THEIR RESPECTIVE JURISDICTIONS.** -**HOW TO ENTER: NO PURCHASE NECESSARY TO ENTER OR WIN. To enter the Program, visit the Google desk at HITBSecConf2012 in Kuala Lumpur, Malaysia during the Program Period. Entrants are entirely responsible for all costs and fees associated with attending the HITBSecConf2012, including (but not limited to) admission fees, transportation, accommodation and living costs. For additional information visit the Program website located at <https://www.chromium.org/Home/chromium-security/pwnium-2> before or during the Program Period and follow the instructions for submitting an Exploit that highlights a critical importance security issue, which has not yet been reported to, or otherwise come to attention of, the Chromium project. The Exploit must meet the “Exploit Requirements,” described below. All entries must be received before the end of the Program Period. Entries are void if they are in whole or part illegible, incomplete, damaged, altered, counterfeit, obtained through fraud, or late. All entries will be deemed made by the authorized account holder of the email address submitted at the time of submission, and potential reward recipients may be required to show proof of being the authorized account holder for that email address. The "authorized account holder" is the natural person assigned to an email address by an Internet service provider, online service provider, or other organization responsible for assigning email address for the domain.** -**EXPLOIT REQUIREMENTS: The Exploit must meet the following criteria:** -**• Be an unreported and original exploit, which has not been shared or partially shared with anyone else or submitted in any other contests until it has been submitted to, and judged by, Google.** -**• Be an exploit relying on an unreported and original bug, bugs or security feature in Chrome or in Chrome when used in connection with Windows, Flash or other software e.g. drivers.** -**• Be a remote exploit accessible through the Chrome browser, which works and is reliable.** -**• Be present in the most recent supported channel(s) of Chrome, running on the latest version of Windows7 on the provided test machine.** -**• Be a critical vulnerability of high impact.** -**• Be authored or created by You.** -**• Be submitted with corresponding documentation that details each bug exploited.** -**During the Program Period, Google and/or its agents will be evaluating each Exploit to ensure that it meets the Exploit Requirements. Google reserves the right, in its sole discretion, to disqualify any entrant who submits an Exploit that does not meet the Exploit Requirements.** -**JUDGING: Each Exploit submission will be judged by a panel of experts who are employees of Google (“Judges”). Each Exploit will be evaluated by the Judges as to whether the Exploit is a critical importance vulnerability of high impact based on the potential for persistent access to the user’s account on the Windows operating system.** -**Judges will evaluate each Exploit based upon the above criteria to determine whether it is critical impact and qualifies for a reward. Rewards will be allocated on a first-come-first-served basis, based on time of submission during the Program Period specified above, until such time as the total reward pool of $2,000,000 USD (two million U.S. dollars) is exhausted.** -**In the event a potential reward recipient is disqualified for any reason, the reward allocated to that recipient will be returned to the total reward pool. The potential reward recipients will be selected and notified by telephone and/or email, at Sponsor’s discretion. If a potential reward recipient does not respond to the notification attempt within five days from the first notification attempt, then such potential recipient may be disqualified and their allocated reward will be returned to the total reward pool. With respect to notification by telephone, such notification will be deemed given when the potential reward recipient engages in a live conversation with Sponsor or when a message is left on the potential reward recipient’s voicemail service or answering machine by the Sponsor, whichever occurs first. Except where prohibited by law, each potential reward recipient may be required to sign and return a Declaration of Eligibility and Liability and Publicity Release and provide any additional information that may be required by Sponsor. If required, potential reward recipients must return all such required documents within seven days following attempted notification or such potential reward recipient may be deemed to have forfeited the reward and the reward may be returned to the total reward pool. In the event the potential reward recipient is a minor, his or her parent or legal guardian must sign the documents and return them as described herein. All notification requirements, as well as other requirements within these Rules, will be strictly enforced. In the event that no Exploits are received, no rewards will be awarded. Determinations of judges are final and binding.** -**REWARDS:** -**An Entrant submitting an Exploit demonstrating a critical importance high impact Chrome / Win7 local OS user account persistence using only bugs in Chrome itself (a “Full Chrome Exploit”), as determined in the sole discretion of the Judges, will receive a reward of $60,000 USD (sixty thousand U.S. dollars).** -**An Entrant submitting an Exploit demonstrating a critical importance high impact Chrome / Win7 local OS user account persistence using at least one bug in Chrome plus bugs in other software (e.g. a WebKit bug combined with a Windows kernel bug) (a “Partial Chrome Exploit”), as determined in the sole discretion of the Judges, will receive a reward of $50,000 USD (fifty thousand U.S. dollars).** -**An Entrant submitting an Exploit demonstrating a critical importance high impact Chrome / Win7 local OS user account persistence using only bugs not found in Chrome (e.g. bugs in Flash / Windows / drivers) (a “Non Chrome Exploit”), as determined in the sole discretion of the Judges, will receive a reward of $40,000 USD (forty thousand U.S. dollars).** -**An Entrant submitting an unreliable or incomplete Exploit demonstrating a critical importance high impact Chrome / Win7 local OS user account persistence (e.g. code execution inside a sandbox but not sandbox escape; or sandbox escape in isolation) (a “Incomplete Exploit”), as determined in the sole discretion of the Judges, may receive a reward in an amount to be determined by the judges.** -**Each reward recipient will also receive a ChromeOS netbook, provided they reside in a country to which ChromeOS netbooks can be legally shipped.** -**All rewards are contingent on Entrant's compliance with these Rules. The rewards will be awarded within approximately two weeks of receipt by Sponsor of final reward acceptance documents. No transfer, substitution or cash equivalent for rewards is allowed, except at Sponsor’s sole discretion. Sponsor reserves the right to substitute a reward, in whole or in part, of equal or greater monetary value if a reward cannot be awarded, in whole or in part, as described for any reason. Value is subject to market conditions, which can fluctuate and any difference between actual market value and ARV will not be awarded. The reward(s) may be subject to restrictions and/or licenses and may require additional hardware, software, service, or maintenance to use. The reward recipient shall bear all responsibility for use of the rewards(s) in compliance with any conditions imposed by such manufacturer(s), and any additional costs associated with its use, service, or maintenance. Program Entities have not made and Program Entities are not responsible in any manner for any warranties, representations, or guarantees, express or implied, in fact or law, relating to the reward(s), regarding the use, value or enjoyment of the reward(s), including, without limitation, its quality, mechanical condition, merchantability, or fitness for a particular purpose, with the exception of any standard manufacturer's warranty that may apply to the reward or any components thereto.** -**TAXES: PAYMENTS TO POTENTIAL REWARD RECIPIENTS ARE SUBJECT TO THE EXPRESS REQUIREMENT THAT THEY SUBMIT TO GOOGLE ALL DOCUMENTATION REQUESTED BY GOOGLE TO PERMIT IT TO COMPLY WITH ALL APPLICABLE STATE, FEDERAL, LOCAL, PROVINCIAL AND FOREIGN TAX REPORTING AND WITHHOLDING REQUIREMENTS. ALL REWARDS WILL BE NET OF ANY TAXES GOOGLE IS REQUIRED BY LAW TO WITHHOLD. ALL TAXES IMPOSED ON REWARDS ARE THE SOLE RESPONSIBILITY OF THE REWARD RECIPIENTS.** -**In order to receive a reward, potential reward recipients must submit the tax documentation requested by Google or otherwise required by applicable law, to Google or the relevant tax authority, all as determined by applicable law, including, where relevant, the law of the potential recipient’s country of residence. The potential reward recipients are responsible for ensuring that (s)he complies with all the applicable tax laws and filing requirements. If a potential reward recipient fails to provide such documentation or comply with such laws, the reward may be forfeited and Google may, in its sole discretion, return the reward to the total reward pool.** -**GENERAL CONDITIONS: All federal, state, provincial and local laws and regulations apply. Google reserves the right to disqualify any entrant from the Program if, in Google’s sole discretion, it reasonably believes that the entrant has attempted to undermine the legitimate operation of the Program by cheating, deception, or other unfair playing practices or annoys, abuses, threatens or harasses any other entrants, Google, or the Judges.** -**INTELLECTUAL PROPERTY RIGHTS: As between Google and the entrant, the entrant retains ownership of all intellectual and industrial property rights (including moral rights) in and to the Exploit. As a condition of submission, entrant grants Google, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Exploit (1) for the purposes of allowing Google and the Judges to evaluate the Exploit for purposes of the Program, (2) for the purposes of evaluating the Exploit and improving Google and third party products, services, systems and networks and (3) in connection with advertising and promotion via communication to the public or other groups, including, but not limited to, the right to make screenshots, animations and Exploit clips available for promotional purposes.** -**PRIVACY: Participants agree that personal data entered during the registration, including name, mailing address, phone number, and email address may be processed, stored, shared and otherwise used for the purposes and within the context of the Program. This data will also be stored in / transferred into the United States. By entering, entrants agree to the transmission, processing, sharing and storage of this personal data in the United States. Participants also understand this data may be used by Sponsor in order to verify an Entrant’s identity, postal address and telephone number in the event a submission qualifies for a reward. Participants have the right to access, review, rectify or cancel any personal data held by Google in connection with the Program by writing to Google at the address listed above. If a participant does not provide the data require at registration, that participant’s submission will be ineligible. Otherwise, all personal information that is collected from the entrant is subject to Google’s Privacy Policy, located at http://www.google.com/privacy.html. By accepting a reward, participant agrees and consents to Google and its agencies use of entrant’s name and/or likeness to name the entrant for a reasonable time after completion of the Program in promotional and advertising material of Google (or its agents) as a recipient of a reward of the Program without additional compensation, unless prohibited by law. For residents of the EU: pursuant to EU law pertaining to data collection and processing, you are informed that: - the data controller is Google and the data recipients are Google and its agents; - your data is collected for purposes of administration of the Program and for marketing purposes; - you have a right of access to and withdrawal of your personal data. You also have a right of opposition to the data collection, under certain circumstances. To exercise such right, you may write to security@chromium.org.** -**PUBLICITY: By accepting a reward, Entrant agrees to Sponsor and its agencies use of his or her name and/or likeness and Exploit for advertising and promotional purposes without additional compensation, unless prohibited by law.** -**WARRANTY AND INDEMNITY: Participants warrant that their Exploits are their own original work and, as such, they are the sole and exclusive owner and rights holder of the submitted Exploit and that they have the right to submit the Exploit in the Program and grant all required licenses. Each entrant agrees not to submit any Exploit that (1) infringes any third party proprietary rights, intellectual property rights, industrial property rights, personal or moral rights or any other rights, including without limitation, copyright, trademark, patent, trade secret, privacy, publicity or confidentiality obligations; or (2) otherwise violates the applicable state, federal, provincial or local law.** -**To the maximum extent permitted by law, each Entrant indemnifies and agrees to keep indemnified Sponsor at all times from and against any liability, claims, demands, losses, damages, costs and expenses resulting from any act, default or omission of the Entrant and/or a breach of any warranty set forth herein. To the maximum extent permitted by law, each Entrant agrees to defend, indemnify and hold harmless the Sponsor from and against any and all claims, actions, suits or proceedings, as well as any and all losses, liabilities, damages, costs and expenses (including reasonable attorneys fees) arising out of or accruing from (a) any or other material uploaded or otherwise provided by the entrant that infringes any copyright, trademark, trade secret, trade dress, patent or other intellectual property right of any person or defames any person or violates their rights of publicity or privacy, (b) any misrepresentation made by the entrant in connection with the Program; (c) any non-compliance by the entrant with these Rules; (d) claims brought by persons or entities other than the parties to these Rules arising from or related to the Entrant’s involvement with the Program; (e) acceptance, possession, misuse or use of any reward or participation in any Program-related activity or participation in this Program; (f) any malfunction or other problem with the Program site; (g) any error in the collection, processing, or retention of submission information; or (h) any typographical or other error in the printing, offering or announcement of any reward or reward recipients.** -**ELIMINATION: Any false information provided within the context of the Program by any Entrant concerning identity, mailing address, telephone number, email address, ownership of right or non-compliance with these Rules or the like may result in the immediate elimination of the entrant from the Program.** -**NETWORK: Sponsor is not responsible for any malfunction of the entire Program site or any late, lost, damaged, misdirected, incomplete, illegible, undeliverable, or destroyed Exploits due to system errors, failed, incomplete or garbled computer or other telecommunication transmission malfunctions, hardware or software failures of any kind, lost or unavailable network connections, typographical or system/human errors and failures, technical malfunction(s) of any telephone network or lines, cable connections, satellite transmissions, servers or providers, or computer equipment, traffic congestion on the Internet or at the Program site, or any combination thereof, including other telecommunication, cable, digital or satellite malfunctions which may limit an entrant’s ability to participate.** -**RIGHT TO CANCEL, MODIFY OR DISQUALIFY: If for any reason the Program is not capable of running as planned, including infection by computer virus, bugs, tampering, unauthorized intervention, fraud, technical failures, or any other causes which corrupt or affect the administration, security, fairness, integrity, or proper conduct of the Program, Google reserves the right at its sole discretion to cancel, terminate, modify or suspend the Program. Google further reserves the right to disqualify any entrant who tampers with the submission process or any other part of the Program or Program site. Any attempt by an entrant to deliberately damage any web site, including the Program site, or undermine the legitimate operation of the Program is a violation of criminal and civil laws and should such an attempt be made, Google reserves the right to seek damages from any such entrant to the fullest extent of the applicable law.** -**NOT AN OFFER OR CONTRACT OF EMPLOYMENT: Under no circumstances shall the submission of a Exploit into the Program, the awarding of a reward, or anything in these Rules be construed as an offer or contract of employment with either Google, or any other Program entities. You acknowledge that you have submitted your Exploit voluntarily and not in confidence or in trust. You acknowledge that no confidential, fiduciary, agency or other relationship or implied-in-fact contract now exists between you and Google or any other Program entities and that no such relationship is established by your submission of an Exploit under these Rules.** -**FORUM AND RECOURSE TO JUDICIAL PROCEDURES: These Rules shall be governed by, subject to, and construed in accordance with the laws of the State of California, United States of America, excluding all conflict of law rules. If any provision(s) of these Rules are held to be invalid or unenforceable, all remaining provisions hereof will remain in full force and effect. To the extent permitted by law, the rights to litigate, seek injunctive relief or make any other recourse to judicial or any other procedure in case of disputes or claims resulting from or in connection with this Program are hereby excluded, and all Participants expressly waive any and all such rights.** -**ARBITRATION: By entering the Program, you agree that exclusive jurisdiction for any dispute, claim, or demand related in any way to the Program will be decided by binding arbitration. All disputes between you and Google of whatsoever kind or nature arising out of these Rules, shall be submitted to Judicial Arbitration and Mediation Services, Inc. (“JAMS”) for binding arbitration under its rules then in effect in the San Jose, California, USA area, before one arbitrator to be mutually agreed upon by both parties. The parties agree to share equally in the arbitration costs incurred.** -**REWARD RECIPIENT’S LIST: Reward recipients will be posted on the Program site -for three months following the conclusion of the Program.** diff --git a/chromium/docs/website/site/Home/chromium-security/pwnium-3/index.md b/chromium/docs/website/site/Home/chromium-security/pwnium-3/index.md deleted file mode 100644 index 72da8df7721..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/pwnium-3/index.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: pwnium-3 -title: Pwnium 3 ---- - -**Chromium Security Reward Program** - -**Pwnium3@CanSecWest2013 Official Rules** - -**The Pwnium3@CanSecWest2013 Chromium Security Reward Program ("Program") is designed to encourage involvement in improving the security of the Chromium project. Participants submit original and unreported exploits relying on security bugs in Chrome OS including Chrome coupled with Flash / Chrome OS kernel and firmware / default apps on Chrome OS (an “Exploit”). Rewards will be awarded to participants who submit full and reliable Exploits (or Incomplete Exploits as described below) with critical impact as determined in the sole discretion of the Judges. NO PURCHASE NECESSARY TO ENTER OR WIN. VOID WHERE PROHIBITED.** -**SPONSOR: The Program is sponsored by Google Inc. (“Google” or "Sponsor"), a Delaware corporation with principal place of business at 1600 Amphitheatre Parkway, Mountain View, CA, 94043, USA.** -**BINDING AGREEMENT: In order to enter the Program, you must agree to these Official Rules (“Rules”). Therefore, please read these Rules prior to entry and submission to ensure you understand and agree. You agree that submission of an Exploit in the Program constitutes agreement to these Rules. You may not submit an Exploit to the Program and are not eligible to receive the rewards described in these Rules unless you agree to these Rules. These Rules form a binding legal agreement between you and Google with respect to the Program.** -**ELIGIBILITY: To be eligible to enter the Program, you must be above the age of majority in the country, state, province or jurisdiction of residence (or at least twenty years old in Taiwan) at the time of submission (“You” or “Entrant”). The Program is void in, and not open to residents of, Cuba, Iran, Syria, North Korea or Sudan or to individuals and entities restricted by U.S. export controls and sanctions, and is void in any other nation, state, or province where prohibited or restricted by U.S. or local law.** -**Employees, interns, contractors, and official office-holders of Google and their subsidiaries, affiliates, and their respective directors, officers, employees, advertising and promotion agencies, representatives, and agents (“Program Entities”), and members of the Program Entities’ and their immediate families (parents, siblings, children, spouses, and life partners of each, regardless of where they live) and members of the households (whether related or not) of such employees, officers and directors are ineligible to participate in the Program. Google reserves the right to verify eligibility and to adjudicate on any dispute at any time. If you are entering as part of a company or on behalf of your employer, these rules are binding on you, individually, and/or your employer. If you are acting within the scope of your employment, as an employee, contractor, or agent of another party, you warrant that such party has full knowledge of your actions and has consented thereto, including your potential receipt of a reward. You further warrant that your actions do not violate your employer’s or company’s policies and procedures.** -**PROGRAM PERIOD: The Program begins at 10:00 A.M. local time (in Vancouver, Canada) at the CanSecWest 2013 on March 7th, 2013 and ends at 2:00 P.M. local time on March 7th, 2013 (“Program Period”). Google may extend the Program Period in its sole discretion. ENTRANTS ARE RESPONSIBLE FOR DETERMINING THE CORRESPONDING TIME ZONE IN THEIR RESPECTIVE JURISDICTIONS.** -**HOW TO ENTER: NO PURCHASE NECESSARY TO ENTER OR WIN. To enter the Program, visit the Google desk at CanSecWest 2013 in Vancouver, Canada during the Program Period. Entrants are entirely responsible for all costs and fees associated with attending the CanSecWest 2013, including (but not limited to) admission fees, transportation, accommodation and living costs. For additional information visit the Program website located at <https://www.chromium.org/Home/chromium-security/pwnium-3> before or during the Program Period and follow the instructions for submitting an Exploit that highlights a critical importance security issue, which has not yet been reported to, or otherwise come to attention of, the Chromium project. The Exploit must meet the “Exploit Requirements,” described below. All entries must be received before the end of the Program Period. Entries are void if they are in whole or part illegible, incomplete, damaged, altered, counterfeit, obtained through fraud, or late. All entries will be deemed made by the authorized account holder of the email address submitted at the time of submission, and potential reward recipients may be required to show proof of being the authorized account holder for that email address. The "authorized account holder" is the natural person assigned to an email address by an Internet service provider, online service provider, or other organization responsible for assigning email address for the domain.** -**EXPLOIT REQUIREMENTS: The Exploit must meet the following criteria:** -**• Be an unreported and original exploit, which has not been shared or partially shared with anyone else or submitted in any other contests until it has been submitted to, and judged by, Google.** -**• Be an exploit relying on an unreported and original bug, bugs or security feature in Chrome OS, Flash or other software e.g. drivers.** -**• Be an attack that’s demonstrated against a base (WiFi) model of the Samsung Series 5 550 Chromebook, running the latest stable version of Chrome OS.** -**• Be a remote exploit accessible through the Chrome browser, which works and is reliable.** -**• Be present in the most recent supported channel(s) of Chrome OS.** -**• Be a critical vulnerability of high impact.** -**• Be authored or created by You.** -**• Be submitted with corresponding documentation that details each bug exploited.** -**During the Program Period, Google and/or its agents will be evaluating each Exploit to ensure that it meets the Exploit Requirements. Google reserves the right, in its sole discretion, to disqualify any entrant who submits an Exploit that does not meet the Exploit Requirements.** -**JUDGING: Each Exploit submission will be judged by a panel of experts who are employees of Google (“Judges”). Each Exploit will be evaluated by the Judges as to whether the Exploit is a critical importance vulnerability of high impact based on the potential for persistent access to the user’s account or Guest mode on the Chrome operating system.** -**Judges will evaluate each Exploit based upon the above criteria to determine whether it is critical impact and qualifies for a reward. Rewards will be allocated on a first-come-first-served basis, based on time of submission during the Program Period specified above, until such time as the total reward pool of $3,141,592 USD (PI million U.S. dollars) is exhausted.** -**In the event a potential reward recipient is disqualified for any reason, the reward allocated to that recipient will be returned to the total reward pool. The potential reward recipients will be selected and notified by telephone and/or email, at Sponsor’s discretion. If a potential reward recipient does not respond to the notification attempt within five days from the first notification attempt, then such potential recipient may be disqualified and their allocated reward will be returned to the total reward pool. With respect to notification by telephone, such notification will be deemed given when the potential reward recipient engages in a live conversation with Sponsor or when a message is left on the potential reward recipient’s voicemail service or answering machine by the Sponsor, whichever occurs first. Except where prohibited by law, each potential reward recipient may be required to sign and return a Declaration of Eligibility and Liability and Publicity Release and provide any additional information that may be required by Sponsor. If required, potential reward recipients must return all such required documents within seven days following attempted notification or such potential reward recipient may be deemed to have forfeited the reward and the reward may be returned to the total reward pool. In the event the potential reward recipient is a minor, his or her parent or legal guardian must sign the documents and return them as described herein. All notification requirements, as well as other requirements within these Rules, will be strictly enforced. In the event that no Exploits are received, no rewards will be awarded. Determinations of judges are final and binding.** -**REWARDS:** -**An Entrant submitting an Entry demonstrating an exploit against Chrome OS delivered via a web page and triggerable when browsing in Guest mode and affecting all subsequent Guest mode sessions across reboots (“persistent Guest-to-Guest exploit”) using bugs in Chrome OS, as determined in the sole discretion of the Judges, will receive a reward of $150,000 USD (one hundred and fifty thousand U.S. dollars).** -**An Entrant submitting an Exploit demonstrating a critical importance high impact Chrome browser level compromise delivered via a web page using only bugs in Chrome OS as determined in the sole discretion of the Judges, will receive a reward of $110,000 USD (one hundred and ten thousand U.S. dollars).** -**Each reward recipient will also receive a Chromebook, provided they reside in a country to which Chromebooks can be legally shipped.** -**All rewards are contingent on Entrant's compliance with these Rules. The rewards will be awarded within approximately two weeks of receipt by Sponsor of final reward acceptance documents. No transfer, substitution or cash equivalent for rewards is allowed, except at Sponsor’s sole discretion. Sponsor reserves the right to substitute a reward, in whole or in part, of equal or greater monetary value if a reward cannot be awarded, in whole or in part, as described for any reason. Value is subject to market conditions, which can fluctuate and any difference between actual market value and ARV will not be awarded. The reward(s) may be subject to restrictions and/or licenses and may require additional hardware, software, service, or maintenance to use. The reward recipient shall bear all responsibility for use of the rewards(s) in compliance with any conditions imposed by such manufacturer(s), and any additional costs associated with its use, service, or maintenance. Program Entities have not made and Program Entities are not responsible in any manner for any warranties, representations, or guarantees, express or implied, in fact or law, relating to the reward(s), regarding the use, value or enjoyment of the reward(s), including, without limitation, its quality, mechanical condition, merchantability, or fitness for a particular purpose, with the exception of any standard manufacturer's warranty that may apply to the reward or any components thereto.** -**TAXES: PAYMENTS TO POTENTIAL REWARD RECIPIENTS ARE SUBJECT TO THE EXPRESS REQUIREMENT THAT THEY SUBMIT TO GOOGLE ALL DOCUMENTATION REQUESTED BY GOOGLE TO PERMIT IT TO COMPLY WITH ALL APPLICABLE STATE, FEDERAL, LOCAL, PROVINCIAL AND FOREIGN TAX REPORTING AND WITHHOLDING REQUIREMENTS. ALL REWARDS WILL BE NET OF ANY TAXES GOOGLE IS REQUIRED BY LAW TO WITHHOLD. ALL TAXES IMPOSED ON REWARDS ARE THE SOLE RESPONSIBILITY OF THE REWARD RECIPIENTS.** -**In order to receive a reward, potential reward recipients must submit the tax documentation requested by Google or otherwise required by applicable law, to Google or the relevant tax authority, all as determined by applicable law, including, where relevant, the law of the potential recipient’s country of residence. The potential reward recipients are responsible for ensuring that (s)he complies with all the applicable tax laws and filing requirements. If a potential reward recipient fails to provide such documentation or comply with such laws, the reward may be forfeited and Google may, in its sole discretion, return the reward to the total reward pool.** -**GENERAL CONDITIONS: All federal, state, provincial and local laws and regulations apply. Google reserves the right to disqualify any entrant from the Program if, in Google’s sole discretion, it reasonably believes that the entrant has attempted to undermine the legitimate operation of the Program by cheating, deception, or other unfair playing practices or annoys, abuses, threatens or harasses any other entrants, Google, or the Judges.** -**INTELLECTUAL PROPERTY RIGHTS: As between Google and the entrant, the entrant retains ownership of all intellectual and industrial property rights (including moral rights) in and to the Exploit. As a condition of submission, entrant grants Google, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Exploit (1) for the purposes of allowing Google and the Judges to evaluate the Exploit for purposes of the Program, (2) for the purposes of evaluating the Exploit and improving Google and third party products, services, systems and networks and (3) in connection with advertising and promotion via communication to the public or other groups, including, but not limited to, the right to make screenshots, animations and Exploit clips available for promotional purposes.** -**PRIVACY: Participants agree that personal data entered during the registration, including name, mailing address, phone number, and email address may be processed, stored, shared and otherwise used for the purposes and within the context of the Program. This data will also be stored in / transferred into the United States. By entering, entrants agree to the transmission, processing, sharing and storage of this personal data in the United States. Participants also understand this data may be used by Sponsor in order to verify an Entrant’s identity, postal address and telephone number in the event a submission qualifies for a reward. Participants have the right to access, review, rectify or cancel any personal data held by Google in connection with the Program by writing to Google at the address listed above. If a participant does not provide the data require at registration, that participant’s submission will be ineligible. Otherwise, all personal information that is collected from the entrant is subject to Google’s Privacy Policy, located at http://www.google.com/privacy.html. By accepting a reward, participant agrees and consents to Google and its agencies use of entrant’s name and/or likeness to name the entrant for a reasonable time after completion of the Program in promotional and advertising material of Google (or its agents) as a recipient of a reward of the Program without additional compensation, unless prohibited by law. For residents of the EU: pursuant to EU law pertaining to data collection and processing, you are informed that: - the data controller is Google and the data recipients are Google and its agents; - your data is collected for purposes of administration of the Program and for marketing purposes; - you have a right of access to and withdrawal of your personal data. You also have a right of opposition to the data collection, under certain circumstances. To exercise such right, you may write to security@chromium.org.** -**PUBLICITY: By accepting a reward, Entrant agrees to Sponsor and its agencies use of his or her name and/or likeness and Exploit for advertising and promotional purposes without additional compensation, unless prohibited by law.** -**WARRANTY AND INDEMNITY: Participants warrant that their Exploits are their own original work and, as such, they are the sole and exclusive owner and rights holder of the submitted Exploit and that they have the right to submit the Exploit in the Program and grant all required licenses. Each entrant agrees not to submit any Exploit that (1) infringes any third party proprietary rights, intellectual property rights, industrial property rights, personal or moral rights or any other rights, including without limitation, copyright, trademark, patent, trade secret, privacy, publicity or confidentiality obligations; or (2) otherwise violates the applicable state, federal, provincial or local law.** -**To the maximum extent permitted by law, each Entrant indemnifies and agrees to keep indemnified Sponsor at all times from and against any liability, claims, demands, losses, damages, costs and expenses resulting from any act, default or omission of the Entrant and/or a breach of any warranty set forth herein. To the maximum extent permitted by law, each Entrant agrees to defend, indemnify and hold harmless the Sponsor from and against any and all claims, actions, suits or proceedings, as well as any and all losses, liabilities, damages, costs and expenses (including reasonable attorneys fees) arising out of or accruing from (a) any or other material uploaded or otherwise provided by the entrant that infringes any copyright, trademark, trade secret, trade dress, patent or other intellectual property right of any person or defames any person or violates their rights of publicity or privacy, (b) any misrepresentation made by the entrant in connection with the Program; (c) any non-compliance by the entrant with these Rules; (d) claims brought by persons or entities other than the parties to these Rules arising from or related to the Entrant’s involvement with the Program; (e) acceptance, possession, misuse or use of any reward or participation in any Program-related activity or participation in this Program; (f) any malfunction or other problem with the Program site; (g) any error in the collection, processing, or retention of submission information; or (h) any typographical or other error in the printing, offering or announcement of any reward or reward recipients.** -**ELIMINATION: Any false information provided within the context of the Program by any Entrant concerning identity, mailing address, telephone number, email address, ownership of right or non-compliance with these Rules or the like may result in the immediate elimination of the entrant from the Program.** -**NETWORK: Sponsor is not responsible for any malfunction of the entire Program site or any late, lost, damaged, misdirected, incomplete, illegible, undeliverable, or destroyed Exploits due to system errors, failed, incomplete or garbled computer or other telecommunication transmission malfunctions, hardware or software failures of any kind, lost or unavailable network connections, typographical or system/human errors and failures, technical malfunction(s) of any telephone network or lines, cable connections, satellite transmissions, servers or providers, or computer equipment, traffic congestion on the Internet or at the Program site, or any combination thereof, including other telecommunication, cable, digital or satellite malfunctions which may limit an entrant’s ability to participate.** -**RIGHT TO CANCEL, MODIFY OR DISQUALIFY: If for any reason the Program is not capable of running as planned, including infection by computer virus, bugs, tampering, unauthorized intervention, fraud, technical failures, or any other causes which corrupt or affect the administration, security, fairness, integrity, or proper conduct of the Program, Google reserves the right at its sole discretion to cancel, terminate, modify or suspend the Program. Google further reserves the right to disqualify any entrant who tampers with the submission process or any other part of the Program or Program site. Any attempt by an entrant to deliberately damage any web site, including the Program site, or undermine the legitimate operation of the Program is a violation of criminal and civil laws and should such an attempt be made, Google reserves the right to seek damages from any such entrant to the fullest extent of the applicable law.** -**NOT AN OFFER OR CONTRACT OF EMPLOYMENT: Under no circumstances shall the submission of a Exploit into the Program, the awarding of a reward, or anything in these Rules be construed as an offer or contract of employment with either Google, or any other Program entities. You acknowledge that you have submitted your Exploit voluntarily and not in confidence or in trust. You acknowledge that no confidential, fiduciary, agency or other relationship or implied-in-fact contract now exists between you and Google or any other Program entities and that no such relationship is established by your submission of an Exploit under these Rules.** -**FORUM AND RECOURSE TO JUDICIAL PROCEDURES: These Rules shall be governed by, subject to, and construed in accordance with the laws of the State of California, United States of America, excluding all conflict of law rules. If any provision(s) of these Rules are held to be invalid or unenforceable, all remaining provisions hereof will remain in full force and effect. To the extent permitted by law, the rights to litigate, seek injunctive relief or make any other recourse to judicial or any other procedure in case of disputes or claims resulting from or in connection with this Program are hereby excluded, and all Participants expressly waive any and all such rights.** -**ARBITRATION: By entering the Program, you agree that exclusive jurisdiction for any dispute, claim, or demand related in any way to the Program will be decided by binding arbitration. All disputes between you and Google of whatsoever kind or nature arising out of these Rules, shall be submitted to Judicial Arbitration and Mediation Services, Inc. (“JAMS”) for binding arbitration under its rules then in effect in the San Jose, California, USA area, before one arbitrator to be mutually agreed upon by both parties. The parties agree to share equally in the arbitration costs incurred.** -**REWARD RECIPIENT’S LIST: Reward recipients will be posted on the Program site -for three months following the conclusion of the Program.** diff --git a/chromium/docs/website/site/Home/chromium-security/pwnium-4/index.md b/chromium/docs/website/site/Home/chromium-security/pwnium-4/index.md deleted file mode 100644 index 09eff14b35b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/pwnium-4/index.md +++ /dev/null @@ -1,364 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: pwnium-4 -title: Pwnium 4 ---- - -Pwnium4@CanSecWest2014 - -Chromium Security Reward Program - -Official Rules - -NO PURCHASE NECESSARY TO ENTER OR WIN. VOID WHERE PROHIBITED. CONTEST IS OPEN TO -RESIDENTS OF THE 50 UNITED STATES, THE DISTRICT OF COLUMBIA AND WORLDWIDE, -EXCEPT FOR RESIDENTS OF ITALY, BRAZIL, QUEBEC, CUBA, IRAN, SYRIA, NORTH KOREA, -and SUDAN. - -ENTRY IN THIS CONTEST CONSTITUTES YOUR ACCEPTANCE OF THESE OFFICIAL RULES. - -The Pwnium4@CanSecWest2014 Chromium Security Reward Program ("Program") is a -skill contest designed to encourage involvement in improving the security of the -Chromium project. Entrants submit original and unreported exploits relying on -security bugs in Chrome OS including Chrome coupled with Flash / Chrome OS -kernel and firmware / default apps on Chrome OS (an “Exploit”). The Exploits -entrants develop will be evaluated by judges, who will award rewards to entrants -who submit full and reliable Exploits (or Incomplete Exploits, as described -below) with critical impact as determined in the sole discretion of the Judges. - -1. BINDING AGREEMENT: In order to enter the Program, you must agree to these -Official Rules (“Rules”). Therefore, please read these Rules prior to entry to -ensure you understand and agree. You agree that submission of an Exploit in the -Program constitutes agreement to these Rules. You may not submit an Exploit to -the Program and are not eligible to receive the rewards described in these Rules -unless you agree to these Rules. These Rules form a binding legal agreement -between you and Google with respect to the Program. - -2. ELIGIBILITY: To be eligible to enter the Program, you must be: (1) above the -age of majority in the country, state, province or jurisdiction of residence (or -at least twenty years old in Taiwan) at the time of entry; (2) not a resident of -Italy, Brazil, Quebec, Cuba, Iran, Syria, North Korea, or Sudan; (3) not a -person or entity under U.S. export controls or sanctions; and (4) have access to -the Internet as of January 23rd, 2014. Contest is void in Italy, Brazil, Quebec, -Cuba, Iran, Syria, North Korea, Sudan), and where prohibited by law. - -Employees, interns, contractors, and official office-holders of Google, and -their parent companies, subsidiaries, affiliates, and their respective -directors, officers, employees, advertising and promotion agencies, -representatives, and agents (“Program Entities”), and members of the Program -Entities’ and their immediate families (parents, siblings, children, spouses, -and life partners of each, regardless of where they live) and members of the -households (whether related or not) of such employees, officers and directors -are ineligible to participate in the Program. Google reserves the right to -verify eligibility and to adjudicate on any dispute at any time. - -If you are entering as part of a company or on behalf of your employer, these -rules are binding on you, individually, and/or your employer. If you are acting -within the scope of your employment, as an employee, contractor, or agent of -another party, you warrant that such party has full knowledge of your actions -and has consented thereto, including your potential receipt of a reward. You -further warrant that your actions do not violate your employer’s or company’s -policies and procedures. - -3. SPONSOR: The Program is sponsored by Google Inc. (“Google” or "Sponsor"), a -Delaware corporation with principal place of business at 1600 Amphitheatre -Parkway, Mountain View, CA, 94043, USA. - -4. PROGRAM PERIOD: The Program begins at 10:00:00 A.M. Pacific Time (PT) Zone -(in Vancouver, Canada) at CanSecWest 2014 on March 12th, 2014 and ends at -12:00:00 P.M. PT on March 12th, 2014 (“Program Period”). Google may extend the -Program Period in its sole discretion. ENTRANTS ARE RESPONSIBLE FOR DETERMINING -THE CORRESPONDING TIME ZONE IN THEIR RESPECTIVE JURISDICTIONS. - -5. HOW TO ENTER: NO PURCHASE NECESSARY TO ENTER OR WIN. To enter the Program, -register before 5:00:00 P.M. PST (Pacific Standard Time) on Monday, March 10th, -2014 by sending an email with your name to -[pwnium4@chromium.org](mailto:pwnium4@chromium.org), and then visit the Google -desk at CanSecWest 2014 in Vancouver, Canada during the Program Period. Entrants -will be assigned a specific timeslot on March 12th, 2014 during which they may -demonstrate Exploits to the Judges. Exploits must be demonstrated during -entrant’s assigned time to be eligible for a reward, and must meet the “Exploit -Requirements,” described below. - -Entrants are entirely responsible for all costs and fees associated with -entrant’s participation in the Program and attending the CanSecWest 2014, -including (but not limited to) admission fees, transportation, accommodation and -living costs. All entries must be received before the end of the Program Period. -Entries are void if they are in whole or part illegible, incomplete, damaged, -altered, counterfeit, obtained through fraud, or late. All entries will be -deemed made by the authorized account holder of the email address submitted at -the time of submission, and potential reward recipients may be required to show -proof of being the authorized account holder for that email address. The -"authorized account holder" is the natural person assigned to an email address -by an Internet service provider, online service provider, or other organization -responsible for assigning email address for the domain. - -EXPLOIT REQUIREMENTS: The Exploit must meet the following criteria: - -• Be an unreported and original exploit, which has not been shared or partially -shared with anyone else or submitted in any other contests. - -• Be an exploit relying on an unreported and original bug, bugs or security -feature in Chrome OS, Flash or other software e.g. drivers. - -• Be an attack that’s demonstrated against a base (WiFi) model of the ARM-based -HP Chromebook 11, running the latest stable version of Chrome OS; or a 2GB WiFi -model of the Acer C720 Intel Chromebook, running the latest stable version of -Chrome OS. - -• Be a remote exploit accessible through the Chrome browser, which works and is -reliable. - -• Be served from a password-authenticated and HTTPS-supported Google property, -such as Google App Engine. - -• Be present in the most recent supported channel(s) of Chrome OS. - -• Be a critical vulnerability of high impact. - -• Be authored or created by You. - -• Be submitted with corresponding documentation that details each bug exploited. - -During the Program Period, Google, its agents, and/or the Judges (defined below) -will be evaluating each Exploit to ensure that it meets the Exploit -Requirements. Google reserves the right, in its sole discretion, to disqualify -any entrant who submits an Exploit that does not meet the Exploit Requirements. - -6. JUDGING: Each Exploit submission will be judged by a panel of experts who are -employees of Google (“Judges”). Each Exploit will be evaluated by the Judges as -to whether the Exploit is a critical importance vulnerability of high impact, -based on the potential for persistent access to the user’s account or guest mode -on the Chrome operating system. - -Judges will evaluate each Exploit based upon the above criteria to determine -whether it is critical impact and qualifies for a reward. - -If a potential reward recipient is disqualified for any reason, the reward -allocated to that recipient will be returned to the total reward pool. On or -about March 17th, 2014, the potential reward recipients will be selected and -notified by telephone and/or email, at Sponsor’s discretion. If a potential -reward recipient does not respond to the notification attempt within five days -from the first notification attempt, then such potential reward recipient may be -disqualified and the allocated reward will be returned to the total reward pool. -With respect to notification by telephone, such notification will be deemed -given when the potential reward recipient engages in a live conversation with -Sponsor or when a message is left on the potential reward recipient’s voicemail -service or answering machine by the Sponsor, whichever occurs first. Except -where prohibited by law, each potential reward recipient may be required to sign -and return a Declaration of Eligibility and Liability and Publicity Release and -provide any additional information that may be required by Sponsor. If required, -potential reward recipients must return all such required documents within seven -days following attempted notification or such potential reward recipient may be -deemed to have forfeited the reward and the reward may be returned to the total -reward pool. All notification requirements, as well as other requirements within -these Rules, will be strictly enforced. In the event no Exploits are received, -no rewards will be awarded. Determinations of judges are final and binding. - -7. REWARDS: Rewards for eligible Exploits will be allocated to eligible entrants -on a first-come-first-served basis, based on time of submission during the -Program Period specified above, until such time as the total reward pool of -$2.71828 million USD is exhausted: - -An entrant submitting an Exploit demonstrating a Chrome OS system-level -compromise delivered via a web page and triggerable when browsing in Guest mode -and affecting all subsequent Guest mode sessions across reboots (“persistent -Guest-to-Guest exploit”) using bugs in Chrome OS, as determined in the sole -discretion of the Judges, will receive a reward of $150,000 USD (one hundred and -fifty thousand U.S. dollars). - -An entrant submitting an Exploit demonstrating a Chrome browser-level compromise -delivered via a web page using bugs in Chrome OS as determined in the sole -discretion of the Judges, will receive a reward of $110,000 USD (one hundred and -ten thousand U.S. dollars). - -Google reserves the right to issue partial rewards, in its sole discretion, for -partial, incomplete or unreliable Exploits. Google may also consider issuing -significant bonuses for any Entrant who demonstrates a particularly impressive -or surprising exploit. - -Each reward recipient will also receive a Chromebook, provided such reward -recipient resides in a country where Chromebooks are legally available. - -Odds of winning any reward depends on the number of eligible entries received -during the Program Period and the skill of the entrants. The rewards will be -awarded within approximately two weeks of receipt by Sponsor of final reward -acceptance documents. No transfer, substitution or cash equivalent for rewards -is allowed, except at Sponsor’s sole discretion. Sponsor reserves the right to -substitute a reward, in whole or in part, of equal or greater monetary value if -a reward cannot be awarded, in whole or in part, as described for any reason. -Value is subject to market conditions, which can fluctuate and any difference -between actual market value and ARV will not be awarded. The reward(s) may be -subject to restrictions and/or licenses and may require additional hardware, -software, service, or maintenance to use. The reward recipient shall bear all -responsibility for use of the rewards(s) in compliance with any conditions -imposed by such manufacturer(s), and any additional costs associated with its -use, service, or maintenance. Program Entities have not made and Program -Entities are not responsible in any manner for any warranties, representations, -or guarantees, express or implied, in fact or law, relating to the reward(s), -regarding the use, value or enjoyment of the reward(s), including, without -limitation, its quality, mechanical condition, merchantability, or fitness for a -particular purpose, with the exception of any standard manufacturer's warranty -that may apply to the reward or any components thereto. - -9. TAXES: PAYMENTS TO POTENTIAL REWARD RECIPIENTS ARE SUBJECT TO THE EXPRESS -REQUIREMENT THAT THEY SUBMIT TO GOOGLE ALL DOCUMENTATION REQUESTED BY GOOGLE TO -PERMIT IT TO COMPLY WITH ALL APPLICABLE STATE, FEDERAL, LOCAL, AND FOREIGN -(INCLUDING PROVINCIAL) TAX REPORTING AND WITHHOLDING REQUIREMENTS. ALL REWARDS -WILL BE NET OF ANY TAXES GOOGLE IS REQUIRED BY LAW TO WITHHOLD. ALL TAXES -IMPOSED ON REWARDS ARE THE SOLE RESPONSIBILITY OF THE REWARD RECIPIENTS. In -order to receive a reward, potential reward recipients must submit the tax -documentation requested by Google or otherwise required by applicable law, to -Google or the relevant tax authority, all as determined by applicable law, -including, where relevant, the law of the potential recipient’s country of -residence. The potential reward recipients are responsible for ensuring that -(s)he complies with all the applicable tax laws and filing requirements. If a -potential reward recipient fails to provide such documentation or comply with -such laws, the reward may be forfeited and Google may, in its sole discretion, -return the reward to the total reward pool. - -10. GENERAL CONDITIONS: All federal, state, provincial and local laws and -regulations apply. Google reserves the right to disqualify any entrant from the -Program if, in Google’s sole discretion, it reasonably believes that the entrant -has attempted to undermine the legitimate operation of the Program by cheating, -deception, or other unfair playing practices or annoys, abuses, threatens or -harasses any other entrants, Google, or the Judges. - -11. INTELLECTUAL PROPERTY RIGHTS: As between Google and the entrant, the entrant -retains ownership of all intellectual and industrial property rights (including -moral rights) in and to the Exploit. By submitting an Exploit to the Program, -the entrant warrants and represents that he or she owns all of the intellectual -and industrial property rights in and to the Exploit. As a condition of -submission, entrant grants Google, its subsidiaries, agents and partner -companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive -license to use, reproduce, adapt, modify, publish, distribute, publicly perform, -create a derivative work from, and publicly display the Exploit (1) for the -purposes of allowing Google and the Judges to evaluate the Exploit for purposes -of the Program, (2) for the purposes of evaluating the Exploit and improving -Google and third party products, services, systems and networks and (3) in -connection with advertising and promotion via communication to the public or -other groups, including, but not limited to, the right to make screenshots, -animations and Exploit clips available for promotional purposes. - -12. PRIVACY: Entrant acknowledges and agrees that Google may collect, store, -share and otherwise use personally identifiable information provided during the -registration process and the Program, including, but not limited to, name, -mailing address, phone number, and email address. Google will use this -information in accordance with its Privacy Policy -(<http://www.google.com/policies/privacy/>), including for administering the -Program and verifying Participant’s identity, postal address and telephone -number in the event an entry qualifies for a reward. - -Participant’s information may also be transferred to countries outside the -country of participant's residence, including the United States. Such other -countries may not have privacy laws and regulations similar to those of the -country of participant's residence. - -If a participant does not provide the mandatory data required at registration, -Google reserves the right to disqualify the entry. - -Participant has the right to request access, review, rectification or deletion -of any personal data held by Google in connection with the Contest by writing to -Google at this email address: security@chromium.org. - -13. PUBLICITY: By accepting a reward, entrant agrees to Sponsor and its agencies -use of his or her name and/or likeness and Exploit for advertising and -promotional purposes without additional compensation, unless prohibited by law. - -14. WARRANTY AND INDEMNITY: Entrants warrant that their Exploits are their own -original work and, as such, they are the sole and exclusive owner and rights -holder of the submitted Exploit and that they have the right to submit the -Exploit in the Program and grant all required licenses. Each entrant agrees not -to submit any Exploit that (1) infringes any third party proprietary rights, -intellectual property rights, industrial property rights, personal or moral -rights or any other rights, including without limitation, copyright, trademark, -patent, trade secret, privacy, publicity or confidentiality obligations; or (2) -otherwise violates the applicable state, federal, provincial or local law. - -To the maximum extent permitted by law, each entrant indemnifies and agrees to -keep indemnified Sponsor at all times from and against any liability, claims, -demands, losses, damages, costs and expenses resulting from any act, default or -omission of the entrant and/or a breach of any warranty set forth herein. To the -maximum extent permitted by law, each entrant agrees to defend, indemnify and -hold harmless the Sponsor from and against any and all claims, actions, suits or -proceedings, as well as any and all losses, liabilities, damages, costs and -expenses (including reasonable attorneys fees) arising out of or accruing from -(a) any Esploit or other material uploaded or otherwise provided by the entrant -that infringes any copyright, trademark, trade secret, trade dress, patent or -other intellectual property right of any person or defames any person or -violates their rights of publicity or privacy, (b) any misrepresentation made by -the entrant in connection with the Program; (c) any non-compliance by the -entrant with these Rules; (d) claims brought by persons or entities other than -the parties to these Rules arising from or related to the entrant’s involvement -with the Program; (e) acceptance, possession, misuse or use of any prize, or -participation in any Program-related activity or participation in this Program; -(f) any malfunction or other problem with the Program site; (g) any error in the -collection, processing, or retention of submission information; or (h) any -typographical or other error in the printing, offering or announcement of any -reward or reward recipients. - -15. ELIMINATION: Any false information provided within the context of the -Program by any entrant concerning identity, mailing address, telephone number, -email address, ownership of right or non-compliance with these Rules or the like -may result in the immediate elimination of the entrant from the Program. - -16. INTERNET: Sponsor is not responsible for any malfunction of the entire -Program site or any late, lost, damaged, misdirected, incomplete, illegible, -undeliverable, or destroyed Exploits or entry materials due to system errors, -failed, incomplete or garbled computer or other telecommunication transmission -malfunctions, hardware or software failures of any kind, lost or unavailable -network connections, typographical or system/human errors and failures, -technical malfunction(s) of any telephone network or lines, cable connections, -satellite transmissions, servers or providers, or computer equipment, traffic -congestion on the Internet or at the Program site, or any combination thereof, -including other telecommunication, cable, digital or satellite malfunctions -which may limit a participant’s ability to participate. - -17. RIGHT TO CANCEL, MODIFY OR DISQUALIFY: If for any reason the Program is not -capable of running as planned, including infection by computer virus, bugs, -tampering, unauthorized intervention, fraud, technical failures, or any other -causes which corrupt or affect the administration, security, fairness, -integrity, or proper conduct of the Program, Google reserves the right at its -sole discretion to cancel, terminate, modify or suspend the Program. Google -further reserves the right to disqualify any entrant who tampers with the -submission process or any other part of the Program or Program site. Any attempt -by an entrant to deliberately damage any web site, including the Program site, -or undermine the legitimate operation of the Program is a violation of criminal -and civil laws and should such an attempt be made, Google reserves the right to -seek damages from any such entrant to the fullest extent of the applicable law. - -18. NOT AN OFFER OR CONTRACT OF EMPLOYMENT: Under no circumstances shall the -submission of a Exploit into the Program, the awarding of a reward, or anything -in these Rules be construed as an offer or contract of employment with either -Google, or any other Program entities. You acknowledge that you have submitted -your Exploit voluntarily and not in confidence or in trust. You acknowledge that -no confidential, fiduciary, agency or other relationship or implied-in-fact -contract now exists between you and Google or any other Program entities and -that no such relationship is established by your submission of an Exploit under -these Rules. - -19. FORUM AND RECOURSE TO JUDICIAL PROCEDURES: These Rules shall be governed by, -subject to, and construed in accordance with the laws of the State of -California, United States of America, excluding all conflict of law rules. If -any provision(s) of these Rules are held to be invalid or unenforceable, all -remaining provisions hereof will remain in full force and effect. To the extent -permitted by law, the rights to litigate, seek injunctive relief or make any -other recourse to judicial or any other procedure in case of disputes or claims -resulting from or in connection with this Program are hereby excluded, and all -participants expressly waive any and all such rights. - -20. ARBITRATION: By entering the Program, you agree that exclusive jurisdiction -for any dispute, claim, or demand related in any way to the Program will be -decided by binding arbitration. All disputes between you and Google of -whatsoever kind or nature arising out of these Rules, shall be submitted to -Judicial Arbitration and Mediation Services, Inc. (“JAMS”) for binding -arbitration under its rules then in effect in the San Jose, California, USA -area, before one arbitrator to be mutually agreed upon by both parties. The -parties agree to share equally in the arbitration costs incurred. - -20. REWARD RECIPIENT’S LIST: Reward recipients will be posted on the Program -site for six months following the conclusion of the Program.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/quarterly-updates/index.md b/chromium/docs/website/site/Home/chromium-security/quarterly-updates/index.md deleted file mode 100644 index 938e085e048..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/quarterly-updates/index.md +++ /dev/null @@ -1,4092 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: quarterly-updates -title: Quarterly Updates ---- - -We post a newsletter-y update quarterly on -[security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!searchin/security-dev/quarter$20summary%7Csort:date). -It's an open list, so -[subscribe](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev) -if you're interested in updates, discussion, or feisty rants related to Chromium -security. - -## Q4 2021 - -Greetings, - -As we enter the last month of the first quarter of 2022, here's a look back to what Chrome Security was doing in the last quarter of 2021. - -**Chrome is hiring for security positions! See [g.co/chrome/hiring](https://g.co/chrome/hiring)** **for more details.** - -For extension security, we are working on a telemetry framework that monitors suspicious extension activity and transmits associated signals to Safe Browsing, for users opt-ed into sharing these data. The signals are analyzed server-side (both manual and automated analysis) to detect and mitigate extension abuse patterns. - -We proposed a redesigned downloads experience for Chrome on desktop platforms that moves downloads into the toolbar. This would be a better overall user experience and also allow us to build advanced downloads features in the future. We plan to launch the MVP in Q1 2022. - -In preparation for an [HTTPS-first world](https://blog.chromium.org/2021/07/increasing-https-adoption.html), we conducted Stable experiments to determine the impact of changing the lock icon (which has been shown to be misleading to users) to a more security-neutral and obviously-clickable icon, with 1% stable results from Chrome 96. Results from this experiment were positive, indicating that the new icon increased engagement with the Page Info surface without regressing user activity or security metrics. - -We’re running an experiment to expand Certificate Transparency (CT) enforcement to Chrome for Android, improving our ability to detect malicious certificates and unifying certificate validation across platforms. This experiment is rolling out in Chrome 98. - -We launched support for Control Flow Guard on Windows, and continue to make good progress with network process sandboxing on multiple platforms. We’ve also been involved in the “unseasoned PDF” project, which removes NaCl as a dependency from PDFium. - -We’re experimenting with Rust in Chrome, to give easier options to write safe code. These experiments aren’t yet switched on in shipping code, but they help us learn what it would take to do so. For example, we’ve landed a memory-safe JSON parser which can save the overhead of creating a utility process. - -We continued our progress towards increased isolation between websites and networks on the one hand, and cross-site scripting mitigation on the other. For isolation, we've started a [Private Network Access](https://wicg.github.io/private-network-access/) [experiment](https://groups.google.com/a/chromium.org/g/blink-dev/c/72CK2mxD47c/m/Tl59oNfABwAJ) to ensure that preflights aren't going to cause problems for subresource requests, shipped [COEP: credentialless](https://html.spec.whatwg.org/multipage/origin.html#coep-credentialless), and reworked our [document.domain deprecation plans](https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/10vHgsmwAQAJ) based on feedback from the ecosystem. For injection, we've solidified the design and implementation of the [Sanitizer API](https://wicg.github.io/sanitizer-api/) (you can poke at it with this handy [Playground](https://sanitizer-api.dev/)!) in coordination with our friends at Mozilla, whose implementation is also proceeding apace. - -The Security Architecture team was honored to receive an [IEEE Cybersecurity Award for Practice](https://secdev.ieee.org/2021/ieee-award-ceremony/) for [Site Isolation's impact](https://youtu.be/xopIryMS5Fs) on browser security! We continued work on full Site Isolation on some Android devices, extension and [citadel](https://crbug.com/1286501) enforcements, [ORB](https://github.com/annevk/orb), and [SiteInstanceGroups](https://crbug.com/1195535). We also started designing [Site Isolation for the <webview> tags](https://crbug.com/1267977) used in Chrome Apps and WebUI pages. We updated code to support new plans for [turning on Origin-Agent-Cluster by default](https://groups.google.com/a/chromium.org/g/blink-dev/c/_oRc19PjpFo/m/10vHgsmwAQAJ), which could allow isolating origins instead of sites. For memory safety, we updated several unsafe uses of RenderFrameHost pointers and continued local work with Rust and C++ lifetime annotations. - -The Chrome VRP just achieved some new records as we closed out 2021 with close to $3.3 million in total rewards to 115 Chrome VRP researchers for 333 valid unique reports of Chrome browser and Chrome OS security bugs. Of that total, just under just over $3M was rewarded for Chrome browser bugs and $250,500 for Chrome OS bugs, with $45,000 being the highest reward for an individual Chrome OS report and $27,000 for a Chrome browser report. $58,000 was rewarded for security issues discovered by fuzzers contributed by VRP researchers to the [Chrome Fuzzer program](https://bughunters.google.com/about/rules/5745167867576320#fuzzerprogram), the highest reward being $16,000 for [an individual fuzzer-based report](https://crbug.com/1242257). To show our appreciation for helping us keep Chrome safe in 2021, in collaboration with Google VRP, we sent end of year gifts to our Top 20 researchers of 2021 and also [celebrated their achievements publicly on Twitter](https://twitter.com/GoogleVRP/status/1466865149655109641?s=20&t=n_a2eIUW3Y114euQ2PIBUw). - -Cheers, - -Andrew - -## Q3 2021 - -Greetings, - -Here's what the Chrome Security team has been up to in Q3 of this year, - -**Chrome is hiring, including for security positions! See [g.co/chrome/hiring](https://g.co/chrome/hiring)**. In particular we're looking for a **[lead security product manager](https://careers.google.com/jobs/results/118648881425588934-lead-product-manager-chrome-security/)** to work with the teams doing all the great things in this update, and more across the Chrome Trust and Safety organisation. - -Through a series of in-product integrations and promotions on the new tab page on Desktop and Android, we saw a growth of almost 70% in the number of users who chose to opt-in to [Enhanced Safe Browsing](https://security.googleblog.com/2021/06/new-protections-for-enhanced-safe.html) in Chrome. - -We deployed two new machine learning models on Android to detect and block phishing pages: one operates on the contents of the DOM, the other is a TfLite model that operates on the overall appearance of the page. Both models led to a 30+% drop in password reuse on phishing pages and also helped us identify new, previously-unknown phishing pages. Following up from that, in Q4, we’ll try to launch the TfLite model on Desktop platforms also. - -We landed protections that disabled installations of Chrome extensions that had been found to be violating Chrome Web Store policies previously but were still enabled on users’ machines. - -We ran an experiment to understand whether users respond to a cookie-theft specific warning at the time of download any differently than our regular malware warning, and initial results suggest no change in the warning bypass rate. - -To close a loophole currently being abused by a large cookie-theft campaign, we landed changes in [Chrome 96](https://chromiumdash.appspot.com/schedule) to stop circumvention of Chrome’s tracking of referrers. - -This quarter we also launched an [experiment](https://blog.chromium.org/2021/07/increasing-https-adoption.html) to remove the padlock icon, a long-misunderstood component of browser security UI. This change will roll out to a small percentage of users gradually in Chrome 94+. We also launched HTTPS-First Mode, a setting that will cause Chrome to load all pages over HTTPS by default. - -Chrome is now distributing [Certificate Transparency](https://certificate.transparency.dev/) log lists outside the binary update cycle, allowing faster and more reliable updates. This change will allow us to begin exploring Certificate Transparency on Chrome for Android as well as removing the requirement for all certificates to be logged to Google logs. - -Our long-term goal has been to use Chrome’s own certificate verifier and root store on all Chrome platforms. This quarter we began rolling out our certificate verifier and transitional root store on Windows, with a metrics-only trial currently running in Chrome 95. We are also continuing to experiment and investigate compatibility issues on Mac. - -To help people understand the domain names to which they’ve connected, we began experimenting with a new heuristic to identify typosquatting domain names such as “googel[.]com”. We also built a new [workflow](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/lookalikes/lookalike-domains.md#Automated-warning-removal) for developers of co-owned domains to opt out of warnings for lookalike domain names. - -The Platform Security team has started experimenting with Rust in the Chromium tree as part of the memory safety effort. Also in the name of memory safety, we are experimenting with using [WasmBoxC](https://docs.google.com/document/d/1sthYFVXlSQfjLVGNOj0Y1y0H5GedDWS7cPJYodwQd9E/edit?disco=AAAARTZJZlc&usp_dm=true) to create in-process sandboxes. The team is also making progress on sandboxing the network service on Windows, Android, and Linux. And we deprecated and removed an [unsafe IPC pattern](https://bugs.chromium.org/p/chromium/issues/detail?id=1213679). Finally, we are keeping busy by helping review all the new features being launched in Chrome. - -The Security Architecture team was excited to launch Site Isolation for additional sites on Android (including those using OAuth or COOP headers) as well as Strict Extension Isolation on desktop; see the [Google Online Security blog](https://security.googleblog.com/2021/07/protecting-more-with-site-isolation.html) and the [Keyword blog](https://blog.google/products/chrome/privacy-and-performance-working-together-chrome/). We are now experimenting with full Site Isolation on Android devices with sufficient RAM. Our work continues on adding more enforcements for extensions, protecting data with [ORB](https://github.com/annevk/orb), isolating sandboxed iframes, and improving [Origin Agent Cluster](https://web.dev/origin-agent-cluster/). On the [memory safety front](https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html), we have started local experiments with Rust in the tree, while also investigating approaches for improving C++ memory safety. - -To make it easier to deploy [cross-origin isolation](https://web.dev/coop-coep/) deployment easier, we launched [COEP credentialless](https://github.com/WICG/credentiallessness/blob/main/explainer.md) in Chrome 96. We’ve also made good progress on the [COOP same-origin-allow-popups-plus-coep](https://github.com/camillelamy/explainers/blob/main/coi-with-popups.md) spec and started implementation. - -We launched the first part of [Private Network Access](https://wicg.github.io/private-network-access/) checks in Chrome 94, which prevents non-secure websites on the public internet from pivoting through users' privileged network positions to make requests to private network resources. We’re planning to extend these protections in the Chrome 98 timeframe to include [a preflight requirement](https://www.chromestatus.com/feature/5737414355058688) ensuring that the private network resource opts-into communication with the public internet. We'll start with devtools warnings and outreach to give websites time to update their devices to respond to the preflights, and hopefully can roll things out more broadly in 2022. - -Beyond isolation, we're working with our friends at Mozilla to finalize our implementation of a new [Sanitizer API](https://wicg.github.io/sanitizer-api/), that we hope can be an important tool for developers' mitigation of injection attacks. You can play with both Chrome and Firefox's implementations by flipping the relevant flag, and hopping over to the [https://sanitizer-api.dev/](https://sanitizer-api.dev/) playground. - -Cheers, - -Andrew - - -## Q1 and Q2 2021 - -Greetings, - -With apologies to those still waiting patiently for our Q1 update, here instead -is a look back at what the Chrome Security teams have been up to in the first -half of 2021. - -Chrome is hiring, including for security positions! See -[g.co/chrome/hiring](https://g.co/chrome/hiring). In particular we're looking -for a [lead security product -manager](https://careers.google.com/jobs/results/118648881425588934-lead-product-manager-chrome-security/) -to work with the teams doing all the great things in this update, and more -across the Chrome Trust and Safety organisation. - -The first half of 2021 is trending toward record-setting totals for the Chrome -[Vulnerability Reward Program](https://g.co/chrome/vrp) (VRP) with the security -researcher community awarded $1.7M for reporting close to 200 unique, valid -security bugs. Of these reward-eligible reports, 84 were reports for Critical -and High severity issues that impacted stable channel users. The Chrome VRP -continues to be a vital part of our security ecosystem and we greatly appreciate -the efforts of the Chrome VRP researcher community to help keep Chrome users -more secure! - -In a collaborative effort led by the Google VRP, the new [Google BugHunters -site](https://bughunters.google.com/) was launched. Chrome bugs can be reported -via that site, as well as at [crbug.com/new](https://crbug.com/new) using the -Security Bug template as before. - -In collaboration with the other VRP programs across Google, bonuses were paid -out to VRP researchers impacted by recent payment delays. We are additionally -working on ways to proactively decrease future delays, and improve the -efficiency and processes of the program. - -In Q1 the Safe Browsing team grew the [Enhanced Safe -Browsing](https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html) -population by more than 400% through in-product integrations with the security -interstitial pages and Safety Check. We also started using machine learning -models to protect users who have [real-time Safe Browsing -lookups](https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html#:~:text=real-time%20phishing%20protection:%20checking%20with%20safe%20browsing%E2%80%99s%20blocklist%20in%20real%20time.) -against phishing attacks which, along with heuristic-based enforcement, allowed -us to decrease our phishing false negatives by up to 20%. - -We designed improvements to our client-side phishing detection subsystem, which -will allow us to innovate faster in that area in the coming quarters. - -In Q2 we [rolled -out](https://security.googleblog.com/2021/06/new-protections-for-enhanced-safe.html) -a new set of protections for Enhanced Safe Browsing users in Chrome 91: Improved -download protection by offering scanning of suspicious downloads, and better -protection against untrusted extensions. We continued to see a phenomenal growth -in the number of users who opt in to Enhanced Safe Browsing to get Chrome’s -highest level of security. - -We helped land improvements to the client-side phishing detection subsystem in -Chrome 92 which made image-based phishing classification [up to 50 times -faster](https://blog.chromium.org/2021/07/m92-faster-and-more-efficient-phishing-detection.html). -And we landed improvements to the Chrome Cleanup Tool to remove new families of -unwanted software from the users’ machines. - -In Chrome 90, we launched a -[milestone](https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html) -for a secure web: Chrome’s omnibox now defaults to HTTPS when users don’t -specify a scheme. We later -[announced](https://blog.chromium.org/2021/07/increasing-https-adoption.html) a -set of changes to prepare the web for an HTTPS-first future. We’re implementing -HTTPS-First Mode as an option for Chrome 94, a setting that will cause Chrome to -automatically upgrade navigations to HTTPS, and show a full-page warning before -falling back to HTTP. We’ll also be experimenting with a new security indicator -icon for HTTPS pages in Chrome 93, inspired by our research showing that many -users don’t understand the security assurances of the padlock icon. Finally, we -announced a set of guiding principles for protecting and informing users on the -slice of the web that is still HTTP. - -To try out HTTPS-First Mode in Chrome Canary, toggle “Always use secure -connections” in chrome://settings/security. You can also preview our new HTTPS -security indicator by enabling “Omnibox Updated connection security indicators” -in chrome://flags and then re-launching Chrome. - -In June, Chrome passed a huge milestone in the history of [Certificate -Transparency](https://certificate.transparency.dev/). The last certificates -issued before Chrome required CT logging have now expired. That eliminates a -hole where a malicious or compromised CA key could backdate a cert to avoid -logging it. Congratulations to all who've worked on CT over the years, and those -who continue to keep the ecosystem thriving. - -To further strengthen the Certificate Transparency ecosystem, we launched the -[first -phase](https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit#heading=h.7nki9mck5t64) -of SCT auditing, which helps verify that CT logs are behaving honestly, and -[designed](https://docs.google.com/document/d/1YTUzoG6BDF1QIxosaQDp2H5IzYY7_fwH8qNJXSVX8OQ/edit) -and began implementing subsequent phases to improve coverage and reliability. In -Chrome 94 we’ll launch a change to distribute CT log information to clients -faster and more reliably, which will help unblock CT enforcement on Chrome for -Android. - -We’ve made progress on under-the-hood improvements to certificates and TLS. We -[proposed](https://github.com/sleevi/cabforum-docs/tree/profiles) a set of -changes in the [CA/Browser Forum](https://cabforum.org/) to better specify how -website (and other) certificates should be structured, and we -[helped](https://cabforum.org/2021/04/22/ballot-sc42-398-day-re-use-period/) -[make](https://cabforum.org/2021/06/02/ballot-sc46-sunset-the-caa-exception-for-dns-operator/) -[improvements](https://cabforum.org/2021/05/01/ballot-sc44-clarify-acceptable-status-codes/) -such as -[tightening](https://cabforum.org/2021/06/03/ballot-sc45-wildcard-domain-validation/) -validation procedures for wildcard certificates and -[sunsetting](https://cabforum.org/2021/06/30/ballot-sc47v2-sunset-subjectorganizationalunitname/) -an unvalidated certificate field. We distrusted the Camerfirma CA, initially -planned for Chrome 90 but later delayed until Chrome 91 due to the exceptional -circumstances of some Covid-19 related government websites being slow to -migrate. - -On the TLS front, we launched a performance improvement to the latest version of -TLS — [zero round-trip -handshakes](https://www.chromestatus.com/feature/5447945241493504) in TLS 1.3 — -to Canary and Dev. We -[announced](https://groups.google.com/a/chromium.org/g/blink-dev/c/RShdgyaDoX4/m/JikQYHPuBQAJ) -and implemented the removal of the obsolete 3DES cipher. Finally, a new privacy -feature for TLS, [Encrypted Client -Hello](https://www.chromestatus.com/feature/6196703843581952), is now -implemented in our TLS library, with integration into Chrome ongoing. - -The Open Web Platform Security team implemented and specced a first version of -the [Sanitizer API](https://wicg.github.io/sanitizer-api/), that will help -developers avoid pesky XSS bugs. In combination with [Trusted -Types](https://web.dev/trusted-types/#:~:text=Trusted%20Types%20give%20you%20the,is%20available%20for%20other%20browsers.) -that we released last year, it will help websites defend against XSS attacks. - -CORS-RFC1918 got renamed to Private Network Access. We are ready to ship -[restrictions on accessing resources from private networks from public HTTP -pages](https://developer.chrome.com/blog/private-network-access-update/) in -Chrome 94: public HTTP pages will no longer be able to request resources from -private networks. We will have a reverse Origin Trial in place until our -preferred workaround (WebTransport) has shipped. We are also working on the next -stage of Private Network Access restrictions, where we will send a CORS -preflight when a public page tries to access a private resource. - -CrossOriginIsolated is really difficult to adopt for websites. We’re planning to -make a few changes to help with deployment. First, we have a new version of -[COEP](https://html.spec.whatwg.org/multipage/origin.html#coep): -[credentialless](https://developer.chrome.com/blog/coep-credentialless-origin-trial/) -currently undergoing an Origin Trial. It will help developers deploy COEP when -they embed third-party subresources. We’re also working on [anonymous -iframes](https://github.com/camillelamy/explainers/blob/main/anonymous_iframes.md), -to deploy COEP on pages that embed legacy 3rd party iframes. And we want to have -[COOP same-origin-allow-popups + COEP enable -crossOriginIsolated](https://github.com/camillelamy/explainers/blob/main/coi-with-popups.md) -to help with OAuth and payment flows support. - -In Q1, the Security Architecture team continued work on several Site Isolation -efforts: isolating sites that use [COOP](https://crbug.com/1018656) or -[OAuth](https://crbug.com/960888) on Android, metrics for protecting data with -[ORB](https://github.com/annevk/orb), better handling of about:blank origins and -tracking of content scripts, and helping with the communications for the -[Spectre -proof-of-concept](https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html) -and -[recommendations](https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html). -Additionally, [Origin Agent Cluster](https://web.dev/origin-agent-cluster/) -shipped in Chrome 88, offering process isolation at an origin granularity (for -performance reasons rather than security). We explored [new -options](https://chromium-review.googlesource.com/c/chromium/src/+/2782585) for -memory safety and helped with the -[MiraclePtr](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit?usp=sharing) -experiments. Finally, we made several stability improvements, continued -refactoring for [SiteInstanceGroup](https://crbug.com/1195535), and helped -unblock the -[MPArch](https://docs.google.com/document/d/1NginQ8k0w3znuwTiJ5qjYmBKgZDekvEPC22q0I4swxQ/edit) -work. - -Q2 saw work improving Site Isolation protections for Origin headers (via request -initiator enforcements) and extension IPCs. We started several Site Isolation -related beta trials, including isolating [more](https://crbug.com/1018656) -[sites](https://crbug.com/960888) on Android and [isolating -extensions](https://crbug.com/1209417) from each other on desktop. We started an -early prototype of [isolating same-site sandboxed -iframes](https://crbug.com/510122) and analyzed metrics for protecting data with -[ORB](https://github.com/annevk/orb), as well. We also contributed to several -efforts to improve memory safety in Chrome, solved long-standing speculative -RenderFrameHost crashes, and improved support for [Origin Agent -Cluster](https://web.dev/origin-agent-cluster/). - -The Platform Security team had a busy first half of the year. We have now -deployed Hardware-enforced stack protection for Windows (also known as -Control-flow Enforcement Technology, -[CET](https://software.intel.com/content/www/us/en/develop/articles/technical-look-control-flow-enforcement-technology.html)) -to most Chrome processes, on supported hardware. CET protects against control -flow attacks attempting to subvert the return from a function, and we -[blogged](https://security.googleblog.com/2021/05/enabling-hardware-enforced-stack.html) -about this earlier in the year. - -With the returns from functions now protected by CET, we are making good headway -in protecting the function calls themselves — indirect calls, or 'icalls' using -[CFG](https://blog.trailofbits.com/2016/12/27/lets-talk-about-cfi-microsoft-edition/) -(Control Flow Guard). We have full CFG support for all processes behind a -compile time flag 'win_enable_cfg_guards = true', so please try it, but in the -meantime we are working on ironing out performance issues so we can roll it out -to as many processes as possible. - -The stack canary mitigation has been significantly strengthened on Linux and -Chrome OS. These platforms use the zygote for launching new processes, so the -secret stack canary value was the same in each process, which means the -mitigation is useless once an attacker has taken over a single process. The -stack canaries are now re-randomized in each process. - -On macOS, we finished our complete rollout of [our V2 sandbox -architecture](https://chromium.googlesource.com/chromium/src/sandbox/+/HEAD/mac/seatbelt_sandbox_design.md) -with the launch of the new GPU process sandbox. That marks the end of a nearly -four-year project to eliminate the unsandboxed warm-up phase of our processes, -which reduces the amount of attack surface available to a process. In addition, -we [enabled macOS -11’s](https://chromium.googlesource.com/chromium/src/+/46e23c8166086ef63e7d383149d4c91f30b7415e) -new [RIDL](https://mdsattacks.com/) CPU mitigation for processes that handle -untrustworthy arbitrary compute jobs (e.g. renderers). - -GWP-ASAN is being field trialed on Linux, Chrome OS, and Android. GWP-ASAN is a -sampling allocation tool designed to detect heap memory errors occurring in -production with negligible overhead, providing allocation/deallocation/crashing -stack traces for production crashes. It has already been launched on macOS and -Windows but hopefully launching on new platforms should help us find and fix -bugs in platform-specific code. - -XFA (the form-filling part of PDF) is now using Blink's garbage collector -[Oilpan](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md), -protecting against use-after-frees in this code. The PDF code is also being -moved from its own process that uses the legacy Pepper interface (previously -used for Flash) into the same process as web content. - -The work on the network service sandbox continues apace. Previously the sandbox -technology being used on Windows was the same one used for the renderer (the -[restricted -token](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/design/sandbox.md#the-token) -sandbox). However, this tighter sandbox caused issues with parts of the network -stack such as Windows Authentication and -[SSPI](https://docs.microsoft.com/en-us/windows/win32/rpc/security-support-provider-interface-sspi-) -providers, so we are moving to an LPAC (Less Privilege App Container) sandbox -which should play much nicer with enterprises. - -Speaking of enterprises, we landed a new set of policies to control the use of -the JIT (Just-In-Time) compiler in [V8](https://v8.dev/) (our JavaScript -engine). These policies allow enterprises to set a [default -policy](https://chromeenterprise.google/policies/#DefaultJavaScriptJitSetting) -and also to -[enable](https://chromeenterprise.google/policies/#JavaScriptJitAllowedForSites) -or -[disable](https://chromeenterprise.google/policies/#JavaScriptJitBlockedForSites) -JIT for certain sites. The V8 JIT has often been a juicy target for exploit -writers, and by not having any dynamically generated code we can also enable OS -mitigations such as CET (see above) and ACG (Arbitrary Code Guard) in renderer -processes to help prevent bugs from being turned into exploits as easily. -Disabling the JIT does have some drawbacks on web compatibility and performance -— but our friends in Edge subsequently wrote a great -[blog](https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/) -exploring this debate which we encourage you to read before deploying this -policy. - -In Q1 the extended team working on permissions was excited to start rolling out -the fruits of several collaborations from last year, including the MVP of the -Chrome Permission Suggestion Service (CPSS) to suppress -very-unlikely-to-be-granted prompts, the automatic revocation of notification -permission on abusive sites, a complete revamp of chrome://settings/content -pages, and experiments for Permission Chip and one-time permission grants. CPSS -reduces unwanted interruptions (number of explicit decisions which are -dismissed, denied or granted) by 20 to 30%. Additionally, the less disruptive -'chip' permission UI is now live for all users for location permission requests -and we’re migrating other permissions to the new pattern. - -We organized a virtual workshop on next-gen permissions, identifying the core -themes – modes, automation, and awareness – for future explorations, and we -conducted our very first qualitative UXR study to better understand users’ -mental models and expectations with permissions - -We'll be back to our quarterly update cadence with news from Q3 later in the -year. - -Cheers, - -Andrew - -## Q4 2020 - -Greetings, - -Even as 2021 is well underway, here's a look back at what Chrome Security was up to in the last quarter of 2020. - -Interested in helping to protect users of Chrome, Chromium, and the entire web? We're hiring! Take a look at [g.co/chrome/hiring](https://g.co/chrome/hiring), with several of the roles in Washington, DC: [g.co/chrome/securityprivacydc](https://g.co/chrome/securityprivacydc). - -The Usable Security team fully launched a new warning for [lookalike domain names](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/lookalikes/lookalike-domains.md): low-quality or suspicious domains that make it hard for people to understand which website they’re actually visiting. We continued to place some final nails in the coffin of [mixed content](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html) (insecure subresources on secure pages). Secure pages are no longer allowed to initiate any [insecure downloads](https://blog.chromium.org/2020/02/protecting-users-from-insecure.html) as of Chrome 88. We uncovered some issues with our new [warning on mixed form submissions](https://blog.chromium.org/2020/08/protecting-google-chrome-users-from.html) due to redirects, and this warning will be re-launching in Chrome 88 as well. - -With HTTPS adoption continuing to rise, it’s now time to begin treating https:// as the default protocol, so we began implementing a change to the Chrome address bar to default to https:// instead of http:// if the user doesn’t type a scheme. Stay tuned for more information about this change in Q1. - -To improve the security of the Certificate Transparency (CT) ecosystem, we began dogfooding an [opt-in approach](https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit) to audit CT information seen in the wild, and we started [designing](https://docs.google.com/document/d/1YTUzoG6BDF1QIxosaQDp2H5IzYY7_fwH8qNJXSVX8OQ/edit#heading=h.7nki9mck5t64) improvements to make this approach more resilient. - -The Chrome Safe Browsing team helped the Chrome for iOS team roll out real-time Safe Browsing protections in Chrome 86 for iOS. Also, in addition to our existing mechanism to disable malicious Chrome Extensions with a large install base, we rolled out a new mechanism that allows us to also disable malware extensions with a small install base. - -On the memory safety front, we've been getting ready to ship [Oilpanned](https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md) [XFA](https://en.wikipedia.org/wiki/XFA) and continue to engage with the [MiraclePtr and \*Scan](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit#) project. As those initiatives are treating the symptom rather than the cause, we continue to investigate what a safer dialect of C++ would look like, and to improve Rust/C++ interoperability ahead of any possible future rust experiments. Ongoing work on exploit mitigations includes [Control-flow Enforcement Technology](https://newsroom.intel.com/editorials/intel-cet-answers-call-protect-common-malware-threats/), [GWP-ASan](https://chromium.googlesource.com/chromium/src/+/lkgr/docs/gwp_asan.md), and [Control Flow Guard](https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard). - -We’re also working on reducing the privilege of the network service sandbox on Windows. We’re planning to do the same on Android later in the year. - -[FuzzBench](https://github.com/google/fuzzbench) continues to help the research community benchmark and create more efficient fuzzing engines (e.g. [AFL++ 3.0](https://github.com/AFLplusplus/AFLplusplus/releases/tag/3.0c), [SymQEMU](https://twitter.com/mboehme_/status/1351729922364960770), etc). We added support for [bug-based benchmarking](https://github.com/google/fuzzbench/search?p=1&q=%22type%3A+bug%22) ([sample report](https://www.fuzzbench.com/reports/2020-12-19-bug/index.html)), [fuzzer stats api](https://github.com/google/fuzzbench/pull/648), [saturated corpora testing](https://github.com/google/fuzzbench/pull/760). Our [OSS-Fuzz](https://github.com/google/oss-fuzz) platform now has first-class support for [Python fuzzing](https://google.github.io/oss-fuzz/getting-started/new-project-guide/python-lang/), and continues to grow at a brisk pace ([~400](https://github.com/google/oss-fuzz/tree/master/projects) projects, [25K+](https://bugs.chromium.org/p/oss-fuzz/issues/list?q=-status%3AWontFix%2CDuplicate&can=1) bugs). Based on community feedback, we created a lightweight, standalone [ClusterFuzz python package](https://pypi.org/project/clusterfuzz/) (alpha) for common fuzzing use cases, e.g. stacktrace parsing. We have refactored [AFL fuzzing integration](https://github.com/google/clusterfuzz/pull/2147) to use the [engine interface](https://github.com/google/clusterfuzz/blob/master/src/python/lib/clusterfuzz/fuzz/engine.py). We have been working on a solution to better track vulnerabilities in third-party dependencies. We have also bootstrapped several open source security efforts under the [OpenSSF](https://openssf.org/) foundation, e.g. [security scorecards](https://opensource.googleblog.com/2020/11/security-scorecards-for-open-source.html), [finding critical projects](https://opensource.googleblog.com/2020/12/finding-critical-open-source-projects.html), etc. - -We implemented blocking of requests from insecure contexts to private networks (first part of [CORS-RFC1918](https://web.dev/cors-rfc1918-feedback/)), and are analyzing metrics to chart a path to launch. - -We introduced the [PolicyContainer](https://github.com/antosart/policy-container-explained) to squash bugs around inheritance of security policies to about:blank, srdoc or javascript documents. - -We also implemented a first version of a [Sanitizer API](https://github.com/WICG/sanitizer-api) and started the specification process. - -With [CrossOriginOpenerPolicy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) and [CrossOriginEmbedderPolicy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy) (COEP) launched, we were able to [re-enable SharedArrayBuffers on Android](https://docs.google.com/document/d/1tXfF0sdMQJPtwc2qEGF_V_z5xiCkP3ayS5ByRz6Rc-A/edit?ts=5f236efa) gated behind crossOriginIsolated (a.k.a COOP+COEP), which Firefox has also done. We have a plan to [deprecate all SAB usage without crossOriginIsolated](https://groups.google.com/a/chromium.org/g/blink-dev/c/1NKvbIj3dq4/m/cdfo-JazBQAJ) in Chrome 91 (with reverse Origin Trial until Chrome 93). - -This will require users of SharedArrayBuffers to adopt COOP and COEP. Adopting COEP has proved difficult. We have heard that the deployment of COEP was difficult for a certain number of websites that embed third-party content. We are considering a new form of COEP that might alleviate those issues: [credentialless](https://github.com/mikewest/credentiallessness). To help drive adoption of COOP we moved the [COOP reporting API](https://web.dev/coop-coep/) out of Origin Trial to on by default in Chrome 89. - -We have started to collect [metrics](https://deprecate.it/) on dangerous web behaviors, with the hope of driving them down. The first one we’ll likely be looking at is [document.domain](https://github.com/mikewest/deprecating-document-domain). - -The Security Architecture team completed the [CORS for content scripts migration](/Home/chromium-security/extension-content-script-fetches) in Chrome 87, removing the allowlist for older extensions and strengthening Site Isolation for all desktop users! Opt-in origin isolation was renamed to [Origin-Keyed Agent Clusters](https://www.chromestatus.com/feature/5683766104162304) and is on track to launch in Chrome 88. We are making progress towards additional Android Site Isolation for OAuth and COOP sites, and we helped secure SkBitmap IPCs against memory bugs. Finally, we have been investing in architecture changes, including [SiteInfo](https://source.chromium.org/chromium/chromium/src/+/HEAD:content/browser/site_instance_impl.h;drc=62f7e7ad10582e60fb724e65dd2b088d4837fe4e;l=28) to better track principals and SiteInstanceGroup to simplify the process model, along with significant reviews for [Multiple Page Architecture](https://docs.google.com/document/d/1NginQ8k0w3znuwTiJ5qjYmBKgZDekvEPC22q0I4swxQ/edit?usp=sharing) and [Multiple Blink Isolates](https://docs.google.com/document/d/1qgDcgQWIXbsJrJUPuqnXv7sy8zf9xrf1ol90D0g7H5o/edit?usp=sharing). - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q3 2020 - -Greetings, - -Here's an update on what the teams in Chrome Security have been up to in the -third quarter of 2020. - -The Chrome Safe Browsing team continued the [roll-out of Enhanced Safe -Browsing](https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html) -by launching it on Android in Chrome 86, and [releasing a -video](https://www.youtube.com/watch?v=w8uNzQqsTrU) with background on the -feature. We also launched [deep scanning of suspicious -downloads](https://security.googleblog.com/2020/09/improved-malware-protection-for-users.html), -initially for users of Google’s Advanced Protection program, which received -[positive -coverage](https://www.theverge.com/2020/9/16/21439599/google-chrome-scan-malicious-files-safe-browsing-advanced-protection). - -This quarter the Usable Security team vanquished a longtime foe: http:// -subresources on https:// pages. [Mixed -content](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html) -is either upgraded to https:// or blocked. We also built new warnings for [mixed -forms](https://blog.chromium.org/2020/08/protecting-google-chrome-users-from.html) -and continued rolling out [mixed download -blocking](https://blog.chromium.org/2020/02/protecting-users-from-insecure.html). -These launches protect users’ privacy and security by decreasing plaintext -content that attackers can spy on or manipulate. - -In Chrome 86, we are beginning a gradual rollout of a new low-confidence warning -for lookalike domains. We also expanded our existing [lookalike -interstitial](https://blog.chromium.org/2019/06/new-chrome-protections-from-deception.html). - -Finally, we rolled out a 1% Chrome 86 -[experiment](https://blog.chromium.org/2020/08/helping-people-spot-spoofs-url.html) -to explore how simplifying the URL in the address bar can improve security -outcomes. - -The Platform Security team continued to move forward on memory safety: With Rust -currently not approved for use in Chromium, we must try to improve C++. Toward -that end, the [PDFium -Oilpan](https://docs.google.com/document/d/1WiZCu0D2RvdpBkYuUdL571oFlj0kSaXU1HhdoL7438Y/edit#heading=h.v9as6odlrky3) -and -[MiraclePtr/\*Scan](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit) -projects are moving forward quickly and ready to try in Q4 and Q1 2021. - -In Sandboxing news, we made changes to Linux and our calling code to handle -coming glibc changes, servicifying the Certificate Verifier (unblocking work to -isolate the network service), and getting a better grip on Mojo. - -Bugs-- has started encouraging Chrome developers to submit vulnerability -analysis after the bug is fixed -([example](https://bugs.chromium.org/p/chromium/issues/detail?id=1126424#c41)). -This guides our future work on eliminating common bug patterns. We -cross-collaborated with fuzzing teams across Google to host 50 summer interns, -with strong impact across Chrome and other critical open source software (see -[blog -post](https://opensource.googleblog.com/2020/10/fuzzing-internships-for-open-source.html)). -We have added automated regression testing of past fixed crashes for -engine-based fuzzers (e.g. libFuzzer, AFL). We have made several changes to our -underlying fuzzing and build infrastructures - UI improvements, Syzkaller -support, OSS-Fuzz builder rewrite, etc. Lastly, we continue to push fuzzing -research across the industry using our FuzzBench benchmarking platform and have -led to improvements in -[AFL++](https://github.com/google/fuzzbench/commits?author=vanhauser-thc), -[libFuzzer](https://github.com/google/fuzzbench/commits?author=dokyungs) and -[Honggfuzz](https://github.com/google/fuzzbench/commits?author=robertswiecki) -fuzzing engines. - -The Open Web Platform security team continues to focus on two problems: -injection attacks, and isolation primitives. - -Regarding injection, we're polishing our [Trusted -Types](https://web.dev/trusted-types/) implementation, supporting Google's -security team with bug fixes as they continue to roll it out across Google -properties. We're following that up with experimental work on a [Sanitizer -API](https://github.com/WICG/sanitizer-api) that's making good progress, and -some hardening work around policy inheritance to fix a class of bugs that have -cropped up recently. - -For isolation, we're continuing to focus on -[COOP](https://web.dev/why-coop-coep/#coop) deployment. We shipped COOP's -report-only mode as an origin trial, and we're aiming to re-enable -SharedArrayBuffers behind COOP+COEP in Chrome 88 after shipping some changes to -the process model in Chrome 87 to enable \`crossOriginIsolated\`. - -In Q3, Chrome's Security Architecture team has enabled CORS for extension -content scripts in Chrome 85, moving to a more secure model against compromised -renderers. We made further progress on opt-in origin isolation, and we took the -first steps towards several improved process model abstractions for Chrome. -MiraclePtr work is progressing towards experiments, and we wrapped up the test -infrastructure improvements from last quarter. - -The CA/Browser Forum guidelines got big updates, with ballots to overhaul the -guidelines to [better match browser -requirements](https://github.com/cabforum/documents/pull/195), including -certificate lifetimes, and long overdue [cleanups and -clarifications](https://github.com/cabforum/documents/pull/208). One good revamp -deserves another, and the [Chrome Root Certificate -Policy](https://g.co/chrome/root-policy) got a big facelift, as part of -transitioning to a Chrome Root Store. - -CT Days 2020 [was held in -September](https://docs.google.com/document/d/18hRJQW5Qzgcb87P-YIkWIuna9_pRUNGsZPC4V0fiq5w/preview), -including the big announcement that Chrome was working to remove the One Google -Log requirement by implementing [SCT -auditing](https://docs.google.com/document/d/1G1Jy8LJgSqJ-B673GnTYIG4b7XRw2ZLtvvSlrqFcl4A/edit). - -[This -summer](https://security.googleblog.com/2020/10/fuzzing-internships-for-open-source.html), -we also hosted an intern who worked on [structure-aware ASN.1 -fuzzing](https://github.com/google/libprotobuf-mutator-asn1), and began -integration with BoringSSL. - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q2 2020 - -Greetings, - -The 2nd quarter of 2020 saw Chrome Security make good progress on multiple -fronts, all helping to keep our users, and the web safe. - -The Chrome Safe Browsing team launched real-time phishing protection for all -Android devices, and observed a 164% increase in phishing warnings for -main-frame URLs. We also completed the rollout of [Enhanced Safe -Browsing](https://security.googleblog.com/2020/05/enhanced-safe-browsing-protection-now.html) -to all users of Chrome on desktop platforms. - -We helped the Chrome for iOS team implement hash-based Safe Browsing protection -in Chrome 84 for iOS for the first time ever. Also working with various teams, -most notably the Mobile UX, we made significant progress in shipping Enhanced -Safe Browsing in Chrome 86 for Android. - -For desktop platforms, we landed changes to the in-browser phishing detection -mechanism to help reduce phishing false negatives using new machine learning -models for Chrome 84 and beyond. We also finalized the plan to disable more -malicious Chrome Extensions, starting with Chrome 85. - -The Enamel team put the finishing touches on our work to prevent https:// pages -from loading insecure content. We built a new warning for https:// pages with -forms targeting insecure endpoints, and prepared to start rolling out [mixed -download -warnings](https://blog.chromium.org/2020/02/protecting-users-from-insecure.html) -in Chrome 84. This release will also include [mixed image -autoupgrading](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html) -and the second phase of [TLS 1.0/1.1 -deprecation](https://security.googleblog.com/2019/10/chrome-ui-for-deprecating-legacy-tls.html). - -Even on an https:// website, users need to accurately understand which website -they’re visiting. We expanded our [lookalike domain -warning](https://blog.chromium.org/2019/06/new-chrome-protections-from-deception.html) -with new triggering heuristics, and prepared to launch an additional warning -(pictured) for lower-precision heuristics in M86. - -The Platform Security team continued to make good progress on many of our longer -term projects, including sandboxing the network service (and associated -certificate verification servicification), -[adopting](https://docs.google.com/document/d/1WiZCu0D2RvdpBkYuUdL571oFlj0kSaXU1HhdoL7438Y/) -Oilpan garbage collection in PDFium's XFA implementation, and investigating -memory safety techniques, and exploitation mitigation technologies. - -Along with our colleagues in Chrome Security Architecture, we've sharpened the -security focus on -[Mojo](https://chromium.googlesource.com/chromium/src/+/HEAD/mojo/README.md), -Chrome's IPC system, and started looking at what's needed to improve developer -ergonomics and make it easier to reason about communicating over security -boundaries. Also with CSA, we've worked on how -[MiraclePtr](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit?usp=sharing) -could help prevent use after free bugs in C++ code. - -Bugs-- continued to develop and improve the FuzzBench platform which has helped -the security research community develop more efficient fuzzing engines -(HonggFuzz, AFL++ got several improvements and leads the [benchmarking -results](https://www.fuzzbench.com/reports/2020-07-13/index.html)). Based on -FuzzBench results, we have successfully integrated -[Entropic](https://mboehme.github.io/paper/FSE20.Entropy.pdf) as a fuzzing -strategy in ClusterFuzz. We have started rewriting/improving several Chrome -blackbox fuzzers (e.g. dom, webbot, media, ipc), and also deprecated ~50 -duplicate/unneeded fuzzers. In OSS-Fuzz service, we added first-class fuzzing -support for -[Golang](https://google.github.io/oss-fuzz/getting-started/new-project-guide/go-lang/) -and -[Rust](https://google.github.io/oss-fuzz/getting-started/new-project-guide/rust-lang/) -languages (better compiler instrumentation, crash parsing, and easier project -integration) and improved CI (e.g. Honggfuzz checks). Lastly, we worked closely -with Android Security and improved ClusterFuzz for on-device and host fuzzing -use cases (e.g. syzkaller support, pixel hardware fuzzing). - -The Open Web Platform Security team remained focused on mitigating injection -attacks on the one hand, and improving isolation of sensitive content on the -other. Q2 was exciting on both fronts! - -We shipped an initial implementation of [Trusted -Types](https://web.dev/trusted-types/), which gives developers the ability to -meaningfully combat DOM XSS, and nicely compliments CSP's existing mitigations -against other forms of injection. Google has deployed Trusted Types in -high-value applications like [My Google -Activity](https://myactivity.google.com/), and we're excited about further -rollouts. -We also rolled out our first pass at [two new isolation -primitives](https://web.dev/coop-coep): Cross-Origin Opener Policy and -Cross-Origin Embedder Policy. Opting-into these mechanisms improves our ability -to process-isolate your pages, mitigating some impacts of Spectre and XSLeaks, -which makes it possible to safely expose powerful APIs like SharedArrayBuffers. - -The Chrome Security Architecture team has started Origin Trials for [opt-in -origin isolation](https://www.chromestatus.com/feature/5683766104162304), -allowing origins to use separate processes from the rest of their site. We have -also made progress on [securing extension content script -requests](/Home/chromium-security/extension-content-script-fetches) and -enforcements for request initiators, and we improved the update mechanism for -Android Site Isolation's list of isolated sites. Much of Q2 was spent on cleanup -and documentation, though, particularly test infrastructure and flaky test -improvements. Finally, we also contributed to -[MiraclePtr](https://docs.google.com/document/d/1pnnOAIz_DMWDI4oIOFoMAqLnf_MZ2GsrJNb_dbQ3ZBg/edit?usp=sharing) -efforts to reduce memory bugs, and we helped more teams use WebUI by adding -support for web iframes. - -In the world of the Web PKI, TLS certificates issued from default-trusted CAs -after 2020-09-01 will be rejected if their lifetime is greater than 398 days, -beginning with Chrome 85. See the [documentation and -FAQ](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/certificate_lifetimes.md). -This is part of a number of changes [adopted -by](https://cabforum.org/2020/07/16/ballot-sc31-browser-alignment/) CA/Browser -Forum with unanimous support from major Browsers, which aligns the Baseline -Requirements with many existing Browser root program requirements. - -We continued informal cross-browser collaboration and met with the European -Union on their eIDAS Regulation, exploring how certificates can be used to -provide identity information for domains in a manner consistent with the Web -Platform. - -Until next time, on behalf of Chrome Security, I wish you all the very best. - -Andrew - -## Q1 2020 - -Greetings, - -Amongst everything the first quarter of 2020 has thrown at the world, it has -underlined the crucial role the web plays in our lives. As always, the Chrome -Security teams have been focusing on the safety of our users, and on keeping -Chrome secure and stable for all those who depend on it. - -The Chrome Safe Browsing team, with the support of many teams, introduced a new -Safe Browsing mode that users can opt-in to get “faster, proactive protection -against dangerous websites, downloads, and extensions.” - -We launched [previously -announced](https://www.blog.google/products/chrome/better-password-protections/) -faster phishing protection to Chrome users on high-memory Android devices. This -led to a 116% increase in the number of phishing warnings shown to users for -main frame URLs. - -We also launched predictive phishing protections to all users of Chrome Password -Manager on Android, which warns users when they type their saved password on an -unsafe website. The initial estimate from the launch on Beta population suggests -an 11% increase in the number of warnings shown compared to that on Windows. - -Chrome's Enamel team finalized plans to bring users a more secure HTTPS -ecosystem by blocking [mixed -content](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html), -[mixed -downloads](https://blog.chromium.org/2020/02/protecting-users-from-insecure.html), -and [legacy TLS -versions](https://security.googleblog.com/2019/10/chrome-ui-for-deprecating-legacy-tls.html). -These changes have now been delayed due to changing global circumstances, but -are still planned for release at the appropriate time. - -To improve how users understand website identity, we experimented with a [new -security indicator -icon](https://bugs.chromium.org/p/chromium/issues/detail?id=1008219) for -insecure pages. We also experimentally launched a [new -warning](https://bugs.chromium.org/p/chromium/issues/detail?id=982930) for sites -with spoofy-looking domain names. We’re now analyzing experiment results and -planning next steps for these changes. - -The Platform Security team made significant forward progress on enabling the -network service to be sandboxed on all platforms (it already is on macOS). This -required getting significant changes into Android R, migrating to a new way of -using the Data Protection API on Windows (which had the side-effect of [breaking -some crime rings’ -operations](https://www.zdnet.com/article/chrome-80-update-cripples-top-cybercrime-marketplace/), -albeit -[temporarily](https://www.bleepingcomputer.com/news/security/malware-unfazed-by-google-chromes-new-password-cookie-encryption/)), -and more. When complete, this will reduce the severity of bugs in that service -from Critical to High. - -We also made progress on Windows sandboxing, working towards adopting -AppContainer, and are refactoring our Linux/Chrome OS sandbox to handle -disruptive upstream changes in glibc and the kernel. - -Discussions about the various ways we can improve memory safety continue, and we -laid plans to migrate PDFium’s XFA support to -[Oilpan](https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md) -garbage collection, with the help of Oilpan and V8 teams. This will enable us to -safely ship XFA in production, hopefully in 2020. - -The bugs-- team launched [FuzzBench](https://github.com/google/fuzzbench), a -fuzzer benchmarking platform to bridge the gap between academic fuzzing research -and industry fuzzing engines (e.g libFuzzer, AFL, Honggfuzz). We have integrated -new techniques in ClusterFuzz to improve fuzzing efficiency and break coverage -walls - dataflow trace based fuzzing, in-process grammar mutators (radamsa, -peach). Also, launched -[CIFuzz](https://google.github.io/oss-fuzz/getting-started/continuous-integration/) -for OSS-Fuzz projects to catch obvious security regressions in a project’s -continuous integration before they are checked in. - -The Chrome Security Architecture (née Site Isolation) team has been -strengthening Site Isolation this quarter. We're [securing extension content -script requests](/Home/chromium-security/extension-content-script-fetches) to -unify CORS and CORB behavior, and we're progressing with a -[prototype](https://crbug.com/1042415) to let websites opt in to [origin-level -isolation](https://github.com/WICG/origin-isolation). To improve Chrome's -security architecture, the team is working on a proposal for a new -SecurityPrincipal abstraction. We have also cleaned up RenderWidget/RenderView -lifetimes. Finally, we are starting to formalize our thinking about privilege -levels and their interactions in Chrome. We are enumerating problem spots in IPC -and other areas as we plan the next large projects for the team. - -For the past five years, Chrome, along with counterparts at browser vendors such -as Mozilla, Microsoft, Apple, Opera, and Vivaldi, have been discussing technical -challenges involved in [the eIDAS -Regulation](https://ec.europa.eu/futurium/en/content/eidas-regulation-regulation-eu-ndeg9102014) -with members of the European Commission, [ETSI](https://www.etsi.org/), and -[European Union Agency for Cybersecurity (ENISA)](https://www.enisa.europa.eu/). -These discussions saw more activity this past quarter, with browsers [publicly -sharing](https://cabforum.org/pipermail/servercert-wg/2020-January/001555.html) -an [alternative technical -proposal](https://cabforum.org/pipermail/servercert-wg/attachments/20200114/3a5fa74c/attachment-0001.pdf) -to the current ETSI-defined approach, in order to help the Commission make the -technology easier to use and interoperate with the web and browsers. - -We announced [Chrome’s 2020 Certificate Transparency -plans](https://groups.google.com/a/chromium.org/d/msg/ct-policy/dqFtoFBy8YU/Xa67FWVCEgAJ) -with a focus on removing “One Google Log” policy dependency. Pending updates to -travel policy, we have tentatively planned CT Days 2020 and sent out an -[interest -survey](https://docs.google.com/forms/d/1NzHadfwhqUPEXqcHHtZTwfVDS1yj9vGvhP0y1qluYEU/edit) -for participants. - -Until next time, on behalf of Chrome Security I wish you all the very best. - -Andrew - -## Q4 2019 - -As we start 2020 and look forward to a new year and a [new -decade](https://xkcd.com/2249/), the Chrome Security Team took a moment to look -back at the final quarter of 2019. - -The Safe Browsing team launched two features that significantly improve phishing -protections available to Chrome users: - -We reduced the false negative rate for Safe Browsing lookups in Chrome by -launching [real-time Safe Browsing -lookups](https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html) -for users who have opted in to “Make Searches and Browsing better.” Early -results are promising, with up to [55% more warnings -shown](https://screenshot.googleplex.com/EADPM3soc10) to users who had this -protection turned on, compared to those who did not. - -A while ago we launched predictive phishing protections to warn users who are -syncing history in Chrome when they enter their Google Account password into -suspected phishing sites that try to steal their credentials. [With the Chrome -79](https://security.googleblog.com/2019/12/better-password-protections-in-chrome.html), -we expanded this protection to everyone signed in to Chrome, even if you have -not enabled Sync. In addition, this feature will now work for all the passwords -that the user has stored in Chrome’s password manager; this will show an -estimated 10 times more warnings daily. - -We also had two telemetry based launches for sending pings to Safe Browsing when -users who have opted into Safe Browsing Extended Reporting focus on password -fields and reuse their passwords on Android. - -[HTTPS adoption](https://transparencyreport.google.com/https/overview?hl=en) has -risen dramatically, but -[many](https://chromestatus.com/metrics/feature/timeline/popularity/609) -https:// pages still include http:// subresources — known as mixed content. In -October, the Usable Security team published a -[plan](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html) -to eradicate mixed content from the web. The first phases of this plan started -shipping in Chrome 79. In Chrome 79, we relocated the setting that allows users -to load mixed content when it’s blocked by default. This setting used to be a -shield icon in the Omnibox, and is now available in Site Settings instead. In -Chrome 80, mixed audio and video will be automatically upgraded to https://, and -they will be blocked if they fail to load. We started work on a [web -standard](https://w3c.github.io/webappsec-mixed-content/level2.html) to codify -these changes. See [this -article](https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content) -for how to fix mixed content if you run an affected website. - -Website owners should keep their HTTPS configurations up-to-date with the latest -security settings. Back in 2018, we (alongside other browsers) announced -[plans](https://security.googleblog.com/2018/10/modernizing-transport-security.html) -to remove support for legacy TLS versions 1.0 and 1.1. In October, we updated -these plans to -[announce](https://security.googleblog.com/2019/10/chrome-ui-for-deprecating-legacy-tls.html) -the specific UI treatments that we’ll use for this deprecation. Starting in -January 2020, Chrome 79 will label affected websites with a “Not Secure” chip in -the omnibox. Chrome 81 will show a full-page error. Make sure your server -supports TLS >=1.2 to avoid this warning treatment. - -To continue to polish our security UI, we iterated on our -[warning](https://blog.chromium.org/2019/06/new-chrome-protections-from-deception.html) -for lookalike domains to make the warning more understandable. We introduced a -new gray triangle icon for http:// sites to make a clearer distinction between -http:// and https://. This icon will appear for some users as part of a -small-scale experiment in Chrome 80. Finally, we cleaned up a large backlog of -low severity security UI vulnerabilities. We fixed, closed, or removed -visibility restrictions on 33 out of 42 bugs. - -The Platform Security Team sandboxed the network service on macOS in Chrome 79, -and continued the work on sandboxing it on other Desktop platforms. There is -also some forward momentum for reducing its privilege in version R of Android. - -You can now check the sandboxing state of processes on Windows by navigating to -chrome://sandbox. Also on Windows, we experimented with enabling the renderer -App Container but ran into crashes likely related to third party software, and -are now working to improve error reporting to support future experimentation. -Chrome 79 also saw Code Integrity Guard enabled on supported Windows versions, -blocking unsigned code injection into the renderer process. - -We have also begun investigating new systemic approaches to memory unsafety. -Look for news in 2020, as well as continual improvements to the core libraries -in Chromium and PDFium. - -In Q4, the Bugs-- team moved closer to our goal of achieving 50% fuzzing -coverage in Chrome (it's currently at 48%). We added new features to our -ClusterFuzz platform, such as [Honggfuzz](https://github.com/google/honggfuzz) -support, libFuzzer support for Android, improved fuzzer weights and more -accurate statistics gathering pipeline. We also enabled several new UBSan -features across both Chrome and OSS-Fuzz. As part of OSS-Fuzz, we added Go -language support and on-boarded several new Go projects. We also gave a talk -about ClusterFuzz platform at [Black Hat -Europe](https://www.blackhat.com/eu-19/briefings/schedule/#clusterfuzz-fuzzing-at-google-scale-17505). - -In conversation with our friends and colleagues at Mozilla over the course of -Q4, the Open Web Platform Security team made substantial progress on -[Cross-Origin-Opener-Policy](https://github.com/whatwg/html/issues/3740) and -[Cross-Origin-Embedder-Policy](https://mikewest.github.io/corpp/). These -isolation primitives will make it possible for us to ensure that process -isolation is robust, even as we ship new and exciting APIs that give developers -more capability. Implementations of both are mostly complete behind a flag, and -we're looking forward to getting them out the door, and beginning the process of -relying upon them to [when deciding whether to allow cross-thread access to -shared -memory](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes). - -Similarly, we're polishing our implementation of [Trusted -Types](https://w3c.github.io/webappsec-trusted-types/dist/spec/) based on -feedback from origin trials and other vendors' review of the spec. We're still -excited about its potential for injection mitigation, and we're looking forward -to closing out the last few issues we know about in our implementation. - -The Site Isolation team posted to the [Google Security -Blog](https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.html) -and the [Chromium -Blog](https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html) -about our recent milestones for Site Isolation on Android and defending against -compromised renderer processes. We also gave a talk at [Black Hat -Europe](https://www.blackhat.com/eu-19/briefings/schedule/#site-isolation-confining-untrustworthy-code-in-the-web-browser-17974) -about Site Isolation and how to look for new bypasses for the -[VRP](https://www.google.com/about/appsecurity/chrome-rewards/index.html). At -the same time, we made progress on additional enforcement, and we ran -experiments to expand Android coverage to more devices. Finally, we also used Q4 -to clean up a lot of core Site Isolation code, and we started updating Chrome's -WebUI framework to better support new types of Chrome features without large -risks of privilege escalation. - -In the world of Web PKI Security, as part of our ongoing collaboration with -Microsoft and Mozilla on the [Common CA Database](https://www.ccadb.org/), -"Audit Letter Validation" is now enabled for the full set of publicly trusted -Certificate Authorities. This tool, developed by Microsoft and Mozilla, -automatically validates the contents of audit letters to ensure they include the -information required of a publicly trusted CA. Audit letter validation was -previously done by hand, which was not scalable to CA's 2,500+ intermediate -certificates. - -Audit Letter Validation enabled us and other root stores to detect a wide -variety of issues in the Web PKI that had previously gone unnoticed. We’ve spent -the past quarter leading the incident response effort, working with -non-compliant CAs to remediate issues and mitigate future risk. This helps not -only Chrome users, but all users who trust these CAs. We can now automatically -detect issues as they happen, ensuring prompt remediation. - -We also collaborate with Mozilla to provide [detailed -reviews](https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review) of -organizations applying to be CAs, completing several in Q4. These public reviews -take an extremely detailed look at how the CA is operated, looking at both -compliance and for risky behaviour not explicitly forbidden, as well as -opportunities for improvement based on emerging good practices. - -[Certificate Transparency](https://www.certificate-transparency.org/) (CT) -continues to be an integral part of our work. Beyond helping protect users by -allowing quick detection of potentially malicious certificates, the large-scale -analysis that CT enables has been essential in helping improve the Web PKI. -Analysis of CT logs this quarter revealed a number of systemic flaws in how -Extended Validation certificates are validated, which has spurred industry-wide -effort to address these issues. - -We took steps to protect users from trusting harmful certificates that might be -installed by software or which they might be directed to install. Working with -the Enamel team, we built on steps we’d [previously taken to protect -users](https://security.googleblog.com/2019/08/protecting-chrome-users-in-kazakhstan.html) -from certificates used to intercept their communications by adding the ability -to rapidly deploy targeted protections via our -[CRLSet](/Home/chromium-security/crlsets) mechanism. CRLSets allow us to quickly -respond, using the [Component -Updater](https://chromium.googlesource.com/chromium/src/+/HEAD/components/component_updater/README.md), -without requiring a full Chrome release or respin. - -More generally, we continue to work on the “patch gap”, where security bug fixes -are posted in our open-source code repository but then take some time before -they are released as a Chrome stable update. We now make regular refresh -releases every two weeks, containing the latest severe security fixes. This has -brought down the median “patch gap” from 33 days in Chrome 76 to 15 days in -Chrome 78, and we continue to work on improving it. - -Finally, you can read what the Chrome (and other Google) Vulnerability Rewards -Programs have been up to in 2019 in our [recent blog -post](https://security.googleblog.com/2020/01/vulnerability-reward-program-2019-year.html). - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q3 2019 - -Greetings! - -With the equinox behind us, it's time for an update on what the Chrome security -team has been up to in the third quarter of 2019. - -The Chrome Safe Browsing team -[launched](https://www.blog.google/technology/safety-security/advanced-protection-program-expands-chrome/) -Stricter Download Protections for [Advanced -Protection](https://landing.google.com/advancedprotection/) users in Chrome and -significantly reduce users’ exposure to potentially risky downloads. - -In Q3, Safe Browsing also brought Google password protection to signed in, -non-sync users. This project is code complete, and the team plans to roll it out -in Chrome 79. - -Enamel, the Security UX team, have been looking at mixed content: http:// -subresources on https:// pages. Mixed content presents a confusing UX and a risk -to user security and privacy. After a long-running data-gathering -[experiment](https://groups.google.com/a/chromium.org/d/msg/blink-dev/ZJxkCJq5zo4/4sSMVZzBAwAJ) -on pre-stable channels, the Enamel team -[publicized](https://security.googleblog.com/2019/10/no-more-mixed-messages-about-https_3.html) -plans to start gradually blocking mixed content. In Chrome 79, the team plans to -relocate the setting to bypass mixed content blocking from a shield icon in the -omnibox to Site Settings. In Chrome 80, we will start auto-upgrading mixed audio -and video to https://, blocking resources if they fail to auto-upgrade. Chrome -80 will also introduce a “Not Secure” omnibox chip for mixed images, which we -plan to start auto-upgrading in a future version of Chrome. - -Furthering our quest to improve the quality of HTTPS deployments, we -[announced](https://security.googleblog.com/2019/10/chrome-ui-for-deprecating-legacy-tls.html) -a new UI plan for the upcoming [legacy TLS -deprecation](https://security.googleblog.com/2018/10/modernizing-transport-security.html) -in early 2020. - -In Q3, Enamel also made improvements to our lookalike domain warning, with -clearer strings and new heuristics for detecting spoofing attacks. We also added -additional signals in our [Suspicious Site Reporter -extension](https://chrome.google.com/webstore/detail/suspicious-site-reporter/jknemblkbdhdcpllfgbfekkdciegfboi?hl=en-US) -for power users to identify suspicious sites that they can report to Safe -Browsing for scanning. In Chrome 77, we -[relocated](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/ev-to-page-info.md) -the Extended Validation certificate UI to Page Info; we presented the user -research that inspired this change at [USENIX Security -2019](https://www.usenix.org/conference/usenixsecurity19/presentation/thompson). - -The Platform Security team continues to help improve the memory safety of the -PDFium code base, and have finished removing all bare new/delete pairs, and -ad-hoc refcounting. We continued to push for greater [memory -safety](https://twitter.com/arw/status/1159631867835895808) on a number of -fronts, and are busy working on plans for the rest of the year and 2020. Q3 saw -a number of projects enter trials on Beta and Stable, including the V2 sandbox -for GPU process and network service sandbox on macOS, and Code Integrity Guard -on Windows. Look out for news of their launch in next quarter's update! - -The [XSS Auditor](/developers/design-documents/xss-auditor), which attempted to -detect and prevent reflected XSS attacks, was [removed in Chrome -78](https://www.zdnet.com/article/google-to-remove-chromes-built-in-xss-protection-xss-auditor/). -It had [a number of -issues](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ), -and in the end the cons outweighed the pros. - -The Bugs-- team added -[FuzzedDataProvider](https://github.com/google/fuzzing/blob/master/docs/split-inputs.md#fuzzed-data-provider) -(FDP) as part of Clang, making it simple to write fuzz targets that require -multiple inputs with just a single header file include. We refactored -ClusterFuzz code to make it easier to add new fuzzing engines and migrated -libFuzzer to use this new -[interface](https://github.com/google/clusterfuzz/blob/master/src/python/bot/fuzzers/engine.py). -We rewrote the ClusterFuzz reproduce tool, which is now part of main ClusterFuzz -GitHub repo. On the OSS front, we launched new features in OSS-Fuzz - Golang -support, X86 config support, FDP support, and OSS-Fuzz Badges. We also did -fuzzer strategy weight adjustments based on multi-armed bandit experiments. -Jonathan Metzman -[presented](https://www.blackhat.com/us-19/briefings/schedule/index.html#going-beyond-coverage-guided-fuzzing-with-structured-fuzzing-16110) -at Black Hat (USA) on structure aware fuzzing. - -The Open Web Platform Security team have been working on [Trusted -Types](https://github.com/w3c/webappsec-trusted-types), the Origin Trial for -which is about to finish. We are making a number of changes to the feature, -mainly to aid deployment and debugging of TT deployments, as well as some -overall simplifications. We expect this work to finish in early Q4, and to -launch in the same quarter. - -The [Site Isolation](/Home/chromium-security/site-isolation) team reached two -more important milestones in Q3. First, we enabled Site Isolation for password -sites on Chrome for Android (on devices with at least 2GB of memory), bringing -Spectre mitigations to mobile devices! Second, we added enough compromised -renderer protections on Chrome for Desktop to include cross-site data disclosure -to the [Chrome -VRP](https://www.google.com/about/appsecurity/chrome-rewards/index.html)! We're -very excited about the new protections, and we continue to improve the defenses -on both Android and Desktop. Separately, we [presented our USENIX Security -paper](https://www.usenix.org/conference/usenixsecurity19/presentation/reis) in -August and launched OOPIF-based PDF support, clearing the way to remove -BrowserPlugin. - -In the Web PKI space, the government of Kazakhstan recently created a Root CA -and with local ISPs engaged in a campaign to encourage all KZ citizens to -install and trust the CA. Ripe Atlas detected this CA [conducting a -man-in-the-middle](https://censoredplanet.org/kazakhstan) on social media. -Chrome blocked this certificate to prevent it from being used for MITMing Chrome -users. In conjunction with several other major browsers, we made a [joint PR -statement](https://blog.mozilla.org/blog/2019/08/21/mozilla-takes-action-to-protect-users-in-kazakhstan/) -against this type of intentional exploitation of users. Following this incident, -we began working on a long-term solution to handling MITM CAs in Chrome. - -In hacker philanthropy news, in July we increased the amounts awarded to -security researchers who submit security bugs to us under the [Chrome -Vulnerability Reward Program](https://g.co/ChromeBugRewards). The update aligned -both categories and amounts with the areas we'd like researchers to focus on. -This generated some good [press -coverage](https://techcrunch.com/2019/07/18/google-will-now-pay-bigger-rewards-for-discovering-chrome-security-bugs/) -which should help spread the word about the Chrome VRP. Tell your friends, and -submit your Chrome security bugs -[here](https://bugs.chromium.org/p/chromium/issues/entry?template=Security%20Bug) -and they'll be considered for a reward when they're fixed! - -In Chrome security generally we've been working to address an issue called the -“patch gap”, where security bug fixes are posted in our open-source code -repository but then take some time before they are released as a Chrome stable -update. During that time, adversaries can use those fixes as evidence of -vulnerabilities in the current version of Chrome. To reduce this problem, we’ve -been merging more security fixes directly to stable, and we’re now always making -a security respin mid-way through the six-week development cycle. This has -reduced the median patch gap from ~33 days in Chrome 76 to ~19 days in Chrome -77. This is still too long, and we’re continuing to explore further solutions. - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q2 2019 - -Greetings, - -With 2019 already more than 58% behind us, here's an update on what Chrome -Security was up to in the second quarter of this year. - -Chrome SafeBrowsing is launching stricter download protections for [Advanced -Protection](https://landing.google.com/advancedprotection/) users, and a -teamfood has begun to test the policy in M75. This will launch broadly with M76. -This significantly reduces an Advanced Protection user’s exposure to potentially -risky downloads by showing them warnings when they try to download “risky” files -(executable files that haven’t been vetted by SafeBrowsing) in Chrome. - -Users need to understand site identity to make safe decisions on the web. Chrome -Security UX published a [USENIX Security -paper](https://ai.google/research/pubs/pub48199) exploring how users understand -modern browser identity indicators. To help users understand site identity from -confusing URLs, we launched a [new -warning](https://security.googleblog.com/2019/06/new-chrome-protections-from-deception.html) -detecting domains that look similar to domains you’ve visited in the past. We -published a -[guide](https://docs.google.com/document/d/1_xJz3J9kkAPwk3pma6K3X12SyPTyyaJDSCxTfF8Y5sU/edit) -to how we triage spoofing bugs involving such domains. We also built a -[Suspicious Site Reporter -extension](https://chrome.google.com/webstore/detail/suspicious-site-reporter/jknemblkbdhdcpllfgbfekkdciegfboi) -that power users can use to report deceptive sites to Google’s Safe Browsing -service, to help protect non-technical users who might not be able to discern a -deceptive site’s identity as well. - -Site identity is meaningless without HTTPS, and we continue to promote HTTPS -adoption across the web. We implemented an experimental flag to -[block](https://groups.google.com/a/chromium.org/d/msg/blink-dev/mALJa0JM13I/-jxMlOyrBAAJ) -high-risk nonsecure downloads initiated from secure contexts. And we continued -to roll out our experiment that auto-upgrades mixed content to HTTPS, pushing to -10% of beta channel and adding new metrics to quantify breakage. - -In addition to helping with the usual unfaltering flow of security launch -reviews, Platform Security engineers have been continuing to investigate ways to -help Chrome engineers create fewer memory safety bugs for clusterfuzz to find. -While performance is a concern when adding checks to libraries, some reports of -regressions nicely turned out to be [red -herrings](https://bugs.chromium.org/p/chromium/issues/detail?id=957296#c15). On -macOS, Chrome executables are [now -signed](https://chromium-review.googlesource.com/c/chromium/src/+/1666734) with -the [hardened runtime -options](https://developer.apple.com/documentation/security/hardened_runtime_entitlements) -enabled. Also on macOS, the change to have [Mojo use Mach -IPC](https://docs.google.com/document/d/1nEUEAP3pq6T9WgEucy2j02QwEHi0PaFdpaQcT8ooH9E/edit#), -rather than POSIX file descriptors/socket pairs, is now fully rolled out. On -Windows, we started to -[enable](https://bugs.chromium.org/p/chromium/issues/detail?id=961831) -[Arbitrary Code -Guard](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/exploit-protection-exploit-guard#mitigation-comparison) -on processes that don't need dynamic code at runtime. - -We've done a lot of analysis on the types of security bugs which are still -common in Chromium. The conclusion is that memory safety is still our biggest -problem, so we've been working to figure out the best next steps to solve -that—both in terms of safer C++, and investigating other choices to find if we -can parse data in a safe language without disrupting the Chromium development -environment too much. - -We've also been looking at how security fixes are released, to ensure fixes get -to our users in the quickest possible way. We have also improved some of the -automatic triage that Clusterfuzz does to make sure that bugs get the right -priority. - -To augment our fuzzing efforts and find vulnerabilities for known bad patterns, -we have decided to invest in static code analysis efforts with -[Semmle](https://semmle.com/). We have written our custom QL queries and -reported -[15](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=label%3AFound-With-Semmle) -bugs so far (some of these were developed in collaboration with [Project -Zero](https://googleprojectzero.blogspot.com/)). - -We have made several changes to improve fuzzing efficiency which include - -leveraging [DFSan](https://clang.llvm.org/docs/DataFlowSanitizer.html) for -[focused mutations](https://github.com/google/clusterfuzz/issues/503), added -support for [custom mutators](https://github.com/google/clusterfuzz/pull/286), -build-type optimizations (sanitizers without instrumentation) and libFuzzer fork -mode on Windows. We have -[upstreamed](https://cs.chromium.org/chromium/src/third_party/libFuzzer/src/utils/FuzzedDataProvider.h) -a helper module in libFuzzer to make it easy to split fuzz input and decrease -fuzz target complexity. - -The Open Web Platform Security team was mainly focused on [Trusted -Types](https://github.com/WICG/trusted-types), and conducted an Origin Trial for -the feature in Q2. The team is presently scrambling to address the issues raised -by public feedback, to modify the feature to make it easier to deploy, and to -generally make Trusted Types fit for a full launch. - -The [Site Isolation](/Home/chromium-security/site-isolation) team published -their Usenix Security 2019 paper about the desktop launch ([Site Isolation: -Process Separation for Web Sites within the -Browser](https://ai.google/research/pubs/pub48285)), which will be presented in -August. We now have a small Stable channel trial of Android Site Isolation, -which isolates the sites that users log into rather than all sites. That work -included persisting and clearing the sites to isolate, fixing text autosizing, -and adding more metrics. Separately, we ran a trial of isolating origins rather -than sites to gauge overhead, and we helped ship [Sec-Fetch-Site -headers](https://w3c.github.io/webappsec-fetch-metadata/). We also started -collecting data on how well CORB is protecting sensitive resources in practice, -and we've started launch trials of out-of-process iframe based PDFs (which adds -CORB protection for PDFs). - -The Chrome OS Security team has been working on the technology underlying Chrome -OS verified boot. Going forward, dm_verity will use SHA256 as its hashing -algorithm, replacing SHA1. So long, weak hashing algorithm! - -We also spent some time making life easier for Chrome OS developers. Devs now -have access to a -[time-of-check-time-of-use](https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use) -safe [file -library](https://chromium.googlesource.com/chromiumos/platform2/libbrillo/+/HEAD/brillo/safe_fd.h), -and a [simplified -mechanism](https://groups.google.com/a/chromium.org/d/msg/chromium-os-dev/zYP4tlXQmRg/aMyd2l-SBAAJ) -for building system call filtering policies. - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q1 2019 - -Greetings, - -Here's an update on what Chrome Security was up to in the first quarter of 2019! - -The [Site Isolation](/Home/chromium-security/site-isolation) team finished the -groundwork for Android Beta Channel field trials, and the trials are now in -progress. This Android mode isolates a subset of sites that users log into, to -protect site data with less overhead than isolating all sites. We also started -enforcing Cross-Origin Read Blocking for [extension content script -requests](/Home/chromium-security/extension-content-script-fetches), maintaining -a temporary allowlist for affected extensions that need to migrate. We tightened -compromised renderer checks for navigations, postMessage, and BroadcastChannel. -We also continued cross-browser discussions about [Long-Term Web Browser -Mitigations for -Spectre](https://docs.google.com/document/d/1dnUjxfGWnvhQEIyCZb0F2LmCZ9gio6ogu2rhMGqi6gY/edit?usp=sharing), -as well as headers for [isolating -pages](https://github.com/whatwg/html/issues/3740) and [enabling precise -timers](https://github.com/whatwg/html/issues/4175). Finally, we are close to -migrating PDFs from BrowserPlugin to out-of-process iframes, allowing -BrowserPlugin to be deleted. - -In the last several years, the Usable Security team have put a lot of effort -into [improving HTTPS -adoption](https://transparencyreport.google.com/https/overview) across the web, -focusing on getting top sites to migrate to HTTPS for their top-level resources. -We’re now starting to turn our attention to insecure subresources, which can -harm user security and privacy even if the top-level page load is secure. We are -currently running an -[experiment](https://chromestatus.com/feature/5557268741357568) on Canary, Dev, -and Beta that automatically upgrades insecure subresources on secure pages to -HTTPS. We also collected metrics on insecure downloads in Q1 and have started -putting together a -[proposal](https://lists.w3.org/Archives/Public/public-webappsec/2019Apr/0004.html) -to block high-risk insecure downloads initiated from secure pages. - -People need to understand website identity to make good security and trust -decisions, but -[lots](http://people.ischool.berkeley.edu/~tygar/papers/Phishing/why_phishing_works.pdf) -[of](http://www.usablesecurity.org/papers/jackson.pdf) -[research](http://grouplab.cpsc.ucalgary.ca/grouplab/uploads/Publications/Publications/2011-DomainHighlighting.CHI.pdf) -suggests that they don’t. We summarized our own research and thinking on this -topic in an [Enigma 2019 talk](https://www.youtube.com/watch?v=RPoAc0ScdTM). We -open-sourced a [tool](https://github.com/chromium/trickuri) that we use to help -browser developers display site identity correctly. We also published a set of -[URL display -guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/url_display_guidelines/url_display_guidelines.md) -and subsequently incorporated them into the [URL -standard](https://url.spec.whatwg.org/#url-rendering). - -The Safe Browsing team increased the coverage against malware and unwanted -software downloads by changing the logic of which file types to check against -Safe Browsing. We flipped the heuristic to an allow-list of known-safe file -extensions, and made the rest require verification. This adds protection from -both the [uncommon -](https://chromium-review.googlesource.com/c/chromium/src/+/1459317)file -extensions (where attackers convince users to rename them to a common executable -after scanning), and from [Office document -types](https://chromium-review.googlesource.com/c/chromium/src/+/1449110) where -the incidence of malware has increased significantly. - -The Chrome Cleanup Tool is now in the Chromium repository! This lets the public -audit the data collected by the tool, which is a win for user privacy, and gives -an example of how to sandbox a file scanner. The open source version includes a -sample scanner that detects only test files, while the version shipped in Chrome -will continue to depend on internal resources for a licensed engine. - -The Bugs-- team has [open sourced](https://github.com/google/clusterfuzz) -ClusterFuzz, a fuzzing infrastructure that we have been developing over the past -8 years! This army of robots has found 30,000+ bugs in Chrome and 200+ open -source projects. To improve the efficiency of our cores, we have developed -automated fuzzer weights management based on fuzzer quality/freshness/code -changes. Additionally, we have developed several new WebGL fuzzers (some of them -leverage [GraphicsFuzz](https://github.com/google/graphicsfuzz)) and found -[63](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=metzman_graphicsfuzz_crash_fuzzer+-status%3AWontFix%2CDuplicate+OR+metzman_graphicsfuzz_mutator++-status%3AWontFix%2CDuplicate+OR+metzman_webgl_api_fuzzer++-status%3AWontFix%2CDuplicate+OR+metzman_webgl_mutator++-status%3AWontFix%2CDuplicate) -bugs. We have significantly scaled up fuzzing Chrome on Android (x86) by using -[Cuttlefish](https://github.com/google/android-cuttlefish) over -[GCE](https://cloud.google.com/compute/docs/). Lastly, we have transitioned -Chrome code coverage tools development to Chrome Infra team, see the new dash -[here](https://analysis.chromium.org/p/chromium/coverage). - -The Platform Security team added some checks for basic safety to our base and -other fundamental libraries, and are investigating how to do more while -maintaining efficiency (run-time, run space, and object code size). We hope to -continue to do more, as well as investigate how to use absl without forgoing the -safety checks. We’ve been having great success with this kind of thing in PDFium -as well, where we’ve found that the compiler can often optimize away these -checks, and investigating where it hasn’t been able to has highlighted several -pre-existing bugs. On macOS, we have re-implemented the Mojo IPC Channel under -the hood to use Mach IPC, which should help reduce system resource shortage -crashes. This also led to the development of two libprotobuf-mutator (LPM) -fuzzers for Mach IPC servers. We’re working on auto-generating an LPM based -fuzzer from Mojo API descriptions to automatically fuzz Mojo endpoints, -in-process. We also continue to write LPM fuzzers for tricky-to-reach areas of -the code like the disk cache. We are also investigating reducing the privilege -of the network process on Windows and macOS. - -Our next update will be the first full quarter after joining Chrome Trust and -Safety. We're looking forward to collaborating with more teams who are also -working to keep our users safe! - -Cheers, - -Andrew on behalf of Chrome Security - -## Q4 2018 - -Greetings, - -With the new year well underway, here's a look back at what Chrome Security was -up to in the last quarter of 2018. - -In our quest to make HTTPS the default, we started marking HTTP sites with a red -Not Secure icon when users enter data into forms. This change launched to stable -in Chrome 70 in October. A new version of the HTTPS error page also launched to -the stable channel as an experiment: it looks the same but is much improved -[under the -hood](https://docs.google.com/document/d/1rEBpw5V-Nn1UIi8CIFa5ZZvwlR08SkY3CogvWE2UMFs/edit). -We built a new version of the [HTTPS Transparency -Report](https://transparencyreport.google.com/https/overview?hl=en) for top -sites; the report now displays aggregate statistics for the top sites instead of -individual sites. We also built a [new interstitial -warning](https://blog.chromium.org/2018/11/notifying-users-of-unclear-subscription.html) -to notify Chrome users of unclear mobile subscription billing pages. The new -warning and policy launched in Chrome 71. - -The Bugs-- team ported libFuzzer to work on Windows, which was previously -lacking coverage guided fuzzing support, and this resulted in -[93](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=windows_libfuzzer_chrome_asan+reporter%3Aclusterfuzz%40chromium.org+-status%3Aduplicate%2Cwontfix&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) -new bugs. We hosted a month-long -[Fuzzathon](https://groups.google.com/a/chromium.org/d/msg/chromium-dev/MAiBRTllPuI/hPbEMRWQDAAJ) -in November, focused on improving fuzz coverage for Chrome’s browser process and -Chrome OS. This effort led to 85 submissions and -[157](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=-status%3AWontFix%2CDuplicate+id%3A907387%2C908754%2C903899%2C907386%2C904054%2C911112%2C904053%2C906711%2C912230%2C906370%2C907662%2C907663%2C910842%2C910843%2C906416%2C906417%2C906418%2C907302%2C903724%2C906395%2C906393%2C906391%2C911475%2C906399%2C908049%2C901782%2C907912%2C908196%2C906007%2C908829%2C907847%2C905334%2C912202%2C910918%2C912208%2C910917%2C904613%2C906568%2C906374%2C907561%2C907560%2C912455%2C907070%2C903251%2C910852%2C910851%2C903252%2C906396%2C910480%2C903828%2C911030%2C906349%2C908678%2C903052%2C903782%2C912219%2C902693%2C902690%2C904689%2C904682%2C905273%2C905272%2C905275%2C907999%2C911320%2C906352%2C906350%2C906356%2C906354%2C910497%2C910970%2C906359%2C904055%2C905649%2C910930%2C905401%2C906469%2C906705%2C910522%2C907693%2C906462%2C910835%2C902964%2C907051%2C906466%2C906372%2C903772%2C912299%2C911155%2C910926%2C910929%2C910928%2C906659%2C903233%2C907345%2C907344%2C904093%2C904090%2C905413%2C906329%2C909713%2C908781%2C905985%2C909801%2C912506%2C906801%2C901649%2C904382%2C905259%2C902605%2C908039%2C903280%2C904141%2C908004%2C910898%2C902131%2C910069%2C904655%2C910896%2C903088%2C906337%2C906440%2C912476%2C906333%2C908392%2C902227%2C912479%2C906448%2C906339%2C910248%2C904712%2C904792%2C910469%2C903690%2C901239%2C902860%2C911700%2C906381%2C906382%2C911822%2C905621%2C904725%2C910866%2C910862%2C911827%2C910860%2C907524%2C901675%2C901674%2C906438%2C906439%2C910892%2C907278%2C904736%2C904734%2C907718%2C907157%2C910592%2C908237%2C907453%2C908232%2C904105%2C908230%2C912227%2C912224%2C912223%2C904221%2C905463%2C903237%2C903236%2C904227%2C903234%2C906425%2C906421%2C906423%2C906422%2C906429%2C906428%2C908209%2C911409%2C912520&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) -bugs. We have added more automation towards auto-adjusting cpu cycles allocated -to various fuzzers based on code coverage changes and recency of fuzzer -submission. Lastly, we added Linux x86 fuzzing configurations -([1](https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Libfuzzer%20Upload%20Linux32%20ASan), -[2](https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Libfuzzer%20Upload%20Linux32%20ASan%20Debug)) -for libFuzzer, which resulted in -[100](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=x86_libfuzzer_chrome_asan+-status%3AWontFix%2CDuplicate+OR+x86_libfuzzer_chrome_asan_debug+-status%3AWontFix%2CDuplicate&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) -new bugs. - -In Platform Security, we started sandboxing the network service on macOS. On -Windows, we’re starting to experiment with an improved GPU sandbox. The network -service has the beginnings of a sandbox on Windows, and we’ll be working on -tightening it in future work. We’re also continuing to gradually harden the -implementations of core Chromium libraries in base/ and elsewhere. We had a -great adventure finding and fixing bugs in SQLite as well, including an -innovative and [productive new -fuzzer](https://github.com/google/fuzzer-test-suite/blob/master/tutorial/structure-aware-fuzzing.md#example-sqlite). -We’re continuing to hammer away at bugs in PDFium, and refactoring it -significantly. - -To help sites defend against cross-site scripting (XSS), we are working on -[Trusted Types](https://wicg.github.io/trusted-types/dist/spec/). This aims to -bring a derivative of Google's "[Safe HTML -Types](https://github.com/google/safe-html-types/blob/master/doc/safehtml-types.md)" -— which relies on external tooling that may be incompatible with existing -workflows or code base — directly into the web platform, thus making it -available to everyone. Both Google-internal and [external -teams](https://github.com/cure53/DOMPurify/blob/master/demos/trusted-types-demo.html) -are presently working on integrating Trusted Types into existing frameworks -which, if successful, offers the chance to rapidly bring this technique to large -parts of the web. Chrome 73 will see an [origin -trial](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/I9To21DXcLo/NrU9P0M4EAAJ). - -The work on [Site Isolation](/Home/chromium-security/site-isolation) continues -as we focus on enabling it on Android — support for adding isolated origins at -runtime, fixing issues with touch events, and balancing process usage for -maximizing stability. We added improvements to CORB to prevent bypasses from -exploited renderers, we announced [extensions changes for content script -requests](/Home/chromium-security/extension-content-script-fetches), and we -reached out to affected authors with guidance on how to update. Additionally, we -continue to add more enforcements to mitigate compromised renderers, which is -the ultimate end goal of the project. Last but not least, we have worked to -improve code quality and clean up architectural deficiencies which accumulated -while developing the project. - -Chrome OS 71 saw the initial, limited release of USBGuard, a technology that -improves the security of the Chrome OS lock screen by (carefully) blocking USB -devices on the lock screen. - -As ever, many thanks to all those in the Chromium community, and our VRP -reporters, who help make the Web more secure! - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q3 2018 - -Greetings! - -Chrome turned 10 in September! Congrats to the team on a [decade of making the -web more -secure](https://www.wired.com/story/chrome-decade-making-the-web-more-secure/). - -In the quest to find security bugs, the Bugs-- team incorporated Machine -Learning in ClusterFuzz infrastructure using [RNN -model](https://en.wikipedia.org/wiki/Recurrent_neural_network) to improve upon -corpus quality and code coverage. We experimented with improving fuzzing -efficiency by adding instability handling and mutation stats strategies inside -libFuzzer. We added a new [Mojo service -fuzzer](https://bugs.chromium.org/p/chromium/issues/detail?id=607649) by -extending the Mojo javascript bindings and found [security -bugs](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=mojo_fuzzer+label%3AClusterFuzz+Type%3DBug-Security&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids). -We also -[migrated](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/code_coverage.md) -our fuzzing infrastructure to provide [Clang Source-based Code -Coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html) reports and -deprecated [Sancov](https://clang.llvm.org/docs/SanitizerCoverage.html). - -The Platform Security team continued to add hardening and checks to fundamental -classes and libraries in base/, and did some of the same work in PDFium and -other parsers and interpreters in Chromium. We also provided some sandboxing -consulting to other teams for their new services including audio and networking. - -Chrome on macOS now has a new sandbox architecture, launched in Chrome 69, which -immediately initializes when a new process executes. This reduces Chrome’s -attack surface and allows better auditing of system resource access between -macOS versions. - -Chrome OS Security wrapped up the response to the [L1TF -vulnerability](https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html), -fixes for which enabled shipping Linux apps on Chrome OS without exposing users -to extra risk. Moreover, we received [an (almost) full-chain exploit for Chrome -OS](https://bugs.chromium.org/p/chromium/issues/detail?id=884511) that both -validated earlier sandboxing work (like for Shill, Chrome OS’s connection -manager) and also shed light on further hardening work that was wrapped up in -Q3. - -Chrome 70 shipped TLS 1.3, although we did have to disable a downgrade check in -this release due to a last-minute incompatibility with some network devices. - -After the excitement [enabling Site Isolation by default on desktop -platforms](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) -in Q2, the team has been focused on building a form of Site Isolation suitable -for devices that run Android, which have more limited memory and processing -power. We've been fixing Android-specific issues (alongside a lot of maintenance -for the desktop launch), we have started field trials for isolating a subset of -sites, and we are working on ways to add more sites to isolate at runtime. -Separately, we added several more enforcements to mitigate compromised -renderers, to extend the protection beyond Spectre. - -Users should expect that the web is safe by default, and they’ll be warned when -there’s an issue. In Chrome 68, we hit a milestone for Chrome security UX, -[marking all HTTP -sites](https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/) -as “not secure”. We continued down that path in Chrome 70, [showing the “not -secure” string in -red](https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/) -when users enter data on an HTTP page. We began stepping towards removing -Chrome’s positive security indicators so that the default unmarked state is -secure, starting by [removing the “Secure” -wording](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html) -in Chrome 69. - -We [would like to -experiment](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ZJxkCJq5zo4/4sSMVZzBAwAJ) -with mixed content autoupgrading to simplify (i.e. improve) the user experience, -and are currently collecting metrics about the impact. We’re also working to -improve Chrome security UX under the hood -- we launched [committed HTTPS -interstitials](https://docs.google.com/document/d/1rEBpw5V-Nn1UIi8CIFa5ZZvwlR08SkY3CogvWE2UMFs/edit) -on Canary and Dev. - -As ever, many thanks to all those in the Chromium community, and our[ VRP -reporters](https://www.google.com/about/appsecurity/chrome-rewards/index.html), -who help make the Web more secure! - -Cheers, - -Andrew, on behalf of the Chrome security team - -## Q2 2018 - -Greetings and salutations, - -It's time for another (rather belated!) update from your friends in Chrome -Security, who are hard at work to keep Chrome the most secure platform to browse -the Internet. - -We're very excited that [Site Isolation](/Home/chromium-security/site-isolation) -is now [enabled by -default](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) -as a Spectre mitigation in M67 for Windows, macOS, Linux, and Chrome OS users! -This involved an incredible number of fixes from the team in Q2 to make -out-of-process iframes fully functional, especially in areas like painting, -input events and performance, and it included standardizing [Cross-Origin Read -Blocking (CORB)](/Home/chromium-security/corb-for-developers). Stay tuned for -more updates on Site Isolation coming later this year, including additional -protections from compromised renderers. Chris and Emily talked about Spectre -response, Site Isolation, and necessary developer steps [at -I/O](https://youtu.be/dBuykrdhK-A). We also announced that security bugs found -in Site Isolation could qualify for [higher VRP reward -payments](https://www.google.com/about/appsecurity/chrome-rewards/index.html#special) -for a limited time. - -In their quest to find security bugs, the Bugs-- team integrated [Clang -Source-based Code -Coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html) into -Chromium project and launched a -[dashboard](https://chromium-coverage.appspot.com/) to make it easy for -developers to see which parts of the code are not covered by fuzzers and unit -tests. We wrote a [Mojo service -fuzzer](https://cs.chromium.org/chromium/src/mojo/public/tools/fuzzers/) that -generates fuzzing bindings in JS and found some scary -[vulnerabilities](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=mojo_fuzzer+Type%3DBug-Security&sort=-type&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified+Type&x=m&y=releaseblock&cells=ids). -We added [libFuzzer fuzzing support in Chrome -OS](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/fuzzing.md) and -got new fuzz target contributions from Chrome OS developers and found several -[bugs](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=libfuzzer_asan_chromeos+-status%3ADuplicate%2CWontFix+label%3AClusterFuzz&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids). -We made numerous improvements to our ClusterFuzz fuzzing infrastructure, -examples include dynamically adjusting CPU allocation for inefficient fuzz -targets until their performance issues are resolved, cross-pollinating corpuses -across fuzz targets and projects, and more. - -The Platform Security team has been working on adding bounds checks and other -sanity checks to -[base/containers](https://bugs.chromium.org/p/chromium/issues/detail?id=817982), -as part of an overarching effort to harden heavily-used code and catch bugs. -We’ve had some good initial success and expect to keep working on this for the -rest of the year. This is a good area for open source contributors and VRP -hunters to work on, too! - -In our quest to move the web to 100% HTTPS, we prepared for showing Not Secure -warnings on all http:// pages which started in M68. We sent Search Console -messages to affected sites and expanded our [enterprise -controls](/administrators/policy-list-3#UnsafelyTreatInsecureOriginAsSecure) for -this warning. We -[announced](https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html) -some further changes to Chrome’s connection security indicators: in M69, we’ll -be removing the Secure chip next to https:// sites, and in M70 we’ll be turning -the Not Secure warning red to more aggressively warn users when they enter data -on a non-secure page. - -We also added some features to help users and developers use HTTPS more often. -The omnibox now remembers pages that redirect from http:// to https://, so that -users don’t get sent to the http:// version in the future. We fixed a -longstanding bug with the -[upgrade-insecure-requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests) -CSP directive that helps developers find and fix mixed content: it now upgrades -requests when following redirects. Finally, we added a setting to -chrome://flags#unsafely-treat-insecure-origin-as-secure to let developers more -easily test HTTPS-only features, especially on Android and ChromeOS. - -To better protect users from unwanted extensions, we announced [the deprecation -of inline installations for -extensions](https://blog.chromium.org/2018/06/improving-extension-transparency-for.html). -This change will result in Chrome users being directed to the Chrome Web Store -when installing extensions, helping to ensure user can make a better informed -decision. - -Chrome OS spent a big chunk of Q2 updating and documenting our processes to -ensure we can better handle future incidents like Spectre and Meltdown. We -expanded our [security review -guidelines](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/security_review_howto.md) -so that they can be used both by security engineers while reviewing a feature, -as well as by SWE and PM feature owners as they navigate the Chrome OS launch -process. - -We continued our system hardening efforts by making Shill, the Chrome OS network -connection manager, run in a restrictive, non-root environment starting with -M69. [Shill was exploited as part of a Chrome OS full-chain -exploit](https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html), -so sandboxing it was something that we’ve been wanting to do for a long time. -With PIN sign-in launching with M68, the remaining work to make the underlying -user credential brute force protection mechanism more robust is underway, and we -plan to enable it for password authentication later this year. Hardening work -also happened on the Android side, as we made progress on functionality that -will allow us to verify generated code on Android using the TPM. - -Q2 continued to require incident response work on the Chrome OS front, as the -fallout from Spectre and Meltdown included several researchers looking into the -consequences of speculative execution. The good news is that we started -receiving updated microcode for Intel devices and these updates will start to go -out with M69. - -As ever, many thanks to all those in the Chromium community, and our [VRP -reporters](https://www.google.com/about/appsecurity/chrome-rewards/index.html), -who help make the Web more secure! - -Cheers - -Andrew - -on behalf of the Chrome Security Team - -## Q1 2018 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard at work trying to keep Chrome as the most secure platform to browse the Internet. We'd also like to welcome our colleagues in Chrome OS security to this update - you'll be able to hear what they've been up to each quarter going forward.** - -In our effort to find and fix bugs, we collaborated with the [Skia](https://skia.org/) team and [integrated](https://github.com/google/oss-fuzz/tree/master/projects/skia) 21 fuzz targets into OSS-Fuzz for continuous 24x7 fuzzing on Skia trunk. So far, we have found [38](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Proj%3Dskia+Type%3DBug-Security+-status%3ADuplicate&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids) security vulns! We also added several new fuzz targets as part of a 2-week bug bash (e.g. [multi-msg mojo fuzzer](https://chromium-review.googlesource.com/c/chromium/src/+/973685), [audio decoder fuzzer](https://chromium-review.googlesource.com/c/chromium/src/+/976184), [appcache manifest parsing fuzzer](https://chromium-review.googlesource.com/c/chromium/src/+/982677), [json fuzzer](https://chromium-review.googlesource.com/c/chromium/src/+/959564) [improvements](https://chromium-review.googlesource.com/c/chromium/src/+/971063), etc) and found an additional [vulnerability](https://crbug.com/826193) through code review. We added libFuzzer support for Chrome OS and integrated it with ClusterFuzz. Sample [puffin fuzzer](https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/944190) found [11](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=libfuzzer_asan_chromeos+-status%3AWontFix%2CDuplicate&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&x=m&y=releaseblock&cells=ids) bugs (includes 2 security). We made several improvements to AFL fuzzing engine integration and fuzzing strategies. This brings it on-par with libFuzzer in terms of the number of bugs found -- it's now ~3X more productive than before! We added support for building MSan instrumented system libraries for newer debian distros ([1](https://github.com/google/oss-fuzz/issues/608), [2](/developers/testing/memorysanitizer)). - -To [help users infected with unwanted software](https://support.google.com/chrome/answer/2765944?co=GENIE.Platform%3DDesktop&hl=en), we moved the standalone Chrome Cleanup Tool into Chrome. Scanning and cleaning Windows machines can now be triggered by visiting chrome://settings/cleanup. There was some misunderstanding on Twitter about why Chrome was scanning, which we clarified. We also pointed people to the [unwanted software protection](https://www.google.com/chrome/privacy/whitepaper.html#unwantedsoftware) section of Chrome's privacy whitepaper so they can understand what data is and isn’t sent back to Google. - -In our effort to move the web to 100% HTTPS, we [announced](https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html) that Chrome will start marking all HTTP pages with a Not Secure warning in July. This is a big milestone that concludes a multi-year effort to roll out this warning to all non-secure pages. Alongside that announcement, we added a [mixed content audit](https://developers.google.com/web/tools/lighthouse/audits/mixed-content) to [Lighthouse](https://developers.google.com/web/tools/lighthouse/), an automated tool for improving webpage quality. This audit helps developers find and fix mixed content, a major hurdle for migrating to HTTPS. We also [announced](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ANnafFBhReY/1Xdr53KxBAAJ) the deprecation of AppCache in nonsecure contexts. - -In addition to MOAR TLS, we also want more secure and usable HTTPS, or BETTER TLS. With that goal in mind, we made changes to get better metrics about features intended to help users with client or network misconfigurations that break their HTTPS connections (like our [customized certificate warnings](https://research.google.com/pubs/archive/46359.pdf)). We also added more of these “helper” features too: for example, we now bundle help content targeted at users who are stuck with incorrect clocks, captive portals, or other configuration problems that interfere with HTTPS. Finally, we started preparing for Chrome’s upcoming Certificate Transparency [enforcement deadline](https://groups.google.com/a/chromium.org/d/msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ) by analyzing and releasing some [metrics](https://www.youtube.com/watch?v=e_rwG7MA5VU) about the state of CT adoption so far. - -To help make security more usable in Chrome, we’re exploring how [URLs are problematic](https://www.youtube.com/watch?v=UD-ukjVoeLc). We removed https/http schemes and www/m subdomains from the steady-state omnibox, and we’re studying the impact of removing positive security indicators that might mislead or distract from the important security information in the origin. - -Chrome OS Security had a busy Q1. The vulnerabilities known as [Meltdown and -Spectre](https://meltdownattack.com/) were disclosed in early January, and a -flurry of activity followed as we rushed to patch older kernels against Meltdown -in Chrome OS 66, and incorporated Spectre fixes for ARM Chrome OS devices in -Chrome OS 67. We also started codifying our [security review guidelines in a -HOWTO -doc](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/security_review_howto.md), -to allow the larger Chrome OS team to better prepare for security reviews of -their features. Moreover, after being bit by symlinks and FIFOs being used as -part of [several](https://bugs.chromium.org/p/chromium/issues/detail?id=344051) -[exploit](https://bugs.chromium.org/p/chromium/issues/detail?id=648971) -[chains](https://bugs.chromium.org/p/chromium/issues/detail?id=766253), we -finally landed -[symlink](https://chromium-review.googlesource.com/c/chromiumos/platform2/+/966683) -and -[FIFO](https://chromium-review.googlesource.com/c/chromiumos/platform2/+/978780) -blocking in Chrome OS 67. On the hardware-backed security front, we've split off -the component that allows irreversible once-per-boot decisions into its own -service, bootlockboxd. Finally, work is nearing completion for a first shipping -version of a hardware-backed mechanism to protect user credentials against -brute force attacks. This will allow PIN codes as a new authentication -mechanism for Chrome OS meeting our authentication security guidelines, and -we'll use it to upgrade password-based authentication to a higher security bar -subsequently. - -Spectre kept us busy on the Chrome Browser side as well. The V8 team landed a large number of JIT mitigations to make Spectre exploits harder to produce, and high resolution timers like SharedArrayBuffer were temporarily disabled; more details on our response [here](/Home/chromium-security/ssca). In parallel, the [Site Isolation](/Home/chromium-security/site-isolation) team significantly ramped up efforts to get Site Isolation launched as a Spectre mitigation, since it helps avoid having data worth stealing anywhere in a compromised process. In Q1, we substantially improved support for the Site Isolation enterprise policies that launched prior to the Spectre disclosure, including: - -* Reducing total memory overhead from 20% to 10%. -* Significantly improving input event handling in out-of-process iframes - (OOPIFs). -* Significantly improving DevTools support for OOPIFs. -* Adding ChromeDriver support for OOPIFs. -* Adding support for printing OOPIFs. -* Improving rendering performance for OOPIFs. -* Starting standards discussions for Cross-Origin Read Blocking (CORB). - -Thanks to these improvements, we have been running field trials and are preparing to launch the strict Site Isolation policy on desktop. We [talked about](https://www.youtube.com/watch?v=dBuykrdhK-A) much of this work at Google I/O. - -Finally, we continue to work on exploit mitigations and other security hardening efforts. For example, [Oilpan](https://chromium.googlesource.com/chromium/src/+/lkcr/third_party/WebKit/Source/platform/heap/BlinkGCDesign.md), blink's garbage collecting memory management system, [removed its inline metadata](https://bugs.chromium.org/p/chromium/issues/detail?id=633030), which make it more difficult to overwrite with memory corruption bugs. This was the culmination of several years of effort, as performance issues were worked through. In Android P, we refactored the WebView [zygote](https://developer.android.com/topic/performance/memory-overview) to become a child of the main app_process zygote, reducing memory usage and helping with the performance of future Site Isolation efforts. Members of Platform Security also helped coordinate the response to Spectre and Meltdown, and still managed to find time to conduct their routine reviews of new [Chrome features](https://www.chromestatus.com/features). - -## Q4 2017 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). As it's the start of 2018, [we -reflected](https://www.blog.google/products/chrome/reflecting-years-worth-chrome-security-improvements/) -on a year’s worth of security improvements, and announced new stats around our -VRP and Safe Browsing warnings. - -Here are some highlights from the last quarter of 2017: - -In effort to find and fix bugs, we (Bugs--): - -Wrote a new and easily extensible javascript fuzzer using -[Babel](https://babeljs.io/), which found 100+ bugs in both V8 -([list](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=ochang_js_fuzzer+-status%3ADuplicate%2CWontFix&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles)) -and other browser javascript engines -([list](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=js_fuzzer+-status%3AWontFix%2CDuplicate&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids)). - -Started integrating [Clang Source-based Code -Coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html) in the -Chromium build system and are deprecating [Sanitizer -Coverage](https://clang.llvm.org/docs/SanitizerCoverage.html). Clang -coverage is very precise, shows hit frequencies and is much easier to -visualize. You can follow progress -[here](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=component%3ATools%3ECodeCoverage). - -Hosted a month long fuzzathon in October where Chromium developers -participated in writing new [fuzz -targets](https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/README.md) -and fixing blockers for existing ones. This resulted in 93 bugs, several of -which were in new uncovered areas of codebase; results -[here](https://clusterfuzz.com/v2/fuzzathon). - -Fixed several -[bugs](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=component%3ATools%3ETest%3EPredator+status%3AFixed%2CVerified&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) -in our automated owner and component assignment pipeline and -[expanded](https://bugs.chromium.org/p/chromium/issues/detail?id=760607) our -builder infrastructure to archive builds more frequently, for more accurate -blame results. Faster and more accurate bug triaging means faster fixes for -users! - -Other than fixing bugs, we (MOAR TLS, Enamel, Safe Browsing) also: - -[Blogged](https://www.blog.google/topics/safety-security/say-yes-https-chrome-secures-web-one-site-time/) -about the massive uptick in HTTPS we saw in 2017: 71 of the top 100 sites on -the Web use HTTPS by default, up from 37 a year ago. We also announced our -continuing platinum sponsorship of Let’s Encrypt. - -Delivered a change (in M62, [announced in -April](https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html)), -extending the “Not Secure” omnibox warning chip to non-secure pages loaded -while Incognito and to non-secure pages after the user edits a form field. - -Added an [enterprise -policy](/administrators/policy-list-3#UnsafelyTreatInsecureOriginAsSecure) -(in M65) for treating insecure origins as secure contexts, to help with -development, testing, and intranet sites that are not secured with HTTPS. - -More tightly integrated Chrome’s captive portal detection with operating -system APIs. This feature helps users log in to captive portals (like hotel -or airport wifi networks) rather than seeing unhelpful TLS certificate -errors. - -[Launched](https://www.blog.google/topics/safety-security/new-security-protections-tailored-you/) -predictive phishing protection to warn users when they’ve typed their Google -password into a never-seen-before phishing site. - -As always, we invest a lot in security architecture and exploit mitigations. -Last quarter, we (Platform Security / Site Isolation): - -Started rolling out the [Mac Sandbox -v2](https://chromium.googlesource.com/chromium/src/+/HEAD/sandbox/mac/seatbelt_sandbox_design.md), -bringing both greater security and cleaner code. - -[Refactored sandbox code out of -//content](https://bugs.chromium.org/p/chromium/issues/detail?id=708738) to -make it easier to use across the system. - -Worked on and helped coordinate Chrome's response to the recently announced -[Spectre and Meltdown CPU -vulnerabilities](https://blog.google/topics/google-cloud/what-google-cloud-g-suite-and-chrome-customers-need-know-about-industry-wide-cpu-vulnerability/) -and worked with the [V8 team](https://developers.google.com/v8/) who -spearheaded Chrome's Javascript and WebAssembly mitigations which are -rolling out to users now. - -Accelerated the rollout of [Site -Isolation](/Home/chromium-security/site-isolation) as a -[mitigation](/Home/chromium-security/ssca) for -[Spectre/Meltdown](https://blog.google/topics/google-cloud/what-google-cloud-g-suite-and-chrome-customers-need-know-about-industry-wide-cpu-vulnerability/). -Enabling Site Isolation reduces the amount of valuable cross-site data that -can be stolen by such attacks. We're working to fix the currently known -issues so that we can start enabling it by default. - -Implemented [cross-site document -blocking](http://www.chromium.org/developers/design-documents/blocking-cross-site-documents) -in (M63) when Site Isolation is enabled. This ensures that cross-site HTML, -XML, JSON, and plain text files are not given to a renderer process on -subresource requests unless allowed by [CORS](https://www.w3.org/TR/cors/). -Both --site-per-process and --isolate-origins modes are [now available via -enterprise -policy](https://www.blog.google/topics/connected-workspaces/security-enhancements-and-more-enterprise-chrome-browser-customers/) -in Chrome 63. - -Ran field trials of --site-per-process and --isolate-origins on 50% of -Chrome Canary instances to measure performance, fix crashes, and spot -potential issues. In a separate launch involving out-of-process iframes and -Site Isolation logic, <https://accounts.google.com> now has a dedicated -renderer process in Chrome 63 to support upcoming requirements for Chrome -Signin. - -We have landed a large number of functional and performance improvements for -Site Isolation, including fixes for input events, DevTools, OAuth, hosted -apps, crashes, and same-site process consolidation which reduces memory -overhead. - -To help users that inadvertently installs unwanted software, we (Chrome -Protector): - -Launched new Chrome Cleanup Tool UI , which we think is more comprehensible -for users. - -Launched a sandboxed ESET-Powered [Chrome Cleanup -Tool](https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/) - -Running on 100% of Chrome users by Nov 23 - -Lastly, we (BoringSSL) deployed TLS 1.3 to Chrome stable for a couple weeks in -December and gathered [valuable -data](https://www.ietf.org/mail-archive/web/tls/current/msg25168.html). - -As ever, many thanks to all those in the Chromium community who help make the -Web more secure! - -Cheers - -Andrew - -on behalf of the Chrome Security Team - -## Q3 2017 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Give you're reading this, you might well be -interested in [two -whitepapers](https://www.blog.google/topics/connected-workspaces/2-new-white-papers-examine-enterprise-web-browser-security/) -evaluating enterprise browser security that were released recently. - -Beyond that, here's a recap from last quarter: - -Bugs-- team - -We've been researching ways to fuzz grammar based formats efficiently. We -experimented with in-process fuzzing with -[libprotobuf-mutator](https://github.com/google/libprotobuf-mutator) and -added a -[sample](https://chromium.googlesource.com/chromium/src/+/HEAD/testing/libfuzzer/libprotobuf-mutator.md). - -Recent ClusterFuzz improvements for developers: - - The [reproduce tool](https://github.com/google/clusterfuzz-tools) is now - out of beta and supports Linux and Android platforms. - - Performance improvements to ClusterFuzz UI and migrated to [Polymer - 2](https://www.polymer-project.org/2.0/docs/about_20). - - We finished the remaining pieces of our end-to-end bug triage automation - and are now auto-assigning - [owners](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=label%3ATest-Predator-AutoOwner&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) - and - [components](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=label%3ATest-Predator-AutoComponents&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) - for all newly filed bugs. - -We have also made infrastructure improvements to -[OSS-Fuzz](https://github.com/google/oss-fuzz) to better isolate workloads -between different projects. OSS-Fuzz continues to improve the security of -the overall web -([74](https://github.com/google/oss-fuzz/tree/master/projects) projects -running 24x7, -[636](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=-component%3AInfra+status%3ANew%2CFixed%2CVerified+Type%3DBug-Security+&sort=-id&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids) -security bugs fixed)! - -Enamel, Permissions - -We began [marking FTP as Not -Secure](https://groups.google.com/a/chromium.org/d/msg/security-dev/HknIAQwMoWo/xYyezYV5AAAJ) -with Chrome 63. - -We published a [paper](https://research.google.com/pubs/pub46359.html) in -CCS 2017 describing years of work we’ve done to investigate and mitigate -false-positive certificate errors. We also launched new improvements to help -users who see lots of these spurious errors: - - We launched an interstitial to help users with buggy MITM Software with - Chrome 63 (see chrome://interstitials/). - - We launched an interstitial to help users affected by Superfish with - Chrome 61 (see chrome://interstitials/). - - Better integration with the OS for captive portal detection on Android - and Windows in Chrome 63. - -Launched new [Site -Details](https://docs.google.com/document/d/1gQG1-QjOuswdwZC-yMhWai7divOPXiCp0mO82SO5VSs/edit?pli=1) -page. - -Removed non-factory-default settings from PageInfo and added back in the -Certificate Viewer link. - -Launching [modal permission prompts on Android -](https://blog.chromium.org/2017/10/chrome-63-beta-dynamic-module-imports_27.html)in -M63. - -Removed the ability to request Notification permission from iframes and over -HTTP. - -MOAR TLS - -The change to [mark HTTP -pages](https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html) -in Incognito or after form field editing as Not Secure is in Chrome 62. We -sent > 1 million Search Console messages warning webmasters about this -change. - -Google is [preloading HSTS for more -TLDs](https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html), -the first new ones since .google was preloaded in 2015. - -Chrome Safe Browsing - -Launched the [PVer4](https://developers.google.com/safe-browsing/v4/) -database-update protocol to all users, saving them 80% of the bandwidth used -by Safe Browsing. - -Platform Security - -Added support for [new Win10 sandbox -mitigations](https://bugs.chromium.org/p/chromium/issues/detail?id=733739) -in M61 as part of our continued Windows Sandbox efforts. - -To help block 3rd-party code being injected into Chrome processes on Windows -we've [Enabled third-party blocking on all child -processes](https://bugs.chromium.org/p/chromium/issues/detail?id=750886#c1), -after warmup (delayed mitigation), in M62. - -New in Android O, the Chrome-powered WebView component [now renders content -in a separate, sandboxed -process](https://android-developers.googleblog.com/2017/06/whats-new-in-webview-security.html)! -This brings the same security and stability benefits of Chrome to web pages -rendered within apps. - -Site Isolation - -We launched [OOPIF](/developers/design-documents/oop-iframes)-based -<webview> in M61 for ChromeOS/Mac/Linux and in M62 for Windows. This -eliminates BrowserPlugin for everything except PDFs (which we're working on -now), helping to clean up old code. - -Running an experiment in M63 to give process isolation to -[accounts.google.com](http://accounts.google.com/), to improve Chrome Signin -security. - -Finished design plans for using isolated processes when users click through -SafeBrowsing malware warnings. - -Improved some of the Site Isolation enforcement mechanisms, including -passwords and localStorage. - -Improved OOPIF support in several areas, including basic frame architecture -(e.g., how proxy frames are created), touch selection editing, and gesture -fling. Also making progress on OOPIF printing support. - -As ever, many thanks to all those in the Chromium community who help make the -web more secure! - -Cheers - -Andrew, on behalf of the Chrome Security Team - -## Q2 2017 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Here’s a recap from last quarter: - -The Bugs-- team have released a [new -tool](https://github.com/google/clusterfuzz-tools) to make ClusterFuzz testcase -reproduction easy for developers. Our open source fuzzing efforts (aka -[OSS-Fuzz](https://github.com/google/oss-fuzz)) continue to improve the security -of the overall web -([86](https://github.com/google/oss-fuzz/tree/master/projects) projects, -[1859](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=-component:Infra%20status:New,Fixed,Verified&sort=-id&colspec=ID%20Type%20Component%20Status%20Proj%20Reported%20Owner%20Summary) -bugs, see recent blog post -[here](https://testing.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html)). -We have written a new Javascript fuzzer that has filed -[102](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=inferno_js_fuzzer%20-status:Duplicate,WontFix%20OR%20inferno_js_fuzzer_c%20-status:Duplicate,WontFix&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID%20Pri%20Status%20Summary%20Modified%20OS%20M%20Security_severity%20Security_impact%20Owner%20Reporter) -bugs to date, many with security implications. We also found some interesting -vulnerabilities -([1](https://bugs.chromium.org/p/chromium/issues/detail?id=740710), -[2](https://bugs.chromium.org/p/chromium/issues/detail?id=716044), -[3](https://bugs.chromium.org/p/chromium/issues/detail?id=724299)) through our -code auditing efforts. - -We integrated the Safe Browsing API with WebView [starting in Android -O](https://developer.android.com/preview/features/managing-webview.html), -allowing custom interstitial blocking pages. WebView developers will be able to -opt-in to check URLs against Google Safe Browsing’s list of unsafe websites. - -We understand that sites which repeatedly prompt for powerful permissions often -annoy users and generate warning fatigue. Starting in Chrome 59, we’ve started -[temporarily blocking permission -requests](https://www.chromestatus.com/feature/6443143280984064) if users have -dismissed a permission prompt from a site multiple times. We’re also moving -forward with plans to [deprecate permissions in cross-origin -iframes](/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes) -by default. Permission requests from iframes have the potential to mislead users -into granting access to content they didn’t intend. - -The Platform Security team has concluded several years of A/B experimentation on -Android, and with Chrome 58 we have turned on the [Seccomp-BPF -sandbox](https://bugs.chromium.org/p/chromium/issues/detail?id=166704) for all -compatible devices. This sandbox filters system calls to reduce the attack -surface of the Linux kernel in renderer processes. Currently about 50% of -Android devices support Seccomp, and this number is rising at a steady rate. In -Chrome 59, you can navigate to about:sandbox to see whether your Android device -supports Seccomp. - -We have migrated PDFium to use PartitionAlloc for most allocations, with -distinct partitions for strings, array buffers, and general allocations. In -Chrome 61, all three partitions will be active. - -We continue to work on MOAR+BETTER TLS and -[announced](https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html) -the next phase of our plan to help people understand the security limitations of -non-secure HTTP. Starting in Chrome 62 (October), we’ll mark HTTP pages as “Not -secure” when users enter data in forms, and on all HTTP pages in Incognito mode. -We [presented](https://youtu.be/GoXgl9r0Kjk) new HTTPS migration case studies at -Google I/O, focusing on real-world site metrics like SEO, ad revenue, and site -performance. - -We experimented with improvements to Chrome’s captive portal detection on Canary -and launched them to stable in Chrome 59, to avoid a predicted 1% of all -certificate errors that users see. - -Also, users [may -restore](https://textslashplain.com/2017/05/02/inspecting-certificates-in-chrome/) -the Certificate information to the Page Information bubble! - -Those working on the Open Web Platform have implemented three new [Referrer -Policies](https://w3c.github.io/webappsec-referrer-policy/#referrer-policies), -giving developers more control over their HTTP Referer headers and bringing our -implementation in line with the spec. We also fixed a longstanding bug so that -site owners can now use [upgrade-insecure-requests in conjunction with CSP -reporting](https://w3c.github.io/webappsec-upgrade-insecure-requests/#reporting-upgrades), -allowing site owners to both upgrade and remediate HTTP references on their -HTTPS sites. - -After our launch of --isolate-extensions in Chrome 56, the Site Isolation team -has been preparing for additional uses of [out-of-process -iframes](/developers/design-documents/oop-iframes) (OOPIFs). We implemented a -new --isolate-origins=https://example.com command line flag that can give -dedicated processes to a subset of origins, which is an important step towards -general [Site Isolation](/developers/design-documents/site-isolation). We also -prepared the OOPIF-based <webview> field trial for Beta and Stable -channels, and we ran a Canary field trial of Top Document Isolation to learn -about the performance impact of putting all cross-site iframes into one subframe -process. We've been improving general support for OOPIFs as well, including -spellcheck, screen orientation, touch selection, and printing. The DevTools team -has also helped out: OOPIFs can now be shown in the main frame's inspector -window, and DevTools extensions are now more fully isolated from DevTools -processes. - -As ever, many thanks to all those in the Chromium community who help make the -web more secure! - -## Q1 2017 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Here’s a recap from last quarter: - -Our [Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. In order to get bugs fixed faster, we released a [new -tool](https://github.com/google/clusterfuzz-tools) to improve developer -experience when trying to reproduce ClusterFuzz bugs. We have overhauled a -significant part of the [ClusterFuzz -UI](https://github.com/google/oss-fuzz/blob/master/docs/clusterfuzz.md) which -now feature a new fuzzer statistics page, crash statistics page and fuzzer -performance analyzer. We’ve also continued to improve our -[OSS-Fuzz](https://github.com/google/oss-fuzz) -[offering](https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html), -adding numerous -[features](https://github.com/google/oss-fuzz/issues?page=3&q=is%3Aissue+is%3Aclosed) -requested by developers and reaching [1000 -bugs](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=status%3AFixed%2CVerified+Type%3ABug%2CBug-Security+-component%3AInfra+) -milestone with 47 -[projects](https://github.com/google/oss-fuzz/tree/master/projects) in just five -months since launch. - -Members of the Chrome Security team attended the 10th annual [Pwn2Own -competition](http://blog.trendmicro.com/pwn2own-returns-for-2017-to-celebrate-10-years-of-exploits/) -at CanSecWest. While Chrome was again a target this year, no team was able to -demonstrate a fully working chain to Windows SYSTEM code execution in the time -allowed! - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. Chrome 56 takes advantage of [Control Flow Guard -(CFG)](https://msdn.microsoft.com/en-us/library/windows/desktop/mt637065(v=vs.85).aspx) -on Windows for Microsoft system DLLs inside the Chrome.exe processes. CFG makes -exploiting corruption vulnerabilities more challenging by limiting valid call -targets, and is available from Win 8.1 Update 3. - -[Site Isolation](/developers/design-documents/site-isolation) makes the most of -Chrome's multi-process architecture to help reduce the scope of attacks. The big -news in Q1 is that we launched --isolate-extensions to Chrome Stable in Chrome -56! This first use of out-of-process iframes (OOPIFs) ensures that web content -is never put into an extension process. To maintain the launch and prepare for -additional uses of OOPIFs, we fixed numerous bugs, cleaned up old code, reduced -OOPIF memory usage, and added OOPIF support for more features (e.g., -IntersectionObserver, and hit testing and IME on Android). Our next step is -expanding the OOPIF-based <webview> trial from Canary to Dev channel and -adding more uses of dedicated processes. - -Beyond the browser, our [web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. Over the -holidays, Google's security team gave us a holiday gift consisting entirely of -[interesting ways to bypass CSP's -nonces](http://sebastian-lekies.de/csp/bypasses.php). We've fixed some -[obvious](https://bugs.chromium.org/p/chromium/issues/detail?id=679291) -[bugs](https://bugs.chromium.org/p/chromium/issues/detail?id=680072) they -uncovered, and we'll continue working with other vendors to harden the spec and -our implementations. In other CSP news, we polished a mechanism to [enforce CSP -on child frames](https://w3c.github.io/webappsec-csp/embedded/), shipped a -[\`script-sample\` -property](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/XlcpobBfJOI/8WYpiyk0CQAJ) -in CSP reports, and [allowed hashes to match external -scripts](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/t2ai4lsHhWI/MndrZyEWCwAJ). -We're also gathering data to support a few [dangling markup -mitigations](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/rOs6YRyBEpw/D3pzVwGJAgAJ), -and dropped support for subresource URLs with [embedded -credentials](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/lx-U_JR2BF0/Hsg1fiZiBAAJ) -and [legacy -protocols](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/bIJdwwoQ98U/-F1aL2FgBAAJ). - -We also spend time building[ security -features](/developers/design-documents/safebrowsing) that[ users -see](/Home/chromium-security/enamel). To protect users from Data URI phishing -attacks, Chrome shows the “not secure” warning on Data URIs and [intends to -deprecate and -remove](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/GbVcuwg_QjM) -content-initiated top-frame navigations to Data URIs. We also brought [AIA -fetching](https://docs.google.com/document/d/1ryqFMSHHRDERg1jm3LeVt7VMfxtXXrI8p49gmtniNP0/edit) -to Chrome for Android, and early metrics show over an 85% reduction in the -fraction of HTTPS warnings caused by misconfigured certificate chains on -Android. We made additional progress on improving Chrome’s captive portal -detection. Chrome now keeps precise attribution of where bad downloads come -from, so we can catch malware and UwS earlier. Chrome 57 also saw the launch of -a [secure time service](/developers/design-documents/sane-time), for which early -data shows detection of bad client clocks when validating certificates improving -from 78% to 95%. - -We see migration to HTTPS as foundational to any web security whatsoever, so -we're actively working to drive #MOARTLS across Google and the Internet at -large. To help people understand the security limitations of non-secure HTTP, -Chrome now marks HTTP pages with passwords or credit card form fields as “not -secure” in the address bar, and is experimenting with in-form contextual -warnings. We’ll [remove -support](https://bugs.chromium.org/p/chromium/issues/detail?id=672605) for EME -over non-secure origins in Chrome 58, and we’ll [remove -support](https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/IVgkxkRNtMo) -for notifications over non-secure origins in Chrome 61. We talked about our -#MOARTLS methodology and the HTTPS business case at -[Enigma](https://www.youtube.com/watch?v=jplIY1GXBHM&feature=youtu.be). - -In addition to #MOARTLS, we want to ensure more secure TLS through work on -protocols and the certificate ecosystem. TLS 1.3 is the next, major version of -the Transport Layer Security protocol. In Q1, Chrome tried the first, -significant deployment of TLS 1.3 by a browser. Based on what we learned from -that we hope to fully enable TLS 1.3 in Chrome in Q2. - -In February, researchers from Google and CWI Amsterdam successfully mounted a -[collision](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html) -attack against the SHA-1 hash algorithm. It had been known to be weak for a very -long time, and in Chrome 56 dropped support for website certificates that used -SHA-1. This was the culmination of a plan first -[announced](https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html) -back in 2014, which we've -[updated](https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html) -a [few -times](https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html) -since. - -As ever, many thanks to all those in the Chromium community who help make the -web more secure! - -Cheers - -Andrew, on behalf of the Chrome Security Team - -For more thrilling security updates and feisty rants,[ subscribe to -security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev). -You can find older updates at[ -https://www.chromium.org/Home/chromium-security/quarterly-updates](/Home/chromium-security/quarterly-updates). - -## Q4 2016 - -Greetings and salutations, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Here’s a recap from the last quarter of -2016: - -Our [Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. - -We announced [OSS-Fuzz](https://github.com/google/oss-fuzz), a new Beta program -developed over the past years with the [Core Infrastructure -Initiative](https://www.coreinfrastructure.org/) community. This program will -provide continuous fuzzing for select core open source software. See full blog -post -[here](https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html). -So far, more than [50 -projects](https://github.com/google/oss-fuzz/tree/master/projects) have been -integrated with OSS-Fuzz and we found ~350 -[bugs](https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Type%3ABug%2CBug-Security%20-component%3AInfra%20-status%3ADuplicate%2CWontFix&colspec=ID%20Type%20Component%20Status%20Proj%20Reported%20Owner%20Summary&num=100&start=300). - -Security bugs submitted by external researchers can receive cash money from the -[Chrome VRP](https://g.co/ChromeBugRewards). - -Last year the Chrome VRP paid out almost one million dollars! More details in a -[blog -post](https://security.googleblog.com/2017/01/vulnerability-rewards-program-2016-year.html) -we did with our colleagues in the Google and Android VRPs. - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. - -[Win32k -lockdown](https://docs.google.com/document/d/1gJDlk-9xkh6_8M_awrczWCaUuyr0Zd2TKjNBCiPO_G4/edit#heading=h.ieb3qn2r8rq1) -for Pepper processes, including Adobe Flash and PDFium was shipped to Windows 10 -clients on all channels in October 2016. Soon after the mitigation was enabled, -a Flash 0-day that used win32k.sys as a [privilege -escalation](https://technet.microsoft.com/en-us/library/security/ms16-135.aspx) -vector was discovered being used in the wild, and this was successfully blocked -by this mitigation! James Forshaw from Project Zero also wrote a -[blog](https://googleprojectzero.blogspot.com/2016/11/breaking-chain.html) about -the process of shipping this new mitigation. - -A new security mitigation on >= Win8 hit stable in October 2016 (Chrome 54). -This mitigation disables extension points (legacy hooking), blocking a number of -third-party injection vectors. Enabled on all child processes - [CL -chain](https://chromium.googlesource.com/chromium/src/+/c06d6fb1850d6217d35a5cccb1abccd6db0e7a2a). -As usual, you can find the Chromium sandbox documentation -[here](/developers/design-documents/sandbox). - -[Site Isolation](/developers/design-documents/site-isolation) makes the most of -Chrome's multi-process architecture to help reduce the scope of attacks. - -Our earlier plan to launch --isolate-extensions in Chrome 54 hit a last minute -delay, and we're now aiming to turn it on in Chrome 56. In the meantime, we've -added support for drag and drop into [out-of-process -iframes](/developers/design-documents/oop-iframes) (OOPIFs) and for printing an -OOPIF. We've fixed several other security and functional issues for ---isolate-extensions as well. We've also started an A/B trial on Canary to use -OOPIFs for Chrome App <webview> tags, and we're close to starting an A/B -trial of --top-document-isolation. - -Beyond the browser, our[ web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. - -After a good deal of experimentation, we (finally) [tightened the behavior of -cookies' \`secure\` -attribute](https://www.chromestatus.com/feature/4506322921848832). [Referrer -Policy](https://www.w3.org/TR/referrer-policy/) moved to a candidate -recommendation, we made solid progress on -[Clear-Site-Data](https://w3c.github.io/webappsec-clear-site-data/), and we -expect to start an [origin -trial](https://github.com/jpchase/OriginTrials/blob/gh-pages/developer-guide.md) -for [Suborigins](https://w3c.github.io/webappsec-suborigins/) shortly. - -Looking to the future, we've started to flesh out our proposal for [stronger -origin isolation properties](https://wicg.github.io/isolation/), continued -discussions on a proposal for [setting origin-wide -policy](https://wicg.github.io/origin-policy/), and began working with the IETF -to expand [opt-in Certificate Transparency -enforcement](https://datatracker.ietf.org/doc/draft-stark-expect-ct/) to the -open web. We hope to further solidify all of these proposals in Q1. - -We also spend time building[ security -features](/developers/design-documents/safebrowsing) that[ users -see](/Home/chromium-security/enamel). - -Our security indicator text labels launched in Chrome 55 for “Secure” HTTPS, -“Not Secure” broken HTTPS, and “Dangerous” pages flagged by Safe Browsing. As -part of our long-term effort to mark HTTP pages as non-secure, we built -[address-bar warnings into Chrome -56](https://blog.chromium.org/2016/12/chrome-56-beta-not-secure-warning-web.html) -to mark HTTP pages with a password or credit card form fields as “Not secure”. - -We see migration to HTTPS as foundational to any web security whatsoever, so -we're actively working to drive #MOARTLS across Google and the Internet at -large. - -We added a new [HTTPS Usage -section](https://www.google.com/transparencyreport/https/metrics/?hl=en) to the -Transparency Report, which shows how the percentage of Chrome pages loaded over -HTTPS increases with time. We talked externally at O’Reilly Security NYC + -Amsterdam and [Chrome Dev Summit](https://www.youtube.com/watch?v=iP75a1Y9saY) -about upcoming HTTP UI changes and the business case for HTTPS. We published -[positive -stories](https://blog.chromium.org/2016/11/heres-to-more-https-on-web.html) -about HTTPS migrations. - -In addition to #MOARTLS, we want to ensure more secure TLS. - -We [concluded](https://www.imperialviolet.org/2016/11/28/cecpq1.html) our -experiment with post-quantum key agreement in TLS. We implemented TLS 1.3 draft -18, which will be enabled for a fraction of users with Chrome 56. - -And here are some other areas we're still investing heavily in: - -Keeping users safe from Unwanted Software (UwS, pronounced 'ooze') and improving -the [Chrome Cleanup Tool](https://www.google.com/chrome/cleanup-tool/), which -has helped millions remove UwS that was injecting ads, changing settings, and -otherwise blighting their machines. - -Working on usable, understandable permissions prompts. We're experimenting with -different prompt UIs, tracking prompt interaction rates, and continuing to learn -how best to ensure users are in control of powerful permissions. - -As ever, many thanks to all those in the Chromium community who help make the -web more secure! - -Cheers - -Andrew, on behalf of the Chrome Security Team - -For more thrilling security updates and feisty rants,[ subscribe to -security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev). -You can find older updates at[ -https://www.chromium.org/Home/chromium-security/quarterly-updates](/Home/chromium-security/quarterly-updates). - -## Q3 2016 - -Greetings and salutations! - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Here’s a recap from last quarter: - -Our[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. - -We have continued to improve upon our [libFuzzer](http://go/libfuzzer-chrome) -and -[AFL](https://cs.chromium.org/chromium/src/third_party/afl/?q=third_party/afl&sq=package:chromium&dr) -integration with ClusterFuzz, which includes automated performance analysis and -quarantining of bad units (like slow units, leaks, etc). We have scaled our code -coverage to -~[160](https://cs.chromium.org/search/?q=%22+int+LLVMFuzzerTestOneInput%22+-libFuzzer/src+-llvm/+-buildtools+-file:.md&sq=package:chromium&type=cs) -targets with help from Chrome developers, who contributed these during the -month-long -[Fuzzathon](https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/MAiBRTllPuI). -We have improved our infrastructure reliability and response times by adding a -24x7 monitoring solution, and fixing more than two dozen fuzzers in the process. -Finally, we have refined our crash bucketization algorithm and enabled automatic -bug filing remove human latency in filing regression bugs — long live the -machines! - -For [Site Isolation](/developers/design-documents/site-isolation), the first -uses of [out-of-process iframes](/developers/design-documents/oop-iframes) -(OOPIFs) have reached the Stable channel in Chrome 54! - -We're using OOPIFs for --isolate-extensions mode, which ensures that web content -is never put into a privileged extension process. In the past quarter, we made -significant progress and fixed all our blocking bugs, including enabling the new -session history logic by default, supporting cross-process POST submissions, and -IME in OOPIFs. We also fixed bugs in painting, input events, and many other -areas. As a result, --isolate-extensions mode has been enabled for 50% of M54 -Beta users and is turned on by default in M55. From here, we plan to further -improve OOPIFs to support --top-document-isolation mode, Chrome App -<webview> tags, and Site Isolation for real web sites. - -We also spend time building[ security -features](/developers/design-documents/safebrowsing) that[ users -see](/Home/chromium-security/enamel). - -We -[overhauled](https://docs.google.com/document/u/2/d/1jIfCjcsZUL6ouLgPOsMORGcTTXc7OTwkcBQCkZvDyGE/pub) -Chrome’s site security indicators in Chrome 52 on Mac and Chrome 53 on all other -platforms, including adding new icons for Safe Browsing. These icons were the -result of extensive user research which we shared in a [peer-reviewed -paper](https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-porter-felt.pdf). -Lastly, we made recovering blocked-downloads much [less -confusing](https://docs.google.com/document/d/1M9AvvXafVRSNquKGhzjAqo3Pl7sSATuEECA78pfkpmA/edit#). - -We like to avoid showing unnecessarily scary warnings when we can. We analyzed -data from opted-in Safe Browsing Extended Reporting users to quantify the major -causes of spurious TLS warnings, like [bad client -clocks](/developers/design-documents/sane-time) and [misconfigured intermediate -certificates](https://docs.google.com/document/d/1ryqFMSHHRDERg1jm3LeVt7VMfxtXXrI8p49gmtniNP0/edit?pli=1). -We also launched two experiments, -[Expect-CT](https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit) -and -[Expect-Staple](https://docs.google.com/document/d/1aISglJIIwglcOAhqNfK-2vtQl-_dWAapc-VLDh-9-BE/edit), -to help site owners deploy advanced new TLS features (Certificate Transparency -and OCSP stapling) without causing warnings for their users. - -Beyond the browser, our[ web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. - -We continued to lock down the security of the web platform while also expanding -capabilities to developers. We helped lock down cookies by starting to ship -[Strict Secure Cookies](https://www.chromestatus.com/feature/4506322921848832). -Similarly, we also shipped the [Referrer -Policy](https://www.w3.org/TR/referrer-policy/) spec and policy header. [Content -Security Policy](https://www.w3.org/TR/CSP3/) was expanded with the -[strict-dynamic](https://www.w3.org/TR/CSP3/#strict-dynamic-usage) and -[unsafe-hashed-attributes](https://www.w3.org/TR/CSP3/#unsafe-hashed-attributes-usage) -directives. Our work on -[suborigins](https://w3c.github.io/webappsec-suborigins/) continued, updating -the serialization and adding new web platform support. - -We've also been working on making users feel more in control of powerful -permissions. - -In M55 and M56 we will be running experiments on permissions prompts to evaluate -how this affects acceptance and decision rates. The experiments are to let users -make temporary decisions, to auto-deny prompts if users keep ignoring them, and -making permission prompts modal. - -We see migration to HTTPS as foundational to any web security whatsoever, so -we're actively working to drive #MOARTLS across Google and the Internet at -large. - -We -[announced](https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html) -concrete steps towards marking HTTP sites as non-secure in Chrome UI — starting -with marking HTTP pages with password or credit card form fields as “Not secure” -starting in Chrome 56 (Jan 2017). We [added YouTube and -Calendar](https://security.googleblog.com/2016/08/adding-youtube-and-calendar-to-https.html) -to the HTTPS Transparency Report. We’re also happy to report that -[www.google.com](http://www.google.com/) [uses -HSTS](https://security.googleblog.com/2016/07/bringing-hsts-to-wwwgooglecom.html)! - -In addition to #MOARTLS, we want to ensure more secure TLS. - -We continue to work on TLS 1.3, a major revision of TLS. For current revisions, -we’re also keeping the TLS ecosystem running smoothly with a little -[grease](https://tools.ietf.org/html/draft-davidben-tls-grease-01). We have -removed [DHE based -ciphers](https://www.chromestatus.com/feature/5128908798164992) and added -[RSA-PSS](https://www.chromestatus.com/features/5748550642171904). Finally, -having removed RC4 from Chrome earlier this year, we’ve now removed it from -BoringSSL’s TLS logic completely. - -We launched a very rough prototype of -[Roughtime](https://roughtime.googlesource.com/roughtime), a combination of NTP -and Certificate Transparency. In parallel we’re investigating what reduction in -Chrome certificate errors a secure clock like Roughtime could give us. - -We also continued our experiments with [post-quantum -cryptography](https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html) -by implementing [CECPQ1](https://www.chromestatus.com/features/5749214348836864) -to help gather some real world data. - -As ever, many thanks to all those in the Chromium community who help make the -web more secure! - -Cheers - -Andrew on behalf of the Chrome Security Team - -## Q2 2016 - -Greetings Earthlings, - -It's time for another update from your friends in Chrome Security, who are hard -at work trying to make Chrome the[ most secure platform to browse the -Internet](/Home/chromium-security). Here’s a recap from last quarter: - -**Our[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and -exterminate) security bugs.** At the start of the quarter, we initiated a -team-wide Security FixIt to trim the backlog of open issues… a bit of Spring -cleaning our issue tracker, if you will :) With the help of dozens of engineers -across Chrome, we fixed over 61 Medium+ severity security bugs in 2 weeks and -brought the count of open issues down to 22! On the fuzzing front, we’ve added -support for[ AFL](http://lcamtuf.coredump.cx/afl/) and continued to improve the[ -libFuzzer](http://llvm.org/docs/LibFuzzer.html)-[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz) -integration, both of which allow coverage-guided testing on a per-function -basis. The number of libFuzzer based fuzzers have expanded from 70 to[ -115](https://cs.chromium.org/search/?q=TestOneInput%5C(const+-file:third_party/llvm+-file:third_party/libFuzzer/src&sq=package:chromium&type=cs), -and we’re processing ~500 Billion testcases every day! We’re also researching -new ways to improve fuzzer efficiency and maximize code coverage -([example](https://chromium.googlesource.com/chromium/src/+/1a6bef1675e05626a4692ab6fa43cbbc5515299b)). -In response to recent trends from[ Vulnerability Reward Program -(VRP)](https://www.google.com/about/appsecurity/chrome-rewards/index.html) and[ -Pwnium](http://blog.chromium.org/2015/02/pwnium-v-never-ending-pwnium.html) -submissions, we wrote a new fuzzer for v8 builtins, which has already yielded[ -bugs](https://bugs.chromium.org/p/chromium/issues/detail?id=625752). Not -everything can be automated, so we started auditing parts of[ -mojo](/developers/design-documents/mojo), Chrome’s new IPC mechanism, and found -several issues -([1](https://bugs.chromium.org/p/chromium/issues/detail?id=611887),[ -2](https://bugs.chromium.org/p/chromium/issues/detail?id=612364),[ -3](https://bugs.chromium.org/p/chromium/issues/detail?id=612613),[ -4](https://bugs.chromium.org/p/chromium/issues/detail?id=613698),[ -5](https://bugs.chromium.org/p/chromium/issues/detail?id=622522)). - -**Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds -in multiple layers of defense.** Many Android apps use[ -WebView](https://developer.android.com/reference/android/webkit/WebView.html) to -display web content inline within their app. A compromised WebView can get -access to an app’s private user data and a number of Android system services / -device drivers. To mitigate this risk, in the upcoming release of[ Android -N](https://developer.android.com/preview/support.html#dp3), we’ve worked to -move[ -WebView](https://developer.android.com/reference/android/webkit/WebView.html) -rendering out-of-process into a sandboxed process. This new process model is -still experimental and can be enabled under Developer Options in Settings. On -Windows, a series of ongoing stability experiments with[ App -Container](/developers/design-documents/sandbox#TOC-App-Container-low-box-token-:) -and[ win32k -lockdown](/developers/design-documents/sandbox#TOC-Win32k.sys-lockdown:) for[ -PPAPI](/nativeclient/getting-started/getting-started-background-and-basics#TOC-Pepper-Plugin-API-PPAPI-) -processes (i.e. Flash and pdfium) have given us good data that puts us in a -position to launch both of these new security mitigations on Windows 10 very -soon! - -**For[ Site Isolation](/developers/design-documents/site-isolation), we're -getting close to enabling --isolate-extensions for everyone.** We've been hard -at work fixing launch blocking bugs, and[ out-of-process -iframes](/developers/design-documents/oop-iframes) (OOPIFs) now have support for -POST submissions, fullscreen, find-in-page, zoom, scrolling, Flash, modal -dialogs, and file choosers, among other features. We've also made lots of -progress on the new navigation codepath, IME, and the task manager, along with -fixing many layout tests and crashes. Finally, we're experimenting with ---top-document-isolation mode to keep the main page responsive despite slow -third party iframes, and with using OOPIFs to replace BrowserPlugin for the -<webview> tag. - -**We also spend time building[ security -features](/developers/design-documents/safebrowsing) that[ users -see](/Home/chromium-security/enamel).** We’re overhauling the omnibox security -iconography in Chrome -- new,[ -improved](https://www.usenix.org/conference/soups2016/technical-sessions/presentation/porter-felt) -connection security indicators are now in Chrome Beta (52) on Mac and Chrome Dev -(53) for all other platforms. We created a[ -reference](https://github.com/google/safebrowsing) interstitial warning that -developers can use for their implementations of the[ Safe Browsing -API](https://developers.google.com/safe-browsing/). Speaking of Safe Browsing, -we’ve extended protection to cover files downloaded by Flash apps, we’re -evaluating many more file types than before, and we closed several gaps that -were reported via our Safe Browsing[ Download Protection -VRP](https://www.google.com/about/appsecurity/chrome-rewards/) program. - -**Beyond the browser, our[ web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features.** We -shipped an implementation of the[ Credential Management -API](https://w3c.github.io/webappsec-credential-management/) (and[ presented a -detailed overview](https://youtu.be/MnvUlGFb3GQ?t=7m23s) at Google I/O), -iterated on[ Referrer Policy](https://www.w3.org/TR/referrer-policy/) with a[ -\`referrer-policy\` -header](https://www.w3.org/TR/referrer-policy/#referrer-policy-header) -implementation behind a flag, and improved our support for[ SameSite -cookies](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site). We're -continuing to experiment with[ -Suborigins](https://w3c.github.io/webappsec-suborigins/) with developers both -inside and outside Google, built a prototype of[ -CORS-RFC1918](https://mikewest.github.io/cors-rfc1918/), and introduce safety -nets to protect against XSS vulnerabilities due to browser bugs\[1\]. - -**We've also been working on making users feel more in control of powerful -permissions.** All permissions will soon be[ scoped to -origins](https://codereview.chromium.org/2075103002/), and we've started -implementing[ permission -delegation](https://noncombatant.github.io/permission-delegation-api/) (which is -becoming part of[ feature policy](https://github.com/igrigorik/feature-policy)). -We’re also actively working to show fewer permission prompts to users, and to -improve the prompts and UI we do show... subtle, critical work that make web -security more human-friendly (and thus, effective). - -**We see migration to HTTPS as foundational to any web security whatsoever, so -we're actively working to drive #MOARTLS across Google and the Internet at -large.**[ Emily](https://twitter.com/estark37) and[ -Emily](https://twitter.com/emschec) busted HTTPS myths for large audiences at[ -Google -I/O](https://www.youtube.com/watch?v=YMfW1bfyGSY&index=19&list=PLOU2XLYxmsILe6_eGvDN3GyiodoV3qNSC) -and the[ Progressive Web App dev -summit](https://www.youtube.com/watch?v=e6DUrH56g14). The[ HSTS Preload -list](https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json) -has seen[ 3x growth](https://twitter.com/lgarron/status/747530273047273472) -since the beginning of the year – a great problem to have! We’ve addressed some[ -growth -hurdles](https://docs.google.com/document/d/1LqpwT2aAekrWPtLui5GYdHSGlZNMNRYmPR14NXMRsQ4/edit#) -by a rewrite of the[ submission site](https://hstspreload.appspot.com/), and -we’re actively working on the preload list infrastructure and how to -additionally scale in the long term. - -**In addition to #MOARTLS, we want to ensure more secure TLS.** Some of us have -been involved in the[ TLS 1.3 standardization -work](https://tlswg.github.io/tls13-spec/) and[ -implementation](https://boringssl.googlesource.com/boringssl/). On the PKI -front, and as part of our[ Expect CT -project](https://docs.google.com/document/d/1VDtHiKa5c96ohP_p-V1k6u83fIh952e_szZVypO4AvQ/edit), -we built the infrastructure in Chrome that will help site owners track down -certificates for their sites that are not publicly logged in[ Certificate -Transparency](https://www.certificate-transparency.org/) logs. As of Chrome 53, -we’ll be requiring Certificate Transparency information for certificates issued -by Symantec-operated CAs, per[ our announcement last -year](https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html). -We also[ launched some post-quantum cipher suite -experiments](https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html) -to protect everyone from... crypto hackers of the future and more advanced -worlds ;) - -For more thrilling security updates and feisty rants, [subscribe to -security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev). -You can find older updates at -<https://www.chromium.org/Home/chromium-security/quarterly-updates>. - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -\[1\] Please[ let us know](/Home/chromium-security/reporting-security-bugs) if -you manage to work around them! - -## Q1 2016 - -Greetings web fans, - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. On the fuzzing front, we’ve continued to improve the integration -between [libFuzzer](http://llvm.org/docs/LibFuzzer.html) and -[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz), which allows -coverage-guided testing on a per-function basis. With the help of many -developers across several teams, we’ve expanded our collection of fuzzing -targets in Chromium (that use libFuzzer) to 70! Not all bugs can be found by -fuzzing, so we invest effort in targeted code audits too. We wrote a [guest post -on the Project Zero -blog](https://googleprojectzero.blogspot.com/2016/02/racing-midi-messages-in-chrome.html) -describing one of the more interesting vulnerabilities we discovered. Since we -find a lot of bugs, we also want to make them easier to manage. We’ve updated -our [Sheriffbot](/issue-tracking/autotriage) tool to simplify the addition of -new rules and expanded it to help manage functional bugs in addition just -security issues. We’ve also automated assigning [security -severity](/developers/severity-guidelines) recommendations. Finally, we continue -to run our [vulnerability reward -program](https://www.google.com/about/appsecurity/chrome-rewards/) to recognize -bugs discovered from researchers outside of the team. As of M50, [we’ve paid out -over $2.5 -million](https://chrome.googleblog.com/2016/04/chrome-50-releases-and-counting.html) -since the start of the reward program, including over $500,000 in 2015. Our -median payment amount for 2015 was $3,000 (up from $2,000 for 2014), and we want -to see that increase again this year! - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. On Android, our -[seccomp-bpf](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) -experiment has been running on the Dev channel and will advance to the Stable -and Beta channels with M50. - -Chrome on Windows is evolving rapidly in step with the operating system. We -shipped [four new layers of defense in -depth](https://bugs.chromium.org/p/chromium/issues/detail?id=504006) to take -advantage of the latest capabilities in Windows 10, some of which patch -vulnerabilities found by our own -[research](https://googleprojectzero.blogspot.co.uk/2015/05/in-console-able.html) -and -[feedback](https://bugs.chromium.org/p/project-zero/issues/detail?id=213&redir=1)! -There was great media attention when these changes landed, from [Ars -Technica](http://arstechnica.com/information-technology/2016/02/chrome-picks-up-bonus-security-features-on-windows-10/) -to a [Risky Business podcast](http://risky.biz/RB398), which said: “There have -been some engineering changes to Chrome on Windows 10 which look pretty good. … -It’s definitely the go-to browser, when it comes to not getting owned on the -internet. And it’s a great example of Google pushing the state of the art in -operating systems.” - -For our[ Site Isolation](/developers/design-documents/site-isolation) effort, we -have expanded our on-going launch trial of --isolate-extensions to include 50% -of both Dev Channel and Canary Channel users! This mode uses [out-of-process -iframes](/developers/design-documents/oop-iframes) (OOPIFs) to keep dangerous -web content out of extension processes. (See -[here](/developers/design-documents/oop-iframes#TOC-Dogfooding) for how to try -it.) We've fixed many launch blocking bugs, and improved support for navigation, -input events, hit testing, and security features like CSP and mixed content. We -improved our test coverage and made progress on updating features like -fullscreen, zoom, and find-in-page to work with OOPIFs. We're also excited to -see progress on other potential uses of OOPIFs, including the <webview> -tag and an experimental "top document isolation" mode. - -We spend time building[ security -features](/developers/design-documents/safebrowsing) that[ people -see](/Home/chromium-security/enamel). In response to user feedback, we’ve -replaced [the old full screen -prompt](https://bugs.chromium.org/p/chromium/issues/attachment?aid=178299&inline=1) -with a [new, lighter weight ephemeral -message](https://bugs.chromium.org/p/chromium/issues/attachment?aid=222712&inline=1) -in M50 across Windows and Linux. We launched a few bug fixes and updates to the -[Security -panel](https://developers.google.com/web/updates/2015/12/security-panel?hl=en), -which we continue to iterate on and support in an effort to drive forward HTTPS -adoption. We also continued our work on [removing powerful features on insecure -origins](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins) -(e.g. [geolocation](https://crbug.com/561641)). - -We’re working on preventing abuse of powerful features on the web. We continue -to support great “permissions request” UX, and have started reaching out to top -websites to directly help them improve how they request permissions for -[powerful -APIs](/Home/chromium-security/prefer-secure-origins-for-powerful-new-features). -To give top-level websites more control over how iframes use permissions, we -started external discussions about a new [Permission Delegation -API](http://noncombatant.github.io/permission-delegation-api/). We also -[extended](https://security.googleblog.com/2016/03/get-rich-or-hack-tryin.html) -our [vulnerability rewards -program](https://www.google.com/about/appsecurity/chrome-rewards/index.html#rewards) -to support [Safe -Browsing](https://www.google.com/transparencyreport/safebrowsing/) reports, in a -first program of its kind. - -Beyond the browser, our[ web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. We now -have an implementation of -[Suborigins](https://w3c.github.io/webappsec-suborigins/) behind a flag, and -have been experimenting with Google developers on usage. We polished up the -[Referrer Policy](https://www.w3.org/TR/referrer-policy/) spec, refined its -integration with [ServiceWorker](https://www.w3.org/TR/service-workers/) and -Fetch, and shipped the \`referrerpolicy\` attribute from that document. We're -excited about the potential of new CSP expressions like -['unsafe-dynamic'](https://w3c.github.io/webappsec-csp/#unsafe-dynamic-usage), -which will ship in Chrome 52 (and is experimentally deployed on [our shiny new -bug tracker](https://bugs.chromium.org/p/chromium/issues/list)). In that same -release, we finally shipped [SameSite -cookies](https://tools.ietf.org/html/draft-west-first-party-cookies), which we -hope will help prevent -[CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery). Lastly, we're -working to pay down some technical debt by refactoring our Mixed Content -implementation and X-Frame-Options to work in an OOPIF world. - -We see migration to HTTPS as foundational to any security whatsoever -([and](https://tools.ietf.org/html/rfc7258)[ -we're](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/)[ -not](https://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html)[ -the](https://w3ctag.github.io/web-https/)[ only](https://https.cio.gov/)[ -ones](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)), -so we're actively working to drive #MOARTLS across Google and the Internet at -large. We worked with a number of teams across Google to help [publish an HTTPS -Report -Card](https://security.googleblog.com/2016/03/securing-web-together_15.html), -which aims to hold Google and other top sites accountable, as well as encourage -others to encrypt the web. In addition to #MOARTLS, we want to ensure more -secure TLS. [We mentioned we were working on it last -time](https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ), -but RC4 support is dead! The [insecure TLS version fallback is also -gone](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/yz1lU9YTeys/yCsK50I3CQAJ). -With help from the [libFuzzer](http://llvm.org/docs/LibFuzzer.html) folks, we -got much better fuzzing coverage on -[BoringSSL](https://boringssl.googlesource.com/boringssl/), which resulted in -[CVE-2016-0705](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0705). -We ended up adding a "fuzzer mode" to the SSL stack to help the fuzzer get past -cryptographic invariants in the handshake, which smoked out some minor (memory -leak) bugs. - -Last, but not least, we rewrote a large chunk of BoringSSL's ASN.1 parsing with -a simpler and more standards-compliant stack. - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). You can find -older updates at -<https://www.chromium.org/Home/chromium-security/quarterly-updates>. - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -## Q4 2015 - -Happy 2016 from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the [most -secure platform to browse the Internet](/Home/chromium-security). Here’s a recap -of some work from last quarter: - -**The [Bugs--](/Home/chromium-security/bugs) effort aims to find (and -exterminate) security bugs.** We’ve integrated -[libFuzzer](http://llvm.org/docs/LibFuzzer.html) into -[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz), which means we -can do coverage-guided fuzz testing on a per-function basis. The result, as you -may have guessed, is several [new -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+label%3AStability-LibFuzzer&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles). -The Bugs-- team has a larger goal this year to help Chromium developers write a -ClusterFuzz fuzzer alongside every unittest, and libFuzzer integration is an -important step toward achieving that goal. Separately, we’ve made security -improvements and cleanups in the [Pdfium](https://code.google.com/p/pdfium/) -codebase and [fixed lots of open -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=status%3AFixed+type%3DBug-Security+owner%3Aochang+Cr%3DInternals-Plugins-PDF). -We also started some manual code auditing efforts, and discovered several high -severity bugs ([here](https://crbug.com/555784), -[here](https://crbug.com/559310), and [here](https://crbug.com/570427)), and -[1](https://crbug.com/564501) critical severity bug. - -**Bugs still happen, so our [Guts](/Home/chromium-security/guts) effort builds -in multiple layers of defense.** On Android, we’re running an experiment that -adds an additional -[seccomp-bpf](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) -sandbox to renderer processes, like we already do on Desktop Linux and Chrome -OS. On Windows 8 (and above), a Win32k lockdown experiment has been implemented -for PPAPI plugins including Flash and Pdfium to help reduce the kernel attack -surface for potential sandbox escapes. Also on Windows 8 (and above), an -AppContainer sandbox experiment has been introduced, which further reduces -kernel attack surface and blocks network communication from renderers. - -**Our [Site Isolation](/developers/design-documents/site-isolation) effort -reached a large milestone in December: running trials of the ---isolate-extensions mode on real Chrome Canary users!** This mode uses -[out-of-process iframes](/developers/design-documents/oop-iframes) to isolate -extension processes from web content for security. ([Give it a -try!](/developers/design-documents/oop-iframes#TOC-Dogfooding)) The trials were -made possible by many updates to session history, session restore, extensions, -painting, focus, save page, popup menus, and more, as well as numerous crash -fixes. We are continuing to fix the [remaining blocking -issues](https://csreis.github.io/oop-iframe-dependencies/), and we aim to launch -both --isolate-extensions and the broader Site Isolation feature in 2016. - -**We also spend time building [security -features](/developers/design-documents/safebrowsing) that [users -see](/Home/chromium-security/enamel).** The Safe Browsing team publicly -announced a [new social engineering -policy](https://googleonlinesecurity.blogspot.com/2015/11/safe-browsing-protection-from-even-more.html), -expanding Chrome’s protection against deceptive sites beyond phishing. One major -milestone is the [launch of Safe Browsing in Chrome for -Android](https://googleonlinesecurity.blogspot.com/2015/12/protecting-hundreds-of-millions-more.html), -protecting hundreds of millions of additional users from phishing, malware, and -other web threats! This is on by default and is already stopping millions of -attacks on mobile Chrome users. The next time you come across a Safe Browsing -warning, you can search for the blocked website in the -[new](https://googleonlinesecurity.blogspot.com/2015/10/behind-red-warning-more-info-about.html) -[Site Status -section](https://www.google.com/transparencyreport/safebrowsing/diagnostic/) of -the Transparency Report to learn why it’s been flagged by our systems. On the -other hand, we’re also trying to show users fewer security warnings in the first -place by decreasing our false positive rate for HTTPS warnings. We spent a large -part of the quarter analyzing client errors that contribute to false alarm HTTPS -errors; check out our [Real World Crypto -talk](https://docs.google.com/presentation/d/1Qmpl-5epx0B5C2t4XsUTyjgbwab_rXfK_4iHqX3IC30/edit?pref=2&pli=1#slide=id.gf44795496_0_1) -for more details. - -**Beyond the browser, our [web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features.** We've -made good progress [with folks in the -IETF](https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0165.html) to -make some meaningful changes to cookies; [cookie -prefixes](https://www.chromestatus.com/features/4952188392570880) and [locking -down 'secure' cookies](https://www.chromestatus.com/features/4506322921848832) -will be shipping shortly. [Subresource -Integrity](https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0020.html) -and [Mixed -Content](https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0021.html) -are trucking along the W3C Recommendation path, we've solidified our [Suborigins -proposal](https://w3c.github.io/webappsec-suborigins/), and have our eyes on -some new hotness like [HSTS Priming](https://mikewest.github.io/hsts-priming/), -[CSP3](https://w3c.github.io/webappsec-csp/) -[bits](https://w3c.github.io/webappsec-csp/embedded/) -[and](https://w3c.github.io/reporting/) -[pieces](https://w3c.github.io/webappsec-csp/cookies/), and [limiting access to -local network resources](https://mikewest.github.io/cors-rfc1918/). - -**We see migration to HTTPS as foundational to any security whatsoever -([and](https://tools.ietf.org/html/rfc7258) -[we're](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/) -[not](https://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html) -[the](https://w3ctag.github.io/web-https/) [only](https://https.cio.gov/) -[ones](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)), -so we're actively working to drive #MOARTLS across Google and the Internet at -large.** We've continued our effort to [deprecate powerful features on insecure -origins](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins) -by readying to block insecure usage of [geolocation -APIs](http://dev.w3.org/geo/api/spec-source.html). We also took to the -[stage](https://www.youtube.com/watch?v=9WuP4KcDBpI) at the [Chrome Dev -Summit](https://developer.chrome.com/devsummit) to spread the word, telling -developers about what we’re doing in Chrome to make deploying TLS easier and -more secure. - -In addition to more TLS, we want to ensure more secure TLS, which depends -heavily on the certificate ecosystem. Via [Certificate -Transparency](http://www.certificate-transparency.org/), we [detected a -fraudulent Symantec-issued certificate in -September](https://googleonlinesecurity.blogspot.com/2015/09/improved-digital-certificate-security.html), -which [subsequently revealed a pattern of additional misissued -certificates](https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html). -Independent of that incident, we took proactive measures to protect users from a -Symantec Root Certificate that was being decommissioned in a way that puts users -at risk (i.e. no longer complying with the CA/Browser Forum’s [Baseline -Requirements](https://cabforum.org/about-the-baseline-requirements/)). Other -efforts include working with -[Mozilla](https://groups.google.com/forum/#!topic/mozilla.dev.platform/JIEFcrGhqSM/discussion) -and -[Microsoft](https://blogs.windows.com/msedgedev/2015/09/01/ending-support-for-the-rc4-cipher-in-microsoft-edge-and-internet-explorer-11/) -to [phase out RC4 ciphersuite -support](https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/kVfCywocUO8/vgi_rQuhKgAJ), -and [continuing the deprecation of SHA-1 -certificates](https://googleonlinesecurity.blogspot.com/2015/12/an-update-on-sha-1-certificates-in.html), -which were shown to be [even weaker than previously -believed](https://sites.google.com/site/itstheshappening/). To make it easier -for developers and site operators to understand these changes, we debuted a new -[Security -Panel](https://developers.google.com/web/updates/2015/12/security-panel?hl=en) -that provides enhanced diagnostics and will continue to be improved with richer -diagnostics in the coming months. - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). You can find -older updates at -<https://www.chromium.org/Home/chromium-security/quarterly-updates>. - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -## Q3 2015 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the Internet](/Home/chromium-security). Here’s a recap -of some work from last quarter: - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. We’ve continued our collaboration with Android Security team and -now have a fully functional -[AddressSanitizer](http://clang.llvm.org/docs/AddressSanitizer.html) (ASAN) -build configuration of [AOSP](https://source.android.com/index.html) master -(public instructions -[here](http://source.android.com/devices/tech/debug/asan.html)). -[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz) is helping Android -Security team triage and verify bugs, including incoming [vulnerability -reward](https://www.google.com/about/appsecurity/android-rewards/) submissions, -and now supports custom APK uploads and the ability to launch commands. Back on -the Chrome front, we’re working on enabling [Control Flow Integrity (CFI) -checks](https://code.google.com/p/chromium/issues/detail?id=464797) on Linux, -which converts invalid vptr accesses into non-exploitable crashes; [8 -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=linux_cfi_chrome&colspec=ID+Pri+M+Stars+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -discovered so far! We’ve made [numerous -improvements](https://code.google.com/p/chromium/issues/detail?id=511270) to how -we fuzz Chrome on Android with respect to speed and accuracy. We also made some -progress toward our goal of expanding ClusterFuzz platform support to include -iOS. In our efforts to improve Chrome Stability, we added -[LeakSanitizer](http://clang.llvm.org/docs/LeakSanitizer.html) (LSAN) into our -list of supported memory tools, which has already found [38 -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=label%3AClusterFuzz+-status%3AWontFix%2CDuplicate+%22-leak%22+linux_lsan_chrome_mp&sort=id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles). - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. Plugin security remains a very important area of -work. With the final [death](https://g.co/npapi) of unsandboxed NPAPI plugins in -September, we’ve continued to introduce mitigations for the remaining sandboxed -PPAPI (Pepper) plugins. First, we implemented [support for Flash component -updates on Linux](https://codereview.chromium.org/1261333004/), a long-standing -feature request, which allows us to respond to [Flash -0-day](http://www.zdnet.com/article/adobe-releases-emergency-patch-for-flash-zero-day-flaw/) -incidents without waiting to qualify a new release of Chrome. We’ve also been -spending time improving the code quality and test coverage of -[Pdfium](https://code.google.com/p/pdfium/), the [now open-source version of the -Foxit PDF -reader](https://plus.sandbox.google.com/+FrancoisBeaufort/posts/9wwSiWDDKKP). In -addition, we have been having some success with enabling [Win32k syscall -filtering](/developers/design-documents/sandbox#TOC-Process-mitigation-policies-Win32k-lockdown-) -on Windows PPAPI processes (PDFium and Adobe Flash). This makes it even tougher -for attackers to get out of the Chromium Flash sandbox, and can be enabled on -Windows 8 and above on Canary channel right now by toggling the settings in -chrome://flags/#enable-ppapi-win32k-lockdown. - -We’ve been making steady progress on [Site -Isolation](/developers/design-documents/site-isolation), and are preparing to -enable out-of-process iframes (OOPIFs) for web pages inside extension processes. -You can test this mode before it launches with --isolate-extensions. We have -[performance -bots](https://chromeperf.appspot.com/report?sid=74ebe5d13c09e34915152f51ee178f77421b1703d2bf26a7a586375f2c5e2cc7) -and UMA stats lined up, and we'll start with some early trials on Canary and Dev -channel. Meanwhile, we've added support for hit testing in the browser process, -scrolling, context menus, and script calls between all reachable frames (even -with changes to window.opener). - -Not all security problems can be solved in[ Chrome’s -guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. To support developers -migrating to HTTPS, starting with M46, Chrome is marking the “[HTTPS with Minor -Errors](https://googleonlinesecurity.blogspot.com/2015/10/simplifying-page-security-icon-in-chrome.html)” -state using the same neutral page icon as HTTP pages (instead of showing the -yellow lock icon). We’ve started analyzing invalid (anonymized!) TLS certificate -reports gathered from the field, to understand the root causes of unnecessary -TLS/SSL warnings. One of the first causes we identified and fixed was -certificate hostname mismatches due to a missing ‘www’. We also launched -[HPKP](https://tools.ietf.org/html/rfc7469) violation reporting in Chrome, -helping developers detect misconfigurations and attacks by sending a report when -a pin is violated. Finally, in an effort to support the Chrome experience across -languages and locales, we made strides in improving how the omnibox is displayed -in [RTL languages](https://en.wikipedia.org/wiki/Right-to-left). - -Beyond the browser, our [web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. We -shipped [Subresource -Integrity](https://w3c.github.io/webappsec-subresource-integrity/) (SRI), which -defends against resource substitution attacks by allowing developers to specify -a hash against which a script or stylesheet is matched before it's executed. -We’re excited to see large sites, like -[Github](http://githubengineering.com/subresource-integrity/), already deploying -SRI! We've sketched out a concept for a [Clear Site -Data](http://w3c.github.io/webappsec-clear-site-data/) feature which we hope -will make it possible for sites to reset their storage, and we're hard at work -on the next iteration of [Content Security -Policy](https://w3c.github.io/webappsec-csp/). Both of these will hopefully -start seeing some implementation in Q4. - -We see migration to HTTPS as foundational to any security whatsoever -([and](https://tools.ietf.org/html/rfc7258) -[we're](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/) -[not](https://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html) -[the](https://w3ctag.github.io/web-https/) [only](https://https.cio.gov/) -[ones](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)), -so we're actively working to drive #MOARTLS across Google and the Internet at -large. We shipped [Upgrade Insecure -Requests](http://www.w3.org/TR/upgrade-insecure-requests/), which eases the -transition to HTTPS by transparently correcting a page's spelling from -\`http://\` to \`https://\` for all resources before any requests are triggered. -We've also continued our effort to [deprecate powerful features on insecure -origins](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins) -by solidifying the definition of a "[Secure -Context](https://w3c.github.io/webappsec-secure-contexts/)", and applying that -definition to block insecure usage of -[getUserMedia()](https://groups.google.com/a/chromium.org/d/msg/blink-dev/Dsoq5xPdzyw/21znuLWVCgAJ). - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -## Q2 2015 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the Internet](/Home/chromium-security). Here’s a recap -of some work from last quarter: - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. At the start of the quarter, we initiated a [Security -FixIt](https://docs.google.com/spreadsheets/d/1za0aWxDx4ga3dKBwrlS8COci6_VXLBaiVg3x5Y6rrFg/edit#gid=0) -to trim back the fat backlog of open issues. With the help of dozens of -engineers across Chrome, we fixed over 40 Medium+ severity security bugs in 2 -weeks and brought the count of issues down to 15! We also collaborated with -Android Security Attacks Team and added native platform fuzzing support to -[ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz) (and -[imported](https://cs.corp.google.com/#android/vendor/google_experimental/users/natashenka/&q=natashenka) -[their](https://cs.corp.google.com/#android/vendor/google/tools/security/ServiceProbe/src/com/google/wireless/android/security/serviceprobe/ServiceFuzzer.java&l=22) -[fuzzers](https://cs.corp.google.com/#android/vendor/google_experimental/users/jlarimer/lhf/README.TXT&l=1)), -which resulted in ~30 new bugs discovered. ClusterFuzz now supports fuzzing on -all devices of the Nexus family (5,6,7,9) and Android One and is running on a -few dozen devices in the Android Lab. On top of this, we have doubled our -fuzzing capacity in [Compute Engine](https://cloud.google.com/compute/) to ~8000 -cores by leveraging [Preemptible -VMs](http://googlecloudplatform.blogspot.com/2015/05/Introducing-Preemptible-VMs-a-new-class-of-compute-available-at-70-off-standard-pricing.html). -Lastly, we have upgraded all of our sanitizer builds on Linux (ASan, MSan, TSan -and UBSan) to report [edge-level -coverage](http://clang.llvm.org/docs/SanitizerCoverage.html) data, which is now -aggregated in the ClusterFuzz -[dashboard](https://cluster-fuzz.appspot.com/#coverage). We’re using this -coverage information to expand data bundles by existing fuzzers and improve our -corpus distillation. - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. Our [Site -Isolation](/developers/design-documents/site-isolation) project is getting -closer to its first stage of launch: using out-of-process iframes (OOPIFs) for -web pages inside extension processes. We've made substantial progress (with lots -of help from others on the Chrome team!) on core Chrome features when using ---site-per-process: OOPIFs now work with back/forward, DevTools, and extensions, -and they use [Surfaces](/developers/design-documents/chromium-graphics/surfaces) -for efficient painting (and soon input event hit-testing). We've collected some -preliminary performance data using [Telemetry](/developers/telemetry), we've -fixed lots of crashes, and we've started enforcing cross-site security -restrictions on cookies and passwords. Much work remains, but we're looking -forward to turning on these protections for real users! - -On Linux and Chrome OS, we’ve made changes to restrict [one PID namespace per -renderer process](https://crbug.com/460972), which strengthens and cleans-up our -sandbox (shipping in Chrome 45). We also finished up a [major cleanup necessary -toward deprecating the setuid sandbox](https://crbug.com/312380), which should -be happening soon. Work continued to prepare for the launch of Windows 10, which -offers some opportunities for new security -[mitigations](/developers/design-documents/sandbox#TOC-Process-mitigation-policies-Win32k-lockdown-); -the new version looks like the most secure Windows yet, so be sure to upgrade -when it comes out! - -Not all security problems can be solved in[ Chrome’s -guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. We’ve continued our efforts -to avoid showing unnecessary TLS/SSL warnings: decisions are now remembered for -a week instead of a session, and a [new checkbox on TLS/SSL warnings allows -users to send us invalid certificate chains -](https://www.google.com/chrome/browser/privacy/whitepaper.html#ssl)that help us -root out false-positive warnings. Since developers and power users have been -asking for more tools to debug TLS/SSL issues, we’ve started building more -security information into DevTools and plan to launch a first version in Q3! - -Another large focus for the team has been improving how users are asked for -permissions, like camera and geolocation. We’ve finalized a redesign of the -fullscreen permission flow that we hope to launch by the end of the year, fixed -a number of bugs relating to permission prompts, and launched another round of -updates to PageInfo and Website Settings on Android. - -Beyond the browser, our [web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. The -W3C's[ WebAppSec](http://www.w3.org/2011/webappsec/) working group continues to -be a fairly productive venue for a number of important features: we've polished -the [Subresource -Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) spec and -shipped an implementation in Chrome 46, published first drafts of [Credential -Management](https://w3c.github.io/webappsec/specs/credentialmanagement/) and -[Entry Point Regulation](https://w3c.github.io/webappsec/specs/epr/), continue -to push [Content Security Policy Level 2](http://www.w3.org/TR/CSP2/) and [Mixed -Content](http://www.w3.org/TR/mixed-content/) towards "Recommendation" status, -and fixed some [longstanding](https://crbug.com/483458) -[bugs](https://crbug.com/508310) with our [Referrer -Policy](http://www.w3.org/TR/referrer-policy/) implementation. - -Elsewhere, we've started prototyping [Per-Page -Suborigins](https://code.google.com/p/chromium/issues/detail?id=336894) with the -intent of bringing a concrete proposal to WebAppSec, published a new draft of -[First-Party-Only -cookies](https://tools.ietf.org/html/draft-west-first-party-cookies-03) (and are -working through some [infrastructure -improvements](https://docs.google.com/document/d/19NACt9PXOUTJi60klT2ZGcFlgHM5wM1Owtcw2GQOKPI/edit) -so we can ship them), and [poked at sandboxed -iframes](https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments) to -make it possible to sandbox ads. - -We see migration to HTTPS as foundational to any security whatsoever -([and](https://tools.ietf.org/html/rfc7258) -[we're](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/) -[not](https://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html) -[the](https://w3ctag.github.io/web-https/) [only](https://https.cio.gov/) -[ones](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)), -so we're actively working to drive #MOARTLS across Google and the Internet at -large. As a small practical step on top of the [HTTPS webmasters fundamentals -section](https://developers.google.com/web/fundamentals/discovery-and-distribution/security-with-https/?hl=en), -we’ve added some functionality to [Webmaster -Tools](https://www.google.com/webmasters/tools/home?hl=en&pli=1) to provide -better assistance to webmasters when dealing with common errors in managing a -site over TLS (launching soon!). Also, we're now measuring the usage of -[pre-existing, powerful features on non-secure -origins](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins), -and are now printing deprecation warnings in the JavaScript console. Our -ultimate goal is to make all powerful features, such as Geolocation and -getUserMedia, available only to secure origins. - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -## Q1 2015 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the Internet](/Home/chromium-security). Here’s a recap -of some work from last quarter: - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. Last quarter, we rewrote our IPC fuzzer, which resulted in -[lots](https://code.google.com/p/chromium/issues/list?can=1&q=linux_asan_chrome_ipc+type%3Dbug-security+-status%3AWontFix%2CDuplicate+&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -[more](https://code.google.com/p/chromium/issues/list?can=1&q=linux_asan_chrome_ipc_32bit+type%3Dbug-security+-status%3AWontFix%2CDuplicate&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -[bugs](https://code.google.com/p/chromium/issues/list?can=1&q=linux_msan_chrome_ipc+type%3Dbug-security+-status%3AWontFix%2CDuplicate&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -discovered by [ClusterFuzz](/Home/chromium-security/bugs/using-clusterfuzz)! We -also expanded fuzzing platform support (Android Lollipop, Linux with Nvidia -GPU), added [archived -builds](http://storage.cloud.google.com/chrome-test-builds/media) for -[proprietary media codecs](http://www.chromium.org/audio-video) testing on all -platforms, and used more code annotations to find bugs (like -[this](https://code.google.com/p/chromium/issues/detail?id=468519&can=1&q=%22Container-overflow%20in%20%22%20type%3Dbug-security%20-status%3AWontFix%2CDuplicate&sort=-id%20-security_severity%20-secseverity%20-owner%20-modified&colspec=ID%20Pri%20Status%20Summary%20Modified%20OS%20M%20Security_severity%20Security_impact%20Owner%20Reporter) -or -[this](https://code.google.com/p/chromium/issues/detail?id=468406&can=1&q=%22Container-overflow%20in%20%22%20type%3Dbug-security%20-status%3AWontFix%2CDuplicate&sort=-id%20-security_severity%20-secseverity%20-owner%20-modified&colspec=ID%20Pri%20Status%20Summary%20Modified%20OS%20M%20Security_severity%20Security_impact%20Owner%20Reporter)). -We auto-add previous crash tests to our data corpus, which helps to catch -regressions even if a developer forgets to add a test -([example](https://code.google.com/p/chromium/issues/detail?id=478745)). We’ve -also started experimenting with enabling and leveraging code coverage -information from fuzzing. Contrary to what [some reports may -imply](http://secunia.com/resources/vulnerability-review/browser-security/), [we -don’t think vulnerability counting is a good standalone metric for -security](http://lcamtuf.blogspot.com/2010/05/vulnerability-databases-and-pie-charts.html), -and more bugs discovered internally -([653](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+label%3AClusterFuzz+opened-after%3A2014%2F1%2F1+opened-before%3A2015%2F1%2F1+-status%3AWontFix%2CDuplicate&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs in 2014 vs. -[380](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+label%3AClusterFuzz+opened-after%3A2013%2F1%2F1+opened-before%3A2014%2F1%2F1+-status%3AWontFix%2CDuplicate&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs in 2013), means more bugs fixed, means safer software! Outside of -engineering, inferno@ gave a talk at [nullcon](http://nullcon.net/) about Chrome -fuzzing -([slides](http://nullcon.net/website/archives/ppt/goa-15/analyzing-chrome-crash-reports-at-scale-by-abhishek-arya.pdf)) -and we launched [never-ending -Pwnium](http://blog.chromium.org/2015/02/pwnium-v-never-ending-pwnium.html) with -a rewards pool up to $∞ million! - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. On Linux and Chrome OS, we did some work to improve -the seccomp-BPF compiler and infrastructure. On modern kernels, we [finally -completed the switch](https://crbug.com/312380) from the [setuid sandbox to a -new design using -](https://code.google.com/p/chromium/wiki/LinuxSandboxing#The_setuid_sandbox)[unprivileged -namespaces](https://code.google.com/p/chromium/wiki/LinuxSandboxing#User_namespaces_sandbox)[. -](https://code.google.com/p/chromium/wiki/LinuxSandboxing#The_setuid_sandbox)We’re -also working on a generic, re-usable sandbox API on Linux, which we hope can be -useful to other Linux projects that want to employ sandboxing. On Android, we’ve -been experimenting with single-threaded renderer execution, which can yield -performance and security benefits for Chrome. We’ve also been involved with the -ambitious [Mojo](/developers/design-documents/mojo) effort. On OSX, we [shipped -crashpad](https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/6eouc7q2j_g) -(which was a necessary project to investigate those sometimes-security-relevant -crashes!). Finally, on Windows, the support to block -[Win32k](/developers/design-documents/sandbox#TOC-Process-mitigation-policies-Win32k-lockdown-) -system calls from renderers on Windows 8 and above is now enabled on Stable - -and renderers on these systems are also running within [App -Containers](/developers/design-documents/sandbox#TOC-App-Container-low-box-token-) -on Chrome Beta, which blocks their access to the network. We also ensured all -Chrome allocations are safe - and use less memory (!) - by moving to the Windows -heap. - -On our [Site Isolation](/developers/design-documents/site-isolation) project, -we’ve made progress on the underlying architecture so that complex pages are -correct and stable (e.g. rendering any combination of iframes, evaluating -renderer-side security checks, sending postMessage between subframes, keeping -script references alive). Great progress has also been made on session history, -DevTools, and test/performance infrastructure, and other teams have started -updating their features for out-of-process iframes after our [Site Isolation -Summit](https://www.youtube.com/playlist?list=PL9ioqAuyl6UJmC0hyI-k1wYW08O71lBn8). - -Not all security problems can be solved in[ Chrome’s -guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. In an effort to determine -the causes of SSL errors, we’ve added a new checkbox on SSL warnings that allows -users to send us invalid certificate chains for analysis. We’ve started looking -at the data, and in the coming months we plan to introduce new warnings that -provide specific troubleshooting steps for common causes of spurious warnings. -We also recently launched the new permissions bubble UI, which solves some of -the problems we had with permissions infobars (like better coalescing of -multiple permission requests). And for our Android users, we recently revamped -PageInfo and Site Settings, making it easier than ever for people to manage -their permissions. Desktop updates to PageInfo and Site Settings are in -progress, too. Finally, we just launched a new extension, [Chrome User -Experience -Surveys](https://chrome.google.com/webstore/detail/chrome-user-experience-su/hgimloonaobbeeagepickockgdcghfnn?utm_source=newsletter&utm_medium=security&utm_campaign=CUES%20extension), -which asks people for in-the-moment feedback after they use certain Chrome -features. If you’re interested in helping improve Chrome, you should try it out! - -Beyond the browser, our [web platform efforts](/Home/chromium-security/owp) -foster cross-vendor cooperation on developer-facing security features. We're -working hard with the good folks in the W3C's -[WebAppSec](http://www.w3.org/2011/webappsec/) working group to make progress on -a number of specifications: [CSP 2](http://www.w3.org/TR/CSP2/) and [Mixed -Content](http://www.w3.org/TR/mixed-content/) have been published as Candidate -Recommendations, [Subresource Integrity](http://www.w3.org/TR/SRI/) is -implemented behind a flag and the spec is coming together nicely, and we've -fixed a number of [Referrer Policy](http://www.w3.org/TR/referrer-policy/) -issues. [First-Party-Only -Cookies](https://tools.ietf.org/html/draft-west-first-party-cookies) are just -about ready to go, and [Origin -Cookies](https://tools.ietf.org/html/draft-west-origin-cookies) are on deck. - -We see migration to HTTPS as foundational to any security whatsoever -([and](https://tools.ietf.org/html/rfc7258) -[we're](https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/) -[not](https://www.iab.net/iablog/2015/03/adopting-encryption-the-need-for-https.html) -[the](https://w3ctag.github.io/web-https/) [only](https://https.cio.gov/) -[ones](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/)), -so we're actively working to [define the properties of secure -contexts](https://w3c.github.io/webappsec/specs/powerfulfeatures/), [deprecate -powerful features on insecure -origins](/Home/chromium-security/deprecating-powerful-features-on-insecure-origins), -and to make it simpler for developers to [Upgrade Insecure -Requests](https://w3c.github.io/webappsec/specs/upgrade/) on existing sites. - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). - -Happy Hacking, - -Parisa, on behalf of Chrome Security - -P.S. Go here to travel back in time and view previous [Chrome security quarterly -updates](/Home/chromium-security/quarterly-updates). - -## Q4 2014 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the -Internet](http://www.chromium.org/Home/chromium-security). Here’s a recap of -some work from last quarter: - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. Last quarter, we incorporated more [coverage -data](https://code.google.com/p/address-sanitizer/wiki/AsanCoverage) into our -[ClusterFuzz dashboard](https://cluster-fuzz.appspot.com/#coverage), especially -for [Android](https://cluster-fuzz.appspot.com/coverage?platform=ANDROID). With -this, we hope to optimize our test cases and improve fuzzing efficiency. We also -incorporated 5 new fuzzers from the external research community as part of the -fuzzer reward program. This has resulted in -[33](https://code.google.com/p/chromium/issues/list?can=1&q=decoder_langfuzz+Type%3DBug-Security+-status%3ADuplicate&colspec=ID+Pri+M+Week+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -[new](https://code.google.com/p/chromium/issues/list?can=1&q=therealholden_worker+Type%3DBug-Security+-status%3ADuplicate&colspec=ID+Pri+M+Week+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -[security](https://code.google.com/p/chromium/issues/list?can=1&q=cdiehl_peach+Type%3DBug-Security+-status%3ADuplicate&colspec=ID+Pri+M+Week+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -vulnerabilities. Finally, we wrote a multi-threaded test case minimizer from -scratch based on [delta debugging](https://www.st.cs.uni-saarland.de/dd/) (a -long-standing request from blink devs!) which produces clean, small, -reproducible test cases. In reward program news, we've paid over $1.6 million -for externally reported Chrome bugs since 2010 ([$4 million total across -Google](http://googleonlinesecurity.blogspot.com/2015/01/security-reward-programs-year-in-review.html)). -In 2014, over 50% of reward program bugs were found and fixed before they hit -the stable channel, protecting our main user population. Oh, and in case you -didn’t notice, the [rewards we’re paying out for vulnerabilities went -up](http://googleonlinesecurity.blogspot.com/2014/09/fewer-bugs-mo-money.html) -again. - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. We’re most excited about progress toward a tighter -sandbox for Chrome on Android (via -[seccomp-bpf](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt)), -which required landing seccomp-bpf support in Android and [enabling TSYNC on all -Chrome OS](https://codereview.chromium.org/759343002/) and Nexus kernels. We’ve -continued to improve our Linux / Chrome OS sandboxing by (1) adding full -cross-process interaction restrictions at the BPF sandbox level, (2) making API -improvements and some code refactoring of //sandbox/linux, and (3) implementing -a more powerful policy system for the GPU sandbox. - -After ~2 years of work on [Site -Isolation](/developers/design-documents/site-isolation), we’re happy to announce -that [out-of-process iframes](/developers/design-documents/oop-iframes) are -working well enough that some Chrome features have [started updating to support -them](https://docs.google.com/document/d/1dCR2aEoBJj_Yqcs6GuM7lUPr0gag77L5OSgDa8bebsI/edit?usp=sharing)! -These include autofill (done), accessibility (nearly done), <webview> -(prototyping), devtools, and extensions. We know how complex a rollout this will -be, and we’re ready with testing infrastructure and -[FYI](http://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Linux) -[bots](http://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Win). -As we announced at our recent Site Isolation Summit -([video](https://www.youtube.com/playlist?list=PL9ioqAuyl6UJmC0hyI-k1wYW08O71lBn8), -[slides](https://docs.google.com/presentation/d/10HTTK4dsxO5p6FcpEOq8EkuV4yiBx2n6dBki8cqDWyo/edit?usp=sharing)), -our goal for Q1 is to finish up OOPIF support with the help of all of Chrome. - -Not all security problems can be solved in [Chrome’s -Guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. For the past few months, -we’ve been looking deeper into the causes of SSL errors by looking at UMA stats -and monitoring user help forums. One source of SSL errors is system clocks with -the wrong time, so we landed a more informative error message in Chrome 40 to -let users know they need to fix their clock. We’ve also started working on a -warning interstitial for [captive -portals](http://en.wikipedia.org/wiki/Captive_portal) to distinguish those SSL -errors from the rest. Finally, we [proposed a plan for browsers to migrate their -user interface from marking insecure origins (i.e. HTTP) as explicitly -insecure](/Home/chromium-security/marking-http-as-non-secure); the [initial -discussion](https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DHQLv76QaEM%5B1-25-false%5D) -and [external attention](http://www.bbc.com/news/technology-30505970) has been -generally positive. - -Over the past few years, we’ve worked on a bunch of isolated projects to push -security on the Open Web Platform forward and make it possible for developers to -write more secure apps. We recognized we can move faster if we get some of the -team fully dedicated to this work, so we formed a new group that will focus on -[web platform efforts](/Home/chromium-security/owp). - -As usual, for more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). - -To a safer web in 2015! - -Parisa, on behalf of Chrome Security - -## Q3 2014 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the -Internet](http://www.chromium.org/Home/chromium-security). Here’s a recap of -some work from last quarter: - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. We increased Clusterfuzz cores across all desktop platforms (Mac, -Android, Windows, and Linux), resulting in -[155](https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DBug-Security+label%3AClusterFuzz+opened-after%3A2014%2F7%2F1+opened-before%3A2014%2F9%2F31+-status%3AWontFix%2CDuplicate&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -security and -[275](https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DBug+label%3AClusterFuzz+opened-after%3A2014%2F7%2F1+opened-before%3A2014%2F9%2F31+-status%3AWontFix%2CDuplicate&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -functional bugs since last update! We also started fuzzing D-Bus system services -on Chrome OS, which is our first attempt at leveraging Clusterfuzz for the -operating system. One of the common security pitfalls in C++ is bad casting -(often rooted in aggressive polymorphism). To address, [one of our -interns](http://www.cc.gatech.edu/~blee303/) tweaked [UBSAN (Undefined Behavior -Sanitizer) -vptr](https://drive.google.com/file/d/0Bxvv8gduedamTEJCUlN6eERtWUE/view?usp=sharing) -to detect bad-casting at runtime, which resulted in [11 new security -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DBug-Security+linux_ubsan_vptr_chrome+-status%3ADuplicate%2CWontFix&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles&)! -We’ve continued to collaborate with external researchers on new fuzzing -techniques to find bugs in V8, Pdfium, Web Workers, IDB, and more. Shout out to -attekett, cloudfuzzer, decoder.oh, and therealholden for their attention and -bugs over the past quarter! - -Finding bugs is only half the battle, so we also did a few things to make it -easier to get security bugs ==fixed==, including (1) a new [security -sheriff](/Home/chromium-security/security-sheriff) -[dashboard](https://cluster-fuzz.appspot.com/#sheriff) and (2) contributing to -the [FindIt -project](https://chromium.googlesource.com/chromium/src.git/+/lkgr/tools/findit/), -which helps narrow down suspected CL(s) for a crash (given a regression range -and stacktrace), thereby saving manual triage cycles. - -Bugs still happen, so our[ Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. We did a number of things to push -[seccomp-bpf](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html) -onto more platforms and architectures, including: (1) adding support for -[MIPS](https://code.google.com/p/chromium/issues/detail?id=369594) and -[ARM64](https://code.google.com/p/chromium/issues/detail?id=355125), (2) adding -a [new capability](https://lkml.org/lkml/2014/7/17/844) to initialize -seccomp-bpf in the presence of threads (bringing us a big step closer to a -stronger sandbox on Android), (3) [general tightening of the -sandboxes](https://crbug.com/413855), and (4) writing a [domain-specific -language to better express BPF -policies](https://drive.google.com/file/d/0B9LSc_-kpOQPVHhvcVBza3NWR0k/view). We -also helped ensure a [safe launch of Android apps on Chrome -OS](http://chrome.blogspot.com/2014/09/first-set-of-android-apps-coming-to.html), -and continued sandboxing new system services. - -On Windows, we [launched Win64 to -Stable](http://blog.chromium.org/2014/08/64-bits-of-awesome-64-bit-windows_26.html), -giving users a safer, speedier, and more stable version of Chrome! On Windows 8, -we added Win32k system call filtering behind a -[switch](https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&sq=package:chromium&l=966), -further reducing the kernel attack surface accessible from the renderer. We also -locked down the [alternate -desktop](http://www.chromium.org/developers/design-documents/sandbox#TOC-The-alternate-desktop) -sandbox tokens and refactored the sandbox startup to cache tokens, which -improves new tab responsiveness. - -Finally, work continues on [site -isolation](http://www.chromium.org/developers/design-documents/site-isolation). -Over the past few months, we’ve started creating RemoteFrames in Blink's frame -tree to support out-of-process iframes (OOPIF) and got -[Linux](http://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Linux) -and -[Windows](http://build.chromium.org/p/chromium.fyi/builders/Site%20Isolation%20Win) -FYI bots running tests with --site-per-process. We’ve also been working with the -[Accessibility](https://groups.google.com/a/chromium.org/forum/#!forum/chromium-accessibility) -team as our guinea pig feature to support OOPIF, and since that work is nearly -done, we’re reaching out to more teams over the next few months to update their -features (see our [FAQ about updating -features](https://docs.google.com/a/chromium.org/document/d/1Iqe_CzFVA6hyxe7h2bUKusxsjB6frXfdAYLerM3JjPo/edit)). - -Not all security problems can be solved in[ Chrome’s -guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. SSL-related warnings are -still a major source of user pain and confusion. Over the past few months, we’ve -been focused on determining the causes of false positive SSL errors (via adding -UMA stats for known client / server errors) and investigating -[pinning](/Home/chromium-security/education/tls#TOC-Certificate-Pinning) -violation reports. We’ve also been [experimenting with cert memory -strategies](https://codereview.chromium.org/369703002/) and integrating relevant -detail when we detect a (likely) benign SSL error due to captive portal or a bad -clock. - -Developers are users too, so we know it’s important to support new web security -features and ensure new features are safe to use by default. In that vein, we -recently landed a first pass at [subresource -integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) -[support](https://codereview.chromium.org/566083003/) behind a flag (with -[useful console errors](https://codereview.chromium.org/596043003/)), we’re -[shipping](https://groups.google.com/a/chromium.org/d/msg/blink-dev/wToP6b04zVE/imuPatGy3awJ) -most of [CSP 2](https://w3c.github.io/webappsec/specs/content-security-policy/) -in M40, we’ve continued to [tighten -up](https://groups.google.com/a/chromium.org/d/msg/blink-dev/Uxzvrqb6IeU/9FAie9Py4cIJ) -handling of [mixed -content](https://w3c.github.io/webappsec/specs/mixedcontent/), and are working -to define and implement [referrer -policies](https://w3c.github.io/webappsec/specs/referrer-policy/). We’ve also -been helping on some security consulting for [Service -Worker](/blink/serviceworker); kudos to the team for making changes to [handle -plugins more -securely](https://code.google.com/p/chromium/issues/detail?id=413094), [restrict -usage to secure origins](http://crbug.com/394213), and for addressing some -memory caching issues. If you want to learn more about what’s going on in the -Blink Security world, check out the -[Blink-SecurityFeature](https://code.google.com/p/chromium/issues/list?q=label:Cr-Blink-SecurityFeature) -label. - -And then there’s other random things, like ad-hoc hunting for security bugs -(e.g. [local privilege escalation bug in -pppd](https://code.google.com/p/chromium/issues/detail?id=390709)), [giving -Chromebooks](http://www.washingtonpost.com/blogs/the-switch/wp/2014/08/18/finding-a-safe-space-for-kids-to-hack/) -to [kids at -DEFCON](https://www.flickr.com/photos/asirap/sets/72157645916802437), and -various artistic endeavors, like [color-by-risk -diagramming](https://docs.google.com/a/chromium.org/drawings/d/1TuECFL9K7J5q5UePJLC-YH3satvb1RrjLRH-tW_VKeE/edit) -and [security-inspired -fashion](https://www.flickr.com/photos/asirap/14798014040/). - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/security-dev). - -Happy Hacking (and Halloween), - -Parisa, on behalf of Chrome Security - -## Q2 2014 - -Hello from the Chromium Security Team! - -For those that don’t know us already, we do stuff to help make Chrome the[ most -secure platform to browse the -Internet](http://www.chromium.org/Home/chromium-security). Here’s a recap of -some work from last quarter: - -One of our primary responsibilities is security **adviser**, and the main way we -do this is via security reviews. A few weeks ago, jschuh@ announced [a new and -improved security review -process](http://www.chromium.org/Home/chromium-security/security-reviews) that -helps teams better assess their current security posture and helps our team -collect more meaningful data about Chrome engineering. All features for M37 went -through the new process, and we’ll be shepherding new projects and launches -through this process going forward. - -The[ Bugs--](/Home/chromium-security/bugs) effort aims to find (and exterminate) -security bugs. One of our best ways of finding bugs and getting them fixed -quickly is fuzz testing via [ClusterFuzz](https://cluster-fuzz.appspot.com/). -This quarter, we started fuzzing Chrome on Mac OS (extending the existing -platform coverage on Windows, Linux, and Android). We also added [code coverage -stats](https://cluster-fuzz.appspot.com/#coverage) to the ClusterFuzz UI, which -some teams have been finding helpful as a complement to their QA testing, as -well as [fuzzer stats](https://cluster-fuzz.appspot.com/#fuzzerstats), which [V8 -team now -checks](https://cluster-fuzz.appspot.com/fuzzerstats?fuzzer_name=stgao_chromebot2&job_type=linux_asan_chrome_v8&last_n_revisions=30) -in new rollouts. Finally, we added some new fuzzers (WebGL, GPU commands) and -integrated a number of memory debugging tools to find new classes of bugs (e.g. -[AddressSanitizer](https://code.google.com/p/address-sanitizer/) on Windows -found -[22](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+%22windows_asan_chrome%22&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs, [Dr. Memory](http://www.drmemory.org/) on Windows found -[1](https://code.google.com/p/chromium/issues/list?can=2&q=Stability%3DMemory-DrMemory+label%3Aclusterfuzz&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -bug, -[MemorySanitizer](https://code.google.com/p/memory-sanitizer/wiki/MemorySanitizer) -on Linux found -[146](https://code.google.com/p/chromium/issues/list?can=1&q=label%3AClusterFuzz+Stability%3DMemory-MemorySanitizer+&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs, and -[LeakSanitizer](https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer) -on Linux found -[18](https://code.google.com/p/chromium/issues/list?can=1&q=label%3AClusterFuzz+Stability%3DMemory-LeakSanitizer+&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs). - -Another source of security bugs is our [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program), which saw a -quiet quarter: only 32 reports opened in Q2 (lowest participation in 12 months) -and an average payout of $765 per bug (lowest value in 12 months). This trend is -likely due to (1) fuzzers, both internal and external, finding over 50% of all -reported bugs in Q2, (2) a reflection of both the increasing difficulty of -finding bugs and outdated reward amounts being less competitive, and (3) -researcher fatigue / lack of interest or stimulus. Plans for Q3 include -reinvigorating participation in the rewards program through a more generous -reward structure and coming up with clever ways to keep researchers engaged. - -Outside of external bug reports, we spent quite a bit of time [improving the -security posture of Pdfium](/Home/chromium-security/pdfium-security) (Chrome's -[recently opensourced](http://blog.foxitsoftware.com/?p=641) PDF renderer) via -finding / fixing -~[150](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+Cr%3DInternals-Plugins-PDF+closed-after%3A2014%2F4%2F1+closed-before%3A2014%2F7%2F31&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -bugs, removing risky code (e.g. [custom -allocator](https://pdfium.googlesource.com/pdfium/+/3522876d5291922ddc62bf1b70d02743b0850673)), -and using [secure integer -library](https://code.google.com/p/chromium/codesearch#chromium/src/base/numerics/&ct=rc&cd=1&q=numerics&sq=package:chromium) -for overflow checks. Thanks to ifratric@, mjurczyk@, and gynvael@ for their PDF -fuzzing help! - -Bugs still happen, so our [Guts](/Home/chromium-security/guts) effort builds in -multiple layers of defense. We did lots of sandboxing work across platforms last -quarter. On Mac OS, rsesek@ started working on a brand new [bootstrap sandbox -for -OSX](https://docs.google.com/a/chromium.org/document/d/108sr6gBxqdrnzVPsb_4_JbDyW1V4-DRQUC4R8YvM40M/edit) -(//sandbox/mac) and on Android, he got a proof-of-concept renderer running under -[seccomp-bpf](http://lwn.net/Articles/475043/). On Linux and Chrome OS, we -continued to improve the sandboxing testing framework and wrote dozens of new -tests; all our security tests are now running on the Chrome OS BVT. We also -refactored all of NaCl-related “outer” sandboxing to support a new and faster -Non-SFI mode for [NaCl](https://developer.chrome.com/native-client). This is -being used to run Android apps on Chrome, as you may have seen [demoed at Google -I/O](https://www.google.com/events/io). - -After many months of hard work, we’re ecstatic to announce that we [released -Win64 on dev and -canary](http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html) -to our Windows 7 and Windows 8 users. This release takes advantage of [High -Entropy -ASLR](http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx) -on Windows 8, and the extra bits help improve the effectiveness of heap -partitioning and mitigate common exploitation techniques (e.g. JIT spraying). -The Win64 release also reduced ~⅓ of the crashes we were seeing on Windows, so -it’s more stable too! - -Finally, work continues on [site -isolation](http://www.chromium.org/developers/design-documents/site-isolation): -lots of code written / rewritten / rearchitected and unknown unknowns discovered -along the way. We're close to having "remote" frames for each out-of-process -iframe, and you can now see subframe processes in Chrome's Task Manager when -visiting a test page like -[this](http://csreis.github.io/tests/cross-site-iframe.html) with the ---site-per-process flag. - -Not all security problems can be solved in[ Chrome’s -guts](/Home/chromium-security/guts), so[ we work on making security more -user-friendly](/Home/chromium-security/enamel) too. The themes of Q2 were SSL -and permissions. For SSL, we nailed down a new ["Prefer Safe Origins for -Powerful Features" -policy](/Home/chromium-security/prefer-secure-origins-for-powerful-new-features), -which we’ll transition to going forward; kudos to palmer@ and sleevi@ for -ironing out all the details and getting us to a safer default state. We’ve also -been trying to improve the experience of our SSL interstitial, which most people -ignore :-/ Work includes launching new UX for [SSL -warnings](https://test-sspev.verisign.com/) and incorporating captive portal -status (ongoing). Congrats to agl@ for launching -[boringssl](https://www.imperialviolet.org/2014/06/20/boringssl.html) - if -boring means avoiding Heartbleed-style hysteria, sounds good to us! - -On the permissions front, we’re working on ways to give users more control over -application privileges, such as (1) reducing the number of install-time CRX -permissions, (2) running UX experiments on the effectiveness of permissions, and -(3) working on building a security and permissions model to bring native -capabilities to the web. - -For more thrilling security updates and feisty rants, subscribe to -[security-dev@chromium.org](mailto:security-dev@chromium.org). - -In the meantime, happy hacking! - -Parisa, on behalf of Chrome Security - -P.S. A big kudos to the V8 team, and jkummerow@ in particular, for their extra -security efforts this quarter! The team rapidly responded to and fixed a number -of security bugs on top of doing some security-inspired hardening of V8 runtime -functions. - -## Q1 2014 - -Hello from the Chrome Security Team! - -For those that don’t know us already, we help make Chrome the [most secure -platform to browse the -Internet](http://www.chromium.org/Home/chromium-security). In addition to -security reviews and consulting, running a [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program), and dealing -with security surprises, we instigate and work on engineering projects that make -Chrome safer. Here’s a recap of some work from last quarter: - -The [Bugs-- ](/Home/chromium-security/bugs)effort aims to find (and exterminate) -exploitable bugs. A major accomplishment from Q1 was getting -[ClusterFuzz](https://cluster-fuzz.appspot.com/) coverage for Chrome on Android; -we’re aiming to scale up resources from [a few devices on inferno@’s -desk](https://plus.sandbox.google.com/u/0/103970240746069356722/posts/LckbsWq6QFZ) -to 100 bots over the next few months. On the fuzzer front, mbarbella@ wrote a -new V8 fuzzer that helped shake out -[30+](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Dbug-security+-status%3Aduplicate+mbarbella_js_mutation&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles) -[bugs](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Dbug-security+-status%3Aduplicate+mbarbella_js_mutation_test&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&x=m&y=releaseblock&cells=tiles); -kudos to the V8 team for being so proactive at fixing these issues and -prioritizing additional proactive security work this quarter. Spring welcomed a -hot new line of PoC exploits at [Pwn2Own](http://www.pwn2own.com/) and [Pwnium -4](http://blog.chromium.org/2014/01/show-off-your-security-skills.html): -highlights included a classic ensemble of overly broad IPC paired with a Windows -“feature,” and a bold chain of 5 intricate bugs for persistent system compromise -on Chrome OS; more details posted soon [here](/Home/chromium-security/bugs). -Beyond exploit contests, we’ve rewarded $52,000 for reports received this year -(from 16 researchers for 23 security bugs) via our ongoing [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program). We also started -rewarding researchers for bugs in [Chrome extensions developed "by -Google.”](http://googleonlinesecurity.blogspot.com/2014/02/security-reward-programs-update.html) -Outside of finding and fixing bugs, jschuh@ landed [a safe numeric -class](https://code.google.com/p/chromium/issues/detail?id=332611) to help -prevent arithmetic overflow bugs from being introduced in the first place; use -it and you'll [sleep better](https://xkcd.com/571/) too! - -Bugs still happen, so we build in multiple layers of defense. One of our most -common techniques is [sandboxing](/Home/chromium-security/guts), which helps to -reduce the impact of any single bug. Simple in theory, but challenging to -implement, maintain, and improve across all platforms. On Linux and Chrome OS, -we spent a lot of the quarter paying back technical debt: cleaning up the GPU -sandbox, writing and fixing tests, and replacing the setuid sandbox. On Android, -we reached consensus with the Android Frameworks team on a path forward for -seccomp-bpf sandboxing for Clank. We've started writing the CTS tests to verify -this in Android, landed the baseline policy in upstream Clankium, and are -working on the required [upstream Linux Kernel -changes](https://lkml.org/lkml/2014/1/13/795) to be incorporated into Chrome -Linux, Chrome OS, and Android L. The [site isolation -project](http://www.chromium.org/developers/design-documents/site-isolation) -(i.e. sandboxing at the site level) landed a usable cross-process iframe -implementation behind --site-per-process, which supports user interaction, -nested iframes (one per doc), sad frame, and basic DevTools support. Major -refactoring of Chrome and Blink, performance testing, and working with teams -that need to update for site isolation continues this quarter. On Windows, we -shipped Win64 canaries, landed code to sandbox the auto update mechanism, and -improved the existing sandboxing, reducing the win32k attack surface by ~30%. -Thanks to the Windows Aura team, we’ve also made tremendous progress on -disabling win32k entirely in the Chrome sandbox, which will eventually eliminate -most Windows-specific sandbox escapes. - -Not all security can be solved in [Chromium’s -Guts](/Home/chromium-security/guts), so [we work on making security more -user-friendly](/Home/chromium-security/enamel) too. We finally landed the -controversial change to [remember passwords, even when -autocomplete='off'](https://code.google.com/p/chromium/issues/detail?id=177288) -in -[M34](http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html), -which is a small, but [significant change to return control back to the -user](/Home/chromium-security/security-faq). We also made some [tweaks to the -malware download UX in -M32](https://docs.google.com/a/google.com/presentation/d/16ygiQS0_5b9A4NwHxpcd6sW3b_Up81_qXU-XY86JHc4/edit#slide=12); -previously users installed ~29% of downloads that were known malware, and that -number is now down to <5%! We’ve recently been thinking a lot about how to -improve the security of Chrome Extensions and Apps, including experimenting with -several changes to the permission dialog to see if we can reduce the amount of -malicious crx installed by users without reducing the amount of non-malicious -items. Separately, we want to make it easier for developers to write secure -APIs, so meacer@ wrote up some [security -tips](https://docs.google.com/document/d/1RamP4-HJ7GAJY3yv2ju2cK50K9GhOsydJN6KIO81das/pub) -to help developers avoid common abuse patterns we’ve identified from bad actors. - -Finally, since [Heartbleed](http://heartbleed.com/) is still on the forefront of -many minds, a reminder that Chrome and Chrome OS [were not directly -affected](http://googleonlinesecurity.blogspot.com/2014/04/google-services-updated-to-address.html). -And if you're curious about how and why Chrome does SSL cert revocation the way -it does, agl@ wrote a great -[post](https://www.imperialviolet.org/2014/04/19/revchecking.html) explaining -that too. - -For more thrilling security updates and feisty rants, subscribe to[ -security-dev@chromium.org](mailto:security-dev@chromium.org). - -Happy Hacking, -Parisa, on behalf of Chrome Security - -## Q4 2013 - -Hello from the Chrome Security Team! -For those that don’t know us already, we help make Chromium the [most secure -browsing platform in the -market](http://www.chromium.org/Home/chromium-security). In addition to security -reviews and consulting, running a [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program), and dealing -with security surprises, we instigate and work on engineering projects that make -Chrome more secure. -The end of last year flew by, but here are a couple of things we’re most proud -of from the last quarter of 2013: -Make security more usable: We made a number of changes to the malware download -warning to discourage users from installing malware. We also worked on a -reporting feature that lets users upload suspicious files to [Safe -Browsing](http://www.google.com/transparencyreport/safebrowsing/), which will -help Safe Browsing catch malicious downloads even faster. -Since PDFs are a common vehicle for exploit delivery, we’ve modified PDF -handling in Chrome so that they're all opened in Chrome’s PDF viewer by default. -This is a huge security win because we believe Chrome’s PDF viewer is the -safest, most hardened, and security-tested viewer available. [Malware via -Microsoft .docs are also -common](https://www.eff.org/deeplinks/2014/01/vietnamese-malware-gets-personal), -so we’re eagerly awaiting the day we can open Office Docs in -[Quickoffice](https://support.google.com/quickoffice/answer/2986862?hl=en) by -default. -Find (and fix) more security bugs: We recently welcomed a new member to the -team, -[Sheriffbot](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+commentby%3Aclusterfuzz%40chromium.org+-reporter%3Aclusterfuzz%40chromium.org&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner+Reporter&cells=tiles). -He’s already started making the [mortal security -sheriffs’](/Home/chromium-security/security-sheriff) lives easier by finding new -owners, adding Cr- area labels, helping apply and fix bug labels, and reminding -people about open security bugs they have assigned to them. -Our fuzzing mammoth, [ClusterFuzz](https://cluster-fuzz.appspot.com/), is now -fully supported on Windows and has helped find -[32](https://code.google.com/p/chromium/issues/list?can=1&q=type:bug-security%20label:Hotlist-SyzyASAN%20label:ClusterFuzz&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID%20Pri%20Status%20Summary%20Modified%20OS%20M%20Security_severity%20Security_impact%20Owner%20Reporter) -new bugs. We’ve added a bunch of new fuzzers to cover Chromium IPC (5 high -severity bugs), networking protocols (1 critical severity bug from a certificate -fuzzer, 1 medium severity bug from an HTTP protocol fuzzer), and WebGL (1 high -severity bug in Angle). Want to write a -[fuzzer](http://en.wikipedia.org/wiki/Fuzz_testing) to add security fuzzing -coverage to your code? Check out the [ClusterFuzz -documentation](/Home/chromium-security/bugs/using-clusterfuzz), or get in touch. -In November, we helped sponsor a [Pwn2Own contest at the PacSec conference in -Tokyo](http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Mobile-Pwn2Own-2013/ba-p/6202185#.Ut6t45DTm91). -Our good friend, Pinkie Pie, exploited an integer overflow in V8 to get reliable -code execution in the renderer, and then exploited a bug in a Clipboard IPC -message to get code execution in the browser process (by spraying multiple -gigabytes of shared memory). We’ll be publishing a full write-up of the exploit -[on our site](/Home/chromium-security/bugs) soon, and are starting to get -excited about our [upcoming -Pwnium](http://blog.chromium.org/2014/01/show-off-your-security-skills.html) in -March. -Secure by default, defense in depth: In [Chrome -32](http://googlechromereleases.blogspot.com/2014/01/stable-channel-update.html), -we started [blocking NPAPI by -default](http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html) -and have plans to completely remove support by the end of the year. This change -significantly reduces Chrome’s exposure to browser plugin vulnerabilities. We -also implemented additional [heap partitioning for buffers and -strings](https://code.google.com/p/chromium/issues/detail?id=270531) in Blink, -which further mitigates memory exploitation techniques. Our Win64 port of -Chromium is now continuously tested on the main waterfall and is on track to -ship this quarter. Lastly, we migrated our Linux and Chrome OS sandbox to a new -policy format and did a lot of overdue sandbox code cleanup. -On our [site isolation](/developers/design-documents/site-isolation) project, -we’ve started landing infrastructure code on trunk to support out-of-process -iframes. We are few CLs away from having functional cross-process iframe behind -a flag and expect it to be complete by the end of January! -Mobile, mobile, mobile: We’ve started focusing more attention to hardening -Chrome on Android. In particular, we’ve been hacking on approaches for strong -sandboxing (e.g. -[seccomp-bpf](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html)), -adding [Safe Browsing](http://www.google.com/transparencyreport/safebrowsing/) -protection, and getting [ClusterFuzz](https://cluster-fuzz.appspot.com/) tuned -for Android. -For more thrilling security updates and feisty rants, catch ya on -[security-dev@chromium.org](mailto:security-dev@chromium.org). -Happy Hacking, -Parisa, on behalf of Chrome Security - -## Q3 2013 - -An early -[boo](http://mountainbikerak.blogspot.com/2010/11/google-chrome-pumpkin.html) -and (late) quarter update from the Chrome Security Team! - -For those that don’t know us already, we help make Chromium the [most secure -browsing platform in the -market](http://www.chromium.org/Home/chromium-security). In addition to security -reviews and consulting, running a [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program), and dealing -with security surprises, we instigate and work on engineering projects that make -Chrome more secure. - -Last quarter, we reorganized the larger team into 3 subgroups: - -**Bugs--**, a group focused on finding security bugs, responding to them, and -helping get them fixed. The group is currently working on expanding -[Clusterfuzz](https://cluster-fuzz.appspot.com/) coverage to other platforms -(Windows and Mac), adding fuzzers to cover IPC, networking, and WebGL, adding -more [security -ASSERTS](http://svnsearch.org/svnsearch/repos/BLINK/search?logMessage=ASSERT_WITH_SECURITY_IMPLICATION) -to catch memory corruption bugs. They're also automating some of the grungy and -manual parts of being [security -sheriff](/Home/chromium-security/security-sheriff) to free up human cycles for -more exciting things. - -Enamel, a group focused on usability problems that affect end user security or -the development of secure web applications. In the near-term, Enamel is working -on: improving the malware download warnings, SSL warnings, and extension -permission dialogs; making it safer to open PDFs and .docs in Chrome; and -investigating ways to combat popular phishing attacks. - -Guts, a group focused on ensuring Chrome’s architecture is secure by design and -resilient to exploitation. Our largest project here is [site -isolation](/developers/design-documents/site-isolation), and in Q4, we’re aiming -to have a usable cross-process iframe implementation (behind a flag ;) Other -Guts top priorities include sandboxing work (stronger sandboxing on Android, -making Chrome OS’s -[seccomp-bpf](https://code.google.com/p/chromium/wiki/LinuxSandboxing#The_seccomp-bpf_sandbox) -easier to maintain and better tested), supporting [NPAPI -deprecation](http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html), -launching 64bit Chrome for Windows, and Blink memory hardening (e.g. heap -partitioning). - -Retrospectively, here are some of notable security wins from recent Chrome -releases: - -In [Chrome -29](http://googlechromereleases.blogspot.com/2013/08/stable-channel-update.html), -we tightened up the sandboxing policies on Linux and added some defenses to the -Omaha (Chrome Update) plugin, which is a particularly exposed and attractive -target in Chrome. The first parts of Blink heap partition were released, and -we’ve had “backchannel” feedback that we made an impact on the greyhat exploit -market. - -In [Chrome -30](http://googlechromereleases.blogspot.com/2013/10/stable-channel-update.html) -we fixed a load of security bugs! The spike in bugs was likely due to a few -factors: (1) we started accepting fuzzers (7 total) from invited external -researchers as part of a Beta extension to our vulnerability reward program -(resulting in -[26](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+label%3AExternal-Fuzzer-Contribution+-status%3AWontFix%2CDuplicate&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Stars+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner&x=m&y=releaseblock&cells=tiles) -new bugs), (2) we [increased reward -payouts](http://googleonlinesecurity.blogspot.com/2013/08/security-rewards-at-google-two.html) -to spark renewed interest from the public, and (3) we found a bunch of new -buffer (over|under)flow and casting bugs ourselves by adding -[ASSERT_WITH_SECURITY_IMPLICATION](http://svnsearch.org/svnsearch/repos/BLINK/search?logMessage=ASSERT_WITH_SECURITY_IMPLICATION)s -in Blink. In M30, we also added [a new layer of -sandboxing](https://code.google.com/p/chromium/issues/detail?id=168812) to NaCl -on Chrome OS, with seccomp-bpf. - -Last, but not least, we want to give a shout out to individuals outside the -security team that made an extraordinary effort to improve Chrome security: - -* Jochen Eisinger for redoing the pop-up blocker... so that it - [actually blocks - pop-ups](https://code.google.com/p/chromium/issues/detail?id=38458) - (instead of hiding them). Beyond frustrating users, this bug was a - security liability, but due to the complexity of the fix, languished - in the issue tracker for years. -* Mike West for his work on CSP, as well as tightening downloading of - bad content types. -* Avi Drissman for fixing a [longstanding bug where PDF password input - was not - masked](http://code.google.com/p/chromium/issues/detail?id=54748#c49). -* Ben Hawkes and Ivan Fratic for finding - [four](https://code.google.com/p/chromium/issues/list?can=1&q=label%3AWinFuzz) - potentially exploitable Chrome bugs using WinFuzz. -* Mateusz Jurczyk on finding ton of bugs in VP9 video decoder. - -Happy Hacking, -Parisa, on behalf of Chrome Security - -## Q2 2013 - -Hello from the Chrome Security Team! - -For those that don’t know us, we’re here to help make Chrome a very (the most!) -[secure browser](http://www.chromium.org/Home/chromium-security). That boils -down to a fair amount of work on security reviews (and other consulting), but -here’s some insight into some of the other things we were up to last quarter: - -Bug Fixin’ and Code Reviews - -At the start of the quarter, we initiated a Code 28 on security bugs to trim -back the fat backlog of open issues. With the help of dozens of engineers across -Chrome, we fixed over 100 security bugs in just over 4 weeks and brought the -count of Medium+ severity issues to single digits. (We’ve lapsed a bit in the -past week, but hopefully will recover once everyone returns from July vacation -:) - -As of July 1st, [Clusterfuzz](http://goto/clusterfuzz) has helped us find and -fix -[822](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+ClusterFuzz+status%3AFixed+closed-before%3A2013%2F7%2F1&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner&x=m&y=releaseblock&cells=tiles) -bugs! Last quarter, we added a [new -check](http://svnsearch.org/svnsearch/repos/BLINK/search?logMessage=ASSERT_WITH_SECURITY_IMPLICATION) -to identify out of bound memory accesses and bad casts -(ASSERT_WITH_SECURITY_IMPLICATION), which resulted in -~[72](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+%22ASSERTION+FAILED%22+status%3AFixed+opened-after%3A2013%2F1%2F1&sort=-security_severity+-secseverity+-owner+-modified&colspec=ID+Stars+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner&x=m&y=releaseblock&cells=tiles) -new bugs identified and fixed. We’re also beta testing a “Fuzzer Donation” -extension to our [vulnerability reward -program](/Home/chromium-security/vulnerability-rewards-program). - -Anecdotally, this quarter we noticed an increase in the number of IPC reviews -and marked decrease in security issues! Not sure if our recent [security tips -doc](/Home/chromium-security/security-tips-for-ipc) is to credit, but well done -to all the IPC authors and editors! - -Process hardening - -We’ve mostly wrapped up the [binding -integrity](/Home/chromium-security/binding-integrity) exploit mitigation changes -we started last quarter, and it’s now landed on all desktop platforms and Clank. -Remaining work entails [making additional V8 wrapped types inherit from -ScriptWrappable](https://code.google.com/p/chromium/issues/detail?id=236671&can=1&q=tsepez%20scriptwrappable&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified) -so more Chrome code benefits from this protection. We also started a new memory -hardening change that aims to [place DOM nodes inside their own heap -partition](https://code.google.com/p/chromium/issues/detail?id=246860). Why -would we want to do that? Used-after-free memory bugs are common. By having a -separate partition, the attacker gets a more limited choice of what to overlap -on top of the freed memory slot, which makes these types of bugs substantially -harder to exploit. (It turns out there is some performance improvement in doing -this too!) - -Sandboxing++ - -We’re constantly trying to improve [Chrome -sandboxing](/developers/design-documents/sandbox). On [Chrome OS and -Linux](https://code.google.com/p/chromium/wiki/LinuxSandboxing), The GPU process -is now sandboxed on ARM -([M28](https://code.google.com/p/chromium/issues/detail?id=235870)) and we’ve -been been working on [sandboxing -NaCl](https://code.google.com/p/chromium/issues/detail?id=168812) under -[seccomp-bpf](http://blog.chromium.org/2012/11/a-safer-playground-for-your-linux-and.html). -We’ve also increased seccomp-bpf test coverage and locked down sandbox -parameters (i.e. less attack surface). Part of the Chrome seccomp-bpf sandbox is -now used in google3 (//third_party/chrome_seccomp), and Seccomp-legacy and -SELinux [have been -deprecated](https://code.google.com/p/chromium/wiki/LinuxSandboxing) as -sandboxing mechanisms. - -Chrome work across platforms - -Mobile platforms pose a number of challenges to replicating some of the -security features we’re most proud of on desktop, but with only expected -growth of mobile, we know we need to shift some security love here. We’re -getting more people ramped up to help on consulting (security and code -reviews) and making headway on short and long-term goals. - -On Windows, we’re still chugging along sorting out tests and build -infrastructure to get a stable Win64 release build for canary tests. - -On Chrome OS, work on kernel ASLR is ongoing, and we continued sandboxing -[system -daemons](https://code.google.com/p/chromium/issues/detail?id=224082). - -Site Isolation Efforts - -After some design and planning in Q1, we started building the early support for -[out-of-process -iframes](http://www.chromium.org/developers/design-documents/oop-iframes) so -that [Chrome's sandbox can help us enforce the Same Origin -Policy](http://www.chromium.org/developers/design-documents/site-isolation). In -Q2, we added a FrameTreeNode class to track frames in the browser process, -refactored some navigation logic, made DOMWindow own its Document (rather than -vice versa) in Blink, and got our prototype to handle simple input events. We'll -be using these changes to get basic out-of-process iframes working behind a flag -in Q3! - -Extensions & Apps - -This quarter, we detected and removed ~N bad extensions from the Web Store that -were either automatically detected or manually flagged as malicious or violating -our policies. We’ve started transitioning manual CRX malware reviews to a newly -formed team, who are staffing and ramping up to handle this significant -workload. Finally, we’ve been looking at ways to improve the permission dialog -for extensions so that it’s easier for users to understand the security -implications of what they’re installing, and working on a set of experiments to -understand how changes to the permissions dialog affect user installation of -malware. - -Happy Q3! - -Parisa, on behalf of Chrome Security - -## Q1 2013 - -Hi from the Chrome Security Team! - -For those that don’t know us already, we’re here to help make Chrome the [most -secure browser in the market](http://www.chromium.org/Home/chromium-security). -We do a fair bit of work on security reviews of new features (and other -consulting), but here’s a summary of some of the other things we were up to last -quarter: - -Bug, bugs, bugs - -Though some time is still spent [handeling external security -reports](http://www.chromium.org/Home/chromium-security/security-sheriff) -(mainly from participants of our [vulnerability reward -program](http://www.chromium.org/Home/chromium-security/vulnerability-rewards-program)), -we spent comparatively more time in Q1 hunting for security bugs ourselves. In -particular, we audited a bunch of IPC implementations after the -[two](http://blog.chromium.org/2012/10/pwnium-2-results-and-wrap-up_10.html) -[impressive](http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html) -IPC-based exploits from last year - aedla found some juicy sandbox bypass -vulnerabilities ([161564](http://crbug.com/161564), -[162114](http://crbug.com/162114), [167840](http://crbug.com/167840), -[169685](http://crbug.com/169685)) and cdn and cevans found / fixed a bunch of -other interesting memory corruption bugs -([169973](https://code.google.com/p/chromium/issues/detail?id=169973), -[166708](https://code.google.com/p/chromium/issues/detail?id=166708), -[164682](https://code.google.com/p/chromium/issues/detail?id=164682)). -Underground rumors indicate many of these internally discovered bugs collided -with discoveries from third party researchers (that were either sitting on or -using them for their own purposes). At this point, most of the IPCs that handle -file paths have been audited, and we’ve started putting together a doc with -[security tips to mind when writing -IPC](https://sites.google.com/a/google.com/chrome-security/security-tips-for-ipc). - -On the fuzzing front, we updated and added a number of [fuzzers to -Clusterfuzz](https://cluster-fuzz.appspot.com/#fuzzers): HTML (ifratric, -mjurczyk), Flash (fjserna), CSS (bcrane), V8 (farcasia), Video VTT (yihongg), -extension APIs (meacer), WebRTC (phoglund), Canvas/Skia (aarya), and -Flicker/media (aarya); aarya also taught Clusterfuzz to look for dangerous -ASSERTs with security implications, which resulted in even more bugs. Kudos to -Clusterfuzz and the ASAN team for kicking out another [132 security -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=type%3Abug-security+label%3AClusterFuzz+opened-after%3A2012%2F12%2F31+-status%3Awontfix+-status%3Aduplicate+opened-before%3A2013%2F4%2F1&sort=-id+-security_severity+-secseverity+-owner+-modified&colspec=ID+Stars+Pri+Status+Summary+Modified+OS+M+Security_severity+Security_impact+Owner&x=m&y=releaseblock&cells=tiles) -last quarter! One downside to all these new bugs is that our queue of open -security bugs across Chrome has really spiked ([85+ as of -today](https://code.google.com/p/chromium/issues/list?can=2&q=Security_Severity%3DCritical+OR+Security_Severity%3DHigh+OR+Security_Severity%3DMedium&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles)). -PIease help us fix these bugs! - -Process hardening - -We’re constantly thinking about proactive hardening we can add to Chrome to -eliminate or mitigate exploitation techniques. We find inspiration not only from -cutting edge security defense research, but also industry chatter around what -the grey and black hats are using to exploit Chrome and other browsers. This -past quarter jln implemented more fine grained support for [sandboxing on -Linux](https://code.google.com/p/chromium/wiki/LinuxSandboxing), in addition to -some low level tcmalloc changes that improve ASLR and general allocator security -on 64-bit platforms. With jorgelo, they also implemented support for a stronger -GPU sandbox on Chrome OS (which we believe was instrumental in avoiding a Pwnium -3 exploit). tsepez landed support for [V8 bindings -integrity](/Home/chromium-security/binding-integrity) on Linux and Mac OS, a -novel feature that ensures DOM objects are valid when bound to Javascript; this -avoids exploitation of type confusion bugs in the DOM, which Chrome has suffered -from in the past. palmer just enabled bindings integrity for Chrome on Android, -and work is in progress on Windows. - -Work across platforms - -One of our key goals is to get Chrome running natively on 64-bit Windows, where -the platform mitigations against certain attacks (such as heap spray) are -stronger than when running within a WOW64 process. (We’ve also seen some -performance bump on graphics and media on 64-bit Windows!) We made serious -progress on this work in Q1, coordinating with engineers on a dozen different -teams to land fixes in our codebase (and dependencies), working with Adobe on -early Flapper builds, porting components of the Windows sandbox to Win64, and -landing 100+ generic Win64 build system and API fixes. Thanks to all that have -made this possible! - -As Chrome usage on mobile platforms increases, so too must our security -attention. We’ve set out some short and long-term goals for mobile Chrome -security, and are excited to start working with the Clank team on better -sandboxing and improved HTTPS authentication. - -Site isolation - -Work continues on the ambitious project to support [site-per-process -sandboxing](http://www.chromium.org/developers/design-documents/site-isolation), -which should help us [prevent additional attacks aimed at stealing or tampering -with user data from a specific -site](https://docs.google.com/a/google.com/document/d/1X5xZ2hYZurR_c2zU11AoEn15Ebu1er4cCLEudLJvPHA/edit). -Last quarter, we published a more complete [design for out-of-process -iframes](http://www.chromium.org/developers/design-documents/oop-iframes), set -up performance and testing infrastructure, and hacked together a prototype -implementation that helped confirm the feasibility of this project and surface -some challenges and open questions that need more investigation. - -Extensions - -When not feeding the team fish, meacer added a lot of features to Navitron to -make flagged extensions easier to review and remove from the WebStore. To put -this work in perspective, each week ~X new items are submitted to Webstore, ~Y -of them are automatically flagged as malware (and taken down), ~Z malware -escalations are manually escalated from extension reviewers (and then reviewed -again by security;. meacer also added a fuzzer for extensions and apps APIs, and -has been fixing [the resulting -bugs](https://code.google.com/p/chromium/issues/list?can=1&q=Fuzzer%3A+Meacer_extension_apis&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles). - -Until we meet again (probably in the issue tracker)... - -Parisa, on behalf of Chrome Security diff --git a/chromium/docs/website/site/Home/chromium-security/reporting-security-bugs/index.md b/chromium/docs/website/site/Home/chromium-security/reporting-security-bugs/index.md deleted file mode 100644 index b3ca063bcb7..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/reporting-security-bugs/index.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: reporting-security-bugs -title: Reporting Security Bugs ---- - -The Chromium project takes security very seriously, but any complex software -project is going to have some vulnerabilities. You can help us make Chromium -more secure by following the guidelines below when filing security bugs against -Chromium. And as an added benefit to you, following these guidelines will -increase both the chance and size of the reward you could receive under the -[Vulnerability Rewards Program](https://g.co/ChromeBugRewards). - -[TOC] - -### Scope - -Do not report physically-local attacks. For example, please do not report that -you can compromise Chromium by installing a malicious DLL on a computer in a -place where Chromium will find it and load it. Similarly, please do not report -password disclosure using the Inspect Element feature to convert the -"\*\*\*\*\*\*\*" into the underlying text. - -To understand why, see the [Chromium Security -FAQ.](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md) - -### General Guidelines - -These are the criteria that we expect from a good security bug report: - -* Was filed via the [security - template](https://code.google.com/p/chromium/issues/entry?template=Security%20Bug). -* Contains a clear and descriptive title. -* Includes the Chromium/Chrome version number and [release - channel](/getting-involved/dev-channel). -* Lists the operating system, version, and service pack level of the - testing platform. -* Includes a reproducible example of the bug, such as an attached HTML - or binary file that triggers the bug when loaded into Chrome. - * **Please** make the file as small as possible and remove any - content not necessary to trigger the vulnerability. - * **Please** avoid dependencies on third-party libraries such as - jQuery or Prototype (which can dramatically complicate the - process of diagnosing a potential vulnerability). - * ***For short** (e.g. 15 lines), text-based reproductions (eg. - HTML or SVG), please include the reproduction case directly in - the report text.* - * **For larger** or more complex cases, please attach files - directly to the bug, not in an archive. - * If you host a page that demonstrates the bug, **please also - attach** the files and config needed reproduce locally. - * **Note** that a screen capture or video showing the issue is - largely unnecessary except in the case for security UI issues, - and is not a substitute for a well-written, reproducible test - case. -* Provides a brief description (where appropriate) of the nature of - the bug along with any additional details required to reproduce it. -* Avoids unnecessary commentary or hyperbole. (If you choose to - provide a severity estimate please follow the criteria at [Severity - Guidelines for Security Issues](/developers/severity-guidelines).) - -### Reporting Crash Bugs - -In addition to the general guidelines above, we look for the following -information on bugs that trigger browser crashes or sad tabs: - -* Whether the crash is in the browser (application crash) or the - renderer (sad tab). -* Paste into the bug description the exception details, register - state, and relevant portion of the stack trace. - * General crash reporting information is available at [Reporting a - Crash - Bug](/for-testers/bug-reporting-guidelines/reporting-crash-bug). - * Platform specific debugger configuration (including instructions - on setting up symbols) is available for - [Windows](/developers/how-tos/debugging), [Mac OS - X](/developers/debugging-on-os-x), and - [Linux](https://code.google.com/p/chromium/wiki/LinuxDebugging). -* If crash reporting is enabled, please provide your [client - ID](/for-testers/bug-reporting-guidelines/reporting-crash-bug). -* Please ensure that **all stack traces include symbols**. - -#### Signs A Crash Is Not A Security Bug - -Generally, we do not consider a denial of service (DoS) issues to be security -vulnerabilities. Examples of these bug classes include: consistent fixed-offset -[NULL pointer -dereferences](https://en.wikipedia.org/wiki/Pointer_(computing)#Null_pointer), -[call stack overflows (stack -exhaustion)](https://blogs.technet.com/b/srd/archive/2009/01/28/stack-overflow-stack-exhaustion-not-the-same-as-stack-buffer-overflow.aspx), -and [out of memory (OOM) errors](https://en.wikipedia.org/wiki/Out_of_memory). -Some of these crashes are valid bugs, and should be reported; however, they are -not security bugs and should be filed through the [normal defect -template](https://code.google.com/p/chromium/issues/entry). - -### Going Above and Beyond - -While we don't expect security vulnerability reporters to provide us any of the -following information, we certainly find it extremely helpful and would take it -into consideration when determining whether or not a particular report qualified -for a larger award: - -* An extremely clear and well-reduced test case demonstrating the - vulnerability. -* An accurate analysis of the exact nature of a crash (e.g. - identifying the reason for and location of a premature pointer - deletion in a use-after-free vulnerability). -* An explanation of a broader vulnerability or recurring vulnerable - pattern associated with the reported bug (e.g. noting that a - vulnerability arises in more than one location due to a common - misuse pattern on a particular class). -* Helpful guidance for fixing the vulnerability, or providing an - effective fix as part of the reporting process. -* Identifying any particularly interesting or impactful issue that - goes beyond the scope of a single report. -* Any noteworthy cooperation in the reporting and resolution that goes - significantly beyond the normal reporting guidelines. -* We reward more where the reporter [provides a good analysis - demonstrating probable exploitability](/system/errors/NodeNotFound). - -### Bug Visibility - -The visibility of security bugs is restricted until a fix has been widely -deployed. For more information see the [Security -FAQ](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#TOC-Can-you-please-un-hide-old-security-bugs-).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/reviews-and-consulting/index.md b/chromium/docs/website/site/Home/chromium-security/reviews-and-consulting/index.md deleted file mode 100644 index 13178eefb53..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/reviews-and-consulting/index.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: reviews-and-consulting -title: Reviews and Consulting ---- - -So, ya need some security help? Our talents are many, but here are the things we -normally assist Chromium engineers with: - -**Security Reviews** - -Features that are new or substantial refactors / expansions should go through -the [Chrome Security Review](/Home/chromium-security/security-reviews) process -via the Chrome launch process. The purpose of a security review is ==not== the -elimination of all possible vulnerabilities, but rather the promotion of [secure -design and implementation practices in -Chromium](/Home/chromium-security/education). It also helps the security team -stay engaged with the rest of Chromium engineering. - -**Adding new code to third_party** - -Third party code is a hot spot for security vulnerabilities, so make sure to -[give security a head's up by getting a code -review](http://www.chromium.org/developers/adding-3rd-party-libraries#TOC-Get-a-Review). - -**One-off questions** - -If you are not sure what to do, or need other help, you can always just reach us -at [security@chromium.org](mailto:security@chromium.org).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/root-ca-policy/index.md b/chromium/docs/website/site/Home/chromium-security/root-ca-policy/index.md deleted file mode 100644 index b6cd2b46a92..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/root-ca-policy/index.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: root-ca-policy -title: Chrome Root Program ---- - -## Last updated: 2020-11-02 - -Bookmark this page as <https://g.co/chrome/root-policy> - -## Introduction - -Google Chrome relies on Certification Authorities (CAs) to issue certificates to -websites. Chrome uses these certificates to ensure the HTTPS connections it -makes on behalf of its users are secure and private. - -As part of establishing a secure connection, Chrome cryptographically verifies -that the website's certificate was issued by a recognized CA. Certificates that -are not issued by a CA recognized by Chrome, or by a user's local settings, can -cause users to see warnings and error pages. - -If you’re an enterprise managing trusted CAs for your organization, including -locally installed enterprise CAs, the policies described in this document do not -apply to your CA. No changes are currently planned for how enterprise -administrators manage those CAs within Chrome. CAs that have been installed by -the device owner or administrator into the operating system trust store are -expected to continue to work as they do today. - -If you’re a Chrome user experiencing a certificate error, please see [this -support article](https://support.google.com/chrome/answer/6098869?hl=en) for -more information. - -If you're a website operator, you can learn more about [why HTTPS -matters](https://web.dev/why-https-matters/) and how to [secure your site with -HTTPS](https://support.google.com/webmasters/answer/6073543). If you've got a -question about a certificate you've been issued, including questions about -validity and revocation, please contact the CA that issued the certificate. - -Though uncommon, certificates can also be used by websites to identify clients -connecting to them. Other than ensuring it is well formed, Chrome simply passes -the certificate to the server, which performs the evaluation and enforces its -chosen policy. The policies on this page do not apply to client certs. - -## Chrome Root Program - -When Chrome presents the connection to a website as secure, Chrome is making a -statement to its users about the security properties of that connection. Because -of the CA's critical role in upholding those properties, Chrome must ensure the -CAs who issue certificates are operated in a consistent and trustworthy manner. -This is achieved by referring to a list of root certificates from CAs that have -demonstrated why continued trust in them is justified. This list is referred to -as a Root Store. The policies and requirements for participating and being -included in a Root Store are known as a Root Program. - -## Root Program Transition - -The sections below describe the Chrome Root Program, and policies and -requirements for CAs to have their certificates included in a default -installation of Chrome, as part of the transition to the Chrome Root Store. - -Historically, Chrome has integrated with the Root Store provided by the platform -on which it is running. Chrome is in the process of transitioning certificate -verification to use a common implementation on all platforms where it's under -application control, namely Android, Chrome OS, Linux, Windows, and macOS. Apple -policies prevent the Chrome Root Store and verifier from being used on Chrome -for iOS. This will ensure users have a consistent experience across platforms, -that developers have a consistent understanding of Chrome's behavior, and that -Chrome will be better able to protect the security and privacy of users' -connections to websites. - -For CAs that already participate in other public Root Programs, such as the -[Mozilla Root -Program](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/), -many of these requirements and processes should be familiar. - -### Transitional Root Store - -During this transition, the Chrome Root Store contains a variety of existing -Certification Authorities' certificates that have historically worked in Chrome -on the majority of supported platforms. This promotes interoperability on -different devices and platforms, and minimizes compatibility issues. This should -ensure as seamless a transition as possible for users. - -In addition to compatibility considerations, CAs have been selected on the basis -of past and current publicly available and verified information, such as that -within the Common CA Certificate Database ([CCADB](https://ccadb.org)). CCADB is -a datastore run by Mozilla and used by a variety of operating systems, browser -vendors, and Certification Authorities to share and disclose information -regarding the ownership, historical operation, and audit history of CA -certificates and key material. - -### Requesting Inclusion - -For Certification Authorities that have not been included as part of this -initial [Chrome Root Store](https://g.co/chrome/root-store), questions can be -directed to -[chrome-root-authority-program@google.com](mailto:chrome-root-authority-program@google.com). -Priority is given to CAs that are widely trusted on platforms that Chrome -supports, in order to minimize compatibility issues. - -For the inclusion of new CA certificates, priority is given to CAs in the -following order, in order to minimize disruption or risks to Chrome users: - -- CAs that are widely trusted, and which are replacing older certificates with certificates and key material created within the past five years, and have an unbroken sequence of annual audits where these certificates and key material are explicitly listed in scope. -- CAs whose certificates and certificate hierarchy are only used to issue TLS server certificates, and do not issue other forms of certificates. -- CAs that have undergone a widely-recognized public discussion process regarding their CP, CPS, audits, and practices. At this time, the only discussion process recognized as acceptable is the discussion process operated by Mozilla on behalf of the open-source community at [mozilla.dev.security.policy](https://www.mozilla.org/en-US/about/forums/#dev-security-policy). -- CAs that maintain sole control over all CA key material within their CA certificate hierarchy, and include their entire certificate hierarchy within a single audit scope. -- CAs that have been annually audited according to both of the “WebTrust Principles and Criteria for Certification Authorities” and the “WebTrust Principles and Criteria for Certification Authorities - SSL Baseline With Network Security”. Other audit criteria may be accepted on a discretionary basis, but Chrome will prioritize audits conducted according to both of these criteria. - -Certification Authorities that do not meet all of the above criteria will be -dealt with on a case-by-case basis. Note that the above requirements are -illustrative only; Google includes CAs in its Root Program, and includes or -removes CA certificates within its Root Store as it deems appropriate for user -safety. The selection and ongoing membership of CAs is done to enhance the -security of Chrome and promote interoperability; CAs that do not provide a broad -service to all browser users are unlikely to be suitable. - -As this transition occurs, CAs should continue to work with the relevant vendors -of operating systems where Chrome is supported to additionally request inclusion -within their root certificate programs as appropriate. This will help minimize -any disruption or incompatibilities for end users, by ensuring that Chrome is -able to validate certificates from the CA regardless of whether it is using the -Chrome Root Store or existing platform integrations. - -The Chrome Root Store Policy will be updated to more fully detail the set of -formal ongoing requirements for working with Google in order to be distributed -and included in a default installation of Chrome, as well as additional steps -for applying or updating existing included certificates. Any questions regarding -this policy can be directed to -[chrome-root-authority-program@google.com](mailto:chrome-root-authority-program@google.com) - -## Responding to Incidents - -Chrome requires that CAs included in the Chrome Root Program abide by their -Certificate Policy and/or Certification Practices Statement, where the CA -describes how they operate, and must incorporate [CA/Browser Forum’s Baseline -Requirements](https://cabforum.org/baseline-requirements-documents/). Failure of -a CA to meet their commitments, as outlined in their CP/CPS and the Baseline -Requirements, is considered an incident, as is any other situation that may -impact the CA’s integrity, trustworthiness, or compatibility. - -Chrome requires that any suspected or actual compliance incident be promptly -reported and publicly disclosed upon discovery by the CA, along with a timeline -for [an analysis of root -causes](https://landing.google.com/sre/sre-book/chapters/postmortem-culture/), -regardless of whether the non-compliance appears to the CA to have a serious or -immediate security impact on end users. Chrome will evaluate every compliance -incident on a case-by-case basis, and will work with the CA to identify -ecosystem-wide risks or potential improvements to be made in the CA’s operations -or in root program requirements that can help prevent future compliance -incidents. - -When evaluating a CA’s incident response, Chrome’s primary concern is ensuring -that browsers, CAs, users, and website developers have the necessary information -to identify improvements, and that the CA is responsive to addressing identified -issues. - -Factors that are significant to Chrome when evaluating incidents include (but -are not limited to): a demonstration of understanding of the root causes of an -incident, a substantive commitment and timeline to changes that clearly and -persuasively address the root cause, past history by the CA in its incident -handling and its follow through on commitments, and the severity of the security -impact of the incident. In general, a single compliance incident considered -alone is unlikely to result in removal of a CA from the Chrome Root Store. - -Chrome expects CAs to be detailed, candid, timely, and transparent in describing -their architecture, implementation, operations, and external dependencies as -necessary for Chrome and the public to evaluate the nature of the incident and -depth of the CA’s response. - -When a CA fails to meet their commitments made in their CP/CPS, Chrome expects -them to file an incident report. Due to the incorporation of the Baseline -Requirements into the CP and CPS, incidents may include a prescribed follow-up -action, such as revoking impacted certificates within a certain timeframe. If -the CA doesn’t perform the required follow-up actions, or doesn’t perform them -in the expected time, the CA should file a secondary incident report describing -any certificates involved, the CA’s expected timeline to complete any follow-up -actions, and what changes the CA is making to ensure they can meet these -requirements consistently in the future. - -When a CA becomes aware of or suspects an incident, they should notify -[chrome-root-authority-program@google.com](mailto:chrome-root-authority-program@google.com) -with a description of the incident. If the CA has publicly disclosed this -incident, this notification should include a link to the disclosure. If the CA -has not yet disclosed this incident, this notification should include an initial -timeline for public disclosure. Chrome uses the information on the public -disclosure as the basis for evaluating incidents.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-bug-lifecycle/index.md b/chromium/docs/website/site/Home/chromium-security/security-bug-lifecycle/index.md deleted file mode 100644 index ba0c5a39d17..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-bug-lifecycle/index.md +++ /dev/null @@ -1,258 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-bug-lifecycle -title: Security Bug Lifecycle ---- - -The [canonical version of this document is now in the Chromium source -tree](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/sheriff.md). - -The following document describes the process of working from an inbound security -bug report to releasing a fix on all affected branches. You can also refer to -the [Security Cheat Sheets](/system/errors/NodeNotFound) to provide a quick walk -through or as a reference to check your progress. - -[TOC] - -## Triage - -The first step of triage is confirming that a bug does exist and it does -represent a vulnerability. Most reporters provide a version in the bug report, -but you’ll generally need to verify against the current stable, beta, and trunk -builds. The [Reporting Security -Bugs](/Home/chromium-security/reporting-security-bugs) page provides information -on what detail is required and how to get it, so you should use that as a guide -to fill in anything the report is missing. If you don’t have a particular build -on hand to perform the analysis against, you can leave a comment in the bug -requesting that another team member assist in verifying it. The list of -currently open security (modulo **Security-Severity-None**) bugs can be viewed -with [this -query](https://code.google.com/p/chromium/issues/list?can=2&q=Type%3DBug-Security+-Security_Severity%3DNone&sort=-secseverity&groupby=&colspec=ID+Pri+Area+Feature+Status+Summary+Modified+Owner+Mstone+OS+Secseverity+Reporter+Secimpacts). - -### Security Features & Non-Vulnerabilities - -There are a number of bugs we want to keep track of for security reasons, but -shouldn't track as vulnerabilities. This includes new security features and -improvements, or changes that simply have a security impact or warrant a closer -inspection from a security perspective. In this case the bug should *not* be -filed as *Type-Security*. Instead it should be filed as whatever type is -relevant (generally **Type-Bug**) and also have the **Feature-Security** label -set. This ensures the security team will still receive updates, but keeps it out -of the list of open vulnerabilities. - -### Assigning Labels - -**==First verify the bug, requirements to trigger, and affected platforms==**; -if you cannot verify the bug directly (e.g. nonavailability of the affected -platform) then assign or CC an owner who can. Once you’ve verified the bug, you -need to determine the appropriate labels. You should follow the severity -guidelines [Severity Guidelines for Security -Issues](/developers/severity-guidelines) to determine the rating for the -**Security-Severity-**\* label. Remember to also consider any mitigating factors -that might reduce the severity, such as unusual or excessive interaction, or the -feasibility of reliably triggering the condition in the wild (e.g. race -conditions are notoriously difficult). - -Once you’ve determined the severity you can assign the milestone and priority -according to the following guidelines: - -* **Security-Severity-Critical** - * **Pri-0** - * Current stable milestone (or earliest milestone impacted) -* **Security-Severity-High** - * **Pri-1** - * Current stable milestone (or earliest milestone impacted) -* **Security-Severity-Medium** - * **Pri-2** - * Next stable milestone -* **Security-Severity-Low** - * **Pri-3** - * Next stable milestone -* **Security-Severity-None** - * No priority required - * No milestone required - -Set the SecImpacts flags to identify the affected branches, so we know what -needs to be merged and have historical tracking data: - -* **SecImpacts-Stable** - Affects shipping branch and should be - considered for merge. -* **SecImpacts-Beta** - Affects beta branch and fix and should be - considered for merge. -* **SecImpacts-None** - Doesn't affect a shipping branch (no merge - required). - -The milestone targets may shift slightly to adjust for a release schedule. For -example, when the current stable is at the end of its cycle you will generally -bump all open bugs to target the next stable milestone. - -Also, it's important to ensure that all security bugs are set to -**Type-Security** and any security bugs with a severity other than -**Security-Severity-None** include the **Restrict-View-SecurityTeam** flag. - -The remaining triage follows the [standard -guidelines](/getting-involved/bug-triage). Key points to remember are the -following: - -* Update the status to **Untriaged**, **Available**, **Assigned**, or - **Started** (as appropriate). -* Apply the following labels as needed: **OS-**\*, **Feature-**\*, - **Area-**\*, **Internals-**\*, **Crash**. -* Any changes that will be merged to the beta branch must be labeled - as **ReleaseBlock-Stable**. -* Ensure the comment adequately explains any status changes - *(severity, milestone, and priority assignment generally require - explanatory text)*. - -### Upstreaming WebKit Bugs - -Any WebKit bugs should be upstreamed to -[bugs.webkit.org](http://bugs.webkit.org/) immediately after verification, basic -analysis to isolate the issue, and reducing any test cases to a manageable size. -When upstreaming WebKit security bugs, remember the following points: - -* File against the security component -* Include a link back to the Chromium bug in your comment -* Include a credit to the original reporter if appropriate -* CC any Chromium Team members working on the bug downstream - -#### Getting Access to WebKit Security Bugs - -Any members of the Chromium Security Team involved in bug triage will need to -join the [WebKit Security Group](http://www.webkit.org/security/). If you're not -already on WebKit Security, please ask another Chromium Security Team member to -nominate you. After joining you'll need to request security bug access (this can -be done by replying to your confirmation email). Once bug access is granted, -you'll need to configure your account to get emailed on all inbound security -bugs. You do this by adding **webkit-security-unassigned@lists.webkit.org** to -the **User Watching** section on the [Email -Preferences](https://bugs.webkit.org/userprefs.cgi?tab=email) tab on WebKit's -bugzilla. (You'll probably want to create a Gmail filter on these messages as -well.) - -**Landing WebKit Patches** - -To contribute a patch to WebKit you can generally just follow the [instructions -on webkit.org](http://www.webkit.org/coding/contributing.html). However, one -additional step must be taken to land patches for security bugs, because the -WebKit Commit Bot and the WebKit Review Bot are not included in the WebKit -Security Group. This means your patch will not be placed in the commit queue -after receiving cq+ unless the bots are explicitly given access to the bug. To -do this, add these addresses to the cc: list of the WebKit bug: - -* webkit.review.bot@gmail.com -* commit-queue@webkit.org - -### Timeline - -As a rule, you’ll want to ensure that the full initial triage is performed and -the bug is updated within 48 hours of the initial report. During business hours -the basic triage and bug update should occur within four hours at most. - -### Erroneous Reports - -Some reports are obviously not legitimate, or represent behavior that we do not -intend to change. In those cases you should mark the bug as **WontFix** or -**Invalid** (as appropriate) and provide a simple explanation to the reporter. -For non-security bugs erroneously reported via the security template, you should -remove all security labels, set the “Crash” label if appropriate, add in the -appropriate area/feature labels, and set the status to “Untriaged.” - -## Shepherding - -The shepherding process starts with finding an owner for a bug. If you have -access to security bugs, you can find a list of all open security bugs without -an owner -[here](http://code.google.com/p/chromium/issues/list?can=2&q=Type%3DBug-Security+-Security_SecSeverity%3DNone+-has%3Aowner&sort=-security_secseverity&colspec=ID+Pri+Area+Feature+Status+Summary+Modified+Owner+Mstone+OS+Secseverity&x=mstone&y=area&cells=tiles). -When analysing a bug for triage you’ll often find that you can work out a -solution yourself. If that’s the case and you have time to develop a patch, then -this is usually the most expedient solution to getting a fix out. - -For bugs that you can’t fix yourself, you’ll need to find an owner. If you don’t -know who to assign a bug to, it’s often best to start by asking other members of -the security team if they’re familiar with the code. Then they can either take -the ownership of the bug, or point you to a developer who would make a good -owner. - -If no one on the security team has a good suggestion, you’ll generally have to -use svn blame or some other means to track back one of the original developers -of the code. If you don’t have a checkout handy, you can always use the annotate -feature on <http://src.chromium.org/>. - -### Following Up - -Priorities and schedules vary between developers. So, when you assign a security -bug to an owner you should make sure you convey the timeline you’re expecting -for a fix. If you don’t see regular progress in the bug report, you may need to -manually follow up with the owner. Oftentimes, the bug just ended up being -harder to reproduce or fix than it originally appeared, so it’s a good idea to -offer help whenever there are unanticipated delays. - -Keep in mind that on average we get high severity bugs fixed on the release -branch within *30 days* of the initial report, and almost always within *60 -days* at the most. For critical severity bugs we have a hard deadline of 60 days -from initial report to a shipping fix. - -### Handling a Fix - -Once a fix is applied to trunk either you or the owner will change the bug -status to **Merge-Approved** and switch the **Restrict-View-SecurityTeam** label -to **Restrict-View-SecurityNotify**. At that point you’ll need to evaluate -whether the bug is a good candidate for a merge. - -## Merging - -Security fixes often need to be merged to the stable branch (this includes -patches to Chrome, WebKit, or other dependencies). Generally this is done by one -of the security team members. The first thing you need to do is evaluate whether -a fix should be considered for merge. Generally any high or critical severity -fixes should be seriously considered for merge. Medium and low-severity fixes -can be considered as well if they're particularly worrisome (e.g. bad -information leak), have significant non-security impact (e.g. top crasher), or -are just very low risk. - -One of the key considerations in determining what to merge is assessing the risk -of breakage, which the bug’s owner should be able to convey. For risky fixes -you’ll often want to consider bumping it to a later milestone. When you've -decided to merge a fix, you should verify with a release manager that the merge -window is open for any affected branches. Normally a fix will need to be merged -to both the current stable and beta branches. - -You should merge fixes via [drover](/developers/how-tos/drover), which automates -most of the process. If the [drover merge](/developers/how-tos/drover) does not -apply cleanly you may want to reconsider whether the fix will introduce an -unacceptable breakage risk. In the event that you can’t use drover to merge a -fix, you still have the option of manually merging from a branch checkout. In -general, most team members should have a checkout for the current stable, beta -and trunk branches. So, this can generally just follow the [normal patch -process](/developers/contributing-code), but using a branch repository. - -Once the fix is successfully merged you will need to update the the bug with the -merge revision numbers, and change the status to **FixUnreleased** (or to -**Fixed** if the stable branch is not affected) and set the merge status to -**Merge-Completed** (if drover didn't do so). For beta merges, you should also -verify that the **ReleaseBlock-Stable** flag is present. - -### Updating and Release Notes - -After a patch has been landed (and potentially merged) you’ll need to update the -[security release -document](https://docs.google.com/a/google.com/Doc?docid=0AUtTDLyP_VtYY2dxczZrNHpfODhzajZzbWd6&hl=en), -which is used for tracking security bugs for release notes. - -### Vulnerability Rewards Nomination - -Generally, once a fix has been applied to trunk we will consider a bug for a -vulnerability reward. This will generally be done by the team member shepherding -the bug, or the owner if it’s a security team member. To remind yourself that -you may want to consider a specific bug you can add the **reward-topanel** label -in the tracker. - -When nominating a bug for a reward, be sure to consider the overall quality, and -any additional value the reporter brought to the process. For reference, the -general guidelines are listed on the [Vulnerability Rewards -Program](/Home/chromium-security/vulnerability-rewards-program) page.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-faq/index.md b/chromium/docs/website/site/Home/chromium-security/security-faq/index.md deleted file mode 100644 index a7b987dea7a..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-faq/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-faq -title: Security FAQ ---- - -**The [canonical version of the FAQ is now in the Chromium source -tree](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md).**
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-faq/service-worker-security-faq/index.md b/chromium/docs/website/site/Home/chromium-security/security-faq/service-worker-security-faq/index.md deleted file mode 100644 index 230a45a998c..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-faq/service-worker-security-faq/index.md +++ /dev/null @@ -1,340 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -- - /Home/chromium-security/security-faq - - Security FAQ -page_name: service-worker-security-faq -title: Service Worker Security FAQ ---- - -#### **Do not edit — for historical reference only** - -#### The [canonical version of the FAQ is now in the Chromium source -tree](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/service-worker-security-faq.md). - -#### [TOC] - -This FAQ is specifically about service workers. Also see the general [security -FAQ](/Home/chromium-security/security-faq). - -Like the general security FAQ, this document is a collaborative effort by many -Chromium developers. (rsesek, estark, falken, slightlyoff, jakearchibald, evn, -raymes, ainslie, mek, lgarron, elawrence, kinuko, palmer, your name here...) -Last updated 12 May 2017. If you see an error or have an additional question, -and have a Chromium account, go ahead and fix it. If you don't have a Chromium -account, email palmer@chromium.org for a fix. - -#### Service Workers seem extremely risky! Why are they OK? - -Service Workers (SW) are indeed powerful. They support compelling web -applications that can run offline or with intermittent connectivity. You can -edit documents, browse and buy from catalogs, send social media messages, write -email, etc. even in the subway! Service Workers can make the web platform more -viable than ever before, enabling web apps to better compete with native apps -even while essentially retaining the browse-to-use, sandboxed nature of the -[Open Web Platform](https://www.w3.org/wiki/Open_Web_Platform) (OWP) that we all -love. The rest of this FAQ will explain how the SW designers and implementers -have mitigated the risks that necessarily come with this functionality. - -Service Workers are a replacement for and an improvement on the legacy -[Application Cache -API](https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache), -which has been available in the OWP for a very long time. - -For more background on Service Workers, see [Service Workers -Explained](https://github.com/w3c/ServiceWorker/blob/master/explainer.md). - -#### Do Service Workers run in a sandbox? - -Yes, SWs run in renderer processes. When Chrome starts a SW, it chooses a -renderer process that is associated with the SW’s origin. If one does not exist, -the browser creates a new one using a new SiteInstance for the origin. - -#### What APIs can Service Workers access? - -The HTML [specification partially enumerates the API surface available to -Workers](https://html.spec.whatwg.org/#apis-available-to-workers). See also -[Client](https://developer.mozilla.org/en-US/docs/Web/API/Client), and -[ServiceWorkerGlobalScope](https://w3c.github.io/ServiceWorker/#serviceworkerglobalscope-interface). -(Note that SWs do not have access to synchronous APIs.) - -However, other web platform specifications can add new API surface. For example, -[the Permissions API exposes a permissions attribute to -workers](https://w3c.github.io/permissions/#navigator-and-workernavigator-extension). -Generally, SWs have access to a subset of the web platform APIs, although there -are some Worker- and Service Worker-specific APIs that do not make sense for -in-page JavaScript. - -(\[Service\]WorkerGlobalScope is of course not necessarily a strict subset of -Window, and similarly WorkerNavigator is not necessarily a strict subset of -Navigator. And the various SW events are of course only exposed to SWs.) - -#### Do Service Workers obey the same-origin policy? - -Service Worker registration specifies that [Service Workers must run in the same -origin as their -callers](https://w3c.github.io/ServiceWorker/#register-algorithm). - -The origin comparison for finding a Service Worker registration for a request is -[specified](https://w3c.github.io/ServiceWorker/#scope-match-algorithm) to be to -be a longest-prefix match of serialized URLs, including their path. (E.g. -<https://example.com/> != <https://example.com.evil.com/>.) This specification -gap seems fragile to us, [and should be fixed to be specified and implemented as -actual origin equality](https://github.com/w3c/ServiceWorker/issues/1118), but -doesn’t currently seem exploitable. - -Only [Secure Contexts can register or use Service -Workers](https://w3c.github.io/webappsec-secure-contexts/#example-c52936fc). - -Because SWs can call importScripts to import scripts (from any other origin), it -is a good idea for site operators to set a Content-Security-Policy response -header on the ServiceWorker’s JavaScript response, instructing the browser what -sources of script the origin considers trustworthy. That would reduce an XSS -attacker’s ability to pull in their own code. - -#### Do Service Workers live forever? - -There are two concepts of “live” here. One is about the installed registration -and one is about the running Service Worker thread. - -The installed registration lasts indefinitely, similar to origin-scoped storage -like -[IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API). -Additionally, the browser performs an update check after any navigation using -the Service Worker, invalidating the HTTP cache every 24 hours. (Additionally, -[according to a recent spec -change](https://w3c.github.io/ServiceWorker/#dfn-use-cache), browsers will -revalidate the HTTP cache for SW scripts unless the site opts into using the -cache. Chrome does not yet adhere to this new part of the spec, [but will -soon](https://bugs.chromium.org/p/chromium/issues/detail?id=675540).) - -The browser also performs an update check whenever the SW starts and -periodically while the worker is running, if it has not checked in the last 24 -hours (86,400 seconds, [as specified in the Handle Functional Event -algorithm](https://w3c.github.io/ServiceWorker/#handle-functional-event-algorithm)). - -The browser can terminate a running SW thread at almost any time. Chrome -terminates a SW if the SW has been idle for 30 seconds. Chrome also detects -long-running workers and terminates them. It does this if an event takes more -than 5 minutes to settle, or if the worker is busy running synchronous -JavaScript and does not respond to a ping within 30 seconds. When a SW is not -running, Developer Tools and chrome://serviceworker-internals show its status as -STOPPED. - -#### How can I see Service Workers in Chrome? - -You can see them in the Service Workers field in the Application tab of -Developer Tools. You can also look at chrome://serviceworker-internals. - -#### Do Service Workers keep running after I close the tab? - -If an origin has any Service Workers running, each worker will be shut down soon -after it processes the last event. Events that can keep a worker alive include -push notifications. (Note that the [push notifications will trigger a -user-visible notification if the SW does not create -one](https://cs.chromium.org/chromium/src/chrome/browser/push_messaging/push_messaging_notification_manager.cc?type=cs&l=270), -and they also require the person to grant the origin permission in a prompt. you -can see that in action in this [push notifications demo -app](https://gauntface.github.io/simple-push-demo/).) - -#### Can attackers use Service Workers to trigger attacks developed after SW registration? - -For example, could an attacker convince users to visit a malicious website, then -wait for (e.g.) a V8 bug to show up in Chrome's repository, then write an -exploit, and then somehow run that exploit on the machines of everyone who -visited the malicious website in the last month or so? - -Without explicit permission from the user, the browser won't let the SW poll -for/receive any push notification events the attacker's server may (try to) -send, and hence the SW won't get a chance to handle the events. - -Similarly, you might imagine a SW that tries to use importScripts to -periodically (re-)load maybe-v8-payload.js. But, the SW would only get to do -that as part of an event handler. And if the SW isn't getting any events -(because the person is not browsing or navigating to attacker.com, and because -the person never granted attacker.com push notification permission), then it -will never get to run its event handlers, and so again the SW won't get a chance -to attack. If the person *is* currently browsing attacker.com, then the attacker -doesn't gain any additional attack benefit from a Service Worker. They can just -<script src="maybe-v8-payload.js"> as usual, from the in-page JavaScript. - -**However,** if/when [Foreign -Fetch](https://github.com/w3c/ServiceWorker/blob/master/foreign_fetch_explainer.md) -ships, the situation will change if people browse sites that fetch resources -from the attacker's server. - -#### If a site has an XSS vulnerability, can the attacker permanently compromise that origin for me? - -An XSS attacker can indeed register an evil SW. As before SWs, XSS is a very -powerful mode of attack on a web origin. To mitigate the risk that an XSS attack -will register a malicious SW, the browser requires that the SW registration URL -come from the origin itself. Thus, to use an XSS attack to register a malicious -SW, the attacker needs the additional capability to host their own scripts on -the server. - -Here is another exploit scenario: If the page with an XSS vulnerability also has -a JSONP endpoint, the attacker could use it to (1) bypass CSP; (2) register a -SW; and (3) call importScripts to import a third-party script to persist until - - the site operators detect and remediates the issue, and - - users navigate to the site again while online. - -In an XSS situation, the 24 hour cache directive limit ensures that a malicious -or compromised SW will outlive a fix to the XSS vulnerability by a maximum of 24 -hours (assuming the client is online). Site operators can shrink the window of -vulnerability by setting lower TTLs on SW scripts. We also encourage developers -to [build a kill-switch -SW](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776). - -In the near future, the right cleanup strategy (for this and other issues) will -be [Clear-Site-Data](https://www.w3.org/TR/clear-site-data/). - -Additionally, site operators should ignore (e.g. respond with 400 Bad Request) -requests that have the Service-Worker request header for domains or paths that -the server doesn’t expect to be serving SW scripts for. - -#### Can sites opt out of Service Workers? - -Sites that do not intend to serve Service Workers on particular domains or paths -can check for and explicitly reject requests for worker scripts, by checking for -[the Service-Worker request -header](https://w3c.github.io/ServiceWorker/#service-worker-script-request). - -#### How many SWs can an origin, or Chrome itself, spawn? - -The current specification and the current implementation in Chrome do not define -any limits. - -#### Can attackers 'hide' Service Worker scripts in JPEGs or other non-script MIME types? - -*Can an attacker upload (for example) JPEG files to a site that supports the -capability, and then use the uploaded files as SW scripts?* The SW specification -and implementation require that a SW script have the right JavaScript MIME type. -(Additionally, as noted elsewhere in this document, server operators should -reject SW script requests except for the exact endopints they intend to serve SW -scripts from.) - -#### Can iframes register Service Workers? - -Yes, if and only if they are themselves secure contexts. [By -definition](https://w3c.github.io/webappsec-secure-contexts/#examples-framed), -that means that they must be nested inside secure contexts, all the way up to -the top-level document. - -Additionally, third-party iframes can’t register Service Workers if third party -cookies are blocked. (See chrome://settings/content.) - -#### Why doesn’t Chrome prompt the user before registering a Service Worker? - -The Chrome Team generally prefers to ask people about things that are -privacy-relevant, using nouns and verbs that are simple and precise (camera, -mic, geo-location, and so on). But we avoid asking questions about resource-use -(caching, persistence, CPU, and so on). We’re better prepared to make those -types of resource decisions automatically. (Consider, for example, that the HTTP -cache, AppCache, and even [Google -Gears](https://en.wikipedia.org/wiki/Gears_(software)) also do not/did not -prompt the user.) - -[An informal study by Chrome team members Rebecca Rolfe, Ben Wells, and Raymes -Khoury](https://docs.google.com/presentation/d/1suzMhtvMtA11jxPUdH1jL1oPh-82rTymCnslgR3ehEE/edit#slide=id.p) -suggests that people do not generally have sufficient context to understand -permission requests triggered by API calls from origins in iframes. It seems -reasonable that people would similarly lack the context to understand requests -from Service Workers. - -#### What if I don't want any SWs? - -You can disable SWs by disabling storage in chrome://settings. SW are gated on -cookie/local data storage settings. (That is, the **Block sites from setting any -data** radio button in **Content Settings**.) - -Clearing browser data (CBD; the **Clear browsing data...** button in Settings or -chrome://settings/clearBrowserData) also deletes SWs. You can verify that by -following this test procedure: - -1. Visit https://gauntface.github.io/simple-push-demo/ -2. In a second tab, visit chrome://serviceworker-internals/ to see the - ACTIVATED and RUNNING SW - 1. Note that the origin/the origin's SW cannot actually send any - push notifications until you grant it that permission -3. In a third tab, go to chrome://settings/clearBrowserData to clear - browsing data; clear it by clicking **Clear browsing data** -4. Reload chrome://serviceworker-internals/ to see that the SW's status - is now REDUNDANT and STOPPED -5. Close the Simple Push Demo tab -6. Reload chrome://serviceworker-internals/ to see that the SW is now - gone - -You can also remove individual SW registrations with -chrome://serviceworker-internals/. - -If you really want to not use the modern web, you can use one of the browsers -that don't (yet) support SWs. But, eventually, the Open Web Platform will -continue to evolve into a powerful, useful platform supporting applications that -are [secure, linkable, indexable, composable, and -ephemeral](https://paul.kinlan.me/slice-the-web/). Yes, SWs make web apps -somewhat less ephemeral, but we believe the increased applicability of the OWP -is worth it. - -Browser vendors are committed to ensuring the security of the OWP improves even -as we give it new capabilities. This process happens in the open, in fora like -[W3C Technical Architecture Group](https://www.w3.org/2001/tag/), [W3C’s Web -Platform Incubator Community Group](https://www.w3.org/blog/2015/07/wicg/), and -[blink-dev@chromium.org](https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev). -Security and privacy reviews are part of the process and we invite knowledgeable -experts to participate in those open fora. - -#### What are some SW best practices for site operators? - - [Build a kill-switch - SW](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776). - - Use [Clear-Site-Data](https://www.w3.org/TR/clear-site-data/) when it - becomes available. - - Be aware of the need for longer session lifetimes, since clients may go - offline and SWs might need to POST cached requests after coming back online. - [Here is one way to handle - that](https://developers.google.com/web/updates/2016/06/2-cookie-handoff). - -#### What SW bugs would quality for a bounty under [Chrome’s VRP](/Home/chromium-security/vulnerability-rewards-program)? - -If you could break one or more of the security assertions we make in this FAQ, -that would be potentially rewardable under the Vulnerability Rewards Program -(VRP). Here is a non-exhaustive list of examples: - - Over-long registration/lifetime (e.g. a SW able to run or stay alive even - without incoming events to handle) - - Same-origin bypass or off-origin SW registration - - Access to APIs that require prompts, choosers, or permissions, without - permission having been granted to the origin - - Geolocation - - Hardware sensors - - Microphone, camera, media devices - - USB, Bluetooth - -Here is [a list of historical SW security -bugs](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=Type%3DBug-Security+serviceworker&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids) -in Chromium’s bug tracker. - -If you believe you have found a bug in the SW specification, please [file a new -Chromium bug using the Security -template](https://bugs.chromium.org/p/chromium/issues/entry?template=Security%20Bug). -It’s a good idea to file bugs with all browser vendors that implement the buggy -section of the spec. - -If you believe you have found a bug in Chrome’s implementation of SW, please -[file a new bug using the Security -template](https://bugs.chromium.org/p/chromium/issues/entry?template=Security%20Bug). -The Chrome Security Team will triage it within 1 or 2 business days. Good bug -reports come with minimal test cases that demonstrate the problem!
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-labels/index.md b/chromium/docs/website/site/Home/chromium-security/security-labels/index.md deleted file mode 100644 index b2ab4a36a6e..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-labels/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-labels -title: Security labels/components ---- - -Please see -[security-labels.md](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/security-labels.md).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-release-management/index.md b/chromium/docs/website/site/Home/chromium-security/security-release-management/index.md deleted file mode 100644 index c85bfbd8e7b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-release-management/index.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-release-management -title: Security Release Management ---- - -## **[TOC]** - -## **Merging Fixes** - -Engineers outside the Chrome Security team shouldn’t request merges for security -fixes. Instead, please [mark the bug as -Fixed](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/security-labels.md#TOC-Merge-labels) -and we’ll take care of it. The instructions below are for the Chrome Security -team itself. - -### **TODO(chrome-security@): Identifying fixes to merge.** - -Security fixes often need to be merged to the Stable or Beta branch. One of the -key considerations in picking a fix to merge is assessing the risk of breakage, -which the bug’s owner should be able to convey. For risky fixes you should -consider bumping it to a later milestone. Generally, you should consider merging -the following: - -* [Critical or High severity bugs](/developers/severity-guidelines) -* [Medium severity bugs](/developers/severity-guidelines) if they're - particularly worrisome (e.g. info leak) or have significant - non-security impact (e.g. top crasher). -* [Low severity bugs](/developers/severity-guidelines) where the fixes - are very low risk. - -For Critical and High bugs, we aim to fix users fast and work directly with -Chrome TPMs to make sure any merge or release is done safely. The following are -general recommendations on when / where to merge: - -* ==Released Critical vulnerability==: Emergency, out of band release, - target a fix as soon as we have a viable release candidate. -* ==Unreleased Critical vulnerability==: Target a fix for the next - scheduled Stable point release. (An exception here is if we know it - will be released prior to the next scheduled release, then we push - as fast as needed to address it). -* ==Released High vulnerability==: A fix should be merged to the next - scheduled Stable point release. -* ==Unreleased High (and lower severity) vulnerability==: Target the - merge to the next scheduled Stable milestone release. - -Other factors to consider in your merge vs. no-merge calculation are: - -* **Bake time**. If a fix has been landed on trunk for weeks and made - it into various dev channels with no observed screaming, a merge - candidate is said to be "well baked". A well baked patch might be - considered for merge even if it is of lower severity, or appears - scary. Conversely, we should rarely be merging anything that hasn't - landed for a few days and been released to a dev channel. -* **Ease of discovery**. If a bug has been found independently by - multiple efforts (e.g. an external researcher as well as ClusterFuzz - internally), this suggests that the bug is readily discoverable and - should be merged sooner rather than later. -* **Ease of merge**. If the merge is a total nightmare, it may be fair - to not merge the fix and just wait for the fix on trunk to "roll - into stable", as all work on trunk eventually does. Of course, if - the bug is critical or other factors (ease of discovery, highly - exploitable, etc.) apply, then we should bite the bullet and - undertake the extra work in order to best protect users. -* **Change of behavior**. If the fix in fact changes behavior (locks - something down, turns something off, etc.) then it is best to have - the fix appear as a major revision bump as opposed to a patch on the - stable channel. This doesn't mean "don't merge" but it does suggest - we might merge to beta but not the existing stable. - -Your worklist for merges is defined by the following bug database criteria: - -* All Issues -* Type-Bug-Security -* Merge=Request,Review - -(Note: beware of querying on the milestone. At this stage in the bug's life, the -milestone label represents the earliest affected release at the time the bug was -filed. So if current stable is M27, there might still be bugs in this list which -are M25, M26, etc., if we've been a little slow in fixing them. Conversely, -anything marked M28 denotes a regression since M27 stable, so it only needs to -be merged to the M28 beta.) - -### **TODO(bug owner): Merging a security patch.** - -When a security merge has been approved, please go ahead and merge. - -To avoid accidentally losing a fix for a Chrome release, branch merges should be -done in a "newer first" manner. For example, if you're merging a fix to M27 -stable and M28 is branched and affected, then merge to M28 first. Such a -strategy can also be used to bake a fix on the M28 branch in order to gain -confidence about an M27 stable channel merge. - -#### **How to merge** - -You should merge fixes with [gerrit](/developers/how-tos/drover), which -automates most of the process. If the [gerrit merge](/developers/how-tos/drover) -does not apply cleanly you may want to reconsider whether the fix will introduce -an unacceptable breakage risk. In the event that you can’t use gerrit to merge a -fix, you still have the option of manually merging from a branch checkout. This -follows the normal developer [normal patch -process](/developers/contributing-code). - -#### **Post-merge bug cleanup.** - -Once the fix is successfully merged you will need to: - -1. Update the bug with the merge revision numbers (one for each branch - you've merged to). -2. Set the merge status to Merge-Approved to Merge-Merged (if drover - didn't do so). - -**Release Notes** - -For every new release, we include notes from security bugs that match the -following search criteria: - -* Type=Bug-Security -* M=? (Milestone) -* Release-x-Myy -* -Security_Severity=None -* Security_Impact=Stable - -For example, [this -link](https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DBug-Security+M%3D26+Release%3D0+-Security_Severity%3DNone+-OS%3DChrome+-OS%3DAndroid&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -shows the security fixes that went into the initial Beta -> Stable promotion -of Chrome 26, and [this -link](https://code.google.com/p/chromium/issues/list?can=1&q=Type%3DBug-Security+M%3D24+Release%3D1+-Security_Severity%3DNone+-OS%3DChrome+-OS%3DAndroid&colspec=ID+Pri+M+Iteration+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles) -shows the security fixes that went into the first post-stable patch of the -Chrome 24 branch. - -Every externally reported issue gets assigned a CVE ID per MITRE's [CVE Counting -Rules](https://cve.mitre.org/cve/editorial_policies/counting_rules.html). -Chrome's CVE pool is -[here](https://docs.google.com/a/google.com/spreadsheet/ccc?key=0AoQyc9BFHd9FdE43bkxKZFRtOEk3eW5zeEhST29zTmc#gid=0) -(Google internal-only link, sorry). As of Chrome 27, we're focusing the release -notes on externally reported issues. This mirrors how Mozilla Firefox arranges -their release notes, saves the precious resource of CVEs, saves a lot of time in -preparing release notes, and appropriately focuses our security release notes on -the excellent contributions and rewards of external researchers. - -CVEs are allocated when the stable release that contains the fix is released, -and they are then placed into the bug tracker using the CVE label, and copied -into the release notes. An example of how it looks is [here for the Chrome 27 -release -notes](http://googlechromereleases.blogspot.com/2013/05/stable-channel-release.html). - -### **security-notify@chromium.org** - -There is no longer any need to pre-notify security-notify@chromium.org with a -copy of release notes. Very few list members were finding it useful or -actionable.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-reviews/index.md b/chromium/docs/website/site/Home/chromium-security/security-reviews/index.md deleted file mode 100644 index d3ce166a507..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-reviews/index.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-reviews -title: Chrome Security Reviews ---- - -All launches and major changes to Chrome undergo a security review. - -Please note that filing a launch bug requires an @google.com account. For -non-Google/open source contributors, find a Google PM who can help you with your -launch. (If you don't know whom to ask, ask on chromium-dev@chromium.org). - -The Chrome Security Team used to ask engineers and PMs to provide the same -information over and over again for incremental launches. We also had a hard -time keeping on top of incremental changes and we weren't really using the -cumulative review data to give us insight into the ongoing engineering practices -across Chrome. - -This process aims to address these issues and make the review process simpler -and faster for everyone. If you have further questions, ping adetaylor@. - -## How does the security review process work? - -The full story is here: [New Chrome Security Review -Plan](https://docs.google.com/document/d/11bnI_H0_Hg_o1mILjjH28PHB98bpSC4STh_OXLwv1gA/edit). - -TL;DR: File a launch bug, and the security team will see it on their dashboard. -Make sure to link to a design document in the launch bug. The security -reviewer(s) will look to the design doc first, and will probably comment and ask -questions in the document. - -If your project is especially tricky or large, it's best to reach out to -security@chromium.org (for public stuff; preferable) or -chrome-security@google.com (for Google confidential stuff) well ahead of time. - -## FAQ - -#### Q: Why do we do security reviews? - -Great question, and thanks for asking it! Security reviews serve three main -purposes: - - Provides an opportunity to educate and advise on potential security issues. - Chrome is one of the hardest pieces of software in the world to secure: - millions of lines of security-critical code, rendering untrusted content - from all corners of the web, sitting on over 1 billion devices... that makes - it an attractive target for the bad guys! Everyone in Chrome is responsible - for security, and we're here to help point out and avoid security pitfalls. - - It’s a second pair of (expert) eyes looking for security holes. An attacker - needs to only find one security bug in your project to exploit, while you - have the job of defending your entire codebase. Not fair, right? We want an - engineer on Chrome to look over your project with an eye on security, before - someone with different motives takes a look when the project lands. - - Gives the security team an overview of what is happening in Chrome. Good - security advice is tailored to a team, but great security advice also - considers the strategic direction of the entire product area. When we can - keep tabs on developments and product trajectories across teams, it - (hopefully) allows us to provide meaningful advice and recommendations, - sometimes even before you approach us and ask for it! - -#### Q: Is there anything security reviews are NOT? - -Unfortunately, security reviews don’t mean that you can stop caring about -security. Your team is still accountable and responsible for ensuring that your -code is free of security bugs. Security reviews won’t catch all bugs, but they -certainly do help to make sure your security practices are sound. - -#### Q: Are Chrome and Chrome OS using the same security review process? - -Yes, but with one important difference: for Chrome OS, kerrnel@ is the main -point of contact. To file a Chrome OS feature survey, please follow the steps at -go/cros-security-review. - -#### Q: I have other questions. How can I get in contact? - -The best address for us is security@chromium.org, or if you’re a Googler you can -reach us at chrome-security@google.com for Chrome stuff, -chromeos-security@google.com for Chrome OS stuff.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (1).png.sha1 b/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (1).png.sha1 deleted file mode 100644 index c6a66c0cd85..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (1).png.sha1 +++ /dev/null @@ -1 +0,0 @@ -32118b68b5ad4afe076287b5df689fbce052a122
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (2).png.sha1 b/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (2).png.sha1 deleted file mode 100644 index f6d7ae4aeb6..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (2).png.sha1 +++ /dev/null @@ -1 +0,0 @@ -60af70776d7c99f008418434ce035c4d686584c6
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (3).png.sha1 b/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (3).png.sha1 deleted file mode 100644 index b83274fa097..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue (3).png.sha1 +++ /dev/null @@ -1 +0,0 @@ -c3934652eac2e21e4eb20872cc71838828b01255
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue.png.sha1 b/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue.png.sha1 deleted file mode 100644 index 86f5cb457c0..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Life of a Security Issue.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -20d867a7595911beeb2c456cfd76649b5e4418bd
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Screen Shot 2016-05-20 at 15.41.22.png.sha1 b/chromium/docs/website/site/Home/chromium-security/security-sheriff/Screen Shot 2016-05-20 at 15.41.22.png.sha1 deleted file mode 100644 index fee823d5b8d..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/Screen Shot 2016-05-20 at 15.41.22.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -b855ec7ad24d2f8ed5c1eba131b58b041403a081
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/security-sheriff/index.md b/chromium/docs/website/site/Home/chromium-security/security-sheriff/index.md deleted file mode 100644 index 57a66a4da2b..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/security-sheriff/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: security-sheriff -title: Security Sheriff ---- - -The [canonical version of this document is now in the Chromium source -tree](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/sheriff.md).
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/site-isolation/OWNERS b/chromium/docs/website/site/Home/chromium-security/site-isolation/OWNERS deleted file mode 100644 index bccc55526a4..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/site-isolation/OWNERS +++ /dev/null @@ -1,3 +0,0 @@ -alexmos@chromium.org -creis@chromium.org -nasko@chromium.org diff --git a/chromium/docs/website/site/Home/chromium-security/site-isolation/index.md b/chromium/docs/website/site/Home/chromium-security/site-isolation/index.md deleted file mode 100644 index b6f3b6ae035..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/site-isolation/index.md +++ /dev/null @@ -1,377 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: site-isolation -title: Site Isolation ---- - -## Overview - -Site Isolation is a security feature in Chrome that offers additional protection -against some types of security bugs. It uses Chrome's sandbox to make it harder -for untrustworthy websites to access or steal information from your accounts on -other websites. - -Websites are typically not allowed to access each other's data inside the -browser, thanks to code that enforces the Same Origin Policy. Occasionally, -security bugs are found in this code and malicious websites may try to bypass -these rules to attack other websites. The Chrome team aims to fix such bugs as -quickly as possible. - -Site Isolation offers an extra line of defense to make such attacks less likely -to succeed. It ensures that pages from different websites are always put into -different processes, each running in a sandbox that limits what the process is -allowed to do. It also makes it possible to block the process from receiving -most types of sensitive data from other sites. As a result, a malicious website -will find it much more difficult to steal data from other sites, even if it can -break some of the rules in its own process. - -This protection is made possible by the following changes in Chrome's behavior: - -* Cross-site documents are always put into a different process, - whether the navigation is in the current tab, a new tab, or an - iframe (i.e., one web page embedded inside another). Note that only - a subset of sites are isolated on Android, to reduce overhead. -* Cross-site data (such as HTML, XML, JSON, and PDF files) is not - delivered to a web page's process unless the server says it should - be allowed (using [CORS](https://www.w3.org/TR/cors/)). -* Security checks in the browser process can detect and terminate a - misbehaving renderer process (only on desktop platforms for the time - being). - -Here, we use a precise definition for a **site**: the scheme and registered -domain name, including the public suffix, but ignoring subdomains, port, or -path. For example, an origin like https://foo.example.com:8080 would have a site -of https://example.com. We use sites instead of origins to avoid breaking -compatibility with existing web pages that might modify their document.domain to -communicate across multiple subdomains of a site. - -For more technical information about the protections offered by Site Isolation -and how they are built, please see the [project's design -document](/developers/design-documents/site-isolation). - -[TOC] - -## Motivation - -Web browser security is important: browsers must defend against untrustworthy -web pages that try to attack other sites or access the user's machine. Given the -complexity of the browser, it is necessary to use a "defense in depth" approach -to limit the damage that occurs even if an attacker finds a way around the Same -Origin Policy or other security logic in the browser. As a result, Chrome uses a -sandbox and Site Isolation to try to defend against even powerful attackers -(e.g., who might know about bugs in the browser). This is motivated by several -different types of attacks. - -First, compromised renderer processes (also known as "arbitrary code execution" -attacks in the renderer process) need to be explicitly included in a browser’s -security threat model. We assume that determined attackers will be able to find -a way to compromise a renderer process, for several reasons: - -* Past experience suggests that potentially exploitable bugs will be - present in future Chrome releases. There were [10 potentially - exploitable bugs in renderer components in - M69](https://bugs.chromium.org/p/chromium/issues/list?can=1&q=Release%3D0-M69%2C1-M69%2C2-M69%2C3-M69+Type%3DBug-Security+Security_Severity%3DHigh%2CCritical+-status%3ADuplicate+label%3Aallpublic+component%3ABlink%2CInternals%3ECompositing%2CInternals%3EImages%3ECodecs%2CInternals%3EMedia%2CInternals%3ESkia%2CInternals%3EWebRTC%2C+-component%3ABlink%3EMedia%3EPictureInPicture%2CBlink%3EPayments%2CBlink%3EStorage%2CInternals%3ECore%2CInternals%3EPrinting%2CInternals%3EStorage%2CMojo%2CServices%3ESync%2CUI%3EBrowser&sort=m&groupby=&colspec=ID+Status+CVE+Security_Severity+Security_Impact+Component+Summary), - [5 in - M70](https://bugs.chromium.org/p/chromium/issues/list?sort=m&groupby=&colspec=ID%20Status%20CVE%20Security_Severity%20Security_Impact%20Component%20Summary&q=Release%3D0-M70%2C1-M70%2C2-M70%2C3-M70%20Type%3DBug-Security%20Security_Severity%3DHigh%2CCritical%20-status%3ADuplicate%20label%3Aallpublic%20component%3ABlink%2CInternals%3ECompositing%2CInternals%3EImages%3ECodecs%2CInternals%3EMedia%2CInternals%3ESkia%2CInternals%3EWebRTC%2C%20-component%3ABlink%3EMedia%3EPictureInPicture%2CBlink%3EPayments%2CBlink%3EStorage%2CInternals%3ECore%2CInternals%3EPrinting%2CInternals%3EStorage%2CMojo%2CServices%3ESync%2CUI%3EBrowser&can=1), - [13 in - M71](https://bugs.chromium.org/p/chromium/issues/list?sort=m&groupby=&colspec=ID%20Status%20CVE%20Security_Severity%20Security_Impact%20Component%20Summary&q=Release%3D0-M71%2C1-M71%2C2-M71%2C3-M71%20Type%3DBug-Security%20Security_Severity%3DHigh%2CCritical%20-status%3ADuplicate%20label%3Aallpublic%20component%3ABlink%2CInternals%3ECompositing%2CInternals%3EImages%3ECodecs%2CInternals%3EMedia%2CInternals%3ESkia%2CInternals%3EWebRTC%2C%20-component%3ABlink%3EMedia%3EPictureInPicture%2CBlink%3EPayments%2CBlink%3EStorage%2CInternals%3ECore%2CInternals%3EPrinting%2CInternals%3EStorage%2CMojo%2CServices%3ESync%2CUI%3EBrowser&can=1), - [13 in - M72](https://bugs.chromium.org/p/chromium/issues/list?sort=m&groupby=&colspec=ID%20Status%20CVE%20Security_Severity%20Security_Impact%20Component%20Summary&q=Release%3D0-M72%2C1-M72%2C2-M72%2C3-M72%20Type%3DBug-Security%20Security_Severity%3DHigh%2CCritical%20-status%3ADuplicate%20label%3Aallpublic%20component%3ABlink%2CInternals%3ECompositing%2CInternals%3EImages%3ECodecs%2CInternals%3EMedia%2CInternals%3ESkia%2CInternals%3EWebRTC%2C%20-component%3ABlink%3EMedia%3EPictureInPicture%2CBlink%3EPayments%2CBlink%3EStorage%2CInternals%3ECore%2CInternals%3EPrinting%2CInternals%3EStorage%2CMojo%2CServices%3ESync%2CUI%3EBrowser&can=1), - [15 in - M73](https://bugs.chromium.org/p/chromium/issues/list?sort=m&groupby=&colspec=ID%20Status%20CVE%20Security_Severity%20Security_Impact%20Component%20Summary&q=Release%3D0-M73%2C1-M73%2C2-M73%2C3-M73%20Type%3DBug-Security%20Security_Severity%3DHigh%2CCritical%20-status%3ADuplicate%20label%3Aallpublic%20component%3ABlink%2CInternals%3ECompositing%2CInternals%3EImages%3ECodecs%2CInternals%3EMedia%2CInternals%3ESkia%2CInternals%3EWebRTC%2C%20-component%3ABlink%3EMedia%3EPictureInPicture%2CBlink%3EPayments%2CBlink%3EStorage%2CInternals%3ECore%2CInternals%3EPrinting%2CInternals%3EStorage%2CMojo%2CServices%3ESync%2CUI%3EBrowser&can=1). - This volume of bugs holds steady despite years of investment into - developer education, fuzzing, Vulnerability Reward Programs, etc. - Note that this only includes bugs that are reported to us or are - found by our team. -* Security bugs can often be made exploitable: even 1-byte buffer - overruns [can be turned into an - exploit](https://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html). -* Deployed mitigations (like - [ASLR](http://en.wikipedia.org/wiki/Address_space_layout_randomization) - or [DEP](http://en.wikipedia.org/wiki/Data_Execution_Prevention)) - are [not always - effective](https://googleprojectzero.blogspot.com/2019/04/virtually-unlimited-memory-escaping.html). - -Second, universal cross-site scripting (UXSS) bugs pose a similar threat. -Security bugs of this form would normally let an attacker bypass the Same Origin -Policy within the renderer process, though they don't give the attacker complete -control over the process. Such UXSS bugs tend to be -[common](https://ai.google/research/pubs/pub48028). - -Third, side channel attacks such as [Spectre](https://spectreattack.com/) make -reading arbitrary renderer process memory possible, even without bugs in Chrome. -This poses additional risks to sensitive data in the renderer process, and it -can make exploitation easier. - -Chrome's architecture provides additional defenses against these powerful -attacks. Chrome's -[sandbox](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md) -helps prevent a compromised renderer process from being able to access arbitrary -local resources (e.g. files, devices). Site Isolation helps protect websites -against attacks from compromised renderer processes, UXSS, and side-channel -attacks like Spectre. - -For more background and motivation, see our [Usenix Security 2019 conference -paper](https://www.usenix.org/conference/usenixsecurity19/presentation/reis) on -Site Isolation, and Chrome's [Post-Spectre Threat Model -Re-Think](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/side-channel-threat-model.md). - -## Current Status - -#### Desktop Platforms - -Site Isolation was [enabled by -default](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) -for all sites in Chrome 67 on Windows, Mac, Linux, and Chrome OS to help to -defend against attacks that are able to read otherwise inaccessible data within -a process, such as [speculative side-channel attack -techniques](https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) -like Spectre/Meltdown. As of Chrome 77, Site Isolation also now defends against -fully compromised renderer processes and UXSS bugs on desktop platforms. In M92, -Site Isolation expanded to isolate all extensions from each other as well. - -#### Android - -On Android devices with at least 2 GB of RAM, Site Isolation has been enabled -for sites that users log into since Chrome 77. In Chrome 92, this expanded to -include sites that use third-party login providers (e.g., OAuth) and sites that -adopt Cross-Origin-Opener-Policy headers. - -## Related Blog Posts - -* [Improving extension security with out-of-process - iframes](https://blog.chromium.org/2017/05/improving-extension-security-with-out.html) - \- May 2017 -* [Mitigating Spectre with Site Isolation in - Chrome](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) - \- July 2018 -* [Improving Site Isolation for Stronger Browser - Security](https://security.googleblog.com/2019/10/improving-site-isolation-for-stronger.html) - / [Recent Site Isolation - improvements](https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html) - \- October 2019 -* [Mitigating Side-Channel - Attacks](https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html) - / [A Spectre proof-of-concept for a Spectre-proof - web](https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html) - \- March 2021 -* [Protecting more with Site - Isolation](https://security.googleblog.com/2021/07/protecting-more-with-site-isolation.html) - / [Privacy and performance, working together in - Chrome](https://blog.google/products/chrome/privacy-and-performance-working-together-chrome/) - \- July 2021 - -## Limitations - -* **Sites vs Origins**: Compatibility with document.domain changes - currently requires us to use sites (e.g., https://example.com) - rather than origins (e.g., https://foo.example.com) for defining - process boundaries. This allows multiple origins within a site to - share the same process. -* **Filtering cross-site data**: Cross-Origin Read Blocking (CORB) is - a best effort approach that tries to protect as much sensitive - content as possible, but it is limited by the need to preserve - compatibility with incorrectly labeled resources (e.g., JavaScript - files labeled as HTML). -* **Unavailable in some settings**: Site Isolation is not yet - supported in Android WebView, or on Chrome for Android devices with - less than 2GB of RAM, or in the <webview> tags used in Chrome - Apps. - -## Tradeoffs - -Site Isolation represents a major architecture change for Chrome, so there are -some tradeoffs when enabling it, such as increased memory overhead. The team has -worked hard to minimize this overhead and fix as many functional issues as -possible. A few known issues remain: - -For users: - -* Higher overall memory use in Chrome. On desktop in Chrome 67, this - is about 10-13% when isolating all sites with many tabs open. On - Android in Chrome 77, this is about 3-5% overhead when isolating - sites that users log into. - -For web developers: - -* Full-page layout is no longer synchronous, since the frames of a - page may be spread across multiple processes. This may affect pages - that change the size of a frame and then send a postMessage to it, - since the receiving frame may not yet know its new size when - receiving the message. One workaround is to send the new size in the - postMessage itself if the receiving frame needs it. As of Chrome 68, - pages can also work around this by forcing a layout in the sending - frame before sending the postMessage. See [Site Isolation for web - developers](https://developers.google.com/web/updates/2018/07/site-isolation) - for more details. -* Unload handlers may not always run when the tab is closed. - postMessage might not work from an unload handler - ([964950](https://crbug.com/964950)). -* When debugging with `--disable-web-security`, it may also be necessary - to disable Site Isolation (using - `--disable-features=IsolateOrigins,site-per-process`) to access - cross-origin frames. - -## How to Configure - -For most users, no action is required, and Site Isolation is enabled at an -appropriate level based on available resources. - -For more advanced cases, it is possible to isolate additional sites and origins -in a few ways. Note that changes to chrome://flags and the command line only -affect the current device, and are not synced to your other instances of Chrome. - -### 1) Isolating All Sites (Android) - -This mode is already enabled by default for 100% of Chrome users on Windows, -Mac, Linux, and Chrome OS. The instructions below can still be useful on -Android, for users desiring the highest security on devices with sufficient RAM. - -This mode ensures that all sites are put into dedicated processes that are not -shared with other sites. It can be enabled in either of the following ways: - -* Visit chrome://flags#enable-site-per-process, click Enable, and - restart. (See also: [help center - article](https://support.google.com/chrome/answer/7623121). Note - that this flag is only present on Android. It is missing on other - platforms, where it is already enabled by default.) - -  - -* Or, use an [Enterprise - Policy](https://support.google.com/chrome/a/answer/7581529) to - enable - [SitePerProcess](/administrators/policy-list-3#SitePerProcess) or - [SitePerProcessAndroid](/administrators/policy-list-3#SitePerProcessAndroid) - within your organization. - -### 2) Isolating Specific Origins - -This mode allows you to provide a list of specific origins that will be given -dedicated processes. On desktop platforms where Site Isolation is already fully -enabled, these origins will be isolated at a finer granularity than their site -(e.g., https://foo.example.com can be isolated from the rest of -https://example.com). On Android, these origins will be isolated in addition to -any other sites already isolated. This can be used to isolate any origins that -need extra protection, such as any that you log into. (Note that wildcards are -supported to isolate all origins underneath a given origin.) - -This mode is automatically enabled on Android devices with at least 2 GB of -memory as of Chrome 77, for sites that users log into. This mode can be further -manually configured in any of the following ways: - -* In Chrome 77 or later versions: Enable - chrome://flags/#isolate-origins, provide the list of origins to - isolate (e.g. - "https://foo.example.com,https://[*.]corp.example.com"), and - restart Chrome. - -* Use [command line flags](/for-testers/command-line-flags) to start - Chrome with `--isolate-origins` followed by a comma-separated list of - origins to isolate. For example: - `--isolate-origins=https://foo.example.com,https://[*.]corp.example.com` - Be careful not to include effective top-level domains (e.g., https://co.uk - or https://appspot.com; see the full list at <https://publicsuffix.org>), - because these will be ignored. -* Or, use an [Enterprise - Policy](https://support.google.com/chrome/a/answer/7581529) to - enable - [IsolateOrigins](https://chromeenterprise.google/policies/#IsolateOrigins) - or - [IsolateOriginsAndroid](https://chromeenterprise.google/policies/#IsolateOriginsAndroid) - within your organization. - -### **3) Isolating All Origins** - -This mode is experimental and will break any pages that depend on modifying -document.domain to access a cross-origin but same-site page. It will also -increase Chrome's process count and may affect performance. The benefit is that -every origin will require its own dedicated process, such that two origins from -the same site won't share a process. - -This mode can be configured by enabling chrome://flags#strict-origin-isolation - -### Diagnosing Issues - -If you encounter problems when Site Isolation is enabled, you can try turning it -off by undoing the steps above, to see if the problem goes away. - -You can also try opting out of field trials of Site Isolation to diagnose bugs, -by visiting chrome://flags#site-isolation-trial-opt-out, choosing "Disabled (not -recommended)," and restarting. - - - -Starting Chrome with the `--disable-site-isolation-trials` flag is equivalent to -the opt-out above. - -Note that if Site Isolation has been enabled by enterprise policy, then none of -these options can be used to disable it. - -We encourage you to [file bugs](https://goo.gl/XBoKtY) if you encounter problems -when using Site Isolation that go away when disabling it. In the bug report, -please describe the problem and mention whether it is specific to having Site -Isolation enabled. - -### Verifying - -You can visit chrome://process-internals to see whether a Site Isolation mode is -enabled. - -If you would like to test that Site Isolation has been successfully turned on in -practice, you can follow the steps below: - -1. Navigate to a website that has cross-site subframes. For example: - * Navigate to - <http://csreis.github.io/tests/cross-site-iframe.html>. - * Click the "Go cross-site (complex page)" button. - * The main page will now be on the http://csreis.github.io site - and the subframe will be on the https://chromium.org site. -2. Open Chrome's Task Manager: Chrome Menu -> More tools -> Task - manager (Shift+Esc). -3. Verify that the main page and the subframe are listed in separate - rows associated with different processes. For example: - * Tab: creis.github.io/tests/cross-site-iframe.html - Process ID = 1234 - * Subframe: https://chromium.org - Process ID = 5678 - -If you see the subframe process in Chrome's Task Manager, then Site Isolation is -correctly enabled. These steps work when using the "Isolating all sites" -approach above (e.g., --site-per-process). They also work when using the -"Isolating certain sites" approach above (e.g., --isolate-origins), as long as -the list of origins provided includes either http://csreis.github.io or -https://chromium.org. - -## Recommendations for Web Developers - -Site Isolation can help protect sensitive data on your website, but only if -Chrome can distinguish it from other resources which any site is allowed to -request (e.g., images, scripts, etc.). Chrome currently tries to identify URLs -that contain HTML, XML, JSON, and PDF files, based on MIME type and other HTTP -headers. See [Cross-Origin Read Blocking for Web -Developers](/Home/chromium-security/corb-for-developers) for information on how -to ensure that sensitive information on your website will be protected by Site -Isolation. - -**We strongly recommend following the guidelines in [Post-Spectre Web -Development](https://www.w3.org/TR/post-spectre-webdev/) to protect content**, -which can help in browsers with and without Site Isolation support. The -[Mitigating Side-Channel -Attacks](https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html) -blog post provides a good overview of these mechanisms and how they help. For -example, using HTTP response headers such as -[Cross-Origin-Resource-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) -and -[Cross-Origin-Opener-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) -can help control which process a resource can load in. Consider also inspecting -the [Sec-Fetch-](https://w3c.github.io/webappsec-fetch-metadata/) request -headers in the HTTP server to identify the source of the request before deciding -how to handle a request. - -See also [Site Isolation for web -developers](https://developers.google.com/web/updates/2018/07/site-isolation) -for more discussion of how Site Isolation can protect web page content and in -which cases it might affect page behavior. diff --git a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-1.png.sha1 b/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-1.png.sha1 deleted file mode 100644 index ecdfc881ca9..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-1.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -bef7d27bc0f2815d8e2c617110d025311e54013a
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-2.png.sha1 b/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-2.png.sha1 deleted file mode 100644 index 9021077c687..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-isolation-flag-2.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -435a10332929ba379951a727f1a8e27661b6cb6f
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-per-process-flag.png.sha1 b/chromium/docs/website/site/Home/chromium-security/site-isolation/site-per-process-flag.png.sha1 deleted file mode 100644 index 94f00435edb..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/site-isolation/site-per-process-flag.png.sha1 +++ /dev/null @@ -1 +0,0 @@ -f7db07cfc74ede5b89d96e6350d732c699b51348
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/ssca/index.md b/chromium/docs/website/site/Home/chromium-security/ssca/index.md deleted file mode 100644 index 2f6003cc48e..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/ssca/index.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: ssca -title: Mitigating Side-Channel Attacks ---- - -At the beginning of 2018, researchers from Google's [Project -Zero](https://googleprojectzero.blogspot.com/2014/07/announcing-project-zero.html) -[disclosed](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html) -a series of new attack techniques against speculative execution optimizations -used by modern CPUs. Security researchers will continue to find new variations -of these and other side-channel attacks. Such techniques have implications for -products and services that execute third-party code, including Chrome and other -browsers with support for features like JavaScript and WebAssembly. - -The Chrome Security Team has written [a document covering the variety of defense -techniques -available](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/side-channel-threat-model.md). - -**Protecting users with Site Isolation** - -Chrome has been working on a feature called [Site -Isolation](/Home/chromium-security/site-isolation) which provides extensive -mitigation against exploitation of these types of vulnerabilities. With Site -Isolation enabled, the amount of data exposed to side-channel attacks is reduced -as Chrome renders content for each website in a separate process. This allows -websites to be protected from each other by the security guarantees provided by -the operating system on which Chrome is running. - -Site Isolation is enabled by default on Windows, Mac, Linux, and Chrome OS since -Chrome 67, and can also can be controlled [via enterprise -policies](https://support.google.com/chrome/a/answer/7581529) or [with -chrome://flags](https://support.google.com/chrome/answer/7623121). More details -can be found in our blog post [Mitigating Spectre with Site Isolation in -Chrome](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html). - -Site Isolation is most effective when website developers follow modern security -best practices: - - Where possible cookies should use - [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7) - and[ HTTPOnly](https://www.owasp.org/index.php/HttpOnly) attributes and - pages should avoid reading from document.cookie. - - Make sure [MIME types are - correct](/Home/chromium-security/site-isolation#TOC-Recommendations-for-Web-Developers) - and specify an X-Content-Type-Options: nosniff response header for any URLs - with user-specific or sensitive content, to take full advantage of - [Cross-Origin Read - Blocking](https://chromium.googlesource.com/chromium/src/+/HEAD/services/network/cross_origin_read_blocking_explainer.md) - (CORB). - -Web developers should also see the [Meltdown/Spectre -WebFundamentals](https://developers.google.com/web/updates/2018/02/meltdown-spectre) -post. - -Spectre and Meltdown - -The attacks known as [Spectre and Meltdown](https://meltdownattack.com/), -originally -[disclosed](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html) -by Project Zero, have implications for Chrome. For information about other -Google products and services, including Chrome OS please see the [Google Online -Security -Blog](https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html). - -These attacks are mitigated by Site Isolation. Additionally, staring in Chrome -64, Chrome's JavaScript engine [V8](https://www.v8project.org/) has included -[further mitigations](https://github.com/v8/v8/wiki/Untrusted-code-mitigations) -which provide protection on platforms where Site Isolation is not enabled. - -In line with -[other](https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/) -[browsers'](https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/) -response to Spectre and Meltdown, Chrome disabled[ -SharedArrayBuffer](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer) -in Chrome 63 starting on Jan 5th 2018, and modified the behavior of other APIs -such as performance.now to help reduce the efficacy of side-channel attacks. - -SharedArrayBuffer is now re-enabled in Chrome versions where Site Isolation is -on by default. - -GLitch - -Researchers from Vrije Universiteit Amsterdam disclosed -[details](https://www.vusec.net/wp-content/uploads/2018/05/glitch.pdf) of the -GLitch attack. Part of the attack uses high-precision GPU timers available in -WebGL to obtain information that is then used to perform a -[Rowhammer-style](https://en.wikipedia.org/wiki/Row_hammer) bit-flip attack. - -Starting in Chrome 65, the -[EXT_disjoint_timer_query](https://developer.mozilla.org/en-US/docs/Web/API/EXT_disjoint_timer_query) -and EXT_disjoint_timer_query_webgl2 WebGL extensions have been disabled, and the -behaviour of clientWaitSync and other \*Sync functions has been changed to -reduce their effective precision as clocks. - -Although the GLitch attack is unrelated to Spectre and Meltdown, -EXT_disjoint_timer_query and EXT_disjoint_timer_query_webgl2 could also be used -to mount Spectre and Meltdown attacks. Accordingly, they will remain disabled in -Chrome until Site Isolation is on by default, at which point they will be -re-enabled with sufficiently reduced precision to mitigate GLitch attacks. - -Also see [more -details](http://www.chromium.org/chromium-os/glitch-vulnerability-status) about -GLitch and Chrome OS.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/strict-origin-isolation-trial/index.md b/chromium/docs/website/site/Home/chromium-security/strict-origin-isolation-trial/index.md deleted file mode 100644 index 6006b060ffd..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/strict-origin-isolation-trial/index.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: strict-origin-isolation-trial -title: Strict Origin Isolation Trial ---- - -tl;dr This page describes a desktop Canary-only field trial to study the effect -of isolating pages by origin (as opposed to the current [Site -Isolation](/Home/chromium-security/site-isolation) approach using sites) on -Chrome's performance. The trial will be one week in duration, starting around -May 23rd, 2019. Some pages, such as those that rely on setting document.domain -to perform cross-origin scripting, may encounter issues during this trial. - -Tracking Issue: <https://crbug.com/902399> “Evaluate feasibility of widespread -origin isolation” - -## Overview - -The Strict Origin Isolation Trial is a short-duration (one week) field trial -designed to gather preliminary data about the performance impact of changing the -granularity of isolation from site (protocol and eTLD+1) to origin (protocol, -host, and port). - -Strict Origin Isolation would improve security by ensuring different origins do -not share a process with each other, but it poses a risk of increased resource -usage. This study will allow us to study the expected impact on process count, -memory usage, and other performance metrics if all origins were isolated, -including potential performance benefits from increased parallelization. - -However, this trial also poses a functional risk to web pages that script -same-site but cross-origin frames, which is possible if the pages modify their -document.domain values via JavaScript. Such cross-origin scripting will be -disrupted if the documents are in different processes, resulting in JavaScript -errors visible in the DevTools console and potentially broken page features. - -<table> -<tr> - -<td>Sample cross-origin scripting error:</td> - -<td>On a page a.example.com with a subframe b.example.com, where both execute document.domain = ‘example.com’, and b.example.com attempts something like top.document.body.innertext, the following error occurs:</td> - -</tr> -<tr> - -<td>VM118:1 Uncaught DOMException: Blocked a frame with origin "https://b.example.com" from accessing a cross-origin frame.</td> - -<td> at <anonymous>:1:5</td> - -</tr> -</table> - -Because of this risk, we will limit this trial to a single week on only the -Canary channel, to avoid disruptions to users of the Dev, Beta, and Stable -channels. 50% of Canary channel users will be opted in to the Strict Origin -Isolation mode, while the remaining 50% will act as a control group using Site -Isolation. The trial will only affect Chrome versions 76.0.3791.0 and higher. - -## Trial Contact Information - -During the trial, if you need further information, please reach out to: - - [wjmaclean@chromium.org](mailto:wjmaclean@chromium.org) - - [site-isolation-dev@chromium.org](mailto:site-isolation-dev@chromium.org) - -## Disabling the Trial - -If you encounter issues during the trial, you can opt-out by running Chrome with ---disable-features=StrictOriginIsolation, or changing the -chrome://flags/#strict-origin-isolation flag from Default to Disabled. - -## Reporting Bugs - -If you experience incorrect behaviour during the trial, first check the -variations list in chrome://version to see if the variation for the trial -(0x4c825337 or 1283609399), is present. If so, and if the issue goes away when -disabling the trial (see above), please file a bug by clicking on [this -link](https://bugs.chromium.org/p/chromium/issues/entry?template=Defect+report+from+user&components=Internals%3ESandbox%3ESiteIsolation&blocking=902399&cc=wjmaclean@chromium.org&summary=Issue+during+Strict+Origin+Isolation+Trial:). - -## Recommended Developer Actions - -To avoid impact from the trial (and otherwise improve security), web developers -can avoid modifying document.domain to script cross-origin frames. - -## Summary - -Determining the feasibility of increasing Chromium’s isolation granularity from -sites to origins is important for improving security performance for our users. -This trial is a first step to better understand the implications, before -considering next steps.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/symantec-legacy-pki/index.md b/chromium/docs/website/site/Home/chromium-security/symantec-legacy-pki/index.md deleted file mode 100644 index d05a2b5c643..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/symantec-legacy-pki/index.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: symantec-legacy-pki -title: Symantec Legacy PKI ---- - -Following our -[announcement](https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html) -in September 2017 to distrust the Legacy Symantec PKI, Chrome has executed on -this plan in incremental phases across several releases. As described in detail -in previous announcements, this distrust is the result of a consensus of -cross-browser efforts to maintain a trusted and secure web. The phased distrust -of this PKI has been implemented as follows: - -<table> -<tr> - -<td>Release</td> - -<td>Description of Changes</td> - -</tr> -<tr> - -<td>Chrome 65</td> - -<td>Remove trust in certificates issued after December 1, 2017, effectively stopping trust in new issuance from the Legacy Symantec PKI.</td> - -</tr> -<tr> - -<td>Chrome 66</td> - -<td>Remove trust in certificates issued from the Legacy Symantec PKI before June 01, 2016, which were the most at-risk certificates based on the <a href="https://wiki.mozilla.org/CA:Symantec_Issues">numerous issues</a> identified by the Browser and Web PKI communities.</td> - -</tr> -<tr> - -<td>Chrome 70</td> - -<td>Remove trust in all certificates issued from the Legacy Symantec PKI. Trust will be removed via <a href="https://textslashplain.com/2017/10/18/chrome-field-trials/">staged rollout</a>.</td> - -</tr> -</table> - -We are approaching the final phase of distrust now that M70 is about to reach -Stable. The following describes Chrome’s behavior with respect to Legacy -Symantec TLS certificates across our various release channels. - -### Chrome 71 and beyond - -### Following the ramp-up to 100% of users in Chrome 70 Stable, Chrome 71 and beyond will be enabling the Legacy Symantec PKI distrust by default. This change is present in all release channels: Canary, Dev, Beta, and Stable. Users observing the distrust in Chrome 70 should experience the exact same behavior in Chrome 71 and up. - -### Chrome 70 Stable - -The distrust of the Legacy Symantec PKI is rolling out to users of Chrome -throughout the release of Chrome 70. At the initial release of Chrome 70, this -change will reach a small percentage of Chrome 70 users, and then slowly scaling -up to 100% of Chrome 70 users over several weeks. This approach seeks to -minimize any remaining breakage associated with this change while still -providing affected sites the ability to diagnose and take corrective action. - -Site Operators receiving problem reports from users are strongly encouraged to -take corrective action by replacing their website certificates as soon as -possible. Instructions on how to determine whether your site is affected as well -as what corrective action is needed can be found -[here](https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html). - -### Chrome 70 Early Release Channels - -Chrome 70 Canary and Dev - -In M70 Canary and Dev, the Symantec PKI has been distrusted by default for all -users. In these release channels, page loads over TLS connecting to sites using -Legacy Symantec TLS certificates display a full page interstitial with the error -code NET::ERR_CERT_SYMANTEC_LEGACY. Additionally, subresources served over such -connections will fail to load, possibly degrading site functionality. - -Chrome 70 Beta - -Distrust in the Legacy Symantec PKI was rolled out over time, starting with the -first Chrome 70 Beta. As a result of this Beta period, many sites still using -Legacy Symantec TLS certificates replaced their certificates.
\ No newline at end of file diff --git a/chromium/docs/website/site/Home/chromium-security/vulnerability-rewards-program/index.md b/chromium/docs/website/site/Home/chromium-security/vulnerability-rewards-program/index.md deleted file mode 100644 index c4a400045f8..00000000000 --- a/chromium/docs/website/site/Home/chromium-security/vulnerability-rewards-program/index.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -breadcrumbs: -- - /Home - - Chromium -- - /Home/chromium-security - - Chromium Security -page_name: vulnerability-rewards-program -title: Vulnerability Rewards Program ---- - -The Chrome Reward Program is hosted at -<https://www.google.com/about/appsecurity/chrome-rewards/index.html>. - -Go forth and report bugs!
\ No newline at end of file |
.png.sha1?id=c5dbcb143405a38088d78b4b760d64aaff5157ab){kind=link}
.png.sha1?id=c5dbcb143405a38088d78b4b760d64aaff5157ab){kind=link}
.png.sha1?id=c5dbcb143405a38088d78b4b760d64aaff5157ab){kind=link}
