Update Java — or just remove it

Oracle recently released an update to its Java software, fixing more than 20 critical security issues in the software. Krebs has a good post on the update, briefly discussing the vulnerabilities and the fact that Java vulnerabilities are exploited for real.

I have to say that in recent years I've installed Java more due to habit than because of an actual need for the software. So when I got the update bubble in the corner of my screen, I figured "of course". I knew they, among other things,  fixed the same-origin-policy bypass used in the BEAST attack (You'll find a straight forward explanation of the Java vulnerability here, and links to resources on BEAST here). So I started the update process, and this was one of the first screens I was presented.

A Google 2-step verification vulnerability

Early this year Google started rolling out their new two-factor authentication procedure, which they refer to as 2-step verification. On their corporate blog they provided a few hints on why they were rolling out a new authentication procedure — mentioning risks associated with password reuse and phishing attacks. 2-step verification is now widely deployed, by June it was available in 150 countries, and in 40 different languages.

Of course, I took interest in how the two-step verification was designed and I discovered a couple of design issues. In addition I discovered a security flaw that qualified for Google's vulnerability reward program, so I engaged in a responsible disclosure process with Google. Now they've fixed the bug, my reward has been donated to charity, and I've received my 19 bytes of fame, so I guess it's time to blog about this. I'll focus on the security bug here, and blog about the design issues later. I need to do some investigation to see whether Google fixed any of them or not, as they reported that they were re-evaluating some of their design decisions.

If you're unfamiliar with how the two-step verification works, see Google's video below (borrowed from Getting started with 2-step verification).

Now, straight to the point.

Making the web even safer: From auto-upgrade to silent updates

Mozilla now aims to add silent updates to Firefox — much like Chrome and Opera already does — as summarized in this Computerworld article. This marks an important milestone, and is an important follow up to Mozilla's decision back in June to auto-upgrade the then soon-to-be unsupported Firefox 3.5. Back then, I blogged about the importance of the bold decision to NOT leave users behind on an unsupported version.

Later in June when Firefox 5 was released, Firefox 4 users where prompted to update to the new version. I was so excited, I had to blog about that too.

Now Mozilla has decided to introduce silent updates to Firefox. From Mitchell Baker's blog we can learn that:

Before Mozilla instituted the rapid release process, we would sometimes have new capabilities ready for nearly a year before we could deliver them to people.  Web developers would have to wait that year to be able to make their applications better.

And why is that a problem?

A browser is the delivery vehicle for the Internet. And the Internet moves very, very quickly.

Bugs get fixed

My bug reporting has been on fire lately. This week I received confirmation from the Google security team that a security bug I reported was found worthy of a reward (a couple of weeks ago Google fixed some issues in their two-step verification procedure). I'll be blogging the details on the security issue anytime soon.

Just now, my hotmail told me that the Visual Studio 2010 firewall setup bug I blogged about last month will be fixed in the next major release of Visual Studio. Cool!

Now, if I could only find and fix my own damn bugs. :)

Announcing TransformTool

I've spent some of my spare time on a hobby project lately. I've been missing a tool that could help me easily encode or decode various pieces of information. When you're studying web applications you often come across values in cookies, URL parameters or forms that are encoded in one way or another. They might even be encoded multiple times with the same encoding function. It has been somewhat cumbersome to fiddle about with such pieces of information, that is until now!

I've created TransformTool, that lets you easily apply a series of encoding/decoding operations to an input. Just have a look at this example:

WIF security considerations

I've been working with WIF (Windows Identity Foundation) for the last couple of months, and have to admit I've spent some time googling for WIF articles explaining how the framework should be used. I'll be putting together a blog post on some of the most useful resources I've found when I find the time. However, you'll discover that there aren't many resources covering WIF and the nitty gritty security details out there. An MSDN article on WIF security was brought to my attention the other day (thanks Jonas!), so I figured I'd link to it sooner rather than later. It might be useful for some of you out there.

The article is titled Security considerations, and it's not easy to find on Google. It contains quite a few security considerations you'd want to look into if you're using, or are contemplating, to use WIF. Stay tuned for more WIF (security) stuff as my calendar hopefully frees up at work, and the golf season ends here in Norway.

VS2010 remote debugging and Windows 7 firewall

*Update, 2011/09/16: The issue has been fixed in the next major release of Visual Studio.

I've had some trouble getting remote debugging going for a development server at work. Turns out there are some oddities in the way VS 2010 creates and manages the firewall entries that let the remote machine connect back to the local computer. You'd might want to read this before checking out the MSDN articles:  How to: Set Up Remote Debugging, How to: Configure the Windows 7 Firewall for Remote Debugging.

I was working with a development server that had the remote debugging monitor installed. Others have been debugging on the server, so I was sure that the server was set up correctly. I was pretty sure my problems were caused by the setup on my local machine.

If you lack firewall rules for remote debugging, VS2010 detects this and asks you what to do:

Without giving it much thought I chose to "Unblock remote debugging from computers on the local network (subnet)". After all, the development server was somewhat "local." The remote debugging monitor reported that I connected to the server, but nothing more happened and I timed out with this error message: 

Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'xxxxxxx'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer.

I then realized that subnet was probably a keyword here, as the server was in the same domain but on a different subnet.