Missed sink in loop in called function

[draftyfrog]

Pysa Bug

Pre-submission checklist
[x] I've checked the list of common issues and mine does not appear

Bug description
Please consider the following program source code

class MyClass:
    def my_function(self):
        self.function1("", "", self.source()) # NOT reported by pysa
        self.sink(self.source()) # Correctly reported by pysa

    def function1(self, arg1: str, arg2: str, arg3: str):
        for i in range(10):  
            arg0 = arg1 
            self.sink(arg3) # NOT reported by pysa
            arg1 = arg2
            arg2 = self.function2(arg1)  

    def function2(self, arg0: str):
        return arg0

    def source(self):
        return "Secret"

    def sink(self, param: str):
        pass

The call to sink in function1 is not detected by pysa, and all the statements around it seem to be responsible. If we for example remove one of the unnecessary assignments, replace the call to function2 with just another assignment or move all the statements out of the loop, pysa correctly reports the taint leak.

In my sources_sinks.pysa I declare source and sink as taint sources and sinks respectively (this config works as we can see with the detected leak in my_function):

def test.MyClass.source() -> TaintSource[TestSource]: ...
def test.MyClass.sink(param: TaintSink[TestSink]): ...

I call pysa via pyre analyze --save-results-to ./results/ --infer-self-tito and I'm using version 0.9.23

[arthaud]

Hi @draftyfrog, sorry for the late answer, I didn't get notified about the issue.

The problem is due to type checking. I see the following error:

Pyre gave up inferring types for some variables because function `MyClass.function1` was too complex. Please simplify the function by factoring out some if-statements or for-loops.

Because the type checker fails on the whole function, it doesn't infer that self has type MyClass and therefore, self.sink is an unknown call, instead of being resolved to MyClass.sink.

As a workaround, this can be fixed by adding a type annotation to arg0, i.e arg0: str = arg1.
The deeper problem is in the main algorithm of the type checker, that uses abstract interpretation.
Fortunately, the is likely to be fixed soon, once Pysa starts using our new type checker Pyrefly (it will be announced soon).

Also note that in practice, this isn't a problem as long as your code passes type checking.

[draftyfrog]

Thanks for the explanation! Indeed, when I add the type annotation to arg0:str = arg1, pysa correctly reports the issue.
Interestingly, any additional type annotation in function1 seems to do the trick: arg1: str = arg2, arg2: str = ..., adding the return type to function2 def function2(self, arg0: str) -> str: has the same effect, pysa reports the issue.