Author(s)
Politehnica
University of
Bucharest
Automatic Control
and Computers
Faculty
Computer
Science
Department
Scientif...
Content
• Introduction
• Fuzzing
• Blackbox vs Whitebox
• Architecture of HybridFuzz
• Implementation
• Evaluation
• Concl...
Introduction
3
• Software security bugs can be very expensive:
– Cost of each Microsoft Security Bulletin: $Millions
– Cos...
Fuzzing
• Automated testing of software applications
• Identify security vulnerabilities
• Automated test case generation
...
5
Blackbox vs Whitebox
Whitebox Blackbox Code exploration
25.06.2013 SECITC Presentation Session - July 2013
• Whitebox
 ...
Blackbox vs Whitebox (2)
6
• TRUST (Team for Research in Ubiquitous Secure Technology)
• Catchconv (whitebox) - 279, 953 t...
HybridFuzz - Architecture
7
SISTEM UNDER
TEST
 Path predicates
collector
 KLEE
 Input data generator
 PPL
 Delivery m...
Path predicates collector
8
LLVM-
GCC
C/C++
application
Bytecode
KLEE
KQuery files
• C/C++ application source code
• Compi...
Input data generator
9
Parser
KQuery
constraints
Linear
inequations
PPL
Input space
• Query constraints  Parser  linear ...
Delivery and monitoring module
10
• Zzuf - blackbox mutation based fuzzer
• Mutation ratio 0%
• Segmentation fault, memory...
Evaluation
11
1 int test(unsigned int t_a, int t_b) {
2 unsigned int a = t_a; // unsigned byte
3 int b = t_b; // signed by...
Evaluation (2)
12
Instrs Time(s) ICov(%) BCov(%) ICount
45 0.44 75.00 100.00 60
• Instrs - number of executed instructions...
Evaluation (3)
13
Coreutils code coverage
App Instrs Time(s) ICov(%) BCov(%) ICount
tr 974109 20.97 22.98 15.40 26697
ls 7...
Conclusion
14
• Variable input length
• Input source (network sockets)
• Parallel execution (pipeline execution)
• Distrib...
15
Thank you!
SECITC Presentation Session - July 201325.06.2013
Upcoming SlideShare
Loading in …5
×

Evaluating software vulnerabilities using fuzzing methods

502 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
502
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Evaluating software vulnerabilities using fuzzing methods

  1. 1. Author(s) Politehnica University of Bucharest Automatic Control and Computers Faculty Computer Science Department Scientific Advisor Evaluating software vulnerabilities using fuzzing methods Victor Varză victor.varza@cti.pub.ro As. Dr. Ing. Laura Gheorghe Presentation Session - July 2013
  2. 2. Content • Introduction • Fuzzing • Blackbox vs Whitebox • Architecture of HybridFuzz • Implementation • Evaluation • Conclusion 225.06.2013 SECITC Presentation Session - July 2013
  3. 3. Introduction 3 • Software security bugs can be very expensive: – Cost of each Microsoft Security Bulletin: $Millions – Cost due to worms (Slammer, CodeRed, Blaster, etc.): $Billions • Most security exploits are initiated via files or packets – Ex: Internet Explorer parses dozens of file formats • Security vulnerabilities: – Buffer overflows – Segmentation faults – Memory corruption – NULL - pointer – division-by-zero 25.06.2013 SECITC Presentation Session - July 2013
  4. 4. Fuzzing • Automated testing of software applications • Identify security vulnerabilities • Automated test case generation • Blackbox, whitebox, graybox 4 Blackbox Fuzzing SpeedFast Slow CodeCoverageLowHigh Static Analysis Hybrid Fuzzing Concolic Execution Whitebox Fuzzing 25.06.2013 SECITC Presentation Session - July 2013
  5. 5. 5 Blackbox vs Whitebox Whitebox Blackbox Code exploration 25.06.2013 SECITC Presentation Session - July 2013 • Whitebox  Is capable to discover all possible unique paths  Is not scalable for large programs • Blackbox  Generates a wide number of random test cases  May explore deeper path of code program branch
  6. 6. Blackbox vs Whitebox (2) 6 • TRUST (Team for Research in Ubiquitous Secure Technology) • Catchconv (whitebox) - 279, 953 test cases; 304,936 errors (157 unique) • Zzuf (Blackbox) - 962,402 test cases; 1,066,000 errors (456 unique) • Mplayer, ImageMagick Convert, Adobe Flash Player and Antiword © M.Aslani 25.06.2013 SECITC Presentation Session - July 2013
  7. 7. HybridFuzz - Architecture 7 SISTEM UNDER TEST  Path predicates collector  KLEE  Input data generator  PPL  Delivery mechanism  Monitoring system  Zzuf • KLEE - whitebox fuzzer developed by Stanford University, US • PPL – mathematical library developed by University of Parma, Italy • Zzuf – blackbox fuzzer developed by Caca Labs 25.06.2013 SECITC Presentation Session - July 2013
  8. 8. Path predicates collector 8 LLVM- GCC C/C++ application Bytecode KLEE KQuery files • C/C++ application source code • Compile using LLVM - GCC  bytecode • Symbolic execution using KLEE  query constraints 25.06.2013 SECITC Presentation Session - July 2013
  9. 9. Input data generator 9 Parser KQuery constraints Linear inequations PPL Input space • Query constraints  Parser  linear inequations • Numerical abstraction and convex polyhedra • Mixted integer linear programming problem • PPL + MIP  input space 25.06.2013 SECITC Presentation Session - July 2013
  10. 10. Delivery and monitoring module 10 • Zzuf - blackbox mutation based fuzzer • Mutation ratio 0% • Segmentation fault, memory corruption 25.06.2013 SECITC Presentation Session - July 2013
  11. 11. Evaluation 11 1 int test(unsigned int t_a, int t_b) { 2 unsigned int a = t_a; // unsigned byte 3 int b = t_b; // signed byte 4 5 if (a >= 20) { 6 if (b <= -80) { 7 printf("PATH 1t"); 8 printf("a=%d, b=%dn", a, b); 9 return 1; 10 } 11 12 printf("PATH 2t"); 13 printf("a=%d, b=%dn", a, b); 14 return 2; 15 } 16 17 printf("PATH 3t"); 18 printf("a=%d, b=%dn", a, b); 19 return -1; 20 } 21 query [(Ult 19 (ReadLSB w32 0 a)) (Eq false (Sle (ReadLSB w32 0 b) 4294967216)) ] 19 < a b > -79 Symbolic execution with KLEE Query constraints to linear inequalities Create input space with PPL 25.06.2013 SECITC Presentation Session - July 2013
  12. 12. Evaluation (2) 12 Instrs Time(s) ICov(%) BCov(%) ICount 45 0.44 75.00 100.00 60 • Instrs - number of executed instructions • Time - total time • ICov - percentage of LLVM instructions that were covered • BCov - percentage of branches that were covered • ICount - total static instructions in the LLVM bitcode • x86 architecture: int = 4 bytes • Max number of tests case for PATH 2: 2147483627 x 2147483727 = 4611686142981437829 25.06.2013 SECITC Presentation Session - July 2013
  13. 13. Evaluation (3) 13 Coreutils code coverage App Instrs Time(s) ICov(%) BCov(%) ICount tr 974109 20.97 22.98 15.40 26697 ls 7581376 79.32 21.89 14.93 47197 seq 2080054 260.34 35.47 23.90 24445 mknod 566278 6.29 27.86 18.61 24137 25.06.2013 SECITC Presentation Session - July 2013
  14. 14. Conclusion 14 • Variable input length • Input source (network sockets) • Parallel execution (pipeline execution) • Distributed architecture 25.06.2013 SECITC Presentation Session - July 2013
  15. 15. 15 Thank you! SECITC Presentation Session - July 201325.06.2013

×