200 likes | 347 Views
Non-Control-Data Attacks Are Realistic Threats Shuo Chen, Jun Xu, Emre C. Sezer, Prachi Gauriar, and Ravishankar K. Iyer Presented by Stephen Karg October 12, 2005. Control-Data Attack. Control Data : Data loaded to program counter during execution. e.g. return address, function pointer…
E N D
Non-Control-Data Attacks Are Realistic ThreatsShuo Chen, Jun Xu, Emre C. Sezer, Prachi Gauriar, and Ravishankar K. IyerPresented byStephen KargOctober 12, 2005
Control-Data Attack • Control Data: Data loaded to program counter during execution. • e.g. return address, function pointer… • Currently the most dominant attack. • The common pattern of most memory attacks we’ve seen so far: • Hijack target programs. • Inject own code or out-of-context library. • Make system calls to spawn root shell.
Non-Control-Data Attack(a.k.a. Pure Data Exploits) • Also memory corruption, but control-flow remains unaffected. • No shell code, no system calls. • Virtually unseen in the wild. Q: Why so rare? A: Harder to mount attack, requires application-specific semantic knowledge. Q: So why do we care? A: Necessity is the mother of invention.
Thesis • As Control-Data defenses continue to improve, attackers will be more motivated to seek alternatives. • Non-Control-Data attacks result in security compromises just as severe as Control-Data attacks (i.e. root privilege escalation). • Inadequate protections currently in place.
How do they work? • Use known exploits to overwrite NCD: • Stack Overflow • Format string vulnerabilities • Heap overflow • Signed integer overflow • NCD often associated with authentication or access control privileges. • Manual source-code analysis needed to expose NCD exploits.
Security-Critical NCD • Configuration Data • User Input • User Identity Data • Decision-Making Data All can be corrupted to gain access to various well know network server applications.
1. Configuration Data Attack • Site-specific config. files in common server applications (ftp, ssh, http, etc.) can define access control policies. • E.g. Linux Null HTTPD server’s CGI-BIN configuration string: • restricts users from executing programs outside specified path. • Use heap corruption to transform string: /usr/local/httpd/cgi-bin\0 /bin\0 • Can then run /bin/sh as legitimate CGI program. • Root shell access with 3 POST commands!
2. User Identity Data Attack • Known format-string exploit on the popular WU-FTP server used to corrupt data structure so EUID can be reverted to 0 (yay!). • putand get commands invoke: • pw->pw_uid cached copy of user ID on heap.
3. User Input Data Attack • Stack overflow on GHTTPD used to gain root with a single GET command! GET AA…AA\xdc\xd7\xff\xbf <-<-/cgi-bin/../../../../bin/sh • Classic TOCTTOU attack with invalid path. • Server checks 1st part of command for the old “/..” trick. • Pointer to the now “ok” URL is then corrupted to reference illegal string in 2nd part of GET.
4. Decision-Making Data Attack • Integer Overflow exploit on multiple SSH servers allows attacker to log on as root. • Client responds to root password request with packet formulated to trigger overflow in the detect_attack() function :) • Overflow corrupts value of the boolean flag: authenticated to non-zero value. Done.
Defensive Techniques that Don’t Work • StackSheild won’t work, no address change. • IDS System Call Tracing? Won’t work, unchanged. • Non-Executable-Memory protections? Irrelevant. No injected code. • Memory/Type Safety Enforcement Can prevent some NCD attacks but with very high overhead and migration costs, currently unsuitable for high-traffic network applications.
Defensive Techniques & Mitigations • StackGuard and FormatGuard are still effective against both attacks using those initial exploits. • Minimize lifetime of critical data structures or reinitialize w/safe values (e.g. authenticated). • Encrypt sensitive configuration data.
Other Potential Defenses/Research • PointGuard (pointer encryption compiler technique). Still needs work. • Address-Space randomization. • Helpful but will not stop determined attack. • Taintcheck - partially effective. • Brutal overhead cost (5-37x), false-positives • Extend IDS to include data-flow analysis (in addition to control-flow). • Heuristic analysis of function parameter signatures.
Conclusions • IDS based on just Control Flow integrity insufficient. • Current defensive techniques are not comprehensive, and only provide partial coverage of NCD exploits. • No generic memory protection available at a reasonable (runtime) cost. • Safer running closed-source apps??