CHAPTER 3 Program Security

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 48

CHAPTER 3 PROGRAM SECURITY

SONALI CHAUHAN Dept. of Information Technology - MSc-IT Part 2 Mumbai University

UDIT

Sonali C.

Introduction
In previous chapter we cover why we need security We will see in this chapter how to apply security And how it can be achieved. Protection programs is heart of security. To secure a program:

How do we keep programs free from flaws How do we protect computing resources against programs that contain flaws?

We will deal with writing of program.


Sonali C. 2

UDIT

Secure Programs Why security at program level?

What is security?

It implies some degree of trust that program enforce expected confidentiality, integrity, availability.

Security characteristic depends on application and users perceptions about software quality. Here we have to make sure that the program:

Do what it is suppose to do? Not what it is not suppose to do?

UDIT Sonali C. 3

What you must understand


What is fault? Cause of fault? What are the effect of faults?

Human makes mistake (error) in performing some s/w activity, error may lead to fault (incorrect data or action or command) in program which may results in failure (system not performing as required) of the system Fault is inside system where as failure can be seen by users i.e outside.

UDIT

Sonali C.

How to fix faults?


Penetrate and patch Patch introduce more problems Patch causes more side effect Patch address problem only in one place, not in other related place May affect non-functional requirements

UDIT

Sonali C.

TERMINOLOGYUnexpected Behavior
Inadequacies of patch-and-penetrate PROGRAM SECURITY FLAW

To achieve program security, one way is to compare requirements with the behavior.

i.e. Check whether program behaves as their designer intended or users expected.

Inappropriate program behavior caused by a program vulnerability (weakness).

Flaw - fault or failure - effect Vulnerability class of flaw -Cause

UDIT Sonali C. 6

Unexpected Behavior
A program with Trojan horse is vulnerable, but the user cannot see any security flaw in program. Address program security flaw to find causes not only in existing failure but also in incipient ones (not yet explore or partly exist) Not only to identify but also we have to prevent harm cause by flaws.

UDIT Sonali C. 7

Unexpected Behavior Program Flaw

Program flaw is in 2 category:

Inadvertent human errors


Validation error (permission check) Domain error (controlled access to data) Inadequate identification and authentication Boundary condition violation Logical error

Malicious and Intentionally induced flaws


Malicious Nonmalicious

UDIT

Sonali C.

Non-malicious Errors Buffer Overflows


Buffer is a place where data is held. It resides in memory and its finite Programmer need to set buffer size

Array bounds example (some languages do not check array bounds, and in others array bounds do not have to be pre-specified)
Char sample[10]; for(int i=0;i<10;i++) Sample[i] = A; Sample[10] = B;

UDIT

Sonali C.

The out-of-array-bounds data can overflow into :

UDIT

Sonali C.

10

UDIT

Sonali C.

11

Users data space, overwriting other existing data Users program data,

Overlaying an already executed instruction, with no effect Overlay an instruction not yet executed, with the result an instruction with operation code 0X42 (internal code for character B) will be executed. If there is no such instruction, the system will halt with illegal instruction exception. Otherwise the machine will use succeeding bytes as if they were rest of the instruction

UDIT

Sonali C.

12

Security Implication

What can a malicious programmer can do with buffer overflows?

Replace code in the system space, insert overflow data corresponding to machine code for instructions, and gain control back from the operating system, with higher privileges. Cause an overflow into the stack, change either

old stack pointer thereby changing the context for the calling procedure) or Return address to cause control to transfer where (s)he wants

Pass parameters on to a web server that causes buffer overflow and crashes the program
Sonali C. 13

UDIT

Non-malicious Errors Incomplete Mediation


Pass parameters to a web server that causes it to fail due to data type error, or execute with a wrong result. This problem can be altered by client side checking of input, or by limiting the clientside choices only to valid ones (by drop-down boxes, check boxes, etc.). However, this can be rendered useless if the client manually edits the URLs in the http requests.

UDIT Sonali C. 14

Security Implication
http://www.things.com/order.asp?custID=101 &part=555A&qy=20&price=10&shipcost=5&tot al=205

Malicious attacker tampered wit URL: http://www.things.com/order.asp?custID=101 &part=555A&qy=20&price=10&shipcost=5&tot al=25

UDIT

Sonali C.

15

Non-malicious Errors Time-of-check to Time-of-use errors


Also known as serialization or synchronization flaw Purchase at a store:

Costs $100 You count out the money on the counter Cashier turns around, you take $20 back Cashier doesn't notice Still get the $100 item

During the time that an access to resources (files) is checked and the time the result of the check is used, the user can change the descriptor of the resource, thereby exploiting the lack of synchronization Use of digital signatures can alleviate this problem
Sonali C. 16

UDIT

Malicious Code

Why worry about Malicious code? Malicious code can do anything that a program can. Malicious code runs under the users authority. Malicious code can do anything that a user can, but without his/her permission or knowledge Definition: Unanticipated or undesired effects in

programs or program parts, caused by an agent intent on damage.

UDIT

Sonali C.

17

CONT

Kinds of malicious code:

Virus: program that can pass on malicious code

to other nonmalicious programs by modifying them It will attach itself to a program, either destroying it or coexisting with it.
Transient: its life depends on the life of the host Resident: locates itself in memory, and can remain

active or be activated as a stand-alone program even after its attached program ends (runs even when host program isn't running)
UDIT Sonali C. 18

CONT

Trojan Horse: In addition to primary function,

also has a non-obvious malicious effect Logic bomb: detonates when a specified condition occurs Time bomb: logic bomb whose trigger is a time or date Worm: program that spreads copies of itself (as a standalone program) through a network

UDIT

Sonali C.

19

CONT

Rabbit: virus or worm that self-replicates without

bound, with the intent of exhausting some computing resource. Trapdoor or backdoor: Someone can access the program by other than obvious, direct call, perhaps with special privileges
Its undocumented entry point to the system Inserted during code development

UDIT

Sonali C.

20

Viruses & Targeted malicious code

How viruses attach & types of viruses Qualities appealing to virus writers Boot sector viruses and Memory-resident viruses Virus signatures Polymorphic viruses Virus prevention Targeted malicious code: Trapdoors, Salami attacks,
covert channels

UDIT

Sonali C.

21

How viruses attach & types of viruses

For a virus to do its work, it must be executed. Once executed, it may install itself in permanent memory, or spread itself E-mail attachments: A common means is via e-mail attachments Virus appended to a program: when the program is executed, the virus is also executed Virus that surrounds a program: Runs the original program, but has control before and after the program execution Integrated virus: integrates itself into the original program Document virus: virus implemented in a formatted document
Sonali C. 22

UDIT

Appended Virus
Dnt need any information about program Easy to write and append and simple Virus do its task and then transfers to original program.

UDIT

Sonali C.

23

How viruses attach & types of viruses

For a virus to do its work, it must be executed. Once executed, it may install itself in permanent memory, or spread itself E-mail attachments: A common means is via e-mail attachments Virus appended to a program: when the program is executed, the virus is also executed Virus that surrounds a program: Runs the original program, but has control before and after the program execution Integrated virus: integrates itself into the original program Document virus: virus implemented in a formatted document
Sonali C. 24

UDIT

Virus that surrounds a program

UDIT

Sonali C.

25

How viruses attach & types of viruses

For a virus to do its work, it must be executed. Once executed, it may install itself in permanent memory, or spread itself E-mail attachments: A common means is via e-mail attachments Virus appended to a program: when the program is executed, the virus is also executed Virus that surrounds a program: Runs the original program, but has control before and after the program execution Integrated virus: integrates itself into the original program Document virus: virus implemented in a formatted document
Sonali C. 26

UDIT

Integrated virus

Virus writer should know the structure of code

UDIT

Sonali C.

27

How viruses attach & types of viruses

For a virus to do its work, it must be executed. Once executed, it may install itself in permanent memory, or spread itself E-mail attachments: A common means is via e-mail attachments Virus appended to a program: when the program is executed, the virus is also executed Virus that surrounds a program: Runs the original program, but has control before and after the program execution Integrated virus: integrates itself into the original program Document virus: virus implemented in a formatted document
Sonali C. 28

UDIT

Qualities appealing to virus writers


Hard to detect Not easily destroyed or deactivated Spreads infection widely Can re-infect its home program or other programs Easy to create Machine independent and operating system independent

UDIT Sonali C. 29

How Virus Gain Control??

UDIT

Sonali C.

30

How Virus Gain Control?? Boot Sector Virus

Boot sector viruses: When a computer is turned on,


firmware recognizes the hardware present, tests them, copies a fixed number of bytes from the disk to a location in memory (bootstrap), and jumps to that address in memory in transferring control to the operating system. Chaining bootstrap makes installation of viruses attractive (by breaking the chain).

Gain control very early in boot process Cannot be detected easily Virus code is not easily noticed by user
Sonali C. 31

UDIT

How Virus Gain Control?? Boot Sector Virus

UDIT

Sonali C.

32

How Virus Gain Control?? Memory-resident viruses

Memory-resident viruses: attached to


memory-resident code since such code is executed frequently while the machine is running

UDIT

Sonali C.

33

Other Home of Virus

One-Time Execution: Virus executes only once,


spreading their infection and causing their effect in one time execution e.g. Often arrives through emails (executed just by opening) Macros Libraries Compilers Linkers

UDIT

Sonali C.

34

Detecting Virus Virus Signatures


Pattern of bytes that provide telltale signs of a virus. They are used by virus scanners to detect the presence of the virus In case of attached viruses, the start of the virus code becomes detectable signature Suspicious patterns such as JUMP instructions at the beginning of programs used by scanners to detect viruses Scanners are effective only if up to date signatures are used

UDIT Sonali C. 35

Detecting Virus
Tracking Storage Pattern Execution Pattern Transmission Pattern

Boot Process Disk Access Network Connection

UDIT

Sonali C.

36

Polymorphism Virus
Virus Signature can be the most reliable way for a scanner to detect Virus. A virus that can change its appearance Forms:
More than one alternative but with equivalent beginning words, on installation one of the words is installed Move pieces of the virus around to make detection difficult Embed random numbers Encrypting viruses

UDIT

Sonali C.

37

Virus Prevention

Not sharing executable code Setting e-mail handlers not to automatically open attachments Be careful with large datasets and graphics since they can have embedded in them executables Be careful with Microsoft file design problem (operating system may switch to the application of the hidden file type) Use only commercial software acquired from reliable, well-established vendors (?)
Sonali C. 38

UDIT

Virus Prevention
Test all new software on an isolated computer Open attachments only when known to be safe Make a recoverable system image and store it safely Backups of executable system files Use detectors regularly and update frequently

UDIT

Sonali C.

39

Truths, Misconceptions about Viruses


Virus can only affect MS-Windows: False Virus can modify hidden or read only files:

True
Can appear only in data files, Word docs, or only in programs: False. (Depends on what you mean by data) Spread only through floppies or email: False. What about file sharing, bulletin boards, etc.?

UDIT Sonali C. 40

Truths, Misconceptions about Viruses


Can't remain in memory after power off: True, but when the affected program is rerun, they're reloaded Virus cannot infect hardware: True Virus can be malevolent, benign, or benevolent: True

UDIT

Sonali C.

41

Targeted malicious code


Trapdoors: undocumented entry point to a module Sources of trapdoors:
During unit and integration testing, programmers use stubs (to mimic output) and drivers (to mimic input). They also embed control sequences in the design to support testing. If such code is not removed at the end of

the testing, they can be used as trapdoors Poor error checking: Unacceptable input may not be
caught but passed on to the user for use Undefined opcodes: hardware equivalent of poor error checking

UDIT

Sonali C.

42

Trapdoors
Trapdoors

can be useful in finding security flaws, but


Left on purpose with full understanding of their potential consequences Must be documented Access to them must be controlled

UDIT

Sonali C.

43

Trapdoors
Causes

of trapdoors: Trapdoors can persist in production because developers


Forget to remove them Intentionally leave them for testing Intentionally leave them for program maintenance Intentionally leave them as covert means of access

UDIT

Sonali C.

44

UDIT

Sonali C.

45

Salami attack

Programs that disregard small amounts of money in computations (interest, tax calculations, etc.) may be vulnerable to salami attack where such shavings from transactions can be accumulated elsewhere

UDIT

Sonali C.

46

Interface Illusion

Spoofing attack in which all or part of web page is false.

Keystroke Logging Man-in-the Middle Attack

Malicious program interjects itself between two program.

UDIT

Sonali C.

47

UDIT

Sonali C.

48

You might also like