full-disclosure - Re: The father of all bombs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3fbf862f0906012107v6901863nc6e23d9136bb99c7@mail.gmail.com>
Date: Tue, 2 Jun 2009 01:07:43 -0300
From: Mario Alejandro Vilas Jerez <mvilas@...il.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: The father of all bombs - another webdav
	fiasco

 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?

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/