Oracle set another record with its latest quarterly Critical Patch Update (CPU), which included 308 vulnerability fixes, 32 of which were Java-related. Released earlier this month, this CPU more than doubles the 136 fixes issued just over a year ago.
That last insight came my way from the folks at Waratek, the Dublin-based app security tools provider with a special focus on Java. I talked with the company's lead security architect, Apostolos Giannakidis, about this CPU, and he argued that the high number of vulnerabilities in the Java Runtime Environment (JRE) covered by this release demonstrate that the Java SE platform continues to be a very popular attack vector.
"The attack vector of the Java platform is huge," he told me. "More and more vulnerabilities are discovered that affect both the legacy and newer versions. Attackers are able to compromise applications and systems specifically by attacking the runtime itself -- and, this trend keeps increasing at a fast rate."
Of the 32 Java-related vulnerabilities covered in this CPU, 10 earned high-risk CVSS ratings. Oracle uses the Common Vulnerability Scoring System (CVSS) to provide an open and standardized rating of the security holes it finds in its products. Each vulnerability is issued a unique CVE number.
This CPU includes fixes for vulnerabilities in a range of Java components, including AWT, ImageIO, JavaFX, JAXP, ThreadPoolExecutor, AsynchronousChannelGroup, LambdaFormEditor, LDAP, Nashorn, JAR verifier, DSA, ECDSA, Elliptic Curve, X.509, PKCS#8 and the HotSpot VM. These vulnerabilities could allow attackers to escalate their privileges, corrupt the JVM's memory, crash the JVM or execute arbitrary code and system commands.
Giannakidis pointed to two new vulnerabilities fixed in this CPU in the serialization component of the JVM that would allow the excessive allocation of memory. (Serialization is the process of converting an object into a stream of bytes for transport and storage.) He also pointed to fixes in this release to deserialization vulnerabilities in the RMI and in the Distributed Garbage Collector. (Deserialization reverses the process when the data is received.)
"This is despite the fact that the January CPU addressed deserialization vulnerabilities in the same components," Giannakidis said. "This demonstrates that there are still critical deserialization attack vectors in the Java platform itself. I would have to say that it looks very much like Oracle is playing the Whac-A-Mole game with the deserialization vulnerabilities."
The problem here is that the Java Runtime is one of the most complex runtimes, he added. "The amount of lines of code in the code base is considerable," he said. "With such a big code base, it makes sense that you are going to have increased vulnerabilities. The important thing to remember is that these vulnerabilities were already there, lurking in the code base for a long time, based on my analysis. It's a matter of spending time finding them. In fact, the vulnerabilities in the runtime are now the focus of the security community."
Each quarterly CPU is a set of patches for multiple vulnerabilities put together since the previous update. They do not include the security advisories from previous updates; those are available on the Oracle Technology Network Web site. However, most CPUs are cumulative, Oracle has said, which means the application of this CPU should resolve new vulnerabilities and previously-reported security issues.
Oracle's CPUs are issued on a quarterly schedule announced at the beginning of the year. The purpose of that schedule is to provide users of Oracle products with a level of predictability that will foster regular maintenance activity, the company has said. The next CPU is scheduled for release on Oct. 17.
Posted by John K. Waters on July 26, 20170 comments
Did you hear that, a kind of whooshing sound coming from the Java community? It was a collective sigh of relief as word got out about the results of the Public Review Reconsideration Ballot for JSR 376, the Java Platform Module System (JPMS) specification, better known as Jigsaw. In case you missed it, the votes were 24 in favor with one abstention (Red Hat). No "no" votes this time around.
A vote in May by the Executive Committee (EC) of the Java Community Process (JCP) to reject JSR 376 moved the Expert Group to address the EC's concerns at something approaching warp speed, and that's just what they seem to have done.
"I think it's fair to say that people were highly motivated to reach closure on all of these issues," Georges Saab, VP of Development for Oracle's Java SE Group, told me in an earlier interview.
Red Hat explained its decision to abstain in the voting comments section of the ballot page:
Red Hat is voting Abstain at this time because although we think there has been positive progress within the EG to reach consensus since the last vote, we believe that there are a number of items within the current proposal which will impact wider community adoption that could have been addressed within the 30-day extension period for this release. However, we do not want to delay the Java 9 release and are happy with the more aggressive schedule proposed by the Specification Lead and EG for subsequent versions of Java because getting real world feedback on the modularity system will be key to understanding whether and where further changes need to occur. We hope that the Project Lead and EG will continue to be as open to input from the wider Java community as they have been in the last 30 days and look forward to the evolution of Java being driven by data from users and communities beyond OpenJDK.
SouJava's comment accompanying its vote included a noteworthy admonition to the community:
As a lesson for future JSRs: the Java Language is a fundamental piece of the Java ecosystem. JSRs that touch the Java Language Specification, should be very careful that proposed changes be reflected in the early drafts. Creating confusion around such a fundamental part of Java is very detrimental to the whole Java ecosystem. We are glad that those issues have been resolved now.
SouJava's comment about "creating confusion around such a fundamental part of what Java is" speaks to the source of much of the angst around the coming of Java 9, which prompted Mark Reinhold in May to engage in an effort to dispel a number of misconceptions about Jigsaw in Java 9. He offered his top 10 from "a long list" during the Devoxx UK developer conference, and later interviews. (My coverage here).
It's also worth noting TomiTribe's voter comment on the process itself:
As stated in our first vote and blog, we saw great value in the 30-day clock getting the EC and EG on the same page with a clear result. The spec lead has done an outstanding job of handling the flood of feedback that resulted and should be congratulated. We believe several of the decisions made, such as permitting illegal access by default but with clear warnings will lead to a smoother transition that still creates pressure for movement into modularity. Though some may have viewed the original vote as negative, it should be seen as a success of the JCP process and a sign of strength for Java overall.
More remains to be done, of course. More than one "yes" voter included a few pointed comments about updates and refinements in future releases. Twitter's comment is a good example:
We are disappointed that the community will not immediately see the benefits that they are expecting JPMS to provide (#AvoidConcealedPackageConflicts, in particular). But we understand that the most requested features will require a lot more discussion and due-diligence than is allowed in the JDK 9 timeframe. We hope that the first version of JPMS will provide a good basis for such features to be worked on and introduced in future JDK releases.
It's a process, after all, and the impact of modularization on Java is hard to overstate. Some industry watchers have said the JPMS will effectively transform Java into a new language. As IBM put it in its voter comments, "We see this release of JPMS as the strong foundation for a new Java SE platform architecture, and expect to build upon this with feedback and experience from our customers and the community."
Posted by John K. Waters on July 17, 20170 comments
As JDK 9 enters the Release-Candidate Phase, it's worth noting exactly what that means for this oft-delayed release. In a nutshell, the Initial Release Candidate phase, which started on June 22, is about fixing "showstopper" bugs and building momentum toward the Final Release Candidate milestone, currently scheduled for July 6.
That's how Mark Reinhold put it in a note on Monday on the JDK 9 mailing list. He also proposed tightening the goals previously adopted for Rampdown Phase 2 (RDP 2). These include:
- Fixing all P1 bugs that are new in JDK 9 and critical to the success of this release
- Decommitting from fixing any P1 bugs that are not new in JDK 9 and are not critical to this release, but were previously targeted to this release
- Explicitly deferring any P1 bugs that are new in JDK 9 but are either not critical to this release or cannot, for good reason, be fixed in this release
Reinhold said that all P2-P5 bugs should be left to future releases at this point, regardless of whether they are in product code, tests or documentation.
P1 (priority 1) bugs are the critters that have to be squashed before a product can be released. Bugs that should be fixed if there's time and resources, are the P2s. The latter bugs almost certainly won't be addressed before the JDK 9 release.
Those who are responsible for the P1 bugs in JDK 9 are advised to follow one of three courses of action: Develop a fix for the bug and then request approval to integrate it; remove it from the list if it's not new in JDK 9; if it is new, but isn't critical or can't be fixed in time, request that the bug be deferred. The JDK 9 community page advises issuing a request explicitly from the release through the bug deferral process adopted earlier for RDP 1. But Reinhold wrote, "There is no need to defer unfixed P2-P5 bugs explicitly."
In any event, they won't be fixed before the release.
P3-P5 are of vanishing importance at this point in the process; they are virtually irrelevant to the overall status of the release. In fact, the OpenJDK community page advises committers to take no specific action on these bugs at this time: "You don't need to defer them, either explicitly via the deferral process or even implicitly by adjusting the 'Fix Version' field...."
The latest list of JDK 9 Release Candidate bugs can be found here.
Posted by John K. Waters on June 28, 20170 comments
Although he wants to continue pushing for a June 22 Release Candidate build, Mark Reinhold has announced a Sept. 21 General Availability release for the JDK 9 project. That's eight weeks past the previously scheduled July 27 GA release, which is going to be frustrating for many in the Java community. But there is reason to hope that this will be the final delay.
The holdup, as anyone who has been following the painfully slow crawl toward Java 9 knows, is mostly about JSR 376, the Java Platform Module System (JPMS) specification, better known as Jigsaw. Reinhold, the chief architect of Oracle's Java Platform Group, proposed two earlier delays, both times citing the challenges posed by Project Jigsaw.
But a vote in May by the Executive Committee (EC) of the Java Community Process (JCP) to reject JSR 376 seems to have sparked a real fire under the Expert Group, which met via video conference last month to address the EC's concerns about the current state of the project. Their goal was to submit a revised Public Review Draft Specification by June 7. The Public Review Reconsideration Ballot is now underway; voting ends on June 26.
The minutes of the Expert Group meeting are available now online, and they're well worth reading. In a nutshell, the EG worked out which issues raised by the EC during the first Public Review would need to be worked out now, which ones could wait for later, and which ones could wait forever. Several issues had already been sorted -- the EG wasn't sitting on its hands -- and several more were resolved at this meeting.
"I think it's fair to say that people were highly motivated to reach closure on all of these issues," Georges Saab, VP of Development for Oracle's Java SE Group, told me. "Meeting directly made a real difference, I think. Sitting down together allowed them to make more rapid progress."
Reinhold brought two "new information" items to the meeting: a proposal to allow illegal reflective access by default in JDK 9, and a proposal he's been talking about at conferences for a more rapid release cadence for Java SE and the JDK.
In her minutes, Iris Clark summarized the first item this way: "As more and more people have tested JDK 9 EA builds it has become clear in wide discussions over the past few months that turning off reflective access from code on the class path is too aggressive for the initial release. The proposal is to allow this access by default in JDK 9, and disallow it in a future release. A warning will be issued on the first access. This proposal will not address all migration concerns, but it changes the migration from one huge step to multiple smaller steps spread across multiple releases. This proposal is technically not part of JSR 376, since 376 is just about the module system; it is part of the JSR 379 platform specification, which will contain the necessary conformance text."
The second item, the idea that the Java ecosystem would benefit from more rapid releases, has been floating around Oracle and the JCP for a while. Clark summarized Reinhold's explanation this way: "Since the inception of Java, big features or a handful of big features have driven major releases every two to three years. This was reasonable in the 1990's and 2000's. Going forward, Java needs to move at a faster pace in order to remain competitive. People are, therefore, exploring the possibility of shifting to a yearly or even a six-month cycle. If a big feature is ready, it goes in; otherwise, it waits for the next release."
There's no formal proposal to crank up the Java release cadence right now, but it's coming, and, as Saab pointed out, the technology causing so many delays right now is probably going to be a key enabler going forward.
"The good news is, the Java Platform Module System and the encapsulation it ultimately provides, gives us a sound basis for doing that without disrupting people with the fears of incompatibility they would have had in the past," Saab said. "It makes it much clearer what the API is you should depend on, and it makes it far easier to test and confirm that you have the compatibility you want as you're doing those more rapid revs."
Reinhold published the new release schedule on the JDK 9 project page. Here's how it currently stands:
| Date |
Milestone |
| 2016/05/26 |
Feature Complete |
| 2016/12/22 |
Feature Extension Complete |
| 2017/01/05 |
Rampdown Start |
| 2017/02/09 |
All Tests Run |
| 2017/02/16 |
Zero Bug Bounce |
| 2017/03/16 |
Rampdown Phase Two |
| 2017/06/22 |
Initial Release Candidate |
| 2017/07/06 |
Final Release Candidate |
| 2017/09/21 |
General Availability |
Posted by John K. Waters on June 14, 20170 comments
James Gosling, the Father of Java, is on the move again. This time, according to a public post on Facebook, it's Amazon Web Services.
"It's time for a change," Gosling wrote. "I'm leaving Boeing Defense (nee Liquid Robotics), with many fond memories. Today I start a new Adventure at Amazon Web Services."
He also updated his LinkedIn profile with a generic AWS job title: "software engineer." He described his new gig this way: "Now I'm wandering around at Amazon Web Services."
Gosling, who was unavailable for comment as of this writing, has had a lively career since Oracle acquired his long-time employer, Sun Microsystems, back in 2010. The former Sun Fellow signed on briefly as CTO of Oracle's client software group, but left the company later that year for a short stint at Google. In 2011 he landed at Liquid Robots, a maker of "autonomous, ocean going platforms" acquired by Boeing last year. In 2014 he joined the platform development advisory team of Java/PHP Platform-as-a-Service provider Jelastic.
Gosling, who is credited with inventing the Java programming language in 1994, was one of the highest profile former Sun employees to leave Oracle following the $7.5 billion acquisition. CEO Jonathan Schwartz, chairman and co-founder Scott McNealy, director of Web technologies Tim Bray, and open source evangelist Simon Phipps never made the transition.
I asked around about Gosling's latest transition, and one Java watcher expressed what I found to be a consensus among those who care about such things: "Guys like Gosling will stay at a place only so long as they're able to do 'their work' (whatever that work is at the moment). When they start running into barriers -- orgs, funding, culture, etc. -- they find more welcoming venues and carry on." Another one put it this way: "The guy is semi-retired and jumping from one interesting thing to another."
From the company's point of view, Redmonk analyst Stephen O'Grady suggested, hiring Gosling could be about courting enterprise Java customers, leveraging his IoT expertise from Liquid Robotics, or just giving him room to experiment.
"Whatever the reality," he said in an e-mail, "it's an interesting and high-profile hire for AWS, one that will have PR benefits beyond whatever he can contribute technically."
Posted by John K. Waters on May 23, 20170 comments
When Wayne Citrin and his partners founded JNBridge back in 2001, Java was about five years old, .NET was still in beta, and the term "cross-platform interoperability" wasn't exactly rolling off the tongues of software vendors. But what seemed like irreconcilable differences at the start of the 21st century looked to Citrin and his partners like opportunity.
"We never had any doubt about this business," Citrin told me. "We'd go into the forums back when .NET was first introduced, and one of the most common questions we'd see was: Will I be able to use it with my existing Java? Microsoft was saying, Oh no, you'll want to take out that Java and rewrite it, or if you don't want to do that, we have something called J#, or we have these Java conversion tools. But there were all sorts of problems with those approaches. What was needed was a bridge between the two platforms, and that's what we provided."
JNBridge showed up on my radar nearly a decade ago at a JavaOne conference, and I've been talking with Citrin, who serves as CTO of the Boulder, Colo.-based company, regularly ever since. I covered his company's product announcements when they were newsworthy, of course, but I also found myself turning to him for his unique perspective on these important enterprise technologies. He's a thoughtful observer with a foot in two different worlds. (Sometimes downright hostile worlds: I think the year the company was founded Microsoft and Sun were suing each other.)
With anniversaries colliding this year -- both JNBridge (the product) and .NET turned 15, and Visual Studio turned 20 (Java turned 20 in 2015) -- it seemed a propitious moment to check in with the guy who spends his days getting Java and .NET to play nice.
Sixteen years is a respectable stretch for a niche tech company. How do you account for your continued success?
We recognized the value of that niche right away and focused on it exclusively. Then we went beyond the general-purpose bridge with the Adapters. And with our Labs, we're able to focus on the common and urgent scenarios people were tell us about.
Just to clarify, your namesake product, JNBridge, is a general purpose Java/.NET interoperability tool designed to bridge anything Java to .NET, and vice versa. Your Adapters connect the Java Message Service (JMS) with BizTalk Server and other .NET apps. And the Labs are free kits that showcase scenarios that bridge Java and .NET.
The JMS Adapters are a big part of our business, now. There's a lot of legacy JMS infrastructure out there. It's still one of the most common ways to connect components in an enterprise and pass data around.
What's the most significant change you've seen in Java in the past 15 years?
Most people would probably say it was the handoff of Java from Sun to Oracle. But I think the most significant change we've seen lately is the decline of Java EE and its replacement with a variety of open-source frameworks. Spring, the various Apache projects, the various web frameworks; I think this is probably a good thing. Java EE was too complicated and hard to use, there was a lot of ambiguity in the specs, and things were different from one app server to another. On the other hand, what you have now is a fragmentation with a whole lot of frameworks. The good news is, a lot of them are very good frameworks, easy to use, and supported by a committed community of users who actually like them.
We've talked about this before. You see a difference between Java EE and enterprise Java?
They're not the same thing, and they haven't been for a long time. Enterprise Java is not going away any time soon, and I think it's fair to call Java EE a subset that, in many ways, has had its day.
Looking specifically at the next versions of Java, which changes excite you the most?
I really like Jigsaw, the modularization coming in Java 9. A lot of people are worried about, but it's not such a big deal to us. They really did a good job of accommodating legacy code. If you have a non-modularized jar file, you can still use it in Java 9. You could use it in the crosspath or put it in the module path. You could do the same thing with a modularized jar file. You could also use it in an early version of Java; it just wouldn't be recognized it as a module. They put a lot of thought into this, and I applaud them for it.
But there's another great feature in Java 9 that hasn't gotten a lot of press. It's called multi-release jar files. The jar files in Java 9 have these nooks and crannies. There's a nook just for stuff Java 9 will know about; Java 8 doesn't know about this stuff and won't use it. Java 9 will look there first and override the general-purpose stuff in the jar file. I think is a very cool feature and we plan to use it going forward. We're just waiting for the tooling to catch up to make it easy.
While you've been watching the evolution of Java and .NET, you've also had a ringside seat for the evolution of the people using these platforms. How has the developer community changed over the past 15 years?
Fifteen years ago, developers had much more uniform characteristics. But there has been a noticeable bifurcation. With the rise of open source projects, we're seeing a large group of developers who are really interested in getting under the hood and understanding how things work. They're using lots of really cool tools to see what's happening at a much lower level, really getting their hands dirty and using those tools to solve problems. We're interacting with a lot of developer customers who are very sophisticated about this stuff in a way they weren't 15 years ago.
But we're also seeing a smaller group of developers who will go until they see a problem, and then stop and come to use for a solution. I'm not saying they're bad developers; they just have a different mindset. I think this group is the result of the rise of these frameworks I mentioned and a world of low-code development where things just work. Unless you really want to, there's no reason to look under the hood, and it's even kind of hard to do it. Plus, there's a lot of legacy software out there that just gets maintained, which we didn't see 15 years ago. Often people we're working with are not the original developers; they're just tasked with maintenance. And it might not even be their full-time job, just something they have to do on the side, and only when there's a problem or a new feature.
Speaking of mindsets, your company is now, and always has been, headquartered in Colorado, which is not exactly a high-tech hub. Why haven't you set up shop here in Silicon Valley?
I like it here in Colorado and don't see any reason to move. You don't need to be in Silicon Valley to run a successful tech business. And as expensive as office space is out there, it's cheaper just to get on a plane once in a while.
Posted by John K. Waters on April 12, 20170 comments
Mike Milinkovich, the executive director of the Eclipse Foundation, kicked off Eclipse Converge 2017 this week with an update for attendees on doings at the 13-year-old organization.
The Foundation grew over the past year to 331 projects, Milinkovich said, and the rate of increase seems to be accelerating. "In the past couple of quarters, we've had more new Eclipse project proposals than I can ever remember," he said. Milinkovich underscored the quality of the ongoing projects at the Foundation with a reminder of how vigorously his organization separates the wheat from the chaff. "We think it should be pretty easy to start an Eclipse project," he said, "but if it's not going well or there's not a lot of activity, we're going to garbage collect every summer."
More than 1,400 committers are currently involved in Eclipse project, he said. Many of the newer participants are drawn to the IoT projects and science group.
"We've worked really hard over the past few years to establish our Foundation as a community where both the biggest companies and the most interested individuals can collaborate successfully on projects," he said. He pointed to the Foundation's flagship Eclipse IDE as an example of a project that continues to draw "a mix and match" of companies and individuals.
Among the most popular of the Foundation's working groups is the Science Working Group, he said. The group's goal is to improve software for science -- things like biology and chemistry workbenches that make it easier for researchers to analyst as run experimental workflows. A founding member of that group, Tracy Miranda, co-founder of Kichwa Coders, a consultancy specializing in Eclipse tools for embedded and scientific software, became the first woman elected to the Eclipse Foundation board this year.
The relatively new Eclipse IoT group now accounts for 30 projects, he said, and for a significant percentage of the Foundation's growth. "We started with this about five and half years ago with a project called Eclipse M2M," he said. "The growth and evolution has been amazing to watch." Geospatial and automotive projects are popular areas of focus among Eclipse committers, he added. And he was especially proud of the work the Foundation has done to make the Eclipse Intellectual Property (IP) Policy more contributor friendly.
He also said that the 12th annual synchronized release of Eclipse projects known as the Release Train is on schedule for June. This year's release, codenamed "Oxygen," is expected to exceed last year's release by a few projects and a few lines of code. And he also promised that the Foundation will ship an Eclipse maintenance release the day Java 9 goes live.
I met with Milinkovich after his keynote to talk about what is arguably one of Foundation's most important but least sexy efforts: the new Eclipse IP Policy.
Approved last June, the new policy provides project owners with the option of foregoing the Foundation's traditionally intense code analysis for a more streamlined approach.
"Throughout the lifespan of a project, we do a deep analysis of all the dependencies," Milinkovich explained, "so that we can demonstrate that we know who wrote all the code that gets contributed at Eclipse. We look for third-party dependencies and check license capability. But we also check the code provenance. We scan their code, go through their email archives looking for conversations, analyze the code to see if any of it has ever been re-licensed. It's an enormous time investment, both for the Foundation and the committers."
When a new project comes to Eclipse, it can take weeks and even months to clear all the dependencies via this process.
"And boy, can that suck the air out of a room, "Milinkovich said. "I mean, you come to Eclipse with a project, and you're buzzing and excited to be there and you're ready to get going… and, oh yeah, you can't do crap for four months. Not a great thing for developers."
The alternative, called Type A, stops at checking license compatibility and does not check the provenance, which is similar to the approach used by the Apache Foundation, Milinkovich said.
"It gets projects off to a quick start," he said, "and we're finding that once the projects mature, the committers come back and ask for the Full Monty."
The one-day Eclipse Converge event is a new one for the Foundation. The idea was to provide an Eclipse-focused event during which North American developers could meet and share ideas. A range of Eclipse contributors, adopters, extenders, consumers, and researchers gathered at the San Jose Convention Center for the conference.
By design, the Converge event was held at the same venue and one day before the inaugural Devoxx US conference. The Devoxx program, launched in 2001, sponsors events in five countries (Belgium, UK, Morocco, France, Poland) and now the US. Event organizers bill the program as the provider of the largest vendor-independent developer events in the world, collectively. No EclipseCon North America conference is planned for 2017, due to the combined events of Eclipse Converge and Devoxx US. "We believe these two events will enable all members of the Eclipse community to come together and share new ideas, not just among other Eclipse community members," organizers said in a statement, "but also with some of the best and brightest in our industry."
Posted by John K. Waters on March 22, 20170 comments
I'm not sure what I expected when I finally connected with Gartner Vice President and Distinguished Analyst Anne Thomas last week to discuss a research note she co-authored that took heavy fire from critics in the enterprise Java community. But her chipper, glad-to-help-out response to my interview request shouldn't have surprised me; in the roughly two decades since we first met, I've found Thomas to be a responsive and thoughtful industry watcher with a relatively thick hide.
"It's my job to be controversial if that's what's needed," Thomas told me, "to make people take a step back and look at what's really going on."
What did surprise me was Thomas's contention that she and her critics are essentially on the same page.
Thomas wrote the report ("Market Guide for Application Platforms") with contributing analyst Aashish Gupta. In it the authors asserted, among other things, that Java EE has not kept pace with architectural trends and digital business initiatives, that Java developers are demonstrating a clear preference for lightweight frameworks over Java EE, and that Java EE is not an appropriate framework for building cloud-native applications. They also advised those responsible for modernizing an enterprise's application infrastructure to "develop a strategy to deal with the obsolescence of Java EE and other three-tier application frameworks."
Java EE community leaders called the Gartner analysts irresponsible and out of touch with the platform, and many blasted the report in blog posts and social media (and my inbox). I interviewed several of those critics for my January post, which includes links to some of the blogs.
Thomas was a bit surprised at the level of outrage over her and Gupta's observations on what she believes are obvious facts about Java EE and the evolving demands on enterprise developers.
"In the note I definitely acknowledged that Java is a tremendous platform for developing enterprise applications," she told me. "But Java EE is, by definition, this amalgam of this massive number of APIs, all of which the certification process says must be present in the platform. What I'm saying is, people don't need 90 percent of the stuff sitting in Java EE to build modern enterprise applications."
Some critics argued that Thomas and Gupta failed to recognize that Java EE has evolved since version 5 and the J2EE era, and that lighter-weight enterprise Java technologies, such as the Web Profile, IBM's WebSphere Liberty Profile, Red Hat's WildFly Swarm, Payara Micro and the new Eclipse MicroProfile, have emerged. Others insisted that the admittedly slower pace of Java EE's evolution is a strength of the platform; it's standards-based, which matters in the enterprise.
But the critics are, if inadvertently, helping to make Thomas's point, she said.
"I'm 100 percent in agreement with a lot of what these guys are saying," she said. "But they've got it in their heads that Java EE means all of Java. The new MicroProfile, for example, is just three Java APIs. That's great, but it's not Java EE."
Everyone understands that Java EE is overgrown, and none better than Thomas, who was working at Sun Microsystems when the platform was conceived and the seeds of that growth were planted.
"The original intention behind Java EE was to make sure that everything you could possibly want in the enterprise Java space was going to be available in any application server you decided to deploy it on," she recalled. "It was all about portability. If I'm building a Java application, I know I'll have this specific set of APIs and these specific versions, so that when I'm building an application I'll know it's there. That was a valuable proposition when Java EE was first created.
"The problem is it ended up becoming this incredibly bloated environment. Do I really need CORBA in applications that I'm building today? In the next version of Java EE, they are going to remove CORBA, so there is evolution happening. The Web Profile took out a bunch of things, and it's a much better environment for building application than a full-bore Java EE. But it's still very focused on three-tier, where the front-end tier is a Web environment. It's not designed to support multi-client-, multi-channel-type applications. It's not designed to support both Web and mobile, much less 20 or 30 other types of systems that are out there. It's not very well suited to support Internet of Things applications. And it's not designed to support microservices, which is why this independent group has gone off and said, we have to have a MicroProfile for Java EE."
One of the criticisms leveled against Thomas and Gupta's report was that they failed to differentiate between the Java EE standard and what Java EE vendors are building.
"Again, that supports my position," Thomas said. "What the vendors are building is not in conformance with the standard. They are building much smaller, much more focused implementations. They're not including everything but the kitchen sink in case somebody might need it.
"If you look at something like the Jetty Web server, for example, which a lot of people are using now to build their applications, I think it's now about 12MB in size. Compare that with the WebLogic platform, which is over 3GB in size. Why do I need such a big platform to host a microservice? It would be insane to use it. What I want is to embed Jetty, or Undertow, or Tomcat into my Spring Boot component, which is now an independently deployable component. I don't have to deploy it into an application server. I just put it into a container and deploy it directly onto my VM. That's what the new environment looks like."
Effectively, she went on to argue, Java EE and enterprise Java are no longer the same thing. And a modern enterprise Java platform for modern applications is emerging, not from Oracle or the older standards bodies, but from open source communities.
"Over the past five years, maybe longer, the open source communities have literally displaced the big standards bodies as a way of ensuring fast innovation and commonality across different systems," she said. It takes years for new standards to get produced through the Java Community Process (JCP). And that process is even slower now that Oracle is running the JCP. The fact is, open source in general is a much more effective way of creating community standards. Communities like Spring, CloudFoundry, Eclipse, Apache -- that's where innovation in Java in particular is happening."
Thomas also expressed her admiration for the work of groups like the Java EE Guardians and the MicroProfile.io initiative, but insisted that they aren't protecting Java EE, but enterprise Java.
"The MicroProfile is saying, this is the stuff that's important to us today," she said, "but Java EE does not give us what we need, so we have to build our own, because Oracle isn't doing that. And the Guardians recognize that Oracle isn't doing what is needed to maintain Java as a critical enterprise language and platform for the modern age."
Posted by John K. Waters on February 16, 20170 comments
Oracle's latest Critical Patch Update, the first of 2017, left Java security maven and Waratek CTO John Matthew Holt scratching his head about Big O's fix for a particular vulnerability: CVE 2017-3241, which affects Java SE, Java SE Embedded, and JRockit, and earned a CVSS score of 9.0 out of 10.0 (very bad).
Holt considers this CVE -- a deserialization vulnerability inside the core Java Remote Method Invocation (RMI) APIs -- especially serious, and he lamented Oracle's fix: a user-configurable whitelist/blacklist filter. He called deserialization an "application security nightmare," and Oracle's latest fix "easy, obvious and simple," but not especially effective.
"I'm really not knocking Oracle," he told me. "They did address the vulnerability, but it's a primitive form of defense, and far from what is considered to be the best way of dealing with it."
Serialization is the process of converting an object into a stream of bytes for transport and storage. Deserialization reverses the process when the data is received. Security researchers discovered that the RMI registry and DCG implementations in the RMI component of OpenJDK performed deserialization of untrusted inputs. A remote attacker could use this vulnerability to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
In its security advisory, Oracle explained it this way: "This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator)."
High-profile attacks that exploit deserialization vulnerabilities abound, Holt said. To give me a local example, he cited last year's deserialization attack on the San Francisco Metropolitan Transit Agency's Municipal Rail (MUNI to locals). As security researcher Brian Krebs reported in November, the ransomware attack caused fare station terminals to carry the message, "You are Hacked. ALL Data Encrypted," and fare payment machines to read, "OUT OF SERVICE" in red LED letters. An SFMTA Web-facing server was probably compromised by the deserialization attack after it was identified by a vulnerability scan. A similar vulnerability was exploited to attack Med Star, the Maryland health system, last spring, and deprive multiple hospitals of access to critical systems.
The problem with the Oracle fix, Holt said, is fourfold:
- Any heuristic or "hands-on" security technique based on whitelists/blacklists almost always requires intricate manual configuration and tuning to operate correctly.
- Anything requiring manual human configuration and tuning requires special domain-specific and app-specific knowledge to configure, is expensive to test and validate, and prone to mistakes and human errors.
- Incomplete or incorrect configuration/tuning virtually guarantees false-positive results, which will break application operation and service.
- Most security professionals know nothing about the serialization mechanics or dependencies of the applications they're tasked with securing, making the job of configuring whitelists/blacklists virtually impossible.
"The consequences of requiring an application owner to know everything about the application -- to be God -- which this approach does, is that you are essentially putting the entire burden of the effectiveness of that security system on the end user, instead of the system," Holt said. "If an attack is successful, it's not the system's fault, but the user's. And that's just not an effective approach."
Waratek has found a way to circumvent this heuristic approach, and in the process, established a niche in a market overflowing with large enterprises that continue to run custom-developed, mission-critical applications on out-of-date versions. The Dublin-based company's virtualization-based AppSecurity product is designed to protect the Java Platform attack surface from known and unknown vulnerabilities by virtually applying critical patch updates and security policies at runtime. Waratek uses a proprietary Smart Compartment to process deserialization without relying on black or white lists.
"Walk into any really large organization and ask them how many Java applications they've got, and they'll tell you, oh we have 500 server-side applications, or 1,000 or 5,000," Holt said. "This is something we hear regularly. No human being is going to sit down in those organizations and manually create individual deserialization lists for those applications."
One of the knottier challenges facing organizations when it comes to application security -- and one Oracle can't solve with a CPU -- is the typical skill sets of the people charged with it, Holt said. "If you look at the security team in any major organization," he said, "most of the people have backgrounds in network security or systems administration. That's traditional. But application security, which is a relatively new problem space, involves thinking about the security inside the application, and these skill sets are inherently outside the application."
Adding to that challenge: App security can be frustratingly language-specific, he said. "The way deserialization vulnerabilities work and are exploitable on Java are entirely different from the way serialization vulnerabilities are exploitable on .NET or Ruby."
Posted by John K. Waters on January 24, 20170 comments