Java: Add taint steps for InputStream wrappers #13772

atorralba · 2023-07-19T11:00:43Z

Adds taint steps for two situations:

When an anonymous instantiation of InputStream is tainted by a variable captured in its read(bytes[]) (and similar) methods, e.g.

InputStream in = source();
InputStream wrapper = new InputStream() {
    @Override
    public int read() throws IOException {
        return 0;
    }

    @Override
    public int read(byte[] b) throws IOException {
        return in.read(b);

    }
};
sink(wrapper);

When a subtype of InputStream is instantiated with a tainted InputStream that gets assigned to a class field, e.g.

static class MyStream extends InputStream {
    private InputStream wrapped;

    MyStream(InputStream wrapped) {
        this.wrapped = wrapped;
    }

    @Override
    public int read() throws IOException {
        return 0;
    }

    @Override
    public int read(byte[] b) throws IOException {
        return wrapped.read(b);
    }
}

public static void test() {
  InputStream src = source();
  InputStream wrapper1 = new MyStream(src);
  InputStream wrapper2 = new MyStream(wrapper1);
  InputStream wrapper3 = new MyStream(wrapper2);
  sink(wrapper3);
}

Note that this doesn't overlap with TaintTrackingUtils::inputStreamWrapper, because that predicate only affects InputStreams that are not from source.

These steps surfaced some weird virtual dispatch from InputStream.read method calls to unrelated implementations. #13769 improves precision in that regard.

java/ql/lib/semmle/code/java/JDK.qll

java/ql/test/library-tests/dataflow/stream-read/A.java

java/ql/lib/semmle/code/java/JDK.qll

java/ql/lib/semmle/code/java/frameworks/InputStream.qll

aschackmull · 2023-07-21T13:12:24Z

One minor comment, otherwise this LGTM.

aschackmull · 2023-07-21T13:43:48Z

Let's see what DCA has to say!

Co-authored-by: Anders Schack-Mulligen <aschackmull@users.noreply.github.com>

Note that this has FNs in the test cases where the source is used locally in the nested classes' methods

Note that this causes FP flow in the call context test cases

Co-authored-by: Anders Schack-Mulligen <aschackmull@users.noreply.github.com>

atorralba · 2023-07-26T16:03:54Z

Spot-checking DCA results, the only changes in alerts are "duplicated" paths for pre-existing alerts that had enough fieldFlowBranchLimit to keep track of taint through constructors and fields (and so this PR adds a new edge that bypasses them, creating a new path). It's not ideal, but I don't think we have a way of avoiding it, do we?

atorralba requested a review from a team as a code owner July 19, 2023 11:00

github-actions bot added documentation Java labels Jul 19, 2023