Security Concerns with Downgrading Java 2527
Good morning forum,
Quick question for all you forum intellects. The company i currently work for is in a bit of a pickle as far as PCI compliancy, and seeing that everyone on this forum has a vast amount of information, i thought someone would be able to help me out. Basically this is the story…
Someone has gone ahead and purchased software for use by the finance department and has not invovled IT, silly i know. Nevertheless, we are now at a point where the application they have acquired needs a java downgrade to run, meaning that the version of java we would be downgrading to is no longer supported by sun, meaning that all security updates to the java platform will be non-existent, leaving our PCI compliancy in jeopordy.
My first question is whether or not you know of any compensating controls we can implement which will relieve this PCI compliancy issue?
Secondly, if this is not possible as we have been finding that there are no compensating controls that seem relevant to this situation, can you point me in the direction of information that will reinforce our theory that this downgrade will leave us vulnerable from a security standpoint?
Thanks for any help you can lend in this regard,
Hi JL - I agree with your concerns and it’s definitely ‘cavet emperor’ (buyer beware), when the IT framework is not properly researched.
While I’d suggest aborsbing the loss and going back to the drawing board on ensuring all solutions are PCI compliant, you might explore whether you can ‘sandbox’ the Finance application (so it’s completely isolated from the PCI environment).
– Does it need to access the Internet?
– Can it be isolated to specific workstations that are outside the PCI infrastructure?
– If there’s just a small number of users, the application could be ported to a ‘kiosk’ environment (where remote control products could access the application)
– Good corporate AV solutions might help compensate for the exploits
Still, your PCI compliancy is worth far more than perhaps having to absorb some small costs for this application. While the Finance area most likely selected a good functional product, it’s always beneficial to get IT involved so they perform the ‘due diligence’ and bless the product in having a good fit within the organization (e.g., from technical, security, and support perspectives).
As requested, these links can provide some of the history associated with Sun Java vulnerabilities
Over 200 documented vulnerabilities -and-#40;and you can home in on specific versions-and-#41;
Numerous exploits have been developed by bad guys
http-and-#58;//www.google.com/search?hl=en-and-q=sun java exploits
Below also are some key links found in research this morning related to the PCI DSS standard. I saw some potential changes that might coming in SEPT 2008 in the last link.
Thank you for the information you have provided, it will definatley help with evidence for why we shouldnt be implemnting this.
I was suprised to see how many vulnerabilities there are in regards to java versions, especially when some of the vulnerabilities seem to carry over to later version of Java. Do you know if this is simply because people are finding new ways to exploit java, but expose the same vulnerabilities? Or is someone just over looking key aspects in the development of the product?
Thanks again for all your input.
Do you know if this is simply because people are finding new ways to exploit java, but expose the same vulnerabilities? Or is someone just over looking key aspects in the development of the product?
It’s more about the complexity of JAVA itself. While JAVA is supposed to use a ‘sandboxing’ address scheme where everything resides within a certain framework, the programming language itself is complex and rich. This low-level programming environment is more reminiceint of Assembler, C , or C#.
JAVA can address real memory and the bad guys have found ways to crash the security layers through long or ususual character strings. Think of sending a 2,000 character URL or highly unusual items, the founders of the programming language never thought of in it’s design. It is one of the most popular programming languages, esp. for scripts and because of it’s power, it has potential for being misused by the bad guys.
As noted earlier, I would ensure being on the latest-and-greatest when it comes to all software, esp. to meet PCI DSS standards. If you can isolate the new application and only downgrade JAVA for those workstations (plus keep these downgraded clients completely out of the PCI environment), that solution may work?
yeah that was an option we looked at except for the fact that it is directly within the scope of PCI compliancy. We have ended up going with the route you have suggested, simply not allowing it.
As a final suggestion, I’d recommend formally requesting from vendor support that the application be changed to ensure it can run with the latest implementation of JAVA. As security is an essential part of meeting business needs today, it needs both a good foundation by the vendor and the best implementation practices by the development team as well.
Funny thing is that the vendor refuses to change their application. They simply shrugging it off and claiming that it isnt their issue. Stupid i know, im not sure why they wouldnt want to keep their client happy, as well comply with standards that will Undoubtedly affect their clients.
Very strange if you ask me.