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

Message-ID: <2d6724810906012216l7a93a747rb282c88f2638ab66@mail.gmail.com>
Date: Tue, 2 Jun 2009 01:16:36 -0400
From: T Biehn <tbiehn@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Is FFSpy a hoax?

On Mon, Jun 1, 2009 at 11:46 PM,  <Valdis.Kletnieks@...edu> wrote:
> 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? ;)
>
>
>

VK: Did you read the first sentence of my e-mail and then ignore the rest?
Pretty obvious from the above.

-Travis

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