Course 1 Learning Plan






Security overview and patching
Public vulnerability databases and resources
Secure software engineering
Security assessment and testing
Resource management
Trust management
Learning objectives




Be able to identify resources at risk
Understand how resources become at risk from
denial-of-service attacks
Be able to decide which resources need to be
exposed
Understand how to mitigate resource exhaustion
risks
Resource Management: Outline



Motivation
Resource identification
Resource exhaustion





CPU exhaustion
Network applications and protocols vulnerabilities
Generous Protocols and Algorithms
Other asymmetric attacks
Memory Management
How Important is Availability?


How important is it to have resources available at
some specific times or all the time?
Market for 99.99% availability systems or even
"5 nines" (99.999%)



Worth a lot of money for some businesses
Redundant hardware, fault-resistant software
Problem: Infrastructure, hardware, software
usually designed for functionality and
performance in normal situations, not robustness
vs. worst-case scenarios

Malicious people can engineer worst-case scenarios to
come true
Availability Through Software





Monitoring software that relaunches an
application whenever it crashes or quits
Redundant software installations on different
partitions
Disk images (e.g., Ghost)
Virtual machines that reload running images
(VMWare)
The above are just mitigating setups that don't
fix the original problem and can still cause
interruptions

Perfect software is not possible, but better software is
Denial of Service


The unavailability of a needed resource, most
often due to a malicious entity.
Sometimes not the primary goal



Side effect of another attack
Failure to achieve worse results
Perhaps used to evade traceability, law
enforcement or accountability


disable logging mechanisms
disable detection and alert systems
 submerge human with messages, human may disable
the attacked defense mechanism!
Resource Identification

Shared resources are exposed to resource
exhaustion attacks










Memory
Hard Drive space
Bandwidth
CPU
Entropy (for random number generation)
Database engines
Servers
Analysts
Wireless Mice, Keyboards
Wireless NICs
Question




Which one of these resources is susceptible to a
resource exhaustion attack?
a) Electric power
b) Chair
c) Trackpad
Resource Exhaustion

May happen whenever there are:



A finite number of resources
A finite rate (e.g., processing)
Hard to defend against some variants


Sometimes a balancing act
Analogy: By staying home, the risk of meeting
unpleasant people is removed, but the cure may be
worse than the risk.
How Resource Exhaustion Happens




Spend time processing requests from illegitimate
(but possibly legitimate) users
Allow legitimate users to hog resources
Improperly free resources no longer needed
Sometimes design errors, sometimes
implementation
Resource Exhaustion Enablers




Expensive Tasks
 Algorithms
 Encryption, Compression and Encoding
 e.g., DVDs are expensive to compress
Generous Protocols and Algorithms
 Anonymous or unauthenticated allocation of computer
resources
 Amplifiers (broadcasts, subscriptions, distributed
systems)
Coding errors turned into vulnerabilities
 Memory Leaks and other memory management errors
Design errors
 Absence of policies, restrictions, access control,
partitions or compartments, backups, failover or
redundant systems
Example: Disk




Risk: Disk or partition is unavailable because it is
completely filled
Threat: one user can rob all others of disk space
(including the use of a partition)
Resource managed by the operating system
Enabling factors

Missing or no quotas specified by OS for users and
processes
 /tmp directory
 fill up the disk (or partition) with temp files

/var directory
 use up the disk (or partition) with logs
Question

Identify the correct resource exhaustion
enablers:
a) Memory failures
b) Generous protocols and algorithms
c) Expensive hardware
Question

Identify the correct resource exhaustion
enablers:
a) Memory failures
b) Generous protocols and algorithms
c) Expensive hardware
CPU Exhaustion Attacks


Uninterruptible tasks
Unwise operational order


Perform a series of complex operations first, before
checking the request's validity
Asymmetric attacks


Cost for attacker is much smaller than for defender
Algorithmic complexity attacks
Uninterruptible Tasks

CAN-1999-1285
Linux 2.1.132 and earlier allows local users to cause a
denial of service (resource exhaustion) by reading a
large buffer from a random device (e.g. /dev/urandom),
which cannot be interrupted until the read has
completed.

CPU not available until random numbers have all been
calculated
Unwise Operational Order

A firewall’s job is to block traffic
Don’t perform expensive operations on traffic you’re
blocking anyway!

CAN-2002-1203
IBM SecureWay Firewall before 4.2.2 performs extra
processing before determining that a packet is invalid
and dropping it, which allows remote attackers to cause
a denial of service (resource exhaustion) via a flood of
malformed TCP packets without any flags set.
Asymmetric CPU Attacks

Cryptographic algorithms are typically expensive


Don’t know if message is good until decrypted


Initiate communications so server generates keys, etc...
Send random messages
IPSEC design vulnerability
Algorithmic Complexity Attacks

Exploit worst-case scenario of algorithms

Hash algorithms (Crosby and Wallach 2003)
 Data structure pollution
 Bro IDS (Intrusion Detection System) dropping 70%
packets
2
 Normally O(N), becomes O(N ) with malicious input
 if N is 1000, cost is 1000 times higher than expected!



Quicksort: O(N2) instead of O(NlogN)
Python regular expression engine
 Exponential blowout with malicious input
Fix: use algorithms that are not vulnerable
 "universal hash algorithms" designed to avoid the
vulnerability
 Please see http://www.cs.rice.edu/~scrosby/hash/
Question

Algorithmic complexity attacks work because:
a) they attack complex algorithms
b) they exploit the worst-case behavior of
algorithms
c) there were errors in the implementation of the
algorithms
Question

Algorithmic complexity attacks work because:
a) they attack complex algorithms
b) they exploit the worst-case behavior of
algorithms
c) there were errors in the implementation of the
algorithms
Discussion

How would you prevent or defend against:



Uninterruptible tasks
Unwise operational order
Asymmetric attacks
Discussion Sample Answers

How would you prevent or defend against:

Uninterruptible tasks
 Limit CPU slices per user
 move part of algorithm out of kernel space


Unwise operational order
 Do not invest in something that may be worthless
until you know for sure you have to (may not be
initially obvious)
Asymmetric attacks
 Limit the rate of the expensive events/origin
Network Application and Protocol
Vulnerabilities

Can produce:



Memory exhaustion
Numbered resource (e.g., ports) exhaustion
Bandwidth exhaustion...
Ports and Thread Exhaustion

In TCP/IP, an application uses a
”port”, a positive number less than 65536. Example: port
80 for web servers.

Passive FTP:
FTP server reserves a random port (above 1024) for use
by a client and waits for the client to connect there.

What if client doesn’t connect ever?
Ports example

CAN-2002-0221
Etype Eserv 2.97 allows remote attackers to
cause a denial of service (resource exhaustion)
via a large number of PASV commands that
consume ports 1024 through 5000, which
prevents the server from accepting valid PASV.
Threads Example


Microsoft NT architecture: FTP and Web services
on the same computer share a common thread
pool
Exhausting the FTP thread pool will cause failed
connection requests for the Web service.
CVE-1999-1148
IIS processes passive FTP connection requests by
assigning a thread to each port waiting for a
client to connect
Sockets

Socket: Data structure to record which application talks
to what

Internet sockets (AF_INET):

Which application reserved which port

One IP address, one port = one socket you can listen to

Incoming connections are recorded with additional sockets

Number of sockets -1 = number of clients
Sockets example

CVE-2001-0830
6tunnel 0.08 and earlier does not properly close
sockets that were initiated by a client, which
allows remote attackers to cause a denial of
service (resource exhaustion) by repeatedly
connecting to and disconnecting from the server.
Generous Protocols and Algorithms


A Protocol or Algorithm that allocates resources
based on (perhaps initially) anonymous or
unauthenticated requests
Can you name one?
TCP/IP Generosity

The TCP/IP protocol allocates memory at the beginning
stage of a communication, upon reception of a packet
with the “SYN” flag, to keep track of communications
(e.g., socket).

Early TCP/IP implementations kept the memory
allocated for a very long time...

SYN flood attack:
The sending of numerous SYN packets until all the
memory available for keeping track of new connections
has been consumed.
Generosity in Stateful Protocols

Protocols that maintain state information are
necessarily more vulnerable to DoS attacks.


Above a certain treshold, quality of service breaks down
 Connectionless protocols show progressive
degradation with load
Conversion of stateful into stateless protocols



Not easy in all cases, but can solve SYN flood
Idea: encrypt the state data, and return it to client
 No memory usage
 Increased CPU and bandwidth usage trade-off
Reference: Aura and Nikander 1997
Amplification


Form of generosity
Example: ICMP ping



Request-response protocol
Unauthenticated
Can send request to a broadcast address
 All computers respond!
 To who? A spoofed IP address == Smurf attack

Bandwidth can be completely consumed by the
response
 Overwhelm victim destination computer
 Other victims
 hosts on affected networks
 networks in between broadcast and destination
Question

Can you name another amplification mechanism
used by attackers?
a) Challenge-response mechanism
b) Encryption
c) Distributed Denial-of-Service attacks
Question

Can you name another amplification mechanism
used by attackers?
a) Challenge-response mechanism
b) Encryption
c) Distributed Denial-of-Service attacks

In DDoS attacks, amplification is provided by
numerous "zombie" (compromised) computers
obeying remote commands.
Work-Around for Generosity

Quickly expire transactions (connections, etc...)
that block while waiting on input

especially anonymous users
Exercise
Name
the vulnerability in this pseudo-code, and explain
why it is vulnerable:
1 Wait for client connection
2 Validate input
3 Create user object
4 Match user against potential dates
5 Prepare report
6 Verify that user paid subscription; if so
send back report, if not send bill
7 Repeat (i.e. go to line 1)
Exercise

Name the vulnerability in this pseudo-code, and explain
why it is vulnerable:

That is an unwise operational ordering. It can result in a
resource exhaustion because expensive operations are
performed before a request validity check.
Memory Management Problems

Memory leaks (very common)



Memory that is never freed, for every request
CAN-2003-0032
Memory leak in libmcrypt before 2.5.5 allows attackers
to cause a denial of service (memory exhaustion)
Double free

CVE-2002-0059
The decompression algorithm in zlib 1.1.3 and earlier,
as used in many different utilities and packages, causes
inflateEnd to release certain memory more than once (a
"double free"), which may allow local and remote
attackers to execute arbitrary code via a block of
malformed compression data.
Memory Management Problems
(cont.)

Use of freed memory


CAN-2002-1490
NetBSD 1.4 through 1.6 beta allows local users to cause
a denial of service (kernel panic) via a series of calls to
the TIOCSCTTY ioctl, which causes an integer overflow
in a structure counter and sets the counter to zero,
which frees memory that is still in use by other
processes.
Freeing wrong memory

CAN-2003-0525
The getCanonicalPath function in Windows NT 4.0 may
free memory that it does not own and cause heap
corruption, which allows attackers to cause a denial of
service (crash) via requests that cause a long file name
to be passed to getCanonicalPath, as demonstrated on
the IBM JVM...
Memory Management Problems
(cont.)

Information leakage



CAN-2003-0048
PuTTY 0.53b and earlier did not clear logon credentials
from memory, including plaintext passwords, which
could allow attackers with access to memory to steal the
SSH credentials.
CAN-2003-0047
SSH2 clients for VanDyke (1) SecureCRT 4.0.2 and
3.4.7, (2) SecureFX 2.1.2 and 2.0.4, and (3) Entunnel
1.0.2 and earlier, do not clear logon credentials from
memory, including plaintext passwords...
CAN-2003-0001
Multiple ethernet Network Interface Card (NIC) device
drivers do not pad frames with null bytes...
Notes About Information Leakage


Overwrite sensitive memory to prevent leakage
Compilers may remove calls to bzero and
memset during optimization



Use memory locking to prevent passwords and
keys from being saved to disk (virtual memory,
swap space)



Use SecureZeroMemory in Windows
Use spc_memset from Secure Programming Cookbook
mlock
AllocateUserPhysicalPages and VirtualLock
Disable crash dumps (core files)

setrlimit(RLIMIT_CORE, …)
Memory Management Problems
(cont.)

Invalid memory references


CAN-2002-1294
The Microsoft Java implementation, as used in Internet
Explorer, can provide HTML object references to applets
via Javascript, which allows remote attackers to cause a
denial of service (crash due to illegal memory accesses)
...
CAN-2002-1289
The Microsoft Java implementation, as used in Internet
Explorer, allows remote attackers to read restricted
process memory, cause a denial of service (crash), and
possibly execute arbitrary code via the
getNativeServices function, which creates an instance of
the com.ms.awt.peer.INativeServices (INativeServices)
class, whose methods do not verify the memory
addresses that are passed as parameters.
Memory Management Problems
(cont.)

Memory exposures


CAN-2002-1125
FreeBSD port programs that use libkvm for FreeBSD
4.6.2-RELEASE and earlier, including (1) asmon, (2)
ascpu, (3) bubblemon, (4) wmmon, and (5) wmnet2,
leave open file descriptors for /dev/mem and
/dev/kmem, which allows local users to read kernel
memory.
CAN-2002-0973
Integer signedness error in several system calls for
FreeBSD 4.6.1 RELEASE-p10 and earlier may allow
attackers to access sensitive kernel memory via large
negative values to the (1) accept, (2) getsockname, and
(3) getpeername system calls, and the (4) vesa
FBIO_GETPALETTE ioctl.
Exhausting Memory for Data
Structures





Process and other tables
Buffer pools
File descriptors
Sockets
Etc...
Human Resource Exhaustion

Typical street scenario:


Some people distract the person guarding assets while
others steal things or otherwise violate policies
Information security:

Create many alerts and warnings so that an analyst or
user is overwhelmed and can't identify the dangerous
ones.
 IDS flooding tools available
 "Stick" (Giovanni 2001)

Attack against online support and services
 Chat bots (Gabriolovich and Gontmahker 2003)
 Defense: Reverse Turing Tests
 Recognizing distorted letters in an image
 Riddles
Discussion

Discuss the similarities between SPAM and
human resource exhaustion attacks.
True or False?

Denial of service attacks are all caused by resource
exhaustion

All shared resources risk being exhausted

Lower resource cost to the attacker than the defender is
indicative of a resource exhaustion vulnerability
Questions?
About These Slides

You are free to copy, distribute, display, and perform the work;
and to make derivative works, under the following conditions.






You must give the original author and other contributors credit
The work will be used for personal or non-commercial educational uses
only, and not for commercial activities and purposes
For any reuse or distribution, you must make clear to others the terms
of use for this work
Derivative works must retain and be subject to the same conditions,
and contain a note identifying the new contributor(s) and date of
modification
For other uses please contact the Purdue Office of Technology
Commercialization.
Developed thanks to the support of Symantec
Corporation
Pascal Meunier
pmeunier@purdue.edu


Contributors:
Jared Robinson, Alan Krassowski, Craig
Ozancin, Tim Brown, Wes Higaki, Melissa
Dark, Chris Clifton, Gustavo RodriguezRivera