Security of GitHub.com

Question

Recently some non-technical managers where I work found out that GitHub has a repository with code from "Hidden Tear" which is a ransomware application. The immediate reaction was to ban GitHub, which is something that we use extensively to get open source code. The only way to access GitHub again is by proving that the site is safe. This would be easy to do if I were convincing software developers, however I am speaking with people who have never written a line of code. I have been told that if I want to use code from GitHub or view pages on the site I need to do the following:

1. Show the site is safe and will not infect our computers
2. Create an open source policy for use when determining the safety of code found on GitHub.

My first step was to go through a list of companies and government organizations that use GitHub. I believe that this will start to calm fears that the site is going to infect all computers with ransomware. I will expand on this by describing what GitHub is, what it does and why it is valuable.

The problem is that I don't have much experience writing policy documents. I'm hoping to find someone with some knowledge about policy that could share some of their experiences in writing open source usage policy. From what I understand our policy should be a step by step guide to determine whether or not we can use a specific library/plugin.

Answer 1

I'm a solo programmer, not any firm. But suppose if I were to form a small firm tomorrow and decided to write a security guideline regarding what to allow/disallow from github, it will be implemented something like this:

1. Only allow github.com domain and not github.io. Reason is that the latter is a web-hosting playground where any random developer can place any random javascript to be executed like some others have said. The former, on the other hand, is from the official company and relatively safe.

2. Create a policy to blacklist/whitelist downloads with certain extensions. EXE and DLL are the worst if you are on windows platform as these are arbitrary binaries that can just do anything on your machine including causing havoc. If you are as paranoid as me, you will take the whitelist approach and just ban everything except the ones that you need (for example, .php, .py, .js, .html, .css, etc. if you are running a FOSS project).

3. Create a policy to install only from the official sources. On Windows machines, not giving admin rights to your every user should be a norm. Only personnel from IT depts should do that, so the user can't cause any damage to their systems even in the rare instance that they did end up downloading something bad.

4. Create a policy to maintain a list of developers who are granted commit access to the git repositories. Don't give any commit access to the main repos unless it is absolutely necessary. If possible, include a code-review process in workflow whereby, the dev sends a pull-request and reviewer later integrates the code after a thorough check. This process will ensure that no malware gets through past your build process, either wittingly or unwittingly.

5. Create a policy to revoke commit access as soon as a dev leaves the firm. This will ensure that no "blame-game" takes place that usually happens when a dev leaves a company.

Answer 2

1. Show the site is safe and will not infect our computers

It's not "safe". GitHub allows anonymous users to upload anything they want including malware. You could get infected by downloading/executing code or visiting anything on the "github.io" domain where arbitrary javascript (and therefore 0-day browser exploits) might be found (github.com is safer than github.io).

2. Create an open source policy for use when determining the safety of code found on GitHub.

The only way to determine the safety of source code is to go through one line at a time and carefully read every single line.

With major projects, you might assume somebody else has already done this, but that's not a safe assumption. For example OpenSSL's security was completely compromised in 2011 but code reviewers failed to notice the problem until 3 years later. Criminal organisations were aware of the problem long before it was fixed and companies were compromised.

Small businesses using open source Word Press plugins are continuously being hacked, we see it almost every day where I work. Smart companies avoid the problem by refusing to use random word press plugins and your company policy should be the same.

---

In general there are two things you need to worry about:

1. The most scary is an actively malicious attack, for example in 2013 a version of phpMyAdmin was being distributed with a "sync_server.php" script who's entire purpose was to execute arbitrary PHP code provided in POST.

2. More common than that and your primary concern, is plain stupidity. There is a ton of open source code available online containing serious security flaws that are almost as bad as an intentional back door. Far too often these issues are not discovered until organised crime starts taking advantage of them – and they usually attack individual companies rather than the entire internet, further increasing the chances that they can attack over and over again before the bug is discovered/fixed.

---

What you need to do is make a risk/reward analysis. Outline the risks of allowing access to GitHub in detail, and then outline the rewards, and conclude with your case that the rewards outweigh the risks.

Developers should not be allowed to use code on GitHub (or from anywhere else) unless they understand the risk and each project's quality must be judged individually. How strict your policy is should depend on how much harm would result in a successful attack.

The largest and most successful corporations in the world have all decided that the rewards outweigh the risks – doing so is necessary to remain competitive. But don't pull in open source code lightly.

Answer 3

There is a giant problem with the logic behind this fuss. Storing the source code of malware is not strongly correlated with being infected with malware.

Consider http://www.metasploit.com/. It's a tool used by people protecting against intrusion -- and also by people looking to perform intrusion. Or any number of other resources used by people who study malware.

Yes, github.com could turn out to contain active malware -- but so could anything else where arbitrary websites are hosted. Does your management prohibit access to all of AWS? Google apps? Heroku? Sourceforge? Bitbucket? There's a list of about a million places that allow people, including bad people, to set up web sites. Does your employer really maintain a white list of only sites that they like? And what do they do when one gets broken into, and turned into a malware distribution apparatus?

So, this has nothing much to do with open source, except insofar as github.com is a hard place to avoid if you want to use it. You could have this debate about every wordpress blog site in creation; those get compromised approximately once every five minutes.

Answer 4

Perhaps you could get access approved on a per-project basis on GitHub? For example, say you wanted to use code from https://github.com/google/zopfli you could somehow get that approved and then be able to download/use the relevant files. Annoying, but better than having to write 100% of your code from scratch.

Also, if they're particularly concerned about ransomware, something like first testing code in a VM that can be trashed at a moment's notice might help them to feel like it's safer?