Security

in Software Applications

Tue 8:00-10:00
Thu 8:00-11:00

Fall 2020
 Information

n Prof.Dr. Francesco Parisi-Presicce

http://www.dsi.uniroma1.it/~parisi/welcome.html
n tel: 06 4991-8512 room 342
(not for long)
n Office hours mostly ‘by appointment‘
(usually Tue and Thu afternoon)
n E-mail parisi@di.uniroma1.it
(indicate Software Security in Subject slot)

Class web page (updated frequently !!)

Material (slides, projects, results) on elearning platform
 OUTLINE
n IMPROVING EXISTING CODE
n Known vulnerabilities: Buffer overflow, SQL/code injection, TOCTOU
n Static and Dynamic Code Analysis and Tools
n Common Vulnerability Scoring System CVSS
n EVALUATING SECURITY
n Principles
n OWASP
n Testing
n DEVELOPING SECURE SOFTWARE
n Secure code development / defensive coding
n Java Security
n Cryptography
n CURRENT APPROACHES
n Language-based Security
n Information Flow Control
n Proof-carrying code
n Code Obfuscation
 References

n R.Anderson, Security Engineering: a guide to building

dependable distributed systems , 2nd ed., John Wiley and
Sons 2008
n J.Viega, G.McGraw, Building Secure Software, Addison-
Wesley 2002
n G.McGraw, Software Security: Building Security in, Addison-
Wesley 2006
n G.Hoglung, G.McGraw, Exploiting Software: how to break
code , Addison-Wesley 2004
n G.McGraw, E.Felten Securing Java, John Wiley and Sons
1999,
n D.A.Wheeler, Secure Programming for Linux and Unix
HOWTO
 Course Evaluation

n 3 individual projects
n Static analysis of C fragment
n Analysis of Java code with assertions
n Testing of given application

n Individual written exam

Prerequisites
Introductory security course ?
Elementary OS and DB
Basic programming skills, in particular
C(++)
eg. malloc(), free(), *(p++),
strings in C using char*

Java
eg. public, final, private, protected

Bits of PHP and javascript

6
 Sample C code

char* copying_a_string(char* string) {

char* b = malloc(strlen(string));
strcpy(b,a);
return(b);
}
int using_pointer_arithmetic(int pin[]) {
intsum = 0;
int *pointer = pin;
for (int i=0; i<4; i++ ){
sum = sum + *pointer;
pointer++;
}
return sum;
}
 Sample Java code

public int summingAnArray(int[] pin)

throws NullPointerException,
ArrayIndexOutOfBoundsException{
int sum = 0;
for (int i=0; i<4; i++ ){
sum = sum + a[i];
}
return sum;
}
Sample Java OO code

final class A {
public final static SOME_CONSTANT 2;
private B b1, b2;

protected A ShallowClone(Object o)
throws ClassCastException{
x = new(A);
x.b1 = ((A)o).b1;
x.b2 = ((A)o).b2;
return x;
}
}
 Course Evaluation
§ Three individual projects (20% each)
§ Probably fragments of code to analyze and correct

§ One final written exam (40%)

§ Dealing with the rest …

NEED to pass all of them

Submission of projects by deadline necessary to take
exam in first session

10
 The context: computer system
security . . .
Question 1: what is a computer system ?
– (classical) computer: mainframe, server, desktop
– mobile device: phone, tablets, audio/video player, etc.. . .
up to IoT, smart cards, . . .
– embedded (networked) systems: inside a car, a plane, a
washing machine, etc.
– clouds
– but also industrial networks (ICS, Scada), . . . etc.
– and certainly many more !
TWO main interesting characteristics:
1. includes hardware + software
2. open/connected to the outside world . . .
 The context: computer system
security . . .
Question 2: what does security mean?
• a set of “high-level” security goals:
CIA = Confidentiality, Integrity, Availability (+ Non Repudiation + . . . )
• is it specific to the computer system we consider ?
how to deal with “unsecure executions” ?
• something beyond safety and fault-tolerance:
– notion of intruder, with specific capabilities
– notion of threats, with a “threat model”
there is an “external actor” with an attack objective in mind, and able to
elaborate a dedicated strategy to achieve it (not a hazard)
• a definition “by default”:
– functional properties = what the system should do
– security properties = what the system should not do
how it should not behave. .
Software Security: an example

consider 2 programs:
• Compress, to compress a file f
• Uncompress, to uncompress a (compressed) file C
Expected behavior (the one we try to validate)
Uncompress(Compress(f)) = f (1)
But, what about uncompressing an arbitrary (i.e., maliciously crafted)
file ? (e.g., CVE-2010-0001 for gzip)
(if C is not Compress(f) for any f) then
(Uncompress(C) = "Error_Msg") (2 )

Actually (2) is much more difficult to validate than (1) . . .

 Some Definitions

Bug: an error (or defect/flaw/failure) introduced in a SW

§ at the specification / design / algorithmic level
§ at the programming / coding level
§ or even by the compiler (or other program transformation tools) .

Vulnerability: a bug that opens a security breach

o non exploitable vulnerability: there is no (known !) way for an
attacker to use this bug to corrupt the system
o exploitable vulnerability: this bug can be used to elaborate an
attack (i.e., write an exploit)
Exploit: a concrete program input to take advantage of a
vulnerability (from an attacker point of view)

Malware: a piece of code “injected” inside a computer to corrupt it

(usually exploiting existing vulnerabilities)
Countermeasures
Several existing mechanisms to enforce SW security

o at the programming level:

o disclosed vulnerabilities -> language weaknesses databases
-> secure coding patterns and libraries
o aggressive compiler options + code instrumentation
-> early detection of unsecure code
o at the OS level:
o sandboxing
o address space randomization
o non executable memory zones
o etc.
o at the hardware level:
o Trusted Platform Modules (TPM)
o secure crypto-processor
o CPU tracking
 What is secure?
In the sense of Engineering Secure Software
 Software Security
What is your favorite software development
technology? (language, tool, library, etc.)

Have you ever written software where security

mattered?
Did you do anything about it then?

How do you know that you have delivered secure

software?
Try to think of examples
What are your indicators?
How will you convince others that your software is secure?
 Discussion Takeaways

• Security is not black-and-white

• Security is “until proven insecure”

• Security “Theater”
– Feeling safer vs. Being safer
– People act on their perception of reality, not necessarily on reality

• Protection can be costly

– E.g. personal liberty and privacy

• Eliminating a Threat vs. Protection

• Vulnerability vs. Exploit vs. Threat

 An Engineer’s Concern
In SE courses you learn how to build software
…but not as much breaking software

How do you know that you have built a system that cannot be
broken into?
What evidence do you look for?
How do you know you are done?
How do you prioritize security against everything else drawing upon
your time?
SE is a zero-sum game
“If I need to focus more energy on security, what should we take
away?”
 Vulnerability

Informally, a bug with security consequences

A design flaw or poor coding that may allow an attacker to exploit

software for a malicious purpose
– Non-software equivalent to “lack of shoe-examining at the airport”
– E.g. allowing easily-guessed passwords (poor coding)
– E.g. complete lack of passwords when needed (design flaw)
– McGraw: 50% are coding mistakes, 50% are design flaws

Alternative definition: “an instance of a fault that violates an

[implicit or explicit] security policy”
 Exploit and Threat

Exploit: a piece of software, a chunk of data, or a sequence of

commands that takes advantage of a vulnerability in an effort to
cause unintended or unanticipated behavior
i.e. maliciously using a vulnerability
– Can manual or automated
– Viruses are merely automated exploits
– Many different ways to exploit just one vulnerability

Threat – two usages of the word

(a) An actor or agent that is a source of danger, capable of violating
confidentiality, availability, or integrity of information assets and security
policy
e.g. black-hat hackers
(b) A class of exploits
e.g. spoofing
[Exploit|Threat|Vulnerability] Protection

Protect against exploits?

Anti-virus, intrusion detection, firewalls, etc.

Protect against threats?

Use forensics to find and eliminate
Policy, incentives, deterrents, etc.

Protect against vulnerabilities?

Engineer secure software!
 Software Security is…

NOT a myth but a reality

Insecure software causes immeasurable

harm

Sony, NSA, Android, Browsers… just read

the news
 Software Security is…

NOT an arcane black art

Much of it seems arcane

Finding a severe vulnerability w/o source code
Crafting the exploit
Endless clever ways to break software

But, you have much more knowledge than the attackers do

Do not just leave it to the others, take responsibility for

knowing security
 Software Security is…

NOT a dire apocalyptic future

Fear-mongering not useful

Risk management dictates that we deal in

the probable more than the possible
 Software Security is…

NOT a set of features

Secure software > Security software

Although tools and experts are helpful,

You cannot just deploy a magical tool and expect all
vulnerabilities to disappear
You cannot outsource all of your security knowledge

Even if you are using a security library, know how to

use it properly
 Software Security is…

NOT a problem for just mathematicians

Cryptography
– Is important and needed
– Cannot solve all of your security problems
– Pick-proof lock vs. open window

Proofs, access control rules, and verification are

helpful, but inherently incomplete
 Software Security is…

NOT a problem for just networking and

operating systems

Software had security problems long

before we had the internet

If you left a window open in your house,

would you try to fix the roads?
 Software Security is…

A reality that everyone must face

Not just developers, all stakeholders

A learnable mindset for software engineers

The ability to prevent unintended functionality

At all layers of the stack
In all parts of your system
 Student Security Maturity

Denial
– I do not have to think about this. Let me just code.
– Leave it to the experts.
– I could never understand this anyway.

Irrational fear, superstition

– EVERYTHING IS POSSIBLE NOW!!!
– EVERY MITIGATION IS NECESSARY!!!
– ENCRYPT EVERYTHING!!!

Bag of Tricks
– Let’s just try these tricks that worked in the past
– We have done these 10 things. That is a lot. Close enough, right?

Reasoned, Balanced, Defensive Mindset

– If we do X, we mitigate Y, which is worthwhile because of Z.