Java vs JavaScript

R

Roedy Green

There is something odd going on.

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

But Oracle and the browsers are acting like unsigned Applets are
highly dangerous, making you do override after override to run them.

On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

Why the double standard? Is JavaScript safer than I thought?
 
M

markspace

On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

JavaScript runs in a sandbox, but as far as I know it isn't very
restrictive. I think there's like a 4 megabyte limit *per site* for the
amount of data it can store on your hard drive, for example.

But yes I agree "something is going on." FireFox OS is what is going
on, and anything that runs in a browser that competes with it is being
extinguished by Brenden Eich and company.
 
J

Joshua Cranmer ðŸ§

There is something odd going on.

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

Unless the Java VM and/or runtime had security holes.
On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

"anything" is a bit of a misnomer here. The standard JavaScript runtime
profile doesn't allow you to:

1. Access the local filesystems
2. Spawn, communicate, or interact with other processes
3. Open generic network sockets
4. Execute arbitrary native code

All of these are possible with part of the standard Java library.

In general, the security model of Java appears to me to be more of an
afterthought, with ad-hoc securing of APIs. In contrast, the development
of JavaScript has tended towards not admitting new APIs until after
security reviews have been done on the APIs. Legacy APIs can be
problematic sometimes, but the mighty hammer of things like CORS or CSP
has reduced the scope of problems here.

Certainly, in the past several months, the browser developers appear to
have been taking security more seriously than Oracle has with Java.
 
S

Silvio

There is something odd going on.

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

But Oracle and the browsers are acting like unsigned Applets are
highly dangerous, making you do override after override to run them.

On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

Why the double standard? Is JavaScript safer than I thought?

In short: yes. Java was not designed to be safe in any particular way in
that it does not restrict you from doing anything potentially dangerous
(accessing file systems, doing socket level IO, executing native
code...). The runtime that executes your code is responsible for taking
away capabilities from the code as an afterthought. This is very hard to
do thoroughly and exhaustively.

JavaScript and it's traditional runtime profile (inside a browser
embedded in a web page) is very limited in what it can do.No need for
the browser to enforce much restriction (barring stuff like XSS).
Insecurity has to be added via libraries provided by the runtime.

Of course JavaScript still sucks as a programming language...

Silvio
 
A

Arne Vajhøj

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

That is true assuming there are no bugs in the Java applet security
implementation.

I think they have found 200-300 bugs during the last 2-3 years.
But Oracle and the browsers are acting like unsigned Applets are
highly dangerous, making you do override after override to run them.

If a bug in Java allows an unsigned applet to gain privs, then it is
extremely dangerous as a malicious site could run a 1 pixel applet
that infected the PC without the user not even knowing that Java was
running.

Apparently Oracle does no longer believe that they can fix all
security bugs.

Given the recent history, then that seems realistic.
On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

Not true.

JavaScript is sandboxed and has about the same access as an unsigned
applet.

And because there are no concept of signed JavaScript with granted
privs then it is probably easier to avoid bugs as the code must be
a lot simpler.
Why the double standard? Is JavaScript safer than I thought?

There has been found plenty of JavaScript bugs over the years.

But JavaScript has done better than Java in recent years.

Arne
 
R

Richard Maher

There is something odd going on.

I have always thought the Java sandbox was so restrictive, there was
nothing a user need worry about. There is no way an unsigned applet
could do any damage.

But Oracle and the browsers are acting like unsigned Applets are
highly dangerous, making you do override after override to run them.

I have commented in detail to your various other posts; the truth is out
there!
On the other hand I don't think JavaScript has any sort of sandbox at
all, and everyone blissfully runs scripts that can do anything.

I suggest/recommend/insist the dinosaurs here at java-IS-the-new-cobol
read the following several times over: -

https://wiki.mozilla.org/WebAPI

As usual the cognoscente here do not know what they are talking about
:-( WebApps have moved on but they'll never replace the functionality
Applets provide out-of-the-box!
Why the double standard? Is JavaScript safer than I thought?

Google, Apple, and Microsoft say Larry is a fat lazy vain old bitch who
is too tired to defend his patch.
 
R

Richard Maher

That is true assuming there are no bugs in the Java applet security
implementation.

I think they have found 200-300 bugs during the last 2-3 years.

So what? How does the imapact-meter rate with the likes of Heart-Bleed
and OpenSSL?
If a bug in Java allows an unsigned applet to gain privs, then it is
extremely dangerous as a malicious site could run a 1 pixel applet
that infected the PC without the user not even knowing that Java was
running.

You don't need a 1px applet; 0x0 is just fine. Once again, look at the
following link to BSD Socket functionality and Contacts lookup and so on
and then ask the Applet Slaggers to shut their fucking mouths!

https://wiki.mozilla.org/WebAPI
Apparently Oracle does no longer believe that they can fix all
security bugs.

Just the incompetent people they've hired.
Given the recent history, then that seems realistic.

Given you're a knob I need not respond.
Not true.

JavaScript is sandboxed and has about the same access as an unsigned
applet.

Wake up to modern Web-Apps!
And because there are no concept of signed JavaScript with granted
privs then it is probably easier to avoid bugs as the code must be
a lot simpler.


There has been found plenty of JavaScript bugs over the years.

But JavaScript has done better than Java in recent years.

There are none so blind as those who will not see.
 
R

Richard Maher

Agreed that this is not the way to design a security arhutecture if you have
the opportunity to build the thing from the ground up. (Of course, the
designers were in a tearing hurry at the time this stuff was set in stone).
Really?


Agreed that JS gains some security from the fact that it just doesn't have the
ability to touch as much as the Java runtime

https://wiki.mozilla.org/WebAPI
 
R

Richard Maher

Have you seen what some people can do with HTML5?

I've certainly seen it and done it (see the link I've posted several
times); many here haven't!

Show me true multi-threading with that Worker-Thread crap . . .

Show me true BSD sockets instead of that WebSocket shit that was tacken
out of the HTML5 standard because it was so functionally and security
deficient . . .

Show me global memory between multiple browser tabs and the intrinsic
segue to single-sign-n out of the box . . .

Show me someone who can think outside of Larry's bollocks JavaFX and
reel at the wonton functionality destruction at the hands of Eric
Costlow. . .

Show me someone who has lived in awe of Adobe Flex Charting for almost
10 years. . .

And I'll show you a sad and sorry newsgroup full of arse-wipes who see
life through lambda coloured glasses :-(
 
S

Stefan Ram

Chris Uppal said:
Agreed that JS gains some security from the fact that it just doesn't have the

I believe that JavaScript was and still is the main entry
surface for infections via Browsers. (Some of the following
URIs might be outdated, because I recorded the some time ago.)

»according to an alert issued Thursday by the U.S.
Computer Emergency Readiness Team (US-CERT), a division of
the Department of Homeland Security (...) A CERT alert
said Explorer users also can protect themselves by turning
off the JavaScript function in their browsers. «

http://www.washingtonpost.com/wp-dyn/articles/A6746-2004Jun25.html

»If JavaScript is enabled in these applications, then the
system is vulnerable to exploitation.«

http://www.uscert.gov/current/current_activity.html#iis5

Even Microsoft recommends to disable JavaScript:

»Under Security level for this zone, move the slider to High.«

http://www.microsoft.com/athome/security/online/browsing_safety.mspx

And Microsoft recommends not to click on links (Yes!) but to
type in URIs because of security risks by »javascript:«-links.

»Do not click any hyperlinks that you do not trust.
Type them in the Address bar yourself.«

http://support.microsoft.com/?id=833786

A web based computer magazine I read usually reports about
2 - 4 browser exploits and security holes a month and about
80 % of the time the advice is »until the manufacturer has a
patch finished, the problem can be avoided by disabling JavaScript«.

Some years ago, I started to collect such reports as a proof.
But then I ceased to collect more such reports, because I
needed my time for other things. Thus, when my records are
dated now, this does not mean that there are no more such
reports today; I just do not collect them anymore. If I
would have continued, the list would be very much longer.
(These reports are in German language.)

http://www.heise.de/newsticker/meldung/48769
http://www.heise.de/newsticker/meldung/48725
http://www.heise.de/newsticker/meldung/63430
http://www.heise.de/newsticker/meldung/48589
http://www.heise.de/newsticker/meldung/48016
http://www.heise.de/newsticker/meldung/48016
http://www.heise.de/newsticker/meldung/47993
http://www.heise.de/newsticker/meldung/60340
http://www.heise.de/newsticker/meldung/47998
http://www.heise.de/newsticker/meldung/47494
http://www.heise.de/newsticker/meldung/47282
http://www.heise.de/newsticker/meldung/46923
http://www.heise.de/newsticker/meldung/61499
http://www.heise.de/newsticker/meldung/60240
http://www.heise.de/newsticker/meldung/69558
http://www.heise.de/newsticker/meldung/66952
http://www.heise.de/newsticker/meldung/66943
http://www.heise.de/newsticker/meldung/66511
http://www.heise.de/newsticker/meldung/67698
http://www.heise.de/newsticker/meldung/67132
http://www.heise.de/newsticker/meldung/69894
http://www.heise.de/newsticker/meldung/68579
http://www.heise.de/newsticker/meldung/69225
http://www.heise.de/newsticker/meldung/66846
http://www.heise.de/newsticker/meldung/68391
http://www.heise.de/newsticker/meldung/69015
http://www.heise.de/newsticker/meldung/66480
http://www.heise.de/newsticker/meldung/66928
http://www.heise.de/newsticker/meldung/66350
http://www.heise.de/newsticker/meldung/64771
http://www.heise.de/newsticker/meldung/58788
http://www.heise.de/newsticker/meldung/61350
http://www.heise.de/newsticker/meldung/59374
http://www.heise.de/newsticker/meldung/60644
http://www.heise.de/newsticker/meldung/60855
http://www.heise.de/newsticker/meldung/64426
http://www.heise.de/newsticker/meldung/60615
http://www.heise.de/newsticker/meldung/68394
http://www.heise.de/newsticker/meldung/58228
http://www.heise.de/newsticker/meldung/61700
http://www.heise.de/newsticker/meldung/61646
http://www.heise.de/newsticker/meldung/61828
http://www.heise.de/newsticker/meldung/57578
http://www.heise.de/newsticker/meldung/56354
http://www.heise.de/newsticker/meldung/54973
http://www.heise.de/newsticker/meldung/59330
http://www.heise.de/newsticker/meldung/56795
http://www.heise.de/newsticker/meldung/56323
http://www.heise.de/newsticker/meldung/53382
http://www.heise.de/newsticker/meldung/59449
http://www.heise.de/newsticker/meldung/54272
http://www.heise.de/newsticker/meldung/56646
http://www.heise.de/newsticker/meldung/53186
http://www.heise.de/newsticker/meldung/53042
http://www.heise.de/newsticker/meldung/54063
http://www.heise.de/newsticker/meldung/52995
http://www.heise.de/newsticker/meldung/52935
http://www.heise.de/newsticker/meldung/55138
http://www.heise.de/newsticker/meldung/54716
http://www.heise.de/newsticker/meldung/52844
http://www.heise.de/newsticker/meldung/54431
http://www.heise.de/newsticker/meldung/54734
http://www.heise.de/newsticker/meldung/54487
http://www.heise.de/newsticker/meldung/54605
http://www.heise.de/newsticker/meldung/55396
http://www.heise.de/newsticker/meldung/53582
http://www.heise.de/newsticker/meldung/52776
http://www.heise.de/newsticker/meldung/52752
http://www.heise.de/newsticker/meldung/61245
http://www.heise.de/newsticker/meldung/52365
http://www.heise.de/newsticker/meldung/52377
http://www.heise.de/newsticker/meldung/54636
http://www.heise.de/newsticker/meldung/54719
http://www.heise.de/newsticker/meldung/54714
http://www.heise.de/newsticker/meldung/54697
http://www.heise.de/newsticker/meldung/52377
http://www.heise.de/newsticker/meldung/54582
http://www.heise.de/newsticker/meldung/52390
http://www.heise.de/newsticker/meldung/52255
http://www.heise.de/newsticker/meldung/54352
http://www.heise.de/newsticker/meldung/51995
http://www.heise.de/newsticker/meldung/51751
http://www.heise.de/newsticker/meldung/53644
http://www.heise.de/newsticker/meldung/60908
http://www.heise.de/newsticker/meldung/51511
http://www.heise.de/newsticker/meldung/50968
http://www.heise.de/newsticker/meldung/50363
http://www.heise.de/newsticker/meldung/50128
http://www.heise.de/newsticker/meldung/50111
http://www.heise.de/newsticker/meldung/50179
http://www.heise.de/newsticker/meldung/53489
http://www.heise.de/newsticker/meldung/52018
http://www.heise.de/newsticker/meldung/54188
http://www.heise.de/newsticker/meldung/49517
http://www.heise.de/newsticker/meldung/53499
http://www.heise.de/newsticker/meldung/49219
http://www.heise.de/newsticker/meldung/49219
http://www.heise.de/newsticker/meldung/49240
http://www.heise.de/newsticker/meldung/49240
http://www.heise.de/newsticker/meldung/49240
http://www.heise.de/newsticker/meldung/48877
http://www.heise.de/newsticker/meldung/48793
http://www.heise.de/newsticker/meldung/48892
http://www.heise.de/newsticker/meldung/53964
http://www.heise.de/newsticker/meldung/53519
http://www.heise.de/newsticker/meldung/53544
 
J

Joerg Meier

I believe that JavaScript was and still is the main entry
surface for infections via Browsers. (Some of the following
URIs might be outdated, because I recorded the some time ago.)

Nobody is doubting that JavaScript was a big offender ten years ago, but it
seems like it has been doing a lot better in more recent years.

Liebe Gruesse,
Joerg
 
S

Stefan Ram

»according to an alert issued Thursday by the U.S.
Computer Emergency Readiness Team (US-CERT), a division of
the Department of Homeland Security (...) A CERT alert
said Explorer users also can protect themselves by turning
off the JavaScript function in their browsers. «
http://www.washingtonpost.com/wp-dyn/articles/A6746-2004Jun25.html

And just today, many press stories are breaking about a
new zero-day drive-by security hole

http://www.us-cert.gov/ncas/current...t-Explorer-Use-After-Free-Vulnerability-Being

, and the suggestion sometimes given for this new hole is to
disable JavaScript in the IE by setting the Security Level
to »High«. They don't write it his way. They just write to
set the Security Level to »High«, but they usually do not
mention »JavaScript«.

A source says:

»The attack vector is quite ingenious in loading a Flash SWF
file, using it to selectively spray memory, and looping back
to a JavaScript program in IE.«
¯¯¯¯¯¯¯¯¯¯

The usual cuplrits: Flash and JavaScript.

However, nowadays, the press will not mention »JavaScript«
and often not even »Flash«, they avoid this, the security
problem is ascribed to the browser - after all the browser
hosts the JavaScript implementation and is the actual
program a person can install or deinstall. But »Java« is
mentioned each time when there is a security problem in the
JRE because »Java« /is/ an installable entity itself.

So, JavaScript is not mentionend in the press because it is
a technical details of the browser, while Java is a
freestanding product, not part of the browser. Because of
this avoidance of the mentioning of JavaScript, some people
do believe that JavaScript today has become more secure. But
you can find the technical details I quoted above if you
search for them.
 
A

Arne Vajhøj

So what? How does the imapact-meter rate with the likes of Heart-Bleed
and OpenSSL?

For number of actual impacted users: much higher.
You don't need a 1px applet; 0x0 is just fine.

That just makes it worse.
Once again, look at the
following link to BSD Socket functionality and Contacts lookup and so on
and then ask the Applet Slaggers to shut their fucking mouths!

https://wiki.mozilla.org/WebAPI

That does not remedy observed Java security problems.
Just the incompetent people they've hired.


Given you're a knob I need not respond.

Wake up to modern Web-Apps!


There are none so blind as those who will not see.

The stats are rather hard on Java:

October 2010 - 6u22 - 29 security fixes
February 2011 - 6u24 - 21 security fixes
June 2011 - 6u26 - 17 security fixes
October 2011 - 6u29/7u1 - 20 security fixes
Februar 2012 - 6u31/7u3 - 14 security fixes
June 2012 - 6u33-7u5 - 14 security fixes
August 2012 - 6u35/7u7 - 1/4 security fixes
October 2012 - 6u37/7u9 - 30 security fixes
February 2013 - 6u39/7u13 - 50 security fixes
February 2013 - 6u41/7u15 - 5 security fixes
March 2013 - 6u43 /7u17- 2 security fixes
April 2013 - 6u45/7u21 - 42 security fixes
June 2013 - 7u25 - 40 security fixes
October 2013 - 7u45 - 51 security fixes
January 2014 - 7u51 - 36 security fixes
April 2014 - 7u55/8u5 - 37 security fixes

Arne
 
S

Silvio

I think there's a lot of truth to that. A few years back, JavaScript was still
viewed with suspicion (justifiably), and as such it was a "live issue" and so,
when it was involved in security problems, it got mentioned. These days many
people take it for granted, and are no more likely to think of it as
"contributing to" an exploit where it is used than the surrounding HTML (if
any) is.

-- chris

That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

The same would hold for Java IF the browser would be the one running the
Java code. But instead the code is run by a third party plugin which
leaves the browser limited room to control what the code can do. Even
stuff like the standard library (which is where all the bombs are) comes
with the plugin so no way for the browser to take away or restrict
things there.

It is much easier to not provide a File/URL class than to provide a
third party one and then try to keep them constrained.
 
G

Gene Wirchenko

[snip]
That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

Oh, nonsense. Put an onclick= in an <a> tag to go to a different
URL than specified in the href=, and you have a security issue due to
JavaScript.

[snip]

Sincerely,

Gene Wirchenko
 
A

Arne Vajhøj

That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

Today a browser typical comes with distinct:
- layout/render engine
- JavaScript engine

And the two do not necessarily come from the same source.

JS engine is still more tightly coupled with the browser, because
it cannot (as far as I know) be replaced by the user. It may even
be linked into the same executable as the rest. But somewhere
at the source code level it is distinct.

Arne
 
S

Silvio

[snip]
That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

Oh, nonsense. Put an onclick= in an <a> tag to go to a different
URL than specified in the href=, and you have a security issue due to
JavaScript.

[snip]

Sincerely,

Gene Wirchenko

Now that is nonsense. Why is it a security issue if that is what the
HTML page says it should do? It is something that can be discovered from
the page itself and anything the JS instructs the browser to do it can
decide to refuse.

On the other hand IE allows the loading of ActiveX controls from
JavaScript and call native code on them which runs completely outside
the browsers control. Depending on the users security settings and how
correct these have been implemented in IE this is certainly an area of
concern. But that is only because IE deliberately implements this
functionality. That makes IE dangerous, not JS. BTW: ActiveX object can
also be loaded with HTML only.
 
S

Silvio

Today a browser typical comes with distinct:
- layout/render engine
- JavaScript engine

And the two do not necessarily come from the same source.

JS engine is still more tightly coupled with the browser, because
it cannot (as far as I know) be replaced by the user. It may even
be linked into the same executable as the rest. But somewhere
at the source code level it is distinct.

Arne

The fact that browsers may choose to use common libraries changes
nothing to the fact that it ultimately the browsers concern what these
libraries do. Webkit could have a major security hole in it. Does that
make HTML insecure?

As soon as the JS engine would become a user replaceable plugin I agree
things could become risky.

But then we would have created exactly the same situation as we have
with Java.
 
S

Simon Lewis

Gene Wirchenko said:
[snip]
That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

Oh, nonsense. Put an onclick= in an <a> tag to go to a different
URL than specified in the href=, and you have a security issue due to
JavaScript.

[snip]

Sincerely,

Gene Wirchenko

What total and utter ignorant bullshit.
 
G

Gene Wirchenko

[snip]
That is because JavaScript IS part of the HTML page and it can not
contain a security hole by definition. Only the browser displaying the
page can.

Oh, nonsense. Put an onclick= in an <a> tag to go to a different
URL than specified in the href=, and you have a security issue due to
JavaScript.

[snip]
Now that is nonsense. Why is it a security issue if that is what the
HTML page says it should do? It is something that can be discovered from
the page itself and anything the JS instructs the browser to do it can
decide to refuse.

Well, if you hover on the link, Firefox, at least, will display
the link as being according to the href= phrase, but the actual
destination will be according to the onclick= phrase.

Why should someone have to examine the page code to see what will
be done? Does that not suggest to you that someone might be trying to
pull a fast one? That situation is a security issue.
On the other hand IE allows the loading of ActiveX controls from
JavaScript and call native code on them which runs completely outside
the browsers control. Depending on the users security settings and how
correct these have been implemented in IE this is certainly an area of
concern. But that is only because IE deliberately implements this
functionality. That makes IE dangerous, not JS. BTW: ActiveX object can
also be loaded with HTML only.

This is also dangerous.

There is more than one mine in this security minefield.

Sincerely,

Gene Wirchenko
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top