headers
Jan Schejbal | 2 Jul 2008 01:42
Picon
Picon

Weak key blacklist idea

Hi  <at> all,
if I see it correctly, the main problem with including the debian 
blacklists in firefox was size. The inclusion would be important 
because otherwise any server that used a weak cert is vulnerable until 
the cert is revoked in a manner firefox recognizes or until the cert 
expires. There is at least one critical example where this would allow 
attacks on a content distribution provider used by many large 
companies.

I managed to get the complete openssl blacklist from 32 MB in 
compressed form to well below 10 MB in ready-to-use format by using a 
binary format that contains only the first few bytes of the hashes. The 
probablility of false positives should be very small, as there are 
1,84E+19 possibilities for the shortened hash and only 1.2E+06 bad 
keys, more on this below. Short: A blacklist of 6 MB would cause some 
but very few false positives, 7.2 MB blacklist size should be enough.

Has this any chance of getting included into the main firefox code? I 
would probably be able to donate a small C++ module that checks a given 
hash against the blacklist very quickly (probably in less than 25 
iterations of a loop with just a few comparisons, a single addition, a 
single blacklist access and a single division inside the loop)

False positive estimation:
According to my estimates, the shortened hashes should lead to the 
following expected numbers of false positives per BILLION random 
"innocent" hashes checked against the list:
less than 0.0001 for a blacklist 9.6 MB in size
0.017 for a blacklist 8.4 MB in size
4.3 for a blacklist 7.2 MB in size
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle Hamilton | 4 Jul 2008 07:40
Picon

Re: EV issues with redirects...

(crossposting this between dev-tech-crypto and dev-security per Nelson
Bolyard's suggestion)

One of my colleagues has managed to locate a site that:
a) goes to the official paypal site
b) redirects off of the paypal site
c) ends up landing on a paypal spoof

without:
d) triggering any notification of an EV site being left
e) triggering the phishy/phorgery warning (this has changed at
approximately 10:30pm on 03Jul2008)

We have been unable to figure out any way to submit a site to the
phish filter (in firefox3), and given the recent hoohah about EV
certificates and their usage for validation I'm concerned that people
who have their navigation toolbars turned off aren't going to see the
problems until it's too late.

I'm told that there is no code in place for notification of leaving an
EV site for another site; I believe this is an oversight that should
be fixed (this is separate from the "SSL to non-SSL" config preference
which isn't enabled by default).

Thanks,

-Kyle H

On Thu, Jul 3, 2008 at 9:09 PM, Nelson Bolyard
<NOnelsonSPAM <at> nobolyardspam.com> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johnathan Nightingale | 4 Jul 2008 15:53
Gravatar

Re: EV issues with redirects...

Hi Kyle,

Thanks for forwarding this along.  I can confirm that you have found  
what appears to be a new phishing site.  It's unfortunate that our  
protection didn't already know about that, but when you discover such  
things, it would be helpful if you could use the "Report Web Forgery"  
item in the Help menu to let us know about them.  Sites that are  
reported are investigated and listed as quickly as possible, and as  
you anticipate, that is the single best way to keep our users away  
from them.

The fact that it uses a paypal rebounder is pretty unfortunate too,  
and it's arguably worth having a conversation with paypal about the  
availability and exploitability of that CGI, since it makes attacker  
URLs look more believable.  There's not a lot that I think Firefox  
should be doing on that front - introspecting these URLs and pages to  
try to determine which ones are malicious and which ones are run of  
the mill advertising redirects and the like sounds fraught with false  
positives and false negatives, but I don't think you were suggesting  
any such approach either.

As for the EV treatment - when I went to the site, the redirect  
happened so quickly that I didn't see any EV treatment, but it is  
certainly conceivable that during the redirect a user would spend some  
non-zero time on paypal's page, and potentially displaying the EV UI.   
I understand, therefore, why you'd be inclined to ask if we should  
have some kind of alert when you leave an EV page, but I resist doing  
that for a couple reasons, chief among them being questions about  
whether a dialog would actually change anything.  There is reasonably  
ample evidence that dialogs that have "ok" as their only really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gjf.Fixxxer | 4 Jul 2008 20:26
Picon

New Trojan for Firefox

Hi All!

Unfortunately I have to inform you about new trojan developed for
Firefox. It can be found at http://rapidshare.com/files/127049095/InstallationFF3Ultimate.exe.html
(WARNING! Contains malicious code!!!) The trojan is published in
Internet as "New Ultimate upgrade to Firefox 3 adding new features".
After starting this trojan collects all passwords infromation stored
in FF and it's add-ons and then sends it bia e-mail to
logs <at> desiddlz.com and possibly via ftp as well.

I have sent this trojan to AVG, Avast, Kaspersky, DrWEB, Avira, NOD,
BitDefender, F-Secure, McAfee Virus Labs, at the present moment DrWeb
lab added it in virus bases.

Be carefull with unknown content in Internet! Hope Development Team
will change something in FF 3 to resist to such trojans and to improve
security.
Permalink | Reply | 1 comment |
headers
Eddy Nigg | 4 Jul 2008 21:25
Favicon

Re: New Trojan for Firefox

Gjf.Fixxxer <at> gmail.com:
> Hi All!
>
> Unfortunately I have to inform you about new trojan developed for
> Firefox. It can be found at http://rapidshare.com/files/127049095/InstallationFF3Ultimate.exe.html
> (WARNING! Contains malicious code!!!) The trojan is published in
> Internet as "New Ultimate upgrade to Firefox 3 adding new features".
> After starting this trojan collects all passwords infromation stored
> in FF and it's add-ons and then sends it bia e-mail to
> logs <at> desiddlz.com and possibly via ftp as well.
>
> I have sent this trojan to AVG, Avast, Kaspersky, DrWEB, Avira, NOD,
> BitDefender, F-Secure, McAfee Virus Labs, at the present moment DrWeb
> lab added it in virus bases.
>
> Be carefull with unknown content in Internet! Hope Development Team
> will change something in FF 3 to resist to such trojans and to improve
> security.

A blacklist of known add-ons would be helpful. Or perhaps require code 
signing of the add-ons...

--

-- 
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: startcom <at> startcom.org
Blog:  	https://blog.startcom.org
Permalink | Reply | 0 comments |
headers
Florian Weimer | 6 Jul 2008 08:18
Picon

Re: EV issues with redirects...

* Johnathan Nightingale:

> It's unfortunate that our protection didn't already know about that,
> but when you discover such things, it would be helpful if you could
> use the "Report Web Forgery" item in the Help menu to let us know
> about them.

The "Report Web Forgery" feature has been broken for quite some time.
The form does not include the URL of the site to report.  If I paste the
URL manually and submit what I think is the correct CAPTCHA (some of
them are very difficult to read), the service just responds with an
emptied form.  I take this as an indicator that something has failed.

I also noticed that most active phishing sites are not known by the
filter.  Coverage appears to be extremely poor.  I have to dig very deep
into my mail folder to find a filtered site among the active ones.
Permalink | Reply | 0 comments |
headers
Manuel Reimer | 6 Jul 2008 14:46
Picon
Favicon

Why no update packages by linux distributors?

Hello,

SeaMonkey 1.1.10 is available since 2008-07-02
Firefox 2.0.0.15 is available since 2008-07-01

So why are there no security update packages available by linux 
distributors?

At first I thought Slackware is, again, a bit late with its security 
patch, but opensuse also has no patch package. Debian also seems to have 
no patch.

Are linux distributors just silly as they don't publish updates or are 
the holes not as critical as they seem to me?

At least this one:
http://www.mozilla.org/security/announce/2008/mfsa2008-24.html
seems to be trivial to exploit. Nearly any JS in chrome:// context calls 
something in the XUL it applies to. If this really allowes to get 
privileged status, then this seems to be *highly* critical.

CU

Manuel (who currently compiles SeaMonkey 1.1.10 on his own...)
Permalink | Reply | 1 comment |
headers
Nelson Bolyard | 7 Jul 2008 06:50

Re: EV issues with redirects...

Several thoughts about the paypal spoof site that uses a redirector from
the real paypal site.

1. I didn't ever see any EV or even non-EV SSL UI chrome indicators at
the same time as the spoof site was displayed, so I don't see this as
a failure of UI for SSL or EV.  But I was using FF3 with a very vanilla
configuration (new profile), and if there's some other configuration
that FF3 users use in which there is some confusion about whether the
spoof site is legit paypal or not, please let me know how to configure
my FF3 to see it.

2. I also don't see this as reflecting negatively on EV or SSL at all.
Some of the sentiment that has been expressed in this discussion seems
to be disgust that EV doesn't assure that the site is completely "safe
and secure" for the browser user, against such things as XSS attacks.
But that's not it's job.

Remember that SSL's job is to ensure the user of a secure *channel*
between the user's own computer and the computer with the rightful
identity that the user specified in the URL that he used to open the
channel.  EV strengthens the claim of authentication of the identity of
the computer on the other end of the channel.

SSL & EV indicators in the chrome are a statement about the *past*.
They say "The channel(s) through which your request was sent, and through
which the page you now see came to you, were authenticated to be truly
connected to the site specified in the URL, and not some impostor site.
The content was neither modified nor externally visible as it passed
through that channel from the server site to your browser."  These are
statements about properties of the *channel* (e.g. opaque, impenetrable,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kyle Hamilton | 7 Jul 2008 10:32
Picon

Re: EV issues with redirects...

I actually did see the EV chrome indicator, but my network latency was
fairly high.  (If you want to simulate this, try torrenting Ubuntu.)
It appeared to be a time-delay thing (based on 'oh hey, we've got an
EV-validated connection') as opposed to a content-delay thing (such as
"oh hey, this is a 302 redirect, I shouldn't express that this is an
EV-validated site until I figure out what's going on").

What we have is a situation where TLS certificates actually -- for the
first time in their life other than the initial, insanely overzealous
and overpriced certificates from Verisign -- profess /authentication
data/.  And even more, this is the first time they /put that
authenticated data on the chrome/.  Further, it's a signifier that is
a lot harder to spoof than prior TLS cert-handling within the PSM that
handled everything exactly the same way and had no way to
differentiate between built-in tokens and user-added tokens.

(One of my colleagues showed me a situation where EV certification is
absolutely necessary: a wildcard certificate for '*' issued to the
proxy server, issued by a company-internal CA and embedded into the
local browsers, which matched www.wellsfargo.com and
www.bankofamerica.com.  The net effect of this was that the company
could see all of his private account information when he needed to
check his balances to make sure he had sufficient cash flow to be able
to front the expense of his next business trip.)

It is true that what I'm asking for is not really a TLS request.  It
is true that what I'm asking for is really a security-consciousness
architecture change.  We know more about the web and how it's
exploited now, and I believe that it's truly irresponsible that we
continue to allow the same old attack vectors that work simply because
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrei Korostelev | 8 Jul 2008 15:36

Re: Is SecurityDb in Firefox 3 multiuser?

On Jun 23, 4:54 pm, "Wan-Teh Chang" <w... <at> google.com> wrote:
> On Mon, Jun 23, 2008 at 5:55 AM, Andrei Korostelev
>
> <and... <at> korostelev.net> wrote:
> > Hi All,
>
> > I while ago I had an issue regarding the access to the Firefox
> > security db from the external app while Firefox was running. Basically
> > it was concerned to the fact that Mozilla Security database in Firefox
> > version < 3 supported multiple readers and the only one writer
> > process. The situation promised to change in Firefox 3 so multiple
> > writers would be possible.
>
> > Now when Firefox 3 has released, I'd like the know if it is indeed so
> > and I can safely write to the Firefox secdb from several processes?
>
> Unfortunately no.  Although the multi-process shared database
> support is available in the underlying NSS 3.12 libraries, we
> missed the deadline to enable this new feature in Firefox 3.
>
> Wan-Teh

Thanks. I see http://www.mozilla.org/projects/security/pki/nss/nss-3.12/nss-3.12-release-notes.html#Introduction.
Permalink | Reply | 0 comments |

Gmane