116 replies to this topic

[Avohir]

you know... it strikes me that if this is an exploit... then the SpywareInfo #privacy chat applet has been exploiting java for a GOOD long while

[rob_]

slotch.com, is the the canadian firm sending this garbage PE file out (just check the lil' URL for the PE file inside the exploit code posted above).

www.slotch.com = [ 216.127.33.119 ]
Registrant:
  Integrated Search Technologies
  3300 Cote-Vertu
  Suite 406
  Montreal  Quebec H4R 2B7
  CA
  Domain name: SLOTCH.COM
  Administrative Contact:
      Search Technologies  Integrated  domain@isearchtech.com
      3300 Cote-Vertu
      Suite 406
      Montreal  Quebec H4R 2B7
      CA
      514-448-9727    Fax: 514-334-7088
  Registrar of Record: TUCOWS  INC.
  Record last updated on 29-Oct-2004.
  Record expires on 27-Nov-2005.
  Record created on 27-Nov-2002.

Slotch.com provides an unrivalled opportunity for a variety of clients. Visitor numbers continue to increase as Slotch.com establishes itself as an innovative search engine tool.

Too funny.

edited by request

Edited by Efwis, 14 March 2005 - 05:12 PM.

[Efwis]

actually harpwolf works for Yahoo, contacted me by YIM

[rob_]

Ah, good to know. If I had permission to edit my last message, I'd remove any reference to his post. The rest of the information still stands.

[Efwis]

ask and ye shall recieve, you want it edited rob?

[rob_]

Aye that would be great. Thanks.

[rob_]

Here are a couple more choice quotations from Integrated Search Technologies' registered websites:

By downloading the toolbar you agree to the terms and conditions. In order for the toolbar to be free, other complementary sofware's [sic] are installed.

Complimentary software, that's funny.

Products aimed for advertisers- Worldwide Pop Distribution System, contact us for details.

At least these people have a sense of humor.

Get paid up to $0.25 per install.  With your sitebar, you can increase traffic to your site as well as generate new incomes from constant streams of loyal visitors. SP2 Compatible, Custom ActiveX & Java Script Prompt, Easy Access to .EXE File, 5% Webmaster Referral

Loyal same as unwitting and or unwilling?

xxx toolbar is a free search utility

Freely installs itself upon visiting.

IST targets the customers through several different delivery methods such as highly effective toolbars and plugins available for Internet Explorer.

Coming soon to Firefox.




I especially like that their certificate was issued for "Secure Application Development". Had this valid certificate not expired, would a Firefox user see any sort of warning at all?

Attached Thumbnails

• 

Edited by rob_, 14 March 2005 - 04:50 PM.

[The Computer Valet]

So I would respectfully disagree that the average user (98% of them) would worry much about this particular warning.  For the simple reason that, most people who have any concept of what Java is, have also assimilated the common, if erroneous, notion that Java applets only run inside of a "security sandbox".

I clean up a lot of spyware for many customers and I can attest to this. Many, MANY people either click Yes out of habit, or they sincerely believe that clicking "YES" is required to view the site. You can call these people "dense," but they really are just not informed about the possible consequences. Furthermore, the concept of good software vs. bad software is simply lost of them when they're staring at this prompt.

[rob_]

You can call these people "dense," but they really are just not informed about the possible consequences

Exactly. And 98% of the "more than 25 million others" who are using Firefox are never going to go to Sun's Java Security FAQ and read even the beginning paragraph. And even if they did, this is what they would come away with:

The goal for the JDK is to enable browsers to run untrusted applets in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent applets from inspecting or changing files on the client file system. Also, the intent is to prevent applets from using network connections to circumvent file protections or people's expectations of privacy.

JDK 1.1 provides the basic technology for loading and authenticating signed classes. This enables browsers to run trusted applets in a trusted environment. This does not make obselete the need to run untrusted applets in a secure way. In the release following JDK 1.1, we will provide tools for finer-grained control of flexible security policies.

And having done so, it would be reasonable for them to assume that they could expect even an unsigned, untrusted applet to be run in a secure way, e.g. inside a sandbox, without any user interaction whatsoever. Popping up a dialog box begging for euphemistic "trust" from naive end users is not the same as running it locked down by default and logging for the user precisely what permissions the applet attempted to exceed. Now, if these curious souls read even further into the FAQ, certainly they would become even more and more convinced of the innate security of Java applets:

1. What are applets prevented from doing?

In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.

In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.

There are other specific capabilities denied to applets loaded over the net ...

2. Can applets read or write files?

In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted.    ...

4. How do I let an applet write a file?

Applets loaded into a Java-enabled browser can't write files.  ...

11. Can an applet start another program on the client?

No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.

12. What is the difference between applets loaded over the net and applets loaded via the file system?

There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.

If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.

14. What's the applet class loader, and what does it buy me?

... applets loaded from different network sources are partitioned from each other.

Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions.

In the current state, what it really boils down to is this: the bulk of the Firefox user base shouldn't have to decide applet security on a case by case basis, it should be secure (sandboxed) by default, devoid of user interaction, and oblivious to signatures.

Then, if Firefox wants to support "advanced users" (presumably advanced enough that they could have started the applet from the command line), then there should be an ACL wherein they can add applet codebases/signatures with associated fine-grained permission lists (a la the defunct HotJava browser).


Reference: Sun Java Applet FAQ

Edited by rob_, 15 March 2005 - 09:17 AM.

[southernlady]

the bulk of the Firefox user base shouldn't have to decide applet security on a case by case basis, it should be secure (sandboxed) by default, devoid of user interaction, and oblivious to signatures.

That actually should read ANY user base not just FIREFOX...but with Mozilla/Firefox being the only one to respond, I guess we can ask them to do this.

We now have other sites syndicating the article from SWI and calling this LIBEL and SLANDER to Firefox...

WHY can't we all cooperate in getting this problem under control and stop the infighting that's started over an article that simply brought attention to the problem? If it hadn't been for the original article, only a handful of us would know about this, thanks to a topic on TC's site and some of us spreading the word to our own forums. That doesn't get it out to the PEOPLE who NEED to KNOW...THE USER!!! Liz

[rob_]

That actually should read ANY user base not just FIREFOX...but with Mozilla/Firefox being the only one to respond

I'm sorry, however I'm only familiar with the issue as it applies to Firefox. I haven't tried to replicate it on any other browser, including Mozilla. IE doesn't interest me because I don't use it (due to ActiveX and plugins). Opera appears to be not vulnerable.

I guess we can ask them to do this.

Or suggest a more viable, more secure, simpler alternative that will make more sense and require less input (thought) from 25+ million users, short of disabling Java applets altogether.

We now have other sites syndicating the article from SWI and calling this ...

Amusing. In any event, it's no crime to delineate a technical opinion on how to mitigate the unwitting execution of arbitrary programs. Nor is it one to state factual material related to the mechanisms involved. Besides, I'm not hawking "built with your security in mind, Firefox keeps your computer safe from malicious spyware", I'm simply one of those who would like to be able to rely on that statement in a less than perfect (i.e., human) end user environment.

Cheers.

[southernlady]

IE doesn't interest me because I don't use it (due to ActiveX and plugins).

Actually, Rob, if you use a Windows product, you use IE even if you don't actually open it up. It is there, it resides in our system and it affects our other browsers, even when we don't use it.

In any event, it's no crime to delineate a technical opinion on how to mitigate the unwitting execution of arbitrary programs. Nor is it one to state factual material related to the mechanisms involved.

If the articles had been stated factually, I'd agree...but there was a slant to the facts in the SWI article and now the one at Lockergnome that you just can't ignore.

I guess we can ask them to do this.


Or suggest a more viable, more secure, simpler alternative that will make more sense and require less input (thought) from 25+ million users, short of disabling Java applets altogether.

I was suggesting SunJava and the browsers involved, not the end user...I'm sorry if my point wasn't clear. Liz

[rob_]

if you use a Windows product, you use IE even if you don't actually open it up

Let me be more explicit: I do not use Internet Explorer, the process (or COM control) or any process based thereon, on a regular basis (e.g. besides Windows update) and was not referencing the various and sundry DLL modules which it in turn utilizes. Sure, Firefox and IE (the process) map around 16 common Microsoft modules into their respect process memory spaces (at least on the Windoze version I'm running now) and thus may share any vulnerabilities these modules may themselves possess. Nevertheless, let's see, they do not share IEXPLORE.EXE, BROWSELC.DLL, BROWSEUI.DLL, MSHTML.DLL, and several of the other code modules that make up IE (the process, or derivatives) to which I was simply referring. Interesting surely, but it's off the topic of this thread.

there was a slant to the facts in the SWI article and now the one at Lockergnome

Welcome to the ugly world of demabloguery, lol. Everyone seems to have a different take on what is important (or not) about this issue of using (under Firefox/SunJava) a Java applet to download and start a Windows executable.

John Leyden buried deep in his article the fact that it is not an automatic exploit (a standard if annoying story lead-in practice). Both he and Paperghost stress the novelty of using one browser as the means to rig up another with parasites. The writers on SWI and Lockergnome merely seem to be interested in the opportunity to grandstand.

Anyway, I am a little dismayed when security wonks dismiss user interface weaknesses. Sure it's not a super sexy automatic remote code execution exploit, but it's still a non-trivial issue. Popping a security dialog box requiring users to perform (uninformed) decision making, even if the answer is usually "no", is at best an annoyance and is at worst (as in this case) a toehold for socially engineered exploits. Labeling the left tail of the world's online population as "dense" neither makes them any less so, nor makes their insecure machines any less of a problem for the rest of us.

So back to Firefox: can anybody think of a single reason why it is a good thing to be side-tracked into providing (usually) negative responses to euphemistically worded prompts as part of a security process that is completely ancillary to their browsing? If anyone from Mozilla is reading, I'd love to hear about the design decision (or lack thereof) behind this behavior, and more importantly, whether or not it is going to change.

Cheers.

Edited by rob_, 16 March 2005 - 06:06 PM.

[The Computer Valet]

Anyway, I am a little dismayed when security wonks dismiss user interface weaknesses. Sure it's not a super sexy automatic remote code execution exploit, but it's still a non-trivial issue. Popping a security dialog box requiring users to perform (uninformed) decision making, even if the answer is usually "no", is at best an annoyance and is at worst (as in this case) a toehold for socially engineered exploits. 

To wit:

You MUST click YES to continue.