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:

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.

Install LAMP on Ubuntu 8.04

ubuntu_logo

Here is the apt-get command to install a basic lamp environment on ubuntu hardy 8.04 with some “quick start help” commands.

First,

apt-get install apache2 php5-mysql libapache2-mod-php5 mysql-server php5-gd phpmyadmin

This will install apache 2 php 5.2 and mysql server 5 and their dependencies. The deamons are launched at install and basically, only apache2 needs a bit of configuration.To enable ~/public_html user folder (which you reach in a browser with this URL : http://localhost/~username) do :

sudo a2enmod userdir && sudo /etc/init.d/apache2 restart

The default document root is /var/www (you need superuser privileges to write in this directory), but you can add more sites. Edit a new configuration file for the new site :

gksudo gedit /etc/apache2/sites-available/<site_name>

Replace with whatever you want. Add virtual host properties and directives that you need, then save and exit gedit.
To enable this new site do :

sudo a2ensite <site_name> && sudo /etc/init.d/apache2 restart

To manage mysql users and database, simply use phpmyadmin by entering this url in your browser : http://localhost/phpmyadmin

The php config file is located at : /etc/php5/apache2/php.ini and requires a restart of apache if you make any change in it.