Oracle CPU Does Little to Fix Serialization Vulnerability

By January 25, 2018 June 12th, 2018 News

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.


Oracle’s latest Critical Patch Update, the first of 2018, 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.”


The problem with the Oracle fix, Holt said, is fourfold:

  1. Any heuristic or “hands-on” security technique based on whitelists/blacklists almost always requires intricate manual configuration and tuning to operate correctly.
  2. 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.
  3. Incomplete or incorrect configuration/tuning virtually guarantees false-positive results, which will break application operation and service.
  4. 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.”


Read the full article here.

Article written by John Waters, ADT Magazine

ADT Mag

News

Author News

More posts by News
X