Intevydis blog has released yet another exploit for Sun Java System Web Server. This one attacks diguest authentication. “Well, I don’t use digest auth, so I’m safe, right?” Wrong! Any client can trigger digest auth handling even if the web site doesn’t require a password.
I know this, not because I am clever and well versed in SJSWS. I know this because I ran the code against a test server and successfully crashed it.
So then, you and I are vulnerable to this exploit.
However there is a workaround. One that we’ve already used to prevent the previous two exploits. It requires that you manually add a couple lines to every virtual server config file in your deployment.
That code is:
<If $method="PROPFIND" or $method="OPTIONS" or $method="PUT" or $method="DELETE" or $method="MOVE" or $method="MKDIR" or $method="RMDIR">
AuthTrans fn="set-variable" remove-headers="transfer-encoding" set-headers="content-length: -1" error="501"
This disables all the methods you probably don’t really use. OPTIONS and PUT have already been used to exploit SJSWS. Why wait for another method to be exploited? Let’s disable them all. At least until Sun comes out with a patch.
I’d like to point out one thing. When I did crash my SJSWS test deployment, it came back up within 10-15 seconds. Sun’s watchdog process keeps tabs on your server process and, should it crash, immediately starts up another. That is really handy. Granted it’d be trivial to still execute a DoS against a vulnerable server (just send the malicious request every 30 seconds), but if someone’s just trying to muck around with your server, it won’t cause any lengthy amount of downtime.