Firefox 2.0.0.2 was released on Friday. This is mostly a bug-fixing release that includes fixes for seven different security bugs that were found this year (click here for a list).

Personally, I'm nonplussed by the Firefox project's point-point-point releases. I'm also troubled that its people have taken so long to get this release out. They were nimble and fast at the beginning, but they are quickly becoming another "legacy browser" that has code bloat and a zillion features that all need to work properly together.

How dearly I wish for software that gets better over time, rather than worse.

PHP is a Web development framework that's at the heart of some of the most important Web applications today. PHP powers Wikipedia. PHP runs websites at National Public Radio, Sourceforge, and the state of Rhode Island, to name a few. Indeed, every time you see a URL that ends ".php," that's a sign that PHP is helping deliver you your Web pages.

So given the current state of computer software, it should be expected that the PHP run-time system has some bugs in it, and that some of these bugs are security bugs. All software has bugs in it, after all.

But PHP has more than a few security bugs: in many ways PHP is fundamentally flawed. The program, whose initials originally stood for Personal Home Page, was designed without much thought given to security. Many of the PHP features that make it really easy to write a Web application also make it really difficult to write one that's secure.

All of this matters just now because Stefan Esser, the founder of the Hardened-PHP Project and the PHP Security Response Team (which he recently quit), has threatened to make March the "month of PHP bugs." By that, Esser means that he is going to be releasing a series of security bugs in March that show the world just how unsecure PHP actually is.

What's driving Esser is both a desire to make PHP more secure and a good touch of anger and resentment at the current PHP developers who have taken many of his security patches and incorporated them into the program without giving Esser any credit. You can read more about his motivations in his blog entry and in the interview that he did with Security Focus.

How will this affect users of the Web? Well, a recent "Month of Bugs" project aimed at Apple identified a number of security problems that the company was apparently unaware of, but it didn't result in any serious worms or threats to Apple users. This month of PHP bugs might be a similar bust. On the other hand, Apple was able to push out a fix to these problems using the Mac OS Software Update feature. PHP has no such feature, and many ISPs run kind of elderly (and buggy) versions of the program.

Personally, I'm troubled by PHP. It's not a well-designed language, it's overly complex, and it's extraordinarily pervasive. Still, it would be nice if the bugs could be fixed without exposing so many systems to attack.

Over the weekend, David Maynor posted a note in his blog that claimed that the so-called Telnet server in the Sun Solaris 10/11 operating system doesn't "require any skill, any exploit knowledge, and can be scripted for mass attacks."

Telnet is a program from the 1970s that allows people to remotely log in to a computer. It's generally disabled because user names and passwords are sent without using encryption (which was illegal to export from the United States back then). But while the program has been largely abandoned, Sun still ships its Solaris 10 operating systems with both the Telnet server and client programs.

In any event, the Telnet server takes the user name that is provided by the person trying to log in and provides this information to what's known as the log-in program. It's the job of the log-in program to ask for the user's user name and password. Normally it does this, and if the password is correct, the user is allowed to log in.

What Maynor discovered is that an attacker can try to log in with a user name like "-fbin." The "-fbin" is passed along to the log-in program, which misinterprets the "-f" as a command from the operating system to log the user in to the specified account without asking for a password. So the exploit looks like this:

% telnet -l "-fbin" 192.168.1.110
Trying 192.168.1.110...
Connected to 192.168.1.110.
Escape character is '^]'.
Last login: Sun Feb 11 02:02:23 from 192.168.1.102
sun Microsystems Inc.     SunOS 5.10     Generic January 2005
$ id
uid=2(bin) gid=2(bin)

(You can read all the gory details here)

What's truly amazing is that this vulnerability was first publicly reported by the Computer Emergency Response Team back in 1996. Apparently the bug was reintroduced by some programmer unfamiliar with the history. I'm told that it has since been fixed in Solaris 11.

So what's wrong here? Many things.

1. When the engineers at Sun fixed this in Solaris 11, they also should have fixed it in Solaris 10.
2. At this point, Sun shouldn't even be shipping a Telnet server.
3. And if they are going to ship a server, they really should be validating it. Although I have no way of knowing what happened at Sun, my guess is that they didn't bother to test the server because it is disabled by default.

In speaking with a security consultant at the RSA Security Trade Show last week, I was told that security bugs fixed in production servers on banking systems are frequently reintroduced when new releases are shipped. This is good news for security consultants, of course. But it also explains why organized crime is having such an easy time making money fast on the Internet.