<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 9/20/19 1:59 PM, Gavin Cui wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DBAE6769-5396-4634-9148-D140CF102B53@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="">Thanks for the help,</div>
<div class="">@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:</div>
<div class=""><br class="">
</div>
<div class="">config_from_file = parse_config_file() // taint
source</div>
<div class="">/* the tainted value may infect other variables
(should_enc) in some paths*/</div>
<div class="">if (use_default) {</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>config
= default_config // in this path, taint does not flow to
condition expr</div>
<div class="">}</div>
<div class="">else {</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>config
= config_from_file // taint flow to config</div>
<div class="">}</div>
<div class="">should_enc = (config.secure_level > 10) // taint
flow to should_enc</div>
<div class="">if (should_enc) { // branch is tainted in one path</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>do_encrypt(data)
// the execution of sensitive function is affected by taint
source in one path.</div>
<div class="">}</div>
<div class="">else { // this block is also tainted if use_default</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...</div>
<div class="">} // after exiting the block, everything should be
fine.</div>
<div class="">other_sensitive_func(); // not affected by taint
source in both paths</div>
</blockquote>
<br>
What about the following test cases?<br>
<br>
// (1):<br>
<br>
if (config.secure_level > 10) // not a control flow dependency
of the sensitive call!<br>
should_enc = true; // concrete value, not tainted!<br>
else<br>
should_enc = false; // concrete value, not tainted!<br>
if (should_enc) // concrete true or false, not tainted!<br>
do_encrypt(data);<br>
<br>
// (2):<br>
<br>
if (config.secure_level > 10)<br>
do_encrypt(data);<br>
else<br>
do_encrypt(data); // encryption is done on both branches anyway!<br>
<br>
// (3):<br>
<br>
if (config.secure_level > 10) // tainted symbol collapsed to a
constant!<br>
do_unrelated_stuff();<br>
if (config.secure_level > 10) // concrete true or false, not
tainted!<br>
do_encrypt(data);<br>
<br>
Basically i want to know not only about the bug you're trying to
find, but more about what your users are and what quality
requirements do you have.<br>
<br>
If you're writing a tool for yourself (eg., for doing a security
audit of a specific project), you can get away with a high false
positive rate. If you're making a tool for automatic code review
that'll point out potential security breaches to other developers as
they write new code, you'll have to make sure your tool doesn't
prevent the developers from easily writing the secure code that they
need to write, so a high false positive rate is unacceptable, and
you'll need to formulate precise rules in an as simple manner as
possible instead of relying on an unpredictable emergent behavior.
If you're really paranoid about security, you should go for a
verification tool that has high false positive rate and zero false
negatives. If you can make your own APIs, you should probably make
safer APIs that are either taking care of the security issues on the
type system level or generally make life easier for static analysis.<br>
<br>
Also Static Analyzer is tweaked for finding very pinpointed bugs
that can be proven by looking at a specific execution path without
taking into account the surrounding code that didn't get executed on
the current path. Your question seems to be focused on the
difference in behavior between the situations in which the branch is
taken or not, which is already too much of a global reasoning.<br>
<br>
<blockquote type="cite"
cite="mid:DBAE6769-5396-4634-9148-D140CF102B53@gmail.com">
<div class="">@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:</div>
<div class="">-in checkPreStmt(const CallExpr *CE, CheckerContext
&C) , check if the statement is a sensitive function call</div>
<div class="">-get cfg from C->ExplodedNode()->getCFG, and
create cdc = ControlDependencyCalculator(cfg)</div>
<div class="">-get dependent blocks from
cdc->getControlDependencies(C->ExplodedNode()->getCFGBlock())</div>
<div class="">-for each returned block, check if the condition
expr is tainted in current state. <br>
</div>
</blockquote>
<br>
The condition expression is not an active expression at this point,
so it doesn't have a value at all in the current state. You'll have
to go back in time, to the moment of time where the condition was
evaluated, in order to understand what its value was. Which is why
your original approach was better.<br>
<br>
You may be able to store branch conditions in the program state for
later use in an Environment-like map, i.e. '(Expr *, LocationContext
*) -> SVal', clean it up as location contexts are destroyed, and
get them overwritten when looping around in a loop.<br>
<br>
Or you can emit a bug on every sensitive function and attach a bug
visitor to it that will suppress the report when it's unable to find
the tainted dependency. This is probably the easiest way to
implement this right now - not sure about performance though.<br>
<br>
<blockquote type="cite"
cite="mid:DBAE6769-5396-4634-9148-D140CF102B53@gmail.com"><br>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Gavin</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 20, 2019, at 4:00 PM, Kristóf Umann <<a
href="mailto:dkszelethus@gmail.com" class=""
moz-do-not-send="true">dkszelethus@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class=""><br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 20 Sep 2019 at
21:35, Artem Dergachev <<a
href="mailto:noqnoqneo@gmail.com" class=""
moz-do-not-send="true">noqnoqneo@gmail.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class=""> @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.<br class="">
<br class="">
@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).<br
class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I guess so. I'm seeing a couple things to
keep track of (inlined function calls to name one),
but nothing too bad.</div>
<div class=""><br class="">
</div>
<div class="">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-<font class=""
face="monospace">noexcept</font><font class=""
face="arial, sans-serif"> function call have an edge
to the exit block if we take exceptions into
account?</font></div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class="">
<div
class="gmail-m_-4944449558918191960moz-cite-prefix">On
9/20/19 10:46 AM, Kristóf Umann via cfe-dev wrote:<br
class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">+ Artem because he knows
everything about the analyzer and symbolic
execution, + Balázs because he is currently
working on TaintChecker.
<div class=""><br class="">
</div>
<div class="">My first instinct here would be
to combine pathsensitive analysis with
control flow analysis. In the header file <font
class="" face="monospace">clang/include/clang/Analysis/Analyses/Dominators.h</font>
you will find the class <font class=""
face="monospace">ControlDependencyCalculator</font>.
You could calculate the control dependencies
of the block in which <font class=""
face="monospace">sensitive_func() </font>is
called (you can retrieve that through the
current <font class="" face="monospace">ExplodedNode</font>)
and find that the <font class=""
face="monospace">CFGBlock</font> whose <font
class="" face="monospace">getLastCondition()</font>
is <font class="" face="monospace">value
< xxx</font> is in fact a control
dependency. Then, you could, in theory,
check whether parts of this expression is
tainted.</div>
<div class=""><br class="">
</div>
<div class="">Artem, do you think this makes
any sense?</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 20
Sep 2019 at 16:10, Gavin Cui via cfe-dev
<<a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" class=""
moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hello
all,<br class="">
I want to check if a tainted value can
affect the control flow of some sensitive
functions. For example:<br class="">
<br class="">
value = taint_source()<br class="">
if (value < xxx) {<br class="">
sensitive_func()<br class="">
}<br class="">
<br class="">
The taint propagation in clang static
analyzer fit part of my need. One approach I
can think of is: <br class="">
Whenever I encounter a branch condition
(register checkBranchCondition() call back),
I will push a tag(tainted or not) to a
taintStack variable in ProgramState.<br
class="">
After the branch block closed, I will pop
one tag. <br class="">
If sensitive_function() get encountered, I
will check all the tags in taintStack to see
if any of them is tainted.<br class="">
<br class="">
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?<br class="">
<br class="">
Any suggestions would be appreciated.<br
class="">
<br class="">
Thank you,<br class="">
Gavin<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org"
target="_blank" class=""
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br
class="">
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank" class=""
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br
class="">
</blockquote>
</div>
</div>
<br class="">
<fieldset
class="gmail-m_-4944449558918191960mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-4944449558918191960moz-quote-pre">_______________________________________________
cfe-dev mailing list
<a class="gmail-m_-4944449558918191960moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
<a class="gmail-m_-4944449558918191960moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br class="">
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>