flankerhqd / type-inference Goto Github PK

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. Create file a.java with contents
class b  { 
    public b(int x) { }
}

public class a {

    public void m() {
        b ref = new b (42)  {
        };
    }
}
2. Run binary/javai-reim a.java

What is the expected output? What do you see instead?
In infer-output/pure-metods.csv contains:
a$1.(int)
a.m()
b.b(int)

The first line should not be output.

What version of the product are you using? On what operating system?
trunk from svn on Linux (Fedora 19) x64, OpenJDK 1.7.0_51

Please provide any additional information below.
<none>

Algorithm to resolve as many conflicts as possible in the set-based solver. 

What steps will reproduce the problem?
1. Create a Java file blah.java with the following contents:
public class blah {
  int a;
  {
    a = 1;
  }
}
2. Run binary/javai-reim blah.java

What is the expected output? What do you see instead?
java.lang.Error: Reim processor threw unexpected exception when processing 
blah.java


What version of the product are you using? On what operating system?
trunk from svn. Linux (Fedora 19) OpenJDK 1.7.0_51

Please provide any additional information below.
The reason is in checkers/inference/reim/ReimVisitor.java, checkMutable calls 
TreeUtils.enclosingMethod(getCurrentPath()).
Unfortunately, getCurrentPath() will not contain a METHOD element in case of 
static and non-static block initializers. The nesting will be
EXPRESSION > BLOCK > CLASS.

==Problem==

In order to have more straightforward type errors, we disallowed SECRET 
parameter for non-private static methods. Suppose we have the following static 
method:

static String escape(String url) {
  // some operations on url
  return url;
}

And we have the following constraint for newUrl1 = StringUtil.escape(oldUrl1):

oldUrl1 <: newUrl1 |> url;

If both oldUrl1 and newUrl are inferred as Secret, then url becomes {Secret, 
Poly}. 

In another statement like newUrl2 = StringUrl.escape(oldUrl2) where oldUrl2 is 
inferred as Secret while newUrl2 as Tainted. Clearly, we have a flow violation, 
but this won't be caught here, because `url` would become {Secret} and this 
above constraint still holds. Eventually, this type error would be caught at 
somewhere, but that is not good. 

Therefore, we disallowed parameters of non-private static method to be Secret. 
However, it leads to another problem when the parameter can be Secret. For 
example, 

public static bool find(String id) {
  @Secret String searchId = ...;
  if (id.equals(searchId) {
    ...
  }
}

Where disallowing `id` to be Secret would lead to an unnecessary type error. 

==Solution==

We should disallow such parameters to be Secret when we solve the constraints. 

In parameter-httpsplitting configuration, there is a type error 

EQU-271653: JDBCDatabaseExport.java:133(340012):VAR_out{@Poly}  == 
JDBCDatabaseExport.java:139(340043):EXP_out{@Secret}

in snipsnap. 

It was due to the constant "name" used in both JDBCDatabaseExport.java:56:DBSER 
and SnipCopyServlet.java:104:request. It transmitted unnecessary flow. 

1. Configure analysis for Android. That is, restrict THIS of
non-private methods of app classes extending/implementing
Android library classes/interfaces, to {POLY,TAINTED}. In other
words, disallow SECRET THIS for those methods. We start with
classes/interfaces Activity, Service, LocationListener and
later add all Android library classes.

This is necessary because of the lack of "main". That is, the
Activity/Service object is created implicitly, not explicitly
and the OS issues callbacks to its methods. Thus, there is
an implicit "x = new XyzActivity()" which amounts to implicit
constraints x <: x |> THIS_m1 and x <: x |> THIS_m2. By setting
the above requirement on THIS_m1 and THIS_m2, we prevent having
one THIS Secret and another THIS Tainted, and thus guarantee that
the above implicit constraints always hold.


2. Bug in dereferencing a Secret Char array. Description below:

The other problem is a new bug I think. They have the following code:
   for(char c : imei.toCharArray()) // imei is a Source, it's                                           Secret
      obfuscated += c + "_";
Here "obfuscated" must become Secret because imei.toCharArray() is Secret.
But for some reason it doesn't.

First I thought the problem was in the "for" construct, but then I tried
   char[] carr = imei.toCharArray();
   char c = carr[0];
   obfuscated = c + "_";
This doesn't work either.

I am almost 100% sure the problem is at "char c = carr[0]". I know that "carr" 
is
inferred as Secret, so it should be some problem with the [] field (maybe we
allow the [] field to be Tainted?).