1. 28 Nov, 2018 2 commits
  2. 18 Nov, 2018 1 commit
  3. 14 Nov, 2018 2 commits
    • index: introduce git_index_iterator · c358bbc5
      Provide a public git_index_iterator API that is backed by an index
      snapshot.  This allows consumers to provide a stable iteration even
      while manipulating the index during iteration.
      Edward Thomson committed
    • strntol: fix out-of-bounds reads when parsing numbers with leading sign · 4209a512
      When parsing a number, we accept a leading plus or minus sign to return
      a positive or negative number. When the parsed string has such a leading
      sign, we set up a flag indicating that the number is negative and
      advance the pointer to the next character in that string. This misses
      updating the number of bytes in the string, though, which is why the
      parser may later on do an out-of-bounds read.
      
      Fix the issue by correctly updating both the pointer and the number of
      remaining bytes. Furthermore, we need to check whether we actually have
      any bytes left after having advanced the pointer, as otherwise the
      auto-detection of the base may do an out-of-bonuds access. Add a test
      that detects the out-of-bound read.
      
      Note that this is not actually security critical. While there are a lot
      of places where the function is called, all of these places are guarded
      or irrelevant:
      
      - commit list: this operates on objects from the ODB, which are always
        NUL terminated any may thus not trigger the off-by-one OOB read.
      
      - config: the configuration is NUL terminated.
      
      - curl stream: user input is being parsed that is always NUL terminated
      
      - index: the index is read via `git_futils_readbuffer`, which always NUL
        terminates it.
      
      - loose objects: used to parse the length from the object's header. As
        we check previously that the buffer contains a NUL byte, this is safe.
      
      - rebase: this parses numbers from the rebase instruction sheet. As the
        rebase code uses `git_futils_readbuffer`, the buffer is always NUL
        terminated.
      
      - revparse: this parses a user provided buffer that is NUL terminated.
      
      - signature: this parser the header information of objects. As objects
        read from the ODB are always NUL terminated, this is a non-issue. The
        constructor `git_signature_from_buffer` does not accept a length
        parameter for the buffer, so the buffer needs to be NUL terminated, as
        well.
      
      - smart transport: the buffer that is parsed is NUL terminated
      
      - tree cache: this parses the tree cache from the index extension. The
        index itself is read via `git_futils_readbuffer`, which always NUL
        terminates it.
      
      - winhttp transport: user input is being parsed that is always NUL
        terminated
      Patrick Steinhardt committed
  4. 13 Nov, 2018 3 commits
    • tests: address two null argument instances · f127ce35
      Handle two null argument cases that occur in the unit tests.
      One is in library code, the other is in test code.
      
      Detected by running unit tests with undefined behavior sanitizer:
      ```bash
       # build
      mkdir build && cd build
      cmake -DBUILD_CLAR=ON -DCMAKE_C_FLAGS="-fsanitize=address \
      -fsanitize=undefined -fstack-usage -static-libasan" ..
      cmake --build .
      
       # run with asan
      ASAN_OPTIONS="allocator_may_return_null=1" ./libgit2_clar
      ...
      ............../libgit2/src/apply.c:316:3: runtime error: null pointer \
      passed as argument 1, which is declared to never be null
      ...................../libgit2/tests/apply/fromfile.c:46:3: runtime \
      error: null pointer passed as argument 1, which is declared to never be null
      ```
      Noah Pendleton committed
    • tests: apply: fix reference to deprecated `git_buf_free` · afc64bcd
      Since commit 56ffdfc6 (buffer: deprecate `git_buf_free` in favor of
      `git_buf_dispose`, 2018-02-08), the function `git_buf_free` is
      deprecated and shall not be used anymore. As part of the new apply
      framework that has been cooking for quite some time some new references
      have been introduced to that deprecated function. Replace them with
      calls to `git_buf_dispose`.
      Patrick Steinhardt committed
    • tests: apply: fix missing `cl_git_pass` wrappers · fe215153
      Some function calls in the new "apply" test suite were missing the
      checks whether they succeeded as expected. Fix this by adding the
      missing `cl_git_pass` wrappers.
      Patrick Steinhardt committed
  5. 09 Nov, 2018 1 commit
    • signature: fix out-of-bounds read when parsing timezone offset · 52f859fd
      When parsing a signature's timezone offset, we first check whether there
      is a timezone at all by verifying that there are still bytes left to
      read following the time itself. The check thus looks like `time_end + 1
      < buffer_end`, which is actually correct in this case. After setting the
      timezone's start pointer to that location, we compute the remaining
      bytes by using the formula `buffer_end - tz_start + 1`, re-using the
      previous `time_end + 1`. But this is in fact missing the braces around
      `(tz_start + 1)`, thus leading to an overestimation of the remaining
      bytes by a length of two. In case of a non-NUL terminated buffer, this
      will result in an overflow.
      
      The function `git_signature__parse` is only used in two locations. First
      is `git_signature_from_buffer`, which only accepts a string without a
      length. The string thus necessarily has to be NUL terminated and cannot
      trigger the issue.
      
      The other function is `git_commit__parse_raw`, which can in fact trigger
      the error as it may receive non-NUL terminated commit data. But as
      objects read from the ODB are always NUL-terminated by us as a
      cautionary measure, it cannot trigger the issue either.
      
      In other words, this error does not have any impact on security.
      Patrick Steinhardt committed
  6. 05 Nov, 2018 29 commits
  7. 04 Nov, 2018 2 commits