Java devs warned of pushbutton exploit for buggy Struts framework Java developers were warned, but they didn't listen. Security researchers at Trend Micro report that old and vulnerable versions of the Apache Struts framework for Java are still in widespread use, and now Chinese hackers are using automated tools to exploit their flaws. The vulnerabilities in question were patched in the July …
"In March, a study by Sonatype and Aspect Software found that developers downloaded out-of-date versions of the most popular frameworks 33 per cent of the time, even though newer versions with security fixes were available."
Ok, so why did they continue to make the bad versions available, and then blame the downloaders for downloading them? Nice going
Ok, so why did they continue to make the bad versions available, and then blame the downloaders for downloading them? Nice going
Because "they" didn't. Oracle makes available the latest primary, and beta releases. Third-party mirror sites make available every known version of Java since the beginning of time.
But even that might not be the reason they're running old versions. It's the web site builders that may have downloaded what was the latest at the time, but never upgraded because of: "don't fix it if it 'aint broke" (even if their definition of "broke" are flawed), too lazy, won't upgrade because we don't have time to fix things if the upgrade breaks our code, they may have even stuck with old versions they had developed on, because the following new version didn't have some feature or behaivour the web site builder wanted, or any other of a host of reasons anyone doesn't upgrade.
You can't "fix" this situation by forcing the users to upgrade (outside of their control) because that causes a host of other reactionary issues. If program behaviour changes and the user's don't like it, they complain. Loudly. Look at Skype as an example, imagine if every web site worked under that model - YOU as the end user would have no choice about your favourite website behaiving differently every month - how long before that pisses you off?
The problem with big utility framework makers, like Apache, is that their frameworks tend to get very tangled together. Third party libraries use them and become tangled with them as well. Now you mix together a bunch of third party libraries, and getting all the utility frameworks that they depend on running on the same version becomes a nightmare. Some of those libraries may be end-of-life and not link against newer components. Every Java developer has had to fight with getting Apache's stupid Log4J library working properly the moment they bring in their second or third open source library. For old and bloated "Enterprise" applications, the thought of upgrading anything sends developers running away in fear.
I pity the Java developer who is still using Log4J directly, as opposed to via Slf4J or a replacement, such as Logback.
Log4J has some serious throughput issues for high logging workloads, resulting in the logging framework actually blocking the running application from running at full pelt.
Dependency versioning is a horrible game these days with Java, most serious projects are managed by Maven and Maven doesn't apply any policy to the version it pulls out of its arse when it has clashing dependencies to resolve.
developers downloaded out-of-date versions of the most popular frameworks 33 per cent of the time
If your application is running in Framework version X, you don't need to keep downloading it. I would guess that most downloads of obsolete versions are intended to build developer environments when legacy applications have to be modified or maintained. In an ideal world the application platform would be upgraded at the same time - in the same ideal world we'd all have unlimited time and money.
Does this mean that Open-source frameworks are less secure than Closed-source frameworks?
--
attackers, automated tools, Chinese hackers, Chinese script-kiddie tool, execute arbitrary code, exploit their flaws, malicious hacker, open source frameworks, plant a backdoor, threat, vulnerable servers ..
Unfortunately the dimwits who write Struts don't just fix bugs in their point releases. They also like to change default behaviour of code, not just breaking apps but in some cases opening security holes if you relied on the existing behaviour. So the process of upgrading to a newer version of Struts can be as risky as not upgrading. You need to have very deep understanding of your apps to know the upgrade is safe to apply. Fine if it's a one-man show, but in a real dev environment it's a Struts update doesn't just add a test cycle, it can mean a major code review too. Having been stung by this in the past I can understand why Struts updates are not applied immediately. Damed if you do, damned if you don't.
Here's an example (only meaningful to Struts users): https://issues.apache.org/jira/browse/WW-3973
For this reason alone, the one project we have using Struts will be last. Can't be having this amateur-hour crap in real software. If they want to change default behaviour they should do it in the next major release and, if they must, optional in the point releases with default being "no change".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
