Skip to content

[security] CVE-2019-10268: An arbitrary execution vulnerability exists in the built-in function getattr #80687

Closed

Description

@bigbigliang-malwarebenchmark
BPO 36506
Nosy @vstinner, @tiran, @serhiy-storchaka, @MojoVampire, @18z, @tirkarthi, @krnick, @bigbigliang-malwarebenchmark

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-04-06.16:24:57.163>
created_at = <Date 2019-04-02.14:48:46.520>
labels = ['type-security', 'interpreter-core', '3.8', '3.9', '3.7', 'invalid']
title = '[security] CVE-2019-10268: An arbitrary execution vulnerability exists in the built-in function getattr'
updated_at = <Date 2019-04-06.16:24:57.162>
user = 'https://github.com/bigbigliang-malwarebenchmark'

bugs.python.org fields:

activity = <Date 2019-04-06.16:24:57.162>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2019-04-06.16:24:57.163>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2019-04-02.14:48:46.520>
creator = 'bigbigliang'
dependencies = []
files = []
hgrepos = []
issue_num = 36506
keywords = ['security_issue']
message_count = 9.0
messages = ['339337', '339342', '339343', '339350', '339351', '339372', '339385', '339395', '339423']
nosy_count = 9.0
nosy_names = ['vstinner', 'christian.heimes', 'SilentGhost', 'serhiy.storchaka', 'josh.r', '18z', 'xtreak', 'krnick', 'bigbigliang']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue36506'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8', 'Python 3.9']

Activity

  1. bigbigliang-malwarebenchmark commented on Apr 2, 2019

    bigbigliang-malwarebenchmarkmannequin
    MannequinAuthor

    Dear Python Community,

    We’ve found a bug in cpython Lib and already received a cve number (CVE-2019-10268).But to be honest, I'm not sure if it's a loophole.
    Please tell me what to do next.

    bigbigliang

  2. tiran commented on Apr 2, 2019

    @tiran
    Member

    Hi,

    this is a public bug tracker. Please don't report new security bugs here but follow the guidelines at https://www.python.org/news/security/. Also please don't acquire CVE numbers for issues yourself. The Python Security Response Team will request CVE numbers.

  3. tirkarthi commented on Apr 2, 2019

    @tirkarthi
    Member

    The security vulnerability disclosure process can be found at https://www.python.org/news/security/ . Please contact security@python.org.

  4. added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    and removed on Apr 2, 2019
  5. changed the title [-]An arbitrary execution vulnerability exists in the built-in function getattr[/-] [+][security] CVE-2019-10268: An arbitrary execution vulnerability exists in the built-in function getattr[/+] on Apr 2, 2019
  6. MojoVampire commented on Apr 2, 2019

    MojoVampiremannequin
    Mannequin

    I'll note that, based on the title, I'm skeptical of the claim of a vulnerability. getattr is effectively *designed* to execute arbitrary code if called on an appropriate object (one where the class defines __getattribute__; defines __getattr__ without defining the name in question; defines the name in question as a property, not an instance attribute; or does something complicated with metaclasses that achieves a similar result looking up the attribute on the class).

    In all of those cases, the "vulnerability" only exists if:

    1. The object in question defines a vulnerable handler for the attribute (that is, provides a code path for arbitrary execution that Python's attribute lookup machinery wasn't responsible for except insofar as it passed control to the unsafe handler in question)
    2. Untrusted user input is passed as the name to look up on the vulnerable object

    If it's something more subtle than that (e.g. something where a "plain" instance with no special execution path supports arbitrary execution), that's an issue, but if it requires a Python developer to both create the vulnerability and open a path to trigger it explicitly, that doesn't really count.

  7. SilentGhost commented on Apr 2, 2019

    SilentGhostmannequin
    Mannequin

    As another note, this seem to be a third "security" issue created in less then a week to the same template (others are 36260 and 36462). I hope it's some assignment due soon.

  8. bigbigliang-malwarebenchmark commented on Apr 3, 2019

    bigbigliang-malwarebenchmarkmannequin
    MannequinAuthor

    Yes, as you said. I think this problem can be closed. My initial idea was
    that if a user carefully constructs a vulnerability point, it may cause
    some danger, such as 'getattr(os,"system")("/bin/sh")'. So I have some
    ideas about whether it is necessary to filter it.
    Thank you for your reply.

    from:bigbigliang

    Josh Rosenberg <report@bugs.python.org> 于2019年4月3日周三 上午12:52写道:

    Josh Rosenberg <shadowranger+python@gmail.com> added the comment:

    I'll note that, based on the title, I'm skeptical of the claim of a
    vulnerability. getattr is effectively *designed* to execute arbitrary code
    if called on an appropriate object (one where the class defines
    __getattribute__; defines __getattr__ without defining the name in
    question; defines the name in question as a property, not an instance
    attribute; or does something complicated with metaclasses that achieves a
    similar result looking up the attribute on the class).

    In all of those cases, the "vulnerability" only exists if:

    1. The object in question defines a vulnerable handler for the attribute
      (that is, provides a code path for arbitrary execution that Python's
      attribute lookup machinery wasn't responsible for except insofar as it
      passed control to the unsafe handler in question)
    2. Untrusted user input is passed as the name to look up on the vulnerable
      object

    If it's something more subtle than that (e.g. something where a "plain"
    instance with no special execution path supports arbitrary execution),
    that's an issue, but if it requires a Python developer to both create the
    vulnerability and open a path to trigger it explicitly, that doesn't really
    count.

    ----------
    keywords: +security_issue
    nosy: +josh.r


    Python tracker <report@bugs.python.org>
    <https://bugs.python.org/issue36506\>


  9. tiran commented on Apr 3, 2019

    @tiran
    Member

    Could you please do us a favor and contact MITRE to get the CVE number revoked? Please CC security@python.org so we have a record of the emails.

  10. bigbigliang-malwarebenchmark commented on Apr 3, 2019

    bigbigliang-malwarebenchmarkmannequin
    MannequinAuthor

    Certainly.

  11. bigbigliang-malwarebenchmark commented on Apr 4, 2019

    bigbigliang-malwarebenchmarkmannequin
    MannequinAuthor

    Thank you for your answer. I am a student and very interested in python. I
    want to continue digging for Python bugs, but I am not good at this area. I
    want to keep looking for loopholes.

    from:bigbigliang

    Christian Heimes <report@bugs.python.org> 于2019年4月3日周三 下午5:33写道:

    Christian Heimes <lists@cheimes.de> added the comment:

    Could you please do us a favor and contact MITRE to get the CVE number
    revoked? Please CC security@python.org so we have a record of the emails.

    ----------


    Python tracker <report@bugs.python.org>
    <https://bugs.python.org/issue36506\>


  12. transferred this issue fromon Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions