program analysis presentation version 1 security perspective(1)

8/2/2019 Program Analysis Presentation Version 1 Security Perspective(1)

1/16

Professor Kyung-Goo Doh

Professor: Dept. of ComputerScience and Engineering,

Hanyang University ERICA

Campus

Head: PLASSE Research

Laboratory, Hanyang

University ERICA Campus

Project

AdvisorStudent

Research proposal for Program Analysis of

Security Properties

Student: Muhammad Suleman

Student ID: 2011557403Department of Computer

Science and Engineering, MS.

Student

PLASSE research lab.

Hanyang University, ERICA

Campus Korea
http://cse.hanyang.ac.kr/http://cse.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://pllab.hanyang.ac.kr/http://pllab.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://pllab.hanyang.ac.kr/http://pllab.hanyang.ac.kr/http://pllab.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://www.hanyang.ac.kr/http://cse.hanyang.ac.kr/http://cse.hanyang.ac.kr/


2/16

In this step I will explain

that every tool made forvulnerability assessment is

either based on some

program analysis problem

or model checking of finite

automata.

Most important class of

tools for securityvulnerability detection is

string analyzer

In this step I will try to

figure our where we canfind security vulnerabilities

and existing tools used for

static analysis to find

vulnerabilities

Here I will give a number

of resources where we can

find updated databases ofsecurity vulnerabilities and

tools

From next slide I will start

exploring the big picture

Laying the

ground1 Easy Step2 Hard Step3

Research proposal for Program Analysis of

Security Properties

This is most hard and

without any doubt fruitfulpart of my proposed

research.

In this step I will try to

explain that all

vulnerabilities can be

analyzed by single

framework based on solidtheoretical ground.

This work is in progress


3/16

1. NIST: National Institute of

standard and technology

2. Static Source CodeAnalysis Tools for C

3. Static Analysis Tools

4. Flawfinder

5. Wikipedia

6. CERT: CarnegieMellon

Software Engineering

Institute

1. CVE: Common

Vulnerabilities and

Exposures2. NVD:National

Vulnerability Database

3. BugTraq:Security Focus

Vulnerability

Repositories1Tools for

Static Analysis2Theoretical

directions3

Vulnerability Databases and Tools

In progress

Actual work is in

theoretical direction. This presentation is just

to laid a framework for

specifying exact problem,

current implementation

of solutions, and practical

guidelines to handle these

problems given byexperts in industry.
http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.htmlhttp://samate.nist.gov/index.php/Source_Code_Security_Analyzers.htmlhttp://samate.nist.gov/index.php/Source_Code_Security_Analyzers.htmlhttp://www.spinroot.com/static/http://www.spinroot.com/static/http://testingfaqs.org/t-static.htmlhttp://www.dwheeler.com/flawfinder/http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysishttps://www.cert.org/secure-coding/tools.htmlhttps://www.cert.org/secure-coding/tools.htmlhttps://www.cert.org/secure-coding/tools.htmlhttp://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://nvd.nist.gov/home.cfmhttp://nvd.nist.gov/home.cfmhttp://nvd.nist.gov/home.cfmhttp://nvd.nist.gov/home.cfmhttp://www.securityfocus.com/archive/1http://www.securityfocus.com/archive/1http://nvd.nist.gov/home.cfmhttp://nvd.nist.gov/home.cfmhttp://nvd.nist.gov/home.cfmhttp://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/https://www.cert.org/secure-coding/tools.htmlhttps://www.cert.org/secure-coding/tools.htmlhttps://www.cert.org/secure-coding/tools.htmlhttps://www.cert.org/secure-coding/tools.htmlhttp://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysishttp://www.dwheeler.com/flawfinder/http://testingfaqs.org/t-static.htmlhttp://www.spinroot.com/static/http://www.spinroot.com/static/http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.htmlhttp://samate.nist.gov/index.php/Source_Code_Security_Analyzers.htmlhttp://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html


4/16

Client-side Vulnerabilities in:

C1. Web Browsers

C2. Office Software

C3. E-mail Clients

C4. Media PlayersServer-side Vulnerabilities in:

S1. Web Applications

S2. Windows Services

S3. Unix and Mac OS Services

S4. Backup Software

S5. Anti-virus Software

S6. Management Servers

S7. Database Software

Security Policy and Personnel:

H1. Excessive User Rights and Unauthorized

DevicesH2. Phishing/Spear Phishing

H3. Unencrypted Laptops and Removable Media

Application Abuse:

A1. Instant Messaging

A2. Peer-to-Peer Programs

Network Devices:

N1. VoIP Servers and Phones

Zero Day Attacks:

Z1. Zero Day Attacks

A1: Injection

A2: Cross-Site Scripting (XSS)

A3: Broken Authentication and

Session Management

A4: Insecure Direct Object

References

A5: Cross-Site Request Forgery

(CSRF)

A6: Security Misconfiguration

A7: Insecure Cryptographic

Storage

A8: Failure to Restrict URL Access

A9: Insufficient Transport Layer

Protection

A10: Unvalidated Redirects and

Forwards

OWASP Top

101

SANS Top 202

OTHER Resources3

Classification of Vulnerabilities

Secure programming with

static analysis

Web application Hackershandbook

Secure programming for linux

and unix howto

NIST Special Publications

500-283
http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/https://www.owasp.org/index.php/Top_10_2010-A1https://www.owasp.org/index.php/Top_10_2010-A2https://www.owasp.org/index.php/Top_10_2010-A3https://www.owasp.org/index.php/Top_10_2010-A3https://www.owasp.org/index.php/Top_10_2010-A4https://www.owasp.org/index.php/Top_10_2010-A4https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A6https://www.owasp.org/index.php/Top_10_2010-A7https://www.owasp.org/index.php/Top_10_2010-A7https://www.owasp.org/index.php/Top_10_2010-A8https://www.owasp.org/index.php/Top_10_2010-A9https://www.owasp.org/index.php/Top_10_2010-A9https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projecthttps://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projecthttp://www.sans.org/top20/2007/http://books.google.co.kr/books?id=GL8AeTCu1WAC&dq=secure+programming+with+static+analysis&hl=en&sa=X&ei=eMoBT6f3J6zBiQf0qeSmAQ&redir_esc=yhttp://books.google.co.kr/books?id=GL8AeTCu1WAC&dq=secure+programming+with+static+analysis&hl=en&sa=X&ei=eMoBT6f3J6zBiQf0qeSmAQ&redir_esc=yhttp://books.google.co.kr/books?id=YJKbVzeabJYC&printsec=frontcover&dq=web+application+hacker+handbook&hl=ko&sa=X&ei=nsoBT9HmBsmWiQeL59TFCQ&ved=0CDkQ6AEwAAhttp://books.google.co.kr/books?id=YJKbVzeabJYC&printsec=frontcover&dq=web+application+hacker+handbook&hl=ko&sa=X&ei=nsoBT9HmBsmWiQeL59TFCQ&ved=0CDkQ6AEwAAhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://samate.nist.gov/docs/NIST_Special_Publication_500-283.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdfhttp://books.google.co.kr/books?id=YJKbVzeabJYC&printsec=frontcover&dq=web+application+hacker+handbook&hl=ko&sa=X&ei=nsoBT9HmBsmWiQeL59TFCQ&ved=0CDkQ6AEwAAhttp://books.google.co.kr/books?id=YJKbVzeabJYC&printsec=frontcover&dq=web+application+hacker+handbook&hl=ko&sa=X&ei=nsoBT9HmBsmWiQeL59TFCQ&ved=0CDkQ6AEwAAhttp://books.google.co.kr/books?id=GL8AeTCu1WAC&dq=secure+programming+with+static+analysis&hl=en&sa=X&ei=eMoBT6f3J6zBiQf0qeSmAQ&redir_esc=yhttp://books.google.co.kr/books?id=GL8AeTCu1WAC&dq=secure+programming+with+static+analysis&hl=en&sa=X&ei=eMoBT6f3J6zBiQf0qeSmAQ&redir_esc=yhttp://books.google.co.kr/books?id=GL8AeTCu1WAC&dq=secure+programming+with+static+analysis&hl=en&sa=X&ei=eMoBT6f3J6zBiQf0qeSmAQ&redir_esc=yhttp://www.sans.org/top20/2007/https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projecthttps://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projecthttps://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A10https://www.owasp.org/index.php/Top_10_2010-A9https://www.owasp.org/index.php/Top_10_2010-A9https://www.owasp.org/index.php/Top_10_2010-A8https://www.owasp.org/index.php/Top_10_2010-A7https://www.owasp.org/index.php/Top_10_2010-A7https://www.owasp.org/index.php/Top_10_2010-A6https://www.owasp.org/index.php/Top_10_2010-A6https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A5https://www.owasp.org/index.php/Top_10_2010-A4https://www.owasp.org/index.php/Top_10_2010-A4https://www.owasp.org/index.php/Top_10_2010-A3https://www.owasp.org/index.php/Top_10_2010-A3https://www.owasp.org/index.php/Top_10_2010-A2https://www.owasp.org/index.php/Top_10_2010-A2https://www.owasp.org/index.php/Top_10_2010-A2https://www.owasp.org/index.php/Top_10_2010-A1http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/http://www.sans.org/top20/2007/


5/16

In order to make software error free, first step is to know what steps produce bugs in

software.

In the slide Vulnerability Databases and Tools we can see that there are almost 49053 CVEin CVE dictionaryand corresponding to these CVEs there are related information for how to

handle these vulnerabilities in NVD database

In Classification of Vulnerability slide we can see that there are a number of efforts by

different industry people to classify these vulnerabilities

Given a program in some language to analyze first thing we need is an automated procedure for

finding what kind of vulnerabilities can be found in that program. A number of papers and some

implementations are working in that direction, list of these papers can be found in slide Papersfor Identification of Vulnerabilities in a given program. Of course this approach will take

advantage of already maintained knowledge base / databases e.g. CVE, NVD, Bugtraq etc

After finding common vulnerabilities for a given program next step is to propose/implement

analyzer in order to make given program error free. Doing this effort from scratch is like

reinventing wheel, instead we need to tackle this problem using existing approaches/tools.

Luckily some databases e.g NVD also recommend existing tools for a given vulnerabilities. For apartial list of existing tools please refer to Vulnerability Databases and Tools slide.

Gather Current Vulnerabilities and Tools for Analyzing these Vulnerabilities1

Direction of Research


6/16

Every successful research needs some implementation. In order to implement some system we

need input and output. Processing of input to output is based on different strategies.

In order to prove that my propose research is in correct direction I will implement a systemwhere input are

A program in some language (imperative, functional, object oriented)

One or more database of current vulnerabilities (CVE, BugTraq). In most program analysis

softwares instead of database, some properties are input e.g. safety etc. Here I just take

vulnerability database and from that database found all the vulnerabilities applies to that

program, then I infer the security properties from these vulnerabilities and analyze the program

for these vulnerabilities. To support my idea Im giving links of following papers

Security Evaluation of Service-oriented Systems with an Extensible Knowledge

BaseChristian Jung, Manuel Rudolph, Reinhard Schwarz 2011

Ontology Model-Based Static Analysis of Security VulnerabilitiesLian Yu, Shi-Zhong Wu,

Tao Guo2, Guo-Wei Dong, Cheng-Cheng Wan, and Yin-Hang Jing 2011

Working on this step is still in progress.

Gather Current Vulnerabilities and Tools for Analyzing these Vulnerabilities: Conclusion1



7/16

This is the another important task of this whole research. Im writing this paper on the

assumption that implementation without sound theory is of very less usage and handle a very small

subset of overall problems, similarly just theoretical research with no practical implementation can bevery sound but it left considering many practical problems, only combination of theoretical work and

implementation of that work can be of use for further research.

There are a number of existing/proposed tools which handles a particular problem on sound

theoretical basis. In the next points I will give some examples of these tools

WebSSARI 2004: Theory behind this tool can be find in paper Securing Web ApplicationCode by Static Analysis and Runtime Protection. Their proposed system acts as an

extension to a languages existing type system.WebSSARI is implementation oflattice-based

static analysis algorithm derived from type systems based on Denning's axioms and Stroms

typestate , authors of paper proves soundness of their algorithm also. Analyze 230 open source

applications out of which 69 have vulnerabilities. Type of vulnerabilities it catches are XSS ,SQL

Injection and General Script Injection. This tool is Information flow based instead of

Finding Theory Behind a Successful Tool

Overcome deficiencies in existing tools based on theoretical knowledge2



8/16

control flow. Fully functional type systems designed to ensure secure information flow have been

offered for high-level, strong typed languages such as ML andJava.WebSSARI is implemented

for PHP

PIXY 2006: This is another tool defined in paper Pixy: A Static Analysis Tool for

Detecting Web Application Vulnerabilities. Goal of this tool is to determine whether it is

possible that tainted data reaches sensitive sinks without being properly sanitized. Type of

analysis used is Data Flow. Type of vulnerabilities it catches are taint-style vulnerabilities

e.g. XSS and SQL Injection. PIXY is implemented for PHP

MOPS 2002: Defined in MOPS: an Infrastructure for Examining Security Properties of

Software. Mops models the program to be verified as a pushdown automaton, represents

the security property as a finite state automaton , and uses model checking techniques to

identify whether any state violating the desired security goal is reachable in the program. Sound

in verifying the absence of certain classes of vulnerabilities, fully interprocedural. Detect

violations of ordering constraints, also known as temporal safety properties. MOPS trades


Overcome deficiencies in existing tools based on theoretical knowledge (cont)2



9/16

precision for scalability and efficiency by considering only control flow and ignoring most

data flow, as theyconjecture that many security properties can be verified without data flow

analysis. MOPS identify rules of safe programming practice, encode them as securityproperties, and describe them by Finite State Automata (FSA). To check these properties

in a program, MOPSmodels the program as a pushdown automaton (PDA) and uses

model checking techniques to determine the reachability of risky states in the PDA.

Examples oftemporal safety properties are Checking Privilege Flow in Non-local

Control Flow, Checking Proper Dropping of Privilege, Verifying Success of System

Calls. MOPS is implemented for C language

Sound and Precise Analysis of Web Applications for Injection Vulnerabilities 2007 :

Tool implemented in this paper is actually string analyzerfor detecting SQL injection

attacks. What is different from previous taint analyses ? Model the precise semantics of

input sanitization routines; (2) No manually written specifications for each query or

for bug patterns; or (3) fully automated no requirement for user intervention at various points

in the analysis. Algorithm described in this paper is Sound i.e. If analysis algorithm does not report





10/16

any SQLCIVs for a given web application P ,then P has no SQLCIVs. Model String values as CFG.

Model String operations as language transducers. Syntax based definition of SQL

injection attacks. Implemented for PHP, using and modifying Minamides string analyzer.Added information flow tracking and checks on the generated grammars,

specifications for 243 PHP functions, support for dynamic includes. The string

analyzerdoes not support all features for PHP.





11/16

In this step I tried to show some examples of existing analyzers that are used for static analysis

for security properties. As indicated in previous slides all these tools are related to one of

OWASP Top 10, Sans Top 20 etc. It has been proved very well that for security properties string analyzers are of prime

importance.

Above step is mostly incomplete because I did not get time to include details of all recent

analyzers which will show the actual type of static analyses currently used, types of security

properties they are analyzing and type of attacks they catch.

Output of above step is to classify all the up to date tools/proposed papers according to

following parameters Type of analysis (data flow, information flow, model checking)

Type of security properties (whether some unsecure state is reachable)

Type of vulnerability (XSS, SQL injection)

Type of language (php, C/C++, java)



Overcome deficiencies in existing tools based on theoretical knowledge (Conclusion)2



12/16

This step is last and perhaps most hard and most fruitful of overall research. In this step I will try

to propose a unified and extensible framework for program analysis for security properties

which can cover all the current vulnerabilities plus any vulnerability expected to be found infuture. Again like previous step I will give examples from many papers which together lay a

ground for further research

Model Checking Is Static Analysis of Modal LogicFlemming Nielson and Hanne Riis

Nielson 2010: This is an excellent paper and it shows proof that problems of model

checking and static analysis are reducible to each other. This is very great result because

it means that all the existing static analysis techniques can be used in model checking and viceversa. It also conclude that for every static analysis there can be corresponding model in model

checking theory and modal analysis. Because modal semantics is described in terms of Kripke

semantics (Kripke strcuture is basically a graph whose nodes represent the reachable states of

the system and whose edges represent state transitions. A labeling function maps each node to

a set of properties that hold in the corresponding state) so we automatically found a non

deterministic automaton for every static analysis. All the existing theories from automata theory

Use existing theories from research to unify a framework for all type of program analysis

especially static vulnerability analysis3



13/16

can be applied to this non deterministic automaton. Existing automata theories can be used to

exploit and find many important properties of static analysis which takes very long time if we

take some other path. Another important thing is that we can now apply whole of ramseytheory to the problem of static analysis (I have seen some papers applying ramsey theory to

problems of static analysis but do not get time to read these papers yet). Finally existing

research in CTL (also based on Kripke semantics) and LTL also applied to static analysis

problem directly, by directly I mean instead of viewing some problem as Using model checking

for proving soundness of shape analysis problem we will view it as finding sound model

equivalent to shape analysis problem.

Program Analysis as Model Checking of Abstract Interpretations David Schmidt

Bernhard Steen 1998: This is 13 year old paper and it is pioneering work in relating model

checking with program analysis and abstract interpretation. First, from a (small-step) operational

semantics definition and a program, one constructs a program model, which is a state-transition

system that encodes the program's executions. Second, abstraction upon the program model is

performed, reducing the detail of information in the model's nodes and arcs. Finally, the program

model is analyzed for properties of its states and paths. Great result in this papers are problems


especially static vulnerability analysis (cont .)3



14/16

formally solved with data-flow analysis techniques are more simply expressed and solved by

model-checking techniques and several more examples.

Temporal Property Verification as a Program Analysis TaskByron Cook1, EricKoskinen,

and Moshe Vardi CAV 2011:This paper is direct result of Schmidt and Steen paper and it shows

huge practical usage of considering program analysis as model checking of abstract

interpretation. Im just copying abstract of paper. We describe a reduction from temporal property

verification to a program analysis problem. We produce an encoding which, with the use of recursion and

nondeterminism, enables off-the-shelf program analysis tools to naturally perform the reasoning

necessary for proving temporal properties (e. g. backtracking, eventuality checking, tree coun-terexamplesfor branching-time properties, abstraction refinement, etc.). Using examples drawn from the PostgreSQL

database server, Apache web server, and Windows OS kernel, we demonstrate the practical via-bility of

our work. We can see the practical usage of reduction from model checking problem to program

analysis problem. Extended version of same problem is Branching-time reasoning for

programsByron Cook1, EricKoskinen, and Moshe Vardi.





15/16

Software Model Checking RANJIT JHALA and RUPAK MAJUMDAR 2009 :Very good

survey of recent progress in software model checking relating all the program analysis problems

to model checking problems.





16/16

This is actual part of research to gather data from Step 1 and 2 and Use existing theories from

research to unify a framework for all type of program analysis especially static vulnerability analysis

As a first step I just prove the link between model checking, abstract interpretation,modal logic and static analysis.

My next step will be to classify application of different concepts ofgraph theory e.g ramsey

theory to specific problems of program analysis. Once all these concepts are mapped properly, I

will try to prove that every program analysis/ model checking problem can be mapped to

some specific problem in graphtheory for which either solution is already developed or it is

an open problem for which work is in progress. Examples of solution of problems in graph

theory is graph coloring problem. Using these results I will finally work on unified and optimized program analysis framework

where all analysis are specific instances of graph theory problems



especially static vulnerability analysis (conclusion)3


program analysis presentation version 1 security perspective(1)

Documents