CVE-2016-1643

CVE: CVE-2016-1643
CWE:
- 821
- 361
bugs:
- 589838
repo: https://chromium.googlesource.com/chromium/src/
vccs:
- 1717cf4bfefc8504ff6971d2e8fab1e14ea462bb:
    note: |
      This commit is when most of the code transitioned to using the shadow DOM approach.  There was a large code
      review (https://codereview.chromium.org/481753002) that introduced the ensurePrimaryContent() function
      and some tests to make sure everything was working properly.  It is interesting to note that this commit
      specifically mentions that a lot of code would need to be rebased because of this change.
fixes:
- 2386a6a49ea992a1e859eb0296c1cc53e5772cdb:
    note: |
      It looks like this fix was introduced to ensure that the ensurePrimaryContent
      actually recreated a shadow DOM in the background.  It was just assumed that
      it did so before this and because of that the DOM became more and more de-synced
      from where the elements on the page were at runtime over time.  This fix
      rectifies that by refreshing the shadow DOM before performing actions with it.
bounty:
  date: '2016-03-08'
  amount: 5000.0
  references:
  - http://chromereleases.googleblog.com/2016/03/stable-channel-update_8.html
lessons:
  yagni:
    note: 
    applies: false
  question: |
    Are there any common lessons we have learned from class that apply to this
    vulnerability? In other words, could this vulnerability serve as an example
    of one of those lessons?

    Leave "applies" blank or put false if you did not see that lesson (you do
    not need to put a reason). Put "true" if you feel the lesson applies and put
    a quick explanation of how it applies.

    Don't feel the need to claim that ALL of these apply, but it's pretty likely
    that one or two of them apply.

    If you think of another lesson we covered in class that applies here, feel
    free to give it a small name and add one in the same format as these.
  serial_killer:
    note: 
    applies: false
  complex_inputs:
    note: 
    applies: false
  distrust_input:
    note: "The shadow DOM (Document Object Model) system assumed that the DOM was
      being \nupdated at all times.  The function to update the DOM when user defined
      images \nchanged did not recreate the tree, leading the system to point to insecure
      areas \nof memory.  The input was not checked (the image src location) and the
      DOM was \nnot updated, which lead to the security hole.\n"
    applies: true
  least_privilege:
    note: 
    applies: false
  native_wrappers:
    note: 
    applies: false
  defense_in_depth:
    note: 
    applies: false
  secure_by_default:
    note: 
    applies: false
  environment_variables:
    note: 
    applies: false
  security_by_obscurity:
    note: 
    applies: false
  frameworks_are_optional:
    note: 
    applies: false
reviews:
- 1732753004
- 1756363003
upvotes: 12
mistakes:
  answer: "This bug was introduced in one fell swoop after a large code rebase.  The
    team seemingly decided it was best to\nutilize the shadow DOM (Document Object
    Model) to silently take care of loading images in the background.  This is\nan
    interesting choice for the use of a shadow DOM because it would have to be maintained
    properly for it to not\nstart pointing to areas in memory that were not secure.
    \ Unfortunately that is what happened here.  One user worked\non implementing
    utilizing a shadow DOM for the first time and did not account for when the shadow
    DOM itself was \nmissing or out of sync.  It was seemingly an oversight on the
    part of the user, and also all the users that \nreviewed the changes.  The change
    impacted many files.  It seems that the decision to utilize the shadow DOM \nframework
    is still in use today.  So this commit introduced the newly accepted framework
    into the system, \nand the bug that accompanied it.  The mistake could have likely
    been avoided had the change been smaller and \nsplit up over more reviews.  Coding
    and reviewing fatigue are a real thing, and as stated before, this was likely
    \njust an oversight."
  question: |
    In your opinion, after all of this research, what mistakes were made that
    led to this vulnerability? Coding mistakes? Design mistakes?
    Maintainability? Requirements? Miscommunications?

    Look at the CWE entry for this vulnerability and examine the mitigations
    they have written there. Are they doing those? Does the fix look proper?

    Use those questions to inspire your answer. Don't feel obligated to answer
    every one. Write a thoughtful entry here that those ing the software
    engineering industry would find interesting.
announced: '2016-03-13'
subsystem:
  name: Webkit
  answer: "This was found in the Webkit third_party code.  Webkit is an open source
    web \nbrowsing engine. There isn't really a subsystem in this case since the issue\noccurred
    in Webkit/Source/core/html, which is likely the primary component \nof Webkit
    (based off the directory name 'core').\n"
  question: |
    What subsystems was the mistake in?

    Look at the path of the source code files code that were fixed to get
    directory names. Look at comments in the code. Look at the bug reports how
    the bug report was tagged. Examples: "clipboard", "gpu", "ssl", "speech", "renderer"
discovered:
  date: '2016-02-25'
  answer: "Found using regression test in the cloudfuzz automated service \n(cloudfuzz@gmail.com
    reported the issue originally.) Several Google employees \nwere able to reproduce
    the issue using cloudfuzz and cluster-fuzz.  The issue\nthey found was type confusion
    in blink::BaseButtonInputType::valueAttributeChanged.\nThey observed an ASSERTION
    FAILED during the testing when they tried to assert that\nthe node they were looking
    at hasn't changed (which is the bug in a nutshell, the\nitem on the page changed,
    but the shadow DOM was never updated to match, so the\nassertion that the items
    on the current page matched the items in the shadow DOM\nfailed).\n"
  google: false
  contest: 
  question: |
    How was this vulnerability discovered?

    Go to the bug report and read the conversation to find out how this was
    originally found. Answer in longform below in "answer", fill in the date in
    YYYY-MM-DD, and then determine if the vulnerability was found by a Google
    employee (you can tell from their email address). If it's clear that the
    vulenrability was discovered by a contest, fill in the name there.

    The "automated" flag can be true, false, or nil.
    The "google" flag can be true, false, or nil.

    If there is no evidence as to how this vulnerability was found, then you may
    leave the entries blank except for "answer". Write down where you looked in "answer".
  automated: true
description: "A function in Google's Webkit in Blink (a web browser Google introduced
  in\n2013) that was used to ensure a resource, called a shadow DOM (Document \nObject
  Model) was synchronized properly with the current content on the page \nthe user
  would be looking at, did not properly update the model when content\nchanged or
  was unavailable.  The out of sync resource would allow remote \nattackers to cause
  a denial of service or possibly have unspecified other impact\nthrough arbitrary
  code execution (hackers could craft their own code which the\nprogram would run
  blindly).  This is because the function, when it crashes, \ngives the attacker semi-reliable
  control of the stack of the chrome system.\nThe stack is the set of instructions
  the program will run in order.  \nControl of the stack means the user has control
  over what the program will \nexecute next. The reason for using a resource like
  a shadow DOM is allow \nfor a controllable boundary between the actual implementation
  of various items\nlike a slider, and the use of them. Rather than requiring users
  to code every last\npiece of everything on webpages, shadow DOMs are used to give
  developers access\nto elements that the implementers of the framework want you to
  have access to,\nwithout exposing the framwork itself.  Think of a shadow DOM as
  a way for\nframweork developers to let webpage developers work with complex pre-built
  \nitems like various kinds of input sliders or video frames, without exposing\nthe
  code for how those reach into the framework itself, all the while allowing\nthe
  user to both utilize, customize, and stylize those elements.  The problem\nthat
  was encountered here for this vulnerability is that the shadow DOM was\nnot being
  properly refreshed. When source images weren't loaded (the\n<img> tag being the
  html component that is actually a secret call to items\nin the shadow DOM that do
  some magic reaching into the framework), the DOM\nwould suddenly have a refernce
  to items that were not actually on the current\npage (memory gets allocated for
  an image, then the image is never actually\nloaded, the DOM thinks there is an image
  but instead points to other mermory),\nwhich exposed the system to hackers.\n"
unit_tested:
  fix: false
  code: true
  answer: |
    Unit tests were used in the shadow-dom area of the code.
    In /src/third_party/WebKit/LayoutTests there is a shadow-dom tests folder.
    No updates were committed near this fix or with this fix so I assume that
    no changes were made to the unit test code to account for this vulnerability.
  question: |
    Were automated unit tests involved in this vulnerability?
    Was the original code unit tested, or not unit tested? Did the fix involve
    improving the automated tests?

    For the "code" answer below, look not only at the fix but the surrounding
    code near the fix and determine if and was there were unit tests involved
    for this module.

    For the "fix" answer below, check if the fix for the vulnerability involves
    adding or improving an automated test to ensure this doesn't happen again.
major_events:
  answer: |
    To me it was just interesting to see that the repository work consisted of basically
    the same 3-4 individuals doing major restructuring and rework of the image rendering
    system.  The events themselves happen over the course of late 2014 through early 2015
    and culminate in the fall of 2015.  Refactoring took place, starting right after the
    major shift of introducing a shadow DOM system.  Many functions, file locations,
    naming conventions, and even code cleanup actions were performed over this period of
    time.  It is really interesting to note that the team did not seem to change during
    the time, possibly a handoff occurred in the middle range.
  events:
  - date: '2014-12-09'
    name: Developers implement shadow DOM approach to handling fallback content for
      images
  - date: '2015-09-10'
    name: Handoff of code refactoring goes from dsinclair@chromium.org to tkent@chromium.org
  - date: '2015-04-30'
    name: Last cleanup commit by dsinclair@chromium.org
  - date: '2015-02-06'
    name: Refactoring of code begins by dsinclair@chromium.org
  question: |
    Please record any major events you found in the history of this
    vulnerability. Was the code rewritten at some point? Was a nearby subsystem
    changed? Did the team change?

    The event doesn't need to be directly related to this vulnerability, rather,
    we want to capture what the development team was dealing with at the time.
curation_level: 0
CWE_instructions: |
  Please go to cwe.mitre.org and find the most specific, appropriate CWE entry
  that describes your vulnerability. (Tip: this may not be a good one to start
  with - spend time understanding this vulnerability before making your choice!)
bounty_instructions: |
  If you came across any indications that a bounty was paid out for this
  vulnerability, fill it out here. Or correct it if the information already here
  was wrong. Otherwise, leave it blank.
interesting_commits:
  answer: 
  commits:
  - note: "This commit is interesting and pertinent because it deals with movement
      and \nrenaming of portions of the shadow DOM system, which is the system that
      didn't\nupdate correctly, and was eventually found to be be exploitable when
      the\nshadow DOM became out of sync because of images that failed to load (if
      the\nimage src updated the shadow DOM was never updated).\n"
    commit: eacf7182612681e86152431ecda050e459bc2355
  - note: |
      This commit in and of itself isn't particularly interesting, but the fact that
      it was the last commit to the file for a year before the vulnerability was found,
      and capped off a year or so of prior work to reorganize and restructure the image
      rendering system seems important to me.
    commit: e2b998a109b5d231dedf2d7c6287d4191b51b7e1
  question: |
    Are there any interesting commits between your VCC(s) and fix(es)?

    Write a brief (under 100 words) description of why you think this commit was
    interesting in light of the lessons learned from this vulnerability. Any
    emerging themes?

    If there are no interesting commits, demonstrate that you completed this section by explaining what happened between the VCCs and the fix.
curated_instructions: |
  If you are manually editing this file, then you are "curating" it. Set the
  entry below to "true" as soon as you start. This will enable additional
  integrity checks on this file to make sure you fill everything out properly.
  If you are a student, we cannot accept your work as finished unless curated is
  set to true.
upvotes_instructions: |
  For the first round, ignore this upvotes number.

  For the second round of reviewing, you will be giving a certain amount of
  upvotes to each vulnerability you see. Your peers will tell you how
  interesting they think this vulnerability is, and you'll add that to the
  upvotes score on your branch.
announced_instructions: |
  Was there a date that this vulnerability was announced to the world? You can
  find this in changelogs, blogs, bug reports, or perhaps the CVE date. A good
  source for this is Chrome's Stable Release Channel
  (https://chromereleases.googleblog.com/).
  Please enter your date in YYYY-MM-DD format.
fixes_vcc_instructions: |
  Please put the commit hash in "commit" below (see my example in
  CVE-2011-3092.yml). Fixes and VCCs follow the same format.
description_instructions: |
  You can get an initial description from the CVE entry on cve.mitre.org. These
  descriptions are a fine start, but they can be kind of jargony.

  Rewrite this description in your own words. Make it interesting and easy to
  read to anyone with some programming experience. We can always pull up the NVD
  description later to get more technical.

  Try to still be specific in your description, but remove Chromium-specific
  stuff. Remove references to versions, specific filenames, and other jargon
  that outsiders to Chromium would not understand. Technology like "regular
  expressions" is fine, and security phrases like "invalid write" are fine to
  keep too.