1. 13 Dec, 2019 3 commits
  2. 12 Dec, 2019 1 commit
  3. 10 Dec, 2019 16 commits
    • Merge pull request #5331 from pks-t/security-fixes · 6777db8e
      Security fixes for master
      Patrick Steinhardt committed
    • path: support non-ascii drive letters on dos · 14ff3516
      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.
      Edward Thomson committed
    • index: ensure that we respect core.protectNTFS=false · 85d4ff77
      Users may want to turn off core.protectNTFS, perhaps to import (and then
      repair) a broken tree.  Ensure that core.protectNTFS=false is honored.
      Edward Thomson committed
    • path: protect NTFS everywhere · e4034dfa
      Enable core.protectNTFS by default everywhere and in every codepath, not
      just on checkout.
      Edward Thomson committed
    • test: ensure we can't add a protected path · d9c0c9cf
      Test that when we enable core.protectNTFS that we cannot add
      platform-specific invalid paths to the index.
      Edward Thomson committed
    • test: improve badname verification test · 72df1cd8
      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.
      Edward Thomson committed
    • test: ensure treebuilder validate new protection rules · f3b28604
      Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
      enabled for using the treebuilder when core.protectNTFS is set.
      Edward Thomson committed
    • test: ensure index adds validate new protection rules · 336991db
      Ensure that the new protection around .git::$INDEX_ALLOCATION rules are
      enabled for adding to the index when core.protectNTFS is set.
      Edward Thomson committed
    • test: improve badname verification test · a3cbd204
      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.
      Edward Thomson committed
    • path: rename function that detects end of filename · b8464342
      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.
      Edward Thomson committed
    • path: also guard `.gitmodules` against NTFS Alternate Data Streams · e1832eb2
      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>
      Johannes Schindelin committed
    • Disallow NTFS Alternate Data Stream attacks, even on Linux/macOS · 3f7851ea
      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>
      Johannes Schindelin committed
    • Protect against 8.3 "short name" attacks also on Linux/macOS · 64c612cc
      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>
      Johannes Schindelin committed
    • cl_git_fail: do not report bogus error message · d29d4de2
      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>
      Johannes Schindelin committed
  4. 04 Dec, 2019 5 commits
  5. 03 Dec, 2019 3 commits
  6. 01 Dec, 2019 3 commits
  7. 29 Nov, 2019 2 commits
    • global: convert to fiber-local storage to fix exit races · 5c6180b5
      On Windows platforms, we automatically clean up the thread-local storage
      upon detaching a thread via `DllMain()`. The thing is that this happens
      for every thread of applications that link against the libgit2 DLL, even
      those that don't have anything to do with libgit2 itself. As a result,
      we cannot assume that these unsuspecting threads make use of our
      `git_libgit2_init()` and `git_libgit2_shutdow()` reference counting,
      which may lead to racy situations:
      
          Thread 1                    Thread 2
      
          git_libgit2_shutdown()
                                      DllMain(DETACH_THREAD)
                                      git__free_tls_data()
          git_atomic_dec() == 0
          git__free_tls_data()
          TlsFree(_tls_index)
                                      TlsGetValue(_tls_index)
      
      Due to the second thread never having executed `git_libgit2_init()`, the
      first thread will clean up TLS data and as a result also free the
      `_tls_index` variable. When detaching the second thread, we
      unconditionally access the now-free'd `_tls_index` variable, which is
      obviously not going to work out well.
      
      Fix the issue by converting the code to use fiber-local storage instead
      of thread-local storage. While FLS will behave the exact same as TLS if
      no fibers are in use, it does allow us to specify a destructor similar
      to the one that is accepted by pthread_key_create(3P). Like this, we do
      not have to manually free indices anymore, but will let the FLS handle
      calling the destructor. This allows us to get rid of `DllMain()`
      completely, as we only used it to keep track of when threads were
      exiting and results in an overall simplification of TLS cleanup.
      Patrick Steinhardt committed
  8. 28 Nov, 2019 7 commits
    • Merge pull request #5311 from pks-t/pks/clar-trace-warning · 7f20778b
      tests: fix compiler warning if tracing is disabled
      Edward Thomson committed
    • Merge pull request #5313 from pks-t/pks/config-invasive · 61038425
      tests: config: only test parsing huge file with GITTEST_INVASIVE_SPEED
      Edward Thomson committed
    • tests: config: only test parsing huge file with GITTEST_INVASIVE_SPEED · 361ebbcb
      The test in config::stress::huge_section_with_many_values takes quite a
      long time to execute. Hide it behind the GITTEST_INVASIVE_SPEED
      environment varibale to not needlessly blow up execution time of tests.
      As this environment variable is being set by the continuous integration,
      we will execute it regularly anyway.
      Patrick Steinhardt committed
    • patch_parse: fix out-of-bounds reads caused by integer underflow · 33e6c402
      The patch format for binary files is a simple Base85 encoding with a
      length byte as prefix that encodes the current line's length. For each
      line, we thus check whether the line's actual length matches its
      expected length in order to not faultily apply a truncated patch. This
      also acts as a check to verify that we're not reading outside of the
      line's string:
      
      	if (encoded_len > ctx->parse_ctx.line_len - 1) {
      		error = git_parse_err(...);
      		goto done;
      	}
      
      There is the possibility for an integer underflow, though. Given a line
      with a single prefix byte, only, `line_len` will be zero when reaching
      this check. As a result, subtracting one from that will result in an
      integer underflow, causing us to assume that there's a wealth of bytes
      available later on. Naturally, this may result in an out-of-bounds read.
      
      Fix the issue by checking both `encoded_len` and `line_len` for a
      non-zero value. The binary format doesn't make use of zero-length lines
      anyway, so we need to know that there are both encoded bytes and
      remaining characters available at all.
      
      This patch also adds a test that works based on the last error message.
      Checking error messages is usually too tightly coupled, but in fact
      parsing the patch failed even before the change. Thus the only
      possibility is to use e.g. Valgrind, but that'd result in us not
      catching issues when run without Valgrind. As a result, using the error
      message is considered a viable tradeoff as we know that we didn't start
      decoding Base85 in the first place.
      Patrick Steinhardt committed
    • tests: fix compiler warning if tracing is disabled · 1d470a71
      If building libgit2's test suite with tracing disabled, then the
      compiler will emit a warning due to the unused `message_prefix`
      function. Fix the issue by wrapping the whole file into ifdef's for
      `GIT_TRACE` and providing separate empty function implementations for
      both `cl_global_trace_register` and `cl_global_trace_disable`.
      Patrick Steinhardt committed
    • Merge pull request #5306 from herrerog/patchid · fb439c97
      diff: complete support for git patchid
      Patrick Steinhardt committed
    • Merge pull request #5243 from pks-t/pks/config-optimize-mem · 61176a9b
      Memory optimizations for config entries
      Patrick Steinhardt committed