Transcript CSCE 790 – Secure Database Systems

CSCE 548
Secure Software
Development
Information Leakage +
Failing to Handle Errors
Reading

This lecture:

Howard et al., 19 deadly sins: Chapters 6, 13, 12,
11
Howard et al., 24 deadly sins: Chapters 11, 12,
17, 19

CSCE 548 - Farkas
2
Identification

Establishes the
identity of an
individual/system/application/etc.
 Proof of identity:
password, driver’s
license, Id card, etc.
CSCE 522 - Farkas
3
Authentication

Allows an entity (a user or a system) to prove its
identity within a context, e.g., computer system
 Typically, the entity whose identity is verified
reveals knowledge of some secret S to the verifier
 Strong authentication: the entity reveals
knowledge of S to the verifier without revealing S
to the verifier
CSCE 522 - Farkas
4
Vulnerabilities of Passwords

Inherent vulnerabilities
– Easy to guess or snoop
– No control on sharing

Practical vulnerabilities
– Visible if unencrypted in distributed and network
environment
– Susceptible for replay attacks if encrypted naively

Password advantage
– Easy to modify compromised password.
CSCE 522 - Farkas
5
Digital Certificates

Most common digital certificate: X.509
 Initially issued in 1988
 Rely on PKI and hierarchy of certificate
authorities
 Certificate Authority: issue and revoke
digital certificates, accepts user
notifications, publishes revocation list
CSCE 522 - Farkas
6
Problem with X.509

Large file
 Long duration  needs validation of
certificate for revocation
 Why are digital certificates revoked?
– Exposure of private key
– Incorrect/unauthorized issuance
– Termination of assignment
CSCE 522 - Farkas
7
Return to Multiple
Authentication
CA
Verify Certificate
System 2
System 1
I am Ann. Here is my
X.509
System 3
I am Ann. Here is my
X.509
I am Ann. Here is my
X.509
CSCE 522 - Farkas
8
CA
Single Sign On
Verify Certificate
System 2
System 1
I am Ann. Here is my
SAML token
System 3
I am Ann. Here is my
X.509. Give me a locally
verifiable token.
SAML token
I am Ann. Here is my
SAML token
CSCE 522 - Farkas
9
Information Protection

During transit
 During use
 During storage
CSCE 548 - Farkas
10
Access Control

Access control: ensures that all direct accesses to
object are authorized
 Protects against accidental and malicious threats
by regulating the reading, writing and execution
of data and programs
 Need:
– Proper user identification and authentication
– Information specifying the access rights is protected
form modification
CSCE 548 - Farkas
11
Implementation
File 1
Access Control List (column) Joe:Read
(ACL)
Joe:Write
Joe:Own
Capability List (row)
File 2
Joe:Read
Sam:Read
Sam:Write
Sam:Own
Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read
Sam: File 2/Read, File 2/Write, File 2/Own
Subject
Access Control Triples Joe
Joe
Joe
Joe
Sam
Sam
Sam
CSCE 548 - Farkas
Access
Read
Write
Own
Read
Read
Write
Own
Object
File 1
File 1
File 1
File 2
File 2
File 2
File 2
12
Problem Areas

Too much access
– Not following least privilege

Security violations
– Deny access – unavailability
– World readable – information disclosure
– Write for everyone – incorrect execution, denial
of service, taking over the system
CSCE 548 - Farkas
13
Recommendation
Use the operating system’s security
technologies
 Keep secrets out of harm’s way
 Use security technology (access control
support, encryption, etc.) properly
 Scrub the memory securely once finished
with secret data

CSCE 548 - Farkas
14
Weak Access Control

Set access control and grants write access to low
privileged user
 Creates an object without setting access control
and creates object in a place writable by lowprivileged user
 Writes configuration information into a shared
area
 Writes sensitive information into a shared area
CSCE 548 - Farkas
15
Information Leakage

By accident
 By intention
CSCE 548 - Farkas
16
Communication Channels

Overt Channel: designed into a system and
documented in the user's manual
–

Information leakage: designers and developers DO
NOT understand security needs of the application
Covert Channel: not documented. Covert
channels may be deliberately inserted into a
system, but most such channels are accidents of
the system design.
–
Information leakage: slow information flow to
unauthorized recipient
CSCE 548 - Farkas
17
Information Flow

Direct Flow:
– Bell-LaPadula example
TS-subject
read
infoflow
S-object

TS-object
write
infoflow
S-subject
Indirect flow:
– Covert channel
– Inference channel
CSCE 548 - Farkas
18
Non-Interference

High-security data does not influence lower
security data
 How to guarantee it?
CSCE 548 - Farkas
19
Covert Channel

Timing Channel: based on system times
 Storage channel: not time related
communication
 Can be turned into each other
CSCE 548 - Farkas
20
Covert Channel

Need:
–
–

Two active participants and encoding schema OR
Access to the system and knowledge about the system
Example: sender modulates the CPU utilization
level with the data stream to be transmitted
Sender:
repeat get a bit to send
if the bit is 1 wait one second (don't use CPU time)
else busy wait one second (use CPU time)
endif
until done
CSCE 548 - Farkas
21
Covert Channels

Problems:
– Noise
– Need sophisticated synchronization

Protection (user state, system state)
– Removal
– Slow down
– Audit
CSCE 548 - Farkas
22
Cryptographic Timing Attack

How long does it take to perform encryption
– Table look ups
– Non-constant time
– Partial guesses  faster performance

Measure the duration between messages,
where message content depends on secret
data
CSCE 548 - Farkas
23
Inference Channels

Statistical Database Inferences
 General Purpose Database Inferences
CSCE 548 - Farkas
24
Statistical Databases

Goal: provide aggregate information about groups
of individuals
– E.g., average grade point of students

Security risk: specific information about a
particular individual
– E.g., grade point of student John Smith

Meta-data:
– Working knowledge about the attributes
– Supplementary knowledge (not stored in database)
CSCE 548 - Farkas
25
Types of Statistics


Macro-statistics: collections of related statistics presented
in 2-dimensional tables
Sex\Year
1997
1998
Sum
Female
4
1
5
Male
6
13
19
Sum
10
14
24
Micro-statistics: Individual data records used for statistics
after identifying information is removed
Sex
Course
GPA
Year
F
CSCE 590
3.5
2000
M
CSCE 590
3.0
2000
F
CSCE 790
4.0
2001
CSCE 548 - Farkas
26
Statistical Compromise

Exact compromise: find exact value of an
attribute of an individual (e.g., John Smith’s
GPA is 3.8)
 Partial compromise: find an estimate of an
attribute value corresponding to an
individual (e.g., John Smith’s GPA is
between 3.5 and 4.0)
CSCE 548 - Farkas
27
Inferences in General-Purpose
Databases

Queries based on sensitive data
 Inference via database constraints
 Inferences via updates
CSCE 548 - Farkas
28
Queries based on sensitive data

Sensitive information is used in selection
condition but not returned to the user.
 Example: Salary: secret, Name: public
NameSalary=$25,000

Protection: apply query of database views at
different security levels
CSCE 548 - Farkas
29
Database Constraints

Integrity constraints
 Database dependencies
 Key integrity
CSCE 548 - Farkas
30
Integrity Constraints

C=A+B
 A=public, C=public, and B=secret
 B can be calculated from A and C, i.e.,
secret information can be calculated from
public data
CSCE 548 - Farkas
31
Database Dependencies
Metadata:
 Functional dependencies
 Multi-valued dependencies
 Join dependencies
 etc.
CSCE 548 - Farkas
32
Functional Dependency
FD: A  B, that is for any two tuples in the
relation, if they have the same value for A, they
must have the same value for B.
 Example: FD: Rank  Salary
Secret information: Name and Salary together

– Query1: Name and Rank
– Query2: Rank and Salary
– Combine answers for query1 and 2 to reveal Name and
Salary together
CSCE 548 - Farkas
33
Key integrity

Every tuple in the relation have a unique
key
 Users at different levels, see different
versions of the database
 Users might attempt to update data that is
not visible for them
CSCE 548 - Farkas
34
Example
Secret View
Name (key)
Black P
Red S
Salary
38,000 P
42,000 S
Address
Columbia S
Irmo S
Name (key)
Salary
Address
Black P
38,000 P
Null P
Public View
CSCE 548 - Farkas
35
Updates
Public User:
Name (key)
Black P
Salary
38,000 P
Address
Null P
1. Update Black’s address to Orlando
2. Add new tuple: (Red, 22,000, Manassas)
If
Refuse update: covert channel
Allow update:
• Overwrite high data – may be incorrect
• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas
36
Updates
Secret user:
Name (key)
Salary
Address
Black P
38,000 P
Columbia S
Red S
42,000 S
Irmo S
1. Update Black’s salary to 45,000
If
Refuse update: denial of service
Allow update:
• Overwrite low data – covert channel
• Create new tuple
– which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas
37
Inference Problem

No general technique is available to solve
the problem
 Need assurance of protection
 Hard to incorporate outside knowledge
CSCE 548 - Farkas
38
Failing to Handle Errors
CSCE 548 - Farkas
39
Failing to Handle Errors

Affected languages:
– Any language that uses function error return values,
e.g., PHP, C, C++, etc.
– Any language that relies on exceptions, e.g., C#, Java,
etc.

Consequences:
–
–
–
–
–
–
Yielding too much information
Ignoring errors
Misinterpreting errors
Using useless error values
Handling the wrong exceptions
Handling all exceptions
CSCE 548 - Farkas
40
Yielding Too Much Information

Error message carries information that can
be misused by the attacker
 Avoid: do not tell the user why his input
failed
 Problem: reduces usability
CSCE 548 - Farkas
41
Ignoring Errors


Error return values: indicate a failure condition, enabling
the code to react accordingly
How serious the error is?
– Return value rarely checked, e.g., printf
– Return value must be checked, e.g., Windows impersonation
functions  if failed, the thread still has the processes identity

Exception handling
– Catch exceptions at compile time
– Some exceptions are not required to be caught, e.g.,
NullPointerException  miss logic error

Handling exceptions and errors
CSCE 548 - Farkas
42
Misinterpreting Errors and
Useless Error Values

Functions with special errors
– E.g., recv():




Successful completion: # of bytes received
No msg. and orderly shut down: 0
Error: -1
No error value
– E.g., strncpy:


Returns a pointer to the destination buffer, regardless of the
state of the copy
Buffer overrun?
CSCE 548 - Farkas
43
Handling the Wrong Exceptions,
Handling All Exceptions

Which exception is going to be thrown?
– Standard, expected exceptions
– Unexpected exceptions  program terminates
because the exception is not caught

All exceptions handled: code may not be
able to handle the exception or mask the
error
– Error may resurface at a later stage  hard to
detect
CSCE 548 - Farkas
44
Detecting Error Handling Flaws

Code review
– Look for key words
– See page 79

Some tools are available
 Redemption steps:
– Handle the appropriate exceptions in your code
– Don’t handle ALL exceptions
– Check return values, in particular


Security related functions
Functions that changes user setting or machine-wide setting
CSCE 548 - Farkas
45
Design Patterns

Capture security effective techniques that should
be replicated
 Distill and document these techniques – design
patters
 CMU.SEI 2009 security design patterns
– Architectural
– Design-level
– Implementation0level
CSCE 548 - Farkas
46
Each Pattern

Intent
 Also known as
 Example
 Motivation
 Applicability structure
 Participants consequence
 Implementation
 Sample code
 Example resolved
 Known uses
CSCE 548 - Farkas
47
Example



SOA Message screening pattern, from
http://www.soapatterns.org/message_screening.php
Problem:
An attacker can transmit messages with malicious or
malformed content to a service, resulting in undesirable
behavior.
Solution
The service is equipped or supplemented with special
screening routines that assume that all input data is harmful
until proven otherwise.
CSCE 548 - Farkas
48
Example cont.


Application:
When a service receives a message, it makes a number of
checks to screen message content for harmful data.
Impacts:
Extra runtime processing is required with each message
exchange, and the screening logic requires additional,
specialized routines to process binary message content,
such as attachments. It may also not be possible to check
for all possible forms of harmful content.
CSCE 548 - Farkas
49
Example cont.
CSCE 548 - Farkas
50
Next Class

Buffer overflow and SQL Injection
CSCE 548 - Farkas
51