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
| ||
|
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/
Powered by blists - more mailing lists