SpringEntityLeakDetector incorrectly parses controller method signature

[Scott Steen]

Environment

Component	Version
Maven	N/A
Gradle	7.3.3
Java	17
SpotBugs	4.5.3
FindSecBugs	1.11.0

Problem

The SpringEntityLeakDetector seems to incorrectly parse the Spring controller method signature when mulitple arguments exist. In this scenario, the mulitple arguments are not split into an array of their individual parts. Instead, an array with one element is produced, whose contents is the concatenated arg classes (i.e. java/lang/String;Ljava/lang/Object). An Exception is then thrown by SpotBugs when it tries to resolve a Class from this single array element.

When a single argument exists, no Exception is thrown.

The following errors occurred during analysis:
  Exception analyzing com.example.ExampleController using detector com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector
    java.lang.IllegalArgumentException: Invalid class name java/lang/String;Ljava/lang/Object
      At edu.umd.cs.findbugs.classfile.ClassDescriptor.<init>(ClassDescriptor.java:59)
      At edu.umd.cs.findbugs.classfile.DescriptorFactory.getClassDescriptor(DescriptorFactory.java:128)
      At edu.umd.cs.findbugs.AnalysisCacheToRepositoryAdapter.loadClass(AnalysisCacheToRepositoryAdapter.java:90)
      At org.apache.bcel.Repository.lookupClass(Repository.java:65)
      At com.h3xstream.findsecbugs.spring.SignatureParserWithGeneric.typeToJavaClass(SignatureParserWithGeneric.java:67)
      At com.h3xstream.findsecbugs.spring.SignatureParserWithGeneric.getArgumentsClasses(SignatureParserWithGeneric.java:52)
      At com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector.analyzeMethod(SpringEntityLeakDetector.java:108)
      At com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector.visitClassContext(SpringEntityLeakDetector.java:69)
      At edu.umd.cs.findbugs.DetectorToDetector2Adapter.visitClass(DetectorToDetector2Adapter.java:76)
      At edu.umd.cs.findbugs.FindBugs2.lambda$analyzeApplication$1(FindBugs2.java:1108)
      At java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      At edu.umd.cs.findbugs.CurrentThreadExecutorService.execute(CurrentThreadExecutorService.java:86)
      At java.base/java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:247)
      At edu.umd.cs.findbugs.FindBugs2.analyzeApplication(FindBugs2.java:1118)
      At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:309)
      At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:395)
      At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1231)

No Exception was observed on SpotBugs version <= 4.5.2. It is likely that the fix for spotbugs/spotbugs#1883 surfaced this bug in FindSecBugs.

Code

package com.example;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ExampleController {

  @GetMapping("/")
  Object example(String s, Object o) {
    return new Object();
  }
}

[Guillaume Toison]

Indeed, this is probably an issue in SpotBugs and the same as spotbugs/spotbugs#1919

[Scott Steen]

I believe the issue lies with this project & have created a PR based on that. The PR has further description of the issue & a new test case to prove the issue.

The PR can be closed if my findings are not correct.

[Guillaume Toison]

Hello @h3xstream,
Could you please have a look at this issue and release a fixed version? It is blocking to upgrade beyond SpotBugs >= 4.5.3 and the Pull request proposed by @scottsteen seems promising
Many thanks

[Matthew Lowry]

For the record, I've found my build started tickling this as well.

Curiously, I didn't see it straight after upgrading to Spotbugs 4.5.3. Initially after that upgrade we had a bunch of global exclusions for both vanilla Spotbugs patterns and also some findsecbugs patterns. I only started seeing these exceptions when I removed the global exclusions for the spotbugs pattern DMI_RANDOM_USED_ONLY_ONCE and the findsecbugs pattern PREDICTABLE_RANDOM, and either patched or placed a class-level @SuppressFbWarnings on the code that triggered those patterns. After that suddenly I start seeing these exceptions for some (but not all) of our arity>1 @RequestMapping methods.

Which is weird. Anyway I'm downgrading to Spotbugs 4.5.2 in the mean time. Thanks everyone for your efforts!

[Scott Steen]

@h3xstream Thanks for hitting the go button on that PR!

Would you like me to close this issue now, or should we wait for a new release before doing so?

[Philippe Arteau]

@scottsteen We can closed it.

[Benoit Lacelle]

We get a similar issue in find-sec-bugs 1.12.0:

The following errors occurred during analysis:
  Exception analyzing com.project.WebAuthnController using detector com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector
    java.lang.IllegalArgumentException: Invalid class name java/util/Map<Ljava/lang/String;*
      At edu.umd.cs.findbugs.classfile.ClassDescriptor.<init>(ClassDescriptor.java:59)
      At edu.umd.cs.findbugs.classfile.DescriptorFactory.getClassDescriptor(DescriptorFactory.java:128)
      At edu.umd.cs.findbugs.AnalysisCacheToRepositoryAdapter.loadClass(AnalysisCacheToRepositoryAdapter.java:90)
      At org.apache.bcel.Repository.lookupClass(Repository.java:65)
      At com.h3xstream.findsecbugs.spring.SignatureParserWithGeneric.typeToJavaClass(SignatureParserWithGeneric.java:75)
      At com.h3xstream.findsecbugs.spring.SignatureParserWithGeneric.getReturnClasses(SignatureParserWithGeneric.java:60)
      At com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector.analyzeMethod(SpringEntityLeakDetector.java:112)
      At com.h3xstream.findsecbugs.spring.SpringEntityLeakDetector.visitClassContext(SpringEntityLeakDetector.java:69)
      At edu.umd.cs.findbugs.DetectorToDetector2Adapter.visitClass(DetectorToDetector2Adapter.java:76)
      At edu.umd.cs.findbugs.FindBugs2.lambda$analyzeApplication$1(FindBugs2.java:1108)
      At java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      At edu.umd.cs.findbugs.CurrentThreadExecutorService.execute(CurrentThreadExecutorService.java:86)
      At java.base/java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:247)
      At edu.umd.cs.findbugs.FindBugs2.analyzeApplication(FindBugs2.java:1118)
      At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:309)
      At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:395)
      At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1231)
      At java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      At java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
      At java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      At java.base/java.lang.reflect.Method.invoke(Method.java:568)
      At org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:218)
      At java.base/java.lang.Thread.run(Thread.java:833)

is this issue fixed in https://github.com/find-sec-bugs/find-sec-bugs/releases/tag/version-1.12.0 ?

The signature looks like:

@PostMapping("xxx")
public ResponseEntity<?> registerTotp(HttpServletRequest request,
		Authentication authentication,
		@RequestBody Map<String, ?> payload) {

[Scott Steen]

@blacelle

That looks like a different Exception message. I believe I've seen the same when it comes to the Map<T, U> signature. If you remove the Map only, do you still see the Exception?

Can you raise a new issue with a minimum reproducible example?