Defensive Programming Using an Annotation Toolkit to Build DoS-Resistant Software

Defensive ProgrammingUsing an Annotation Toolkit to Build DoS-Resistant Software Xiaohu (Tiger) Qie Ruoming Pang and Larry Peterson Princeton University OSDI'02, Boston, MA

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 OSDI'02, Boston, MA

How to Slow-DoS a Web Server • 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 ... OSDI'02, Boston, MA

Resources and Vulnerabilities Renewable Resources CPU cycles Network BW Disk BW Non-renewable Resources Processes File descriptors Buffers Admission control Busy Attack Vulnerability Claim-and-hold Attack Vulnerability  Recycle OSDI'02, Boston, MA

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 OSDI'02, Boston, MA

OS Protection Static Analysis Anomaly Detection Profiling Related Work Annotation Toolkit OSDI'02, Boston, MA

Outline • Attack and Resource Characterization • Toolkit Description • Case Study • Conclusions OSDI'02, Boston, MA

X R X R S X X S Renewable Resource Protection • Divide program functionality into services • Balance resource consumption • Confine damage of a DoS attack within a service S R S S X R Client Request S S S R S S Services Renewable Resources OSDI'02, Boston, MA

rate < ??? RL foo foo rate < ??? bar tee RL RL rate < 100? STOP RL bar tee No Yes RESOURCE RESOURCE Rate Limiting Options Resource not balanced among services Hard to set appropriate limits OSDI'02, Boston, MA

Rate Sensor & Service Admission 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); } A foo A A bar tee RATE SENSOR RESOURCE OSDI'02, Boston, MA

Time Sensor TIME_SENSOR void entry() { TIME_SENSOR(100); foo(); bar(); } void foo() { SERVICE_ADMISSION; } void bar() { SERVICE_ADMISSION; compute_pi(); } void compute_pi() { SERVICE_ADMISSION; } A foo A MaxTime bar A compute_pi Deadline OSDI'02, Boston, MA

Non-Renewable Resource Protection • Inspect principals that hold resources • Reclaim resources from “unproductive” principals • Starvation avoidance R R R Incoming Requests Accepted Requests Non-Renewable Resources Principals OSDI'02, Boston, MA

Non-Renewable Resource Protection • 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 OSDI'02, Boston, MA

C DoConnReadingBackend() { switch(ProcessRequestReading()) { case PRR_DONE: PROGRESS_SENSOR(10000); /* switch to sending */ break; ... Dispatcher Read/Parse Request PROGRESS SENSOR DoSingleWriteBackend() { sz = writev(...); /* Ok, we wrote something. */ PROGRESS_SENSOR(sz); if (all data are sent) { /* conection is finished! */ DoneWithConnection(c, FALSE); return; } ... File Directory CGI PROGRESS SENSOR Send Response PROGRESS SENSOR Progress Sensor & Reclamation Checkpoint OSDI'02, Boston, MA

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 OSDI'02, Boston, MA

Case Study: Flash Web Server • 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 OSDI'02, Boston, MA

Services in Flash Main Loop    StartRequest RegularFileStuff RegularFileStuff ProcessColdRequest ProcessColdRequest ScheduleDirHelp SendDirRedirect          CGIStuff ProcessColdRequestBackend2 ExpandSymlinks ExpandSymlinks    OSDI'02, Boston, MA

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; } OSDI'02, Boston, MA

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: OSDI'02, Boston, MA

Limitations • 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 OSDI'02, Boston, MA

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 OSDI'02, Boston, MA

More Information • http://www.cs.princeton.edu/nsg Thank you! OSDI'02, Boston, MA

Defensive Programming Using an Annotation Toolkit to Build DoS-Resistant Software