190 likes | 321 Vues
This presentation explores the emerging threat of Non-Control Data (NCD) attacks, which exploit memory vulnerabilities without affecting control flow. While currently less prevalent than Control-Data attacks, NCD attacks can lead to severe security compromises, including root privilege escalation. We discuss the techniques used in NCD attacks, such as stack and heap overflows, and examine the limitations of existing defenses against these emerging threats. The necessity for robust security measures and innovative solutions to effectively counter these attacks is underscored.
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??