s ecure p rogramming 3. s tatic a nalysis as p art of the c ode r eview ( including bo d...
TRANSCRIPT
1
SECURE PROGRAMMING
3. STATIC ANALYSIS AS PART OF THE CODE REVIEW (INCLUDING BO DEMONSTRATION)
Chih Hung Wang
Reference:1. B. Chess and J. West, Secure Programming with Static Analysis, Addison-Wesley, 2007.2. R. C. Seacord, Secure Coding in C and C++, Addison-Wesley, 2006.
2
Performing a Code Review
A security-focused code review happens for a number of different reasons: Some reviewers start out with the need to find a
few exploitable vulnerabilities to prove that additional security investment is justified.
For every large project that didn’t begin with security in mind, the team eventually has to make an initial pass through the code to do a security retrofit.
At least once in every release period, every project should receive a security review to account for new features and ongoing maintenance work.
3
Performing a Code Review (cont.)
Steve Lipner estimates that at Microsoft security activities consume roughly 20% of the release schedule the first time a product goes through Microsoft’s Security Development Lifecycle. In subsequent iterations, security requires less than 10% of the schedule.
4
The Review Cycle (1)
The four major phases in the cycle are: Establish goals Run the static analysis Review code (using output from the tool) Make fixes
5
The Review Cycle (2)
6
The Review Cycle (3)
Establish Goals A well-defined set of security goals will help
prioritize the code that should be reviewed and criteria that should be used to review it.
Your goals should come from an assessment of the software risks you face. “If it can be reached from the Internet, it has to be
reviewed before it’s released.” “If it handles money, it has to be reviewed at least
once a year.” “We can’t fail our next compliance audit. Make sure
the auditor gives us a clean bill of health.” “We’ve been embarrassed by a series of cross-site
scripting vulnerabilities. Make it stop.”
7
The Review Cycle (4)
Run Static Analysis Tools Run static analysis tools with the goals of the review in
mind. To get started, you need to gather the target code, configure the tool to report the kinds of problems that pose the greatest risks, and disable checks that aren’t relevant.
8
The Review Cycle (5)
Review Code Now it’s time to review the code with your own
eyes. Go through the static analysis results, but don’t limit yourself to just analysis results.
We routinely find other bugs right next door to a tool-reported issue. This “neighborhood effect” results from the fact that static analysis tools often report a problem when they become confused in the vicinity of a sensitive operation.
9
The Review Cycle (6)
Collaborative auditing is a form of peer review. Structured peer reviews are a proven technique for identifying all sorts of defects.
If, during the review process, you identify a problem that wasn’t found using static analysis, return to step 2: Write custom rules to detect other instances of the same problem and rerun the tools.
Human eyes are great for spotting new varieties of defects, and static analysis excels at making sure that every instance of those new problems has been found.
10
The Review Cycle (7)
Make Fixes Two factors control the way programmers respond
to the feedback from security review: Does security matter to them? If getting security right is
a prerequisite for releasing their code, it matters. Anything less is shaky ground because it competes with adding new functionality, fixing bugs, and making the release date.
Do they understand the feedback? Understanding security issues requires security training. It also requires the feedback to be written in an intelligible manner. Results stemming from code review are not concrete the way a failing test case is, so they require a more complete explanation of the risk involved.
When programmers have fixed the problems identified by the review, the fixes must be verified.
11
Steer Clear of the Exploitability Trap Security review should not be about creating flashy
exploits, but all too often, review teams get pulled down into exploit development.
Three possible verdicts that a piece of code might receive during a security review: Obviously exploitable Ambiguous Obviously secure
Don’t fall into the exploitability trap: Get the bugs fixed! A “security researcher” who finds a new buffer overflow
might be able to garner fame and glory by publishing the details, even if it is not possible to build an attack around the bug. Software companies sometimes find themselves issuing security patches even though all indications are that a defect isn’t exploitable.
12
Five Lame Executes for Not Fixing Bad Code
1. “I trust system administrators.” 2. “You have to authenticate before you can
access that page.” 3. “No one would ever think to do that!” 4. “That function call can never fail.” 5. “We didn’t intend for that to be
production-ready code.”
13
Adding Security Review to an Existing Development Process
Static analysis should be used as part of a secure development lifecycle, not as a replacement for a secure development lifecycle. Tools can make programmers more efficient at
tackling the software security problem, but tools alone cannot solve the problem.
14
Adoption Anxiety
All the software development organizations we’ve ever seen are at least a little bit chaotic, and changing the behavior of a chaotic system is no mean feat.
15
Who Runs the Tool?
Ideally, it wouldn’t matter who actually runs the tool, but a number of practical considerations make it an important question, such as access to the code. Many organizations have two obvious choices: The Security Team
For this to work, you must ensure that your security team has the right skill set—in short, you want security folks with software development chops.
The Programmers Programmers possess the best knowledge about how
their code works. Combine this with the vulnerability details provided by a tool, and you’ve got a good reason to allow development to run the operation.
All of the Above
16
When is the Tool Run? While the Code Is Being Written
Integrate the source code analysis tool into the programmer’s development environment so that the programmer can run on-demand analysis and gain expertise with the tool over time.
At Build Time For most organizations, software projects have a well-
defined build process, usually with regularly scheduled builds. Performing analysis at build time gives code reviewers a reliable report to use for direct remediation, as well as a baseline for further manual code inspection.
At Major Milestones Organizations that rely on heavier-weight processes
have checkpoints at project milestones, generally near the end of a development cycle or at some large interval during development.
17
What Happen to the Results?
Output Feeds a Release Gate A Central Authority Doles Out Individual
Results A Central Authority Sets Pinpoint Focus
18
Static Analysis Metrics
Metrics for Tactical Focus Many simple metrics can be derived from static
analysis results. Here we look at the following: Measuring vulnerability density Comparing projects by severity Breaking down results by category Monitoring trends
19
Measuring Vulnerability Density
Dividing the number of static analysis results by the number of lines of code is an awful way to measure risk, but it’s a good way to measure the amount of work required to do a complete review.
20
The Density Deception (1)
21
The Density Deception (2)
The program in the previous page has 18 lines, and any static analysis tool will point out two glaring buffer overflow vulnerabilities: the calls to gets() on lines 10 and 12. Divide 2 by 18 for a vulnerability density of 0.111. Now consider another program that performs exactly the same computation:
22
The Density Deception (3)
23
The Density Deception (4)
The program in the previous page calls gets(), too, but it uses a separate function to do it. The result is that a static analysis tool will report only one vulnerability (the call to gets() on line 17). Divide 1 by 18 for a vulnerability density of 0.056.
The second program is just as vulnerable as the first, but its vulnerability density is 50% smaller!
The moral to the story is that the way the program is written has a big impact on the vulnerability density. This makes vulnerability density completely meaningless when it comes to quantifying risk.
24
Comparing Projects by Severity Static analysis results can be applied for project comparison
purposes. Comparing projects side by side can help people understand how much work they have in front of them and how they compare to their peers.
25
Breaking Down Results by Category (1)
Single project grouped by category
26
Breaking Down Results by Category (2)
Source code analysis result from a series of nightly builds
27
Process Metrics (1) Vulnerability dwell
After an auditor identifies a vulnerability, how long, on average, does it take for the programmers to make a fix? We call this vulnerability dwell.
28
Process Metrics (2) At the point the project is first reviewed, audit
coverage goes to 100%. Then, as the code continues to evolve, the audit coverage decays until the project is audited again.
29
Process Metrics (3)
At the same time the code review is taking place, development is in full swing, so the issues in the code continue to change. As the auditors work, they report vulnerabilities.
30
Process Metrics (4)
Around build 14, the auditors have looked at all the results, so the total number of results is the same as the number reviewed.
Development work is not yet complete, though, and soon the project again contains unreviewed results.
As the programmers respond to some of the vulnerabilities identified by the audit team, the number of results begins to decrease and some of the identified vulnerabilities are fixed.
31
BUFFER OVERFLOW DEMONSTRATION
32
BO References
References : Buffer Overflow Example Papers and Videos
Papers: http://insecure.org/stf/smashstack.html http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/
stack_smashing.pdf
Videos: http://www.securitytube.net/video/231 http://www.benjaminhumphrey.co.uk/simple-buffer-ove
rflow-exploit/
33
Stack Smashing (1)
What's Problem?
#include <stdio.h>#include <string.h>#include <stdbool.h>
bool IsPasswordValid(void);int main(void) { bool PWverify;
puts("Enter your password:");PWverify = IsPasswordValid();if (!PWverify) {
puts("Password Error!! Please try again.");
return -1;}else puts("Welcome. Your password is
correct.");return 0;
}
bool IsPasswordValid(void) {char Password[12];
gets(Password);if (!strcmp(Password, "secure pro"))
return(true);else return(false);
}
34
Stack Smashing (2) GDB
GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.
GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:
Start your program, specifying anything that might affect its behavior.
Make your program stop on specified conditions. Examine what has happened, when your program has stopped. Change things in your program, so you can experiment with
correcting the effects of one bug and go on to learn about another. The program being debugged can be written in Ada, C, C++,
Objective-C, Pascal (and many other languages). Those programs might be executing on the same machine as GDB (native) or on another machine (remote). GDB can run on most popular UNIX and Microsoft Windows variants.
http://www.gnu.org/software/gdb/
35
Stack Smashing (3)
Execute GDBgdb buf1.exedisass
IsPasswordValid
36
Stack Smashing (4)
Observe main()
disass main
37
Stack Smashing (5) Using break
38
Stack Smashing (6)
Find where is the input password
我們發現,當 $esp-28 時為資料開始輸入 0x34333231 ( 表示我們輸入資料為 1234) 0x00401353 is the return address
1. The distance of the last byte of password and the return address is 4*3=12 bytes.
2. We must input at least 12+ 12 + 4 = 28 bytes to overwrite the return address.
3. Try x/8wx $esp-4
39
Stack Smashing (7)
Rerun the program…
40
Stack Smashing (8)
Check the memory:
0x31313131 denotes “1111” 。 0x38373635 is the overwritten "return
address".
Overwrittenreturn address
41
Stack Smashing (9) Try to modify the return address
42
Stack Smashing (10)
Rerun the program 123456789012345678901234\0x75 \0x13 \0x40
43
Stack Smashing (11)
Execute and test
44
Stack Smashing (12)
Homework: Do it yourselves
#include <stdio.h>#include <string.h>#include <stdbool.h>
bool IsPasswordValid(void);int main(void) { bool PWverify;
puts("Enter your password:");PWverify = IsPasswordValid();if (!PWverify) {
puts("Wrong!! Wrong!! Wrong!!");
return -1;}else {
puts("Welcome. Your password is correct."); system("notepad.exe");
}return 0;
}
bool IsPasswordValid(void) {char Password[12];
gets(Password);if (!strcmp(Password, "secure pro"))
return(true);else return(false);
}
45
Stack Smashing (13)
Open notepad
46
Stack Smashing (14)
Attack result
47
Stack Smashing (15)
Using HxD (Hex editor) to make the input file
48
Stack Smashing (16)
Attack process
49
Stack Smashing (17)
buf1_m < 1.in
50
Buffer Overflow Prevention (1)
Input Validation A simple method Check all inputs (key-in, files, networks,
configurations...)
51
Buffer Overflow Prevention (2)
Check the input length!!
#include <stdio.h>#include <string.h>#include <stdbool.h>
int testfunc(char *);int main(void) { char str1[20]; gets(str1); testfunc(str1); return 0;}int testfunc(char *arg) { char buff[20]; if (strlen(arg) >= sizeof(buff)){ puts("Input Error!"); return -1; } strncpy(buff, arg, 19); buff[19]='\0'; puts("Input OK!"); printf("Input string is: %s", buff); return 0;}
Normal
Too long!!
52
Buffer Overflow Prevention (3)
Avoid using gets function It is a dangerous function because it directly
inputs the string without checking the length. Try to use fgets. It can control the input length.
53
Buffer Overflow Prevntation (4)
Revised version
#include <stdio.h>#include <string.h>#include <stdbool.h>
bool IsPasswordValid(void);int main(void) { bool PWverify;
puts("Enter your password:"); PWverify = IsPasswordValid(); if (!PWverify) { puts("Password Error!! Please try again."); return -1; } else puts("Welcome. Your password is correct."); return 0;}
bool IsPasswordValid(void) { char Password[12];
if (fgets(Password, 12, stdin)==NULL) { puts("Read error!!"); return -1; } printf("The password is: %s\n", Password); if (!strcmp(Password, "secure pro")) return(true); else return(false);}
54
Buffer Overflow Prevention (5)
Test result : Input "This is a long string", we can see that the
output result is "This is a l \0" (the last one is null termination).
55
Buffer Overflow Prevention (6)
Using GDB to observe the stack status Input "12345678901234567890123456781111" 0x00313039 in 11th byte and then we see the
null (0x00). Other memories were not overwritten.
56
Stack Smashing in Linux (1)
Note that the function PrivateTest() would not be executed in this program
#include <stdio.h>#include <string.h>#include <stdbool.h>
int PrivateTest(void);bool IsPasswordValid(void);int main(void) { bool PWverify;
puts("Enter your password:");PWverify = IsPasswordValid();if (!PWverify) {
puts("Password Error!! Please try again.");
return -1;}else puts("Welcome. Your
password is correct.");return 0;
}
57
Stack Smashing in Linux (2)
Cont. int PrivateTest(void){ system("/usr/bin/cal"); return 0;}bool IsPasswordValid(void) {
char Password[12];
gets(Password);if (!strcmp(Password, "secure
pro"))return(true);
else return(false);}
Note that the following compiler parameters to performthe buffer overflow attack in Linux system. gcc -o bfnew_m bfnew_m.c -fno-stack-protector
58
Stack Smashing in Linux (3)
Really test the program in ubuntu 12.10 gdb bfnew_m disass main disass IsPasswordValid disass PrivateTest
59
Stack Smashing in Linux (4) PrivateTest and IsPasswordValid
break *0x08048511 run
60
Stack Smashing in Linux (5)
Using Hex Editor bless (Hex Editor) the filename is bn.in
61
Stack Smashing in Linux (6)
In gdb
In shell