1. 05 Aug, 2019 1 commit
    • commit_list: fix possible buffer overflow in `commit_quick_parse` · 12bcc7a9
      The function `commit_quick_parse` provides a way to quickly parse
      parts of a commit without storing or verifying most of its
      metadata. The first thing it does is calculating the number of
      parents by skipping "parent " lines until it finds the first
      non-parent line. Afterwards, this parent count is passed to
      `alloc_parents`, which will allocate an array to store all the
      parent.
      
      To calculate the amount of storage required for the parents
      array, `alloc_parents` simply multiplicates the number of parents
      with the respective elements's size. This already screams "buffer
      overflow", and in fact this problem is getting worse by the
      result being cast to an `uint32_t`.
      
      In fact, triggering this is possible: git-hash-object(1) will
      happily write a commit with multiple millions of parents for you.
      I've stopped at 67,108,864 parents as git-hash-object(1)
      unfortunately soaks up the complete object without streaming
      anything to disk and thus will cause an OOM situation at a later
      point. The point here is: this commit was about 4.1GB of size but
      compressed down to 24MB and thus easy to distribute.
      
      The above doesn't yet trigger the buffer overflow, thus. As the
      array's elements are all pointers which are 8 bytes on 64 bit, we
      need a total of 536,870,912 parents to trigger the overflow to
      `0`. The effect is that we're now underallocating the array
      and do an out-of-bound writes. As the buffer is kindly provided
      by the adversary, this may easily result in code execution.
      
      Extrapolating from the test file with 67m commits to the one with
      536m commits results in a factor of 8. Thus the uncompressed
      contents would be about 32GB in size and the compressed ones
      192MB. While still easily distributable via the network, only
      servers will have that amount of RAM and not cause an
      out-of-memory condition previous to triggering the overflow. This
      at least makes this attack not an easy vector for client-side use
      of libgit2.
      Patrick Steinhardt committed
  2. 26 Oct, 2018 1 commit
    • commit_list: avoid use of strtol64 without length limit · 4dddcafb
      When quick-parsing a commit, we use `git__strtol64` to parse the
      commit's time. The buffer that's passed to `commit_quick_parse` is the
      raw data of an ODB object, though, whose data may not be properly
      formatted and also does not have to be `NUL` terminated. This may lead
      to out-of-bound reads.
      
      Use `git__strntol64` to avoid this problem.
      
      (cherry picked from commit 1a3fa1f5)
      Patrick Steinhardt committed
  3. 03 Jul, 2017 1 commit
    • Make sure to always include "common.h" first · 0c7f49dd
      Next to including several files, our "common.h" header also declares
      various macros which are then used throughout the project. As such, we
      have to make sure to always include this file first in all
      implementation files. Otherwise, we might encounter problems or even
      silent behavioural differences due to macros or defines not being
      defined as they should be. So in fact, our header and implementation
      files should make sure to always include "common.h" first.
      
      This commit does so by establishing a common include pattern. Header
      files inside of "src" will now always include "common.h" as its first
      other file, separated by a newline from all the other includes to make
      it stand out as special. There are two cases for the implementation
      files. If they do have a matching header file, they will always include
      this one first, leading to "common.h" being transitively included as
      first file. If they do not have a matching header file, they instead
      include "common.h" as first file themselves.
      
      This fixes the outlined problems and will become our standard practice
      for header and source files inside of the "src/" from now on.
      Patrick Steinhardt committed
  4. 29 Dec, 2016 1 commit
  5. 06 Oct, 2016 1 commit
  6. 28 Oct, 2015 1 commit
  7. 14 Oct, 2015 1 commit
  8. 05 Dec, 2014 1 commit
  9. 04 Feb, 2014 1 commit
    • Replace pqueue with code from hashsig heap · 4075e060
      I accidentally wrote a separate priority queue implementation when
      I was working on file rename detection as part of the file hash
      signature calculation code.  To simplify licensing terms, I just
      adapted that to a general purpose priority queue and replace the
      old priority queue implementation that was borrowed from elsewhere.
      
      This also removes parts of the COPYING document that no longer
      apply to libgit2.
      Russell Belfer committed
  10. 25 Jun, 2013 1 commit
  11. 22 Apr, 2013 2 commits
  12. 08 Jan, 2013 1 commit
  13. 30 Nov, 2012 2 commits
  14. 27 Nov, 2012 1 commit