(Software) Security
Erik Poll
Digital Security group
Radboud University Nijmegen
A brief history of security problems
• attacks on multi-user UNIX systems for fun
• viruses & worms attacking operating systems
– due to buffer overflow, format string attacks, integer
overflows,...
– response: firewalls & better operating system code
– variant: bot-nets
• attacks on web-applications
– due to SQL injection, XSS, session riding, ....
– response: intrusion detection systems & application
firewalls
• attacks on web-browsers
– man-in-the-browser attacks
• ...
2
Causes
Important causes of these security problems
• bad software
– buggy OS software, web-application software,
...
– solution: patching?
• gullible & stupid users
– too easy to just blame users: if they are gullible
and stupid, they should be protected
– solution: user education?
3
Security is about
people (users, employees, sys-admins, programmers,...),
incompetence, confusion, lethargy, stupidity, mistakes,
access control, passwords, biometrics, cryptology, protocols,
policies & their enforcement, monitoring, auditing,
legislation, persecution, liability, risk management,
complexity, software, bugs, verification, hackers, viruses,
hardware, operating systems, networks, databases,
public relations, public perception, conventions, standards,
physical protection, data protection, ...
4
Root cause analysis
• Security is always a secondary concern
– primary goal of software is to provide some
functionality or services
– managing the associated risks is only a derived
or secondary concern
• There is often a trade-off/conflict between
– security
– functionality & convenience
5
What goes wrong?
• at a high-level
– not understanding the security requirements
and threats
• at a low-level
– silly little program bugs or flaws that introduce
vulnerabilities
6
How can we improve things?
• at a high-level
– seriously looking at security requirements and
threats when (prior to) building systems
• at a low-level
– train programmers to be aware of pitfalls
associated with programming language, OS,
platform
– improve these languages, OSs, platform
• making them less error-prone
7
low-level
Security as secondary concern
• in programming languages
– Algol 60 introduces array bound checks, in 1960
– C doesn't use this, in 1970s ...
– ... 3 decades later, we're still trying to get rid
of buffer overflows
– early 2000s: people start using safestr.h
9
Functionality vs security
Lost battles?
• operating systems
– huge OS, with huge attack surface (API),
• programming languages
– buffer overflows, format strings, ... in C
– lots of things in PHP
• webbrowsers
– plug-ins for various formats, javascript, VBscript, ...
• email clients
– ...
10
Software infrastructure
Applications are built on top of very complex
"infrastructure" consisting of
• operating system
• programming language/platform/APIs/middleware
• other applications & utilities
– eg SQL database
This infrastructure provides security mechanisms,
but is also a source of security pitfalls.
You need to understand both to develop secure
applications on a give infrastructure.
11
Threats & vulnerabilities
• Knowledge about threats & vulnerabilities crucial
– my first dynamic webpage, with a cgi-bin script, was
hopelessly insecure
• Vulnerabilities can be specific to programming
language, operating system, database,... used, and
are continuously evolving, so we cannot hope to
cover all vulnerabilities.
• “Fortunately” people keep making the same
mistakes
– and the same security problems keep
reappearing
12
The bad news:
people keep making the same mistakes
• when writing programs & when designing
programming languages or other infrastructure
• SQL injection
– string concatenation is a convenient way to
build SQL queries...
• will we be chasing SQL injection faults in 30 years,
just as we're still chasing buffer overflow attacks?
• insist on use of eg. PreparedStatement?
• PHP
– PHP is a convenient way to quickly build a
website...
13
The "good" news:
people keep making the same mistakes
• We can make checklists for common mistakes
• We can teach students about common mistakes
• We can implement tools that check them
– source code analysers aka static analysis tools
• Static analysis tools for C(++)
– Coverity, Fortify, jTest, PolySpace, PREfast, PREfix, ...
• C/C++ checkers focus on memory-related issues
and for Java
– CheckStyle, Findbugs, PMD, Fortify, jTest, IntelliJ, ...
14
OWASP Top 10 of web application vulnerabilities
1. Unvalidated Input
2. Broken Access Control
Anyone
building a web3. Broken Authentication and Session
Management
application should know
4. Cross Site Scripting (XSS) Flaws
about these vulnerabilities:
5. Buffer Overflows
•how they work,
6. Injection Flaws
•how they arise, and
7. Improper Error Handling
•how they can be avoided
8. Insecure Storage
9. Denial of Service
10. Insecure Configuration Management
Lots of info on web-application security on OWAPS.org
15
19 Deadly sins of software security [Howard, LeBlanc, Viega]
1. buffer overruns
2. format string problems
3. integer overflows
4. SQL injection
5. command injection
6. failing to handle errors
7. XSS
8. failing to protect network
traffic
9. use of magic URLs or
hidden form fields
10. improper use of TLS, SSL
11. weak passwords
12. failing to store & protect
data securely
13. information leakage
14. improper file access
15. trusting network name
resolution
16. race conditions
17. unauthenticated key
exchange
18. weak random numbers
19. poor usability
16
Classification of Software Security Errors
1. Input Validation and Representation
2. API Abuse
3. Security Features
4. Time and State
5. Errors
6. Code Quality
7. Encapsulation
*. Environment
•
[Katrina Tsipenyuk, Brian Chess, Gary McGraw, Seven Pernicious Kingdoms:
A Taxonomy of Software Security Errors]
17
How to improve software security?
• Awareness & knowledge of vulnerabilities (don'ts)
– general (input validation, ...)
– specific to a kind of application (SQL injection, XSS, ...), or
– specific to a kind of programming language (buffer overflows, ...)
• Awareness & knowledge of countermeasures (do's)
at different points in the development lifecycle
at level of application, programming language, or platform
Eg security technologies such as
– access control, session management
– untrusted code security
• type-safe languages, sandboxing, code-based access control
– runtime monitoring
– program analyses: typing, information flow, static analysis,
verification
But beware that security software ≠ software security
18
high-level
Security concepts [as used in Common Criteria]
owners
impose
availability/
usefulness
want to maximise
want to minimise
countermeasures
reduce
may have
require
attackers
give
rise to
increase
vulnerabilities
exploit
threats
lead to
increase
to
of
risks
assets
want to abuse
20
Starting point for ensuring security
• Any discussion of security should start with an
inventory of
– the stakeholders,
– their assets, and
– the threats to these assets
by possible attackers
– employees, clients, script kiddies, criminals
• Any discussion of security without understanding
these issues is meaningless
21
Threat Modeling
Aka security/risk/requirements analysis
A first step, not just for software
• Identify assets & stakeholders
• Consider architecture of application & its environment
• Brainstorm about known threats
• Define security assumptions
• Rank threats by risk
≈ impact x likelihood
• Decide which threats to respond to
• Decide how to migitate these threats
– which techniques & technologies
22
STRIDE
Simple approach to threat modelling developed at Microsoft, as
part of SDL (Secure Development Lifecycle process)
• Spoofing Identity
• Tampering with Data
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilige
These and other checklists can be useful
See also http://msdn2.microsoft.com/en-us/library/aa302419.aspx
23
Techniques to migitate these threats
• Spoofing Identity
– authentication, protect keys & passwords, ...
• Tampering with Data
– access control, hashes, digital signatures, MACs (message
authentication codes), write-once storage...
• Repudiation
– logging, audit trails, digital signatures, ...
• Information Disclosure
– access control, encryption, not storing secrets, ...
• Denial of Service
– graceful degradation, filtering
• Elevation of Privilige
– access control, esp. least privilige, sandboxing, ...
24
Security in Software Development Life Cycle
[Source: Gary McGraw, Software security, Security & Privacy Magazine,
IEEE, Vol 2, No. 2, pp. 80-83, 2004. ]
25
Security principles
• keep it simple
• secure the weakest
link
• defence in depth
• principle of least
privilige
• minimise attack
surface
• compartementalise
• secure defaults
• identify & question
your assumptions
• fail securely
• promote privacy
• hiding secrets is hard
• use community
resources
– ie find out about
attacks and
countermeasures
• be reluctant to trust
• ...
26
Conclusions
Conclusions
• Security problems growing, because of
– more networks
– more software
– growing importance of services provided by
these
• more money to be made by attacker!
• People will always concentrate on functionality
first, and worry about security later (if at all)
28
Conclusions
To prevent security problems, you must
• understand the security requirements & the
threats that attackers pose
– aka threat modeling
– think like an attacker!
• know the technologies you use
– operating system
– programming language & platform
– ...
and their security problems (do's & don'ts)
– buffer overflows, SQL injection, ...
29
0
