24

I'm actually fixing driver under Linux. Klokwork said that code like:

file = fopen(fileName, "w+"); // w+,r,a and any mix of those is used here
if (file != NULL) { /* do things*/ }
else { /* throw error */ }
fclose(file);

can end as Time-of-check to time-of-use vulnerability.

However as far as I read it need do something like if(access()) before fopen to make it happen.

And there is question: Does that code example I show have any weak point? or I don't need to care?

Henry Malinowski
  • 103
  • 2
user209896
  • 243
  • 3
  • 4
  • You may as well review Bishop and Dilger's original paper at [Checking for Race Conditions in File Accesses](https://www.usenix.org/legacy/publications/compsystems/1996/spr_bishop.pdf) –  Jun 11 '19 at 17:10

1 Answers1

29

A call to fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”.

A common example of TOCTOU vulnerability is checking access permissions with access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a vulnerability because file permissions are important for security.

The access system call is highly suspicious because there aren't many ways to use it that don't introduce a TOCTOU. The fopen call in itself is not particularly suspicious because there are many ways to use it that are safe. However this doesn't mean that access is the only way to make a TOCTOU with fopen.

An example of race condition that can occur when opening files is if you got the file name from some external source, and you make assumptions about that name. For example, if you build the argument to fopen by concatenating a directory name with a file name, and you've made some checks on the directory, that's a TOCTOU vulnerability as well. The checks on the directory may no longer be valid by the time you use the directory to open a file. That's why Linux has the openat system call: so you can call opendir on a directory, perform checks on the directory, then call openat to open a file inside that directory (whereas open with concatenated names would open a file in a directory which now has this name, but may not be the one you checked).

So yes, you do need to care. Your code may or may not have a vulnerability. In my very limited experience, Klocwork does have a lot of false positives, but not everything is a false positive. Start by reading the complete message carefully. Review your code carefully, with written-down security objectives, and track how these security objectives are met (or not). There's no miracle: writing correct and secure code is harder than just applying a checklist.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • Then to sum up that. 1. if i successful open file I'm safe and there is not that much to do for attacker. 2. but i need make sure user open right file – user209896 Jun 10 '19 at 10:41
  • 6
    @user209896 Right. If `fopen` succeeds _and you know that you opened the file you meant to open_, you're safe. – Gilles 'SO- stop being evil' Jun 10 '19 at 10:45
  • 1
    Not all uses of `access(2)` lead to TOCTOU vulnerabilities. Also see AOSP [Issue 36941868, sdcard.c, do_node_get_path: possible TOCTOU due to use of access(2)](https://issuetracker.google.com/issues/36941868) –  Jun 11 '19 at 17:16
  • In the general case, it is extremely difficult to avoid TOCTOU issues. For example, if you check whether a file exists, by any means whatsoever, then your thread could get preempted and another thread could create or delete the file right after the check returns. But unless an attacker can leverage that bug into a security vulnerability, it's (mostly) uninteresting. Not all TOCTOU's are security vulnerabilities. – Kevin Jun 11 '19 at 18:18