Back in March, a security professional found out something rather disturbing about Git, one of the leading version control systems on the web: a pair of vulnerabilities that left untouched could bring down entire servers.
You may be wondering why that’s so distressing. After all, vulnerabilities are nothing new, right? No piece of software can be considered truly secure.
The fact that these flaws exist isn’t the troubling part. It’s the fact that they’ve existed in the application, unpatched, for several years. And they’re present in multiple branches, including 2.x, 1.9, and 1.7.
What Are The Vulnerabilities?
What makes these bugs so serious? If exploited, how can they be used by an attacker? Chris Williams of The Register offers a good explanation:
“It is possible these two programming blunders can be potentially exploited to corrupt memory or execute malicious code on remote servers and clients,” writes Williams. “To do so, an attacker would have to craft a git repository with a tree of files that have extremely long filenames, then push the repo to a vulnerable server or let a vulnerable client clone it from the Internet.”
The bugs, which were discovered by Laël Cellier(who received a hefty reward through Git’s Bug Bounty program), are both located in the function path_name() which appends a filename to the end of a path in a repo tree. By allocating memory for NULL-terminated strings, filenames can be copied to the end of said strings. The good news is that as of 2.8, they’ve been patched out.
The bad news is the damage they can cause in unpatched applications.
“There is a lot of danger here: the string length variables nlen and len are signed integers rather than unsigned,” Williams explains. “They can be positive and negative, and are in this case susceptible to integer overflow. If strlen() is passed a very large filename and returns a very large number, nlen will overflow and be negative rather than positive. That’ll make len negative too, at least to begin with, and xmalloc() could end up being called to allocate too few bytes for the final combined string.”
“Next, the code strcpy(), which is extremely risky as it invites buffer overflows,” he continues. “It will blindly copy from the large attacker-controlled filename over the small amount of heap memory allocated until it hits a NULL byte, causing a heap overwrite, and thus allows the attacker to manipulate the program’s data structures.”
It gets worse. More recently, it was discovered that Mac OS X distributions of Git were shipping with the exact same vulnerability discovered by Cellier. They were insecure right out of the box – and many aren’t even aware of that fact.
“If you rely on machines like this, I am truly sorry. I feel for you,” Kroll writes in a blog post. “I wrote this post in an attempt to goad them [Apple] into action because this is affecting lots of people who are important to me. They are basically screwed until Apple deigns to deliver a patched git unto them.”
How Can You Protect Yourself?
The good news is that the two bugs – including the ones in Apple’s distribution of Git – have now been patched out. I’d advise you to update to the latest version of Git immediately. Otherwise, you’re essentially operating with a big target painted on your back, especially now that knowledge of the vulnerabilities is now out in the wild.
But what can you do beyond patching now? Is there any way to protect yourself from vulnerabilities like this that doesn’t involve relying on vendors to keep up with security? After all, it’s not as though they’re entirely liable for vulnerabilities in their software, right?
In all honesty, the best advice I can give you here is to always keep one ear to the ground. Pay close attention to news in the tech industry, and whenever a vulnerability surfaces, adapt your tools and business processes to mitigate it until it’s patched out. That might sound exhausting, but it really doesn’t need to be – allow me to explain why.
Automated Security and You
At the end of the day, human beings are fallible. We make mistakes. We’re slow to react in a crisis situation. Small details often escape our notice.
Taken together, what this means is that in the event of a breach – or even in the event that a vulnerability surfaces – we may not be capable of reacting quickly enough to mitigate the potential damages. Consider: 95% of all security incidents involve human error, according to IBM.
Sort of a staggering figure, isn’t it?
Here’s the good news: by automating your security infrastructure, you can cut down on human error, improve your response to security incidents, and ensure that if there are unpatched vulnerabilities in your system, they’re eliminated the moment a patch becomes available.
By automating incident response, deployments, monitoring, and infrastructure buildout, you’ll be able to create a better, more ironclad system.
Git’s vulnerabilities are really nothing new – no software instance is 100% secure. They are troubling, however, even if they’re now patched out. Take the advice we’ve laid out in this article: these aren’t the first security bugs that could put your organization at risk, and they most definitely won’t be the last.