Automatic update service

[Ben Bucksch]

(Reposted, because I fell into spam-trap)
(Already posted in policy thread, but I received no response.)
Brendan Eich wrote:

We do need an automated update system.
As it happens, I wrote just such a system for Mozilla (for a customer, 
but under the MPL). Half the code bases on my roaming module. It is used 
in beta releases of said customer and seems to work mainly, modulo some 
superfluous updates due to timezone problems in Windows.

With explicit user consent, it

 * downloads a manifest file from a certain, preconfigured server
 * compares the listed files with those installed locally
 * downloads any mismatching files (into a temporary dir)
 * tries to make sure that the download worked correctly
 * moves away the original files
 * moves the downloaded file into their final location
 * asks the users to restart the browser
Alternatively, it can download XPIs and install them without user 
intervention, but they are currently also treated as normal install 
files, which makes it very impractical in the long term. That's why I am 
planning to additionally implement an internal patchlevel, and all 
available XPIs with a patchlevel larger than the running build will be 
downloaded and installed and may then be deleted.

That is, unless somebody has a better idea. That's why I am writing. How 
do you think should the update service work?

Ben

P.S. Discussion is of general interest and not secret, so please cc 
n.p.m.security.

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Starting EXEs from browser (was: Mozilla targeted malware in the wild)

[Ben Bucksch]

Daniel Veditz wrote:

Figuring out an appropriate UI and security model is tough. When sites
offered .exe downloads we used to force people to explicitly save them and
launch them using the OS. This was to discourage stu^H^H^Hinexperienced
people from running any malware they ran across, with a barrier easily
overcome by anyone who knew what they were doing.
Plus, running apps from the web *should* be an infrequent action 
anyways, so it should be only a minor inconvience.

Later ... we let people launch them directly from the download screen, albeit with a modal "Are you sure" dialog interposed.

IMHO, this was one of the worst decisions ever made for Mozilla. Esp. 
when considering how often people run malware off the web.

Fup-To security.

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Mozilla targeted malware in the wild

[Ben Bucksch]

Daniel Veditz wrote:

site level filtering ... we're still arguing

Where?

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Mozilla security bug policy

[Ben Bucksch]

Daniel Veditz wrote:

Let's forget about the AOL-burdened past. I--and the Mozilla Foundation, I'm sure--want us to do the right thing now.

Yes, I hoped so. That's exactly the reason why I posted this.

Can we start over and give the existing policy (as written, not as executed) a try for a milestone or two?

I don't see how it would work without a targetted procedure, but if you 
think it's going to work with just the current policy and informal 
execution, sure. As long as the results are good, fine with me. Most 
important results for me are: (only for "critical" security bugs)

   * A warning to users about bugs within at most one day after they
 are reported (even if the reproduction and details are kept
 secret), with a workaround (if possible), so that people know the
 threats they are facing and can protect themselves as early as
 possible
   * Quick distribution of available patches to users
   * Reasonably soon fixing of bugs
___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Mozilla security bug policy

[Ben Bucksch]

Daniel Veditz wrote:

I don't think you've demonstrated problems with the policy but rather that
we have to do a better job implementing it.
I see. I guess we have differing viewpionts. Given that we ask for 
secrecy, I think that the policy should *ensure* for outsiders/users 
that we're doing the right thing. Just like I think that the law should 
ensure that the police and the secret services do the right thing, not 
just give them blanket permissions.

Not true, there are guidelines for issuing immediate warnings

Ah, right, we just never used them. But note the difference between "may 
warn" and "will warn".

As a member of that group you share in that failing.

That's not fair. I wanted to issue warnings, but need the allowance of 
the security group, esp. its former owner, which I practically never 
got. I tried, IIRC, but ended up thinking that it's futile.

Another problem with that is that when I have to ask for permission, and 
wait for the answer, which may not be positive, and then have to argue, 
often a few days go by, while warnings should be issued within hours to 
be effective. My proposal tried to solve that.

I propose the following changes to the policy and procedure:
   

A good starting point for discussion, that's what the security group mailing list is for (not, I should point out, [EMAIL PROTECTED] cc'd in this thread, which is for reporting potential problems). If you'd raise these points there I'm sure we could improve things greatly.

Oh. I used security@ as an alias for the security group address, for 
spam-prevention, because I wanted the policy discussion to be public.

Should I re-post the proposal (this time without listing the 
'problems')? I'd prefer the public to be able to listen and add to it, 
but the security group and you as the owner in particular are the main 
adressees, because we have to decide on it and implement it.

Ben

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Mozilla security bug policy

[Ben Bucksch]

Ben Bucksch wrote:

* The known, hidden security bugs are usually *not* being fixed
  timely (contrary to assertions by Mitch during the policy
  discussion IIRC). Some critical ones rotted for years until they
  were driven out. There are currently 59 hidden, unfixed bugs.
  The by far oldest one, a spoofing bug, is from 1999; none from
  2000/2001; about 40% are from 2002; 90% are from 2003 or earlier.
It was pointed out to me that this statement was misleading. This is 
merely counting the hidden, unresolved bugs in Bugzilla classified as 
"security bugs", this does not mean that all of these are critical or 
even valid, as I implied later by saying that there were basically no 
critical bugs in September and later "(I think that's feasible now, 
given that we should be at or close to zero critical bugs)". Many of 
these current, hidden bugs are just questions from review, "are we 
having a problem there?".

(However, if they are not critical, I don't think they should be hidden, 
which was one of my points.)

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Mozilla security bug policy

[Ben Bucksch]

I forgot:

  There are currently 36 fixed, hidden bugs. Some of them fixed a
year ago.
  A
query for the formerly hidden, now disclosed bugs
  

Mozilla security bug policy

[Ben Bucksch]

In October 2001, we discussed a security bug policy for mozilla.org,
which resulted in the
current policy. I was quite unhappy about the policy, with the
worst problems listed in the attached post. I also included Mitch's
reply.

However, the policy very much reflected Netscape's interestes, probably
because Netscape was such a big contributor back then and Netscape
employed the security module owner.

As I understood from later private comments, I wasn't alone in my
opinion even within mozilla.org, and definitely not at large, although
I was pretty much alone in the public discussion. The secrecy with
which we deal with bugs may have supported Linux distributors and other
vendors in being incredibly careless about updating the browser (Debian
stable still ships Mozilla 1.0.0 (!!!) with more holes than
swiss cheese stolen by a bunch of mice). There's also been public
punishment for that, see attached mail.

The policy isn't working. Some problems and facts:

  Users have no idea about the security of their browser, most
assume there are no holes
  
  There's no announce mailing for critical security problems and
fixes to alert users
  
  Public
security bug lists are generally not current, due to neglectance
and lack of process, and per policy only list *fixed* bugs anyways.
  Known (to mozilla.org), but unfixed bugs are in Bugzilla, but
can't be seen by normal mortals and most developers, per policy. Same
for fixed ones, until a bigger release is out and 'important
distributors' (used to be codename for 'Netscape') issued updates.
  
  The relation of the number of critical, hidden bugs to security
bugs reported by the press is 10:1 by my observation
  The known, hidden security bugs are usually not being
fixed timely (contrary to assertions by Mitch during the policy
discussion IIRC). Some critical ones rotted for years until they were
driven out. There are currently 59 hidden, unfixed bugs. The by far
oldest one, a spoofing bug, is from 1999; none from 2000/2001; about
40% are from 2002; 90% are from 2003 or earlier.
  
  Bugs reported about by the press are usually fixed quickly (in
Bugzilla, then CVS), often within 1-2 days.
  The releases recommended by mozilla.org are usually *not*
supported with security fixes, thus contain known security bugs later
during their lifetime. Only for the most high-profile ones reported
widely by the press are new versions (1.x.1) of the browser being
released, and even that often with huge delay.
  
  Meanwhile, the situation seems to be better, so good that mstoltz
could announce in (IIRC) September that no more unfixed, critical
security bugs are known (incl. hidden ones). I could confirm confirmed
that (back then), with a few open questions.

I would define "critical" as allowing arbitary code execution (allowing
full access and control of computer) or reading local files (allowing
full access to all data on computer). Maybe also same-origin bugs
(allowing to use login to online banking site from a third party site).


So, given that Netscape is no more, can we use full disclosure now?

In case that isn't being accepted and partially in addition to that, I
propose the following changes to the policy and procedure:

  Response team: At an given time, somebody from the security group
is responsible for evaluating and treating incoming critical security
bug reports via Bugzilla and email, within hours or at most one day,
and adding that information to the Bugzilla bug. This includes

  asserting the severity
  
worst-case threat
migitiating factors preventing exploit

potentially vulnerable userbase
  
  reproducing the bug
  possible cause and culprit
  workaround
  
  assigning the bug to a developer and alerting him (preferably
by phone)
  
  writing an announcement to the public mailing list (see below)
  

Stuff like "I think I found a security bug: ZoneAlarm reports about
Mozilla opening ports" can be ignored ;-).
  Assignee: In the past, security bugs were often assigned to
mstoltz, the security module owner, I think even when the bug wasn't in
his code. I'd propose that bugs are generally assigned to the developer
who caused it and requiring him to do no other Mozilla development
until the bug is completely fixed. Security bugs are far worse than
breaking the tree! This puts pressure on developers to fix security
bugs quickly and to prevent them to appear in the first place. As for
the caps
module, we'd have to find a solution to distribute workload (and
knowledge, if needed).
  
  Checkin: Review requirements for critical and immediate security
bugs are much easier on the normal criteria (can hardly get worse -
esp. no nits about style, speed etc.), to allow fast checkin of
available patches, but reviews should still carefully check the
correctness of the fix from a security standpoint. More thorough review
for normal coding standards can happen later after checkin. Compar

Re: Serious security issue (Mozilla 1.5)

[Ben Bucksch]

Mark Preston wrote:

this is the specific newsgroup referenced by the Mozilla site for this sort of help, so I naturally assumed that it was where I should go for help.

Where did you read that?
The site explicitly says that the newsgroups are *not* for user help 
support.
, "Are you in the right place?", 
there you aslo find a few hints where to ask.

And - as a mere aside - it is definately a security issue.

No, it's not. A security problem is when e.g. someone can break into 
your computer, not when something just doesn't work.

it just doesn't work with Mozilla's latest release.

Maybe just file a bug.

___
Mozilla-security mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-security

Re: Question on FTP Email address settings

[Ben Bucksch]

GhostMouse wrote:

Whenn I try to do this in Mozilla 1.4, I have an option I've never seen
before, and that is the option to check a box that says "send *THIS* email address as 
anonymous FTP password" (emphasis added) and then there is a place to actually write in 
something, presumably an email address.
My question is:  Will putting in something like [EMAIL PROTECTED]  (or any fake email address) actually stop the distribution of my real email addy and will it stop the spam I get from all these websites that are picking up my information from the browser as I surf?

You email address is not being sent to FTP servers unless you 
specifically enable that option and enter you address there. I thought 
we (in fact, I) removed that option exactly because it causes this kind 
of confusion.

Excessive distribution, followupto .prefs.

Re: security novice :signed chrome? (revisited)

[Ben Bucksch]

rvj wrote:

I am concerned with tampering at the local workstation

Then protect it at that level - prevent people from messing with it. It 
doesn't make much sense to lock one door, if you leave the other door open.

If you still want to do that, write a little md5 checker and use that as 
wrapper for Mozilla or even build it into Mozilla, you have the source. 
You'll have to do that yourself, though. Yes, the cracker could replace 
that checker. That's exactly Mitch's point.

Re: 128-bit encryption not supported by Mozilla 1.3 ?

[Ben Bucksch]

Michael Lefevre wrote:

After I upgraded Mozilla from 1.2.1 to 1.3, I tried accessing
https://home.da-us.citibank.com/signin/indexkiosk.htm
with Mozilla 1.3 but the site returned an error page stating:
	To use Direct Access, you need a browser that supports
	strong encryption (128-bit)
   

t seems that is what they do.  what's really silly is that if you go on
to their browser check page -
http://home.da-us.citibank.com/da/whatdo/index.htm and choose "check
encryption", then it says the browser encryption is ok.
Same behaviour with Beonex Communicator 0.8.2, based on Moz 1.0.2. 
Someone please give them a whack.

Re: Long attachement file-names.

[Ben Bucksch]

Nelson B. Bolyard wrote:


Decisions about whether a file is "safe" for some purpose should be made
based on the MIME content type, not the file name or "extension".


Tell that MS Windows :-(.

Ben

Re: Long attachement file-names.

[Ben Bucksch]

Ulrich Eckhardt wrote:


The filename is displayed as readme.xls (and 3 dots wich can
be easily overlooked). After having a closer look in the headers,
the full name of this attachement is readme.xls.scr .


Good point, please file a bug (and cc me (remove ".news)).

Ben

Re: blocking O/S detection

[Ben Bucksch]

Zade wrote:


How can you block/change the O/S identity as seen by the website you
visit, without disabling javascript?


Set your UA string (search on google for it). IIRC, that's the only 
place where websites can see it. To check, visit .

Ben

.general removed per the charter.

Re: Why giving programmeres so hard times?

[Ben Bucksch]

TGOS wrote:


And if *you* expect to be taken serious, then follow the charter of the 
newsgroups you post to.

http://www.mozilla.org/community.html


If Mozilla has generated the data, it's still my data
 

Just like the processor cache. You can't access that either.


You say the way I suggest isn't secure enough


No, I didn't. I said it's impractical.

Re: Password Manager File - The Final Conflict

[Ben Bucksch]

Chris LeBlanc wrote:


This lets him look up the username/password that he has forgotten, 
edit any that have been entered incorrectly, or has changed, and 
delete any that are depricated or should not be used.

Use Mozilla's Password Manager to delete entries.
Mozilla often detects password changes on websites. If not, delete the 
password and log in at the site again and accept to store the new password.
You cannot look up old passwords this way, nor is that a good idea IMO, 
because it might lead users to trust Mozilla with the master database of 
their passwords, which is a bad idea (TM) as stated in my last post.

You can, however, take the Mozilla code for the password manager and 
create a custom password manager as addon/XPI. mozdev will surely be 
happy to host your project.

Also, this discussion might do better on the Mozilla Crypto Mailing List.


Which is just plain n.p.m.crypto.

Re: Password Manager File

[Ben Bucksch]

TGOS wrote:


Written on Mozilla.org (somewhere in the shameful little documentation
about PSM or NSS).


TGOS, it's enough. You recieved more individual help here than I usually 
get when I try to fix Mozilla bugs/features. You are not glad about 
that, but continue to flame the Mozilla/Netscape developers.

And if *you* expect to be taken serious, then follow the charter of the 
newsgroups you post to. Which would have meant to post with (real) name 
and email address. This was pointed out to you, but you ignored it.

No, I don't want to write software that depends on some external library
to be present (which may not even exist for the platform it will run
later on)


I wonder how the Mozilla profiles get on that platform, but anyways: You 
probably know that NSS runs pretty much on all desktop and server 
platforms in existance. I don't think your washing machine needs to read 
your Mozilla password file.

because one would need root privileges to add the library
which a user just may not have, etc.)


Libraries don't need root priviledges to work. You can install them 
aside to your binary, no uninstall hassles involved. In fact, you might 
even be able to link it statically.

What if I want to write the code in JavaScript and use a HTML page as
GUI?


Aha aha ahaaa. JavaScript, HTML page. I smell something.


I think no scripting language has a better cross-platform
support as every platform that offers a modern browser can execute
JavaScript.


Every platform I know that offers "a modern browser" can run NSS. Often, 
Mozilla is exactly that modern browser, the only one.

You're assuming the intent is to give people access to the data.


Yes. This is MY DATA. These are MY PASSWORDS. And, OMG, believe it or
not, I want to have access to MY DATA.


First, it seems to me that you are contradicting yourself here. You 
wrote before

"So PGP mails are only secure if you can always keep the key file (that 
contains your private keys) secure, which is not the case if it's stored 
on HD (a Trojan could access it easily)."

Ignoring for now that if you have a trojan onboard, you are lost 
*anyways*. You appearantly want your data protected from that trojan, 
but not from your self-written script (where does it run from? a 
webpage?). Where is the difference, technically?
(Consider dictionary attacks on passwords and the fact that the vast 
majority of Mozilla users doesn't have a master password. - Sorry, if I 
mixed something up here, but I didn't follow the whole thread.)

Second: No, the passwords Mozilla stores for you are not your "data". 
They are more in a cache. You are supposed to keep track of your 
usernames/passwords somewhere else. This feature is only for convience, 
to save you the repeated typing. Mozilla cannot garantee the level of 
data security that would be needed to savely keep the only instance of 
your online identity.

Keep the master database of your passwords in a PGP-encrypted file or 
whereever. (Or tell the user to do so.) Which should also pretty much 
end this discussion.

the fact that you didn't bother to do a careful search
on what OIDs are is pretty indicative, imo.


Tell this the webmaster of Mozilla.org


Where does the site state that OIDs apply to S/MIME only?

Maybe a trivial, obvious Google search would help you? 

Or the search function of the site itself? 

Re: Known security vulnerabilities page

[Ben Bucksch]

Dan Veditz wrote:


The Register article was from last May, when only one item was listed on the
page.


Nope.

Article says:
Mozilla riddled with security holes
By John Leyden 
Posted: 05/11/2002 at 10:38 GMT

Frontpage says:
*Mozilla riddled with security holes* 

Playing catch up
5 November 2002 10:38am

This is today, 2002-11-05 (CET and PST, in ISO notation)



Ben

Re: Known security vulnerabilities page

[Ben Bucksch]

Boris Zbarsky wrote:


I was just reading the nice article at 
http://www.theregister.co.uk/content/55/27934.html and was struck by 
the "External Links" section I have to wonder: Why exactly are we 
not updating the known vulnerabilities page?

Actually, comparing the pages, most of them *are* listed, not? And the 
document history says last change Oct 22, done by mstoltz.

However, it does seem to be the case that only those bugs are listed 
there which the press or bugtraq already reported about. That's not the 
point of the page IMO.

Ben

Re: Known security vulnerabilities page

[Ben Bucksch]

Boris, full ACK. I have not followed the press, but I do know that the 
current situation is bad.

What I proposed (when the policy was formed), and where I would probably 
be willing to formally participate, is to warn users about bugs as soon 
as we know about them. Write

   * the bugnumber,
   * a summary of the bug,
   * the vulnerability (incl. an assessment of the severity),
   * a workaround (if known),
   * but without exploit and without disclosing the bugzilla bug
 (because Netscape doesn't want that).

Post that information on a security-announce list and on the webpage. 
Update (both newsgroup and webpage) as soon as a fix is available.

Re press: This would give transparency, we wouldn't be blamed several 
times for the same bug (because of the ID) and most importantly, we 
hopefully wouldn't be blamed for bugs that have already been fixed (and 
the fix shipped).

Re distributors: This would make the work of distributors a whole of a 
lot easier, because they don't have to wade through all the bugs and 
make an assessment themselves and try to figure out, when and where a 
bug is fixed. They have an easy to understand list of security bugs 
existant in their products and can make a decision when they want to 
push a new release. They would also have boiler-plate security 
advisories to be distributed to their users.

Re users: Users would be a lot more secure, because distributors have it 
easier to warn them and users can take precautions until a bug is fixed 
(which can take months, given current experiences, just check the old, 
disclosed bugs).

The major roadblock is to agree that this procedure is wanted. Sorry for 
bringing that up again, but it seems like current policy and its 
implementation does not work.

Ben Bucksch
Beonex

Re: Mac OS: Vulnerability with StuffIt

[Ben Bucksch]

Ben Bucksch wrote:


To my knowledge, they have been notified by the bug finders from the 
beginning. 

I forgot to mention the bug number:
<http://bugzilla.mozilla.org/show_bug.cgi?id=123152>

Re: Mac OS: Vulnerability with StuffIt

[Ben Bucksch]

Chris LeBlanc wrote:


I would send something like this on to the people at StuffIt and Apple 
Quicktime team.

To my knowledge, they have been notified by the bug finders from the 
beginning.

Mac OS: Vulnerability with StuffIt

[Ben Bucksch]

There is a severe vulnerability in the combination of browser (pretty 
much any browser), StuffIt and Quicktime on Macs.

Often, StuffIt is configured to automatically open files that it can 
handle on behalf of the browser. For example, if you click on a link 
with a sit file, StuffIt is being called and opens the file. This is a 
normal process to allow the user to use files placed on the web. in 
uncommon formats.

One of the file types StuffIt handles are disk images. When asked to 
open them, StuffIt mounts them directly on the filesystem.

Quicktime has a feature to automatically start applications as soon as 
disks are inserted. That is probably intended for multimedia CDs and 
installers. However, it is also incredibly dangerous, if you insert an 
untrusted medium, because a started, malicious application can do pretty 
much take over the system.

Now, if you take all these together, you get the following 
vulnerability: You visit a malicious webpage. The author offers a link 
to a disk image and tricks you into clicking it or the webpage even 
triggers the opening of the disk image itself, e.g. using JavaScript or 
refresh. The browser will tell StuffIt to open the disk image. StuffIt 
will mount it. Quicktime will start the malicious application that the 
author placed there. The author of the malicious webpage can now take 
over your system.

The problem is eased by the fact that Beonex Communicator by default 
asks before opening external helper applications like StuffIt, but many 
users probably disabled that or don't expect problems in this case.

There is not much that browsers could do against that. In my opinion, 
the main problem is with Quicktime running applications from potentially 
untrusted sources, and part of the problem with StuffIt not guarding 
against that.

Most of that behaviour is adjustable by the user, in any of the 
applications. Please so that. We recommend to disable the autostart 
feature in Quicktime.

Ben Bucksch

Re: Proposal: HTML tag to disable active content

[Ben Bucksch]

Lincoln Yeoh wrote:


But can you actually help?


No, I have no time.


e.g. Telling me I've got it wrong and so I can forget the whole thing 
or fix it (slightly broken), or I've got it right and you can actually 
help take the idea further, or you know someone who can?

The idea doesn't look wrong per se to me. However:

IIRC, the argument on the www-html list was to make server-side libs. 
That sounds like solution which is
- more correct
- more secure (less likely to fail, if there are bugs)
- more likely to get implemented (try convincing MS OTOH, you can 
implement e.g. a python lib and just use that, and your server is secure 
as well as all other servers caring and using your lib)
- more adaptable (different servers might have different security needs, 
i.e. different tradeoffs between features and security)

Taken seriously? Go ahead laugh


I didn't laugh. But to get something in the HTML standard, you need a 
make a decent case.

Ben Bucksch
Beonex

Re: Proposal: HTML tag to disable active content

[Ben Bucksch]

Lincoln Yeoh wrote:


I have tried the www-html list,


And have read your proposal there (about a year ago?). (But I don't 
remember the discussion exactly anymore.)

and other places, nothing happened


Maybe because there were valid concerns, maybe it's even just a bad 
idea? To be taken seriously,  you'd have to link to these other 
discussions and preferably include and consider the counter-arguments.

Re: disable security

[Ben Bucksch]

hocus, I think such measures are an extremely bad idea. On the internet, 
you cannot trust that

* a certain host is the one you think it is (esp. so with HTTP and
  in some cases even with HTTPS)
* that the data you receive is unaltered (with HTTP)

Giving any http host on the Internet UniversalBrowserWrite (no matter 
what purpose) is IMO grossly careless, risking your customers' computers 
and (if that didn't scare you yet) you make yourself a potential subject 
to a lawsuit from your threatened customers.

Ben

Mitchell Stoltz wrote:

> pref("signed.applets.codebase_principal_support", true);
> pref("capability.principal.codebase.foo.id", "http://foo.com 
> http://bar.com";);
> pref("capability.principal.codebase.foo.granted", 
> "UniversalBrowserRead UniversalBrowserWrite");

> hocus wrote:
>
>> make possible using javascript on documents loaded into frames/iframes,
>> originating from different domain than the base page.
>

Re: insecure form submission dialog

[Ben Bucksch]

Jesse Ruderman wrote:

> Could we replace this dialog with a one-time dialog like the password 
> manager intro dialog, or change the checkbox to be unchecked the first 
> time the user sees the dialog? 

me too.

I agree with you, and the dialog is disabled by default in Beonex 
Communicator for the same reasons.

Policy Manager UI

[Ben Bucksch]

By coincidence, I just found that somebody implemented a Policy Manager 
UI as add-on. Several people here said in the past that they would be 
interested in getting this into Mozilla, but I never saw implementations.

I haven't tried it myself, just passing the info.

<http://www.cc-net.or.jp/~piro/xul/_policymanager.html>

I bcced who seems to be the author.

Ben Bucksch

Re: Web application security w getstring

[Ben Bucksch]

 

 
lists some problems to consider.

Mitchell Stoltz wrote:

> Those long query strings can serve both purposes - security and 
> customization. They do roughly the same thing as cookies, although 
> each has its advantages and disadvantages.

> Justin wrote:
>
>> I'm a newbie to web app security. Are URLs you see with long 
>> querystrings,
>> for security reasons or to allow the end user to add to favourites 
>> (get the
>> exact same page/situation back- url integrity). I'm learning how to 
>> maintain
>> a 'session' with a logged-in user.
>>
>> Tks
>> Justin
>>
>>
>>
>
>
>

Re: Email viruses vs Mozilla Mail: is this overstating the case?

[Ben Bucksch]

[Is Mozilla Mail vonerable to virii (as OE)?]

OE worms exploit security bugs in Outlook, MSIE or another accessible 
ActiveX component. Being vulnerable to worms is not a feature of OE :). 
Of course, Mozilla also can and does have security bugs. As such, it is 
in principle as vulnerable to worms as OE.

HOWEVER, it now depends on the security strategy on how often such bugs 
appear. Microsoft has an extremely bad track record of security bugs. 
Some of that might be due to the wide deployment, but that's not all. MS 
also usually values features over security, and thus takes great risks 
like ActiveX and enabling scripting in mail. While ActiveX problems 
obviously don't apply to Mozilla, we have our own potential problem 
source: XUL.

The security strategy is also largely reflected in the default 
configuration. That's why Netscape 6, Mozilla and Beonex Communicator 
are very different in their vulnerability. (And that's where OE also 
falls short - extremely poor default config.)

* Netscape unfortunately chose to enable JavaScript in Mailnews by
  default, making many of the major Navigator security bugs
  potentionally exploitable in mail, possibly for email worms.
* Mozilla has JS in Mailnews disabled by default, making most (80+%)
  attacks run against the wall.
* Beonex Communicator has JavaScript in Mailnews disabled, currently
  with no UI to switch it on. It also has the Simply HTML mode
  enabled by default, which should send almost all attacks to /dev/null.


Your warning about running executables of course is always a good 
advice. Never run binaries you didn't expect (even if they appear to 
come from a friend - worms use your friends' address books to fool you). 
Mozilla based apps help here by (currently) not offering a way to start 
the binary from Mozilla - you have to save and then execute in the Explorer.

Re: mozilla.org statement on recent Mozilla vulnerability

[Ben Bucksch]

Frank Hecker wrote:

> Christian Biesinger wrote:
>
>> What about posting information about this vulnerability at this page:
>> http://www.mozilla.org/projects/security/known-vulnerabilities.html
>
> I've asked Mitch Stoltz (who maintains that page) to add an 
> appropriate entry. 

While you're at it, could you please add all the other bugs, too, closed 
ones and severe open ones?

Re: newbie security question

[Ben Bucksch]

Tony G wrote:

> Christian Biesinger wrote:
>
>> Beaumont Jones wrote:
>>
>>> i just starting using mac mozilla 0.9.9. is the encryption for 
>>> sending credit card info and that sort of stuff fairly secure?
>>
>> The 128 bit SSL-encryption that's used for sending encrypted data 
>> over the internet is considered very secure by cryptography experts. 
>> It would probably take (on average) years to decrypt a transmission.
>
Yes, 128bit are secure enough for credit card info, your addresses etc., 
provided that the intended reciever is trustworthy, of course.

The SSL / S/MIME scheme has some inherent weaknesses, if you try to 
protect yourself from powerful organisations like the U.S. government, 
but that's surely no concern for credit cards (all your financial data 
belong to them anyways :-( ).

Ben Bucksch

Re: automatic URL lookup on paste into window?

[Ben Bucksch]

Christian Biesinger wrote:

> However, there's a bug about not resolving names with spaces in them, 
> which I can't find right now. 


85677 

Re: css "exploit" kind of

[Ben Bucksch]

basic wrote:

> from what I know of the issue it is not a bug

Sure it is. The fact, if I visited a certain, different website is 
private. Leaking this info is a privacy bug.

I think that the property exploited is even proprietatry (i.e. not part 
of the DOM spec). But even if it is, then the spec is buggy and should 
not be implemented in that case.

Ben

Re: Risks using downled Mozilla builds

[Ben Bucksch]

Sven Krohlas wrote:

> Hi,
>
>> Wouldn't it be possible to modify the installer to be able to 
>> Download the Files being a normal user and only after all Files are 
>> copied to the local Harddisk to provide instructions how to do a 
>> system wide install? For people not really concerned about security 
>> this could be as easy as running a little Script.
>
>
> I think this is:
> "Mozilla-bin must not write to bin dir during installation"
> http://bugzilla.mozilla.org/show_bug.cgi?id=42184
>
No, that bug is about the main app, not the installer.

Re: Risks using downled Mozilla builds

[Ben Bucksch]

Thorsten wrote:

> Wouldn't it be possible to modify the installer to be able to Download 
> the Files being a normal user

> Is there any real reason, why almost the entire installation needs to 
> be done as root, just because someone wants a system wide install?

I agree that downloading should happen without root privs. I think that 
e.g. apt-get does that. Maybe the Mozilla Installer already does, I 
don't know. If not, file a bug.

Re: Risks using downled Mozilla builds

[Ben Bucksch]

Christian Biesinger wrote:

> Ben Bucksch wrote:
>
>> I wouldn't use the net installer at all and instead use the 
>> tarballs/zipfiles or the full installer.
>
> Well, that's useless - anybody who can manipulate the files that the 
> installer downloads can manipulate the installer itself as well so 
> that it would trust the binaries.

That's why I said you need to sign them!?!

> Also, if you would PGP sign the binaries, you would need to make sure 
> that the used key really belongs to mozilla.org/Netscape and is not 
> created by the one who modifies your binaries. But how can you be sure 
> that it does? You can't trust the internet for verification, because 
> the hypothetical person controls it (in your (Sven's) example).

1. The key usually lasts for a year, and subsequent keys can be verified 
with it. This means that I only have to get the right one *once* and not 
worry after that.
2. The "web of trust". The mozilla.org key can be signed by e.g. scc and 
Redhat. It is possible that I already trust one of them, directly or 
indirectly.

Re: Risks using downled Mozilla builds

[Ben Bucksch]

Sven Krohlas wrote:

>> Personally, I trust the ftp.mozilla.org I see more than the CD I get 
>
> I also trust ftp.mozilla.org, but the problem is that you can't trust
> the networks between your computer and ftp.mozilla.org

I understood that. ThatÄs why I said "the ftp.mozilla.org *I see*". I 
think, that risk is smaller than the risk of the computer magazine being 
cracked.

[computer magazines]

>> software, and probably just run Norton AV over it and that's it.
>
> Sad thing, what to do against this? 

Don't use these CDs... :-)

> The net installer exists, and so it is being used.

But not necessarily by the ones concerned about security.

The net installer is very helpful for Netscape, because it allows them 
to manage download streams (even the actual download URLs are downloaded).

> Due to this there is the responsibility to make it as secure as
> possible.

OK, do it :).

There's still lots of room to make Mozilla more secure, unfortunately.

Re: Risks using downled Mozilla builds

[Ben Bucksch]

(reposting, because I got "Service unavailable" from the news server.)

Sven Krohlas wrote:

 > One solution might be to get the installer from a "secure source"
 > (well, a nice
 > word for something that doesn't exist in relity, imho),

Yes, this is exactly the problem here.

 > Another idea was to provide md5 sums of all Mozill builds, but this
 > only semms
 > to make sens if you also sign these md5 sums, because someone who can
 > spoof
 > ftp.mozilla.org can also spoof any other server for you. This signing
 > could
 > happen via pgp,

Bug 68079.

In any scheme, at least one file has to be PGP-verified by the user (or
a user's agent like rpm). (Of course, at some point in time, the user
must have gotten the mozilla.org PGP key.)

Or am I missing a solution?

 > Don't use the net installer (and, for maximum security no downloaded
 > build),
 > but a version provided and verified by you favourite computer magazine.
 > This one is very ugly, the verification work would only be pushed to
 > another
 > place.

Personally, I trust the ftp.mozilla.org I see more than the CD I get
from my computer magazine. These guys deal with a lot of shaddy
software, and probably just run Norton AV over it and that's it.

I wouldn't use the net installer at all and instead use the
tarballs/zipfiles or the full installer. This is a single file, which
can easily be signed/verified via PGP. That's what I do with Beonex
Communicator. Just get mozilla.org to sign the packages on a machine not
directly accessible via the internet and forget about that net installer.

Ben

Re: Risks using downled Mozilla builds

[Ben Bucksch]

  Sven Krohlas wrote:

> One solution might be to get the installer from a "secure source" 
> (well, a nice
> word for something that doesn't exist in relity, imho),

Yes, this is exactly the problem here.

> Another idea was to provide md5 sums of all Mozill builds, but this 
> only semms
> to make sens if you also sign these md5 sums, because someone who can 
> spoof
> ftp.mozilla.org can also spoof any other server for you. This signing 
> could
> happen via pgp, 

Bug 68079.

In any scheme, at least one file has to be PGP-verified by the user (or 
a user's agent like rpm). (Of course, at some point in time, the user 
must have gotten the mozilla.org PGP key.)

Or am I missing a solution?

> Don't use the net installer (and, for maximum security no downloaded 
> build),
> but a version provided and verified by you favourite computer magazine.
> This one is very ugly, the verification work would only be pushed to 
> another
> place.

Personally, I trust the ftp.mozilla.org I see more than the CD I get 
from my computer magazine. These guys deal with a lot of shaddy 
software, and probably just run Norton AV over it and that's it.

I wouldn't use the net installer at all and instead use the 
tarballs/zipfiles or the full installer. This is a single file, which 
can easily be signed/verified via PGP. That's what I do with Beonex 
Communicator. Just get mozilla.org to sign the packages on a machine not 
directly accessible via the internet and forget about that net installer.

Ben

Re: Do we have a signing tool for Windows 2000 by Netscape?

[Ben Bucksch]

Leee wrote:

>I can't find a SignTool 1.3 for Windows 2000 from
>http://developer.netscape.com/software/signedobj/jarpack.html.
>
eh, try the NT4 one?

Re: Protect Script Code

[Ben Bucksch]

Henrik Gemal wrote:

> Paulo Lopes wrote:
>
>> Is there a way to protect javascript code?
>> Something like microsoft script encoder, but that aplies to Mozilla?
>
> Nope. MS Script encode is stupid and very easy to decode. 

I think it's impossible. Mozilla is open-source. I can always hack my 
Mozilla to display instead of execute the JS.

Apart from that, it is the wrong thing to do. The script is executed on 
the user's machine, so I believe the user has a right to see whst is 
being executed. Esp. because websites usually are not (and can not be) 
trusted by the visitor.

Ben Bucksch

Re: Feature request: Disable image loading in Mozilla mail

[Ben Bucksch]

Matt Sheffield wrote:

> I want to be able to use images on the WWW but never want to have them 
> in my e-mail (Web bugs). There should be a setting which allows the 
> user to control whether or not external image references are loaded. 
> This would enhance privacy and help reduce spammers' effectiveness. 
> Naturally, images would be enabled by default so newbies wouldn't have 
> trouble.
>
> I apologize if this feature has already been added. 

Bug 28327.

Re: Handling Mozilla security bugs, draft 8 ("release candidate")

[Ben Bucksch]

Frank Hecker wrote:

> The changes in this draft include: 

The changes you made look fine. More important are the changes you did 
*not* make.

All: I discussed a bit more with each of Mitch and Frank privately some 
time ago. Unfortunately, both discussions stopped at some point. I hope, 
they don't disagree with me discussing the 2 most important points here.


  1. Vendor warnings wording/content

Frank suggested the following wording wrt. vulnerability warnings:

"Mozilla distributors who wish to inform their users of the existence of 
a vulnerability may redistribute these [official] security warnings 
verbatim or use them as a basis for warnings to their own users. However 
Mozilla distributors and others should not publish information that 
could be used to create exploits for the bug."

That (which is different from the wording in the latest draft) would 
work for me, with one exception discussed next.


  2. No warning at all

Mitch told me that he in fact sees cases where a severe exploit would 
not be warned about at all. He mentioned the case, where the only 
workaround would be to stop using the product.
I do think that it is important to warn users even in those cases. If 
Netscape doesn't want to issue a warning to its users, that's Netscape's 
choice, but I would surely want to warn Beonex users. Under the current 
policy, I would not be allowed to.

Even if the strategy Mitch proposed might sound reasonable /from a 
certain point of view/, it is very problematic in practice. When exactly 
is there "no workaround"? For example,

* does disabling JavaScript count as workaround? I would surely say
  yes, and it would probably be the most common workaround, but
  somebody could argue that many websites are not usable at all
  without JavaScript. If we follow that argumentation, we wouldn't
  warn about the majority of severe bugs.
* If there is a buffer overflow bug in the image lib, does it count
  as workaround to disable images?
* If there is a overflow in HTTP, HTML or (mail-)MIME code, does it
  count as workaround to use a filtering proxy? Many companies force
  the use of a proxy anyway and could, maybe even without too much
  hassle, install a proxy [rule], which protects against the
  exploit. So, I would say that there is a workaround. Netscape OTOH
  might argue that most of its users are individuals which are
  connected directly to the internet and that it is (in fact)
  unreasonable to ask them to install a proxy.


I stick to my point that it is necessary to warn users about every 
severe bug. Every policy which disallows that does IMO put users 
unnecessarily at risk.

Re: connection to Netscape?

[Ben Bucksch]

[EMAIL PROTECTED] wrote:

> Anyone know why this connection is made from my PC to the host : 
> h-204-29-187-156.netscape.com on port 119 whenever mozilla is running? 

119 is "news" (usenet), the host is news.mozilla.org. Mozilla checks for 
new news postings!

Please use a valid From or risk to be ignored.

Re: whoops, the diff was garbled

[Ben Bucksch]

Mitchell Stoltz wrote:

> What about the other list address, [EMAIL PROTECTED]?

OK with me, but I don't care much.

>> Seriously, a .announce style mailing list is a good idea.
>
> Sounds fine to me, although I think the authoritative list should be a
> webpage. We can do a mailing list too.

No, my point is specifically that the mailing list must be authorative. 
I want to subscribe to that address and be sure that I get notified 
about new bugs (modulo technical problems outside mozilla.org). If 
someone posts a bug to the webpage only, and thus causing several 
parties not to notice the bug, the poster should have no excuse by 
saying that the web page is the only authorative source.

> Ben Buchsch wrote:
> > Everybody on the security bug group should be able to subscribe to the
> > security bug reports list.
>
> Everything I get from the bug reports address will be posted to a bug 
> right away, and the security group can view it there.

That's good.

> That way we won't have people filing duplicate bugs from the same 
> problem report.

We can avpid that by conventions (e.g. only the module owner files these 
bugs or anybody can file it, if it's not there already after some time). 
But I would still like to have some garantee that I can see all bugs. I 
see no reason why not everybody should be able to subscribe.

Re: Security Group Proposal, Draft 7

[Ben Bucksch]

Mitchell Stoltz wrote:

> I think "security" is ambiguous, and doesn't precisely describe the 
> purpose of the address, which means it may attract more off-topic 
> posts. People may think it's for discussion of cryptography 
> engineering or physical building security or the security of Mozilla 
> servers, none of which is the case. More off-topic, irrelevant posts 
> to this address means more work for the maintainers.

That's right. There will most likely lots of ofoftopic mail to this 
address. But I think that the advantage of possibly getting more / 
earlier reports because of being able to reach easily is more important 
than the convience of the maintainers.
Note that the "right" way to file the bug reports is bugzilla anyway. 
This only purpose of this alias is to be reachable easily.

Re: whoops, the diff was garbled

[Ben Bucksch]

Mitchell Stoltz wrote

>! The Mozilla security bug group will have a private mailing list,
>! [EMAIL PROTECTED],
>
Good.

>to which everyone in the security bug group will be subscribed. This
>! list will act as a forum for discussing group policy
>! and the addition of new members, as described below. In addition,
>! Mozilla.org will maintain a second well-known address,
>! [EMAIL PROTECTED], through which people not
>! on the security group can submit reports of security bugs. Mail
>! sent to this address will go to the security module owner and peers,
>! who will be responsible for posting the information received to a
>! security bug.
>
Everybody on the security bug group should be able to subscribe to the 
security bug reports list.

The list should (maybe additionally) have the conventional alias 
<[EMAIL PROTECTED]>.

>! A typical warning will mention the application or module
>! affected, the affected versions, and a workaround (e.g. disabling
>! JavaScript).
>
* Description of bug
* Maybe limiting factors
  (in case only certain user groups are affected, other groups can
  safely ignore it)

>If the group decides to publish a warning, the module owner,
>! a peer, or some other person they may designate will post this
>! message to the
>! http://www.mozilla.org/projects/security/KnownVulnerabilities.html";>
>! Known Vulnerabilities page.
>
The mailing list is still missing. It is not reasonable to ask Mozilla 
contributors to reload the page twice a day or so.

Re: Security Group Proposal, Draft 6

[Ben Bucksch]

Gervase Markham wrote:

> Ben Bucksch wrote:
>
>>  Gervase Markham wrote:
>>
>>> If a bug is security-confidential, then some form of warning will be 
>>> agreed (unless none of the participants requests that one be agreed.)
>>
>> What if not? 
>
> If you ask in the bug for the participants to agree a warning text, 
> one should be agreed.

I'm talking about a case where a strong party disagrees that *anything* 
at all should be make public. E.g. Netscape or someone else finds the 
GIF buffer overflow you mentioned, and Netscape doesn't want to have any 
warning made by any vendor.

> If you want that stated in the policy, say so - but it seems like 
> common sense to me.

You mean that there will *always* be a meaningful warning, if *I* (i.e. 
any participant in the security bug group) want to? If you write that in 
the policy, that'd be good.

[part cutted - I'd only repeat myself, if I replied.]

>> Weren't we talking about consensus?
>
> We were. But it appears we have reached an impasse.

Right. Not only can't I get my views reflected (forced disclosure, even 
if unfixed, after a certain amount of time), it seems like I have to 
fight very hard for my absolute minimun requirements. I have no 
experience in these things, but I think that's usually the point where 
either the other party agrees or the fighting party leaves the negotiations.

> you [...] perhaps hurting their users by being over-generous with 
> vulnerability information.
>
> If you claim that the latter could never happen, then you should have 
> no objection to saying only what is agreed by the group.

The latter assertion is wrong. I am concerned that a strong party in the 
group deliberately blocks or obfuscates the warning in order to hide the 
bug.

>> How am I going to "shaft" their users??
>
> As I understand it, the entire reason that this web page announcement 
> proposal has been put forward is so that a member of the security 
> group does not (advertently or inadvertently) reveal information which 
> leads to trouble for the users of other members' software. This is why 
> what is said must be agreed upon.

blabla. Please explain, concretely, how Netscape's users would be harmed 
by me informing my users about security holes in Beonex Communicator / 
Mozilla. (No concrete reproduction info, of course.)

>> You cannot ask me to reload the page every 3 hours, if I want to be 
>> sure to get the latest warning.
>
> You as a distributor of Mozilla-based products, or you as an end-user?

As whoever needs to know what is on the page.
The page is intended for mainly Mozilla contributors.

Re: Security Group Proposal, Draft 6

[Ben Bucksch]

  Gervase Markham wrote:

> If a bug is security-confidential, then some form of warning will be 
> agreed (unless none of the participants requests that one be agreed.)

What if not? What if it takes too long? What if it's inappropriate for me?

> On the other hand, take the GIF overflow bug in NS 4.77 as an example. 
> If we had a bug like that, are you really going to warn your users to 
> disable images?

Maybe. Maybe I'm going to warn them to possibly not use the browser at all.

> I think that the answer to this is basically "you can't have it."

Then I think my answer to this will basically be "Then I don't want to 
play with you".

Weren't we talking about consensus?

> I'm not saying that this possibility allows Netscape to dictate the 
> terms of the entire security group proposal without discussion; I am 
> merely making the point that the usefulness of the group goes up with 
> the number of the participants, in proportion to what those 
> participants contribute.

And I am saying that too "liberal" terms in the security bug group make 
it useless for me, no matter if anybody participates or not.

> If Netscape feels it can't contribute because it can't be sure you 
> aren't going to shaft _their_ users, then they won't.

How am I going to "shaft" their users??

> I think Mitch is saying that the web page (which has checkin and 
> change control) is the master source,

Which I think is wrong. You cannot ask me to reload the page every 3 
hours, if I want to be sure to get the latest warning.

Re: Security Group Proposal, Draft 6

[Ben Bucksch]

Jesse Ruderman wrote:

>How about having a sublist to which users can send reports of new security
>bugs, so not all members of the list have to recieve all the spam?
>
.../discussion.

Agreed. <[EMAIL PROTECTED]> should be reserved for new reports, not 
used for long discussion.

>Reporters are unlikely to care about the bug several months after it is
>fixed, and are even less likely to care enough to ask permission to open it.
>
Ex-act-ly.

>Reporters should have the *ability* to open bugs to the public, but they
>should not be relied upon to make their bugs public several months after the
>bugs are fixed.   That responsibility should lie elsewhere (hi BenB).
>
Wave :).

Re: Security Group Proposal, Draft 6

[Ben Bucksch]

Mitchell Stoltz wrote:

> As module owner, I'd be happy to maintain that page, along with 
> whoever we pick as peers. As with the rest of this proposal, I expect 
> that the amount of information disclosed on the public page will be 
> decided by consensus among the security group on a per-bug basis.

"Consensus" is such a thing. Do we have consensus on a security policy 
for Mozilla? No.

>! When a bug is put into the security group, the security
>! group members, bug reporter, and others associated with the bug
>! will decide, either through comments on the bug or the security group
>! mailing list, whether an immediate warning to users is appropriate
>! and how it should be worded. This warning should mention the existence
>! of a vulnerability, which features or modules are affected, and a
>! workaround, if one exists. The module owner, a peer, or some other
>! person they may designate will post this message to a 
>! "Known Vulnerabilities" page, which will be maintained at a well-known
>! location on on www.mozilla.org. These messages will contain all of the
>! information that the security group has agreed to be safe for
>! immediate public disclosure. Mozilla distributors who wish to inform
>! their users of the existence of a vulnerability may repost these
>! messages to their own websites, mailing lists, release notes, etc, as
>! long as they don't disclose any additional details about the bug.
>
That's much less than you said were OK in your last posts and much less 
than I need. You now constrain the info I give my users to what you 
publish for Mozillam, while yesterday, you said "You can inform *your* 
users via your mailing list, release notes, etc, as long as you make an 
effort not to provide enough information to allow someone to reproduce 
the bug".

I want to issue warnings (to my users)

   1. for *all* bugs I consider severe enough and
   2. in I wording I choose, with content I choose (as long as I don't
  disclose reproduction info or something close to it)


Rationale:
2., because my users are of course less technically savvy than Mozilla 
contributors, and the workarounds are also likely to be different for 
Beonex Communicator (different default settings, different install 
strategy etc.). I might even need to reveal more (still vage) facts 
about a bug than the official warning does, when I think that this is 
necessary for my users to judge their risk and to work around the bug.
Reaching "consensus" also takes time, more time than is acceptable for 
me in some situations.

1.: please try to understand my situation. I see a bug, know that users 
risk their whole network security because of that buffer overflow, and, 
for any reason, the reporter or the security group decides not to issue 
a warning, so I am not allowed to warn my users. That's unacceptable and 
cruel (sorry for the hard word, but that's how I feel about it).


If you want to prepare the warnings for mozilla.org, incl. their 
wording, in the security group, that's certainly fine with me.
BTW: I wouldn't define a web-"page", because I think that 
newsgroups/mailing lists are the best method to publish such urgent and 
important info. Having the same info additionally on a webpage is surely 
nice, though.

> If disputes arise about whether or when to disclose information
>! about a security bug, the security group will discuss the issue via
>! its mailing list and attempt to reach consensus. If
>  necessary mozilla.org staff will serve as the "court of last
>  resort."
>
Great!

Re: New proposal for handling security bugs

[Ben Bucksch]

Christopher Blizzard wrote:

> What this policy does is set up a framework for end user distributors 
> and other interested parties to share information about security 
> vulnerabilities

You seem to assume that reports come from "inside", from parties (esp. 
companies) developing Mozilla. While that might be true for many bugs, 
it is by no means true for all of them.

I hope that a considerable amount of bug reports come from people not at 
all involved with Mozilla development or from individual developers. We 
need to set a policy for them, because they most likely have no opinion.

> Ben talks a lot about people who report bugs who might be naive and 
> might be influenced by the big bad corporations waiting around the 
> corner to protect their products but I don't see this as a major 
> problem.  Remeber, there are lots of reasonable non-corporate people 
> who will be involved in this security group, Ben included,

You call me reasonable? Wow! ;-P

> to keep this kind of behaviour in check if it does happen ( and I 
> doubt that it will. ) 

First, I don't want to go after Netscape mnd make sure, it plays nice. 
Second, I can't, as I outlined. because in the current scheme, Netscape 
will probably talk to the reporter privately, so I won't even notice. 
Please see previous conversation with Frank.

Re: New proposal for handling security bugs

[Ben Bucksch]

Mitchell Stoltz wrote:
[citation from draft proposal]

> Ben Bucksch wrote:
>
>> Just that this point says "fixed", while I want to inform in both 
>> cases - when a bug gets discovered (and I have a workaround) and when 
>> I have a fix.
>
> That's what I intended. Sorry for the confusion.

That's very good, thanks for the clarification.

But now I am a bit confused for another reason. What you say suggests 
that *you* wrote that paragraph in the proposal, while Frank said, he 
wriote the proposal without consulting Netscape.

> You can inform *your* users via your mailing Yes, they could subscribe 
> to your mailing list, but fewer people will think to look there than 
> Mozilla, and the information they find on your mailing list will not 
> be sufficient to reproduce the bug. That's two levels of protection.

[For the record: Here, I am not proposing to release details about a 
bug. I just propose to issue a vage warning to a dedicated Mozilla list.]

Note that the "fewer people" also includes people working on Mozilla. I 
think, we have the responsibility to protect them.

> Absolutely it will happen. Look at all of the bad PR Microsoft gets 
> about its security vulnerabilities. Whether you consider PR to be a 
> valid reason is irrelevant - vendors do, and it will affect their 
> decision to participate.

No, the bad PR of Microsoft comes from crackers exploiting (long-known) 
holes on a very large scale, not from Microsoft notifying users about 
the holes. Au contraire, the fact that Microsoft issues bugfixes before 
the hole has been exploited was very *good* PR for Microsoft in the most 
recent cases.

> Let me revise that. "everyone who needs to be protected from an 
> exploit will be protected."

ok.

> Users of Mozilla builds are protected by frequent and regular releases 
> - if you're using dailies, then the bug will probably be fixed in a 
> matter of days anyway. 

I disagree here. We have no garantee at all that bugs are fixed quickly. 
Which means that there is a considerable time where Mozilla contributors 
are unnecessarily vulnerable. "Unnecessarily", because they could 
protect them from the bug, if somebody told them to.

> If there were really a bug serious enough to delete a user's hard 
> drive, we (the various vendor reps and security folks) will discuss 
> via the security newsgroup what the appropriate response should be. 
> Bugs of this severity are *rare* and can be handled as they come along. 

This was just a comparison. Few security bugs will delete the harddrive. 
But many of them have the risk of private data being exposed to 
unauthorized people. That's what security bugs are all about, not? Or do 
you have a much broader definition of security bugs than I do? (Which 
would concern me for other reasons, i.e. that too many bugs end up 
confidental.)

>> and may publically speak about what happens in the security group 
>> (but not mention specific exploits or details about a bug itself)
>
> There's a difference between 'publicly' and 'with your own customers.'

In this case, I meant public, e.g. talking on n.p.m.security. OK, I was 
speaking only half as Beonex representative and half as Mozilla contributor.

> I believe this is a real difference. What do you mean by "what happens 
> in the security group?" If you mean matters of policy, those will be 
> added to the policy document, which will be publically available. If 
> you mean discussion about sepcific bugs, that's what you can't discuss 
> publically.

What I am thinking of is that I strongly disagree with the decisions 
made in the security group and that I want people outside of the group 
to be aware of it. It is basically about discussing policy, but at 
mozilla.org, from my experience, most people seem to be pragmatic and 
won't accept a general description of an abstract problem without me 
mentioning an actual problem which they can discuss.

That's why I might want to say (I'm making this up, of course) "We have 
that buffer overflow bug in HTML form submittion, but these bad boys 
from Netscape in the security group refuse to fix it correctly, because 
they say, it would require them to remove that feature which their 
marketing dept thinks it needs, and to make matters worse, it seems like 
they are talking the naive reporter into never disclosing the bug." I 
would of course try hard not to mention enough details to disclose the 
bug at the same time.

In other words, I want only the details of bugs (which can be used to 
reproduce the bug) to be confidental, nothing else.

> All right then, what do you propose? How would you write the policy?

See my reponses (and suggestions) to Frank. I already thought about 
creating an alternative proposal, but it would only summarize what I 
already wrote and I first want to hear, if Frank or anybody else has any 
substantional counter-arguments.

Re: New proposal for handling security bugs

[Ben Bucksch]

Mitchell Stoltz wrote:

> You've both missed this point:
> --- begin quote ---
> Mozilla distributors participating in security bug group activities 
> can mention in their release notes that a security bug has been fixed, 
> but we ask that they be vague and not describe the exploit in detail.
> --- end quote --- 

No, I didn't. Just that this point says "fixed", while I want to inform 
in both cases - when a bug gets discovered (and I have a workaround) and 
when I have a fix.

> However, I think there's a distinct difference between *allowing* 
> individual vendors to inform their users, ship new versions, mention 
> the bug in the release notes, etc, if and when they deem necessary, 
> and *requiring* that Mozilla.org post even a vague description of each 
> and every vulnerability submitted.

I don't see the difference. In both cases, the public knows about the 
problem. It's not too hard to subscribe to Beonex's announce mailing 
list and then assume that the same bug is in all derivates of Mozilla, 
especially when I say that the bug is not Beonex-specific (just like 
Debian does in its notices). Crackers are not *that* dumb.

> The latter will discourage many vendors from participating at all, 
> enough so that the security group will become pointless.

Can you explain why? I see absolutely no rationale. (Other than bad PR 
maybe, which I don't think will happen or consider a valid reason in 
this case.)

> My understanding from Mozilla.org (Mozilla staff, please correct me if 
> I'm wrong) is that Mozilla is not an end user product.

Agreed. That's why I spoke about testers when I spoke about Mozilla.

> All users of the Mozilla browser are considered to be beta testers, 
> and Mozilla makes no guarantees about the safety of any build, 
> including milestones.

There is a huge difference between not being able to garantee safety and 
deliberately not informing testers about known, severe bugs.

In fact, not even Netscape or Microsoft garantees safety for any 
software it releases, to my knowledge.

How would you think, if it were known that a certain Mozilla build 
erases your harddisk, but nobody would tell you, because "they decided 
not to"? Not informing users grossly raises the risk, and I am not 
willing to take *that* risk.

I am using Mozilla under the assumption that everything possible is done 
to prevent me from such desasters like severe dataloss or security bugs. 
If you don't do that, the risk is too high for me. Actually, I would 
consider that being close to malice (lacking a better word).

> Vendors such as Netscape, Red Hat, and Beonex turn these betas into 
> end-user products, and vendors bear responsibility for the safety of 
> those products.

Where?

> I would argue that everyone who needs to know about the bug will still 
> have access to it through their representative on the security group.

Depends on how you define "know". Or am I allowed to mention details ot 
the bug to a customer?

> I realize that this proposal isn't perfectly "open,"

hah

> but it's a compromise that I believe vendors can accept.

If I may issue vage warnings (but a bit more concrete than what Frank 
described) and workarounds at any time and may publically speak about 
what happens in the security group (but not mention specific exploits or 
details about a bug itself), then yes, this is what is acceptable to me 
as a distributor.

But this does not mean that it is the right thing to do for Mozilla in 
general or that this allows ideal treatment of security bugs. (And, in 
these indirect and abstract ways, the current proposal is IMHO no good 
for Beonex Communicator or Netscape 6 or any other Mozilla.)

> The alternative is for vendors not to file vulnerabilities in Bugzilla 
> or disclose them to Mozilla.org at all.

That remains to be seen. I do think that a compromise could be found 
that respects more the open nature of open-source projects and the 
believes of many people (as I understood it). In the current proposal, I 
see no compromise at all.

Re: New proposal for handling security bugs

[Ben Bucksch]

Frank Hecker wrote:

> However I believe the intent was that we (mozilla.org staff) would 
> encourage the security module owner, peers, and the security bug group 
> to consider issuing such vague warnings where appropriate, but would 
> not mandate as an absolute policy that this be done immediately upon 
> the security bug group becoming aware of the existence of a bug. 

Would I be *allowed* to issue such warnings on my own, without havong to 
ask anybody, on a regular basis, to a Mozilla forum or to my own 
(Beonex) users?

Your response to my proposal suggests that some reporters might object 
to a warning policy, so why wouldn't they object to a warning done by me?

Re: New proposal for handling security bugs

[Ben Bucksch]

Stuart Ballard wrote:

>So would you [...] allow bugs to be kept secret
>indefinitely if a fix is provided?
>
No. No bug should ever be kept confidental infinitely. All bugs should 
be, in any case, opened after about 6 months. That's another defect in 
the current proposal IMO.

Information about bugs is important to

* learn about earlier errors (developers)
* review, how a bug has been treated (developers and users)
* know, why particular code is there in that way (developers)

Re: New proposal for handling security bugs

[Ben Bucksch]

Stuart Ballard wrote:

>It may be that someone's latest
>branded release has the bug, or something else, but there must be
>*something*.
>
That's almost always the case. The worst and thus most important and 
interesting bugs will probably be kept condfidental for a years or so.

>And when that "something" no longer applies, the bug should be opened;
>the current policy leaves it up to the reporter with the implication
>that overriding by the module owner or staff@mozilla will be a rare last
>resort. I'd like it to be more clear that the module owner and the
>security group will routinely work to open up a bug - preferably with
>the consent of the reporter, but without the reporter having to initiate
>the process. Just suggest that the security group be actively looking
>for the earliest time consensus on opening the bug could be reached, as
>opposed to passively waiting until the reporter suggests it.
>
I don't think that will work. I expect many parties with an interest in 
closure being members of the security group, and people falling back to 
closed when they are not sure, because "there's nothing to harm if we 
don't disclose, but much to harm if we do" (they think).

In other words, I trust neither mozilla.org staff nor the security group 
at large to do the right decisions about disclosure. Even if they do the 
right thing most of the time, that's not enough. It's the exceptions 
that count here. One open security hole is enough to let everything fall.

Re: New proposal for handling security bugs

[Ben Bucksch]

Frank Hecker wrote:

> The problems you're concerned about are mainly problems when the bug
> reporter is a Mozilla vendor with an incentive to keep the bug
> confidential. They can take advantage of their position as a bug
> reporter to try to keep the bug private.

This concern seems to be the base of much of your reasoning. I have an 
idea about it: To allow a vendor to participate in the security group, 
we mandate that the bugs this vendor knows about can be used at least 
under these and these terms. That's similar to the idea of (limited) 
copyleft - we give you something, but you have to give us something 
comparable in return. That way, we could impose *some* terms on vendors.

We'd have to see, if that works for Netscape, but all other vendors will 
probably have more to gain than to lose and will agree.

Re: New proposal for handling security bugs

[Ben Bucksch]

Stuart Ballard wrote:

>This would include notifying your users of the bug's existence as soon
>as it is found (provided you only do so in a vague way)
>
That is what I need to do, but I am disallowed to do that (to my 
understanding) under the new scheme.

Re: New proposal for handling security bugs

[Ben Bucksch]

Frank,

I repect you, but I strongly disagree with you here and with the 
proposal. I believe that it is completely inadequate for an open-source 
project.

Frank Hecker wrote:

> > What, if that bug or strongly related topics are discussed on the
> > mailing list? IMO, there should be a policy that those people are added
> > to the (email) cc list of such discussions.
>
> That's a reasonable request; however note that there's no technical way
> to ensure that a bug reporter gets cc-ed on all correspondence.

(I know. But policies don't necessarily have to be enforced by technology. )

> > Involvement of the original reporter is essential, because 
> sometimes, he
> > is the only one involved who is really interested in getting the bug
> > fixed right. (This is nothing against anybody working on Mozilla, but a
> > general (sad) statement).)
>
> I agree 100%. That is why this policy tries to put the bug reporter at
> the center of the process of investigating and resolving security bugs, 

But, apart from the bug reporter, users have a vivid interst in the bug 
being fixed, just that they are not directly involved. Thus, mozilla.org 
should represent also its users, maybe even primarily so, because 
developers are already represented. That's why I think that mozilla.org 
should do its share to force developers to fix these bugs.

The current proposal does nothing like that. In that proposal, 
mozilla.org does not help users in any way, instead it favors only the 
needs of some commercial distributors. It lays all burden on the 
reporter, which might be identical to the commercial distributor or 
which might be an unexperienced individual that is easily influenced.

> One major goal of this policy is to give potential reporters of security
> bugs a reason to work within the Mozilla project processes, as opposed
> to putting potential reporters in a position where they have to work
> outside those processes.

I can see the rationale, but you are going way too far to please 
commercial bug reporters and do nothing for users. It is not balanced in 
any way.

> > I strongly believe that each new bug reported confidentally should
> > *immediately* be reported in a vage way to the public.

[...]

> > I believe that the public has at least the right to know that there 
> is a
> > bug and roughly where it is. This allows people to protect themselves,

[...]

> "What I object to is making it a precondition of forming the security
> [bug] group that mozilla.org mandate such warnings as a universal
> policy. While this may be the right thing to do in theory, in practice I
> think mandating such a policy would potentially lead to some Mozilla
> distributors choosing not to participate in the security group, and
> doing things on their own behind closed doors.

I do believe that mozilla.org, being an open-source project, has the 
*obligation* to do the "right thing" and protect end-users*, testers and 
developers. (*See below, why I include end-users.)

I see no valid reason for not wanting to have this kind of information 
(vage warnings about bugs and workarounds) being publicized.
If there really are parties who would not disclose bug information under 
these terms, they should speak up and defend their position here. We can 
then decide, if the arguments are valid and if the information coming 
from the disagreeing party is valueable enough for mozilla.org to do the 
wrong thing and to risk the direct security and privacy of its 
contributors and testers (the *other* "hands that feed it") for the sake 
of getting this additional, confidental information. But I think that 
even in that case, we could find a compromise.
If there is nobody objecting in that way, then we should make this a 
policy, or at least allow someone in the security group to release such 
warnings.

> And that in turn
> potentially lessens the benefit to everyone (including users) of having
> a security [bug] group in the first place.

I don't think so. I do think that the security bug group, as proposed, 
is almost useless, apart from letting a few people (who *really* need to 
see that info *anyway* and who should have seen it from the beginning) 
see the bugs.

Actually, if you don't even allow me to warn my (Beonex end-)users about 
new bugs and to give them workarounds, even seeing the bugs is hardly 
useful for me as a distributor. I can also get the information, that a 
bug has been fixed, from the CVS logs (although that is admittedly much 
harder and obscure).

> I presume it means something like "#@?&!" :-)

(Correct. It was by accident, I sent this mail too early, sorry.)

> > If security-concious people get to
> > know about that, it drives them up the wall and they generally loose 
> all
> > trust in that vendor. I don't think, mozilla.org should support such
> > irresponsible treatment of security bugs.
>
> As I said above, mozilla.org is prepared to step in if we feel that a
> particular vendor is abusing the system and trying to k

Re: New proposal for handling security bugs

[Ben Bucksch]

Stuart Ballard wrote:

>I don't know whether this will affect your views, but did you notice
>that under this policy, the "small, hand-picked group of people" would
>almost certainly include yourself?
>
Yes, I am aware of that. Actually, Mitch said something like that I 
"would certainly be part of such a group" in an earlier post. All I 
wrote here is written under the assumption that I will be part of the 
(larger) security group.

I am very glad about that, as I really need that info, but that's also 
why I see it as something like "stating the necessarity". But the 
proposal doesn't even allow me do to everything I need to do for Beonex.

Much less does the proposal do what I think is the right thing in general.

Re: New proposal for handling security bugs

[Ben Bucksch]

Frank Hecker wrote:

> If you're wondering why I'm reluctant to commit on this, I have the 
> selfish motivation that I don't want mozilla.org staff (including me) 
> to have to specify in advance excactly what should be done for each 
> and every possible contingency. I would prefer to delegate to the 
> module owner, peers, and the security bug group where possible.

But you are delegating to a small, selected and confidental group. I 
think that the policy should be decided by the public. (Actually, I 
think that this is of vital importance.)

> To repeat, I'm not confident in our ability to pick (especially in 
> advance) a single time limit scheme that everyone is happy with and 
> that will make sense in every possible combination of circumstances. 
> However I'm happy to have experience to prove me wrong, and if we 
> adopt an initial policy without fixed time limits, I'd be glad to go 
> back and revisit the question later.

Note that other organizations did specify hard time limits for such 
matters. (Not that I would agree with their policies, but for other 
reasons :).)

Re: New proposal for handling security bugs

[Ben Bucksch]

Frank Hecker wrote:

> * Full information about security bugs will be restricted to a
>   known group of people, using the Bugzilla access control
>   restrictions described above.
>

> * As noted above, information about security bugs can be held
>   confidential for some period of time; there is no pre-determined
>   limit on how long that time period might be. However this is
>   offset by the fact that the person reporting a bug has
>   visibility into the activities (if any) being taken to address
>   the bug, has the primary responsibility for deciding when the
>   bug report should be opened for public scrutiny, and has the
>   power to do so.
>

> * A person who reports a security bug will have continued access
>   to all Bugzilla activities associated with that bug, even if the
>   bug is marked "Security-Sensitive."
> * Any other persons may be given access to a particular security
>   bug, by someone else (who does have access) adding them to the
>   CC list for that bug.
>
What, if that bug or strongly related topics are discussed on the 
mailing list? IMO, there should be a policy that those people are added 
to the (email) cc list of such discussions.

Rationale:

* Bugzilla is not an ideal platform for longer discussions, thus it
  sometimes makes sense to move a discussion which started in a bug
  to a mailing list.
* Members of the security group might be tempted to move discussions
  to the list specifically to exclude the reporter or other people
  on the cc list. I don't think, this should happen, unless the
  group at large decides so for good reasons.

Involvement of the original reporter is essential, because sometimes, he 
is the only one involved who is really interested in getting the bug 
fixed right. (This is nothing against anybody working on Mozilla, but a 
general (sad) statement).)

> The criteria for membership in the Mozilla security bug group are as 
> follows:
>
> * The applicant must be trusted by those already in the group.
> * The applicant should have a legitimate purpose for wishing to
>   join the group.
>
What is "legitimate"? "I want to fix a few security bugs."? "I want to 
do a securty-audit of Mozilla."?

> We reserve the right to cap the membership at some reasonable level, 
> either by refusing new applications or (if necessary and appropriate) 
> by removing some existing members of the security bug group to make 
> room for new ones.
>
But that "reasonable" must depend on the size of the Mozilla project. 
The more people

> Mozilla distributors participating in security bug group activities 
> can mention in their release notes that a security bug has been fixed, 
> but we ask that they be vague and not describe the exploit in detail. 
> (For example, a release note could say, "This release fixes a serious 
> security bug involving HTML form submission.")
>
I strongly believe that each new bug reported confidentally should 
*immediately* be reported in a vage way to the public. See an older post 
of mine for details.

E.g., we create a newsgroup .security-announce and whenever a security 
bug gets reported, a certain person has the reposibility of posting a 
summary (without details about how to exploit it) to that group.

I believe that the public has at least the right to know that there is a 
bug and roughly where it is. This allows people to protect themselves, 
e.g. by disabling JavaScript or avoiding to use Mozilla to submit 
sensitive information in https HTML forms or whatever.

Rationale:

* There might be distributors who are denied join the security group.
* There are lots of people testing Mozilla by doing their day-to-day
  work with it, and they have a right for their security too.
* Such a newsgroup is a convient and visible way to be warned and
  notified about security bugs, for all parties:
  * People new to the project will find the newsgroup very quickly
  * Even people in the security bug group have a nice and
easily-tracked way to keep themselves informed.
* That newsgroup acts as public archive for very important
  information about Mozilla. (Bugzilla might be down, mozilla.org
  might cease to exist, etc.)


Also, in any case, distributors *must* have the right to inform their 
users about the bug (in a vage way, but with suggested workarounds) as 
soon as it has been discovered.


If a bug is fixed, a followup to the warning should be posted, saying 
that the bug is believed to be fixed from build / CVS source x on.

> This level of generality informs users without potentially causing 
> security "fire drills" for other Mozilla distributors.
>
Well, I believe that fire drills are good and necessary here. :-)

> The original reporter of a security bug has the primary responsibility 
> for deciding when that bug will be made public; disclosure is done by 
> clearing t

Re: Web content filtering - can we use this idea?

[Ben Bucksch]

Nils Ellmenreich wrote:

> I was talking about the referrer header string. If you remove it, 
> there are indeed pages that block you (IIRC, e.g. Cartoon pages from 
> the Washington Post)

Oh, I got confused.

What other major sites block you, if you don't send a referrer? (I 
worry, because Beonex Communicator ships with referrer off.)

I agree that a UI pref would be good. Should be trivial to add.

Re: Web content filtering - can we use this idea?

[Ben Bucksch]

Nils Ellmenreich wrote:

> That's not quite a solution, because you'd have to quit Mozilla to 
> change it.

That's just a matter of an interface. The pref do supports switching at 
runtime, I think. You mioght be able to set it in the JS console - never 
tried it. Otherwise, there's a bug about a UI.

> All theses capabilities we've talked about sometimes inhibit you to 
> see a particular web page.

I'll take your word, but I didn't come across a page yet that would 
block Mozilla due to the UA, I think.

> Related to this, there's a bunch of other options/prefs you frequently 
> want to change at runtime (I think we've talked about it in a previous 
> thread). Anyone seen the "Settings" menu in galeon? That's all you 
> need, it's extremely useful. But all the Mozilla bugs filed on this 
> topic seem to go nowhere  :-(

There's something bigger, together with a sidebar UI planned, I think. 
No ETA.

Re: Web content filtering - can we use this idea?

[Ben Bucksch]

Nils Ellmenreich wrote:

> - banner ad (site) blocking based on regexps (that's more powerful 
> than the current "block images from this server"). Like junkbuster, 
> I'd like to have regexps on entire URLs 

Yup. With one short and simple regexp, you can strip out 80+% of the 
ads. (Squid supports that too.)

> - Removal of referrer header 

Already implemented and working as pref (no UI).

Re: Project Cheese - Mouse movements on website tracked

[Ben Bucksch]

Stuart Ballard wrote:

>The only surefire way seems to be to disable onmouseover and onmouseout,
>
Right, and onmousemove.

>which we can already do.
>
Really? How? As I see it, 
 
describes only, how to disable JavaScript functions, not the triggers, 
i.e. HTML attributes. That's what bug 64737 is about, not?

Re: Mozilla and On-line banking

[Ben Bucksch]

Mitchell Stoltz wrote:

> Several banks block Netscape 6.1 (which has the user-agent string 
> "Mozilla/5.0...") because they believe it's not secure.

> your bank is just being stupid.

What was the reason for them believing, Netscape 6 were not secure?

Did they install an old Mozilla, forgot to install PSM and thought, 
Mozilla had no crypto, or what?

Re: Web content filtering - can we use this idea?

[Ben Bucksch]

Mitchell Stoltz wrote:

> http://spywaresucks.org/prox/index.html
>
> it's software that runs regexps on incoming web pages. The author has 
> written regexps that do all kinds of interesting content filtration: 
> popup blocking, banner ad blocking, filtering various types of 
> annoying content, and cookie filters (by filtering http headers and/or 
> Javascript).

There are quite a number of packages that do that: I once tried to use 
muffin and filterproxy.

> Could we incorporate any of this guy's ideas into Mozilla?

This was supposed to be part of "Transformation Services", a "blue-sky" 
idea I once kind of worked on. Bug 13014. (But the "filters" in my old 
desgin didn't use the Mozilla HTML parser - please also consider the 
time when judging.)

> Please look through his list of filters and let me know of any you'd 
> particularly like to see implemented in Mozilla.

I already thought about a "santinizer" in Mozilla. It would be located 
near the parser and drop all tags and attributes not explicitly allowed. 
The rendering engine would never see them. This would be useful for HTML 
mail and "cleaner" web browsing.

>   Thoughts?

Great idea. I didn't know, if that was supposed to be on-topic in 
Mozilla. You can do that with external apps (like the one you 
mentioned), but they are a hassle to configure, for normal end-users at 
least.

On a related topic - I am totally unclear about how well we are 
protected against buffer overflows. Is the parser believed to be secure? 
Does it truncate bogus part, protecting the renderer from overflows?

Project Cheese - Mouse movements on website tracked

[Ben Bucksch]

MIT is exploring, what I was scared about with JavaScript and XMLExtras: 
Tracking not only links, but also mouse movements of website visitors. 
Appearently, they are recorded via a JavaScript (onmousemove), sending 
it back to the server and analysing it there.

They had a 65+% hit rate at guessing, what the user would have been 
interested in next.

(The report also mentions that another project recorded the scrollbar 
activity to measure interest in a page.)

http://gn.www.media.mit.edu/context/cheese.htm
http://www.heise.de/newsticker/data/chk-10.09.01-000/

Re: Mozilla and On-line banking

[Ben Bucksch]

M. Schneier wrote:

>Why won't banks recognize the Mozilla 5 Browser for on-line Banking. I
>mention Mozilla 5 even though I'm using 6.1 because the page on which I
>have to set up my on-line banking for Netscape 6.1 mentioned that I have
>to upgrade my browser from Mozilla 5 to get 128 encryption.
>
Telling you to "upgrade" from Mozilla 5.0 is just silly.

If you bank refuses to accept Mozilla or Netscape 6 as browser, complain 
at your bank. It is not a fault of the browser - it works just fine for 
me (Deutsche Bank 24 in Germany).

Re: Better Popup Window Blocking has arrived

[Ben Bucksch]

Mitchell Stoltz wrote:

> Besides, maybe there's something that gets popped up on load or unload 
> that you do want to see. I doubt it. I'll build in the ability to 
> create an exception list for those cases should one arise.

FWIW, IIRC, there are some poorly written sites which desperately want a 
certain window size (all-Flash sites usually) and then open a new window 
with the wanted size onLoad on the homepage. Luckily, they are very rare.

> That's a good idea - a tray icon.

me too.

Re: Better Popup Window Blocking has arrived

[Ben Bucksch]

Mitchell Stoltz wrote:

> Please bear in mind that this is experimental, and it has some flaws: 
> If you hit the Stop button while a page is loading, then no calls to 
> window.open on that page will work.

Any plans to fix that?

> Please give this a try

OK, will do.

> and post feedback about how this feature could be improved.

An UI (pref checkbox) would be an improvement :-). (But I guess, it 
should first be non-experimental.)

> Thanks to Rob Ginda for contributing the original patch. 

Many thanks to both of you!

Re: Documentation of UIless cookie prefs?

[Ben Bucksch]

Jason Bassford wrote:

>>You can limit the lifetime of cookies. (The prefs are not yet listed in 
>>all.js.) See bug 53354.
>>
>
>   The only possibility I can see there are from your source code for
>a possible fix that was then rejected by morse.
>
>+user_pref("network.cookie.lifetimeLimit",0) 
>
>   But if the patch wasn't checked in I assumed that it wouldn't be
>functional.  Or was this part of your UI interface to the pref?
>
>   According to 53354 the backend, pref, side was already completed in
>bug 8530.  And reading that bug it says that it was verified and
>fixed.  But it doesn't say what the pref is.  Is it the above?
>
>  Jason.
>
yes

Re: Documentation of UIless cookie prefs?

[Ben Bucksch]

Mitchell Stoltz wrote:

>>> * Accept all other cookies but discard after two hours (or failing 
>>> that,
>>>  at the end of the session)
>>
>   Not currently possible.

You can limit the lifetime of cookies. (The prefs are not yet listed in 
all.js.) See bug 53354.

Re: hypertext linkage to file://...

[Ben Bucksch]

Mitchell Stoltz wrote:

> Any installed application imposes some constraints on directory 
> structure, and Mozilla is no exception. Maybe I don't like the fact 
> thet the Mozilla binary has to be in the same directory as its 
> associated files (like the chrome directory). Tough turkey - it won't 
> run otherwise. I don't see how salting is any different.

Exactly. After all, the user can specify, where the profile (incl. 
salting dir) should go.

> That said, in light of all the complaints, what I would like to do is 
> get rid of the salt directory and do the following: Assume that if a 
> profile name is something other than "default," then it's reasonably 
> unpredicatble and doesn't need salting.

Personally, I would prefer more unpredictability. My profile could be 
named "Ben", and if somebody starts an attack targetted at my 
personally, it would not be hard to guess.

I don't want to use Ben_abcd1234 as profile name, because that will 
appear in the ProfileSelector.

But we could skip the salting dir whenever the user explicitly specifies 
a profile dir. I would consider it "natural" that we don't use a salting 
dir in that case. The user has an intuitive way to avoid the salting 
dir, and we didn't even had to add any pref :).

This would also solve the problem: If I want to reuse an old profile, 
should I target the dir of the newly created one at the dir with the 
profile name "/Ben/" or at the salting dir 
"/Ben/a1b2c3d4" of the old profile?

Re: hypertext linkage to file://...

[Ben Bucksch]

Does the salting dir get added when the user specifies an explicit path 
during creation? It shouldn't. (We're just trying to prevent guessing of 
locations, which is easy, when the user accepts all defaults, but a 
user-specified path is hard to guess anyways.) If it does, file a bug.

Maybe you can also find a way to write the registry file directly or at 
least manipulate its entires. Don't ask me how, though.

Re: Window popup security broken with v0.9.3?

[Ben Bucksch]

Jason Bassford wrote:

>>user_pref("capability.policy.default.window.open", "noAccess");
>>user_pref("capability.policy.non_spammers.sites", "http://www.microsoft.com";);
>>user_pref("capability.policy.non_spammers.window.open", "allAccess");
>>user_pref("capability.policy.non_spammers.windowinternal.open", "allAccess");
>>
>
>   Your syntax is wrong. (This isn't helped by wrong documentation at
>Mozilla itself - I had to look through Newsgroup postings to find the
>correct whitelist syntax.)  It should have the following form - also
>pay attention to the fact that it is case sensitive:
>
>user_pref("capability.policy.allowpopups.Window.open", "sameOrigin");
>user_pref("capability.policy.allowpopups.sites",
>"http://www.somesite.com";);
>user_pref("capability.policy.default.Window.open", "noAccess");
>
The documentation 
 
is OK.

It also was in the 0.9.2 release notes:

*

  The syntax for blocking pop-up windows has changed since Mozilla
  0.9. To block pop-up windows, add this line to the prefs.js file
  in your Mozilla profile directory while Mozilla is not running:

user_pref("capability.policy.default.Window.open", "noAccess");

  If you want to allow specific sites to open new windows, add the
  line above and also these lines:

user_pref("capability.policy.allowpopups.sites", 
  "http://www.mozilla.org http://bugzilla.mozilla.org";);
user_pref("capability.policy.allowpopups.Window.open", "sameOrigin");

  See the Configurable Security Policy
  
  documentation for more information.


  0.1.

Re: Disable cookies - except for whitelist.

[Ben Bucksch]

Jason Bassford wrote:

>http://bugzilla.mozilla.org/show_bug.cgi?id=75915
>
>   The short answer is that, no, this is not possible at present. 
>(Although it's being worked on.)
>
There are workarounds, I'll add them to the bug.

Re: JavaScript security prefs

[Ben Bucksch]

Mitchell Stoltz wrote:

>> I believe that every day. But my goal is 0 exploits, not being better 
>> than Microsoft.
>
> A worthy goal, but we will never get there. No security is perfect.

I wouldn't be so quick with that.

OpenBSD managed to keep 3 years without a remote exploit in their base 
system. (Is it even longer now?) Given, that base system is small. But 
then again, this is a complete operating system with kernel, mail 
transport agent (IIRC) etc., and we are only one (complex) application. 
So, it is not at all clear, if reaching 0 remote exploits is possible or 
not for us.

Let's say, we disable JavaScript and Java. How many exploits did we have 
then? Mozilla is young, so let's add 4.x. I think, you can count these 
exploits on one hand. (I know that there recently was a buffer overflow 
somewhere in the 4.x HTML parser, IIRC.) Now, let's put 2-4 man-years 
into security reviews outside of scripting. With that, I think, we could 
make a few years without exploits outside Java[Script].

Now, either we can achieve the same (with a bit more work) with 
JavaScript, or it was a bad idea in the first place.

> IE and Outlook, being the market leaders, are a good basis for 
> comparison. 

Maybe for Netscape. But for me, and hopefully for Mozilla too, the goal 
is at least to be the best :) in the class.

> 41876 was about allowing remote XUL pages (loaded as content, not 
> chrome) to access certain types of content from the browser chrome, so 
> they can use skins.

That's what I meant. (I was a bit incorrect in my try to be brief.) This 
would be a candidate high on my list of functions to disable in a more 
secure mode.

Re: JavaScript security prefs

[Ben Bucksch]

Mitchell Stoltz wrote:

> Again, exploits can potentially involve any function or property 
> that's accessible to scripts on the Web. The ones which are really 
> dangerous are already blocked. Of the ones remaining, I don't think we 
> can say "these are dangerous" and "these are not." Most of the 
> functionality in the DOM/JS API accessible from scripts is equally 
> dangerous, which is to say, an exploit could appear anywhere.

OK, then my assumption that there are more and less secure (but 
accessible) functions is wrong. If an exploit is everywhere similarily 
likely to appear, it makes no sense to single out certain functions and 
disable them.

Re: JavaScript security prefs

[Ben Bucksch]

Mitchell Stoltz wrote:

> You could say the same for Java. JavaScript is not inherently 
> insecure; it's just a powerful language, and with power comes risk. 

Sure. But Java is hardly used on the web, so it is easy to have it 
always turned off. That's not true for JavaScript.

(Here, a zones prefs would come in handy, because Java might be used on 
some intranet sites.)

> Believe me, Microsoft takes the "functionality route" much more often 
> than Netscape.

I believe that every day. But my goal is 0 exploits, not being better 
than Microsoft.

> Remote chrome was not and is not secure enough for deployment - it may 
> be so eventually. This is generally understood at Netscape. We don't 
> ship fundamentally insecure technologies.

So, bug 41876 has been reverted?

> This is not to say we don't have exploits, just that we *do* in fact 
> place a pretty high emphasis on security, more so than M$ in my opinion.

And it brings you many customers.

> That said, yes, I would like to create a "high-privacy mode" that can 
> be enabled with a single checkbox.

I'm not talking about privacy (cookies etc.) here. I'm talking about 
security, about preventing exploits, cracking.

Re: pop-up ads and denial of service attacks

[Ben Bucksch]

Mitch wrote:

>What "implementation issues" are you concerned about? Anything specific?
>
I think he is concerned about the same thing I am: It is a fact that 
almost all security holes discovered in the last time (in both Mozilla 
and 4.x) need Javascript to work or often even are about bugs in the 
JavaScript/DOM implementation and their security policies. In other 
words, if you disable JavaScript, you are protected from most exploits.

Unfortunately, disabling JavaScript is not feasible in the current web 
(at least not for me).

I am sure that you know that there are often tradeoffs between 
functionality and security.
AOL/Netscape being a content provider often takes the functionality 
route. (Some people will remember the discussion about remote chrome and 
the arguments of some Netscape employees for enabling it.)
Some users care more about security and are willing to accept some 
functionality limitations for that.
It would be nice to compile a list of these dangerous functions and then 
implement pref(s) to disable them. Hopefully, this will protect people 
which disable these functions from some of the future exploits, or it 
will offer a quick workaround, if an exploit is found.

I agree that we should use a new thread for this discussion.

Re: pop-up ads and denial of service attacks

[Ben Bucksch]

Mitchell Stoltz wrote:

> What if you could turn the blocking on for the current site via the 
> context menu? Would that be convenient enough?

No. Also, as soon as I am on the site, it is too late to stop anything 
in the onload handler.

> I'm worried about making "disallow window.open except on user click" 
> the default, because I think even that might break a significant 
> number of legitimate uses. It could be a pref that applies to all 
> sites, though. 

Yes, I can understand that. One effect that's wanted here is that 
popup-ads are ignored, and Netscape probably has no interest in that. 
Also, I agree, it might break sites. It is an advanced protection 
offered to the user, something that Mozilla and Netscape 6 usually turn 
on on request only. (Beonex Communicator is a different matter.)

>>> someone could maintain a list of annoying sites which could be 
>>> automatically banned from creating popups.
>>
>> Doomed approach, just like the "child-protecting" site blocker apps.
>
> Doomed why?

Because blacklist are always incomplete up to a point were they offer 
neglectable protection, and whitelists are always so incomplete that 
they interfere substantially with normal usage. There are just too many 
domains out there. Some count that as advantage :).

Re: pop-up ads and denial of service attacks

[Ben Bucksch]

Mitchell Stoltz wrote:

> To me, the interesting question is this: We've got legitimate uses of 
> window.open(), such as the ones Ben described,

Well, personally, I don't count any of the listed uses as legitim :-).

> and we've got illegitimate uses, such as popup ads that border on DoS. 
> Do these two categories often coexist on the same site? It seems to me 
> that if only a small percentage of sites have both popup ads *and* 
> other more legitimate uses of window.open, then a simple "block 
> window.open from this site"/"block window open from all sites 
> except..." sort of option, like the cookie manager, will do just fine

No, because there are too many sites of both sorts. So, even if 
"legitimate" and illegitimate uses don't appear on the same site, this 
approach still won't work. No matter how I set the default, I will break 
on many sites. And I won't bother to alter the prefs (even with UI) for 
every third site.

The per-site prefs are good for some special sites which I use often. 
They are not good for random sites out on the net.

> someone could maintain a list of annoying sites which could be 
> automatically banned from creating popups.

Doomed approach, just like the "child-protecting" site blocker apps.

Re: pop-up ads and denial of service attacks

[Ben Bucksch]

TenThumbs wrote:

>I would go for a simple UI.
>
> Should websites be allowed to open new windows on your desktop?
>   ( ) Always
>   ( ) Never
>   ( ) Allow websites to display new information in the window they are
>   already using.
>
This does not work for me. Many sites assume that I am dumb and not able 
to do rightclick-OpenInNewWindow, but use javascript:window.open for 
"links" that show me additional information to the current page (without 
closing it). E.g. "Enlarge Screenshot" or "Explain this form field". 
These "links" still have to work (even for yet unknown sites), that's 
why the current backend prefs don't work for me. If you show them in the 
current window, you might break things (e.g. going away from the form 
that I'm just filling out.)

Re: pop-up ads and denial of service attacks

[Ben Bucksch]

Gervase Markham wrote:

>>Most current browsers, including Mozilla, allow a class of profitable denial of 
>service attacks.
>>
>The backend work is mostly in place for this sort of thing.
>
What *I* want is not possible, not even with backend prefs: Never open a 
new window unless I triggered it directly by e.g. a click. I.e. allow 
window.open when (effectively) called from oncommand or onclick or 
similar, but never from onload or onunload.

Re: Mozilla 0.9.2 Phoning home???

[Ben Bucksch]

[EMAIL PROTECTED] wrote:

>After installing, rebooting and starting Mozilla, Zone Alarm asks if I
>want Mozilla to use my computer as a server, to which I tell it "NO!"
>
I have lots of these comments about Beonex Communicator 0.6 (based on 
Mozilla 0.6). I guess it was PSM1.

I thought, this were fixed in PSM2 and it communicates in-process with 
Mozilla? Isn't it? Or iis there some other component that does this kind 
of stuff?

>I have a blank start
>page, so it shouldn't try to access before I tell it where to go. 
>
>I have been using Netscape 4.72 and it does not try to access the
>internet until I give it a url to go to. Checking Netstat reveals that
>Mozilla is opening TCP Local Address is desk:1027, and 1028, State is
>"Listening" with a Foreign Address of localhost:1028 and 1027, State is
>"Established".
>
>I REALLY like the new features on Mozilla such as the personal sidebar,
>and the Gecko build /20010628 engine is really fast! I'm just wondering
>what's going on with this accessing the internet thing. I don't feel
>very comfortable with it until I get some good answers. I understand
>that Netscape 6.0 is based on this Mozilla browser and Gecko engine too.
>
Don't you get the same "Alarm" for Netscape 6?

Re: Is the security model XBL uses wrong?

[Ben Bucksch]

Stuart Ballard wrote:

>This model also potentially
>*introduces* security holes. For example, currently a skin has to be
>trusted, because it can provide XBL that binds into chrome:// documents
>that are unrestricted.
>
That would indeed be a problem, because skins are assumed to be 
untrusted. E.g. the skin install dialog is different from the XPI dialog 
in that the former doesn't warn about risks.

Re: UK Government IE only website-Could Mozilla help? Security

[Ben Bucksch]

  Gervase Markham wrote:

>>If the site requires users to use certificates to authenticate to the
>>server, the standard for that is TLS/SSL.  Mozilla supports the client
>>certificate feature of the IETF standard Transport Layer Security
>>protocol, RFC 2246 section 7.4.6.  Netscape Communicator supports the
>>same feature of SSL 3.0, an earlier version of the same protocol.
>>
>
>I believe certificates are being used here to authenticate the user to the
>site, rather than the other way around.
>
Yes, that's exactly what "client certificates" are about, the feature 
John described.

Re: Someone fill me in on this port blacklisting stuff

[Ben Bucksch]

Doug Turner wrote:

> The basic deal is that some protocols should not be allowed to run on 
> some ports.  Without any checking someone could do all sorts of evil 
> things

What do you mean with "run"? Mozilla shouldn't accept any connections 
from outside. So, the "ports" can only refer to the server, the - I 
assume - potentially hostile side. But if I am hostile, I can let my 
server run on any port I want.

Or are you trying to protect third-party sites? E.g. I happend to visit 
hostile site A, which causes my browser to open a connection to victim 
site B?

Re: Someone fill me in on this port blacklisting stuff

[Ben Bucksch]

Jeffrey W. Baker wrote:

>Can anyone spill the beans on "port blacklisting"
>
The code, for those interested:


>The whiteboard on that bug has
>good stuff like "MUST HAVE. Security Hole."
>
How can avoiding a static list of ports fix a security hole?

Re: UK Government IE only website-Could Mozilla help? Security

[Ben Bucksch]

hm, that was a bit many typos, even for me :-(. Corrections and 
additions below.

Ben Bucksch wrote:

> If you have one, you can test it at SSL test sites. 

<http://www.mozilla.org/quality/security/smoketest.html>

>> The web site is apparently being built by Microsoft UK [...]
>
If it really is built by MS, a good reaction is to complain about that 
fact at your government. If the government partners with MS, of course 
MS will try to lock out everybody else.

Or, as Henri Sivonen suggests, go to the press. Making them aware of the 
MS problematic won't hurt :).

Re: UK Government IE only website-Could Mozilla help? Security

[Ben Bucksch]

Steve Ball wrote:

> The reason given for the total lack of support for Linux and Mozilla / 
> Netscape 6 is that they require a signed PKI security system that is 
> apparently only available for Windows. 

 From what I understand, they present pseudo-arguments.

You can autenticate clients using client certificates. It is implemented 
in Mozilla. If you have one, you can test it at SSL test sites.

> The web site is apparently being built by Microsoft UK, so I feel sure 
> that there will be little presure from them to support Mozilla or Linux.

If you are real thing to do it to complain about that fact at your 
goverment. If the government partners, of course MS will try to lock out 
everybody else.

Re: PSM stream converters question

[Ben Bucksch]

Garth Wallace wrote:

> WRT http://www.mozilla.org/mailnews/compose_send_plugin_arch_notes.html
>
> Would it be possible to use this architecture

There is no such architecture. It's just a bunch of quick notes about 
signed/encrpted mails.

If there was the architecture for plugins, this might be possible. I 
don't know, I don't know anon. remailers too well.

Re: Password Protected Profiles

[Ben Bucksch]

Jason Bassford wrote:

>1. Have no security in Netscape at all and "let the OS deal with it". 
>By that reasoning, abandon PSM altogether.
>
[...]

>argument in
>position 1. above - that it should be the responsibility of the OS. 
>But that's obviously false because, if that were valid reasoning, then
>PSM should be thrown out also - and that's not going to happen.
>
That's complete nonsense. PSM's primary function is SSL (https etc.) and 
S/MIME. Password encryption is only a minor function that were added 
only recently. (Does 4.x even have it?)

>So
>that blanket reply needs to be dropped and some more reasoning into
>the response needs to be applied.
>
See below.

>Anybody who
>knows how where the data is stored will be able to view it.
>
WHich is as easy as:
Windows: Start->[something]->Search->Text->"[EMAIL PROTECTED]"
Linux: grep "[EMAIL PROTECTED]" / -r
Don't tell me an ordinary user cannot search.

Re: Password Protected Profiles - VOTE HERE !!! You know you want this feature!

[Ben Bucksch]

Martijn Kluijtmans wrote:

> I just vote for it.
> Think of the following situation:
> In a family, every member wants to use Mozilla's, mail facilities
> - Father gets confidential information from clients
> - Daughter gets love letters by her friend
> - Mother 
> enz. 

Yes, we had this discussion already on .security a few months ago.

> And of course they don't want anybody to read their e-mail, so if 
> it's  not too much too implement, although maybe it's just for 
> Windows, please  add this funcionality.
> I don't expect 100% hack proof, but for normal use, a password would 
> be  enough.

Unix and WinNT give stronger protection already. Windows 95 and higher 
has a buit-in password protection (but not more - no dis access 
protection), and I think we honor that.
IIRC, if you activate it somewhere in networking, you can make Windows 
come up with a login during startup. The Windows preferences will be 
stored for each user separately, as will the "Documents" folder, where 
we will then store Mozilla's profiles, I think. I.e. if you have 2 
Windows users, one would not even see the Mozilla profiles (in the 
Profile Selecltor/Manager) of the other user.
Of course, you can still access the Mozilla files on disk, but that's 
not much different from Word files.

Please move the discussion to .security only. (Personally, I think 
.prefs is the right group, but it's too late.)

Re: Password Protected Profiles - VOTE HERE !!! You know you want this feature!

[Ben Bucksch]

Peter Lairo wrote:

> "User Profiles should be able to be protected with passwords."
>
> If you agree with the above statement, please vote for this BUG to be
> fixed here:
>
> http://bugzilla.mozilla.org/show_bug.cgi?id=16489 

Where do I vote for this bug getting WONTFIX? :-)