ok

On Tue, May 26, 2009 at 4:30 PM, David Blanc <davidblanc1...@gmail.com> wrote:
> On Tue, May 26, 2009 at 8:38 PM, Shell Code <technobus...@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 <sap...@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.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Reply via email to