Friday, May 17, 2013

The current Java is update 7u21. There will never be a 7u22.

Write once, run everywhere. It's secure because it runs in a sandbox.

Eventually, even the largest IT marketing machines cannot overcome IT reality--social issues are a whole different thing, but (mostly) out of scope for this post.

"Write once, debug everywhere," is commonly heard. And we really don't understand how to reliably and easily build secure sandboxes, from chroot jails on up.

But I believe a page titled  Java SE - Change in Version Numbering Scheme to be a landmark. So far as I know, this is the first time that a major vendor of 'Enterprise' software has pretty much admitted complete defeat on the security front. Microsoft came close, several years ago (they have gotten much better), but this is an admission of  abject defeat.

Oracle has never had a good rep, on several fronts. Hardball business tactics and vendor lock-in don't really concern me here. That is an easy Web search away, if you aren't already affected by it. Being widely regarded as the least secure of the 'Enterprise' DB vendors does, but only insofar as it is symptomatic of the current problem. Which is that Oracle has not only consistently produced horrible products, but they have been very slow to fix their problems.

The way Java updates worked in the past was

  1. Limited Update patches (feature adds and and non-security bugfixes) got even update numbers.
  2. Critical Patch Updates (CPUs) got odd update numbers.
They are done with that. There have been so many security flaws that they have had to renumber releases, which causes huge problems for users in risk analysis, patch scheduling, etc. The majority of the problems involved Java running in Web browsers, not server-side Java.

That was the one ray of sunshine, but security teams had to take very careful looks at exactly what was being run, and where. Multiple versions, installed on the same PC, were a problem. Common exploit code can call the vulnerable version if it is available. And some organizations did not prevent Java installation, of any version, regardless of whether it was really necessary on that employee machine. To make matters worse, a common installation scenario involved developer and QA machines. These users could often mount a specious argument that they needed it to do their jobs, and would be given blanket permissions. 

It was, and is, completely fubar. It is a really great way to make an adversary's job easier.

So, Oracle has at last bagged it. How have they admitted complete defeat (though not in so many words, of course)? Like 1970 BASIC programmers, leaving space between line numbers. 

Limited Update patch numbers are assigned in increments of 20. That leaves fill-in-the-blanks room for CPUs that will be issued as odd numbers that are increments of 5. Leaving still more fill-in-the-blanks room toad more fixes, and/or fix their previous fixes. And they reserve the right to use even numbers in those CPU intervals. I would guess that they are expecting more than a few.

Buy Oracle products. Because Larry Ellison needs a bigger yacht, more CA beachfront property, or another Hawaiian island. It's the right thing to do, because Larry is a caring kind of guy.

6/4/13 Update. This just gets gets better and better. See Java Security Revisited--Part 1.

Sunday, May 5, 2013

I Really Need a Document Management System

[gregm@feynman ~]$ du -hs $HOME
52G     /home/gregm
[gregm@feynman ~]$ find $HOME -type f -name *pdf | wc -l
[gregm@feynman ~]$ 

That 'working set' is nothing, in terms of storage requirements; it's a speck on Terrabyte drives. The requirements are so low because there are very few media files. I don't 'do' media, as a rule. I want my favorite entertainment producers to get paid, so that they can keep entertaining me. I buy DVDs, have only ripped MP3s from CDs that I bought (years ago, and still have) etc.

But there are also large numbers of text files (notes and code), email, spreadsheets, etc. That stuff, combined with the PDFs, is important, in the sense that having this stuff on tap, efficiently accessible, is directly related to whether I can make a living at protecting people and the things that are important to them. I'd obviously like to continue to do that, as it's one of the more worthwhile things I can do with my life. And life is all too short.

Currently, I am most concerned with the PDFs. Some small percentage are chapter-by-chapter downloads of books from my Safari account. Those can be recreated, and there are other examples of PDFs that I am not very concerned about. But a large number, were they lost, would be difficult to replace, for a variety of reasons. 
  • An academic has changed positions
  • A commercial entity has ceased operations, deleted old files, etc.
  • A security industry private researcher has lost interest and allowed their site to lapse
  • I do not have data on why that missing file is important, and/or the source
  • Other. And 'Other' is large.
I'm very old-school about having a well-organized file system; I know how my directories are organized, and I'm far from reliant the file indexing systems that bog so many systems down. Nor am I fan of various 'tagging' systems; their usefulness seems ephemeral in that it's mostly useful in the scope of a single project, or a small number of related projects. It is perhaps likely that these would also be ephemeral, while I am also interested in the broad sweep of history, and how these things evolve over time. 

The notion of keeping a good mental reference breaks down at 5000 files. Is something filed under privacy, breaking anonymized data, or what?

I need a more formal document control, or library system. Current approaches seem to revolve around the Semantic Web (e.g. the 2012 ACM Computing Classification System ( is one approach, etc. One program I am particularly interested in is Invenio, which has roots from CERN (birthplace of the Web, and home of the Large Hadron Collider), but is now a collaboration involving The Stanford Linear Accelerator Center, Fermilab, and others. Details are at