Further, the older JRE families (JRE 1.5/5.0 family and earlier, as well as JInitiator) are no longer supported and so while malware authors can continue to develop attacks for those older versions, the vulnerabilities are not being fixed and just remain exploitable.
Why? Because any web app can specify any vulnerable JRE you happen to have installed and run attack code on your computer. You cannot keep the older version and be protected against exploits. Well, it seemed like a good idea at the time.īack then, “older version” was not automatically considered to be synonymous with “riddled with easily exploitable security bugs.” However, many JRE updates are Critical Patch Updates (CPUs) that fix such bugs.
“It was developed, tested and known to work on 1.2.2_14 and so we require that version.” In particular, I see many custom, internal line of business (LOB) apps at my customers that require a specific, old JRE version. Naturally, many responsible and conscientious developers continue to leverage this feature to ensure that their code continues to perform as originally tested. Forward compatibility guaranteed! Brilliant! Your app would simply continue to use the older version. If a newer version of the JRE were installed, everything would be fine as long as the version you needed were also still installed. Their answer was that different versions of Java could be installed and run side by side, and if your app was known to work with a specific JRE (say, version 1.2.2 Update 14), you could always just specify that version and use it. The makers of the Java programming language and Java Runtime Environment (JRE) thought they had it figured out. Some internal implementation detail may have changed that breaks your program, or the rules for the new platform disallow behaviors you had depended upon, such as storing data in a particular location, or expecting that since “foo” was not a language keyword it wouldn’t become one in the next version. It will effectively become a different platform, and you really have no way to know whether the implicit assumptions you had made will still hold.
But eventually that platform and its specifications will be updated. You carefully write your programs strictly according to the current specifications for your target platform, and it works perfectly well on that platform. Writing forward-compatible software is really hard.
0 kommentar(er)
