

XSS vulnerability found in Github - Stuk
https://github.com/Stuk/hackgh

======
pilif
This might look really funny, but consider this: The javascript you are
executing there runs on the github domain. So it can do whatever you can do by
manually clicking.

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.

------
chrisbroadfoot
Seems to be fixed now.

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.

~~~
mike-cardwell
They should be able to look at their database to determine if anyone else has
has used this method to inject arbitrary html into a page in the past.

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.

~~~
tjarratt

         |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.

~~~
bl4k
> that wasn't aggressively used by any would-be exploiters.

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.

------
mike-cardwell
Didn't work for me. Then I remembered to tell noscript to enable js. Does
anyone still need convincing that they should be using noscript?

~~~
redthrowaway
Noscript uses a sledgehammer to do a scalpel's job. It would be much more
widely used if it was a little more subtle, and less noticeable as most
browser extensions are. Scorched Earth-like blocking is safe, but it very
strongly degrades the web surfing experience. I would much rather they use a
heuristics-based approach to warn users when potentially malicious scripts
were trying to run, than simply block all scripts. I used it for a couple
years, but stopped when I realized how annoying it made my browsing
experience.

~~~
jerf
You do realize that NoScript is _not_ "block all scripts", right?

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.

~~~
mrud
> 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.)

Have a look at
[https://chrome.google.com/extensions/detail/odjhifogjcknibka...](https://chrome.google.com/extensions/detail/odjhifogjcknibkahlpidmdajjpkkcfn)
its basically noscript with some restrictions

~~~
InnocentB
This is unrelated, but how did Google manage to produce such awful URLs? Is
this just a base-26 encoded GUID? If so, they could've saved a few characters:
[http://www.wolframalpha.com/input/?i=0xED11C880FA5611DDA6040...](http://www.wolframalpha.com/input/?i=0xED11C880FA5611DDA604001EC203A3AD+in+base+26)

Not that this is something you'd want to do in the first place, because it's
hideous.

------
Stuk
Something @chrislloyd and I found in Github. Nothing too serious!

~~~
mike-cardwell
A nice POC would have been to write some XSS code which adds your SSH key to a
users account if they're logged in when viewing the XSS. I wonder how many
HN'ers that would have affected, and git repositories that would have
exploited.

I don't think it is an exageration to say that an XSS flaw on something like
github has the potential to be disasterous.

~~~
patio11
XSS trivially compromises your cookie. If I have your cookie, I am you.
Demonstrating cute ways to do things that I could just do by logging in as you
is superfluous.

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.

~~~
pilif
you wouldn't get access to the cookie in most browsers. The github session
cookie is apparently marked as httponly in which case JS wouldn't see it.

~~~
patio11
I wouldn't trust that, since there are many paths to the cheese besides
document.cookie. For example, Firefox (IIRC) will let Javascript inspect all
headers from an Ajax request. The cookie is just another string there...

~~~
mike-cardwell
Is that actually possible, or are you just pondering that it might be? If
Firefox lets you access the raw HTTP Cookie header of a http-only cookie via
AJAX, I would consider that a security bug, and report it...

I may take out 10 minutes to have a play with that later if nobody else checks
first...

~~~
patio11
I have personal knowledge that it was possible in 2007. I don't keep abreast
of developments in browser security that make them _more_ secure: unlike, say,
Thomas and the geniuses at Matasano, all I need to know is the worst possible
consequence of whatever our wonderful outsourcing partners dreamed up this
time. XSS was one step below server-side code execution on our severity scale.

[Edit: This was apparently fixed in 2009 in Firefox.
[http://www.mozilla.org/security/announce/2009/mfsa2009-05.ht...](http://www.mozilla.org/security/announce/2009/mfsa2009-05.html)
Again, that is just one vector -- I still think HttpOnly is likely
insufficient.]

------
Garbage
Not working for me. Is it fixed? I can see only JavaScript. IE8 on Windows XP.

~~~
pilif
mouse over the message in the file list.

