"I reported the fixation issue privately only because I'm a good guy and was in a good mood."
I for one am glad that Homakov decided to share and write about these security issues rather than just selling it to the highest bidder. I have learned quite a bit over the past year. And it's deplorable that Github isn't paying anything.
In negotiation theory your 'BATNA' or 'Best Alternative To Negotiated Agreement' is the second choice you'll go with if the current negotiation breaks down. Theoretically, neither party in a negotiation need accept less than their BATNA.
For example, when you negotiate your annual raise, your best alternative is the raise you could get by moving to another employer (adjusted for benefits, time spent commuting, how fun the job is etc). You don't have to explicitly say to your boss "give me a raise or I'll quit" - your boss just needs to know your options are open.
If homakov publicly says he'd never consider selling an exploit, he's saying his BATNA is $0 and some kudos on Hacker News. If he says he's undecided, his BATNA would be somewhere between a few thousand and a few hundred thousand dollars. Needless to say, the former statement closes off a lot of negotiation options while the latter leaves them open.
Oops, looks like my tweet (the "open-source GitHub") got a bit more famous than I thought. I feel I must write a big disclaimer here:
I was just joking and would never actually exploit someone that would do so much damage. I was merely commenting on the irony of leaking GitHub on GitHub. Don't fucking do this. It's not fun.
Wow Homakov, other great write up! I'm really interested in what resources you used to learn all this stuff! Would you mind doing a "recommended books and blogs" post anytime soon?
honestly, i didn't read a single book about web sec. I just learn things one by one and if something looks weird i investigate. This is why sometimes i publish "known" stuff.
You can sign up for Cryptography courses at Coursera.org. You learn about basic tenets of crypto like attacker games, cryptogaphic advantage, cracking some exploits (AES-CBC). If you do the problem sets and programming assignments and pass the course without help, you are off to a very good start I would say.
Another interesting post from homakov. Thanks so much for posting these as I learn a lot.
A few months back didn't your blog do something devious to people who read it? (Oh, yeah! It was signing people out of their Google accounts, I think?) Anyway, now I'm leery of clicking any links to homakov.blogspot.com.... :-p
I do think I'm safe from you, though. I browse with cookies off, NoScript enabled (except for small whitelist), and RequestPolicy blocking cross-site requests. Homakov, can you think of any sort of exploits I'd be vulnerable to when browsing the web?
Ha, well in some ways the web is better: I generally don't get ads or annoying pop-ups or social sharing widgets, etc. CSS is often on a separate domain so most pages are unstyled and ugly, but pretty easy to read (usually just black text on white background).
But the downside is I had to open this page in a different browser to reply to you just now. And things like Gmail, GitHub, etc, I use in my other browser, but I try to keep the sites I use "unprotected" to a minimum.
I am not an expert in security but when I started using github pages a week ago. When I realized I could put any Javascript on the github.com domain I thought: good luck with making this secure.
Alright... what if they could only change the CSS, and not the HTML and JS? (Obviously not a solution for Github pages, but workable in some scenarios)
Does this mean all domains which allow arbitrary JS on subdomains are vulnerable? Is this why heroku app domains are x.herokuapp.com and not x.heroku.com?
This is not new[1], but interesting that github didn't think about this when they set-up gh-pages.
It's hard to blame them though. Security is easy to miss. Myself and many other people who use github, and who understand those issues, don't really think about it until someone points this out...
Saying that it's not new wasn't meant as a criticism for your discovery of this happening on github. Quite the opposite.
It's more of an observation on how even well-known security vulnerabilities can go overlooked. Even by companies with as big exposure and as many resources as github.
Wouldn't a solution be for the server to set its session cookie for every subdomain, as HTTP-only? For example, set "_gh_sess" for every requesting domain, whether www.github.com, github.com, something.github.com; and ".github.com" as well. If you hit them all, you prevent js from shadowing them.
Github only sets their cookie for "github.com". What I'm suggesting is that they set multiple http-only cookies: one for "github.com", one for ".github.com", another for every subdomain you access -- "pages.github.com", etc. If there's already an http-only _gh_sess cookie for every subdomain I can put scripts on, I won't be able to shadow it with my own _gh_sess cookie.
Got it, thanks. More detail at [1] mentioned by gingerline above: "the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection."
What is the difference between allowing users to put custom JS on a subdomain, vs. someone just opening up the developer console and running whatever JS they like? Does JS loaded from the server have different privileges to JS entered at the console?
The difference is, I can put custom JS on my Github page and send you a link, when you open it you run code I authored.
Developer console is just me running code, and is also on any arbitrary domain on any site.
My understanding of this article was that he pulled off the hack entirely by himself, without having to get someone to visit his page. Maybe I misunderstood.
What you're referring to is a self-XSS. They were a lot more common back when you could run JavaScript from the address bar.
These days if you try and paste JavaScript to your address bar (try it with: javascript:alert(1);) then the browsers try and stop you. Firefox just won't execute any JavaScript, even if you've manually typed it. IE and Chrome strip the "javascript:" prefix (but Chrome is vunerable if you type "j" and paste the remainder).
Bitbucket supports private repos aswell and works with mercury and Git afaik. The main reason GitHub is popular is because it is popular; it just happened.
Given the first vulnerability, which stemmed from poor defaults in Rails and Github using said defaults, I wouldn't be surprised if it were affected by this.
Not using attr_accessible is a lot different than not using reset_session after authenticating a log in. It's very easy to forget or not notice a model missing some whitelisting but to roll your own authentication code with zero security investment is just stupid and I would be extremely surprised if GitHub doesn't do it.
I for one am glad that Homakov decided to share and write about these security issues rather than just selling it to the highest bidder. I have learned quite a bit over the past year. And it's deplorable that Github isn't paying anything.