Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23474 > unrolled thread

> Sandboxed power == More secure???

Back to article view | Back to comp.lang.java.programmer

Contents

  > Sandboxed power == More secure??? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-17 07:45 +0800
    Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-16 22:12 -0400
      Re: > Sandboxed power == More secure??? Lew <lewbloch@gmail.com> - 2013-04-16 19:25 -0700
        Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-16 22:30 -0400
      Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-17 09:14 -0700
        Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 13:09 -0400
          Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-17 11:37 -0700
            Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 15:49 -0400
              Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:10 -0400
              Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:13 -0400
                Re: > Sandboxed power == More secure??? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-17 21:12 -0400
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 21:34 -0400
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 21:39 -0400
        Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:06 -0400
          Re: > Sandboxed power == More secure??? Joerg Meier <joergmmeier@arcor.de> - 2013-04-18 03:04 +0200
    Re: > Sandboxed power == More secure??? Roedy Green <see_website@mindprod.com.invalid> - 2013-04-17 10:37 -0700
      Re: > Sandboxed power == More secure??? paul.cager@gmail.com - 2013-04-17 10:54 -0700
      Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-17 19:02 -0400
        Re: > Sandboxed power == More secure??? Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-04-25 10:09 +0800
          Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-24 22:30 -0400
          Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-25 08:54 -0700
            Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-26 22:11 -0400
              Re: > Sandboxed power == More secure??? markspace <markspace@nospam.nospam> - 2013-04-26 20:05 -0700
                Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-27 22:23 -0400
                Re: > Sandboxed power == More secure??? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-04-28 12:09 +0100
                  Re: > Sandboxed power == More secure??? Arne Vajhøj <arne@vajhoej.dk> - 2013-04-28 09:43 -0400

Page 1 of 2  [1] 2  Next page →

#23474 — > Sandboxed power == More secure???

Perhaps the most significant change will be that, in the default 
setting, sites will not be able to force the small programs known as 
Java applets to run in the browser unless they have been digitally 
signed. Users can override that only if they click to acknowledge the 
risk, Rizvi said.

Read more: 
http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B

Disbelief!

[toc] | [next] | [standalone]

#23478

On 4/16/2013 7:45 PM, Richard Maher wrote:
> Perhaps the most significant change will be that, in the default
> setting, sites will not be able to force the small programs known as
> Java applets to run in the browser unless they have been digitally
> signed. Users can override that only if they click to acknowledge the
> risk, Rizvi said.
>
> Read more:
> http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B
>
> Disbelief!

They want users to confirm that they want to run an applet.

It somewhat protects against users being infected without noticing if
a malicious site uses a zero day vulnerability.

And there has been a few of those.

Chrome already prompts every time.

A bit frustrating for user experience, but Oracle has deemed it
necessary.

Arne

[toc] | [prev] | [next] | [standalone]

#23480

Arne Vajhøj wrote:
> Richard Maher wrote:
>> Perhaps the most significant change will be that, in the default
>> setting, sites will not be able to force the small programs known as
>> Java applets to run in the browser unless they have been digitally
>> signed. Users can override that only if they click to acknowledge the
>> risk, Rizvi said.
>> Read more:
>> http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B
> 
>> Disbelief!

Really?

Rather overblown, that reaction.
 
> They want users to confirm that they want to run an applet.
> It somewhat protects against users being infected without noticing if
> a malicious site uses a zero day vulnerability.
> 
> And there has been a few of those.
> 
> Chrome already prompts every time.
> 
> A bit frustrating for user experience,

Really?

> but Oracle has deemed it necessary.

But only for unsigned applets.

Tempest in a teapot.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#23482

On 4/16/2013 10:25 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Richard Maher wrote:
>>> Perhaps the most significant change will be that, in the default
>>> setting, sites will not be able to force the small programs known as
>>> Java applets to run in the browser unless they have been digitally
>>> signed. Users can override that only if they click to acknowledge the
>>> risk, Rizvi said.
>>> Read more:
>>> http://www.smh.com.au/it-pro/security-it/oracle-fixes-42-holes-in-java-to-revive-confidence-20130417-2hz6n.html#ixzz2QfmbSO5B
>>
>>> Disbelief!
>
> Really?
>
> Rather overblown, that reaction.
>
>> They want users to confirm that they want to run an applet.
>> It somewhat protects against users being infected without noticing if
>> a malicious site uses a zero day vulnerability.
>>
>> And there has been a few of those.
>>
>> Chrome already prompts every time.
>>
>> A bit frustrating for user experience,
>
> Really?

That type of user confirmation does confuse large segments
of web users.

>> but Oracle has deemed it necessary.
>
> But only for unsigned applets.

Signed applets has had the requirement for user accept from day 1.

Arne

[toc] | [prev] | [next] | [standalone]

#23484

On 4/16/2013 7:12 PM, Arne Vajhøj wrote:

> A bit frustrating for user experience, but Oracle has deemed it
> necessary.

Yes.  I'm disappointed that Oracle can't make Java applets secure 
without resorting to a "click the box" experience for users.  JavaScript 
and Flash are secure without a special click-through dialog, why can't 
applets be the same way?

Still I understand practically speaking that this will in fact prevent 
some malicious attacks.

[toc] | [prev] | [next] | [standalone]

#23485

On 4/17/2013 12:14 PM, markspace wrote:
> On 4/16/2013 7:12 PM, Arne Vajhøj wrote:
>
>> A bit frustrating for user experience, but Oracle has deemed it
>> necessary.
>
> Yes.  I'm disappointed that Oracle can't make Java applets secure
> without resorting to a "click the box" experience for users.  JavaScript
> and Flash are secure without a special click-through dialog, why can't
> applets be the same way?

     Time to get my eyesight checked: When I read your post it
looked like a claim that Flash is secure!

     (Yesterday I applied security updates for both Java and
Flash, also AIR.  Any bets on which requires its next update
sooner?)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23488

On 4/17/2013 10:09 AM, Eric Sosman wrote:

>      Time to get my eyesight checked: When I read your post it
> looked like a claim that Flash is secure!

Well, you should get your eyesight checked.  Java is currently exploited 
far more often and far worse than Flash has been.  It's been all over 
the security related websites, and even some for the general public.  I 
see what you're saying, but Flash and Java don't really compare right 
now: things currently really bad for Java.  Example:

<http://www.securityweek.com/unique-challenges-controlling-java-exploits>

In short complaining that Flash really isn't secure is to complain about 
the mote in Flash's eye while ignoring the beam in Java's.

You still have a point though.  I use No-Script and both JavaScript and 
Flash are blocked by default on my system.  I guess I was referring to 
the fact that the vendors don't block their own systems by default.

I also like the UI for NoScript better than Java's security pop-up. 
It's better integrated into the browser and OS, and provides wider 
options than just "permanently allow this page."  Which I think is all 
that the Java plug-in has in terms of options.

>      (Yesterday I applied security updates for both Java and
> Flash, also AIR.  Any bets on which requires its next update
> sooner?)

I doubt frequency of updates correlates to security.  I'd guess that 
company culture and resources correlate more strongly.

[toc] | [prev] | [next] | [standalone]

#23489

On 4/17/2013 2:37 PM, markspace wrote:
> On 4/17/2013 10:09 AM, Eric Sosman wrote:
>
>>      Time to get my eyesight checked: When I read your post it
>> looked like a claim that Flash is secure!
>
> Well, you should get your eyesight checked.  Java is currently exploited
> far more often and far worse than Flash has been.  It's been all over
> the security related websites, and even some for the general public.  I
> see what you're saying, but Flash and Java don't really compare right
> now: things currently really bad for Java.  Example:
>
> <http://www.securityweek.com/unique-challenges-controlling-java-exploits>
>
> In short complaining that Flash really isn't secure is to complain about
> the mote in Flash's eye while ignoring the beam in Java's.

Searching the last three months' worth of the National Vulnerability
Database turns up 33 records for "Adobe Flash":

http://web.nvd.nist.gov/view/vuln/search-results?query=adobe+flash&search_type=last3months&cves=on

At a quick look I don't see how to search for "Java" without getting
"Javascript" at the same time, but searching for each in turn and
then subtracting gives 132-16=116 reports:

http://web.nvd.nist.gov/view/vuln/search-results?query=java&search_type=last3months&cves=on

http://web.nvd.nist.gov/view/vuln/search-results?query=javascript&search_type=last3months&cves=on

Admittedly, it's not as simple as "Java is 116/33=3.5 times worse
than Flash."  Some of the NVD notices cover multiple problems,
some cover only one.  Some "Java" problems are actually about
associated technologies like JBoss or non-Snoracle implementations
like IBM Java.  Different notices carry different CVSS severities,
and I haven't tried to catogorize them.

So the "3.5 times worse" figure certainly doesn't have two significant
digits, perhaps not even one full digit.  Still, "mote vs. beam" seems
to imply more difference of scale than the NVD data will support.

Let's face it: They're both bad.

> You still have a point though.  I use No-Script and both JavaScript and
> Flash are blocked by default on my system.  I guess I was referring to
> the fact that the vendors don't block their own systems by default.
>
> I also like the UI for NoScript better than Java's security pop-up. It's
> better integrated into the browser and OS, and provides wider options
> than just "permanently allow this page."  Which I think is all that the
> Java plug-in has in terms of options.

De gustibus, but my preference for a Java-safety UI is the simplest
one imaginable: I disable Java in my browsers, and never have to
worry about any popups at all.  Only two web sites that I (used to)
frequent require Java, and I've found I can live without them.

>>      (Yesterday I applied security updates for both Java and
>> Flash, also AIR.  Any bets on which requires its next update
>> sooner?)
>
> I doubt frequency of updates correlates to security.  I'd guess that
> company culture and resources correlate more strongly.

Yes, Adobe seems much more responsive -- at least, the frequency of
updates greatly exceeds Java's.  However, I didn't ask for bets about
when the next update would be available, but about when it would be
required.  :-(

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23496

On 4/17/2013 3:49 PM, Eric Sosman wrote:
> On 4/17/2013 2:37 PM, markspace wrote:
>> On 4/17/2013 10:09 AM, Eric Sosman wrote:
>>
>>>      Time to get my eyesight checked: When I read your post it
>>> looked like a claim that Flash is secure!
>>
>> Well, you should get your eyesight checked.  Java is currently exploited
>> far more often and far worse than Flash has been.  It's been all over
>> the security related websites, and even some for the general public.  I
>> see what you're saying, but Flash and Java don't really compare right
>> now: things currently really bad for Java.  Example:
>>
>> <http://www.securityweek.com/unique-challenges-controlling-java-exploits>
>>
>> In short complaining that Flash really isn't secure is to complain about
>> the mote in Flash's eye while ignoring the beam in Java's.
>
> Searching the last three months' worth of the National Vulnerability
> Database turns up 33 records for "Adobe Flash":
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=adobe+flash&search_type=last3months&cves=on
>
>
> At a quick look I don't see how to search for "Java" without getting
> "Javascript" at the same time, but searching for each in turn and
> then subtracting gives 132-16=116 reports:
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=java&search_type=last3months&cves=on
>
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=javascript&search_type=last3months&cves=on
>
>
> Admittedly, it's not as simple as "Java is 116/33=3.5 times worse
> than Flash."  Some of the NVD notices cover multiple problems,
> some cover only one.  Some "Java" problems are actually about
> associated technologies like JBoss or non-Snoracle implementations
> like IBM Java.  Different notices carry different CVSS severities,
> and I haven't tried to catogorize them.
>
> So the "3.5 times worse" figure certainly doesn't have two significant
> digits, perhaps not even one full digit.  Still, "mote vs. beam" seems
> to imply more difference of scale than the NVD data will support.
>
> Let's face it: They're both bad.

The whole concept of running code loaded from server in browser client
side is tricky.

In theory it can be done safe.

In reality bugs tend to sneak in.

Java applets, Flash, SilverLight, JavaScript etc..

No one has been able to supply and maintain over many years
such a product with security bugs.

Arne

[toc] | [prev] | [next] | [standalone]

#23497

On 4/17/2013 3:49 PM, Eric Sosman wrote:
> On 4/17/2013 2:37 PM, markspace wrote:
>> On 4/17/2013 10:09 AM, Eric Sosman wrote:
>>
>>>      Time to get my eyesight checked: When I read your post it
>>> looked like a claim that Flash is secure!
>>
>> Well, you should get your eyesight checked.  Java is currently exploited
>> far more often and far worse than Flash has been.  It's been all over
>> the security related websites, and even some for the general public.  I
>> see what you're saying, but Flash and Java don't really compare right
>> now: things currently really bad for Java.  Example:
>>
>> <http://www.securityweek.com/unique-challenges-controlling-java-exploits>
>>
>> In short complaining that Flash really isn't secure is to complain about
>> the mote in Flash's eye while ignoring the beam in Java's.
>
> Searching the last three months' worth of the National Vulnerability
> Database turns up 33 records for "Adobe Flash":
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=adobe+flash&search_type=last3months&cves=on
>
>
> At a quick look I don't see how to search for "Java" without getting
> "Javascript" at the same time, but searching for each in turn and
> then subtracting gives 132-16=116 reports:
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=java&search_type=last3months&cves=on
>
>
> http://web.nvd.nist.gov/view/vuln/search-results?query=javascript&search_type=last3months&cves=on
>
>
> Admittedly, it's not as simple as "Java is 116/33=3.5 times worse
> than Flash."  Some of the NVD notices cover multiple problems,
> some cover only one.  Some "Java" problems are actually about
> associated technologies like JBoss or non-Snoracle implementations
> like IBM Java.  Different notices carry different CVSS severities,
> and I haven't tried to catogorize them.
>
> So the "3.5 times worse" figure certainly doesn't have two significant
> digits, perhaps not even one full digit.  Still, "mote vs. beam" seems
> to imply more difference of scale than the NVD data will support.
>
> Let's face it: They're both bad.

Another statistic is the one from the original link:

"Java was the vehicle for 50 per cent of all cyber attacks last year in 
which hackers broke into computers by exploiting software bugs, 
according to Kaspersky. That was followed by Adobe Reader, which was 
involved in 28 per cent of all incidents. Microsoft Windows and Internet 
Explorer were involved in about 3 per cent of incidents, according to 
the survey."

Arne

[toc] | [prev] | [next] | [standalone]

#23499

On 4/17/2013 7:13 PM, Arne Vajhøj wrote:
>[...]
> Another statistic is the one from the original link:
>
> "Java was the vehicle for 50 per cent of all cyber attacks last year in
> which hackers broke into computers by exploiting software bugs,
> according to Kaspersky. That was followed by Adobe Reader, which was
> involved in 28 per cent of all incidents. Microsoft Windows and Internet
> Explorer were involved in about 3 per cent of incidents, according to
> the survey."

     I suspect that a would-be penetrator would try a long list
of vulnerabilities on each system visited.  Java vulnerabilities
would be particularly attractive, because they'd probably affect
many systems: Windows, Macs, Androids, UnameIts.  Also, it seems
common (with all kinds of software) that a large percentage of
the vulnerable population lags "the latest and greatest" by more
than a few days ...

     All in all, then, I think that if I were trying to penetrate
a large number of systems I would put my Java attacks near the
top of my hit list.  They wouldn't be alone, just "preferred."

     Things might be different if I were aiming at a particular
system.  If I were Hell-bent on breaking into XYZBank, I'd spend
a lot of time studying what XYZBank uses and researching how I
might subvert it.  But since

                  THREE BILLION DEVICES RUN JAVA

(according to Oracle's installation splash), if I'm just trolling
for easy marks I'll look for Java.  It's a simple matter of balancing
success rate (high) and vulnerability rate (ditto).

     In a sense, it's the same thing that happened to Windows.  When
Windows was the only game in town, *everybody* ran it and *everybody*
who wasn't up-to-date with the patch from twenty minutes ago was
dead meat.  Microsoft (to much derision, including mine) undertook to
improve Windows' security, and -- to their credit -- they've managed
to raise it to the "Not absolutely pathetic" level.

     Java has not yet attained that lofty standard.

     Java exposed to the Net is, as Mr. Nader might say, "Unsafe at
any speed."  Maybe Oracle will apply the resources needed to
resuscitate it, but I sort of think they won't: It's now viewed
as a server-side technology (and it's just fine there, and that's
where Oracle's big investments lie), so its client-side deficiencies
will just sort of sit there and rot.

     And rot.  And rot.  And rot.  And rot.  And rot.

     Friends don't let friends run Java in their browsers.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#23500

On 4/17/2013 9:12 PM, Eric Sosman wrote:
> On 4/17/2013 7:13 PM, Arne Vajhøj wrote:
>> [...]
>> Another statistic is the one from the original link:
>>
>> "Java was the vehicle for 50 per cent of all cyber attacks last year in
>> which hackers broke into computers by exploiting software bugs,
>> according to Kaspersky. That was followed by Adobe Reader, which was
>> involved in 28 per cent of all incidents. Microsoft Windows and Internet
>> Explorer were involved in about 3 per cent of incidents, according to
>> the survey."
>
>      I suspect that a would-be penetrator would try a long list
> of vulnerabilities on each system visited.  Java vulnerabilities
> would be particularly attractive, because they'd probably affect
> many systems: Windows, Macs, Androids, UnameIts.  Also, it seems
> common (with all kinds of software) that a large percentage of
> the vulnerable population lags "the latest and greatest" by more
> than a few days ...

Yep.

http://www.zdnet.com/java-based-attacks-remain-at-large-researchers-say-7000013131/

has a little figure showing how bad it is.

Arne

[toc] | [prev] | [next] | [standalone]

#23501

On 4/17/2013 9:12 PM, Eric Sosman wrote:
>      Things might be different if I were aiming at a particular
> system.  If I were Hell-bent on breaking into XYZBank, I'd spend
> a lot of time studying what XYZBank uses and researching how I
> might subvert it.  But since
>
>                   THREE BILLION DEVICES RUN JAVA
>
> (according to Oracle's installation splash), if I'm just trolling
> for easy marks I'll look for Java.  It's a simple matter of balancing
> success rate (high) and vulnerability rate (ditto).
>
>      In a sense, it's the same thing that happened to Windows.  When
> Windows was the only game in town, *everybody* ran it and *everybody*
> who wasn't up-to-date with the patch from twenty minutes ago was
> dead meat.  Microsoft (to much derision, including mine) undertook to
> improve Windows' security, and -- to their credit -- they've managed
> to raise it to the "Not absolutely pathetic" level.
>
>      Java has not yet attained that lofty standard.
>
>      Java exposed to the Net is, as Mr. Nader might say, "Unsafe at
> any speed."  Maybe Oracle will apply the resources needed to
> resuscitate it, but I sort of think they won't: It's now viewed
> as a server-side technology (and it's just fine there, and that's
> where Oracle's big investments lie), so its client-side deficiencies
> will just sort of sit there and rot.
>
>      And rot.  And rot.  And rot.  And rot.  And rot.
>
>      Friends don't let friends run Java in their browsers.

Oracle is not making a cent directly from applet usage.

And I have no doubt that is the reason why applet security
have been let us call it "less than perfect".

But they seem to be focusing strongly on it now.

And for good reasons.

In the public java has been labelled "security problem" and
the general public does not understand the difference between
applets and Java EE.

A lot of the managers authorizing paying millions of dollars for
Java based middleware may not know either.

I think the new interest in security is because the message
from Oracle sales people has been that these applet problems
are hurting general sales.

Arne

[toc] | [prev] | [next] | [standalone]

#23495

On 4/17/2013 12:14 PM, markspace wrote:
> On 4/16/2013 7:12 PM, Arne Vajhøj wrote:
>
>> A bit frustrating for user experience, but Oracle has deemed it
>> necessary.
>
> Yes.  I'm disappointed that Oracle can't make Java applets secure
> without resorting to a "click the box" experience for users.  JavaScript
> and Flash are secure without a special click-through dialog, why can't
> applets be the same way?

That is also how Java in theory should work.

But there had been several bugs allowing unsigned applets to
get privs.

And according to Oracle even with the many bug fixes done, then there
are still some bugs left.

To protect against those and against bugs not yet found, then
Oracle has decided to play it safe.

Arne

PS: Both JavaScript and Flash have previously had lots of security bugs,
     but the last year Java has been in the spotlight.

[toc] | [prev] | [next] | [standalone]

#23498

On Wed, 17 Apr 2013 19:06:57 -0400, Arne Vajhøj wrote:

> And according to Oracle even with the many bug fixes done, then there
> are still some bugs left.

> To protect against those and against bugs not yet found, then
> Oracle has decided to play it safe.

As a fellow ESL poster: your use of "then" in both of the above sentences
is wrong. Just remove it from both of them.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#23486

On Wed, 17 Apr 2013 07:45:12 +0800, Richard Maher
<maher_rjSPAMLESS@hotmail.com> wrote, quoted or indirectly quoted
someone who said :

>Perhaps the most significant change will be that, in the default 
>setting, sites will not be able to force the small programs known as 
>Java applets to run in the browser unless they have been digitally 
>signed.

This makes no sense. A digitally signed Applet does dangerous things.
Unsigned ones do not.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Computer programming is the best remedy for pain (physical or emotional) 
I have encountered. It requires so much concentration there is nothing left 
over to pay attention to the pain. They should teach this in AA.

[toc] | [prev] | [next] | [standalone]

#23487

On Wednesday, 17 April 2013 18:37:00 UTC+1, Roedy Green  wrote:
> This makes no sense. A digitally signed Applet does dangerous things.
> 
> Unsigned ones do not.

I think the problem is that there have been bugs in Java's security model such that an unsigned applet could exploit a bug and do dangerous things.

[toc] | [prev] | [next] | [standalone]

#23494

On 4/17/2013 1:37 PM, Roedy Green wrote:
> On Wed, 17 Apr 2013 07:45:12 +0800, Richard Maher
> <maher_rjSPAMLESS@hotmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
>> Perhaps the most significant change will be that, in the default
>> setting, sites will not be able to force the small programs known as
>> Java applets to run in the browser unless they have been digitally
>> signed.
>
> This makes no sense. A digitally signed Applet does dangerous things.
> Unsigned ones do not.

If you had followed what has happened in the Java world, then
you would know that Java has had a couple of zero day vulnerabilities
where unsigned applets could get full privs due to bugs.

If people only enable applets on trustworthy sites where they really
need Java, then they are much safer than if any web site can start
a Java applet.

Arne

[toc] | [prev] | [next] | [standalone]

#23634

On 4/18/2013 7:02 AM, Arne Vajhøj wrote:
> On 4/17/2013 1:37 PM, Roedy Green wrote:
>> On Wed, 17 Apr 2013 07:45:12 +0800, Richard Maher
>> <maher_rjSPAMLESS@hotmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> Perhaps the most significant change will be that, in the default
>>> setting, sites will not be able to force the small programs known as
>>> Java applets to run in the browser unless they have been digitally
>>> signed.
>>
>> This makes no sense. A digitally signed Applet does dangerous things.
>> Unsigned ones do not.

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

shed a bit more light on it. Thankfully the <param name="permissions" 
value="sandbox" /> parameter is there.
>
> If you had followed what has happened in the Java world, then
> you would know that Java has had a couple of zero day vulnerabilities
> where unsigned applets could get full privs due to bugs.

Yes and a couple more serious bugs were introduced with webstart and 
jnlp! If Oracle ever forces us to use that crap then I  will give up.
>
> If people only enable applets on trustworthy sites where they really
> need Java, then they are much safer than if any web site can start
> a Java applet.

  If people only enable JavaScript  on trustworthy sites where they really
  need JavaScript, then they are much safer than if any web site can start
  JavaScript.

Would you agree?

Java's great drawing card has been its ubiquity. Without that it's 
condemned to being the new Cobol.

If it's got security bugs then you fix them! Saying "This might be 
really bad for you" could capture the teenage market but everyone else 
is going to think you're taking the piss :-(

>
> Arne
>
>
>

Cheers Richard Maher

[toc] | [prev] | [next] | [standalone]

#23636

On 4/24/2013 10:09 PM, Richard Maher wrote:
> On 4/18/2013 7:02 AM, Arne Vajhøj wrote:
>> If people only enable applets on trustworthy sites where they really
>> need Java, then they are much safer than if any web site can start
>> a Java applet.
>
>   If people only enable JavaScript  on trustworthy sites where they really
>   need JavaScript, then they are much safer than if any web site can start
>   JavaScript.
>
> Would you agree?
>
> Java's great drawing card has been its ubiquity. Without that it's
> condemned to being the new Cobol.
>
> If it's got security bugs then you fix them! Saying "This might be
> really bad for you" could capture the teenage market but everyone else
> is going to think you're taking the piss :-(

There has been a lot of attention on finding bugs in Java. And it has
resulted in finding exploits. And Oracle believes that there are still
security holes. It is not as if they are not fixing problems. They have
closed so many security holes the last 3/4 year. But they know that
they are not where they want to be yet. So it is not theoretical
issues they are protecting against it is real issues.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web