XSS vulnerability found in Github
github.com
github.com
The injected script could for example submit a new SSH public key for your account (doesn't require your password again). Or just be funny and delete repos. Or just upgrading your account to a bigger, more expensive plan.
Or they could get a list of your private repositories. Combine that with the upload of a new private key and you'll get free access to proprietary code of any account.
Aside of fixing the XSS issue, they really should ask for the password again when uploading a public key.
Quick work by the github guys, kudos.
For those who missed it, the title attribute inside commit messages in the file list wasn't HTML encoded.
They should then put up a notice on their website to describe what happened, describe how they confirmed that this flaw hasn't been exploited previously, and describe what measures they will take in future to prevent this sort of problem.
In my opinion, that is how a "good", company would react. Anything less would be a disappointment.
|In my opinion, that is how a "good", company would react.
This is (more or less) how Github has reacted to security issues in the past. However, at the moment this seems to be a fairly small exploit, that wasn't aggressively used by any would-be exploiters. I definitely don't think github should put up a notice for this.Would you really want to be alerted every time a website you used closed a minor security hole, that had possibly never even affected anyone? They absolutely should, if any user information was leaked, or if there was downtime involved, but you honestly do not need to keep informing users about this sort of mundane security update. At best, I would suggest it go on their blog.
Not reporting "oh we found an xss hole that maybe one or two people had used before." is NOT a disappointment.
Doesn't matter. A response shouldn't be measured according to how widely a security hole was exploited, it should always be responded to with full information and transparency.
I see so many people criticizing it with no apparent experience or use of it, and this is the primary misconception I see. It is not block all scripts. Why would anyone need an extension for that? You just turn off Javascript in the preferences for that. What it is is a domain-by-domain whitelister.
I can't use Chrome because it doesn't have NoScript, and I end up routinely visiting domains that I didn't even realize have some foreign-loaded script that pops up some crappy survey over the page ("please give us your private info under the guise of providing site feedback we intend to ignore!"), or pops up a flash ad, or who knows what. The web is too irritating to use anymore without it. (And Flashblock.)
Also, NoScripts does have heuristics, but they can't catch already-in-the-page XSS without firing too many false positives. They do have some decent protection against hostile links that have XSS-inducing strings in a query string or something. You can in fact download NoScript and configure it just for that. Personally, I've never had anything but a false positive from that check, but I don't cruise fora where such links are common.
It isn't anywhere near as hard to use as the critics say it is. I know this because I use it on three systems and I don't even bother trying to synchronize the settings somehow; it's more work to synchronize the settings that just use it in all three places.
Domain whitelisting is useless in situations like this, as sites like Github are likely to be in a frequent visitor's trusted sites list.
Have a look at https://chrome.google.com/extensions/detail/odjhifogjcknibka... its basically noscript with some restrictions
Not that this is something you'd want to do in the first place, because it's hideous.
Actually, I didn't. You do realize that the name "NoScript" implies NO SCRIPTS, right? It shouldn't be surprising that many people think it makes your browser execute "no scripts".
well, isn't it? Kidding, kidding.
Mostly I browse to read, and NoScript eliminates a ton of pointless HTTP requests and CPU cycles.
Deleted comment
The reason is simple: JavaScript actually has a security model and browsers are one of the few bits of software with widely used update systems; plugins and most other applications are much easier targets (all of that juicy native code not coded defensively) and drift horribly out of date.
So, yes, put me firmly on the list of people who find NoScript 70% PR, 20% clunk UI, and 10% meaningful improvement. Something like Chrome's sandbox and click-to-play will actually make a noticeable benefit for the web because it'll actually be used - and even that's somewhat minor since we're still losing the user education battle where most exploits are actively assisted by the user.
Some bits of github don't work unless you enable JavaScript, but most of it does. So I only enable it when I'm using those bits.
I also make sure I log out of github before I start browsing other websites.
* IE for two banks
* firefox+adblock for gmail, github and chesscube
* chrome for facebook
* opera for everything else, which includes HN.
Just looking back at that list makes it seem even more terrible than it actually is :(Don't get me wrong, I can appreciate reducing your attack surface... but noscript just doesn't seem like that great of an idea, still.
Humans are quite irrational sometimes...
I don't use the twitter.com website any more. Prefering to use clients that don't run JavaScript. Whenever I can use something other than a web browser to access a service, I will take that path. I use NoScript when that isn't an option.
I also found (and reported responsibly) an XSRF flaw in Linode.com a few months back that I believe has now been fixed. That was quite a dangerous one. I also found an XSS flaw in DuckDuckGo a few weeks back. Maybe this is the reason I'm so "paranoid" about JavaScript. Maybe I'm right to be.
When I try to explain this to friends, they respond with, "No, it's only on that webpage I visit."
I don't think it is an exageration to say that an XSS flaw on something like github has the potential to be disasterous.
Even doing that as a prank would cause a Big Red Button security audit at some companies. As in, drop what you're doing, we need to go over every line of every commit in the git repo and verify nothing like a server password was committed. Recommendation #1 from that audit will be to stop using github.
We know that the two scenarios (ssh key injection as a prank and what happened here as a prank) are equivalent.
If a company reacts like that in your scenario but doesn't do the same after what really happened, they're doing something very wrong.
I may take out 10 minutes to have a play with that later if nobody else checks first...
[Edit: This was apparently fixed in 2009 in Firefox. http://www.mozilla.org/security/announce/2009/mfsa2009-05.ht... Again, that is just one vector -- I still think HttpOnly is likely insufficient.]
The big security hole, as alluded to above, is that Firefox (and presumably Opera) allow access to the headers through XMLHttpObject. So you could make a trivial JavaScript call back to the local server, get the headers out of the string, and then post that back to an external domain. Not as easy as document.cookie, but hardly a feat of software engineering.
http://www.codinghorror.com/blog/2008/08/protecting-your-coo...
Sess cookie for github is km_ai
_github_ses
which is the only one that's set as both httponly and secure and, by the way, doesn't appear in document.cookie
If I do an XSS attack against you on github whilst you are logged in, I can compromise all of your source repositories, your code, and in turn, potentially compromise the systems of your users.
Cute use of rickrolling btw. :-)
Deleted comment
Deleted comment
Nice delete.
since you were so incensed by my irresponsible, unethical, and down-right evil behavior, that you saw fit to call me a 4chan script kiddie (horrors!), just thought you'd like to know:
From: "Chris Wanstrath" <chris@redacted.org>
To: mml
Subject: Re: security hole
In-Reply-To: <0228F552-5269-4F44-9D77- 82F077DE2242@redacted.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <0228F552-5269-4F44-9D77-82F077DE2242@mml>
Thanks, fixed!
On Wed, Mar 26, 2008 at 3:54 PM, <mml> wrote:
> hi,
>
> github needs to clean up it's xss act:
>
>
> http://github.com/redacted
>
>
> -mml
--
Chris Wanstrath
http://github.com/defunkt
Cheers,-mml
Anyway, thanks for clearing this up!