mailing list archives
Re: FFSpy, a firefox malware PoC
From: saphex <saphex () gmail com>
Date: Tue, 26 May 2009 19:48:41 +0100
On Tue, May 26, 2009 at 4:30 PM, David Blanc <davidblanc1975 () gmail com> wrote:
On Tue, May 26, 2009 at 8:38 PM, Shell Code <technobuster () gmail com> wrote:
I would appreciate if you post replies to the list instead of sending
it only to me. My comments inline.
On Tue, May 26, 2009 at 5:10 PM, saphex <saphex () gmail com> wrote:
I fail to understand what is new or interesting in this POC. If a
person with malicious intent gains so much access to a system that he
can put his files or firefox plugins, modify existing files, etc
If you gain access to a system with the user that isn't administrator
(at least under systems that enforce user *differentiation*, read any
Linux flavour and Vista), you only have access to the users folder,
you can't install anything (especially under Linux). I guess this is
meant to be an alternative way of getting the job done.
This is not true. You can carry out attacks of the same severity by
gaining access to a Linux or Windows system as a user that isn't the
administrator. Here are a few examples:
1. Modify a vim, emacs, KDE, GNome, etc. plugin that the user uses so
that it sends user's personal content (data, files, commands executed,
etc.) from the system to a remote server.
2. Put a malicious executable file or script in the user's home
directory and execute it from start up scripts (.bashrc,
.bash_profile, etc.) so that the malicious executable file executes
whenever the user logs in. Now this malicious file can send user's
personal content to a remote server.
3. Modify or put plugins for other software to malicous stuff. Similar
to point 1.
4. Override PATH settings, aliases, put scripts, etc. so that when the
'ls' now executes 'rm' or some other malicious command so that user
ends up executing commands he did not intend to.
5. ... and much more ...
From the POC it seems that somehow the attacker has to gain physical
access to the system or do some social engineering attack to fool the
user in installing or modifying his existing plugins. The PoC does not
explain how this is done.
To you know the download and execute payload for exploits? Make an
application that changes the files, then use that payload in some
exploit. People just want everything done. Just click, download, use,
and call them self l33ts .
How is it any different from the attack scenarios I have explained in
case of vim, emacs, KDE, GNome, Linux shell, etc.?
Maybe this is nothing new, but I think that the way to do it is new.
Because you don't install anything, and the point to be proven here is
that Firefox add-on system is security flawed from the very beginning.
So, are you saying vim, emacs and the plugin system of every other
software on the earth is security flawed from the very beginning?
I believe saphex or the author of the so-called-PoC, Duarte Silva do
not understand the concept of privileges and security vulnerabilities.
By the way, are saphex and Duarte Silva two different persons or
saphex == Duarte Silva?
Coming back to the topic of privileges, any Firefox addon runs in the
context of the user running the browser. So, the addon can do whatever
the user running the browser can. The same holds true for plugins of
other software too as Shell Code has correctly explained. For example,
an emacs plugin can do whatever the user running the emacs can.
So, if saphex or Duarte Silva argues that this is a security flaw in
Firefox addon mechanism, they will also argue that this is a security
flaw in emacs, Windows, Eclipse and every other OS and software. Such
an argument, without any doubt, is lame and stupid as most people
trained in computer security would agree.
"Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former." - by Albert Einstein.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/