chapter 3 - program security

7/23/2019 Chapter 3 - Program Security

1/52

By Mohammed Al-Saleh / JUST1

Chapter 3

Program Security

Security in Computing, 4thEd, Pfleeger


2/52


Chapter3

In this chapter

Programming errors with security implications buffer overflows, incomplete access control

Malicious code viruses, worms, Trojan horses

Program development controls against maliciouscode and vulnerabilities software engineering principles and practices

Controls to protect against program flaws inexecution operating system support and administrative controls


3/52


Chapter3

Programs Security

Protecting programs is at the heart of computersecurity programs constitute so much of a computing system

(the operating system, device drivers, the networinfrastructure, database management systems andother applications, even executable commands onweb pages!" all are called #programs$

%o we need to as two important &uestions'

ow do we eep programs free from flaws) ow do we protect computing resources against

programs that contain flaws)


4/52


Chapter3

Secure Programs

*hat we mean when we say that a program is+secure+ security implies some degree of trust that the program

enforces expected confidentiality, integrity, andavailability

-rom the point of view of a program or aprogrammer, how can we loo at a softwarecomponent or code fragment and assess its

security) similar to the problem of assessing software &uality in

general


5/52


Chapter3

Secure Programs

.ne way to assess security or &uality is to aspeopleto name the characteristics of softwarethat contribute to its overall security different answers from different people because the

importance of the characteristics depends on who isanaly/ing the software one person may decide that code is secure because it taes

too long to brea through its security controls someone else may decide code is secure if it has run for a

period of time with no apparent failures a third person may decide that any potential fault in meeting

security re&uirements maes code insecure


6/52


Chapter3

Secure Programs

0n assessment of security can also be influenced bysomeone1s general perspective on software &uality if your manager1s idea of &uality is conformance to specifications,

then she might consider the code secure if it meets securityre&uirements, whether or not the re&uirements are complete orcorrect

This security view played a role when a major computermanufacturer delivered all its machines with eyed locs since a eyed loc was written in the re&uirements 2ut the machines were not secure, because all locs were configured to use

the same ey

Thus, another view of security is fitness for purpose in this view, the manufacturer clearly had room for improvement


7/52


Chapter3

Secure Programs

n general, practitioners often loo at &uantityand types of faults for evidence of a product1s&uality (or lac of it! developers trac the number of faults found in

re&uirements, design, and code inspections and usethem as indicators of the liely &uality of the finalproduct


8/52


Chapter3

Fixing Faults

4ou might argue that a module in which 566faults were discovered and fixed is better thananother in which only 76 faults were discoveredand fixed

more rigorous analysis and testing had led to thefinding of the larger number of faults


9/52


Chapter3

Fixing Faults

8arly wor in computer security was based on theparadigm of +penetrate an patch,+ analysts searched for and repaired faults test a system1s security by attempting to cause it to

!ail The test was considered to be a +proof+ of security

if the system withstood the attacs, it was considered secure "n!ortunately# the proo! $ecame a counterexample

The problem discovery in turn led to a rapid effort to+patch+ the system to repair or restore the security owever, the patch efforts were largely useless, maing the

system less secure rather than more secure because theyfre&uently introduced new faults


10/52

By Mohammed Al-Saleh / JUST1%

Chapter3

omewor' -u// Testing


11/52


Chapter3

"nexpecte &eha'ior

0 better approach than +penetrate an patch,+ is to

compare the re&uirements with the behavior Test whether programs behave as their designers intended or

users expected unexpected behavior is a program security !la(

Program security flaws can derive from any ind of softwarefault They range from a misunderstanding of program re&uirements to a one9

character error in coding or even typing

two separate logical categories of program flaws ' nadvertent:unintentional human errors malicious, intentionally induced flaws

we still have to address the flaws; effects, regardless ofintention

+it doesn1t matter whether the stone hits the pitcher or the pitcher hits thestone, it1s going to be bad for the pitcher+


12/52


Chapter3

Security Fla(s

0 system attac often exploits an unintentional security

flaw to perform intentional damage


13/52


Chapter3

)ypes o! Fla(s

0 list of categories that helps distinguishing one ind of

problem from another and gives us a useful overview ofthe ways in which programs can fail to meet their securityre&uirements >alidation error (incomplete or inconsistent!' permission checs

occur when a program fails to chec that the parameterssupplied or returned to it conform to its assumptions aboutthem, or when these checs are misplaced

?omain error' controlled access to data occur when the intended boundaries between protection

environments are porous including implicit sharing ofprivileged:confidential data or when then the lower levelrepresentation of an abstract object, supposed to be hiddenin the current domain, is in fact exposed


14/52


Chapter3

)ypes o! Fla(s

%eriali/ation' program flow order permit asynchronous behavior of different system components to

be exploited (T.CTT.@!

2oundary condition violation' failure on first or last case occur due to omission of checs to assure that constraints (table

si/e, file allocation, or other resource consumption! are notexceeded

nade&uate identification and authentication' basis forauthori/ation permits operations to be invoed without sufficiently checing the

identity and the authority of the invoing entity

C


15/52


Chapter3

*onmalicious Program +rrors

@nintentional mistaes cause program malfunctions but some lead to more serious security vulnerabilities

C


16/52


Chapter3

&u!!er ,'er!lo(s

t is an example on 2oundary condition violation -e!inition

0 buffer (or array or string! is a space in which datacan be held

0 buffer resides in memory 2ecause memory is finite, a buffer1s capacity is finite in many programming languages the programmer

must declare the buffer1s maximum si/e Then the compiler can set aside that amount of space

C


17/52


Chapter3

&u!!er ,'er!lo(s

8xample char sampleA56B" .ne byte for elements sampleA6B through sampleAB =ow we execute the statement'

sampleA56B D 121" The subscript 56 is out of bounds

The compiler can detect it during the compilation owever, if the statement were

sampleAiB D 121" we could not identify the problem until i was set during execution

The problem1s occurrence depends on what is adjacent to thearray sample

C


18/52


Chapter3

&u!!er ,'er!lo(s

8xample suppose each of the ten elements of the array sample

is filled with the letter 0 and the erroneous referenceuses the letter 2, as follows'

for (i=0; i


19/52


Chapter3

&u!!er ,'er!lo(s .+xample /ont0

%o there are four cases to consider in deciding where

the 121 goes

C


20/52


Chapter3

&u!!er ,'er!lo(s .+xample /ont0

f the extra character overflows into the user1s data space it simply overwrites an existing variable value

perhaps affecting the program1s result but affecting no other program or data

n the second case, the 121 goes into the user1s programarea f it overlays an already executed instruction

no effect

f it overlays an instruction that is not yet executed the machine will try to execute an instruction with operation code 6xE7

the internal code for the character 12F

%pilling over into system data or code areas producessimilar results to those for the user1s space' computing witha faulty value or trying to execute an improper operation

C


21/52


Chapter3

Process ress Space

C


22/52


Chapter3

/all Stac cti'ation ecor

C


23/52


Chapter3

Integer ,'er!lo(

http'::wwwphracorg:issueshtml)issueDG6HidD56

%ince an integer is a fixed si/e (37 bits for the purposes of thispaper!, there is a fixed maximum value it can store *hen anattempt is made to store a value greater than this maximum value itis nown as an integer overflow

Most compilers seem to ignore the overflow, resulting in an

unexpected or erroneous result being stored This can get dangerous if the calculation has to do with the si/e of a

buffer or how far into an array to index *hat happens thenII

a D 6xffffffff b D 6x5 r D a J br D (6xffffffff J 6x5! K 6x566666666

r D (6x566666666! K 6x566666666 D 6 This is often called a +wrap around+, as the result appears to wrap around to 6

C
http://www.phrack.org/issues.html?issue=60&id=10http://www.phrack.org/issues.html?issue=60&id=10


24/52


Chapter3

Integer ,'er!lo( +xamples

+xample 1

#include

int main(void){

unsigned int num = 0xffffffff;

printf("num ! = 0xxn"$ num !);

return 0;

%

&' * '&

The output of this program looks like

this:

num ! = 0x0

+xample 2

#include


25/52


Chapter3

Incomplete eiation .ex0 %L njection!

Nohn -iore

%88CT O from C@%T.M8


26/52


Chapter3

Incomplete eiation .ex0 %L njection!

Nohn -iore1 or 151D15

%88CT O from C@%T.M8


27/52


Chapter3

omewor' bring examples on

Cross9%ite9%cripting (C%%!

C


28/52


Chapter3

)imeo!/hecto)imeo!"se +rrors.),/)),"


29/52


Chapter3

)imeo!/hecto)imeo!"se +rrors.),/)),"

Computing 8xample' #file$ is a symbolic lin for a file that can be opened normally The attacer, after access is called, can change the #file$

)he program (ith ),/)),"

'ulnera$ility

ttacer

if (access(file* 78/) := 0) $e%it(1);

,,ritin oer ,etc,passd

fd = open(file*/87/>?@);rite(fd* uffer* sieof(uffer));

,, After t!e access c!ecC,, and Before t!e open* file points tot!e passord dataase

sDmlinC(,etc,passd* file);

C


30/52


Chapter3

iruses an ,ther alicious /oe

Much of the wor done by a program is invisibleto users who are not liely to be aware of anymalicious activity

Can you tell

if a game program does anything in addition to itsexpected interaction with you)

*hich files are modified by a word processor whenyou create a document)

*hich programs execute when you start yourcomputer or open a web page)

Most users cannot answer these &uestions

C


31/52


Chapter3

alicious /oe

=one of us lie the unexpected, especially in ourprograms Malicious code behaves in unexpected ways

thans to a malicious programmer1s intention

Malicious code can do anything any otherprogram can writing a message on a computer screen, stopping a

running program, generating a sound, or erasing a

stored file .r malicious code can do nothing at all right now" it

can be planted to lie dormant, undetected, until someevent triggers the code to act (eg, based on time!

C


32/52


hapter3

alicious /oe

malicious code is still around, and its effects aremore pervasive *hat it loos lie and how it wors) ow can malicious code tae control of a system)

ow can it lodge in a system) ow does malicious code spread) ow can it be recogni/ed) ow can it be detected) ow can it be stopped) ow can it be prevented)

C


33/52


hapter3

ins o! alicious /oe

/oe )ype /haracteristics

>irus 0ttaches itself to program andpropagates copies of itself to otherprograms

*orm Propagates copies of itself through anetwor

Trojan horse oos legal:normal programs, but

contains unexpected, additionalfunctionality

ogic bomb Triggers action when condition occurs

Time bomb Triggers action when specified timeoccurs

Trapdoor:bacdoor 0llows unauthori/ed access tofunctionality


34/52


hapter3

:eneral +xploit )imeline

The general exploit timeline:scenario follows this se&uence' 0n attacer discovers a previously unnown vulnerability The manufacturer becomes aware of the vulnerability %omeone develops code (called proof of concept! to demonstrate

the vulnerability in a controlled setting The manufacturer develops and distributes a patch or wor9

around that counters the vulnerability @sers implement the control %omeone extends the proof of concept, or the original vulnerability

definition, to an actual attac

0s long as users receive and implement the controlbefore the actual attac, no harm occurs

0n attac before availability of the control is called a ;eroay exploit

Ch


35/52


hapter3


36/52


hapter3

ppene iruses

0 program virus attaches itself to a program"then, whenever the program is run, the virus isactivated

Ch


37/52


hapter3

ppene iruses

0n alternative to the attachment is a virus thatruns the original program but has control beforeand after its execution

>irus %urrounding a Program

Ch


38/52


hapter3

ppene iruses

0 third situation occurs when the virus replacessome of its target, integrating itself into theoriginal code of the target

>irus ntegrated into a Program

Ch


39/52


hapter3

irus /ompletely eplacing a Program

Ch


40/52


hapter3

&oot Sector iruses

Ch


41/52


hapter3

emoryesient iruses

%ome parts of the operating system and most user

programs execute, terminate, and disappear -or very fre&uently used parts of the operating system and for a

few speciali/ed user programs, it would tae too long to reloadthe program each time it was needed %uch code remains in memory and is called +resident+ code 8g, a routine that interprets eys pressed on the eyboard

>irus writers lie to attach viruses to resident code 0 virus can also modify the operating system1s table of programs

to run

8g, changing the startup programs from *indows registry sothe virus starts every boot

0lso, viruses lie application programs (such asM% word! and fre&uently used libraries

Ch


42/52


hapter3

irus Signatures

The pattern which distinguishes a virus is calleda signature 0nti9viruses (or called virus scanners! loo for

signatures to identify a virus The signature is part of the virus code

Ch


43/52


hapter3


44/52


hapter3

Polymorphic iruses

0 virus that can change its appearance is calleda polymorphic 'irus0(Poly means +many+ andmorph means +form+!

Ch


45/52


hapter3

Pre'ention o! irus In!ection

several techni&ues for building a reasonably safecommunity @se only commercial software ac&uired from reliable,

well9established vendors @se virus detectors (often called virus scanners!

regularly and update them daily .pen attachments only when you now them to be

safe

Mae a recoverable system image and store it safely Mae and retain bacup copies of executable system

files Test all new software on an isolated computer

Ch


46/52


apter3

)he &rain irus

.ne of the earliest viruses one of the most intensively studied was given its name because it changes the label of any

dis it attacs to the word +2


47/52


apter3

)he Internet =orm

7 =ovember 5QQ caused serious damage to the networ The perpetrator was


48/52


apter3

)he Internet =orm

The worm exploited several nown flaws and

configuration failures of 2ereley version E of the @nixoperating system

The worm1s primary effect was resource exhaustion Many copies of the worm, all busily attempting to spread the

infection 0 second9order effect was the disconnection of many

systems from the nternet third9order effect' isolation and inability to perform

necessary wor The worm caused an estimated G,666 installations to shut

down or disconnect from the nternet cost of the damage range from 566,666 to R million

Cha

/


49/52


apter3

/oe e

appeared in the middle of 7665 propagates itself on web servers running Microsoft1s

nternet nformation %erver (%! software infected more than 7S6,666 systems in just nine hours This spread has the potential to disrupt business and

personal use of the nternet for applications such as e9commerce, e9mail and entertainment

the Code


50/52


apter3

eystroe >ogging

-irst, recogni/e that there is not a direct path between a

ey you press on your eyboard and the program (let1ssay a word processor! that handles that eystroe *hen you press 0

it activates a switch that generates a signal that is received by a devicedriver, converted and analy/ed and passed along, until finally your word

processor receives the 0 there is still more conversion, analysis, and transmission until the 0 appears

on your screen

0 malicious program called a eystroe loggerretains asurreptitious copy of all eys pressed

Cha

i th il tt


51/52


apter3

anintheile ttacs

0 eystroe logger is a special form of the more

general man9in9the9middle attac malicious program interjects itself between two

other programs

.ne example of a man9in9the9middle attaccould be a program that operated between yourword processor and the file system each time you thought you were saving your file, the

middle program prevented that, or scrambled yourtext or encrypted your file

Cha

/ t l i t P )h t


52/52

apter3

/ontrols gainst Program )hreats

development controls limit software development activities, maing it harder for a

developer to create malicious (or inadvertent! programs produce better software

operating system controls

limit access to computing system objects and provides safesharing of information among programs

administrative controls limit the inds of actions people can tae improve system usability, reusability, and maintainability

chapter 3 - program security

Documents