Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security fixes for master #5331

Merged
merged 15 commits into from Dec 10, 2019
Merged

Security fixes for master #5331

merged 15 commits into from Dec 10, 2019

Conversation

@pks-t
Copy link
Member

pks-t commented Dec 10, 2019

This contains security fixes for the following issues:

  • CVE-2019-1348: the fast-import stream command "feature
    export-marks=path" allows writing to arbitrary file paths. As
    libgit2 does not offer any interface for fast-import, it is not
    susceptible to this vulnerability.

  • CVE-2019-1349: by using NTFS 8.3 short names, backslashes or
    alternate filesystreams, it is possible to cause submodules to
    be written into pre-existing directories during a recursive
    clone using git. As libgit2 rejects cloning into non-empty
    directories by default, it is not susceptible to this
    vulnerability.

  • CVE-2019-1350: recursive clones may lead to arbitrary remote
    code executing due to improper quoting of command line
    arguments. As libgit2 uses libssh2, which does not require us
    to perform command line parsing, it is not susceptible to this
    vulnerability.

  • CVE-2019-1351: Windows provides the ability to substitute
    drive letters with arbitrary letters, including multi-byte
    Unicode letters. To fix any potential issues arising from
    interpreting such paths as relative paths, we have extended
    detection of DOS drive prefixes to accomodate for such cases.

  • CVE-2019-1352: by using NTFS-style alternative file streams for
    the ".git" directory, it is possible to overwrite parts of the
    repository. While this has been fixed in the past for Windows,
    the same vulnerability may also exist on other systems that
    write to NTFS filesystems. We now reject any paths starting
    with ".git:" on all systems.

  • CVE-2019-1353: by using NTFS-style 8.3 short names, it was
    possible to write to the ".git" directory and thus overwrite
    parts of the repository, leading to possible remote code
    execution. While this problem was already fixed in the past for
    Windows, other systems accessing NTFS filesystems are
    vulnerable to this issue too. We now enable NTFS protecions by
    default on all systems to fix this attack vector.

  • CVE-2019-1354: on Windows, backslashes are not a valid part of
    a filename but are instead interpreted as directory separators.
    As other platforms allowed to use such paths, it was possible
    to write such invalid entries into a Git repository and was
    thus an attack vector to write into the ".git" dierctory. We
    now reject any entries starting with ".git" on all systems.

  • CVE-2019-1387: it is possible to let a submodule's git
    directory point into a sibling's submodule directory, which may
    result in overwriting parts of the Git repository and thus lead
    to arbitrary command execution. As libgit2 doesn't provide any
    way to do submodule clones natively, it is not susceptible to
    this vulnerability. Users of libgit2 that have implemented
    recursive submodule clones manually are encouraged to review
    their implementation for this vulnerability.

dscho and others added 15 commits Sep 18, 2019
A little-known feature of NTFS is that it offers to store metadata in
so-called "Alternate Data Streams" (inspired by Apple's "resource
forks") that are copied together with the file they are associated with.
These Alternate Data Streams can be accessed via `<file name>:<stream
name>:<stream type>`.

Directories, too, have Alternate Data Streams, and they even have a
default stream type `$INDEX_ALLOCATION`. Which means that `abc/` and
`abc::$INDEX_ALLOCATION/` are actually equivalent.

This is of course another attack vector on the Git directory that we
definitely want to prevent.

On Windows, we already do this incidentally, by disallowing colons in
file/directory names.

While it looks as if files'/directories' Alternate Data Streams are not
accessible in the Windows Subsystem for Linux, and neither via
CIFS/SMB-mounted network shares in Linux, it _is_ possible to access
them on SMB-mounted network shares on macOS.

Therefore, let's go the extra mile and prevent this particular attack
_everywhere_. To keep things simple, let's just disallow *any* Alternate
Data Stream of `.git`.

This is libgit2's variant of CVE-2019-1352.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we expect a checkout operation to fail, but it succeeds, we
actually do not want to see the error messages that were generated in
the meantime for errors that were handled gracefully by the code (e.g.
when an object could not be found in a pack: in this case, the next
backend would have been given a chance to look up the object, and
probably would have found it because the checkout succeeded, after all).

Which means that in the specific case of `cl_git_fail()`, we actually
want to clear the global error state _after_ evaluating the command: we
know that any still-available error would be bogus, seeing as the
command succeeded (unexpectedly).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Windows Subsystem for Linux (WSL) is getting increasingly popular,
in particular because it makes it _so_ easy to run Linux software on
Windows' files, via the auto-mounted Windows drives (`C:\` is mapped to
`/mnt/c/`, no need to set that up manually).

Unfortunately, files/directories on the Windows drives can be accessed
via their _short names_, if that feature is enabled (which it is on the
`C:` drive by default).

Which means that we have to safeguard even our Linux users against the
short name attacks.

Further, while the default options of CIFS/SMB-mounts seem to disallow
accessing files on network shares via their short names on Linux/macOS,
it _is_ possible to do so with the right options.

So let's just safe-guard against short name attacks _everywhere_.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We just safe-guarded `.git` against NTFS Alternate Data Stream-related
attack vectors, and now it is time to do the same for `.gitmodules`.

Note: In the added regression test, we refrain from verifying all kinds
of variations between short names and NTFS Alternate Data Streams: as
the new code disallows _all_ Alternate Data Streams of `.gitmodules`, it
is enough to test one in order to know that all of them are guarded
against.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The function `only_spaces_and_dots` used to detect the end of the
filename on win32.  Now we look at spaces and dots _before_ the end of
the string _or_ a `:` character, which would signify a win32 alternate
data stream.

Thus, rename the function `ntfs_end_of_filename` to indicate that it
detects the (virtual) end of a filename, that any further characters
would be elided to the given path.
The name of the `write_invalid_filename` function suggests that we
_want_ to write an invalid filename.  Rename the function to show that
we expect to _fail_ to write the invalid filename.
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for adding to the index when core.protectNTFS is set.
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
enabled for using the treebuilder when core.protectNTFS is set.
The name of the `add_invalid_filename` function suggests that we
_want_ to add an invalid filename.  Rename the function to show that
we expect to _fail_ to add the invalid filename.
Test that when we enable core.protectNTFS that we cannot add
platform-specific invalid paths to the index.
Enable core.protectNTFS by default everywhere and in every codepath, not
just on checkout.
Users may want to turn off core.protectNTFS, perhaps to import (and then
repair) a broken tree.  Ensure that core.protectNTFS=false is honored.
Windows/DOS only supports drive letters that are alpha characters A-Z.
However, you can `subst` any one-character as a drive letter, including
numbers or even emoji.  Test that we can identify emoji as drive
letters.
@pks-t pks-t merged commit 6777db8 into libgit2:master Dec 10, 2019
1 check passed
1 check passed
libgit2 #20191210.3 succeeded
Details
@pks-t pks-t deleted the pks-t:security-fixes branch Dec 10, 2019
implausible added a commit to nodegit/libgit2 that referenced this pull request Dec 10, 2019
Security fixes for master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.