TOCTTOU Vulnerability and Stack Security in Unix Systems - Prof. X. D. Song, Study notes of Computer Science

The tocttou (time-of-check to time-of-use) vulnerability, a common issue in unix systems where the meaning of a file path can change between a stat() and open() call, allowing an attacker to bypass security checks. The text also covers methods to prevent stack exploits, such as marking the stack as non-executable and implementing stack guards.

Typology: Study notes

Pre 2010

Uploaded on 10/01/2009

koofers-user-7cn
koofers-user-7cn 🇺🇸

9 documents

1 / 12

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Software security; Common implementation flaws;
Principles
Dawn Song
2
Another Vulnerability
char buf[80];
void vulnerable() {
int len = read_int_from_network();
char *p = read_string_from_network();
if (len > sizeof buf) {
error("length too large, nice try!");
return;
}
memcpy(buf, p, len);
}
What's wrong with this code?
Hint – memcpy() prototype:
void *memcpy(void *dest, const void *src, size_t n);
Definition of size_t: typedef unsigned int size_t;
Do you see it now?
3
Implicit Casting Bug
Attacker provides a negative value for len
if won’t notice anything wrong
Execute memcpy() with negative third arg
Third arg is implicitly cast to an unsigned int, and
becomes a very large positive int
memcpy() copies huge amount of memory into buf,
yielding a buffer overrun!
A signed/unsigned or an implicit casting bug
Very nasty – hard to spot
C compiler doesn’t warn about type mismatch
between signed int and unsigned int
Silently inserts an implicit cast
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download TOCTTOU Vulnerability and Stack Security in Unix Systems - Prof. X. D. Song and more Study notes Computer Science in PDF only on Docsity!

1

Software security; Common implementation flaws;

Principles

Dawn Song

[email protected]

2

Another Vulnerability

  • char buf[80]; void vulnerable() { int len = read_int_from_network(); *char p = read_string_from_network(); if (len > sizeof buf) { error("length too large, nice try!"); return; } memcpy(buf, p, len); }

• What's wrong with this code?

• Hint – memcpy() prototype:

  • **void *memcpy(void dest, const void src, size_t n);

• Definition of size_t: typedef unsigned int size_t;

• Do you see it now?

Implicit Casting Bug

• Attacker provides a negative value for len

  • if won’t notice anything wrong
  • Execute memcpy() with negative third arg
  • Third arg is implicitly cast to an unsigned int, and becomes a very large positive int
  • memcpy() copies huge amount of memory into buf, yielding a buffer overrun!

• A signed/unsigned or an implicit casting bug

  • Very nasty – hard to spot

• C compiler doesn’t warn about type mismatch

between signed int and unsigned int

  • Silently inserts an implicit cast

4

Another Example

  • size_t len = read_int_from_network(); *char buf; buf = malloc(len+5); read(fd, buf, len); ...
  • What’s wrong with this code?
    • No buffer overrun problems (5 spare bytes)
    • No sign problems (all ints are unsigned)
  • But, len+5 can overflow if len is too large
    • If len = 0xFFFFFFFF, then len+5 is 4
    • Allocate 4-byte buffer then read a lot more than 4 bytes into it: classic buffer overrun!
  • You have to know programming language’s

semantics very well to avoid all the pitfalls

5

Preventing overflow attacks

  • Main problem:
    • strcpy(), strcat(), sprintf() have no range checking.
    • “Safe” versions strncpy(), strncat() are misleading » strncpy() may leave buffer unterminated. » strncpy(), strncat() encourage off by 1 bugs.
  • Defenses:
    • Type safe languages (Java, ML). Legacy code?
    • Mark stack as non-execute. Random stack location.
    • Static source code analysis.
    • Run time checking: StackGuard, Libsafe, SafeC, (Purify).
    • Many more …

Marking stack as non-execute

  • Basic stack exploit can be prevented by marking stack segment as non-executable. - NX-bit on AMD Athlon 64, XD-bit on Intel P “Prescott”. » NX bit in every Page Table Entry (PTE) - Support in SP2. Code patches exist for Linux, Solaris.
  • Limitations:
    • Does not defend against `return-to-libc’ exploit. » Overflow sets ret-addr to address of libc function.
    • Does not block more general overflow exploits: » Overflow on heap: overflow buffer next to func pointer.
    • Some apps need executable stack (e.g. LISP interpreters).

10

Non-Language-Specific Vulnerabilities

  • *int openfile(char path) { struct stat s; if (stat(path, &s) < 0) return -1; if (!S_ISRREG(s.st_mode)) { error("only regular files allowed!"); return -1; } return open(path, O_RDONLY); }
  • Code to open only regular files
    • Not symlink, directory, nor special device
  • On Unix, uses stat() call to extract file’s

meta-data

  • Then, uses open() call to open the file

11

The Flaw?

  • Code assumes FS is unchanged between stat()

and open() calls – Never assume anything…

  • An attacker could change file referred to by path

in between stat() and open()

  • From regular file to another kind
  • Bypasses the check in the code!
  • If check was a security check, attacker can subvert system security
  • Time-Of-Check To Time-Of-Use (TOCTTOU)

vulnerability

  • Meaning of path changed from time it is checked (stat()) and time it is used (open())

TOCTTOU Vulnerability

  • In Unix, often occurs with filesystem calls

because system calls are not atomic

  • But, TOCTTOU vulnerabilities can arise

anywhere there is mutable state shared

between two or more entities

  • Example: multi-threaded Java servlets and applications are at risk for TOCTTOU

13

Many More Vulnerabilities…

  • We’ve only scratched the surface!
    • These are the most prevalent examples
  • If it makes you just a bit more cautious

about how you write code, good!

  • In future lectures, we’ll discuss how to

prevent (or reduce the likelihood of) these

kinds of flaws, and to improve the odds of

surviving any flaws that do creep in

14

Administrivia

  • Office hour this week moved to Thu 4pm.
  • From next week on, office hour moved to

Wed 5pm.

Principles of Secure Software

  • Let’s explore some principles for building

secure systems

  • Trusted Computing Base & several principles
  • These principles are neither necessary nor

sufficient to ensure a secure system design,

but they are often very helpful

  • Goal is to explore what you can do at design

time to improve security

  • How to choose an architecture that helps reduce likelihood of system flaws (or increases survival rate)
  • Next lecture: what to do at implementation time

19

TCB Example (continued)

  • What about a web browser application on

the same machine? Is it in the TCB?

  • Hopefully not!
    • OS is supposed to protect sshd from other unprivileged applications
  • Another ex.: network perimeter firewall
    • Enforces security goal that only authorized connections are permitted into internal net
  • In this example, the firewall is the TCB for

this security goal

20

Why Keep the TCB Simple and Small?

  • Good practice!
    • Less code you write, less chances to make mistakes or introduces implementation flaws
  • Industry standard error rates are 1–5 defects

per thousand Lines of Code (kLoC)

  • TCB containing 1 kLoC might have 1–5 defects
  • 100 kLoC TCB might have 100–500 defects!
  • (Windows XP is about 40,000 kLoC of TCB!!) » Almost all of which is the TCB
  • Lesson:
  • Shed code and design system so as much code can be moved outside the TCB as possible

TCBs: What are They Good for?

  • Is the TCB concept just an esoteric idea?
    • No, it is a very powerful and pragmatic idea
    • TCB allows primitive, yet effective modularity
  • Separates system into two parts: security-

critical (TCB) and everything else

  • Building secure and correct systems is hard!
    • More pieces makes security assurance harder
    • Only parts in TCB must be correct for system security –> focus efforts where they matter
    • Making TCB small gives us better odds of ending up with a secure system

22

Ex: Email Retention for National Archives

  • National Archives chartered with saving a

copy of every email ever sent by

government officials

  • Security Goal: Ensure that saved records cannot be deleted or destroyed
  • Someone being investigated might try to destroy embarrassing or incriminating archived documents
  • We need an “append-only” document

storage system

  • How can we do it?

23

A Possible Approach

  • Augment email program on every desktop

computer to save a copy of all emails to a special

directory on that computer

  • What's the TCB for this approach? » TCB includes every copy of email application on every government machine » Also OS, all privileged SW, and sys admins
  • That’s an awfully large TCB!
  • Unlikely that everything in TCB works correctly
  • Also, any sys admin can delete files from the

special directory after the fact

  • We’d better find a better solution!!

Another Approach

  • Set up a high-speed networked printer
    • An email is “collected” when it is printed
    • Printer room is locked to prevent tampering
    • What’s the TCB in this system? » TCB includes room’s physical security » Also includes the printer
  • Suppose we add a ratchet to paper spool so

that it can only rotate forward

  • Don’t need to trust the rest of the printer
  • Wow!
  • TCB is only this ratchet, and room’s physical security, nothing else!
  • But, our approach uses a lot of paper!

28

1. Conservative Design

  • Systems should be evaluated according to

worst plausible security failure, under

assumptions favorable to attacker

  • If you find such circumstance where the

system can be rendered insecure, then

you should seek a more secure system

29

2. Kerkhoff’s Principle

  • Cryptosystems should remain secure

even when the attacker knows all internal

details of the system

  • The key should be the only thing that

must be kept secret

  • If your secrets are leaked, it is a lot easier

to change the key than to change the

algorithm

3. Proactively Study Attacks

  • We must devote considerable effort to trying

to break our own systems

  • How we can gain confidence in their security
  • Other reasons:
  • In security game, attacker gets last move
  • Very costly if a security hole is discovered after wide system deployment
  • Pays to try to identify attacks before bad

guys find them

  • Gives us lead time to close security holes before they are exploited in the wild

31

Principles for Secure Systems

  • General principles for secure system design
    • Many drawn from a classic 1970s paper by Saltzer and Schroeder
  • 1. Security is Economics
    • No system is 100% secure against all attacks » Only need to resist a certain level of attack » No point buying a $10K firewall to protect $1K worth of trade secrets
    • Often helpful to quantify level of effort an attacker would expend to break the system.
    • Adi Shamir once wrote, “There are no secure systems, only degrees of insecurity” » A lot of the science of computer security comes in measuring the degree of insecurity

32

Economics Analogy

  • Safes come with a security level rating
  • Consumer-grade safe:
    • Rated to resist attack for up to 5 minutes by anyone without tools
  • High-end safe might be rated TL-
    • Secure against burglar with safecracking tools and less than 30 minutes access
    • We can hire security guards with a less than 30 minute response time to any intrusion

Corollary of This Principle

  • Focus your energy on securing weakest links
    • Security is like a chain: it is only as secure as the weakest link
    • Attackers follow the path of least resistance, and will attack system at its weakest point
  • No point in putting an expensive high-end

deadbolt on a screen door

  • Attacker isn’t going to bother trying to pick the lock when he can just rip out the screen and step through!