3.1.2 release did not go through

[tiganov]

The readme was updated to 3.1.2, but the release did not succeed via Actions.

[johspaeth]

The readme was updated to 3.1.2, but the release did not succeed via Actions.

Thanks for letting me know, the GitHub action currently gets an exception

status: 422 Unprocessable Entity
    at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed (ArtifactTransportListener.java:52)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run (BasicRepositoryConnector.java:369)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.put (BasicRepositoryConnector.java:288)

The same occurs locally on my machine and I have not yet found a workaround.
Can you build from sources?

[tiganov]

Yes, I think I can build from sources (if I clone the repo and run mvn clean install -DskipTests).

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for SPDS 3.1.2:
[INFO]
[INFO] SPDS ............................................... SUCCESS [  1.386 s]
[INFO] WPDS ............................................... SUCCESS [  4.907 s]
[INFO] synchronizedPDS .................................... SUCCESS [  2.375 s]
[INFO] testCore ........................................... SUCCESS [  4.692 s]
[INFO] boomerangScope ..................................... SUCCESS [  2.643 s]
[INFO] boomerangPDS ....................................... SUCCESS [  6.351 s]
[INFO] idealPDS ........................................... SUCCESS [  3.271 s]
[INFO] boomerangScope-WALA ................................ SUCCESS [  2.692 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  28.427 s
[INFO] Finished at: 2021-06-06T14:21:11+03:00
[INFO] ------------------------------------------------------------------------

[tiganov]

@johspaeth When will 3.1.2 be released? I can't currently use the flow-sensitive static field strategy because it is broken in 3.1.1 (fixed in this commit). I'm also having an issue with the PathTrackingBoomerang taking a really long time for certain cases, even for really simple programs, but I'm not sure if 3.1.2 will fix that.

[johspaeth]

@tiganov
Unfortunately, I couldn't yet work out the issue above neither locally nor via GitHub Actions. Can't give an estimate on when this is fixed. Working with a local build - even if sub-optimal - doesn't work for you?

I'm also having an issue with the PathTrackingBoomerang taking a really long time for certain cases, even for really simple programs, but I'm not sure if 3.1.2 will fix that.

Do you have a minimal (Java) program for reproducing the case? No changes have been made in 3.1.2 regarding PathTrackingBoomerang.

[tiganov]

Working with a local build - even if sub-optimal - doesn't work for you?

I could pull a local build into SWAN, but I wouldn't want to push any code that depends on that.

Do you have a minimal (Java) program for reproducing the case?

I've modified boomerangPDS/src/main/java/boomerang/example/ExampleMain1.java and boomerangPDS/src/main/java/boomerang/example/BoomerangExampleTarget1.java (at the end of this post).

My Java example comes from this Swift example.

  var strings = [String]();
  strings.append(source());
  sink(sunk: strings[0]);
  sink(sunk: strings[0]);
  sink(sunk: strings[0]);
  sink(sunk: strings[0]);

I use a forward query on the result of source().

If I remove one of the sink(sunk: strings[0]);, then execution is quick. Otherwise, I'm not sure if it ever finishes executing. It seems that the DataFlowPathWeights (not edges) grow bigger and bigger. The call PDS stack gets very deep with many addWeightForTransitions and onOutTransitionAdded calls.

However, that example is a bit misleading because the actual Swift Intermediate Language (SIL) code will look different. I've tried to recreate its semantics with this Java example (modified BoomerangExampleTarget1.java). Just like in the Swift example, if I remove one of the StringPointer/getter/sink blocks, it will execute quickly.

public class BoomerangExampleTarget1 {
  public static void main(String... args) {

    // The analysis triggers a query for the following variable
    String tainted = customSource();

    FakeStringArray arr = new FakeStringArray();
    arr.append(tainted);

    StringPointer p1 = new StringPointer();
    arr.getter(p1);
    customSink(p1.value);

    StringPointer p2 = new StringPointer();
    arr.getter(p2);
    customSink(p2.value);

    StringPointer p3 = new StringPointer();
    arr.getter(p3);
    customSink(p3.value);

    StringPointer p4 = new StringPointer();
    arr.getter(p4);
    customSink(p4.value);

  }

  private static String customSource() { return "I'm tainted"; }
  private static void customSink(String sunk) { System.out.println(sunk); }

  public static class StringPointer {
    public String value;
  }

  public static class FakeStringArray {
    public String element;
    public void append(String s) { element = s; }
    public void getter(StringPointer p) { p.value = element; }
  }
}

I've also changed createAnalysisTransformer() in ExampleMain1.java.

private static Transformer createAnalysisTransformer() {
    return new SceneTransformer() {
      protected void internalTransform(
          String phaseName, @SuppressWarnings("rawtypes") Map options) {
        SootCallGraph sootCallGraph = new SootCallGraph();
        AnalysisScope scope =
            new AnalysisScope(sootCallGraph) {
              @Override
              protected Collection<? extends Query> generate(Edge cfgEdge) {
                Statement statement = cfgEdge.getStart();
                if (statement.toString().contains("customSource") && statement.containsInvokeExpr()) {
                  Val arg = statement.getLeftOp();
                  return Collections.singleton(new ForwardQuery(cfgEdge,
                          new AllocVal(arg, statement, arg)));
                }
                return Collections.emptySet();
              }
            };
        
        PathTrackingBoomerang solver =
            new PathTrackingBoomerang(
                sootCallGraph, SootDataFlowScope.make(Scene.v()), new DefaultBoomerangOptions() {
              @Override
              public int analysisTimeoutMS() {
                return 10000;
              }
            }) {};

        Collection<Query> seeds = scope.computeSeeds();
        for (Query query : seeds) {
          System.out.println("Solving query: " + query);

          ForwardBoomerangResults<DataFlowPathWeight> res = solver.solve((ForwardQuery) query);

          if (res.isTimedout()) {
            throw new RuntimeException("Timed out");
          }

          res.asStatementValWeightTable().cellSet().forEach(s -> {
            Method m = s.getRowKey().getMethod();
            if (m.getName().contains("customSink") && m.getParameterLocals().contains(s.getColumnKey())) {
              System.out.println("\n ----- PATH: ");
              s.getValue().getAllStatements().forEach(stmt -> {
                System.out.println("        " + stmt.stmt().getStart().toString());
              });
            }
          });
        }
      }
    };
  }

[johspaeth]

Thanks for the code for reproducing, that's an interesting case.

I.e. the timeout only occurs when we have more than 3 blocks of

    StringPointer p1 = new StringPointer();
    arr.getter(p1);
    customSink(p1.value);

?

If we only have 1,2 or 3 such blocks, the analysis terminates quickly? I cannot yet see a logical explanation for that behavior.

[tiganov]

That's right. I've tried it with 1,2,3,4, and 5 blocks, and more than 3 will cause a timeout but 3 or less will swiftly execute. The difference between 1 and 3 is still noticeable.