281305 - EXE software installed without any user intervention through Java 1.4.2_06

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Java: OJI, defect)

Description

[:deanis74]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Going to this page will load a java applet that will install software without
confirmation from the user.

I haven't seen something like this being fixed on the trunk, apologies if it has
been.  I'm using FF 1.0 on this machine.

Reproducible: Always

Steps to Reproduce:
Disclaimer: Following these steps will run an installer for a XXX toolbar.

1. Open the test case (one line of code)
2. Wait.
Actual Results:  
Blocked installation warning displays but the software is installed.  I can
confirm this because my software firewall immediately prompts me to give
outbound access to "iinstall<number>.exe".

Expected Results:  
Firefox says it blocked the site from installing software, and nothing else happens.

Comment 1

[:deanis74]

Attachment: test case

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: evil site's script

Here's the js the site is using, a grab bag of different exploit attempts. The
Java one is the one you most likely fell victim to. I haven't tested the
exploit, but my guess is that it's exploiting fairly recently announced flaw in
JRE 1.4.2_05 and before:
http://sunsolve.sun.com/search/document.do?assetkey=1-26-57591-1

Which version of Java do you have installed? Do you have Sun's update
notification feature turned on?

Comment 3

[Brendan Eich [:brendan]]

This is not a JS engine bug.  Dan, can you find a better owner than yourself?

/be

Comment 4

[Daniel Veditz [:dveditz]]

I don't think this is our bug at all, except as another vote for the "centrally
blacklist plugins by version" bug.

Comment 5

[:deanis74]

It could well be that I don't have the last point release of the Java plug-in. 
I'll check that when I get home tonight.  I did want to log this, in case it was
our bug.

Comment 6

[:deanis74]

(In reply to comment #2)
> my guess is that it's exploiting fairly recently announced flaw in
> JRE 1.4.2_05 and before:
> http://sunsolve.sun.com/search/document.do?assetkey=1-26-57591-1
> 
> Which version of Java do you have installed?

I upgraded to 1.4.2_06 and I still experience the same problem.

Comment 7

[Kyle Yuan]

Dean, where will iinstall<number>.exe be installed?

I saw a java warning dialog that asks "do you want to trust the 'Integrated
search Technology' software?" (or something else likes that), and I chose no.
Then there was an java security exception in the java console, but I'm not sure
whether any software has been installed without my permission. 

I'm using jre 1.5.0_01.

Comment 8

[:deanis74]

The EXE gets installed into my temp directory.  I've never seen a prompt like
what you saw.  Weird.

Comment 9

[chris hofmann]

jst, can you see if there is a low risk way to disable older versions of java
that are vulerabile, then users could upgrade or override if they believe they
are set up to be safe.

Comment 10

[Daniel Veditz [:dveditz]]

According to the attached script (Thanks!) this is another multi-pronged attack.
For IE they try ActiveX and loading a couple of pages, presumably with different
attacks though I didn't spend the time to investigate. One is loaded as an <img>
src, maybe trying the fairly recent gdiplus exploit?

For Mozilla they try a java applet, launching a xpi install, and failing that
simply starting an .exe download by replacing the page (hoping someone will run
it later? Who would run an unasked-for program?). They don't take xpinstall
whitelisting into account. My copy of McAfee does not detect anything fishy with
the java class, but it is signed (bad CA? can't be verified) and tries to create
a temp file -- probably the installer. From Dean's description they found a way
around the signing in older versions of the JRE.

Since McAfee is not detecting this as the known ByteVerifier flaw in 1.4.2_05,
and Dean is actually on 1.4.2_06 the Sun java guys might want to inspect this
closely to see if an unknown exploit affects 1.4.2_06

Comment 11

[Kyle Yuan]

I can also see the security warning dialog with jre 1.4.2_05. So I'm wondering
if Dean have some special java security settings to bypass this checking. Dean,
do you have any .java.policy file in your home directory? Did you change any
settings in ${java.home}\lib\security\java.policy?

Comment 12

[Daniel Veditz [:dveditz]]

Disabling isn't going to safely make 1.0.1, we'll just hope notification (bug
282257) and Sun's own update feature (though many people seem to disable it)
will cover enough people.

Comment 13

[:deanis74]

(In reply to comment #11)
> I can also see the security warning dialog with jre 1.4.2_05. So I'm wondering
> if Dean have some special java security settings to bypass this checking. Dean,
> do you have any .java.policy file in your home directory? Did you change any
> settings in ${java.home}\lib\security\java.policy?

I've never touched a java.policy file, and I can't find any versions of this
file that look different than the default version.

Comment 14

[Daniel Veditz [:dveditz]]

Not blocking: still not sure what the exploit is (can't reproduce with Dean's
JRE version), no patch.