-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with handling detections of sub-rules #8
Comments
Another problem related to this mechanism with TraceSymbols:
This behaviour seems to be a bug more than a limitation of the TraceSymbol mechanism. If a depending detection rule is added to the method of a rule (and not a parameter), the TraceSymbol filtering should be completely bypassed. It can be done from now on using In the future, it may be even better to have a way to link these two function calls using |
Another problem where TraceSymbols work, but where we are too limited by the scope of search:
|
Context
When writing a rule using the
DetectionRuleBuilder
, one can use theshouldBeDetectedAs
function to resolve directly a specific parameter, and one can use theaddDependingDetectionRules
function to resolve a parameter with another rule (for example when this method is a method invocation, using a depending detection rule allows to resolve a specific parameter of this function call).This issue is about the behaviour of the static analysis when resolving the following case (written here in Python, but the issue is also valid for Java):
To do so, one should write a rule R1 to detect
func1
, with a depending detection rule R2 on its parameter to detectfunc2
. Then R2 resolves the content of the parameter offunc2
, here "RSA", usingshouldBeDetectedAs
.Currently (at main 0cd69ef79984b2c91bd0e06b07fb5488a2ea6473 and feature/python-support f5cdfe445fd4e5ea87ba6d0e886b84f02ad0c7cd), this type of resolution implies a complex mechanism that is quite limited.
Current mechanism
The detection process starts by visiting all method invocations (and class instantiations). For each invocation, a detection executive is started for each registered "entry" rule: R1 in our case.
We will therefore look for all functions
func1
in the current scope. Once we have a match, the functionanalyseExpression
is called, and there are several cases:DetectableParameter
(coming fromshouldBeDetectedAs
), meaning that we want to resolve a parameter of the detected function call, we name the subsequent handling logic case of a detectable parameter.DetectableParameter
despite having parameters, it is probably a rule written for an intermediary function that does directly not carry information, but may have depending detections rules. We name the subsequent handling logic case of an intermediary parameter.In our example,
func1
brings not information other than through the content of its parameterfunc2("RSA")
. R1 is written as a rule with a depending detection rule R2 on its parameter, but without ashouldBeDetectedAs
part.We therefore enter the case of an intermediary parameter in the function
analyseExpression
.Case of an intermediary parameter
In this case, depending on the implementation, we have the choice to call
onDetectedDependingParameter
with two possible scopes:EXPRESSION
orENCLOSED_METHOD
. Basically, it will resolve the depending detection rule(s) by visiting either the parameter tree (func2("RSA")
in our case) or the enclosing method of this parameter (the function in which this expression is).In our example, we want to resolve this particular
func2("RSA")
call, so using the EXPRESSION scope makes sense.func2("RSA")
will be the only match of rule R2, which will correctly resolve the parameter content "RSA". This resolution is will go through the case of a detectable parameter explained below. This example worked as expected!Case of a detectable parameter
Let's look at a new example:
In this example,
func1
still does not bring information other than through the content of its parametervar = ec.ECDSA("SHA_256")
.R1' (to detect
func1
) is written as a rule with a depending detection rule R2' for its parameter, but has now also ashouldBeDetectedAs
part aiming at resolving the value "ECDSA" (name of the function used as parameter offunc1
).R2' (to detect
ec.ECDSA
) (withshouldBeDetectedAs
), resolves the content of the parameter ofec.ECDSA
, here "SHA_256", usingshouldBeDetectedAs
.Upon detection of
func1
with rule R1', because the parameter offunc1
is a detectable parameter, we enter the case of a detectable parameter.Let's say that resolution works as expected in this case ("ECDSA" has been detected). Then,
analyseExpression
will callonReceivingNewDetection
, that will call the following rules (here R2') withfollowNextRules
. For now, there is no choice of scope, so it is necessarily the scope of the enclosing method. This means that it will look for a call ofECDSA
in the entire scope of the method: how to make sure that this call is linked to our parametervar
offunc1
?To do so, the current implementation uses a TraceSymbol.
onReceivingNewDetection
will obtain the symbol of the parameter offunc1
, hereSYMBOL, var
, and will pass it as an argument tofollowNextRules
.Then, all function calls in the scope of the enclosing method will be matched against R2', which will detect the two
ECDSA
function calls, one assigned tovar
and the other toother_var
. Using the previous TraceSymbol, we filter the findings to only keep the finding linked tovar
.In our case, this works and this example will correctly resolve "SHA_256".
A better approach
Could a better and simpler approach be found and replace this complex mechanism (currently based on limited TraceSymbols and varying scopes of resolution)?
The text was updated successfully, but these errors were encountered: