[PATCH] Properly taint gets()

[Anna Zaks]

Keaton, 

This problem has not been fixed; we have not modified the Taint checker in a while. But I do not think that this approach is quite right.

The taint propagation rule says that if any of the inputs are tainted, then the outputs should be tainted (return value is treated as one of the outputs). This is why we have an early return in the process function. I do not think your patch differentiates between the rule in which the return value should be tainted only if the input is tainted and the case where the return value just should always be tainted. Do we not have any tests for the former?

What about adding another flag to the TaintPropagationRule, which explicitly states that the outputs should always be tainted?

Thanks!
Anna.

On Jul 1, 2013, at 5:50 PM, Keaton Mowery <kmowery at gmail.com> wrote:

> The llvm-3.2 taint engine does not properly taint the results of a gets() call.
> 
> For gets(), since none of the function arguments are tainted, ProgramStateRef GenericTaintChecker::TaintPropagationRule::process() bails out early. Most other input functions take stdin as an argument; gets() is a special case, wherein stdin is implied.
> The attached patch includes a fix for this issue and a regression test case. This fix does slightly change the semantics of TaintPropagationRule, but I think it maintains correctness.
> Note: this patch is against llvm/clang 3.2. Due to a bug, I can't use 3.3, and HEAD is too unstable for my purposes. My apologies if this bug has been fixed already!
> Also, I mistakenly submitted this patch as Bug 16475. If this is committed, could someone please close that bug? Thanks!http://llvm.org/bugs/show_bug.cgi?id=16475
> 
> Keaton Mowery
> <gets-taint.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130715/f333c6c6/attachment.html>