Message-ID: <2d6724810906012005r2542dda6kf548bc2fd4eaf063@mail.gmail.com>
Date: Mon, 1 Jun 2009 23:05:02 -0400
From: T Biehn <tbiehn@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Is FFSpy a hoax?

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

On Mon, Jun 1, 2009 at 11:37 AM,  <Valdis.Kletnieks@...edu> wrote:
> On Sat, 30 May 2009 12:31:03 +0530, FFSpy Buster said:
>
>> He suggests that Firefox must do something to notify the user when an addon
>> has been compromised by a remote attacker. He agrees that the remote
>> attacker has to gain physical or local access of the system by remotely
>> logging in or something.
>
> I wouldn't rank it as a major panic, but it *is* pointing out an interesting
> and little-considered place for an attacker who has gotten access to leave a
> back door for themselves. Most security books will tell you to check places
> like 'crontab', and I've seen backdoors and other attacks hidden in .vimrc and
> .gdbinit files, but don't mention browser plugins and add-ons.  This is a bit
> more nefarious because the API and packaging of Firefox add-ons isn't well
> understood by most people, so it's hard to tell where exactly to look, and for
> what.
>
>>                            Let us say the attacker ssh-ed or telnet-ed into
>> the user's PC and modified an addon. What measures can Firefox take to
>> notify the user of the modification?
>>
>> I can't imagine of any because if it is digital signature or checksum based,
>> the attacker can very well modify the public key or the checksum in
>> Firefox's store. So, this whole FFSpy thing sounds like a hoax to me, an
>> unnecessary panic being created by Duarte Silva. Please correct me, if I am
>> wrong.
>
> The trick is to take the signature/checksum and store it someplace that
> isn't writable by the user.  For instance, the venerable Tripwire or the
> more recent Aide will be able to detect this sort of attack - and if you're
> really paranoid and store the Tripwire keys and database offline (cd-rom or
> USB key, etc), it will even be able to work if the system gets compromised
> (booting off known clean media needed for this one, of course).
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
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