Argh, wrong subject, damn it :P Let's try again:
On Tue, Jun 2, 2009 at 1:07 AM, Mario Alejandro Vilas Jerez < [email protected]> 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?
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
