Skip to content

[CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7 #83582

Closed
Closed
[CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7#83582
Assignees
zooba
Labels
3.7 (EOL)end of life3.8 (EOL)end of lifeOS-windowstype-securityA security issue

Description

@anthonywee
anthonywee
mannequin
opened on Jan 21, 2020
BPO 39401
Nosy @pfmoore, @vstinner, @tjguk, @jkloth, @ned-deily, @zware, @eryksun, @zooba, @miss-islington, @anthonywee
PRs
  • bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier #18231
  • [3.7] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) #18232
  • [3.6] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) #18233
  • [3.8] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) #18234
    		•
    Files
  • python unsafe dll loading.png
    		•

    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 = 'https://github.com/zooba'
closed_at = <Date 2020-01-31.02:14:13.825>
created_at = <Date 2020-01-21.01:02:15.447>
labels = ['type-security', '3.7', '3.8', 'OS-windows']
title = '[CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7'
updated_at = <Date 2020-01-31.02:14:13.824>
user = 'https://github.com/anthonywee'

    bugs.python.org fields:

    activity = <Date 2020-01-31.02:14:13.824>
actor = 'ned.deily'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2020-01-31.02:14:13.825>
closer = 'ned.deily'
components = ['Windows']
creation = <Date 2020-01-21.01:02:15.447>
creator = 'anthonywee'
dependencies = []
files = ['48855']
hgrepos = []
issue_num = 39401
keywords = ['patch']
message_count = 17.0
messages = ['360348', '360350', '360529', '360858', '360882', '360933', '360935', '360946', '360994', '360997', '360998', '360999', '361013', '361014', '361022', '361038', '361088']
nosy_count = 10.0
nosy_names = ['paul.moore', 'vstinner', 'tim.golden', 'jkloth', 'ned.deily', 'zach.ware', 'eryksun', 'steve.dower', 'miss-islington', 'anthonywee']
pr_nums = ['18231', '18232', '18233', '18234']
priority = None
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue39401'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']

    Activity

    1. anthonywee commented on Jan 21, 2020

      @anthonywee
      anthonyweemannequin
      on Jan 21, 2020
      MannequinAuthor

      On Win7, running Python in the terminal will attempt to load the "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the Python directory and the C:\Windows\System32 directories. This behavior can be verified using Process Monitor (see attachment).

      This is happening due to direct calls to LoadLibraryW() in getpathp.c without any "LOAD_LIBRARY_SEARCH*" flags.

      In join():

      cpython/PC/getpathp.c

      Line 255 in c02b41b

      HMODULE pathapi = LoadLibraryW(L"api-ms-win-core-path-l1-1-0.dll");

      and canonicalize():

      cpython/PC/getpathp.c

      Line 291 in c02b41b

      HMODULE pathapi = LoadLibraryW(L"api-ms-win-core-path-l1-1-0.dll");

      For both cases, the methods they are trying to load from api-ms-win-core-path-l1-1-0.dll (PathCchCanonicalizeEx and PathCchCombineEx) were introduced in Win8.

      I tested on Win7 and Win10 and they differ in how they load these api-ms-win-* dll's and whether they appear in process monitor. In Win7, a CreateFile event appears in procmon, while in Win10 it seems like the OS is automatically loading the module from kernelbase.dll. Also in Win7 the loading of api-ms-win-core-path-l1-1-0.dll will fail while in Win10 it succeeds. However, in Win7 when it fails it results in the standard dll search strategy, which will eventually search outside of the secure directories such as the directories in the PATH env var: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

      Each of the problematic methods in cpython have a pattern of attempting to load the dll, then falling back to an older version of the method. Thus in Win7, the dll fails to load and it falls back to the older version of the method. In Win10, the dll load succeeds and we use the new versions of the methods.

      I'm working on a fix to pass the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag to limit to the dll search path scope.

    2. eryksun commented on Jan 21, 2020

      @eryksun
      eryksun
      on Jan 21, 2020
      Contributor

      On Win7, running Python in the terminal will attempt to load the
      "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the
      Python directory and the C:\Windows\System32 directories.

      "api-ms-win-core-path-l1-1-0.dll" is not assigned in the API set schema (in ApiSetSchema.dll) in Windows 7. Since the name is neither in the list of known DLLs nor the list of assigned API sets, the loader searches for it in the normal way. (FYI, the number of API sets increased from 35 in Windows 7 up to 502 in Windows 8.1.)

      I'm working on a fix to pass the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS

      I think this could use just LOAD_LIBRARY_SEARCH_SYSTEM32. I see no reason to try to load "api-ms-win-core-path-l1-1-0.dll" from the application directory or user directories.

      I'm adding 3.6-3.9 to the list of affected versions. In 3.9 it can use a static import instead (i.e. remove LoadLibraryaExW / GetProcAddress), since only Windows 8.1+ is supported.

    3. eryksun
      added
      OS-windows
      3.7 (EOL)end of life
      3.8 (EOL)end of life
      3.9 (EOL)end of life
      type-securityA security issue
      on Jan 21, 2020

    4. zooba commented on Jan 23, 2020

      @zooba
      zooba
      on Jan 23, 2020
      Member

      Agreed, we can just search System32 for this. Thanks for doing the patch!

      For future reference, and for anyone else reading this, we generally prefer unavoidable DLL hijacking bugs to come to the Python Security Response Team first (security@python.org).

    5. ned-deily
      added
      deferred-blocker
      on Jan 23, 2020
    6. zooba
      self-assigned this
      on Jan 28, 2020

    7. zooba commented on Jan 28, 2020

      @zooba
      zooba
      on Jan 28, 2020
      Member

      For clarity, I'm removing 3.9 from the affected versions. This version does not support Windows 7, and only Windows 7 is vulnerable to this DLL hijack.

      Also submitting the CVE request.

    8. zooba
      removed
      3.9 (EOL)end of life
      on Jan 28, 2020

    9. eryksun commented on Jan 28, 2020

      @eryksun
      eryksun
      on Jan 28, 2020
      Contributor

      For clarity, I'm removing 3.9 from the affected versions. This version
      does not support Windows 7, and only Windows 7 is vulnerable to this
      DLL hijack.

      I added 3.9 for the related issue to switch to using a static import, since Windows 7 isn't supported in 3.9. But I guess that should have been made a separate issue, or added to the omnibus issue bpo-32592.

    10. zooba commented on Jan 29, 2020

      @zooba
      zooba
      on Jan 29, 2020
      Member

      This is now assigned CVE-2020-8315 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8315 https://nvd.nist.gov/vuln/detail/CVE-2020-8315)

      Thanks Anthony for the report! I included your name as the reporter, though I don't see it on any of the pages.

    11. zooba
      changed the title [-]Unsafe dll loading in getpathp.c on Win7[/-] [+][CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7[/+] on Jan 29, 2020

    12. 2 remaining items

    13. vstinner commented on Jan 29, 2020

      @vstinner
      vstinner
      on Jan 29, 2020
      Member

      I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

    14. jkloth commented on Jan 29, 2020

      @jkloth
      jkloth
      on Jan 29, 2020
      Contributor

      As noted on the PR landing page, this PR has caused failures of 2 buildbots:

      https://buildbot.python.org/all/#builders/81/builds/272

      https://buildbot.python.org/all/#builders/150/builds/227

      (both are Windows 7)

    15. zooba commented on Jan 30, 2020

      @zooba
      zooba
      on Jan 30, 2020
      Member

      Both of those buildbots should be retired (or repurposed for versions of Python that still support Windows 7) :)

    16. eryksun commented on Jan 30, 2020

      @eryksun
      eryksun
      on Jan 30, 2020
      Contributor

      this PR has caused failures of 2 buildbots

      The master branch should no longer get built on Windows 7 machines. The initial build succeeds, but running "_freeze_importlib[_d].exe" fails with STATUS_DLL_NOT_FOUND (0xC0000135, i.e. -1073741515) since "api-ms-win-core-path-l1-1-0.dll" (linked from pathcch.lib) is not a Windows 7 API set.

    17. zooba commented on Jan 30, 2020

      @zooba
      zooba
      on Jan 30, 2020
      Member

      I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

      Thanks, Victor!

      Python 2.7 and 3.5 are not vulnerable. The issue was added in 3.6 when I added support for installing Python into a long path name on up-to-date OS, which required dynamically loading an OS function. That dynamic load was the problem.

    18. miss-islington commented on Jan 30, 2020

      @miss-islington
      miss-islington
      on Jan 30, 2020
      Contributor

      New changeset 561c597 by Steve Dower in branch '3.7':
      [3.7] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18232)
      561c597

    19. miss-islington commented on Jan 30, 2020

      @miss-islington
      miss-islington
      on Jan 30, 2020
      Contributor

      New changeset ad4a20b by Steve Dower in branch '3.8':
      [3.8] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18234)
      ad4a20b

    20. vstinner commented on Jan 30, 2020

      @vstinner
      vstinner
      on Jan 30, 2020
      Member

      > I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

      Thanks, Victor! Python 2.7 and 3.5 are not vulnerable. The issue was added in 3.6 when I added support for installing Python into a long path name on up-to-date OS, which required dynamically loading an OS function. That dynamic load was the problem.

      Oh ok, I updated the page to reflect that. I also added 3.7 & 3.8 commits.

    21. anthonywee commented on Jan 30, 2020

      @anthonywee
      anthonyweemannequin
      on Jan 30, 2020
      MannequinAuthor

      Thanks Anthony for the report! I included your name as the reporter, though I don't see it on any of the pages.

      No problem! Thanks Steve, Eryk, and Victor for jumping on this!

    22. ned-deily commented on Jan 31, 2020

      @ned-deily
      ned-deily
      on Jan 31, 2020
      Member

      New changeset 51332c4 by Steve Dower in branch '3.6':
      [3.6] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18233)
      51332c4

    23. ned-deily
      closed this as completedon Jan 31, 2020
    24. ned-deily
      removed
      deferred-blocker
      on Jan 31, 2020
    25. ned-deily
      closed this as completedon Jan 31, 2020
    26. ned-deily
      removed
      deferred-blocker
      on Jan 31, 2020
    27. ezio-melotti
      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

    Labels

    3.7 (EOL)end of life3.8 (EOL)end of lifeOS-windowstype-securityA security issue

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions