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? -- 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/
