Non-Control-Data Attacks Are Realistic Threats

1
Non-Control-Data Attacks Are Realistic Threats

• Shuo Chen, Jun Xu, Emre Sezer, Prachi
  Gauriar, Ravi Iyer

• Center for Reliable and High-Performance
  Computing, University of Illinois at
  Urbana-Champaign
• Department of Computer Science, North Carolina
  State University
• Cybersecurity and Systems Management Group,
  Microsoft Research

2
Control Data Attack Well-Known, Dominant

• Control data attack corrupt function pointers,
  jump targets and return addresses to run
  malicious code
• E.g., code injection, mimicry attack and
  return-to-LibC
• Currently the most dominant form of memory
  corruption attacks CERT and Microsoft Security
  Bulletin
• By exploiting many vulnerabilities such as buffer
  overflow, format string bug, integer overflow,
  double free, etc.
• Many current defense techniques to enforce
  control data integrity to provide security.

3
Non-Control-Data Attack

• Non-control-data attacks attacks not corrupting
  any control data
• i.e., attacks preserving the integrity of control
  flow of the victim process
• Currently very rare in reality
• Very few instances documented in literature.
• Several papers theoretically possible to
  construct non-control-data attacks against
  synthetic programs.
• Not yet considered as a serious threat
• How applicable are such attacks against
  real-world software?
• Why rare ? attackers incapability or lack of
  incentives?
• No focused investigation yet.

4
Motivating Facts

• Random hardware memory errors could subvert the
  security of real-world systems.
• Boneh and DeMillo random errors allow deriving
  secret keys in CRT-based RSA implementation.
  Eurocrypt97
• Our previous work authentication of SSH and FTP
  servers, packet filtering of Linux firewalls can
  be compromised. DSN01 and DSN02
• Govindavajhala and Appel Java type system can be
  subverted. SP03
• None of them is control-data attack. A wide range
  of real-world software susceptible.
• Software vulnerabilities are more deterministic
  and more amenable to attacks.
• Many software vulnerabilities are essentially
  memory fault injectors overwriting an
  arbitrary memory location
• Heap overflow
• Double free
• Format string bug
• Integer overflow

5
Our Claim General Applicability of
Non-Control-Data Attacks

• The claim
• Many real-world software applications are
  susceptible to non-control-data attacks.
• The severity of the attack consequences is
  equivalent to that due to control data attacks.
• Goal of our project
• Experimentally validate the claim
• Construct non-control-data attacks to compromise
  the security of representative applications
• Discuss the implications of the claim on current
  defensive techniques
• Call for comprehensive defensive techniques

6
Selection of Target Applications

• Real-world applications, not synthetic
  applications.
• Leading application categories
• CERT advisories (2000 2004)
• 84 are server vulnerabilities
• HTTP service (18), database service (10), 6
  remote login service (8), mail service (5), FTP
  service (4).
• Selection criteria
• Different types of vulnerabilities should be
  covered
• Different types of server applications should be
  studied
• Practical constraints for our selection
• Uncertainties in many vulnerability reports
  really exploitable?
• Proprietary source code
• Limited information about details of many
  vulnerabilities
• Eventually, we selected
• Open-source FTP, SSH, Telnet, HTTP servers
• Stack buffer overflow, format string, heap
  corruption, integer overflow.

7
Non-Control-Data Attack against WU-FTPD Server
(via a format string bug)
int x FTP_service(...) authenticate() x
user ID of the authenticated user seteuid(x)
while (1) get_FTP_command(...) if
(a data command?) getdatasock(...)
getdatasock( ... ) seteuid(0)
setsockopt( ... ) seteuid(x)
When return to service loop, still runs as EUID 0
(root). Allow us to upload /etc/passwd We can
grant ourselves the root privilege! Only corrupt
an integer, not a control data attack.
8
Non-Control-Data Attack against NULL-HTTP Server
(via a heap overflow bug)

• Attack the configuration string of CGI-BIN path.
• Mechanism of CGI
• suppose server name www.foo.comCGI-BIN
• Requested URL http//www.foo.com/cgi-bin
• The server executes
• Our attack
• Exploit the vulnerability to overwrite CGI-BIN to
  /bin
• Request URL http//www.foo.com/cgi-bin/sh
• The server executes

/usr/local/httpd/exe
/usr/local/httpd/exe
/bar
/bar
/bin
/sh
The server gives me a root shell! Only overwrite
four characters in the CGI-BIN string.
9
Non-Control-Data Attack against SSH
Communications SSH Server (via an integer
overflow bug)
void do_authentication(char user, ...) int
auth 0 ... while (!auth) / Get a
packet from the client / type
packet_read() switch (type) ...
case SSH_CMSG_AUTH_PASSWORD if
(auth_password(user, password)) auth
1 case ... if (auth) break
/ Perform session preparation. /
do_authenticated()
10
More Non-Control-Data Attacks

• Against NetKit Telnet server (default Telnet
  server of Redhat Linux)
• Exploit a heap overflow bug
• Overwrite two strings/bin/login h foo.com -p
  (normal scenario) /bin/sh h p
  -p (attack scenario)
• The server runs /bin/sh when it tries to
  authenticate the user.
• Against GazTek HTTP server
• Exploit a stack buffer overflow bug
• Send a legitimate URL http//www.foo.com/cgi-bin/b
  ar
• The server checks that /.. is not embedded in
  the URL
• Exploit the bug to change the URL to
  http//www.foo.com/cgi-bin/../../../../bin/sh
• The server executes /bin/sh

11
What Non-Control-Data Attacks Imply?

• Control flow integrity is not a sufficiently
  accurate approximation to software security.
• Many types of non-control data critical to
  security
• User identify data, configuration data, user
  input data and decision-making data
• Once attackers have the incentive, they are
  likely to succeed in non-control-data attacks.

12
Discussions on Current Defensive Techniques

• Defenses based on control flow integrity
• Monitor system call sequences
• Protect control data
• Non-executable stack and heap
• Pointer encryption PointGuard
• Identifying pointers in low level code is really
  challenging
• Address space randomization
• Challenge need to randomize every program
  segment
• Limitation 32-bit address space cannot provide
  sufficient entropy
• Memory safety enforcement
• Promising direction, e.g., CCured, Cyclone, CRED
• Currently difficult to migrate existing large
  code bases to memory safe version. Incur runtime
  overhead. Difficult to ensure memory safety for
  low-level code.
• Still open to design a generic and secure defense

13
Mitigating Factors

• Requiring application-specific semantic knowledge
• Control-data attack ? unrelated to the semantics
  of the victim process (hijack the control flow,
  do whatever you like)
• Non-control-data attack ? rely on the semantics
  of the victim process
• Not a fundamental constraint
• Semantics of widely used applications will be
  well understood, if attackers have strong
  incentives
• The more instances attackers see, the easier they
  can clone new ones. A matter of experiences.
• Lifetime of security-critical data
• Attacks are not possible if the vulnerabilities
  exist outside the lifetime of the target data.
• Programs can be modified to reduce data lifetime
  to enhance security.

14
Reducing Data Lifetime for Security
Original WU-FTPD lifetime of x is global siteexec() getdatasock() seteuid(0) setsockopt( ... ) seteuid(x) Modified WU-FTPD siteexec() getdatasock() tmp geteuid() seteuid(0) setsockopt( ... ) seteuid(tmp)
Lifetime of seteuid() argument
15
Reducing Data Lifetime for Security
Original SSHD do_authentication() int auth 0 while (!auth) type packet_read() switch (type) case CMSG_AUTH_PASSWORD if (auth_password(passwd)) auth 1 case ... if (auth) break do_authenticated(pw) Modified SSHD do_authentication() int auth 0 while (!auth) type packet_read() auth 0 switch (type) case CMSG_AUTH_PASSWORD if (auth_password(passwd)) auth 1 case ... if (auth) break do_authenticated(pw)
Lifetime of auth flag
16
Conclusions

• Major claim many real-world software
  applications are susceptible to attacks that do
  not hijack program control flow.
• Constructing a generic and secure defensive
  technique to defeat both control-data attacks and
  non-control-data attacks is still an open
  problem.
• Reducing data lifetime is a secure programming
  practice to increase software resilience to
  attacks.

17
Links

• DEPEND Research Group, Univ. of Illinois
• http//www.crhc.uiuc.edu/DEPEND
• Prof. Jun Xus Research Group. North Carolina
  State University
• http//www.csc.ncsu.edu/faculty/junxu/
• Cybersecurity and Systems Management Group,
  Microsoft Research (a.k.a. the Strider team)
• http//research.microsoft.com/csm