256534 - ChatZilla's client.prefix variable provides opportunity for malicious ruse.

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[John J Foerch]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

When client.prefix is set, ChatZilla will evaluate messages that start with that
prefix as javascript.  Useful for debugging, but this provides evil-deed-doers
with a backdoor to hijack someone's client.  They need only convince that person
to set the client.prefix variable, which they could do by sending the individual
a plugin that contains the code, or by pretending to be helpful and embedding
the code into other instructions.


Reproducible: Always
Steps to Reproduce:
1. Hang out in a help channel and wait for a newbie to ask a question.
2. Send the person a private message offering to help, and while instructing
them how to accomplish a certain task, tell them to do /eval client.prefix =
'do_as_i_command'
3. Hack at will.

Actual Results:  
I tested this the steps described, by running two instances of ChatZilla on my
computer, and was able to control one client from the other.

Expected Results:  
This capability should be removed from ChatZilla, or rewritten in such a way
that the individual would have to give explicit permission to one person to
execute javascript on their machine, and would be given a gigantic red warning
box that fills half their screen and won't go away while the feature is active.

Comment 1

[Samuel Sieb]

A plugin has full access to chatzilla internals anyways and could listen for its
own signal.  You also can't secretly command chatzilla to do something, since it
will be fully visible in the channel.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

The plugin issue is a red herring, like Samuel notes.

However, that does not mean client.prefix might not be dangerous. If it could be
automatically set by an attacker, it could be an issue. But the report does not
imply there is an automatic way to set it without a user noticing it.

If the only way to exploit this is to get the user to type some command in
Chatzilla window, then I think this is not a real vulnerability. The reason is
that I don't see any difference between this and instructing the user to type
javascript:eval('do something bad'); in the browser URL bar.

Comment 3

[Robert Ginda]

I agree with John on this one, this makes it way too easy to abuse someone.

The difference between this and javascript:eval('do something bad'); is that
there is no short way to say "make it really easy for me to run lots of
arbitrary script" in an eval().

Comment 4

[John J Foerch]

I can appreciate the notion that if someone runs some javascript code that a
stranger told them to, without knowing what it does, it's their own fault if
they get hacked.  Yet maybe the thrust of what I'm saying in this report is that
the variable name client.prefix is too vague.  It should be something more like
client.prefix_set_this_at_your_own_peril_you_fool .  Harharhar.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Of course I don't object to fixing this (in fact, the less there is attack
surface, the better).

Confirming so that this gets into more people's radar.

Comment 6

[James Ross]

This code was removed from ChatZilla 0.9.65 (bug 255081).