How to identify the anti-standard TOCTOU? How to avoid/remove it?

Asked

Viewed 429 times

17

I was reading an answer about transform vectors into lists in Java, when we comment the AIR directs me to the source codes of JDK9. There in the sources, I have the following comment:

ListN(E... input) {
  // copy and check manually to avoid TOCTOU

  @SuppressWarnings("unchecked")
  E[] tmp = (E[])new Object[input.length]; // implicit nullcheck of input
  for (int i = 0; i < input.length; i++) {
    tmp[i] = Objects.requireNonNull(input[i]);
  }
  this.elements = tmp;
}

So, I came to the question "what is TOCTOU"? The reference you have here at Sopt is that answer (for the query ?q=toctou in 2019-02-04 before 9h GMT-3).

The @Anderson Carlos Woss pointed out the meaning: time of check/time of use (time of check to time of use, of the English original). It happens when you check the data at a time and, when using the data for real, the system is in a different state and therefore makes the check invalid.

So I kept asking myself:

  • how to identify that I fell into this anti-pattern?
  • has some pattern to avoid falling into this anti-pattern?
  • if I take a code that I have identified that is with TOCTOU, it has some algorithm so that I change the code so as to remove it?
  • 2

    I also had this question when I read the source code, and I was going to ask this question here, but you were faster :)

  • 2

    Hahahaha! Quickness in the trigger =D EU almost I ask you about it, but then I realized I was running too far from the original answer

  • Practically duplicate: https://answall.com/q/159342/101

  • @Maniero de facto. TOCTOU is a racing condition (think a specific type of). Identifying a TOCTOU, then, is identifying race conditions that change the internal value of a program after checking its status. Here, I expected to see a response talking about IPC and multi-threaded; and for IPC, I expected a response aimed at dealing on the remote side with atomic mode verification and alteration of the internal value. I will see with more affection this issue of race condition to be able to close this issue here when the Bounty is over

  • If you are interested I can put an example that just occurred in commercial code whose object is the intercommunication of variables between scopes distributed between different Appdomains?

1 answer

14

TOCTOU is acronym for Time Thef CHeck to Time Thef Uif. It is a bug of the kind running condition caused between checking a condition and using the results of the check.

How many your questions:

How to identify that I fell into this anti-pattern?

Most codes that access the low-level file system are committed to TOCTOU and some are vulnerable to attack.

Code in C seemingly innocent but vulnerable to TOCTOU:

// access retorna 0 em caso de sucesso
if(!access(file, W_OK)) {
   f = fopen(file, "wb+");
   write_to_file(f);
} else {
   fprintf(stderr, "Permissão negada ao abrir o arquivo %s.\n", file);
}

How to explore command line TOCTOU.

$ touch dummy; ln –s dummy pointer
$ rm pointer; ln –s /etc/passwd pointer

In this case it is a fictional attack from the command line to obtain the local credentials of a local file. This is not so worrying, in corporate networks this is a problem, but in the case of a CGI written at low level and that makes access to the file system can compromise an entire server.

Have some pattern to avoid falling into this anti-pattern?

Avoid making access to system files at a low level. Instead of using a check engine use exception handling and if you have in Windows or Mono environment use File Handlers to access the file system.

In Java (or other high-level language) the vulnerability to TOCTOU cannot be exploited by third parties, but it can freeze an application (deadlock) as in the case of vectors if the function in question is accessed by two or more threads. Then in multithreading code use lock and syncrhonize on the stretches where there is competition, and instead of checking a condition, force an error handling.

Avoid things like:

if (file is null) {
  // Menssagem de erro
} else {
  // realize acões com o arquivo
}

And prefer:

try
  file.Open("")
  // realize ações com o arquivo
  ...
catch (){
  // Mensagem de erro
}

If I get a code I’ve identified that’s with TOCTOU, there’s some algorithm for me to change the code so as to remove it?

Turn checking into an error handling and apply synchronization mechanisms that language offers.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.