On March 9, GitHub officially released a patch against the CVE-2021-21300 vulnerability. It turns out that this popular distributed version control system, which as its name suggests is based on GIT, was susceptible to a very nasty exploit.

As you probably know very well, GitHub is currently used by software developers all over the world. Many of the repositories based on GitHub have LFS (Large File Storage) enabled, and this is understandable. Thanks to this option, we run the so-called large file storage, and thus we can better manage and optimize our repositories containing, for example, PDF files, etc. No wonder that many companies use such a facility. The problem along with LFS we enable the use of the clean / smudge filter. Now it is enough for our server to be installed with the NTFS, HFS +, or APFS file system, i.e. on a system installed with a default file system such as Windows or macOS. At this point, we have a prepared environment for the attacker.

Get free trial

…it doesn’t take much to lose entire repositories

Although this exploit requires symbolic link support on the server, GitHub has this feature enabled by default. More specifically, it was just turned off in the newest version of GitHub, because the GitHub team currently disables the use of symbolic links globally from March 9, and this is “the patch” for mentioned vulnerability proposed by them. Below is an example of a crafted code that will execute an unwanted command:

  #!/bin/sh
 
  git init delayed-checkout &&
  (
    cd delayed-checkout &&
    echo "A/post-checkout filter=lfs diff=lfs merge=lfs" \
        >.gitattributes &&
    mkdir A &&
    printf '#!/bin/sh\n\necho PWNED >&2\n' >A/post-checkout &&
    chmod +x A/post-checkout &&
    >A/a &&
    >A/b &&
    git add -A &&
    rm -rf A &&
    ln -s .git/hooks a &&
    git add a &&
    git commit -m initial
  ) &&
  git clone delayed-checkout cloned

True, it doesn’t take much to lose entire repositories. Sometimes losing everything isn’t as painful as, for example, deliberate code implemented without our knowledge by a hacker added to our every app. You can imagine that each of our applications released for production has a code that allows third parties to view and manipulate its data. Of course, in utopia, we all have time to review exploits, update the latest software releases and security patches as soon as they come out. The truth is that, firstly, it’s hard to prepare for 0day hacking, and secondly, there is a mass of yet undisclosed vulnerabilities everywhere, so we must be ready for every scenario.


How secure are your repos and metadata? Don’t push luck – secure your code with the first professional GitHub, Bitbucket, and GitLab backup.


Time for a Change – make it with GitProtect

On March 31, we celebrated world backup day. Personally, I think every day should be a backup day, and a day without an up-to-date archive should never happen. With this kind of slogan on banners Xopero, which is currently preparing for the official release of GitProtect powered by Xopero ONE, meets us. This application will focus on archiving your repositories in the background and without your involvement. The most important thing, however, is that when properly set, it will allow your company to always be prepared for unpredictable attacks.

In the next few blog entries, we will present a tool that allows you to focus on work and our clients, and not on feverishly looking for help. One of the key, if not the most important, task in the company is to protect intellectual property, and thanks to GitProtect, we and our team will be able to sleep well. Let’s add that this tool will allow for the verification, auditing, and reporting of the state of our archives and we have a complete package closed in one application preparing us for all scenarios.

Comments are closed.

You may also like