I work in a lab and use a number of Windows VMs to run analysis software. I manage these VMs and am being asked to fix the log4j vulnerability. However, while I have some experience in research computing, I'm really lost as to exactly what I need to do.
I know I need to update to log4j 2.16.0. For next steps, I received instructions from our IT to "make sure that both of the patched API and Core jars are listed in your application’s classpath, which can be done from the command line or by using a manifest file." Unfortunately I don't know what that means.
What are the exact steps I should take to fix the log4j vulnerability on a Windows machine (Windows Server 2019 Datacentre)?
Java applications typically use JAR files that ar zip files with classes. The Log4J.jar file has to be updated. Java applications load these classes at startup, by loading all jar files and classfiles that are specified in the classpath. From the command line that may look like this
Java -cp log4j.jar;myapp.jar my.app.HelloWorld
Its enough to replace the jar file with a new version and restart the application. How the startup looks like for you and where the jar files are located can wildly vary and is impossible to guess without more information
R Greg Stacey
https://github.com/lunasec-io/lunasec/releases/
Apex One indicates a ramsomware
Related
Creating a docker image with gradle 7.4.1 triggers the security scan which shows vulnerability CVE-2020-36518. How can this particular jar file within the gradle package be updated?
I would just reject the security issue, explaining that it is not possible to exploit the vulnerability as the Gradle build runs isolated on controlled input, and is not accessible by any potential attackers.
(Assuming this is the case, of cause, and you don't have a custom Gradle plugin that reads untrusted JSON documents using Jackson from the Gradle classpath. But even then, all you are risking is a denial-of-service on the build.)
Fiddling around with jar files in external tools could easily lead to problems hard to debug later. But if you like, you could create an issue for them, asking if they could bump the Jackson version to avoid unnecessary noise from security scans like this. There is an example of that here.
I want to learn cyber security and I started with webgoat(On youtube). It says that you should donwnload a jar file from github.com. But I am not able to get the jar file on https://github.com/WebGoat/WebGoat/releases
Looks like a while ago they stopped producing the jar file. Latest build with one is https://github.com/WebGoat/WebGoat/releases/tag/v8.1.0
If you want to use 8.2.0 look at building the source detailed https://github.com/WebGoat/WebGoat
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
I want to package a Groovy CLI application in a form that's easy to distribute, similar to what Java does with JARs. I haven't been able to find anything that seems to be able to do this. I've found a couple of things like this that are intended for one-off scripts, but nothing that can compile an entire Groovy application made up of a lot of separate Groovy files and resource data.
I don't necessarily need to have the Groovy standalone executable be a part of it (though that would be nice), and this is not a library intended to be used by other JVM languages. All I want is a simply packaged version of my application.
EDIT:
Based on the couple of responses I got, I don't think I was being clear enough on my goal. What I'm looking for is basically a archive format that Groovy can support. The goal here is to make this easier to distribute. Right now, the best way is to ZIP it up, have the user unzip it, and then modify a batch/shell file to start it. I was hoping to find a way to make this more like an executable JAR file, where the user just has to run a single file.
I know that Groovy compiles down to JVM-compatible byte-code, but I'm not trying to get this to run as Java code. I'm doing some dynamic addition of Groovy classes at runtime based on the user's configuration and Java won't be able to handle that. As I said in the original post, having the Groovy executable is included in the archive is kind of a nice-to-have. However, I do actually need Groovy to be executable that runs, not Java.
The Gradle Cookbook shows how to make a "fat jar" from a groovy project: http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Creatingafatjar
This bundles up all the dependencies, including groovy. The resulting jar file can be run on the command line like:
java -jar myapp.jar
I've had a lot of success using a combination of the eclipse Fat Jar plugin and Yet Another Java Service Wrapper.
Essentially this becomes a 'Java' problem not a groovy problem. Fat Jar is painless to use. It might take you a couple of tries to get your single jar right, but once all the dependencies are flattened into a single jar you are now off an running it at the command line with
java -jar application.jar
I then wrap these jars as a service. I often develop standalone groovy based services that perform some task. I set it up as a service on Windows server using Yet Another Java Service and schedule it using various techniques to interact with Windows services.
How should I package and ship my groovy scripts without assuming groovy to be installed (and on PATH) on client machine? However, JDK/JRE will be available on all client machines.
What I'm currently doing is to groovy-compile & bundle related scripts in a jar with groovy-all-xxx.jar included in the lib (Netbeans does this automatically). But the problem with this approach is - with every independent small script (project), I have to bundle the huge groovy-all jar creating a big binary.
Just wanted to know if there is any better way of doing this.
You might be able to use the extension mechanism for this - that way each client machine would have to download groovy-all-xxx.jar just once.