Java vs JavaScript

Discussion in 'Java' started by Roedy Green, Apr 23, 2014.

  1. Roedy Green

    Roedy Green Guest

    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?
    Roedy Green, Apr 23, 2014
    1. Advertisements

  2. Roedy Green

    markspace Guest

    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.
    markspace, Apr 23, 2014
    1. Advertisements

  3. Unless the Java VM and/or runtime had security holes.
    "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.
    Joshua Cranmer ðŸ§, Apr 23, 2014
  4. Roedy Green

    Silvio Guest

    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, Apr 23, 2014
  5. Roedy Green

    Arne Vajhøj Guest

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

    I think they have found 200-300 bugs during the last 2-3 years.
    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

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

    Given the recent history, then that seems realistic.
    Not true.

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

    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.

    Arne Vajhøj, Apr 24, 2014
  6. I have commented in detail to your various other posts; the truth is out
    I suggest/recommend/insist the dinosaurs here at java-IS-the-new-cobol
    read the following several times over: -

    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!
    Google, Apple, and Microsoft say Larry is a fat lazy vain old bitch who
    is too tired to defend his patch.
    Richard Maher, Apr 24, 2014
  7. So what? How does the imapact-meter rate with the likes of Heart-Bleed
    and OpenSSL?
    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!
    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.
    Richard Maher, Apr 24, 2014
    Richard Maher, Apr 27, 2014
  9. 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 :-(
    Richard Maher, Apr 27, 2014
  10. Roedy Green

    Stefan Ram Guest

    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. «

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

    Even Microsoft recommends to disable JavaScript:

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

    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.«

    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.)
    Stefan Ram, Apr 27, 2014
  11. Roedy Green

    Joerg Meier Guest

    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 Meier, Apr 27, 2014
  12. Roedy Green

    Stefan Ram Guest

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

    , 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.
    Stefan Ram, Apr 29, 2014
  13. Roedy Green

    Arne Vajhøj Guest

    For number of actual impacted users: much higher.
    That just makes it worse.
    That does not remedy observed Java security problems.
    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 Vajhøj, Apr 30, 2014
  14. Roedy Green

    Silvio Guest

    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.
    Silvio, May 1, 2014
  15. [snip]
    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



    Gene Wirchenko
    Gene Wirchenko, May 1, 2014
  16. Roedy Green

    Arne Vajhøj Guest

    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 Vajhøj, May 2, 2014
  17. Roedy Green

    Silvio Guest

    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.
    Silvio, May 2, 2014
  18. Roedy Green

    Silvio Guest

    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.
    Silvio, May 2, 2014
  19. Roedy Green

    Simon Lewis Guest

    What total and utter ignorant bullshit.
    Simon Lewis, May 2, 2014
  20. 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.
    This is also dangerous.

    There is more than one mine in this security minefield.


    Gene Wirchenko
    Gene Wirchenko, May 2, 2014
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.