> Sandboxed power == More secure???

[markspace]

I think it's madness but the docs at: -
https://www.java.com/en/download/help/appsecuritydialogs.xml#background

http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

Thanks for posting these. That second document has some links of its
own, one of which is here:

<http://www.oracle.com/technetwork/java/seccodeguide-139067.html>

That if you ask me is a pretty stunning indictment of Java's broken
security model. The amount of work they push onto the developer, and
the amount of security code that must be understood before writing any
applet is pretty astounding.

Oracle should really devote some resources to fixing this. And by
"fixing" I mean obviating every last item in that document.

 

[Arne Vajhøj]

Thanks for posting these. That second document has some links of its
own, one of which is here:

<http://www.oracle.com/technetwork/java/seccodeguide-139067.html>

That if you ask me is a pretty stunning indictment of Java's broken
security model. The amount of work they push onto the developer, and
the amount of security code that must be understood before writing any
applet is pretty astounding.

Oracle should really devote some resources to fixing this. And by
"fixing" I mean obviating every last item in that document.

I don't think that is possible or desirable.

A lot of this has to be done by the developer based
on context.

Arne

 

[markspace]

I don't think that is possible or desirable.

A lot of this has to be done by the developer based
on context.

I see a few things in that document that should be done by the
developer. I see a lot more that really shouldn't be the developers
concern, under any circumstances.

I'd honestly like to see some discussion about it because I'd like to
propose some fixes to Oracle. Otherwise I think applets are just plain
doomed.

For example, some "context" for applets that I'm concerned about where
Oracle pushes security onto the developer:

1. Mutable statics. This includes private fields, if I read the
document aright.

2. "Exceptions." WTH?

3. Call backs, including applets, which are apparently invoked with full
permissions.

All of those are big areas of concern. I honestly don't see what to do
with the mutable statics. You need globals in any non-trivial app.

Exceptions cause a security breach? How the heck I'm I supposed to deal
with that?

And applets are all callbacks, so apparently the Java plug-in can't even
call my applet correctly at all.

Those are all issues, and they need to be addressed in a serious way.
Or Oracle is simply not going to have any presence on the desktop in any
way. Which would be too bad, because imo there's a need for more
platforms than just the vendor supplied (Windows, *nix) ones.

 

[Arne Vajhøj]

I see a few things in that document that should be done by the
developer. I see a lot more that really shouldn't be the developers
concern, under any circumstances.

* release resources
* protect against integer overflow
* no sensitive info in exceptions
* no sensitive info in logs
* protect against SQL injection
* protect against XSS
* limit visibility
* validate input
* no sensitive info serialized
* check access
etc.

are all very important items. And pretty close to OWASP.

But doing this is programming.

Java language/Java library/Java VM can do this for programmers.

I'd honestly like to see some discussion about it because I'd like to
propose some fixes to Oracle. Otherwise I think applets are just plain
doomed.

For example, some "context" for applets that I'm concerned about where
Oracle pushes security onto the developer:

1. Mutable statics. This includes private fields, if I read the
document aright.

They note that even if private then there is most likely a method
to change it with.

They are expressing concerns because JavaScript / other applets may
change state of an applet.

2. "Exceptions." WTH?

What about exceptions?

The need to free resources and not reveal sensitive information
is valid for most Java not just applets.

3. Call backs, including applets, which are apparently invoked with full
permissions.

Applets are not invoked with full permissions.

But the text is interesting:

<quote>
Guideline 9-2: Beware of callback methods

Callback methods are generally invoked from the system with full
permissions. It seems reasonable to expect that malicious code needs to
be on the stack in order to perform an operation, but that is not the
case. Malicious code may set up objects that bridge the callback to a
security checked operation. For instance, a file chooser dialog box that
can manipulate the filesystem from user actions, may have events posted
from malicious code. Alternatively, malicious code can disguise a file
chooser as something benign while redirecting user events.

Callbacks are widespread in object-oriented systems. Examples include
the following:

Static initialization is often done with full privileges
Application main method
Applet/Midlet/Servlet lifecycle events
Runnable.run
</quote>

I can't quite see what scenario they are talking about.

Those are all issues, and they need to be addressed in a serious way. Or
Oracle is simply not going to have any presence on the desktop in any
way.

Applets are only one type of desktop app.

Normal Java apps run with full permission anyway.

And neither applets nor Java desktop apps are widely used.

Oracle does not make a cent from applets or Java desktop
apps, so they most likely do not care about usage.

I am assuming that Oracle's only interest in this is to preserve
Java's "good name". Because Oracle is selling billions of
dollars of server side Java stuff. And if everybody get the
impression that Java is "insecure", then it could hurt that
business.

Arne

 

[Arne Vajhøj]

The main thing that's wrong with it, to my mind, is that it's so bloody long!

And as a result I haven't bothered to read all of it (and don't intend to). By
my impression of it after a quick skim is that it's made up of four kinds of
guidance:

Motherhood and apple pie stuff (Restrict privileges, Do not log highly
sensitive information, Validate inputs,...) which would apply to pretty-much
any code in any language on any platform (where security is any kind of concern
at all). We can't fault them on that, but it might be better split out into
separate guidance ("What every would-be programmer should know before being
allowed within twenty miles of a computer").
Yep.

Stuff that basically can be paraphrased as "Yup, Sun designed the language
wrong -- we'll all have to live with it. Sorry..."). Integer overflows (not
only do they happen but they happen silently!). Lack of a /convenient/ way of
managing limited resources (such as C#s "using" syntax). Lack of immutable
references (though I have my doubts about whether that can be made meaningful
/and/ useful). Even /having/ public (or protected) mutable fields in the
language at all. Public constructors (rather than factory methods). Etc...

C# using was added in Java 7.

A few examples of plain daft behaviour of the platform classes which should be
fixed pronto. (Such as allowing HTML in Swing components by default). Just
about everything to do with serialisation.

And the last category can be summed up as "the security model is too
complicated, and very easy to get wrong". That's the biggest (by linecount)
item. Not sure what to do about that. Maybe a library along the lines of Doug
Lea's concurrency stuff that hides all the fragile mess inside nice tight
interfaces with clear simple guidelines ?? I say that, but I'm not going to
claim that /I/ could design and implement such a beast (not without
language/JVM changes anyway).

Libraries that are powerful, flexible, simple, secure
and good performing are not easy to write.

I was under the impression that each applet ran in its own classloader. Am I
wrong ? If not then mutable statics are no worse a problem in applets than
they are anywhere else.

I think the concern is that something internal can alter the state and
thereby alter the execution of the applet.

JavaScript can access fields and call methods in an applet.

Arne