mailing list archives
Re: The father of all bombs - another webdav fiasco
From: Mario Alejandro Vilas Jerez <mvilas () gmail com>
Date: Tue, 2 Jun 2009 01:07:43 -0300
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
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.
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.
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.
Hosted and sponsored by Secunia - http://secunia.com/