Re: [Full-disclosure] Is FFSpy a hoax?

[Mario Alejandro Vilas Jerez <mvilas@xxxxxxxxx>]

Argh, wrong subject, damn it :P

Let's try again:

> On Tue, Jun 2, 2009 at 1:07 AM, Mario Alejandro Vilas Jerez 
> <mvilas@xxxxxxxxx> 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/