Information Technology Reference
In-Depth Information
How can the choice of programming language affect the security of the resulting
program?
In two ways. The more obvious one is that some programming languages enforce constraints that limit
unsafe practices. For example, in Java, the language prevents indexing beyond the end of an array. In C,
the language does not. So you can get buffer overflows in C, but it's much harder to get buffer overflows
in Java. The less obvious one is that the language controls how most programmers think about their
algorithms. For example, a language that is functional matches some algorithms better than one that
is imperative. This means the programmer will make fewer mistakes, and the mistakes he or she makes
will tend to be at the implementation level rather than the conceptual or design level—and mistakes
at the implementation level will be
much
easier to fix.
What can be done about the problem of viruses, worms, and Trojan horses?
These programs run with the authority of the user who triggers them; worms also spread au-
tonomously through the network and most often take advantage of vulnerabilities to enter a system
and spread from it. So several things can ameliorate the situation:
1. Minimize the number of network services you run. In particular, if you don't need
the service, disable it. This will stop the spread of many worms.
2. Don't run any attachments you receive in the mail unless you trust the person who
sent them to you. Most viruses and many worms spread this way. In particular,
some mailers (such as Outlook) can be set up to execute and/or unpack attachments
automatically. This feature should be disabled.
3. The user should not be able to alter certain files, such as system programs and
system configuration files. If the user must be able to alter them, confirmation
should be required. This will limit the effect of most viruses to affecting the user
rather than the system as a whole or other users on the system.
Many personal computer users do not update their systems with the latest operating
system patches. Should computer manufacturers be given the ability (and the obligation)
to keep up-to-date all of their customers' Internet-connected computers?
I question the wisdom of allowing vendors to update computers remotely. The problem is that ven-
dors do not know the particular environment in which the computers function. The environment
determines what “security” means. So a patch that improves security in one realm may weaken it in
another.
As an example, suppose a company disallows any connections from the network except through a
virtual private network (VPN). Its systems were designed to start all servers in a particular directory
that contains all network servers. So to enforce this restriction, all network servers
except
the VPN are
removed from the systems. This prevents the other servers from being started.
The system vendor discovers a security vulnerability in the email server and the login procedure. It fixes
both and sends out a patch that includes a new login program and a new email server. The patch installs
both and reboots the system so the new login program and email server will be used immediately.
The problem here is that by installing the new email server (which improves security in most systems),
the company's systems now are nonsecure, as they can be connected to via a port other than those used
for the VPN (for example, the email port, port 25). The vendor's patch may therefore damage security.
We saw this with Windows XP SP2. It patched many holes but also broke various third-party applica-
tions, some of them very important to their users.
