search

eclipse / steady

Analyses your Java applications for open-source dependencies with known vulnerabilities, using both static analysis and testing to determine code context and usage for greater accuracy. https://eclipse.github.io/steady/
Apache License 2.0
517 stars 124 forks source link

Error executing "checkcode" goal #560

Closed mwager closed 2 years ago

mwager commented 2 years ago

Hey guys,

I installed and analysed an app according to the official docs. (Repo: https://github.com/mwager/WebGoat)

Unfortunately when running the checkcode goal I get an error (see also the attached textfile: checkcode_output.txt ) and have no idea how to fix this. All my dependencies have an orange hourglass and the docs state that in this case the checkcode goal needs to be executed.

An API incompatibility was encountered while executing org.eclipse.steady:plugin-maven:3.2.4:checkcode: java.lang.ExceptionInInitializerError: null

The history Tab tells me I executed it, but the orange hourglass is still there.

grafik

Also the goal a2c throws the following exception:

java.nio.file.NoSuchFileException: /modules/modules
    at java.base/jdk.internal.jrtfs.JrtFileSystem.checkNode(JrtFileSystem.java:486)
    at java.base/jdk.internal.jrtfs.JrtFileSystem.isDirectory(JrtFileSystem.java:431)
    at java.base/jdk.internal.jrtfs.JrtDirectoryStream.<init>(JrtDirectoryStream.java:58)
    at java.base/jdk.internal.jrtfs.JrtPath.newDirectoryStream(JrtPath.java:642)
    at java.base/jdk.internal.jrtfs.JrtFileSystemProvider.newDirectoryStream(JrtFileSystemProvider.java:311)
    at java.base/java.nio.file.Files.newDirectoryStream(Files.java:482)
    at soot.asm.AsmJava9ClassProvider.find(AsmJava9ClassProvider.java:50)
    at soot.SourceLocator.getClassSource(SourceLocator.java:187)
    at soot.Scene.tryLoadClass(Scene.java:967)
    at soot.Scene.loadBasicClasses(Scene.java:1708)
    at soot.Scene.loadNecessaryClasses(Scene.java:1807)
    at org.eclipse.steady.cg.soot.SootCallgraphConstructor.setEntrypoints(SootCallgraphConstructor.java:351)
    at org.eclipse.steady.cg.ReachabilityAnalyzer.run(ReachabilityAnalyzer.java:398)
    at java.base/java.lang.Thread.run(Thread.java:833)

Am I doing smt wrong?

Environment information:

Mac OSX: 11.6 (20G165) Intel 2.3 GHz Intel Core i7

$ java -version openjdk version "18.0.1.1" 2022-04-22 OpenJDK Runtime Environment (build 18.0.1.1+2-6) OpenJDK 64-Bit Server VM (build 18.0.1.1+2-6, mixed mode, sharing)

Expected behavior No execptions thrown when using the tool. Orange hourglasses gone (?)

Steady version 3.2.4 via setup-steady.sh

serenaponta commented 2 years ago

Hi @mwager ,

from the log of checkcode it looks like it's the backend going wrong and returning a HTTP 500 response. Could you also attach the log of the steady-rest-backend container?

Also note that the goal checkcode is able to resolve orange hourglasses propagating the results in terms of ASTs known to be vulnerable/fixed as produced by other evaluation strategies which are implemented in steady-patch-lib-analyzer (see https://eclipse.github.io/steady/user/manuals/analysis/#analyze-unconfirmed-vulnerabilities-checkcode and https://eclipse.github.io/steady/user/manuals/library_assessment/#automated-library-assessment). In a nutshell, when running the analysis on the client the potentially vulnerable code is identified and shown with the orange hourglass if no prior knowledge is available (as it is the case in the first runs after setting up the tool). A java program running in the container steady-patch-lib-analyzer, periodically goes through all orange hourglasses and applies several strategies to try to resolve a them (and additional cases to create prior knowledge). Thus, if all container are running correctly, orange hourglasses are meant to disappear over time. In case the existing strategies cannot establish whether the library contains the fixed or vulnerable version of the code, checkcode is an additional step that can be used before resorting to manual analysis.

From the stacktrace you got running a2c, it looks like it is thrown while the Soot static analyzer is run. In fact, for the static part of the reachability analysis, Steady relies on external tools that can be configured: Soot (default) or Wala. If possible, I would suggest to try to run it with an older Jdk, e.g. Jdk 11, as Steady was not tested with Jdk 18 yet and the version of Soot it's using was released before the release of JDK 18.

thanks!

mwager commented 2 years ago

Hi @serenaponta ,

thank you for your quick response and your explanation!

Hmm the backend seems to be running without issues. I think you saw 500s against webgoat?

2022-07-11 15:11:33,265 [main] [ERROR] kend.requests.BasicHttpRequest - Response-body: [{"timestamp":1657545093283,"status":500,"error":"Internal Server Error","path":"/backend/apps/org.owasp.webgoat/webgoat/8.2.3-SNAPSHOT/vulndeps"}]

grafik

I cannot find logs inside the rest container :/ but it seems running without issues.

grafik

I did try with java 11 and no exceptions are thrown anymore :D thx!

I think I am going to let the container run for longer time and will evaluate more. Closing this issue for now :)

serenaponta commented 2 years ago

Hi @mwager,

happy to hear that the exception is gone :)

you should be able to see the logs directly through docker logs: docker logs -f steady-rest-backend. The response with error code 500, should be the call from the steady maven plugin to the steady rest backend to retrieve all "vulndeps" for the application being scanned, i.e., org.owasp.webgoat/webgoat/8.2.3-SNAPSHOT.

You can also check the logs of steady-patch-lib-analyzer if you want to double check if and what is being processed.