September’s off to a rather slow start, and only a few
issues have cropped up this week. Another slow week in the security arena gives
me the chance to address a TechRepublic member’s burning question: Why can’t we
get rid of vulnerabilities once and for all?

Details

In the absence of any serious security warnings, it seems
like a good opportunity to go over some not-so-basic basics of security. Don’t
worry—I won’t lecture you on elementary topics. However, I did receive a
question from a TechRepublic member who brought up some points that I bet
trouble others, especially those who manage security but have never programmed
or performed any software testing.

But first, here are some updates on a few recent problems. A
Microsoft
Security Advisory released on August 31 states that a flaw in the user
interface for the Windows Firewall—it’s not actually a vulnerability because it
doesn’t cause or permit any damage—may fail to report some exceptions. While
this can’t result in system compromise, it could cause the interface to fail to
report such a problem.

This is just a problem in the
user interface—not the underlying firewall code—and administrators can view
all exceptions by opening the command prompt and entering – netsh firewall show state verbose = ENABLE. Look under Ports
Currently Open in the output for unblocked ports.

In other Microsoft news, patching will
purportedly be easier in Microsoft’s next-generation OS, Windows Vista,
thanks to new patching technology. Code-named Freeze Dry, the new technology will reduce the number of restarts
and will save user data when a reboot is necessary.

And, speaking of Microsoft problems, no less a security firm
than the SANS Institute has stated in its weekly newsletter that, having reviewed
statistics from Secunia.com, it no longer feels it’s worth switching to an
alternative browser to avoid IE6 vulnerabilities. As I’ve written before,
the surge in
Firefox vulnerabilities, combined with the major reduction of new problems
reported in IE6, means that the major reason for downloading and supporting a
new browser can no longer be that it’s more secure than Microsoft’s program.

A recent news article may provide another reason not to allow your users to switch from
IE. Not only is support more difficult because you still have to support
the built-in IE browser, but apparently some less knowledgeable investigators
are experiencing trouble locating cookies and caches for the alternative
browsers.

I personally wouldn’t consider this a big problem. However,
for some businesses that are barely able to deal with pure Microsoft
installations, there may be a lack of security investigators with the expertise
to troubleshoot and conduct forensics on non-Microsoft program files.

And now, let’s get back to that member’s question.

Why can’t we be more proactive
with finding vulnerabilities?

TechRepublic member David e-mailed
me these comments:

“I enjoy reading how all the top-o-the-heap security
experts—companies full of them and individuals alike, all over the world—get
all their sage knowledge about security holes in popular software after the
fact—or is that after the hack? Has anyone of them ever thought of hanging a
supercomputer off of the source code and seeing what it reveals? Or would that
appear overly proactive and perhaps affect profits?”

First of all, let’s keep in mind that it’s illegal to
decompile some source code. For example, check out any copyrighted or non-open
source code, including Microsoft. Case in point: William P. Genovese Jr. recently
pled guilty to “unlawfully
distributing a trade secret.” Genovese attempted to sell pieces of Windows
NT 4.0 and Windows code that he didn’t even steal himself; he merely downloaded
it off the Net!

Doing almost anything with copyrighted code, which includes
everything that isn’t specifically open source, is a federal crime punishable
by up to 10 years in prison and a $250,000 fine. The plea bargain will probably
reduce that considerably for Genovese, but prosecutors are still asking for
prison time.

However, even if this were legal, it isn’t as easy as it sounds—even
for those with legitimate access to the source code. Software exists that
checks for vulnerabilities, but it isn’t that effective, or there wouldn’t be
any flaws. If it did, Microsoft would obviously use it since it can afford
virtually anything, including the purchase of some small countries.

Want more proof? Go to scholar.google.com, search for “difficulty
finding source code vulnerability,” and you’ll find more than 8,000
scholarly studies on the topic.

In fact, my very first review for BYTE Magazine was of a book, “Software Validation, Verification, Testing, and Documentation“—19
years ago! While that book is certainly out of date, it does contain some
useful background, including the analysis that even a simple FORTRAN program 50
lines long containing 25 IF statements will have 33.5 million potential control
paths.

Vulnerabilities can come from coding errors (i.e., typos),
errors in libraries, logical errors, faulty algorithms, and other problems,
including the complexity of the software. Therefore, calculating the precise
number of things that require testing is a bit difficult.

For example, counting the OS, applications, and libraries,
you may well be dealing with 50 million lines of code just for Microsoft
Office. Even if someone created a supercomputer program that could find all the
vulnerabilities, it would take just short of forever to run the complete
analysis.

And remember: Software has an average life of about three years
before developers make some significant change to some component. For more
information, I recommend this PDF, “Dynamic
Taint Analysis for Automatic Detection, Analysis, and Signature Generation of
Exploits on Commodity Software,” from Carnegie Mellon University.

Finally, let’s not forget that most of the vulnerabilities
we learn about do come from experts who pore over whatever source code they can
find. Knowing the history of computing (because I lived through much of it), I’m
familiar with why many vulnerabilities exist—after all, I was programming before there were even operating
systems!

In the early days of software development, remember that
there was no outside connection to most computers. If a connection did exist, it
was a dedicated phone line, so there was no threat of hackers.

In those days, developers built compilers and the libraries
they use in a hit-or-miss fashion with tons of holes in them because we were
only just learning about computers. But some of that code is still floating
around in modern software and operating systems.

However, David’s question was certainly reasonable. Many people
wonder the same thing because they don’t realize just how complex the problem
is.

Final word

Of course, the online scams that I
predicted in the wake of Katrina have materialized,
but I certainly don’t take any credit for warning against them. It was so
obvious that I know all my readers were expecting it.

However, I brought it up because it’ s important to remind ourselves
that not everyone is as security-aware as we are. We need to proactively warn
users about the issues that those of us in the business can see coming—the
network news stations started warning about them about five days after I did.

Miss a column?

Check out the IT Locksmith Archive,
and catch up on the most recent editions of John McCormick’s column.

Want to stay on top of
the latest security updates? Automatically
sign up for our free IT Locksmith newsletter, delivered each Tuesday!

John McCormick is a
security consultant and well-known author in the field of IT, with more than
17,000 published articles. He has written the IT Locksmith column for
TechRepublic for more than four years.