full-disclosure - Re: Is FFSpy a hoax?

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] [thread-next>] [day] [month] [year] [list]

Date: Mon, 01 Jun 2009 23:46:49 -0400
From: Valdis.Kletnieks@...edu
To: T Biehn <tbiehn@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Is FFSpy a hoax?

On Mon, 01 Jun 2009 23:05:02 EDT, T Biehn said:
> 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.

Several problems here:

1) Self-encrypting to the one-way-hash doesn't solve the problem - an
attacker can decrypt the stored file, extract the identifier, and then
save the backdoored file encrypted to the new hash, identifier and all.
(Hint - this is exactly what you'd have to do on a *legitimate* update
of an extension...)

2) And in fact, encrypting to the expected hash value doesn't actually do
much for you - if I know the expected hash value is 0x349F3D, I can just
use that to store an encrypted backdoored file whose hash in fact *isn't*
0x349F3D.  Now, *once retrieved*, you probably should re-check the hash
of the retrieved file, and make sure it is still 0x349F3D - but at that
point, the crypting is pointless, as all you care about is the before/after
hashes of the plaintext. Now finding a secure way to store that "before"
hash - *that's* the hard part (in general, you can't store it anyplace the
user can write to, which makes a legitimate update "interesting")

3) The usual warnings about using a good crypto-strength hash function apply.
I haven't seen a break for MD5 that allows colliding to a pre-determined hash
yet.  The key word here is "yet". ;)

4) You'd probably have to decide between having one master identifier which
would piss off users and break every time Firefox or any extension released a
patch, or having one identifier per extension, and piss off users who can't
remember all the identifiers...

5) A small UI real estate problem - at least on my Linux box, Firefox is
already using the window titlebar to display the <title> tag from the page.
I suspect that users still want that behavior, so you need to find a way
to co-exist with that. But heck, if Firefox Minefield builds can stick
a build ID onto the titlebar, what's another 10-15 chars? ;)

Content of type "application/pgp-signature" 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/