Message-ID: <3fbf862f0906012108w1beebc23y2d2186ff490bcc3@mail.gmail.com>
Date: Tue, 2 Jun 2009 01:08:39 -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?

Content of type "text/html" skipped

_______________________________________________
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