MOOC ON INFORMATION SECURITY

MODULE 8
PROGRAM THREATS

We know that security implies some degree of trust that the program enforces
expected confidentiality, integrity, and availability. From the point of view of a
program or a programmer, how can we look at a software component or code
fragment and assess its security? This question is, of course, similar to the problem of
assessing software quality in general. One way to assess security or quality is to ask
people to name the characteristics of software that contribute to its overall security.
However, we are likely to get different answers from different people. This
difference occurs because the importance of the characteristics depends on who is
analysing the software. For example, one person may decide that code is secure
because it takes too long to break through its security controls. And someone else
may decide code is secure if it has run for a period of time with no apparent failures.
But a third person may decide that any potential fault in meeting security
requirements makes code insecure.

Secure programming is a way of writing codes in software so that it is protected

from all kinds of vulnerabilities, attacks or anything that can cause harm to the
software or the system using it. Because it deals with securing the code, secure
programming is also known as secure coding.

Types of Secure Programs

Many different types of programs may need to be secure programs. Some common
types are:

Application programs used as viewers of remote data:

Programs used as viewers (such as word processors or file format viewers) are often
asked to view data sent remotely by an untrusted user (this request may be
automatically invoked by a web browser). Clearly, the untrusted user’s input should
not be allowed to cause the application to run arbitrary programs. It’s usually
1
unwise to support initialization macros which run when the data is displayed; if you
must, then you must create a secure sandbox.

Application programs used by the administrator (root):

Such programs shouldn’t trust information that can be controlled by non-

administrators such as Local servers (also called daemons) and Network-accessible
servers (sometimes called network daemons).

Web-based applications (including CGI scripts)”

These are a special case of network-accessible servers, but they are so common they
deserve their own category. Such programs are invoked indirectly via a web server,
which filters out some attacks but nevertheless leaves many attacks that must be
withstood.

Applets:

Applets are programs downloaded to the client for automatic execution. This is
something Java is especially famous for, though other languages (such as Python)
support mobile code as well. There are several security viewpoints here; the
implementer of the applet infrastructure on the client side has to make sure that the
only operations allowed are “safe” ones, and the writer of an applet has to deal with
the problem of hostile hosts

setuid/setgid programs. These programs are invoked by a local user and, when
executed, are immediately granted the privileges of the program’s owner and/or
owner’s group. In many ways these are the hardest programs to secure, because so
many of their inputs are under the control of the untrusted user and some of those
inputs are not obvious.

Fixing Faults

When a human makes a mistake, called an error, in performing some software

activity, the error may lead to a fault, or an incorrect step, command, process, or data
definition in a computer program. For example, a designer may misunderstand a
requirement and create a design that does not match the actual intent of the

2
requirements analyst and the user. This design fault is an encoding of the error, and
it can lead to other faults, such as incorrect code and an incorrect description in a
user manual. Thus, a single error can generate many faults, and a fault can reside in
any development or maintenance product.

A failure is a departure from the system's required behaviour. It can be discovered

before or after system delivery, during testing, or during operation and
maintenance. Since the requirements documents can contain faults, a failure
indicates that the system is not performing as required, even though it may be
performing as specified.

Thus, a fault is an inside view of the system, as seen by the eyes of the developers,
whereas a failure is an outside view: a problem that the user sees. Not every fault
corresponds to a failure; for example, if faulty code is never executed or a particular
state is never entered, then the fault will never cause the code to fail.

Unexpected Behaviour

The inadequacies of penetrate-and-patch led researchers to seek a better way to be

confident that code meets its security requirements. One way to do that is to
compare the requirements with the behaviour. That is, to understand program
security, we can examine programs to see whether they behave as their designers
intended or users expected. We call such unexpected behaviour a program security
flaw; it is inappropriate program behaviour caused by a program vulnerability.

A flaw can be either a fault or failure, and vulnerability usually describes a class of
flaws, such as a buffer overflow. In spite of the inconsistency, it is important for us to
remember that we must view vulnerabilities and flaws from two perspectives, cause
and effect, so that we see what fault caused the problem and what failure (if any) is
visible to the user. For example, a Trojan horse may have been injected in a piece of
code flaw exploiting a vulnerability, but the user may not yet have seen the Trojan
horse's malicious behaviour. Thus, we must address program security flaws from
inside and outside, to find causes not only of existing failures but also of incipient

3
ones. Moreover, it is not enough just to identify these problems. We must also
determine how to prevent harm caused by possible flaws.

Types of Flaws

To aid our understanding of the problems and their prevention or correction, we can
define categories that distinguish one kind of problem from another.

The inadvertent flaws fall into six categories:

 validation error (incomplete or inconsistent)

 domain error
 serialization and aliasing
 inadequate identification and authentication
 boundary condition violation
 other exploitable logic errors

Non-Malicious Program Errors

Being human, programmers and other developers make many mistakes, most of
which are unintentional and non-malicious. Many such errors cause program
malfunctions but do not lead to more serious security vulnerabilities. However, a
few classes of errors have plagued programmers and security professionals for
decades, and there is no reason to believe they will disappear. In this section we
consider three classic error types that have enabled many recent security breaches.
We explain each type, why it is relevant to security, and how it can be prevented or
mitigated.

1. Buffer Overflows

A buffer is a space in which data can be held. A buffer resides in memory. Because
memory is finite, a buffer's capacity is finite. For this reason, in many programming
languages the programmer must declare the buffer's maximum size so that the
compiler can set aside that amount of space.

4
Suppose, that a malicious person understands the damage that can be done by a
buffer overflow. If the buffer overflow into system code space, the attacker merely
inserts overflow data that correspond to the machine code for instruction.

Buffer overflows can affect all types of software. They typically result from
malformed inputs or failure to allocate enough space for the buffer. If the transaction
overwrites executable code, it can cause the program to behave unpredictably and
generate incorrect results, memory access errors, or crashes.

2. Incomplete Mediation

Incomplete mediation is another security problem that has been with us for decades.
Attackers are exploiting it to cause security problems. In this attack, attacker
supplies wrong type of data in wrong length. It is easy to exploit, but it has been
exercised less often than buffer overflows, Nevertheless, unchecked data values
represent a serious potential vulnerability.

One possible consequence is that the system would fail catastrophically; Another
possibility is that the receiving program would continue to execute but would
generate wrong results.

3. Time of check to time of use (TOCTTOU) Errors

TOCTOU states that race condition can occur if the state of the system changes
between the moment when some condition was checked by a process and the
moment when the action was taken based on that condition by the same process.

Errors can occur when the status changes unexpectedly, either maliciously or
unintentionally, between a check and a subsequent operation. A TOCTTOU attack
exploiting such conditions can lead to privilege escalation, allowing unauthorized
access to resources, such as read and write access, as well as avoiding log and audit
controls. This sort of attack is difficult to detect. It requires not only looking for
evidence, but also determining whether it could be caused by TOCTOU.

The root cause of many TOCTTOU vulnerabilities lies in the lack of concurrency
control in an operating system's file-system API and so it's not a problem that's easy

5
to resolve. Most OSes change the order that instructions and processes are actually
executed to improve efficiency. A programmer has to achieve atomicity of two
operations using an API that isn't designed for such a purpose. The challenge
therefore is ensuring the file system state, managed by the operating system, cannot
change between two system calls.

Most UNIX systems have adopted variants of common file system calls that operate
on file handles rather than file names. These calls end in “at”, such as openat and
statat. Because file handles are a private mapping to a file, they cannot be changed
by another program and so are not subject to race conditions with other applications.
Another preventative measure when working with a single file is to lock it before the
check, as opposed to afterwards so the resource, as checked, is the same as it is when
in use. However, file locking can't automatically roll back a failed operation, which
requires transaction support by the OS.

A simple example is as follows: Consider a Web application that allows a user to edit
pages, and also allows administrators to lock pages to prevent editing. A user
requests to edit a page, getting a form which can be used to alter its content. Before
the user submits the form, an administrator locks the page, which should prevent
editing. However, since editing has already begun, when the user submits the form,
those edits (which have already been made) are accepted. When the user began
editing, the appropriate authorization was checked, and the user was indeed
allowed to edit. However, the authorization was used later, at a time when edits
should no longer have been allowed.

Malicious code

Malicious code is unwanted files or programs that can cause harm to a computer or
compromise data stored on a computer.

By themselves, programs are seldom security threats. The programs operate on data,
taking action only when data and state changes trigger it. Much of the work done by
a program is invisible to users who are not likely to be aware of any malicious
activity. However, since users usually do not see computer data directly, malicious

6
people can make programs serve as vehicles to access and change data and other
programs.

Malicious code can do anything any other program can, such as writing a message
on a computer screen, stopping a running program, generating a sound, or erasing a
stored file. Or malicious code can do nothing at all right now; it can be planted to lie
dormant, undetected, until some event triggers the code to act. The trigger can be a
time or date, an interval (for example, after 30 minutes), an event (for example, when
a particular program is executed), a condition (for example, when communication
occurs on a network interface), a count (for example, the fifth time something
happens), some combination of these, or a random situation. In fact, malicious code
can do different things each time, or nothing most of the time with something
dramatic on occasion.

Malicious code runs under the user's authority. Thus, malicious code can touch
everything the user can touch, and in the same ways. Users typically have complete
control over their own program code and data files; they can read, write, modify,
append, and even delete them. And well they should. But malicious code can do the
same, without the user's permission or even knowledge.

Kinds of Malicious Code

Malicious code or rogue program is the general name for unanticipated or undesired
effects in programs or program parts, caused by an agent intent on damage. This
definition excludes unintentional errors, although they can also have a serious
negative effect. This definition also excludes coincidence, in which two benign
programs combine for a negative effect. The agent is the writer of the program or the
person who causes its distribution.

The terminology of malicious code is sometimes used imprecisely. A virus is a

program that a replicate itself and pass on malicious code to other non-malicious
programs by modifying them. Moreover, a good program can be modified to include
a copy of the virus program, so the infected good program itself begins to act as a
virus, infecting other programs. The infection usually spreads at a geometric rate,

7
eventually overtaking an entire computing system and spreading to all other
connected systems.

Various classifications of malicious code include viruses, worms, and Trojan horses.

Viruses have the ability to damage or destroy files on a computer system and are
spread by sharing an already infected removable media, opening malicious email
attachments, and visiting malicious web pages.

Worms are a type of virus that self-propagates from computer to computer. Its
functionality is to use all of your computer’s resources, which can cause your
computer to stop responding.

Trojan Horses are computer programs that are hiding a virus or a potentially
damaging program. It is not uncommon that free software contains a Trojan horse
making a user think they are using legitimate software, instead the program is
performing malicious actions on your computer.

Malicious data files are non-executable files—such as a Word document, a PDF, a

ZIP file, or an image file—that exploits weaknesses in the software program used to
open it. Attackers frequently use malicious data files to install malware on a victim’s
system, commonly distributing the files via email, social media, and websites.

Any program which does malicious tasks is known as Program Threat. If a program
installed in a computer can store and send user credentials through network to some
hacker it is a program threat. An overview of some well-known malicious programs
is discussed in this session. The important ones like, viruses, worms, Trojans will be
discussed later in detail.