-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get some trouble on using taint analysis #124
Comments
Tai-e Version is 6150e1f |
What you've provided is the program being analyzed, not a reproducible example, so I can't delve into your issue. Could you provide a reproducible example? Could you try the latest version of Tai-e? (i.e., |
It seems that the issue section of GitHub cannot submit the entire Tai-e project because it is too large. Perhaps you can access all of my project files through the following link: https://pan.baidu.com/s/1fl8dMh9mh4E8BeAuUePerQ?pwd=gnbg |
I ran my case again on the latest version of Tai-e. In fact, the latest version of Tai-e did not solve my problem. And this is not an error in class loading, I have added some new code logic to determine the value of java. net Has the URLStreamHandler class and its methods been truly loaded and analyzed? Tai-e's feedback is normal, which means that Tai-e loaded the class but did not propagate to the target method properly during taint analysis |
Hi @f4nx1ng, just downloaded your project files and quickly examined the option files contained within. It seems that the project is not consistent with your comments above (e.g., |
Sorry, the content of the taint-config.yml file is inconsistent with the previous log. I hope you can debug the problem more easily at that time, so I commented out some irrelevant or wrong content for you. If this caused you misunderstanding, I am very sorry, but the rest of the part still truly reflects the problem I encountered at that time. |
And now I have forked a copy of Tai-e in my repository. Thanks for your advice. |
Perhaps I know where the problem lies. I have found that from the perspective of pointer analysis, this variable related to UrlStreamHandler points to null. Because this UrlStreamHandler class is an abstract class, it does not have any related new statements. Is there any handling of abstract class function calls in Tai-e? |
Hi @f4nx1ng, tried to understand how the URLDNS gadget works by digging into the the dynamic execution of your example, please correct me if I got it wrong:
And yes, |
Thanks for your reply. In fact, your understanding of the working principle of URLDNS example is correct. I am currently looking for additional solutions on Tai-e so that I can initialize the variable PointerToSet next time I encounter a similar problem. (e.g., when the content of pts is empty, add a required obj/csobj to this pts |
As of the question of To make the best use of Tai-e in the presence of reflection methods, try:
You can try out this example yourself with/without the reflection logs provided. public class Append {
public static void main(String[] args) throws Exception {
String var5 = "sun.net.www.protocol";
String var0 = "http";
Class cls = Class.forName(var5 + "." + var0 + ".Handler");
Object o = cls.newInstance();
}
} without reflection logs:
with reflection logs provided:
And the reflection logs generated by Tamiflex:
|
Oh, thank you for your reply. Although this method is already very good, I still hope there is a more automated way to solve this problem. So I added the following code to the plugin: public void onPhaseFinish() {
solver.getCallGraph().reachableMethods().forEach(csMethod -> {
if (csMethod.getMethod().getDeclaringClass().getName().equals("java.net.URL")){
csMethod.getMethod().getIR().getStmts().forEach(stmt1 -> {
if(stmt1 instanceof Invoke invoke && (invoke.isVirtual() || invoke.isInterface()) && invoke.getRValue() instanceof InvokeInstanceExp invokeInstanceExp){
Var var = invokeInstanceExp.getBase();
Context context = csMethod.getContext();
if (solver.getCSManager().getCSVar(context, var).getPointsToSet() == null || solver.getCSManager().getCSVar(context, var).getPointsToSet().isEmpty()){
JClass jclass = World.get().getClassHierarchy().getClass(var.getType().getName());
Collection<JClass> implementors = new ArrayList<>();
if(invoke.isInterface()){
implementors.addAll(World.get().getClassHierarchy().getDirectImplementorsOf(jclass));
}else {
implementors.add(jclass);
implementors.addAll(World.get().getClassHierarchy().getDirectSubclassesOf(jclass));
}
System.out.printf("%s %s %s %s\n", csMethod.getMethod().getName(), var, jclass, implementors);
implementors.forEach(implementor ->{
solver.addPointsTo(solver.getCSManager().getCSVar(csMethod.getContext(), var), csMethod.getContext(), solver.getHeapModel().getMockObj(()->"Unserialzie", implementor.getName(), implementor.getType()));
});
}
}
});
}
});
} the code above can provide PointerToSet for URLStreamHandler. But it still can't correctly perform taint analysis |
Seems like some points-to-sets are still missing caused by reflection APIs. An invocation of
in the method If you check the pta-results.txt out, you will find that all the instances of class This is, again, a reflection related issue caused by this notorious java feature. Currently Tai-e employs a heuristic to balances between precision and soundness by simplifying the handle of reflection APIs inside libraries (i.e., outside the Application). Again, you may need to provide a reflection log according to the documentation to reproduce the dynamic behavior of the application, or write some taint transfers to guide Tai-e to discover some of the missing function calls and objects. Also, it maybe helpful if you could explain how this taint flow really works (e.g., by providing a comprehensive concrete execution path), as it seem more like a misuse of Tai-e instead of a bug. |
In fact, I have tried to avoid the problem you mentioned when I first wrote the code. You can see the addition of an additional entry method in my plugin implementation, which is used to add the HashMap.readObject() method, thus avoiding the problem you mentioned. The problem you mentioned will not affect the subsequent taint propagation, because the analysis starts from within the JDK. You can see more details in my plgin: |
After debugging for a while, I have some information to share.
|
Oh, I found the problem. This is due to multiple type conversions in the gadget chain. Since this type is unpredictable, it will cause the tainted type to not be parsed normally, causing the resolvecall function to call the wrong method. |
Thank you very much for your help during this period |
📝 Overall Description
When I used the framework for taint analysis, I found that the framework did not perform taint propagation well. Specifically, when I tried to detect the URLDNS deserialization gadget chain, Tai-e did not achieve the expected effect. So I want to know if this is a bug
🎯 Expected Behavior
The result should be a taint flow path from <java.util.HashMap: void readObject(java.io.ObjectInputStream)> to <java.net.URLStreamHandler: int hashCode(java.net.URL)>
🐛 Current Behavior
Tai-e report nothing to me
🔄 Reproducible Example
issue-package.zip
⚙️ Tai-e Arguments
🔍 Click here to see Tai-e Options
🔍 Click here to see Tai-e Analysis Plan
📜 Tai-e Log
🔍 Click here to see Tai-e Log
ℹ️ Additional Information
In addition to the above information, I also added a Tai-e analysis plugin to identify the entry, As shown below
The text was updated successfully, but these errors were encountered: