C++: Prepare cpp/cleartext-transmission for IR-based use-use dataflow

[MathiasVP]

This is a rather large change. Since we now have use-use flow we don't need to search backwards from a use of a variable with a name that implies that it's sensitive. Instead, we can just mark that variable use as a source, and dataflow will continue from there.

This means that it requires a bit more work to block taint if there's some evidence somewhere for the data being encrypted. To see why, consider this example:

char password1[256], password2[256];
encrypt_to_buffer(password1, password2); // proof that `password2` is in fact encrypted
char* x = password2;
send(val(), x, strlen(password2), val()); // GOOD: password is encrypted

We can now just mark the use of password2 on line 3 as a source, and dataflow will end up as an argument to x. However, since we now start on line 3, the encryption isn't actually part of the dataflow path anymore.

To fix this, I've added two additional taint-tracking configurations: One that checks the source (i.e., password2 on line 3 in the example above) flows to some encryption, and one that checks if encrypted data flows to the sink (i.e., the send argument on line 4).

There are a couple of new FPs/missing flows. I think we can tweak the source/sinks to fix these, but this fixes most of the regressions, though.

[geoffw0]

Looks like a fair improvement, in addition to preparing for use-use flow. The three newly incorrect test results appear to come from taint being blocked by operations of the form buffer[255] = 0, which it probably shouldn't be.

Its nice to see three previously [NOT DETECTED] results are now detected.

[MathiasVP]

Looks like a fair improvement, in addition to preparing for use-use flow. The three newly incorrect test results appear to come from taint being blocked by operations of the form buffer[255] = 0, which it probably shouldn't be.

Indeed, I also noticed this. This seems like a new bug in dataflow that should be fixed. I've created https://github.com/github/codeql-c-team/issues/1294 for this. I don't think this should block this PR, however.

[geoffw0]

👍