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.