Fixing responsible disclosure

Today I had the pleasure to post:

http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html

It is co-signed by some of my awesome fellow engineers who personally believe in what is written.

Recent discussions and debates have shown that "responsible disclosure" is broken. It is badly named and ill-defined. Possibly the worst problem with responsible disclosure is that is permits known critical vulnerabilities to go unfixed for months or even years. As many commentators have pointed out, that is hardly "responsible". We've also seen what happens when we go down that route.

The simple proposed fix is to use reasonable deadlines to encourage things in the right direction. 60 days for critical issues. ("critical" in the genuine unsandboxed & arbitrary code execution sense, not "critical" just because some news article or researcher is overstating things).

Speaking personally about my work on securing the Chromium browser: I'd be mortified if I learned of a SecSeverity-Critical bug and it took me over 60 days to protect my users from it. It's not always possible to move this fast, but for one of the few critical bugs I found, the timeline shows it was not only fixed but also installed across the user base in about 6 days.

Related reading:

• http://lcamtuf.blogspot.com/2010/07/rebooting-responsible-disclosure.html


• http://taviso.decsystem.org/grandma.html

More money for critical Chromium security bugs!

We've seen who is $1337 but who is $3133.7 ?

I just launched this:
http://blog.chromium.org/2010/07/celebrating-six-months-of-chromium.html

I've really enjoyed launching and now refreshing this program.

Open redirectors: some sanity

Open redirectors are a contentious issue. Old-school hackers think anyone who thinks they are serious is on drugs. New-school hackers are more evenly divided. I haven't yet seen a public, balanced list of reasons why you should be worrying about other problems. Here it is. For now, I'll concentrate on the central idea that open redirectors permit domain obfuscation and therefore facilitate phishing etc.

• OMG! Open redirectors can send a user to evil.com whilst appearing to go to good.com
  
  
  
  1. Not an issue: The only security indicator for URLs supported by browsers is the URL bar. The status bubble can be faked. This is to say that you can only securely do an URL check on the final landing page of a click. Check out the Browser Security Handbook.
  
  
  2. Not an issue: An easier way to fake an URL is to simply use mismatched anchor text vs. the actual href. End users make decisions based solely on the the text they read, not the underlying URL.
  
  
  3. Not an issue: We cannot seriously expect end users to make safe / dodgy distinctions based on any component of an URL. If we as a security community try and offload decisions like this on to end users, we're exhibiting basic misunderstandings. A case in point -- I just keynoted OWASP Stockholm with my colleague Ian Fette and he released an eye-opening statistic: 50% of users click through the phishing / malware interstitial in Google Chrome. Just to be clear, this is a dialog with a red background and a huge no-entry sign, with text such as "This website may harm your computer". Ouch, 50%, and that's a simple decision. It's time to stop suggesting users make complicated decisions based on URLs. The issue is becoming pretty moot with URL shorteners anyway.
  
  
  4. Not an issue: It's very easy for attackers to register a domain name that sounds offical but is not. Time and time again, even relatively technical users fall for phishing scams simply because a bad domain looks vaguely official. This backs up the previous point about users understanding URLs nicely.

The fact is, it's really easy to get a user's browser to come into contact with untrusted bits. Malware ads would be one example; there are plenty of others.
If you want to be a productive member of the security community, please do the following things:

• Desist from seizing upon minor issues and declaring them "critical" in order to get attention. You may get quoted by some clueless reporter, but you'll still be a third-rate security researcher.


• Get involved in hardening web app frameworks, browsers and plug-ins such that they are robust in the face of malicious data. Users are going to be exposed to bad stuff. Help tackle the problem at the roots.

vsftpd HTTP lunacy!

Ok, so I was bored and I added very very basic HTTP support to vsftpd. vsftpd is now perhaps the only FTP server to have an option ftp_enable=NO. Basically none of the HTTP protocol is implemented, but it might suffice for someone who is super-paranoid and needs to serve some static files over the HTTP protocol. The selling point is the re-use of vsftpd's tried-and-tested listener, string handling and built-in sandboxing.

The bits live at ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.3.0pre1.tar.gz

I cannot use the name vshttpd, because bizarrely a Google search indicates it as taken: http://sourceforge.net/projects/vshttpd/. I do not know what the "vs" stands for in that case.

As usual, the feature will live or die depending on the level of user enthusiasm shown.

Encouraging More Chromium Security Research

I don't usually post non-original content here, but in this case I'll make an exception :) Here's one of the things I've been working on over in Chromium land:

http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

Will you be the first $1337 ?

Posting raw XML cross-domain

I was recently stealing anti-XSRF tokens using the CSS design error I found. In the (unnamed for now) app I was exploiting, all the fun happens in XSRF-protected POST requests with an XML RPC protocol.

If you are good.com, then sending XML to yourself is easy - you can send arbitrary POST payloads using XHR. This of course is not an option from evil.com.

I'll document how I got around it. I didn't see anything similar with a bunch of Google queries, but I somehow doubt it's new. I'm sure I've missed an easier way, too - let me know. (Note that I set myself the goal of not involving plugins).

When submitting a <form> POST, there are three standard form encodings to choose from:

• application/x-www-form-urlencoded - "All characters are encoded before sent (this is default)"


• multipart/form-data - "No characters are encoded. This value is required when you are using forms that have a file upload control"


• text/plain - "Spaces are converted to "+" symbols, but no special characters are encoded"

The first is clearly unsuitable because it does URL encoding. Critical XML characters such as < > " etc. will get mangled. The second sounds ideal because there is no character encoding... but... of course, multi-part POST bodies have the separator lines such as ------WebKitFormBoundary2eC9p3Z2xdIQfdTS, so are useless to us.

The final option will have to do. The encoding of space is not ideal but we could look into using a whitespace-free subset of XML. There's just one catch. The format of the POST body will be a series of name, value pairs:

name1=value1&name2=value2

The trick to save the day here is to use a single name / value pair and abuse the fact that XML is typically full of = characters. So imagine the following XML:

<element attribute="value">node text</element>

Bold and italic are used to show the name used (<element attribute) and the value ("value">node text</element>) respectively. Job done. We could also bury the = in a node value if we didn't want to use attributes.

But wait. The spec for the text/plain encoding type specifies that any spaces will be converted to + symbols. This will wreck the space between element name and attribute name and perhaps spoil our fun. It's now down to how the browsers behave. Curiously, it breaks down to WebKit browsers vs. non-WebKit browsers:

• Opera, IE, Firefox: do not URL encode; do not replace space with +


• Chrome, Safari: do URL encode; do replace space with +

So this trick will work on some browsers but not others. A note on the specifications for this: the most recent document is obviously the HTML5 draft. The relevant section mentions nothing about replacing spaces with + anymore, so either WebKit doesn't support text/plain or it is non-compliant:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#plain-text-form-data

Thanks to Michal Zalewski for being around to debate ideas!

"Logout XSRF" - significant web app bug?

[Or "Logout CSRF" for search indexes; I seem to be addicted to the less common acronym ;-)]

Significant? No, of course not. It is a technical integrity violation inflicted upon good.com by evil.com. That's not ideal, and could be an annoyance. But there are some other interesting technicalities that can make it futile to defend against. They include:

• Cookie forcing. A man-in-the-middle attacker can nuke the auth cookie, even though your session is https.


• Cookie bombardment. There is no standard on how a browser should behave when a range of collaborating sites (e.g. *.evil.com) pile a load of cookies on to a browser. kuza55 documents the plausibility of this attack in Firefox and Opera and the Browser Security Handbook also alludes to this in Part2 under the heading "Problems with cookie jar size". Essentially *.evil.com could "LRU-out" the auth cookie of another site. I've not seen a definitive answer to whether IE8 has a global cookie max limit or not. Intriguingly, having one can be a problem as can not having one!