Are vulnerabilities ever really fixed?

Earlier this month, news surfaced of a new threat that could cause a "LAND attack," affecting Windows Server 2003 and Windows XP systems that have Support Pack 2 installed. While the threat is minor, the flaw itself is disturbing because it's one ostensibly fixed years ago. Jonathan Yarden discusses this latest conundrum: Are flaw fixes ever permanent?

Want more advice for locking down your network? Stay on top of the latest security issues and industry trends by automatically signing up for our free Internet Security Focus newsletter, delivered each Monday.

Earlier this month, news surfaced of a new threat that could cause a "LAND attack," resulting in a temporary denial of service (DoS) that could last about 30 seconds, locking up servers and workstations in the process. The vulnerability affects Windows Server 2003 and Windows XP systems that have Support Pack 2 installed, but the firewall turned off.

Microsoft was quick to point out that this flaw doesn't present a significant threat, and the fix is relatively simple. (Implement a firewall that blocks such attacks.) But if you've been in this business long enough, you know that there's something more disturbing about this ostensibly minor flaw—it's not a new one. In fact, it's a previously fixed vulnerability that has resurfaced.

According to information I found on the BugTraq list, in 1997, an enterprising person discovered that it was possible to freeze or disable any computer running Windows 95 with a specially-crafted IP packet. In addition, that person released the code as proof that the exploit existed.

Anyone who subscribed to BugTraq then had access to a tool that he or she could use to disable any Windows 95 machine connected to the Internet, provided they could forge the TCP/IP packets. In those days, few users bothered to worry about network filtering and firewalling, least of all on their own PC. So, at the time, anyone using Windows 95 to access the Internet was technically vulnerable to a possible "LAND attack."

Shortly after the initial release of this exploit, someone else discovered that attackers could exploit this flaw on a number of different TCP/IP implementations across dozens of operating systems and network hardware. The specially-crafted IP packet was a TCP connection initiation request, forged to appear to originate from and go to the same IP address and port numbers.

The results on various TCP/IP implementations differed, and some TCP/IP stacks weren't vulnerable at all. On the systems that were vulnerable, including Cisco routers running specific IOS versions and (obviously) Windows 95, the common denominator appeared to be an older version of the BSD Net/3 code.

Because much of the Internet was at risk, the response from both vendors and network operators was swift. It didn't take long before the infamous LAND attack became part of the history, and maybe even folklore, of the Internet.

That is, of course, until some point in recent history, when Microsoft apparently decided it was time to make some changes to its TCP/IP stack. Of course, it's rare that anyone rewrites a TCP/IP stack from scratch, and Microsoft undoubtedly has dozens of TCP/IP implementations in its code arsenal. I don't know whether it chose to use some of the ancient BSD Net/3 code, but the end result was that Windows 2003 and Windows XP with SP2 installed became once again vulnerable to a LAND attack.

In the meantime, however troubling it is that Microsoft reintroduced the LAND attack, the Internet has become quite a different place than it was in 1997, when, with a few exceptions, security was practically nonexistent on the Internet. These days, firewalls and other security measures are essential in corporate networks. And yet, a large percentage of computers are vulnerable to this resurrected vulnerability.

So how do old vulnerabilities resurface in new or updated software? I can't answer that. However, sometimes the only method for fixing software or implementing a new feature is to completely rebuild it. In my experience, the effort spent trying to find and fix even a minor bug in software can take longer than scrapping entire sections of code and writing them over from scratch.

Choosing whether to fix a bug or recode software is a difficult decision, particularly because it involves software defects that are often unknown until discovered through testing. Perhaps Microsoft reached a point in its work on the TCP/IP stack that required a complete redesign, which inadvertently resulted in the resurfacing of the previously fixed vulnerability.

Whatever the reason, the LAND vulnerability is back, bringing with it something new to consider: Previously fixed flaws aren't always a moot point. If nothing else, it only serves to reemphasize the importance of staying on top of your organization's security.

Editor's Picks

Free Newsletters, In your Inbox