CVE-2019-11358

aka Blame jQuery

CVE: CVE-2019-11358
CWE: 79
ipc:
  note: |
    The feature that this vulnerability existed within dealt directly with
    the inter-process communication between the frontend of the application and
    the backend of the application. As one of the successful ways of doing this
    was to poison the object structure of the message being passed, it made it
    highly associated to the IPCs in the language for commmunication between
    frontend and backend channels.
  answer: true
  question: |
    Did the feature that this vulnerability affected use inter-process
    communication? IPC includes OS signals, pipes, stdin/stdout, message
    passing, and clipboard. Writing to files that another program in this
    software system reads is another form of IPC.

    Answer should be boolean.
CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
bugs: []
i18n:
  note: |
    This error, as it was within an internal package within a method for
    handling header information on Object prototypes is very much internal, and
    was not caused by internationalization, as this is standard across all
    languages.
  answer: false
  question: |
    Was the feature impacted by this vulnerability about internationalization
    (i18n)? An internationalization feature is one that enables people from all
    over the world to use the system. This includes translations, locales,
    typography, unicode, or various other features.

    Answer should be boolean. Write a note about how you came to the conclusions
    you did.
repo: 
vccs:
- note: This VCC was discovered automatically via archeogit.
  commit: c14937cf7a1e8c25702e89485cc2dd33aa0d3a16
fixes:
- note: 
  commit: baaf187a4e354bf3976c51e2c83a0d2f8ee6e6ad
- note: 
  commit: 95649bc08547a878cebfa1d019edec8cb1b80829
- note: |
    Taken from NVD references list with Git commit. If you are
    curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed'
  commit: 753d591aea698e57d6db58c9f722cd0808619b1b
bounty:
  amt: 
  url: 
  announced: 
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: 
    applies: false
  least_privilege:
    note: 
    applies: false
  native_wrappers:
    note: 
    applies: false
  defense_in_depth:
    note: |
      It appears this issue could've been slightly more protected if there was
      a secondary layer between the object returned from jQuery and the object
      used in the Django class. This layer of securty would've ensured that
      any issues internal to jQuery are separated from the core logic of the
      Django system, leaving it less vunlerabile to attacks (such as this one).
    applies: true
  secure_by_default:
    note: |
      There seems to be some immediate trust here of the jQuery framework and
      this, especially in this case, could've been a terrible mistake to trust
      the system. Trusting jQuery in this instance allowed for direct
      modifications to the __proto__ of the class, enabling large issues to
      occur if fallen into the right hands. But the more concerning part was
      that the bug was known for as long as it was, but nothing was done to
      fix it in jQuery, or nothing was done to help to secure Django against
      it, even if the developers there chose to wait so long to fix it.
    applies: true
  environment_variables:
    note: 
    applies: false
  security_by_obscurity:
    note: 
    applies: false
  frameworks_are_optional:
    note: 
    applies: false
reviews: []
sandbox: 
upvotes: 6
CWE_note: |
  The attack strategy used here matches best with a cross-site scripting
  vulnerability, as data entered by this vulnerability was directly allowing
  a user to modify data within objects. This allows for the potential for
  vulnerabilities to be saved in the system, data retreived by the system, or
  would alllow for this to propogate to other users of the system based on the
  goal of the person using the vulnerability.
mistakes:
  answer: |
    It appears most of this stems from a maintainability issue. This, however
    is not an issue with Django, but more so with jQuery. The origins of this
    bug report first started in 2016 and the ticket/report was continuously
    pushed back by the developers to fix until 2019. That's an incredibly long
    time for a vulnerability as serious as this to be lurking in all of the
    code bases. If the codebase for JQuery was properly maintained, it appears
    this would've gone away faster and wouldn't of been such a big issue (would
    still be a coding mistake, but not as large as now).
  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.
nickname: Blame jQuery
subsystem:
  name: vendor
  answer: |
    This appears to be in the vendor subsystem under the overarching js
    subsystem. Most static information held for this is held under a directory
    named static, and then for the level of information the static files are
    for (in this case admin), and then under the vendor subsystem. Within
    this subsystem exists the external packages for JS libraries (in this
    case jQuery), and then in the jquery.js file was the modification.
  question: |
    What subsystems was the mistake in?

    Most systems don't have a formal list of their subsystems, but you can
    usually infer them from path names, bug report tags, or other key words
    used. A single source file is not what we mean by a subsystem. In Django,
    the "Component" field on the bug report is useful. But there may be other
    subsystems involved.

    Your subsystem name(s) should not have any dots or slashes in them. Only
    alphanumerics, whitespace, _, - and @.Feel free to add multiple using a YAML
    array.

    In the answer field, explain where you saw these words.
    In the name field, a subsystem name (or an array of names)

    e.g. clipboard, model, view, controller, mod_dav, ui, authentication
discovered:
  answer: |
    The vulnerability was discovered within the jQuery library back in 2016 by
    an external github user when testing a method within the response header
    jQuery package. Upon further investigation into the issue, it was
    determined that the issue reached farther than this, and that the method
    itself in its extensibility, was able to potentially pollute an
    Object.prototype property, and that the jQuery.extend method would then
    be able to override the proto property of classes in Python/Django.
    The issue sat dormant for two years before finally being addressed by the
    development team late in 2018, then the CVE fix was finally added to the
    release done in eary 2019.
  contest: false
  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, contest, and developer flags can be true, false, or nil.

    If there is no evidence as to how this vulnerability was found, then please explain where you looked.
  automated: false
  developer: false
description: |
  This Django vulnerability stems from the ability to use a property
  of jQuery (a JavaScript Frontend Library) to modify internal python objects.
  This, in turn, allows for information that is not supposed to be in the
  class object for a python class to appear, or enables users to modify the
  class object without having to directly access the code. This, at a high
  level, is known as a cross-site scripting vulnerability, as you are putting
  information that shouldn't exist within the application's current state,
  in the application's state.

  This attack is completed by modiftying the __proto__ property of a
  request to the backend, which in turn would allow this new object to extend
  the object that already created. This is a major issue, as cross-site
  scripting can lead large data leaks, false information for users, and much
  more.
unit_tested:
  fix: false
  code: false
  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 code: and fix: - your answer should be boolean.

    For the code_answer below, look not only at the fix but the surrounding
    code near the fix in related directories and determine if and was there were unit tests involved for this subsystem. The code

    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.
  fix_answer: |
    The fix completed was to update the version of the jQuery library used, and
    with this, no extra tests were added.
  code_answer: |
    No tests exist for the vulnerability, as the vulnerability's origin is
    within the jQuery library used for some of Django's frontend featues.
discoverable: 
reported_date: '2016-11-18'
specification:
  answer: false
  answer_note: |
    There were no mentions of specifications in the documentation. This
    seems to come from an internal jQuery issue. Therefore, this
    vulnerability only propogated into the Django library due to its far
    reaching implications. The upgrade of versions seems to be the only way
    this could've been resolved.
  instructions: |
    Is there mention of a violation of a specification? For example,
    an RFC specification, a protocol specification, or a requirements
    specification.

    Be sure to check all artifacts for this: bug report, security
    advisory, commit message, etc.

    The answer field should be boolean. In answer_note, please explain
    why you come to that conclusion.
announced_date: 2019-04-20T00:29Z
curation_level: 1
published_date: '2019-04-20'
CWE_instructions: |
  Please go to http://cwe.mitre.org and find the most specific, appropriate CWE
  entry that describes your vulnerability. We recommend going to
  https://cwe.mitre.org/data/definitions/699.html for the Software Development
  view of the vulnerabilities. We also recommend the tool
  http://www.cwevis.org/viz to help see how the classifications work.

  If you have anything to note about why you classified it this way, write
  something in CWE_note. This field is optional.

  Just the number here is fine. No need for name or CWE prefix. If more than one
  apply here, then choose the best one and mention the others in CWE_note.
yaml_instructions: |
  ===YAML Primer===
  This is a dictionary data structure, akin to JSON.
  Everything before a colon is a key, and the values here are usually strings
  For one-line strings, you can just use quotes after the colon
  For multi-line strings, as we do for our instructions, you put a | and then
  indent by two spaces

  For readability, we hard-wrap multi-line strings at 80 characters. This is
  not absolutely required, but appreciated.
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:
  commits:
  - note: |
      This commit discusses the implications of unvalidated links within the
      Django admin page.
    commit: deeba6d92006999fee9adfbd8be79bf0a59e8008
  - note: 
    commit: 
  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?
curated_instructions: |
  If you are manually editing this file, then you are "curating" it.

  Set the version number that you were given in your instructions.

  This will enable additional editorial 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 properly updated.
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.
nickname_instructions: |
  A catchy name for this vulnerability that would draw attention it. If the
  report mentions a nickname, use that. Must be under 30 characters.
  Optional.
reported_instructions: |
  What date was the vulnerability reported to the security team? Look at the
  security bulletins and bug reports. It is not necessarily the same day that the
  CVE was created.  Leave blank if no date is given.
  Please enter your date in YYYY-MM-DD format.
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.
published_instructions: |
  Is there a published fix or patch date for this vulnerability?
  Please enter your date in YYYY-MM-DD 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 project-specific
  stuff. Remove references to versions, specific filenames, and other jargon
  that outsiders to this project would not understand. Technology like "regular
  expressions" is fine, and security phrases like "invalid write" are fine to
  keep too.

  Your target audience is people just like you before you took any course in
  security