الرابعة.pdf

Information Security Chapter 3 Programs and Programming Charles P. Pfleeger Overview In this chapter;  Programming oversights:  buffer overflows, incomplete mediation, time-of- check to time-of-use errors.  Undocumented Access Point, Off-by-One Err...

Information Security Chapter 3 Programs and Programming Charles P. Pfleeger Overview In this chapter;  Programming oversights:  buffer overflows, incomplete mediation, time-of- check to time-of-use errors.  Undocumented Access Point, Off-by-One Error  Integer Overflow  Unterminated Null-Terminated String  Parameter Length, Type, and Number  Unsafe Utility Program, Race Condition  Unsynchronized Activity  Malicious code:  viruses, worms, Trojan horses.  Countermeasures:  Countermeasures for Users  Countermeasures for Developers  Countermeasure Specifically for Security  Countermeasures That Don’t Work. Overview Countermeasures:  Countermeasures for Users  Countermeasures for Developers:  program development techniques, security principles; − Software Engineering (SWE) principles and practices.  Countermeasure Specifically for Security  Countermeasures That Don’t Work we begin to study how to apply security in computing, We start with;  why we need security at the program level; and  how we can achieve it. Overview Programs are simple things but they can wield mighty power;  Programs are just strings of 0s and 1s, representing elementary machine commands such as;  move one data item, compare two data items, or branch to a different command.  Those primitive machine commands implement higher-level programming language constructs such as:  conditionals, repeat loops, case selection, and arithmetic and string operations.  Instruction by instruction, those zeros and ones become pacemaker functions, satellite control, smart-home technology services, traffic management, and digital photography. Overview The Intel 32- and 64-bit instruction set has about 30 basic primitives, such as;  move, compare, branch, increment and decrement, logical operations, arithmetic operations, trigger I/O, generate and service interrupts, push, pop, call, and return, and;  specialized instructions to improve performance on computations such as:  floating point operations or cryptography. These few machine commands are sufficient to implement the vast range of programs we know today; Overview Protecting programs is at the heart of computer security because;  programs constitute so much of a computing system:  the operating system,  device drivers,  the network infrastructure,  database management systems, and  other applications, even executable commands on web pages. We call all these pieces of code "programs“;  Most programs are written in higher-level languages such as Java, C, C++, Perl, or Python; Overview So we need to ask two important questions:  How do we keep programs free from flaws?  How do we protect computing resources against programs that contain flaws? One approach to judging quality in security has been fixing faults;  100 faults were discovered and fixed is better than another in which only 20 faults were discovered and fixed; ― more rigorous analysis and testing had led to the finding of the larger number of faults. Overview A security problems in programs and programming can reside anywhere between the machine hardware and the user interface;  Two or more problems may combine in negative ways, ― some problems can be intermittent or occur only when some other condition is present, and ― the impact of problems can range from annoying (perhaps not even perceptible) to catastrophic. Security failures can result from intentional or nonmalicious causes;  both can cause harm.  some security problems result from nonmalicious oversights or blunders, but others are intentional; A malicious attacker can exploit a nonmalicious flaw to cause real harm. Overview We now study several common program failings;  A simple errors during programming can lead to: − large-scale problems during execution. − real attacks that have been caused by program flaws. − We use the term flaw or bug;  as you can see in Sidebar 3-1, the language for describing program problems is not universal. When a human makes a mistake, called an error;  in software activity, the error may lead to; − a fault, or an Incorrect step, command, process, or data definition in a computer program, design, or documentation. − Ex. a designer may misunderstand a requirements 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 user manual. − A single error can generate many faults, and a fault can reside in any development or maintenance product. Overview A failure is a departure from the system's required behavior;  a failure indicates that the system is not performing as required, even though it may be performing as specified.  It can be discovered before or after system delivery; ─ during testing, or during operation and maintenance.  Since the requirements documents can contain faults, A fault is an inside view of the system;  as seen by the eyes of the developers. A failure is an outside view;  a problem that the user sees. Types of Flaws Landwehr et al. present a taxonomy of program flaws;  intentional flaws; divided into: ― malicious and ― nonmalicious ones.  inadvertent flaws; divided into: ― validation error (incomplete or inconsistent): permission checks, ― domain error: controlled access to data, ― serialization and aliasing: program flow order, ― inadequate identification and authentication: basis for authorization, ― boundary condition violation: failure on first or last case, ― other exploitable logic errors. Unintentional (Nonmalicious) Programming Oversights (Nonmalicious Program Errors) Program flaws can have two kinds of security implications:  They can cause integrity problems leading to harmful output or action, and  they offer an opportunity for exploitation by a malicious actor. Programming oversights or nonmalicious program errors:  buffer overflows, incomplete mediation, time-of- check to time-of-use errors, Off-by-One Error, Undocumented Access Point, Integer Overflow,  Unterminated Null-Terminated String, Parameter Length, Type, and Number, Unsafe Utility Program, Race Condition, Unsynchronized Activity. Buffer Overflows Definition:  A buffer (or array or string) is a space in which data can be held, and a buffer overflow occurs when a program exceeds the space allocated for the buffer.  A buffer overflow takes place when too much data are accepted as input to a specific process.  A buffer is an allocated segment of memory. A buffer overflow:  the basic problem is easy to describe, locating and preventing such difficulties are challenging.  the impact of an overflow can be subtle and disproportionate to the underlying oversight.  buffer overflows have existed almost as long as higher- level programming languages with arrays;  A buffer overflow is often the initial toehold for mounting a more damaging strike.  Most buffer overflows are simple programming oversights, but they can be used for malicious ends. Buffer Overflows; Anatomy of Buffer Overflows Buffer overflows often come from innocent programmer oversights or failures to document and check for excessive data;  buffer overflows have existed almost as long as higher- level programming languages with arrays.  Early overflows were simply a minor annoyance to programmers and users, a cause of errors and sometimes even system crashes.  More recently, however, attackers have used them as vehicles to cause first a system crash and then a controlled failure with a serious security implication.  The CVE records database (reported by cvedetails.com)  in July 2022 contained 179,663 records, − of which buffer overflows accounted for 21,945 entries or over 12%. − The large proportion of security vulnerabilities based on buffer overflows shows that developers must pay more attention now to what had previously been thought to be just a minor annoyance. Buffer Overflows; Memory Allocation Memory is a limited but flexible resource;  any memory location can hold any piece of code or data.  To make managing computer memory efficient, − OSs jam one data element next to another, without regard for data type, size, content, or purpose. − Most operating systems and hardware do not implement strong separation.  Computers use a pointer or register known as a program counter that indicates the next instruction.  Figure 3-1 show a typical memory organization; Buffer Overflows; Memory Allocation From Figure 3-1 we show a typical arrangement of the contents of memory, showing:  code, local data,  the heap: storage for dynamically created data, and  the stack: storage for subtask call and return data. Instructions move from the bottom (low addresses) of memory up;  left unchecked, − execution would proceed through the local data area and into the heap and stack.  execution typically stays within the area assigned to program code.  Buffer Overflows; Code and Data A different data types, instructions, structures, utility routines, and user files in memory are just strings of 0s and 1s;  Each computer instruction determines how data values are interpreted: − For each instruction a unique code.  In memory, code is indistinguishable from data; − The origin of code (respected source or attacker) is also not visible. − Usually we do not treat code as data, or vice versa; − attackers sometimes do, however, especially in memory overflow attacks.  See figure 3.2; Buffer Overflows; Harm from an Overflow Let us suppose a malicious person understands the damage that can be done by a buffer overflow; that is,  we are dealing with more than simply a normal, bumbling programmer.  The malicious programmer thinks deviously: − What data values could I insert to cause mischief or damage, and − what planned instruction codes could I force the system to execute?  We present two buffer overflow attacks that are used frequently: − the attacker may replace code in the system space. − the intruder may wander into an area called the stack and heap. Buffer Overflows; Harm from an Overflow the attacker may replace code in the system space;  every program is invoked by the OS and that the OS may run with higher privileges,  if the attacker can gain control by masquerading as the OS,  the attacker can execute many commands in a powerful role.  by replacing a few instructions right after returning from his or her own procedure,  the attacker regains control from the OS, possibly with raised privileges,  This technique is called privilege escalation.  If the buffer overflows into system code space, the attacker merely inserts overflow data that correspond to the machine code for instructions.  Privilege escalation, executing attack code with higher system permissions, is a bonus for the attacker. Buffer Overflows; Harm from an Overflow The intruder may wander into an area called the stack and heap;  Subprocedure calls are handled with a stack,  This structure works when procedure calls can be nested,  with each return causing control to transfer back to the immediately preceding routine at its point of execution.  Each time a procedure is called, its parameters, the return address and other local values are pushed onto a stack.  An old stack pointer is also pushed onto the stack, and a stack pointer register is reloaded with the address of these new values.  by causing an overflow into the stack;  the attacker can change either the old stack pointer (changing the context for the calling procedure); or  the return address; causing control to transfer where the attacker wants when the subprocedure returns.  Changing the context or return address allows the attacker to redirect execution to code written by the attacker. Buffer Overflows; Harm from an Overflow An alternative style of buffer overflow occurs when parameter values are passed into a routine,  especially when the parameters are passed to a web server on the Internet.  Parameters are passed in the URL line, with a syntax similar to: http://www.somesite.com/subpage/userinput.asp?parm1=( 808)555-1212  The attacker might question: − what the server would do with a really long telephone number, say, one with 500 or 1000 digits.  Passing a very long string to a web server is a slight variation on the classic buffer overflow, but no less effective. Buffer Overflows; Overwriting Memory If you write an element past the end of an array or you store an 11-byte string in a 10-byte area;  that extra data has to go somewhere, − often it goes immediately after the last assigned space for the data. Now we execute the statement: sample = ‘B’;  The subscript is out of bounds, so we have a problem.  The nicest outcome (from a security perspective) is for the compiler to detect the problem and mark the error during compilation. However, if the statement were sample[i] = ‘B’;  then the compiler could not identify the problem until i was set during execution either − to a proper value (0:9) or − to an out-of-bounds subscript (less than 0 or greater than 9). Unfortunately,  in some languages, buffer sizes do not have to be predefined, so there is no way to detect an out-of-bounds error. Buffer Overflows; Implications of Overwriting Memory The problem’s occurrence depends on what is adjacent to the array sample;  For example, suppose the following statements: for (i=0; i