Module boto3 - Taint Propagation Issue about pyre-check

[giusepperaffa]

Hi @arthaud,

Thank you very much for your help. I have now solved the problem, and this issue can be closed. A few details for the future.

Analysis of the call graph
The are two ways of printing the call graph, which rely on the functions pyre_dump() and pyre_dump_call_graph() mentioned in the Pysa documentation here. Note: in my case, neither of them generates the above-mentioned call-graph.json file in the results directory, despite executing Pysa with the --save-results-to option. This might be due to the particular version of Pysa that I am using (installed in March 2022).

Case 1 - pyre_dump()
This is the function that provides the most verbose output. I simply called it within the function body as shown below:

from mypy_boto3_s3 import S3ServiceResource
import boto3

def onHTTPPostEvent(event, context) -> None:
    pyre_dump()
    s3: S3ServiceResource = boto3.resource('s3')
    bucket = s3.Bucket(event['body'])
    bucket.objects.all().delete()

Case 2 - pyre_dump_call_graph()
This is the function that provides the least verbose output. I simply called it within the function body as shown below:

from mypy_boto3_s3 import S3ServiceResource
import boto3

def onHTTPPostEvent(event, context) -> None:
    pyre_dump_call_graph()
    s3: S3ServiceResource = boto3.resource('s3')
    bucket = s3.Bucket(event['body'])
    bucket.objects.all().delete()

Model for the source
The analysis of the call graph was enough to understand how to propagate the taint. This was the missing model:

def mypy_boto3_s3.service_resource.S3ServiceResource.Bucket(self, name: TaintInTaintOut[LocalReturn]): ...

Model for the sink
The model for the sink was also corrected, as suggested above. The following models are both considered valid by Pysa:

• def mypy_boto3_s3.service_resource.ObjectSummary.delete(self: TaintSink[Test]): ...
• def mypy_boto3_s3.service_resource.BucketObjectsCollection.all(self: TaintSink[Test]): ...

However, it is the model for BucketObjectsCollection that allows identifying the expected sink. Again, this can be understood by looking at the call graph (Pysa will not complain if the model for ObjectSummary is used as well, but this is not the model that allows detecting the expected sink).

[arthaud]

Hi @giusepperaffa,

You are definitely on the right track. The problem is that bucket is not tainted when it should be.
The first thing I would do is check the call graph for onHTTPPostEvent. This can be found in the call-graph.json file in the result directory (use --save-results-to).
Then, depending on what that line bucket = s3.Bucket(event['body']) calls, I would check the model for the callee in the taint-output.json file. This can be done with the model explorer: https://pyre-check.org/docs/pysa-explore/
If you want me to take a look, please send me all the files in the result directory (--save-results-to) as an archive/zip/whatever.

Note that there is another problem that you will hit next. Those models:

def mypy_boto3_s3.service_resource.BucketObjectsCollection.all() -> TaintSink[Test]: ...
def mypy_boto3_s3.service_resource.ObjectSummary.delete() -> TaintSink[Test]: ...

You are marking the result of a function as a sink (something we call "return sinks"). This will only impact the analysis of the body of delete and all itself:

# within mypy_boto3_s3.service_resource
class ObjectSummary:
  def delete(self):
     return something # here the return is considered a sink

This is not what you want. What you want is to mark self as flowing into a sink:

def mypy_boto3_s3.service_resource.ObjectSummary.delete(self: TaintSink[Test]): ...

[arthaud]

Note: in my case, neither of them generates the above-mentioned call-graph.json file in the results directory, despite executing Pysa with the --save-results-to option. This might be due to the particular version of Pysa that I am using (installed in March 2022).

Just for clarification: this must be because this is a somewhat new feature. The latest pyre-check package might not have it.