search

spring-projects / sts4

The next generation of tooling for Spring Boot, including support for Cloud Foundry manifest files, Concourse CI pipeline definitions, BOSH deployment manifests, and more... - Available for Eclipse, Visual Studio Code, and Theia
https://spring.io/tools
Eclipse Public License 1.0
880 stars 205 forks source link

Advanced Threat Prevention #400

Closed StephenDillon closed 4 years ago

StephenDillon commented 4 years ago

1578418720241338684272978264628

Installing any version of STS 4 triggers the attached error message (including latest 4.5.0.RELEASE) using a clean install with just a simple Gradle project open. No issues with all 3.X releases opening 10+ of the same Gradle spring boot projects.

Might be something related to the Dell corporate image but this is the only app that triggers this error and sts 3 works without issue. Any suggestions to try debug? (stephen.dillon@dell.com)

martinlippert commented 4 years ago

Looks like this is a duplicate of https://github.com/spring-projects/sts4/issues/398. I am really wondering what might cause this. Is there any chance that this message could reveal more information about which exact process caused this?

I am wondering especially about the memory violation that the error message mentions, since the processes that we start in the background are regular Java/JVM processes, for which it is quite hard to produce a memory violation. So any more details would be highly appreciated.

StephenDillon commented 4 years ago

Hey Martin, i can try figure out what program is triggering that warning, it occurs pretty fast when i start up and try to do anything in the IDE. I tried tweaking the memory settings via the ini file but didn't seem to have any effect. Is there any specific logs for STS that might give some info. It doesnt kill STS process itself, so i assume its a process that STS creates in the background?

kdvolder commented 4 years ago

It doesnt kill STS process itself, so i assume its a process that STS creates in the background?

That's an interesting tidbit of info, upto now I was assuming that it was the STS process itself being flagged and killed.

So, you mentioned Gradle project, wonder if this is signigicant or not. Can you try something else, like maybe just a maven project? If this is specific to Gradle project then maybe it has something to do with the Gradle daemon.

Another thing to try, is disabling all the language servers (uncheck everything in "Window >> Preferences >> Language Servers". The language servers are also processes that STS starts.

StephenDillon commented 4 years ago

Good call. I tried a start.spring maven project and gradle, both triggered the issue. Disabling the Java Source File and Spring Properties File under the language server seems to have stopped the error occurring. When these are enabled, simply opening a java file and hitting format a few times triggers the issue.

I have a zoom meeting open if by any chance you want to jump on that and see for yourselves. https://Dell.zoom.us/j/294598783

I think i have a stack trace that might point to something, ill attach it from my work pc

StephenDillon commented 4 years ago

from the workspace .log

!ENTRY org.eclipse.lsp4e 4 0 2020-01-09 13:47:56.628 !MESSAGE !STACK 0 java.util.concurrent.TimeoutException at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1957) at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2092) at org.eclipse.lsp4e.LanguageServerWrapper.supportsWorkspaceFolderCapability(LanguageServerWrapper.java:529) at org.eclipse.lsp4e.LanguageServerWrapper.canOperate(LanguageServerWrapper.java:518) at org.eclipse.lsp4e.LanguageServerWrapper.canOperate(LanguageServerWrapper.java:841) at org.eclipse.lsp4e.LanguageServiceAccessor.lambda$6(LanguageServiceAccessor.java:361) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:176) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1600) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at org.eclipse.lsp4e.LanguageServiceAccessor.getLSWrappers(LanguageServiceAccessor.java:362) at org.eclipse.lsp4e.LanguageServiceAccessor.getLanguageServers(LanguageServiceAccessor.java:588) at org.eclipse.lsp4e.operations.color.DocumentColorProvider.provideCodeMinings(DocumentColorProvider.java:60) at org.eclipse.lsp4e.operations.color.DocumentColorProvider.provideCodeMinings(DocumentColorProvider.java:87) at org.eclipse.jface.internal.text.codemining.CodeMiningManager.lambda$2(CodeMiningManager.java:189) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at org.eclipse.jface.internal.text.codemining.CodeMiningManager.getCodeMinings(CodeMiningManager.java:195) at org.eclipse.jface.internal.text.codemining.CodeMiningManager.updateCodeMinings(CodeMiningManager.java:140) at org.eclipse.jface.internal.text.codemining.CodeMiningManager.run(CodeMiningManager.java:129) at org.eclipse.jface.text.source.SourceViewer.updateCodeMinings(SourceViewer.java:1313) at org.eclipse.jdt.internal.ui.javaeditor.JavaCodeMiningReconciler.reconciled(JavaCodeMiningReconciler.java:51) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1694) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:222) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:167) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:115) at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:76) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:210)

kdvolder commented 4 years ago

@StephenDillon and I managed to connect on Zoom and did a bit of trouble-shooting. Here's a summary:

At this point we suspected that the live hover process scraping, which is similar to how JConsole connects to processes... might be involved. We disabled live process support via the Preferences in Eclipse and the problem no longer occurs.

Conclusion: we don't know exactly why, but it seems that Dell Security does not like it when jvm process tries to connect to other process using the Jconsole/JMX mechanics and decides that this is 'suspicious' activity, and terminates the process.

@StephenDillon works at Dell and said he might be able to contact someone inside Dell who might be able to do something about it. I have offered to help with this from our end if need be.

At the moment I don't think there is much that we can do ourselves here.

But it is at least good progress that we know live hover is the thing that triggers the security tool to terminate our process. And a workaround is to disable live hovers. All other language server features can then be used (though of course, live hovers will not work).

I'm closing this ticket for now as there is nothing to do at the moment.

@StephenDillon Feel free to comment here however for further follow ups.

martinlippert commented 4 years ago

This is an awesome analysis and great to hear that you found the underlying issue.

martinlippert commented 4 years ago

From another task I know that the implementation to find running processes uses native code in a library that uses shared memory. Maybe that is the underlying root cause there.

StephenDillon commented 4 years ago

Thank you so much for following up on this, very happy to finally catch up to the latest STS version and your responsiveness/helpfulness is why i love the spring community! :)

I reached out to Dell IT and the Dell Data Security team with the info we found here, They where able to adjust the policy to allow for these connections. Looks like it is specific to dell, so anyone else hitting this can feel free to reach out to me and i can set them up with the method of resolving.

IMSAITAN commented 4 years ago

@StephenDillon I work for dell as well and facing the same issue - Would you be able provide any assistance to resolve the issue Thanks in Advance

StephenDillon commented 4 years ago

Hey, @IMSAITAN . Sure reach out to me on Teams or Email and i can help you out