...iOS? How so?
"...including iOS" - how so? iOS doesn't even allow Java - how could it possibly be vulnerable to a Java deserialization bug?
November's high-profile Java deserialisation bug has bitten Cisco, with the company announcing vulnerabilities across the board in its huge product line. The problem is so pervasive that it reaches into the most trivial activities of the sysadmin, such as serial number assessment services. The original advisory made by …
“Any application or application framework could be vulnerable if it uses the ACC library and deserializes arbitrary, user-supplied Java serialized data”.
While the fire is lit by the the Java ACC library's unsanitary handling of input to be deserialized, this type of bug keeps appearing again and again... ad infinitum. Arbitrary, user supplied input improperly handled.
How many "developers" do we need to execute before this stops?
How many "developers" do we need to execute before this stops?
Try "educating" instead of "executing". The problem with the approach of executing those that make mistakes is that there is no opportunity to learn from experience. One of the reasons all bloody tyrannies eventually fail.
the Java ACC library's unsanitary handling of input to be deserialized
Actually, no. First, that should really be "the ACC Java library", or some such; ACC isn't part of Java. But more importantly, the problem is that the transformer class in ACC can be coaxed into executing any Runnable during deserialization, so if you have an application that 1) performs unsanitary deserialization and 2) has ACC on the class path, then you're vulnerable.
The issue isn't unsanitary deserialization in ACC per se. It's unsanitary deserialization anywhere. ACC was just used in the original AppSecCali presentation and the Foxglove elaboration of the technique to create dangerous payloads.
Arbitrary, user supplied input improperly handled.
Yes. That is indeed the core problem.
How many "developers" do we need to execute before this stops?
Fortunately, if you make them Runnable, you can just package them up and pass them to one of the vulnerable applications, and it'll execute them for you.
deserializes arbitrary, user-supplied Java serialized data
Kornheiser_Why.jpg
If only there was a tool that traced the trusthworthyness of data flowingf through a system....
Aliens, because they also forgot to check data coming from an Apple laptop directly to the Queen Mothership over Alien Wifi, with dire consequences.
Also widely done in other languages. Frohoff's original Marshalling Pickles presentation from AppSecCali 2015 is very much worth viewing.
Anyone who thinks lots of developers aren't doing this in lots of applications, in lots of languages, is sorely mistaken. It may strike some of us as a rookie mistake, but until the industry gets serious about training developers in security, we're going to keep seeing it.
Browser yes, but on a desktop there is a good case for java. There is still no viable alternative for cross platform UIs, over the years I've developed apps that run unchanged on linux, windows, macs, solaris and irix. Write once debug everywhere is not something I've encountered
"Does HTML5 browser based UI's give you an alternative? Just asking, I'm not a programmer."
Well, Cordova will wrap web pages for OSX and Windows 8+ (And IIRC Windows10 supports HTML5 apps natively.) For earlier versions, there are Chrome Apps, if you can persuade your users to install them, or nw.js
Generally, the problem is the need to access native file/print dialogs and other native APIs. Most of these approached provide some solutions or the options for plugins. So if you're doing cross-platform, explain to me why you won't write the UI in HTML5. (We have a Java app, but it will be slowly converted and retired.)
Refrain from insulting the source of my income.
Also, there are plenty of ways of pointing out deficiencies in Java without using plain lies.
Java on a server, today, is fast, it isn't harder to maintain than other technologies, and IS cross-platform unless you are a moron or needed something very specific.