[cfe-dev] Clang Static Analyzer conditional terminating call back

[Gavin Cui via cfe-dev]

Thanks for the help,
@Artem, I think the taint propagation is necessary for my problem. I want to analyze if an untrust input can somehow affect the control flow of some sensitive function (tainted source determine whether a sensitive function get executed or not). The untrusted input can taint other variables and eventually taint the branch condition expression. It still needs to be path sensitive. For example:

config_from_file = parse_config_file() // taint source
/* the tainted value may infect other variables (should_enc) in some paths*/
if (use_default) {
	config = default_config // in this path, taint does not flow to condition expr
}
else {
	config = config_from_file // taint flow to config
}
should_enc = (config.secure_level > 10) // taint flow to should_enc
if (should_enc) { // branch is tainted in one path
	do_encrypt(data) // the execution of sensitive function is affected by taint source in one path.
}
else {  // this block is also tainted if use_default
	...
}  // after exiting the block, everything should be fine.
other_sensitive_func(); // not affected by taint source in both paths

@Kristof, I think ControlDependencyCalculator might do the trick. I do not need to use a stack structure to track the blocks myself. Here's what I might do:
-in checkPreStmt(const CallExpr *CE, CheckerContext &C) , check if the statement is a sensitive function call
-get cfg from C->ExplodedNode()->getCFG, and create cdc = ControlDependencyCalculator(cfg)
-get dependent blocks from cdc->getControlDependencies(C->ExplodedNode()->getCFGBlock())
-for each returned block, check if the condition expr is tainted in current state. 

If ControlDependencyCalculator can correctly calculate the dependence, I think the above steps should work. I am not sure if the getLastCondition()s return from dependency blocks overlaps, but it will not affect the result.

Gavin

> On Sep 20, 2019, at 4:00 PM, Kristóf Umann <dkszelethus at gmail.com> wrote:
> 
> 
> 
> On Fri, 20 Sep 2019 at 21:35, Artem Dergachev <noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>> wrote:
> @Gavin: I'm worried that you're choosing a wrong strategy here. Branches with tainted conditions can be used for sanitizing the input, but it sounds like you want to ban them rather than promote them. That said, i can't figure out what's the right solution for you unless i understand the original problem that you're trying to solve.
> 
> @Kristof: Do you think you can implement a checkBeginControlDependentSection / checkEndControlDependentSection callback pair on top of your control dependency tracking mechanisms, so that they behaved intuitively and always perfectly paired each other, even in the more complicated cases like for-loops and Duff's devices? (there's no indication so far that we really need them - scope contexts are much more valuable and might actually be helpful here as well - but i'm kinda curious).
> 
> I guess so. I'm seeing a couple things to keep track of (inlined function calls to name one), but nothing too bad.
> 
> It raises (haha) a question about exceptions, if we ever end up supporting them, what happens if an exception is raised? Also, just came to my mind, should any block with a non-noexcept function call have an edge to the exit block if we take exceptions into account?
>  
> On 9/20/19 10:46 AM, Kristóf Umann via cfe-dev wrote:
>> + Artem because he knows everything about the analyzer and symbolic execution, + Balázs because he is currently working on TaintChecker.
>> 
>> My first instinct here would be to combine pathsensitive analysis with control flow analysis. In the header file clang/include/clang/Analysis/Analyses/Dominators.h you will find the class ControlDependencyCalculator. You could calculate the control dependencies of the block in which sensitive_func() is called (you can retrieve that through the current ExplodedNode) and find that the CFGBlock whose getLastCondition() is value < xxx is in fact a control dependency. Then, you could, in theory, check whether parts of this expression is tainted.
>> 
>> Artem, do you think this makes any sense?
>> 
>> On Fri, 20 Sep 2019 at 16:10, Gavin Cui via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> Hello all,
>> I want to check if a tainted value can affect the control flow of some sensitive functions. For example:
>> 
>> value = taint_source()
>> if (value < xxx) {
>>         sensitive_func()
>> }
>> 
>> The taint propagation in clang static analyzer fit part of my need. One approach I can think of is: 
>> Whenever I encounter a branch condition (register checkBranchCondition() call back), I will push a tag(tainted or not) to a taintStack variable in ProgramState.
>> After the branch block closed, I will pop one tag. 
>> If sensitive_function() get encountered, I will check all the tags in taintStack to see if any of them is tainted.
>> 
>> The problem is I did not find a callback like checkBranchCondition() which will be called every time exiting a branch block.  Then what should be a good approach for this control flow checking?
>> 
>> Any suggestions would be appreciated.
>> 
>> Thank you,
>> Gavin
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190920/bf0947d2/attachment.html>