defensive programming using an annotation toolkit to build dos-resistant software

Dec 2002 OSDI'02, Boston, MA 1

Defensive Programming

Using an Annotation Toolkit to Build DoS-Resistant Software

Xiaohu (Tiger) QieRuoming Pang and Larry Peterson

Princeton University


How to DoS a Networked System• Exhaust resource on a remote target

Making normal service unavailable Seriously degrade service quality

• Examples– Christmas tree packets

• Flood of packets with IP options• Router CPU swamped Too busy to run routing protocols

– Ping flood– TCP SYN flood


• Web Servers limit the number of connections• Idea: Slow down TCP

– Slow sender: • ‘G’, ‘E’, ‘T’, ‘ ’, ‘/’, ‘/’, ‘/’, ...

– Slow receiver and acker: • Request a big file• Open receive window lazily• Pretend packets were lost

– Tie up all connections for as long as you want

• Other victims: NIS servers, NAT boxes ...

How to Slow-DoS a Web Server


Renewable Resources

CPU cycles

Network BW

Disk BW

Non-renewable Resources

Processes

File descriptors

Buffers

Resources and Vulnerabilities

Busy AttackVulnerability

Claim-and-holdAttack

Vulnerability

Admission control

Recycle


Proposal: Defensive Programming• Program for Robustness

– Integrate software functionality and protection– Highlight resource control– Pro-active, Systematic and Fine-grained

protection

• Annotation Toolkit– Sensors and Actuators– Protect both renewable and non-renewable

resources– Low programming burden


Related Work

AnnotatioAnnotation Toolkitn Toolkit

OS Protection

Profiling

Static Analysis

Anomaly Detection


Outline

• Attack and Resource Characterization• Toolkit Description• Case Study• Conclusions


Renewable Resource Protection– Divide program functionality into services– Balance resource consumption– Confine damage of a DoS attack within a service

S

S

S

S

S

S

S

Renewable ResourcesServices

Client Request

SR

R

R

X

R

R

X

X

X

X

S

S


Rate Limiting Options

Resource not balanced among services

Hard to set appropriate limits

foo

teebar

Yes

STOP

RESOURCE

No

rate < 100?RL

foo

teebar

RESOURCE

rate < ???

rate < ???

RL

RL

RL


Rate Sensor & Service Admission

foo

teebar

RESOURCE

A

AA

void foo() { ... bar(); send_pkt();}

void bar() { ... send_pkt();}

void send_pkt() { ...}

void foo() { SERVICE_ADMISSION; bar(); send_pkt();}

void bar() { SERVICE_ADMISSION; send_pkt();}

void send_pkt() { RATE_SENSOR(100HZ);}

RATE SENSOR


Time Sensor

foo

bar

compute_piDeadline

A

TIME_SENSOR

MaxTimeA

void entry() { TIME_SENSOR(100); foo(); bar();}void foo() { SERVICE_ADMISSION;}void bar() { SERVICE_ADMISSION; compute_pi();}void compute_pi() { SERVICE_ADMISSION;}

A


Non-Renewable Resource Protection

– Inspect principals that hold resources– Reclaim resources from “unproductive” principals– Starvation avoidance

R

R

Non-Renewable Resources

AcceptedRequests

R

Incoming Requests

Principals


• Timer-based recycle– Idle timer– One shot timer

• Progress-based recycle– User-defined progress metric

• E.g. output generated, state transitions made

– Reclaim resources from the “slowest” principal – User-defined pressure metric to trigger

reclamation

Non-Renewable Resource Protection


CGIDirectory

File

Send Response

Dispatcher

Read/Parse Request

Progress Sensor & Reclamation Checkpoint

DoConnReadingBackend() { switch(ProcessRequestReading()) { case PRR_DONE: PROGRESS_SENSOR(10000); /* switch to sending */ break; ...

DoSingleWriteBackend() { sz = writev(...); /* Ok, we wrote something. */ PROGRESS_SENSOR(sz); if (all data are sent) { /* conection is finished! */ DoneWithConnection(c, FALSE); return; } ...PROGRESS SENSOR

C

PROGRESS SENSOR

PROGRESS SENSOR


Toolkit Implementation• Sensors and Actuators

– 11 C-macros / library functions– Managing renewable resources

• RATE_SENSOR, TIME_SENSOR• SERVICE_ADMISSION

– Managing non-renewable resources• PRESSURE_SENSOR, PROGRESS_SENSOR ...• RECLAMATION_CHECKPOINT

• Compiler assistance– Auxiliary code generation– Annotation coverage check


• Flash– Event-driven architecture– ~12,000 lines of code

• Annotating Flash Web Server– 46 services (mainly event handlers)– TIME_SENSOR in main loop, enclosing all

services– PRESSURE_SENSOR tracks connection

availability– PROGRESS_SENSOR in every stage– Added ~60 annotations

Case Study: Flash Web Server


Services in FlashMain Loop

StartRequest

RegularFileStuff ProcessColdRequest SendDirRedirectScheduleDirHelp

CGIStuff ProcessColdRequestBackend2

ExpandSymlinks

RegularFileStuff ProcessColdRequest

ExpandSymlinks


Slash Attack

• O(N^2) memory read/write: – ~150ms for 10,000 slashes

• “GET //////////////////…///xyz”– 7 requests per second saturates server

/* Remove any leading slashes. */

while ( rest[0] == '/' ) {

(void) strcpy( rest, &(rest[1]) );

--restlen;

}


Flash Under Slash Attack• Normal Client:

– Requests a 10KB file in the hot name cache

• Attacker: – Requests cold URLs with 10000 slashes– 10 requests per second

• Average client-perceived response time:

no attackerw/ attacker

unmodified serverw/ attacker

annotated server

4.3ms >25 seconds 5.1ms


• Effectiveness depends on service granularity– All clients requesting cold URLs are affected– Possible solution: refine classification

granularity

• How to set parameters– Don’t have to be precise – for disaster control

only– Fine tune from behavior profile

Limitations


Conclusions• Defensive Programming:

– Protect from inside– A useful additional layer of protection

• Toolkit:– Renewable resources balanced among services– Non-renewable resources recycled based on

progress– Systematic deployment of sensors and

actuators• Not to look for specific “bugs”

– Low programming burden


More Information

• http://www.cs.princeton.edu/nsg

Thank you!

defensive programming using an annotation toolkit to build dos-resistant software

Documents

void bar

admission bar

void compute

admission compute

sensor100 foo bar

normal service unavailable

dos attack

slow receiver