Chapter 2 Program Security

Program Security Overview

An assessment of security can also be influenced by someone's general perspective on software

quality. For example, if your manager's idea of quality is conformance to specifications, then she
might consider the code secure if it meets security requirements, whether or not the requirements
are complete or correct.

IEEE Terminology for Quality

Frequently, we talk about "bugs" in software, a term that can mean many different things
depending on context. A bug can be a mistake in interpreting a requirement, a syntax error in a
piece of code, or the (as-yet-unknown) cause of a system crash.
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 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

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

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 behavior. 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.

Making the system less secure rather than more secure because they frequently
introduced new faults. There are at least five reasons why.

o Narrow focus on the fault itself.

o The fault often had nonobvious side effects in places other than the immediate area of the
fault.
o Fixing one problem often caused a failure somewhere
o The fault could not be fixed properly because system functionality or performance would
suffer as a consequence
o Unexpected Behavior - to understand program security, it can examine programs to see
whether they behave as their designers intended or users expected.

Flaws:

Program security flaws can derive from any kind of software fault. That is, they cover everything
from a misunderstanding of program requirements to a one-character error in coding or even
typing.

The flaws can result from problems in a single code component or from the failure of several
programs or program pieces to interact compatibly through a shared interface.

The security flaws can reflect code that was intentionally designed or coded to be malicious or
code that was simply developed in a sloppy or misguided way. Thus, it makes sense to divide
program flaws into two separate logical categories: human errors, intentionally induced flaws
(malicious)

Types of Flaws

They further divide intentional flaws into malicious and nonmalicious ones. In the taxonomy, the
inadvertent flaws fall into six categories:

1. validation error (incomplete or inconsistent)

2. domain error
3. serialization
4. inadequate identification and authentication
5. boundary condition violation
6. logic errors

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

Malicious Code

Malicious code refers to a broad category of programs that can cause damage or undesirable effects
to computers or networks. Potential damage can include modifying, destroying or stealing data,
gaining or allowing unauthorized access to a system, bringing up unwanted screens, and executing
functions that a user never intended.

Examples of malicious code include computer

1. Viruses, is a program that infects a computer by attaching itself to another program, and
propagating itself when that program is executed.
2. Worms, is a standalone malware computer program that replicates itself in order to spread
to other computers
3. Trojan horses, A Trojan horse usually carries a hidden destructive function that is
activated when the application is started.
4. Logic bombs, is a class of malicious code that "detonates" or goes off when a specified
condition occurs. A time bomb is a logic bomb whose trigger is a time or date.
5. Spyware, is a type of software that secretly forwards information about a user to third
parties without the user's knowledge or consent. This information can include a user's
online activities, files accessed on the computer, or even user's keystrokes.
6. Adware, is a type of software that displays advertising banners while a program is running.
Some adware can also be spyware. They first spy on and gather information from a victim's
computer, and then display an advertising banner related to the information collected.

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

Computer Virus
A computer virus is a self replicating computer program which can attach itself to other
files/programs, and can execute secretly when the host program/file is activated. When the virus
is executed, it can perform a number of tasks, such as erasing your files/hard disk, displaying
nuisance information, attaching to other files, etc.

Type of virus
1) Memory-Resident Virus - This type will reside in main system memory. Whenever the
operating system executes a file, the virus will infect a file if it is a suitable target, for
example, a program file.
2) Program File Virus - This will infect programs like EXE, COM, SYS etc.
3) Polymorphic Virus -The virus itself can change form using various polymorphism
techniques.
4) Boot Sector Virus -This type will infect the system area of a disk, when the disk is
accessed initially or booted.
5) Stealth Virus - A virus which uses various stealth techniques in order to hide itself from
detection by anti-virus software.
6) Macro Virus - Unlike other virus types, these viruses attack data files instead of executable
files.
7) Email virus - A virus spread by email messages.

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

Nonmalicious Program flaws:

Being human, programmers and other developers make many mistakes, most of which are
unintentional and nonmalicious. 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,
2) time-of-check to time-of-use flaws,
3) incomplete mediation

Buffer Overflow Attack

A buffer is a temporary area for data storage. When more data (than was originally allocated to
be stored) gets placed by a program or system process, the extra data overflows. It causes some of
that data to leak out into other buffers, which can corrupt or overwrite whatever data they were
holding.

In a buffer-overflow attack, the extra data sometimes holds specific instructions for actions
intended by a hacker or malicious user; for example, the data could trigger a response that damages
files, changes data or exposes private information.

Attacker would use a buffer-overflow exploit to take advantage of a program that is waiting on a
user’s input. There are two types of buffer overflows: stack-based and heap-based.

Heap-based, which are difficult to execute and the least common of the two, attack an application
by flooding the memory space reserved for a program.
Stack-based buffer overflows, which are more common among attackers, exploit applications and
programs by using what is known as a stack: memory space used to store user input.

Key Concepts of Buffer Overflow

 This error occurs when there is more data in a buffer than it can handle, causing data to overflow
into adjacent storage.
 This vulnerability can cause a system crash or, worse, create an entry point for a cyberattack.
 C and C++ are more susceptible to buffer overflow.
 Secure development practices should include regular testing to detect and fix buffer overflows.
These practices include automatic protection at the language level and bounds-checking at run-
time.
 Many programming languages are prone to buffer overflow attacks. However, the extent of
such attacks varies depending on the language used to write the vulnerable program

Let us study some real program examples that show the danger of such situations based on the C.
In the examples, we do not implement any malicious code injection but just to show that the
buffer can be overflow. Modern compilers normally provide overflow checking option during

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

the compile/link time but during the run time it is quite difficult to check this problem without
any extra protection mechanism such as using exception handling.

// A C program to demonstrate buffer overflow

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char *argv[])

{

// Reserve 5 byte of buffer plus the terminating NULL.

// should allocate 8 bytes = 2 double words,
// To overflow, need more than 8 bytes...
char buffer[5]; // If more than 8 characters input
// by user, there will be access
// violation, segmentation fault

// a prompt how to execute the program...

if (argc < 2)
{
printf("strcpy() NOT executed....\n");
printf("Syntax: %s <characters>\n", argv[0]);
exit(0);
}

// copy the user input to mybuffer, without any

// bound checking a secure version is srtcpy_s()
strcpy(buffer, argv[1]);
printf("buffer content= %s\n", buffer);

// you may want to try strcpy_s()

printf("strcpy() executed...\n");

return 0;
}
Compile this program in Linux and for output use command outpute_file INPUT

Input : 12345678 (8 bytes), the program run smoothly.

Input : 123456789 (9 bytes)
"Segmentation fault" message will be displayed and the program terminates.
The vulnerability exists because the buffer could be overflowed if the user input (argv[1]) bigger
than 8 bytes. Why 8 bytes? For 32 bit (4 bytes) system, we must fill up a double word (32 bits)
memory. Character (char) size is 1 byte, so if we request buffer with 5 bytes, the system will

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

allocate 2 double words (8 bytes). That is why when you input more than 8 bytes; the mybuffer
will be over flowed
.

Buffer Overflow Causes

Coding errors are typically the cause of buffer overflow.

 failing to allocate large enough buffers and neglecting to check for overflow problems.
These mistakes are especially problematic with C/C++, which does not have built-in
protection against buffer overflows. Consequently, C/C++ applications are often targets of
buffer overflow attacks.

How to stop a buffer overflow from attacking applications

Now that you know how a buffer-overflow attack works, you can better grasp how to prevent
them from infiltrating your system and taking control of your applications. Here are some ways
to bulk up your defenses and prevent a buffer overflow:
1. Avoid using library files: Library files, which are used in programming language and are
inherently insecure, are a target for hackers during application attacks. Any weakness found by a

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

hacker in a library file will also exist in all applications that use that library file, giving hackers a
glaring target for a potential attack.
2. Filter user input: Filtering out possibly dangerous HTML code and characters that could
cause database problems. For example, in ASP code, the apostrophe, quotation mark and
ampersand symbols are all reserved symbols. These reserved symbols can't be included within a
user's input or they will cause the application to crash. Filter them out and replace them with
something else to avoid complications and problems.
3. Test applications: Be sure to test all applications prior to deployment; trying to break into
every application to ensure secure coding. If the application breaks, it will be clear that there is a
problem that needs to be fixed before a hacker is able to exploit it.

TIME-OF-CHECK TO TIME-OF-USE FLAWS

In software development, time of check to time of use (TOCTOU, TOCTTOU or TOC/TOU) is

a class of software bugs caused by changes in a system between the checking of a condition
(such as a security credential) and the use of the results of that check. This is one example of a
race condition. Time-of-check, time-of-use race conditions occur when between the time in
which a given resource is checked, and the time that resource is used, a change occurs in the
resource to invalidate the results of the check.

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.

Time-of-check, time-of-use consequences

Access control: The attacker can gain access to otherwise unauthorized resources.
Authorization: race conditions such as this kind may be employed to gain read or write access
to resources which are not normally readable or writable by the user in question.
Integrity: The resource in question, or other resources (through the corrupted one), may be
changed in undesirable ways by a malicious user.
Accountability: If a file or other resource is written in this method, as opposed to in a valid way,
logging of the activity may not occur.
Non-repudiation: In some cases it may be possible to delete files a malicious user might not
otherwise have access to, such as log files.

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

What Happens During a Race Condition Attack?

Web applications, file systems, and networking environments are all vulnerable to a race condition
attack. Attackers might target an access control list (ACL), a payroll or human resources database,
a transactional system, a financial ledger, or some other data repository.

Although race condition attacks don’t happen frequently — because they’re relatively difficult to
engineer and attackers must exploit a very brief window of opportunity — when they do happen,
they can lead to serious consequences, including a system granting unauthorized privileges.
What’s more, race condition attacks are inherently difficult to detect.

Preventing Damage and Remediating Code Are Critical

It’s critical to scan and review code for race condition vulnerabilities and Exposure period to
check

Design: Strong locking methods may be designed to protect against this flaw.
Implementation: Use of system APIs may prevent check, use race conditions

INCOMPLETE MEDIATION::

 Incomplete mediation is another security problem that has been with us for decades.
 Attackers are exploiting it to cause security problems.
 Supplying 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.

How to stop a incomplete mediation from attacking applications

1) Don’t let client return a sensitive result .that can be easily recomputed by server
2) Use drop-down boxes/choice lists for data input.
3) Prevent user from editing input directly.
4) Check validity of data values received from client.

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

CONTROLS AGAINST PROGRAM THREATS

A wise engineer who finds a fault can deal with it in at least three ways:
1. by learning how, when and why errors occur,
2. by taking action to prevent mistakes, and
3. by scrutinizing products to find the instances and effects of errors that were missed.

There are many ways a program can fail and many ways to turn the underlying faults into security
failures. It is of course better to focus on prevention than cure; how do we use controls
during software development—the specifying, designing, writing, and testing of the program

The Nature of Software Development

Software development is often considered a solitary effort; a programmer sits with a specification
or design and grinds out line after line of code. But in fact, software development is a collaborative
effort, involving people with different skill sets who combine their expertise to produce a working
product. Development requires people who can
 specify the system, by capturing the requirements and building a model of how the system
should work from the users' point of view
 design the system, by proposing a solution to the problem described by the requirements and
building a model of the solution
 implement the system, by using the design as a blueprint for building a working solution
 test the system, to ensure that it meets the requirements and implements the solution as called
for in the design
 review the system at various stages, to make sure that the end products are consistent with
the specification and design models
 document the system, so that users can be trained and supported
 manage the system, to estimate what resources will be needed for development and to track
when the system will be done
 maintain the system, tracking problems found, changes needed, and changes made, and
evaluating their effects on overall quality and functionality

We can examine both product and process to see how each contributes to quality and in particular
to security as an aspect of quality. Let us begin with the product, to get a sense of how we recognize
high-quality secure software.
 Modularity, Encapsulation, and Information Hiding

Modularity
Modularization is the process of dividing a task into subtasks. This division is done on a logical
or functional basis. Each component performs a separate, independent part of the task.

Encapsulation
Encapsulation hides a component's implementation details, but it does not necessarily mean
complete isolation. Many components must share information with other components, usually with

Dr.J.R.Arunkumar Arbaminch University

Chapter 2 Program Security

good reason. However, this sharing is carefully documented so that a component is affected only
in known ways by others in the system.

Information Hiding
Developers who work where modularization is stressed can be sure that other components will
have limited effect on the ones they write.

Peer Reviews
We turn next to the process of developing software. Certain practices and techniques can assist us
in finding real and potential security flaws (as well as other faults) and fixing them before the
system is turned over to the users. Of the many practices available for building what they call
"solid software,"
 peer reviews
 hazard analysis
 testing
 good design
 prediction
 static analysis
 configuration management
 analysis of mistakes

Dr.J.R.Arunkumar Arbaminch University