2

I am using FlawFinder to find potential vulnerabilities in a piece of C code.

In the analysis, the tool reports this problem:

file.c:54:  [2] (misc) fopen:
  Check when opening files - can an attacker redirect it (via symlinks),
  force the opening of special file type (e.g., device files), move things
  around to create a race condition, control its ancestors, or change its
  contents? (CWE-362).

The related piece of code is this one:

FILE *aFile = fopen("/tmp/tmpfile", "w");

Although I know that not all the problems reported are errors or vulnerabilities, I would like to understand why this happens and how I could potentially fix it. I tried searching the web, but all I found was about race condition and I don't understand why this piece of code could lead to race condition.

Moreover, is there an alternative function I could use instead of fopen?

Francesco
  • 897
  • 8
  • 22
  • 1
    All of the issue mentioned there are not issues inherent to `fopen` but are issues related to opening a file. If you use a name in the file system to open a file, all of those are potential problems. – William Pursell Nov 05 '20 at 15:41
  • It's not the `fopen`'s fault, but the fact that you're opening a file inside the `/tmp` directory, where any other user can create `/tmp/tmpfile` (e.g. as a symlink to your `~/.bashrc` or to `/path/to/some/your/precious/data`) before you run your program. –  Nov 05 '20 at 15:41
  • @user414777 you should post that as an answer really. – Marco Bonelli Nov 05 '20 at 15:47
  • @user414777 even if I change the directory, still I obtain the same error. – Francesco Nov 05 '20 at 15:51
  • @WilliamPursell so I can not solve it? – Francesco Nov 05 '20 at 15:52
  • @FrancescoLucianò which directories have you tried? – Marco Bonelli Nov 05 '20 at 15:54
  • @MarcoBonelli `/etc/`, `/home/myusername/`, `/usr/bin` – Francesco Nov 05 '20 at 15:56
  • That warning is given for basically any instance of `fopen`, you cannot really avoid it. It's just stating the obvious: opening a file is, by definition, a race condition (between your program and any other program on the same system). That's it. – Marco Bonelli Nov 05 '20 at 16:03

1 Answers1

0

As it says, in theory, if you are using a file in a constant location, one may hijack this file and use your exe permissions to access something that he cannot. Wouldn't say it is a great risk, as it assumes the attacker already has some level of control over your system, but yeah, probaly a vulnerability.

Solution: if you need just a temporary file use tmpfile. Temp files are supported on OS level, they will not exist before open and after close, you cannot really redirect them.

FILE *aFile = tmpfile();
Yuri Nudelman
  • 2,874
  • 2
  • 17
  • 24
  • Thanks for your answer, but this do not completely solve my problem. The `tmpfile()` function triggers another issue in the report (`(tmpfile) tmpfile: Function tmpfile() has a security flaw on some systems (e.g., older System V systems) (CWE-377).`), so I still have a warning and/or potential vulnerabilty – Francesco Nov 05 '20 at 16:14
  • 6
    @FrancescoLucianò you will lose your mind looking at all the warnings produced by FlawFinder. You will not be able to eliminate all of them. They are either just stating the obvious or reporting all kinds of nonsensical "possible" vulnerabilities. Whether or not those are real problems is up to ***you*** to figure out, based on the intended usage of your program. – Marco Bonelli Nov 05 '20 at 16:18
  • 1
    Well you can always use fmemopen to create the file in memory only, but is it worth it? Using tmpfile is an absolutely valid way to work with temporary files. – Yuri Nudelman Nov 05 '20 at 16:40