nbpoole

As far as I'm aware this is the first time I've been mentioned in a conspiracy theory. So thanks for that. :-)

Interesting: this sounds like a recurrence of the same issue which was described a number of months back:

https://www.digitalocean.com/blog_posts/resolved-lvm-data-is...

At the time, the blog post claimed that the issue was resolved and that data was now being wiped by default. I wonder why that would have changed.

I think tptacek's point is that the answer to your question is spelled out very clearly on the page. ;-)

From the page:

You should own Ferguson and Schneier’s follow-up, Cryptography Engineering (C.E.). Written partly in penance, the new book deftly handles material the older book stumbles over. C.E. wants to teach you the right way to work with cryptography without wasting time on GOST and El Gamal.

Plus a whole section at the end which starts with "If this stuff is interesting to you, here’s some additional reading:"

If that were true it would be a major security vulnerability. ;-)

The Google Translate content is served up from a subdomain of googleusercontent.com. This is a domain designated by Google for user-supplied content so that it can be rendered without affecting the safety of pages on google.com and elsewhere.

The demonstration here is that one page on googleusercontent.com can affect another page on googleusercontent.com. This is perfectly acceptable via the same origin policy.

This was posted yesterday: https://news.ycombinator.com/item?id=6080048

Right. But your post shows that you can reliably get the browser to crash. It doesn't demonstrate that the crash is exploitable, unless I'm missing something.

Right. But I can very easily find reports of reliable ways to crash IE via CSS: https://www.google.com/search?q=crash+ie+css

I don't have a problem with your blog post. It documents how to reproduce the issue referenced in a particular CVE. But I'm curious what value people are deriving from reading it.

Not sure why this is getting voted up so much. The author came across a report of IE freezing/crashing, replicated it, and Microsoft fixed it. In the same security update (http://technet.microsoft.com/en-us/security/bulletin/ms13-03...) there are 10 other vulnerabilities described in the same way. Why is this particular vulnerability noteworthy or interesting, other than the fact that someone stumbled across it and documented it before it ended up reported to Microsoft?

In fact, CVE-2013-1297 from that same security update (which I didn't know existed until now) is far more interesting from a security perspective (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1...).

Microsoft Internet Explorer 6 through 8 does not properly restrict data access by VBScript, which allows remote attackers to perform cross-domain reading of JSON files via a crafted web site, aka "JSON Array Information Disclosure Vulnerability."

Similar JSON information disclosure can be very serious for a web application. http://haacked.com/archive/2009/06/24/json-hijacking.aspx describes the general issue in some depth. The fact that it was possible to use vbscript as a way to read in cross-domain JavaScript is very important from a security perspective.

Luckily, this question has been asked and answered fairly recently!

Specifically https://news.ycombinator.com/item?id=5955043 from last week, complete with a response from Matt Cutts (https://news.ycombinator.com/item?id=5955374):

It's not that PG has a grudge against Google (or vice versa) or anything like that. I believe that search engine bots crawl Hacker News hard enough that PG blocks most crawling by bots. In the case of Google, he does allow us to crawl from some IP addresses, but it's true that Google isn't able to crawl/index every page on Hacker News.

Here's a link where I answered the same question about three weeks ago: https://news.ycombinator.com/item?id=5837004 , so this isn't a new issue. In fact, PG has been blocking various bots since 2011 or so; https://news.ycombinator.com/item?id=3277661 is one of the original discussions about this.

And to show this isn't a Google-specific issue, note that Bing's #1 result for the search [hacker news] is a completely different site, thehackernews.com: http://www.bing.com/search?q=hacker+news

In general, I think PG's priority is to have a useful, interesting site for hackers. That takes precedence and is the reason why I believe PG blocks most bots: so that crawling doesn't overload the site.

I believe that's how Rails works, except using an HMAC on the cookie instead of AES (since AES itself doesn't prevent tampering).

You can't just read cookies for arbitrary domains in an iframe.

Not in general, no. You can drop replay protection as a requirement and that gets you to actual statelessness. If you then have your website on a single domain and never put anything else onto other subdomains, theoretically now the only risk is that your single application is vulnerable to XSS. But you shouldn't build your security based on assumptions like that if you can help it.

"Stateless" CSRF protection as described here is strictly inferior to other forms of protection. The reasons are somewhat laid out in this blog post's comments:

1. JavaScript in any subdomain allows a cookie to be set on unrelated subdomains. That means an attacker can set a token and override the CSRF protection entirely.

2. The "replay protection" means that you must continue to maintain state on the server (ostensibly to prevent duplicate requests)

The author has actually gone on to propose a "triple submit" system for CSRF protection (http://www.slideshare.net/johnwilander/stateless-anticsrf) which is still vulnerable to compromise if a related subdomain can be used to attack by setting many cookies.

For a more thorough discussion of CSRF mitigations, check out https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

"This wouldn't happen if Yahoo had a Vulnerability Reward Program"

As much as I support these kinds of programs (https://nealpoole.com/blog/responsible-disclosure-programs/), that's a false dichotomy. Some companies have responsible disclosure policies or vulnerability reward programs. Some companies don't.

Anecdotally, the companies that do have programs don't inherently respond more quickly or handle reports better (ie: https://nealpoole.com/blog/2013/04/experiences-with-the-yand..., https://nealpoole.com/blog/2013/03/csrf-persistent-xss-in-my...). In contrast, companies that don't have programs may still be very responsive and willing to work with researchers; I reported issues to GitHub, Etsy, and Facebook before their respective programs were in place and they always responded quickly and effectively.

It comes down to the people who focus on security at the company and the way in which security is prioritized. If your company doesn't value and prioritize security, a responsible disclosure program won't make anyone's life easier.

In that sense, I do think that companies can and should do a better job of working with security researchers, regardless of whether they have a responsible disclosure program or vulnerability reward program in place. If a company takes security seriously, it should make it easy for researchers to report vulnerabilities. Researchers shouldn't feel that their reports are being sent into a black hole: if they do, they'll be less likely to spend their time reporting issues in the future.

I encountered the same problem on a site I run where I provide custom subdomains. The RFCs technically prohibit underscores but they appeared to work fine in the major browsers, with the exception of cookies in older versions of IE (ie: http://stackoverflow.com/questions/794243/internet-explorer-...). I ended up munging underscores to dashes to make everyone happy.

Please don't presume to speak for me. I left Matasano because I was returning to school; I greatly enjoyed my time there and I keep in touch with everyone I worked with because they are a group of intelligent, kind, and all around awesome people.

Also, I wholeheartedly endorse Tom's responses to your insinuations.

Hmm, a majority of passfree's account's submissions (20/25) appear to be for websecurify.com. Combined with the dismissal of Burp as "java madness," seems like a socketpuppet on behalf of the company.

Ex-Matasano chiming in! ;-)

I've been demonstrating web app security topics for the Intro to Security course at Brown University this semester. I've used Burp almost exclusively. I've even had the students use the free version of Burp for labs. I don't know that the functionality / price tradeoff would make sense for them even if they were full time freelancers: they use Repeater and Proxy more than any other tools.

That being said, any time someone complains about it being too expensive I point out that a single vulnerability found as part of a security bug bounty program (ie: Google, Facebook, Mozilla, etc) nets you more than the cost of a license.

This is an (unfortunately) fairly common class of vulnerability. Many applications fall victim to this form of attack because they don't think to check signatures on binaries. There is a tool, EvilGrade (https://code.google.com/p/isr-evilgrade/), designed to assist in demonstrating these types of attacks.

This reminds me of a post a few months back about Voyager 2, where NASA traced the issue back to a single bit flip (and fixed it!)

Engineers successfully reset a computer onboard Voyager 2 that caused an unexpected data pattern shift, and the spacecraft resumed sending properly formatted science data back to Earth on Sunday, May 23. Mission managers at NASA's Jet Propulsion Laboratory in Pasadena, Calif., had been operating the spacecraft in engineering mode since May 6. They took this action as they traced the source of the pattern shift to the flip of a single bit in the flight data system computer that packages data to transmit back to Earth. In the next week, engineers will be checking the science data with Voyager team scientists to make sure instruments onboard the spacecraft are processing data correctly.

http://news.ycombinator.com/item?id=1459328

The hosting companies I've used (eg: Linode, Dreamhost for smaller projects) all provide DNS services. I trust them to manage a DNS infrastructure more than I trust myself.

Some previous discussion on this issue (almost 2 years ago):

http://news.ycombinator.com/item?id=2443710

I'll say the same thing I said then:

As an anecdotal counterpoint, I'm an extremely happy Name.com customer. I transfered several domains to them a year or so ago from GoDaddy. They support two-factor authentication, their interface is uncluttered, I pay them less money than I paid GoDaddy, and I haven't had a single issue. I would highly recommend them to anyone looking for a registrar.

That being said, I don't use them for DNS. If this is a feature of their nameservers, I do find it strange that they don't offer a way to opt out (other than using alternative nameservers).

I am still an incredibly happy Name.com customer and would recommend them as a registrar to anyone who asks. I just would point them somewhere else for DNS hosting.

Example: http://www.idontplaydarts.com/2010/07/mongodb-is-vulnerable-...

I think the CVE description is inaccurate in this case. Check out the Rails security email list description, which never mentions sessions.

https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

This is actually several months old:

http://www.theverge.com/2012/9/21/3369878/facebook-saves-you...

> The default privacy setting for searches is "Only Me," and cannot be changed unlike the privacy toggles of other Activity Log entries. But, you can delete any searches you want to hide from yourself. The idea is to provide added context and transparency to using Facebook, as well as provide you with complete control over every single thing you do on the site, like searches — which apparently we're doing a lot of.

First idea that comes to mind: http://stackoverflow.com/questions/3837043/best-practice-for...

Anecdotally I've seen similar bad behaviors in a lot of bug bounty programs:

- I haven't submitted to PayPal, but I do have a minor eBay XSS which I reported in May (eBay doesn't have a bounty program, but they do have a responsible disclosure policy: http://pages.ebay.com/securitycenter/Researchers.html). The last time I asked if the issue was patched I was told "Not yet. We'll let you know when this is resolved." This was in June, I haven't re-tested recently.

- When CCBill had a bug bounty program I was able to gain access to their admin panel because it was publicly accessible and linked to via a directory index. That followed a story similar to the one here (I reported it, it was rejected as a duplicate, I followed up about a month later when it still wasn't patched and they quietly patched it and paid me money)

- Yandex recently launched a bug bounty program. So far I've submitted 3 or 4 issues. I've only heard about one of them: it was marked as a duplicate, which is fine, but weeks later the issue still isn't patched.

That being said there are companies like Google, Mozilla, Facebook, Etsy, GitHub, Reddit, and many others which take responsible disclosure of security issues seriously. But it does seem like certain companies need to re-examine how they handle reports from external researchers.

I have no Django experience, but I can imagine how an attack like this works:

1. Links are rendered via some function that takes into account the user's current request (ie: to determine the proper host)

2. The "reset your password by clicking this link" URL is generated using that function.

3. I am a malicious attacker and I submit a password reset request for your account.

Thus, I can control the URL that is sent to you in an email.

> We don't post anything without your explicit permission on the page following authentication.

Respectfully going to disagree on that one. The "Unhack" button doesn't seem to have removed any content from my profile but it did post a link on my timeline promoting the app (and using the old URL and name). Definitely not expected behavior.

    Mess With Your Friends | BuddyHack
    buddyhack.com
    "Sorry guys, I just got Buddyhacked. Whoever it was, I will find you, and I will get you back."

From the homepage: "BuddyHack: Did a friend leave Facebook open? Mess with it now."

It's an app designed to be authorized on someone else's account. You make that pretty clear.