HNHacker News
TopNewBestAskShowJobs

sjones671

15 karma · joined May 6, 2019

submissionscomments
sjones671··on Running local models on an M4 with 24GB memory
Thanks for saying this. There's so much nonsense out there online about local models being better than Opus 4.7 and the like. It's just not true for regular users.

I have a brand new M5 MacBook Pro - top end with all the specs and I've tried local models and they're barely functional.

sjones671··on James Webb, Hubble space telescopes face reduction in operations
Agreed
sjones671··on CVE Foundation
$40 million per year.
sjones671··on Working fewer hours is associated with higher life satisfaction
Surprising nobody.
sjones671··on Elon Musk makes $43B unsolicited bid to take Twitter private
That’s a lot of zeros for some frozen peaches.
sjones671··on Spring Core on JDK9 is vulnerable to remote code execution
The exploit PoC that is doing the rounds works on full tomcat, not embedded tomcat, so if your example vulnerable application is using embedded tomcat that exploit won't work on it without being tweaked.

I've looked at it today as well, for most of the day. Embedded tomcat doesn't have a webapps directory, whereas the full version of tomcat does, so the PoC writes the webshell to webapps/<APP>/tomcatwar.jsp and that is served up then.

I'm on OSX and I found the temp directory that is created for the embedded tomcat at runtime but there's nothing deployed there, so I can't figure out where to write the webshell to or if it is even possible. I looked at the process with lsof and just followed the trail to find the directory but it's not working.

Anyway, embedded tomcat IS vulnerable, just not sure if it is exploitable.

To check if it is vulnerable you can do run the following curl command: curl "http://localhost:8080/?class.module.classLoader.URLs%5B0%5D=..."

If this returns status:400 then it is vulnerable, if not then it is not. If you have an app deployed to a different context path (so /my-webapp) then you'd need to run: curl "http://localhost:8080/my-webapp?class.module.classLoader.URL..."

I don't think it is common to use @RequestMapping in java and take in a POJO as a parameter to the request, but that is needed in order to be vulnerable to this.

I'm sure there's other gadgets that can be used to exploit this, the example we saw was using tomcat to write a webshell.