Not just no, HELL NO.
If you have a business need for an old broken and vulnerable Java, then the business will need to figure out how to allow that to safely coexist with the reality that running out of date Java on a machine that accesses the internet will get that machine owned in very short order, no matter whose AV you use.
The attacks available today make it really easy for attackers to customize code to evade AV and consequently AV is only catching a small fraction of the newest threats. You still need it of course because widely deployed threats do eventually get signatures, and regulatory and audit drivers pretty much mandate AV. As I say in my user awareness classes "No, Virginia, AV won't save you."
A web proxy that can block old Java user agents at the internet gateway may be your path of least resistance. Bluecoat and Palo Alto may be vendors you'll be interested in talking with. I don't know if McAfee has network devices that allow filtering on user agent?
Whoever wrote the software that breaks on the newest Java really needs to be flogged into getting that fixed though. Otherwise it's a massive liability to your enterprise.
Is there any proof of this?
The people responsible for the business apps that only run on several years old versions of Java have the belief that AV can update their definitions much more frequently than Sun can update Java, so all Java exploits that would be fixed by updating the Jaca would also be blocked by McAfee. They believe many tens of thousands of dollars of cost it would take to update the software cannot be justified when they are covered by the fixed expense of VSE licensing.
If a new Java exploit comes out tomorrow that bypasses VSE, it would also bypass a fully up to date Java installation until Sun patches it weeks later. AV companies could block the exploit it in days or hours, so there would be no benefit.
Isn't this true? If not, specifically why not?
1 of 1 people found this helpful
Yes, there's proof. And no, unfortunately I must be the bearer of bad news and the inconvenient truth that this is not true. The people responsible for the business apps need to be educated by security SME's that their thinking is unfortunately severely flawed if they're trying to make themselves feel okay for keeping known vulnerable JVM's on machines that are also used for Internet surfing. If they're leveraging java on a server machine that never touches the internet with a web browser, that's another matter, but forcing end users to have a vulnerable JVM on their workstation without another mitigating control somewhere is asking to be owned, I'm afraid.
That AV signatures can provide a virtual patch while Sun updates Java for the latest vulnerability is surely the kool aid that AV vendors want people to believe, but sadly, like any signature based methodology, evasion is unnervingly easy. AVs and most IPS's work on signatures of known attacks. If the attacker modifies the attack slightly, the signature changes, and you're naked if you're still running the ancient software that's still full of vulnerabilities.
The second reason this thinking is flawed is that the race they've ignored is the race that's already lost -- there are a ton of publicly available exploits for old Java, today. No one needs to discover a new vulnerability. Download metasploit, learn to run it, and watch your test box with old java get totally owned via a drive by exploit while your AV remains silent. Run the automatically generated exploits with even the most basic of the many obfuscations/packings that metasploit can perform and let us know how AV detection rates are on those exploits. And then watch your test box get owned by virtue of the Java exploit just by surfing to a test web page.
Once they see that, then see if their risk justification still holds up. It might, or they might figure out another way to keep that essential old java off the internet by spending some money on a web proxy applicance that can block java user-agent requests at the web gateway. If figuring out metasploit isn't in anyone's time budget, have a penetration test done by a company that knows how to put client-side applications in scope, or just run long enough and wonder why your hosts are seeming to contract so much malware.
Brian Krebs wrote a good blog post on the issue that remains the case today:
Java: A Gift to Exploit Pack Makers
And if you need further convincing of the limitations of AV, here's a very recent ISC diary entry talking about how FakeAV leverages Flash vulns and continues to stymie nearly all the AV vendors with respect to detection.
AV only blocks the stuff the AV company a) knows about and b) has written a signature for. Talk to any penetration tester or black hat attacker about what a repacker is and how much of a problem AV poses to them.
You need to patch client-side Java or take measures to make sure that Internet web surfing never reaches your vulnerable JVM. If that means running the JVM in a Citrix or vmware thinapp sandbox, or purchasing a web proxy that can block http requests with a user-agent of a JVM older than a certain vintage, it's something that should be considered.
Message was edited by: Regis (added clarification about client side java vs server side java) on 6/14/11 8:37:31 AM CDT
They have a web proxy available.
So, blocking the Java user agent would eliminate the need to update Java for security then?
Is there an easy way to test if it's already being blocked through the proxy (assuming there is no need for there to be access through the proxy for the apps to work)?
Blocking requests that contain old Java version strings at the proxy and dropping external .jar filetypes in responses would greatly reduce your attack surface.
Now, not all web proxies are flexible enough to be able to block in this way, but you may get lucky. What web proxy do they have? Do they have enough CPU margin to do a regex match on User-Agent: or does the proxy have native policy ability to make decisions on User agents?
I haven't penetration tested those specifics enough to tell you it'd eliminate the need to update Java, but I think you'd have mitigated a huge % of the risk associated with having vulnerable JVM's on your desktops.
Most likely the web proxy would be Blue Coat or else something similar.
Isn't there something that can block these old versions of Java from accessing anything except for whitelist of apps or web sites?
What about the Mcafee firewall installed on the local worklstations?
With Bluecoat you can do it if you can afford the CPU for a regex expression on user agent..provided it is Java doing the connection to the internet to grab the goodies.
The edge cases you'll have to study armed with proxy logs though is "what if the web browser is what goes out and gets the malicious jar file, then hands it off local and highly vulnerable java?" In such a case, only blocking java to the internet entirely might effectively prevent comrpomise, since a user-agent regex isn't going to help at all.
On the local firewall end, you could tell the java process not to talk to anything but the local network, but if the java is being handed a piece of code to evaluate from another program that can get to the internet, you're still possibly screwed.
The place to sandbox is at the code level... citrix or thinapp or something like that.
I don't envy your position--this is a hard problem if the business truly won't invest the money to fix the issue.
I wanted to see more than just one person's opinion on this, but I will go ahead and mark it as answered.
It's possible that the company might have already done something like suggested above with the web proxy or maybe VSE has something similar to Symantec Endpoint's IPS with custom signatures that will block Java exploits that I simply am not in the loop on and I'm concerned about this for no reason. The people resonsible for running those areas will need to do their jobs properly to make for the Java app developers coding apps in a way that requires specific versions of Java to run and then dropping further developement of those critical business apps once they were "stable" to save money.
If the company is stupid enough to not be doing anything effective to mitigate the threat, then they will simply have to deal with the consequences and damage later since they have made the choice to take the risk.
Having consulted for several and having worked in a similarly fragmented environment, I'd be willing to bet that nope, the sane/safe thing probably hasn't been done, and the right groups aren't talking to one another to realize what a threat this is.
It's not that the company is stupid pe se, it's just organizationally difficult to get the stakeholders together to deal with it, particularly if infosec isn't in a governance organization outside of IT operations, where it's their mission to find such insanitites and they're granted a big enough stick to herd the necessary cats to fix the problem. Hell, even Sony didn't have a CISO until recently (and THAT was indeed truly stupid).