Message-ID: <3fbf862f0906012109od320891x9e4087cbd5eab0a@mail.gmail.com>
Date: Tue, 2 Jun 2009 01:09:49 -0300
From: Mario Alejandro Vilas Jerez <mvilas@...il.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: Is FFSpy a hoax?

Argh, wrong subject, damn it :P

Let's try again:

> On Tue, Jun 2, 2009 at 1:07 AM, Mario Alejandro Vilas Jerez <mvilas@...il.com> wrote:
>>
>> Maybe this is a stupid question, but why not just requiring sudo to install addons? Then the addons could be stored along with the program files. That could require making the addons global rather than per-user, but I don't see that as a major problem - besides it can be avoided too by having a per-user list of addons to load. I believe a similar solution can be implemented for Windows.
>>
>>>
>>> Consider a defense within the realm of possibility:
>>> On install firefox requests that the user enter an identifier. This
>>> identifier is presented to the user in the top bar of his browser
>>> window. Firefox 'locks' all script files while it is on.
>>>
>>>
>>> Firefox self-encrypts to the one-way-hash of the files.
>>> A user will know they have been compromised because the identifier
>>> cannot match if firefox.exe has been replaced by another version that
>>> supersedes the checks if the identifier is stored as part of the
>>>
>>>
>>> encrypted program stub.
>>>
>>> Firefox can lock the script files while it is open. It can update
>>> scripts because it owns the locks and then can re-encrypt itself at
>>> this time to match the new hash.
>>>
>>> Consider the possible attacks of such a defense:
>>>
>>>
>>> This is susceptible to attacks on memory (injection to trigger an
>>> update, overriding the update mechanism, trivial to read the
>>> identifier to clone behavior). Is there an extension to this idea that
>>> can protect against this? Perhaps this method in-situ with a memory
>>>
>>>
>>> protection mechanism of some sort.
>>>
>>> Why:
>>> Only a checking process that runs in an isolated read-only manner
>>> would be sufficient to protect against such attacks. There are ways to
>>> cat and mouse this problem but without a watchdog process that isn't
>>>
>>>
>>> user-writable a tenable solution cannot be found.
>>>
>>> Can this be applied to other possible defenses?
>>> A clever algorithm can always be beaten by another clever algorithm.
>>>
>>> What about other situations of this kind?
>>>
>>>
>>> Consider also that it is just as likely, if not more so, that a virus
>>> author would instead chose to write stubs to all binary files that
>>> show up in either init scripts, cron, automatic services in windows
>>> (hell you can patch svchost dlls), the start menu, explorer.exe, the
>>>
>>>
>>> kernel, drivers, etc etc.
>>>
>>> ............................
>>> The real point here is a system that is difficult to compromise in the
>>> first place, and that is encapsulated by many such systems that are
>>> regularly rebuilt, is the only current defense. An attacker slowly
>>>
>>>
>>> gains leverage over a system or system of systems, once gaining access
>>> it is almost impossible to lock out and / or defend given an
>>> adequately skilled adversary.
>>>
>>> The solution becomes clear, build innumerable artificial obstacles.
>>>
>>>
>>>
>>> All articles of advisories of this sort are masturbatory in nature.
>>>
>>> -Travis
>>
>> --
>> HONEY: I want to… put some powder on my nose.
>> GEORGE: Martha, won’t you show her where we keep the euphemism?
>
>
>
> --
> HONEY: I want to… put some powder on my nose.
> GEORGE: Martha, won’t you show her where we keep the euphemism?



--
HONEY: I want to… put some powder on my nose.
GEORGE: Martha, won’t you show her where we keep the euphemism?

_______________________________________________
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