lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 May 2009 21:00:53 +0530
From: David Blanc <davidblanc1975@...il.com>
To: Shell Code <technobuster@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: FFSpy, a firefox malware PoC

On Tue, May 26, 2009 at 8:38 PM, Shell Code <technobuster@...il.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@...il.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.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ