Critical Security Release for GitLab 8.2 through 8.7

Gitlab can be run on Sandstorm.io (of which I am tech lead / co-founder). Sandstorm claims to mitigate most vulnerabilities in apps:

https://docs.sandstorm.io/en/latest/using/security-non-event...

Let's see how it scores here...

For background, on Sandstorm, each Gitlab project is placed in a separate grain (container), isolated from all others. In order to communicate with a grain at all, you must have been granted some level of access to it by its owner -- Sandstorm does not let you send requests to private grains to which you haven't been given access. So, private Gitlab repos hosted on Sandstorm are basically not vulnerable to any vulnerability.

Of course, Gitlab is the kind of thing you might intentionally make public to all, e.g. to host an open source project. Therefore, it makes sense to analyze whether a public repository would be exploitable.

    Privilege escalation via "impersonate" feature

On Sandstorm, authentication is handled by Sandstorm. The app receives an unspoofable header indicating which user the request came from, and what permissions they have. A well-written app uses this header on every request to authenticate the user.

Unfortunately, our Gitlab package currently uses this information only when a session first opens, then relies on the session cookie going forward. This pattern is sometimes used as a "hack" on Sandstorm to more easily integrate with existing login code designed to do upfront / one-time authentication. As such, public Gitlab repositories hosted on Sandstorm would be vulnerable.

Had Gitlab on Sandstorm been implemented "properly", it would not be vulnerable. That said, the "impersonate user" feature would not have worked at all. That's probably for the best: a feature like this really ought to be implemented by Sandstorm itself, which would have the ability to implement it (securely) across all apps at once, rather than have each app implement its own version.

Somewhat embarrassingly, the Sandstorm package of Gitlab actually predates this feature being added, therefore Gitlab instances on Sandstorm today actually aren't vulnerable. (Generally, if the upstream app author does not directly maintain the Sandstorm package, then the Sandstorm package will tend to fall behind. This should get better as Sandstorm gains popularity and upstream authors target it explicitly.)

    Privilege escalation via notes API
    Privilege escalation via project webhook API
    Information disclosure via project labels
    Information disclosure via new merge request page

These vulnerabilities allow a user to manipulate a private project to which they aren't supposed to have access. On Sandstorm, a private project would live in its own grain, and if you hadn't been given access then Sandstorm would deny you the ability to talk to the grain at all. Therefore, these cannot be exploited.

    XSS vulnerability via branch and tag names
    XSS vulnerability via custom issue tracker URL
    XSS vulnerability via label drop-down

These vulnerabilities require that you have write access to one project on the server in order to launch an attack. On Sandstorm, since every repository is its own instance, the attack would be limited to the repository on which you have write access -- you would not be able to use this attack to damage someone else's Gitlab repository on which you lack write access.

    XSS vulnerability via window.opener

This is a subtle phishing issue that is very widespread. However, it mostly doesn't work when the opener is a sandstorm app: the app lives inside an iframe which is prohibited by Content-Security-Policy from browsing away from the server.

    Information disclosure via milestone API
    Information disclosure via snippet API

A public project hosted on Sandstorm would be vulnerable to these (leaking confidential issues attached to public milestones, and leaking private snippets attached to a public project). Sandstorm can only enforce access control at the grain level; anything finer than that is up to the app, and is subject to app bugs. I generally recommend that Sandstorm users try to put confidential data in separate grains from public data -- e.g. creating a separate issue tracker for confidential issues.

(The Sandstorm packaging again predates the milestone bug's introduction, though may be affected by the snippet issue.)

We will update the Gitlab package tomorrow. Once an update is pushed, every Sandstorm user will receive a notification within 24 hours and can apply the update with one click.

Conclusion: Sandstorm mitigated 8/11 issues by design, 2/11 by accident, and is vulnerable to 1/11. The biggest issue was only mitigated by accident in this case, although a well-behaved Sandstorm app normally wouldn't have this kind of issue by design. Overall, though, I'm disappointed in Sandstorm's performance here -- it's much worse than the usual 95% mitigation rate.

Not been tracking GitLab closely but how many critical issues have there been in the last 6 months?

Github isn't open source.

From https://sandstorm.io/install

> Run this in a terminal:

> curl https://install.sandstorm.io | bash

kthxbye

I get what you're trying to say, but how is it more insecure than doing "git clone; make; sudo make install" or double-clicking on a NSIS installer ?