Re: security novice :signed chrome? (revisited)
rvj wrote: My concern with Mozilla is the ability of almost any javascript hacker to replace some of the chrome files Replace chrome files how? Do you know of a way for an attacker to do this remotely? If so, please let me know, as we consider that very serious. If you're talking about an attacker sitting at the victim's keyboard, there's nothing we can do about that. Unlike modifying C++ components (operating system or otherwise) , javascript hacking requires VERY little experise to capture passwords etc. Again, that assumes the attacker has a way of replacing those files. If they have a way of replacing files, they could replace chrome or native components, or the whole OS for that matter. -Mitch
Re: Privileges affect cookie validity
I do believe you've found a bug. I'll take a look and try to fix it. Thanks! -Mitch Thomas Pelzer wrote: Hi, when I create a privilege for www.domain.com, i. e. UniversalPreferencesWrite, I get a prompt to grant the privilege. If I allow this without enabling the option remember this decision, the cookie behaviour will stay normal: sites in subdirectories can access cookies valid for that subdirectory. Otherwise (with enabled option remember this decision) two new lines will be added to my prefs.js: user_pref(capability.principal.codebase.p0.id, http://www.domain.com;); user_pref(capability.principal.codebase.p0.granted, UniversalPreferencesWrite); and the cookie behaviour will change: all sites in subdirectories have cookie-access as if they were in the root. They can no longer read cookies from their own directories, and if they create a new cookie, it will be valid for the root. There seems to be no way to read subdirectory-cookies. Any idea? Regards, Thomas
Re: security novice :signed chrome? (revisited)
What if your operating system files are compromised? There's no cryptographic verification there... You are correct that local security issues did and continue to take a backseat to remote exploits. We assume that if an attacker can change files locally (or is sitting at your keyboard) then there's nothing we can do. There has been no impetus for signature verification of local chrome files. However, if you can find some like-minded people who also want this feature, this would make a great Mozdev project. -Mitch rvj wrote: OK dumb question but is it potentially possible to have signed chrome which could be authenticated when Mozilla starts up? I know that signing is primary used for file transfer verfication but I am more interested in preventing tampering at the local workstation (i.e. tampering/ replacement of JAR files) Instead of having to sign individual scripts, objects, etc, I would like to sign a single chrome JAR file containing a collection of secure files . i.e. the signed chrome would be verified on startup using Mozilla certficate security methods. I asked this question a couple of years ago and there didnt seem to be too much concern for local security issues. i.e. a security loophole that results in mozilla's application files being compromised I was trying to find out if things have moved on?
Re: 401 Unauthorized not clearing cache
There's an open bug on that (don't know the number). I agree that it would be nice to have a logout buttin for HTTP auth. It's coming. -Mitch Khomar wrote: I am using windows authentication with .NET when I discovered a problem with the Mozilla browser. In IE and Netscape, if I return a 401 status code, the authentication cache is cleared forcing the user to re-enter their user name and password. However, with Mozilla, I cannot seem to clear the authentication cache without closing all of the opened Mozilla browser windows. Since all of the Mozilla windows use the same session and authentication cache, there is no way to reliably log a user out (after session timeout) and force a new login. Is there a way to clear the authentication cache for Mozilla, or is this a bug in the browser? I have not been able to find any answers after searching the Internet, so I thought I would try to post the problem here. Khomar
Re: 128-bit encryption not supported by Mozilla 1.3 ?
You might want to file a bug in the Evangelism product at bugzilla.mozilla.org - our evangelists can show the owners of that site the error of their ways. All they have to do is support the standards, instead of proprietary extensions. -Mitch KUROSAKA Teruhiko wrote: This is very convincing evidence that my installation of Mozilla 1.3 does support 128-bit encryption and they cannot deny it. I reported the problem to them. So I complain them and their answer was the familiar We don't support Mozilla period. What surprises me further is that they do support Netscape 4.x, but they don't Netscape 6 or 7. T. Kuro Kurosaka
Re: grant dialog to show up again?
Jens, Unfortunately, there's no user interface for doing that, but you can do it by editing your prefs file manually. Quit Mozilla (including the Fastload taskbar button), and edit the prefs.js file in your user profile directory. Delete all lines that start with capability.principal. Save, and restart Mozilla. -Mitch Jens Ansorg wrote: hi, on one site I clicked the remember this decision in the grant script privileges ... dialog. how can I undo this? where do I have to delete something to make mozilla forget about the desicion? thanks Jens
Re: Password Manager File
TGOS wrote: I was trustful that people actually think about such things like Does it make sense to offer third party apps easy access to the data without forcing them to use our libs. I didn't know that things like this are never considered right from the start. Who says it wasn't considered? There are a lot of things we could have done with Mozilla. We could have added a word processor, too, but we chose not to. If you feel that Mozilla is severely lacking becasue we chose not to provide an easy method for non-C-programmers to access a particular C-level API, while you're entitled to your opinion, you are probably in the minority. The bottom line is, if you want help with your project, you are going about it in exactly the wrong way. No one who works on Mozilla is under any obligation to answer your questions. We make an effort to answer questions when people are polite, but nobody pays us to do it. Calling Mozilla engineers names and refusing to post in the correct newsgroup are not good ways to receive assistance. A little courtesy goes a long way. -Mitch Stoltz
Re: Proposal: HTML tag to disable active content
Interesting idea. We'd have to think about whether there would be any way for the malicious cross-site scripter to get the value of the random key attribute. If they could do so, they could generate a valid closing tag and proceed with active content. It would be great to feellike there was something we could do about cross-site scripting on the browser end, however it's fundamentally a server configuration problem, and I think Ben's concerns are valid - a server-side library is a more robust solution which would cover all browsers, not just ours. -Mitch Ben Bucksch wrote: IIRC, the argument on the www-html list was to make server-side libs.
Re: signing a jsp file which contain javascript
Unfortunately, there's no way to do that right now. There was some discussion of allowing pages sent via HTTPS to be treated as signed pages, but this has not happened yet. In the meantime, you'll need to put the script that needs to be signed on its own static page (you could include it in your jsp page as a hidden iframe) and it could then interact with the jsp-generated page via javascript. -Mitch didier ernotte wrote: Hi, All the example I have read about the signtool and the syntax jar:http://server/archive.jar!/file.html deal with static HTML pages. How can I trust a JSP file called by a Servlet ? Thank's Didier
Re: disable security
The simplest and most drastic change would be to open up mozilla/caps/src/nsScriptSecurityManager, and make the CheckPropertyAccessImpl function a no-op that always returns true. That will essentially disable all security and create a browser that's totally unsafe to be used on the public Internet. Or, you could make a more specific change. Try adding these lines to defaults/pref/all.js: 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); Replace http://foo.com http://bar.com; with a space-separated list of the hosts to which your Mozilla-based tool needs to connect. Hope this helps, -Mitch hocus wrote: Hi! I need to tailor mozilla as a special-purpose tool. I want to disable security checks related to javascript and page source domain. I suppose it has something to do with principals, but so far I haven't succeeded in finding the correct place in source code to disable it. I would be very thankful if someone could tell me, what exactly I should change, to make possible using javascript on documents loaded into frames/iframes, originating from different domain than the base page. TIA Hocus
Re: Web application security w getstring
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. -Mitch 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: turn off pop-up dialog?
I don't know if it's possible to turn off that dialog, but here's something you can do: run a web server on the localhost (127.0.0.1) interface, and configure it to deliver a transparent 1x1 pixel image as its 404 not found page. Then image requests to sites on your blacklist will become invisible images instead of error messages. -Mitch xx wrote: I've added a bunch of onlines ads site names into my local hosts file and set them to 127.0.0.1, e.g. 127.0.0.1 ads.doubleclick.net etc and the whole black list from junkbuster. However, mozilla keeps on popping up this dialog saying the connection was refused by such and such (one of the sites on the black list), whenever a web site is trying to download the ads from the black listed site. Could anyone tell if it's possible to turn that pop-up dialog off? Or tell mozilla to ignore any site that refuse connection? I'm not using junkbuster, 'cause it's slow and is having a lot of problem with our firewall. Any hint would be appreciated. Thanks xx
Re: Security manager blocks basic functionality - is this intended?
Michael A. Borisov wrote:
Is this behaiour intentional? Will I be able to do this once signed
scripts are supported in Mozilla?
netscape.security.PrivilegeManager.enablePrivilege('UniversalFileRead');
window.win = window.open('file:///C:/dir/subdir/whatever.html');
Signed scripts are supported in Mozilla, and yes, you can do this with
signed scripts by enabling the UniversalBrowserRead privilege.
And where I can read about
netscape.security.PrivilegeManager.enablePrivilege() method in detail?
http://www.mozilla.org/projects/security/components/signed-scripts.html
and
http://www.mozilla.org/projects/security/components/signed-script-example.html
-Mitch
Re: switching protocals (presume it's a security feature)
Try adding this line to prefs.js, in your user profile directory, with Mozilla not running: user_pref(security.checkloaduri, false); Bear in mind, this might open up some security holes. -Mitch mb wrote: attempting to have javascript bounce a user from an HTTP requested web page to a specific file housed somewhere on their internal network (to a computer without a an HTTP server) If the intial page is HTTP://www.website.com/... and the .js trys to send them to file:file... NS browsers simply go blank. I presume this is to prevent malicious users from accessing a browsers file system but want confirmation. We're trying to open internal docs to the network via a web application / without forcing the documents into a Server Respository. If anyone can confirm or has ideas, please let me know thanks
Re: Can one view actual passwords stored in Password Manager (Netscape6.2.2)
No, there's no way to retreive stored passwords in cleartext, not through Mozilla anyway. Someone should write a little utility that decrypts the stored password file - anyone interested in doing that? -Mitch Jeff wrote: I'd be grateful for any help you could offer... A couple of years ago I registered with seti@home through the ATT Worldnet ISP. Now of course I'm with a new provider, and I can't remember the password. Since my old email account is dead, I can't request the password from the seti@home website. It is, however, stored in Password Manager (though seti@home doesn't make use of that info). Is there any way to retrieve what the actual password is? The encryption option is off for all the passwords, would a search for relevant text strings in the Netscape folders (Seti, berkeley, for exmpl) using START|FIND turn up anything? Not a major life crisis, I know, but I do have over a year of CPU time credited to the account, and I'd hate to start all over again unless I really needed to. Thanks in advance, Jeff
Re: window.opendialog security
rvj wrote: Havent looked at the CVS yet and it looks like a simpler approach than downloading 'remote package' definitions There is, to my knowledge, no such thing as a 'remote package. In fact, we specifically disabled remote chrome, and if it has been re-enabled, it was without my knowledge. Please be clear on this point: Pages get privileges based on where they come from, NOT what language they're written in. Anything loaded from the local chrome directory using a chrome: URL, whether XUL or HTML, is fully privileged. Anything loaded from the network, or from the local drive outside the chrome directory, whether XUL or HTML, is untrusted by default, but can gain privileges by being signed. Remotely loaded chrome has not been implemented yet. Frankly, it makes me very nervous and would require a lot of careful security review. It would also require signing or some other sort of cryptographic verification. -Mitch
Re: window.opendialog security
openDialog allows a nasty exploit, which is why it can't be called from content. You should be able to do whatever you need to do using open() instead. -Mitch rvj wrote: It seems that openDialog in a remote xul file is thrown out by the xul parser However if I just use window.open, the new window is created I noticed this when using the reload button on the remote xul. It generates XML Parsing Error: unclosed token Location: http://host/remote.xul Line Number 35, Column 1:/wi ^
Re: jar:http://www.site.com/myjar.jar!/signed.html does not work - how do I sign scripts
What version of Netscape are you running? 6.2 hangs on signed scripts; the problem was fixed in 6.2.1. -Mitch RL Clippard wrote: I assume that since Netscape 6 is not mostly Mozilla that it has adopted Mozilla's technique for signing scripts. In the doc Signed Scripts in Mozilla (http://www.mozilla.org/projects/security/components/signed-scripts.html), it says that the Netscape way (using ARCHIVE) will not work and that I should use jar:http://www.site.com/myjar.jar!/signed.html;. However when I try this approach, it just hangs resolving the host - no errors but no results either. However it works if I reference the local drive. What am I doing wrong?
Re: Java applets+proxy server security problem: what about Mozilla?
If you're using the latest JRE with Mozilla, then you're protected. AFAIK, Sun has fixed the issue. -Mitch Derek Lee wrote: Hi, I read about the security issue below involving Java applets: http://www.theregister.co.uk/content/55/24295.html What to do with Mozilla? I am using the Sun J2RE 1.4 plugin. -Derek
Re: Accessing files in Signed Jar over https fails
Lloyd, It's probably a bug; I'll look into it. -Mitch Lloyd Colling wrote: Hi all, I have made a test html page called test.html, in which the content is: htmlheadtitletest/title/headbodytest page/body/html This was then signed and jar'ed using the netscape signing tool: signtool -k testkey -Z test.jar ./ This jar was then put onto a webserver. This webserver supports both http and https (using mod_ssl, if you really want to know...). The browser being used for the test is Mozilla 0.9.8 release build. When accessing the jar using the form: jar:http://192.168.2.1/test.jar!/test.html The page loads fine and is displayed. However, when accessed using: jar:https://192.168.2.1/test.jar!/test.html The browser displays 'transferring data' in the status bar, and stays like that. The browser is still responsive, but the page never loads. Anyone with any ideas on what's going on here? Is this a bug? Thanks all, -- Lloyd Colling
NB: Change in configurable security policies
I'm about to make a change in the way configurable security policies are stored, and I wanted to let everyone know. The instructions at http://www.mozilla.org/projects/security/components/ConfigPolicy.html still apply, except for the following change: When you create one or more site-specific policies, you must add one additional line to prefs, that looks like this: user_pref(capability.policy.policynames, mypolicy); where mypolicy is the name of the policy you created. For example, if you want to stop all popup windows from appearing on yahoo.com, you might use these prefs: user_pref(capability.policy.annoyingsites.sites, http://www.yahoo.com;); user_pref(capability.policy.annoyingsites.Window.open, noAccess); As of tomorrow's build, you will have to add this line as well: user_pref(capability.policy.policynames, annoyingsites); As of tomorrow, site-specific policies *will not work* without adding this line. If you have more than one site-specific policy, add their names to the policynames line; do not add a second policynames line. For example, user_pref(capability.policy.policynames, annoyingsites, spamsites, othergroup); Use commas and/or spaces to separate the names. Also note that the default policy is unaffected and doesn't need to be listed on the policynames line. If you don't use site-specific policies you can ignore this message. I apologize in advance for the added hassle, but this change makes possible a major performance boost. This is bug 119646 if anyone's curious. I'm going to update the docs as well. -Mitch
Re: setting event.screenX/screenY ?
Any content loaded as chrome has no security restrictions at all, and
you shouldn't have to call enablePrivilege. XUL files which are not
loaded as chrome (installed in the browser chrome directory and accessed
with a chrome:// URL) are treated exactly the same as HTML files. If you
load a XUL file via the Open File dialog, that's the equivalent of using
the file: protocol, which requires enablePrivilege calls.
If you're still having trouble, please send me a complete, minimal
testcase that demonstrates the problem, and I'll try to diagnose it.
-Mitch
rvj wrote:
PS Ive tried using just the file references as you suggest
Ive opened the test xul file via Mozilla's open file option but even
though I get the Internet Security dialog box asking me to allow enhanced
priviliges and accept, setting the event's screenX or screenY property
still fails
Can you confirm that Mozilla should be able to set these javascript
attributes/properties as follows
function mousedowns(event)
{
netscape.security.PrivilegeManager.enablePrivilege(UniversalBrowserWrite);
alert(before+event.screenX)
event.screenX=event.screenX+1
alert(after+event.screenX)
}
Do not post SSL questions to this newsgroup, please
*please* post all questions regarding SSL, HTTPS, certificate management, and any other crypto or PKI issues to netscape.public.mozilla.crypto. This newsgroup is for non-crypto security issues. Thanks, Mitch Stoltz
Re: setting event.screenX/screenY ?
One of three conditions must be true in order to call enablePrivilege: 1. The script is signed 2. The script is local (loaded from the local drive with the file: protocol) 3. Codebase principals are enabled in the browser. THis is intended as a debugging feature only, not for end users. Please see http://www.mozilla.org/projects/security/components/signed-scripts.html which explains this in more detail. - Mitch rvj wrote: Does Mozilla support netscape.security.PrivilegeManager.enablePrivilege(UniversalBrowserWrite) or is it only available for signed scripts? In the example below Im trying to set the event screenX and screenY values to point to the center of the current window // enable security for universalbrowserwrite netscape.security.PrivilegeManager.enablePrivilege(UniversalBrowserWrite); // setting the event screenX/screenY values to center of window fails event.screenX=window.screenX+(window.outerWidth/2) event.screenY=window.screenY+(window.outerHeight/2) PS Where can I get a list of Mozilla security privileges options
Re: netscape.security.PrivilegeManager.enablePrivilege(UniversalXPConnect) in 096
Could you send me a testcase, along with actual and expected results? I need more information to know what's gone wrong. You can send it to me privately at [EMAIL PROTECTED] if you don't want to post it. -Mitch Thad Hoffman wrote: this is not working for me in build 096. (or 095 for that matter) Works in Netscape 6.1 and 6.2 and my old 091 build Just curious as to why it might have changed. I cannot connect to a different domain now. Same set up as before, only the client versions have changed. Running on OSX. Again, it works fine for the previous builds.
Re: netscape.security.PrivilegeManager.enablePrivilege(UniversalXPConnect) in 096
Thad Hoffman wrote: stupid question, when I try to edit the all.js file I get an alert that the file is checked into a source control system and asks if I want to modify the code readonly... Would this be affecting the above code and causing the no privilege error? I am using the build provided by the 0.9.6 milestone link No, that shouldn't affect anything. If you change modules/libpref/src/init/all.js, you need to make in that directory or manually copy all.js to bin/defaults/pref. -Mitch
Re: Handling pop-ups
We knew that was inevitable. You can block all pop-ups by adding this line to prefs: user_pref(capability.policy.default.Window.open, noAccess); However, this will block some legitimate (non-advertisement) pop-up windows. Eventually, we will add the ability to block Window.open() calls in response to mouseover and other event types, however this is more likely to block more legitimate uses of popup windows. -Mitch Andrew Mutch wrote: The ability to block pop-ups is a HUGE advancement in Mozilla. However, now people are reporting ads that occur from a mouseover a link that causes an ad to pop-up. Is there a way to block these from occuring without disabling Javascript completely? Andrew Mutch
Re: enable privilege not granted.
Ramya, You need to enable codebase principals or else sign your scripts. See http://www.mozilla.org/projects/security/components/signed-scripts.html for more information. -Mitch Ramya wrote: Hi, I am using Mozilla0.9. While trying to access XUL files from server (Apache Web Server) that uses XPCOM, I encounter a js file error enable privilege not granted how to over come this error and access XPCOM components. pls reply
Re: whoops, the diff was garbled
Christopher Blizzard wrote: Yes, please. In fact, I would just say shorten that to [EMAIL PROTECTED] instead of the overly-obscure [EMAIL PROTECTED] and just use [EMAIL PROTECTED] security means different things to different people. I was thinking that making the address of the list reflect its purpose rather specifically will lower the amount of noise on the list. security could be interpreted as security feature development, for example, or as physical security ([EMAIL PROTECTED] is supposed to be an engineering list, but it gets mail for campus security all the time). [EMAIL PROTECTED] is long, but why do you call it obscure? Seems pretty straightforward to me. If people don't think that calling it security-bug-reports will cut down on noise, or that brevity is more important, then we'll go with [EMAIL PROTECTED] What about the other list address, [EMAIL PROTECTED]? 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. 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 way we won't have people filing duplicate bugs from the same problem report. -Mitch
Re: Security Group Proposal, Draft 7
Please keep in mind that we are creating TWO mailing lists, one to receive security bug reports from outside and one for internal discussion. It sounds like people are saying they want [EMAIL PROTECTED] to be the address where people not on the security group can send security bug reports. Yes, this is one of the traditional addresses to use for this purpose, as several people have pointed out. However, no one has directly responded to my question: 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. My question is, is this a valid concern? If most of you think we should use [EMAIL PROTECTED], then I'm fine with that, but I'd like to hear opinions about this point. The second mailing list is for discussion among security group members. Having a very specific name is not so impotant in this case, and short is good, but if we're going to use [EMAIL PROTECTED] for the bug reports address, we'll have to pick another for the group discussion address. -Mitch Mike Shaver wrote: Brendan Eich wrote: I must now channel jwz's ghost and object to lack of hyphens and cybercrud grp in the last. If short wins, why not [EMAIL PROTECTED]? Otherwise, -group it. [EMAIL PROTECTED] is the traditional notification address, I think. Mike
Security Group Proposal, Draft 7
In addition to the changes Frank requested, I've rewritten the section about a 'known vulnerabilities' page on mozilla.org to clarify what it's about, and I changed the section about mailing lists. As I discussed with staff, we should have separate lists for discussion and outside bug reports. Please give me your comments on these changes. Bear in mind they were made by me alone and are just a proposal - they are open to debate. Also, please outline what issues still need to be discussed. Mozilla staff (and I) would like to finalize this policy by this Friday, 10/12. This draft includes a link to a Known Vulnerabilities page. Is it in a good location? I plan to link to it from projects/security/index.html and projects/security/components/index.html. Do you like the names of the mailing lists, [EMAIL PROTECTED] and [EMAIL PROTECTED]? Should we use shorter names? I wanted to make it very clear what each one is for. -Mitch Title: Handling Mozilla Security Bugs Handling Mozilla Security Bugs Version 1.0 DRAFT 7 October 8, 2001 Introduction In order to improve the Mozilla project's approach to resolving Mozilla security vulnerabilities, mozilla.org is creating more formal arrangements for handling Mozilla security-related bugs. First, mozilla.org is appointing a security module owner charged with primary responsibility for coordinating the investigation and resolution of reported Mozilla security vulnerabilities; the security module owner will have one or more peers to assist in this task. At the same time mozilla.org is also creating a larger "Mozilla security bug group" by which Mozilla contributors and others can participate in addressing security vulnerabilities in Mozilla. This document describes how this new organizational structure will work, and how security-related Mozilla bug reports will be handled. Note that the focus of this new structure is restricted solely to addressing actual security vulnerabilities arising from problems in Mozilla code. This work is separate from the work of developers adding new security features (cryptographically-based or otherwise) to Mozilla, although obviously many of the same people will be involved in both sets of activities. Note also that the scheme described in this document will completely replace the traditional practice of marking security-related Mozilla bugs as "Netscape Confidential." The mozilla.org Bugzilla system is being modified to remove the ability to mark bugs as "Netscape Confidential," and to instead implement the scheme described below. Background Security vulnerabilities are different from other bugs, because their consequences are potentially so severe: users' private information (including financial information) could be exposed, users' data could be destroyed, and users' systems could be used as platforms for attacks on other systems. Thus people have strong feelings about how security-related bugs are handled, and in particular about the degree to which information about such bugs is publicly disclosed. The Mozilla project is a public software development project, and thus we have an inherent bias towards openness. In particular, we understand and acknowledge the concerns of those who believe that all information about security vulnerabilities should be publicly disclosed as soon as it is known, so that users may take immediate steps to protect themselves and so that problems can get the maximum amount of developer attention and be fixed as soon as possible. At the same time the Mozilla project receives substantial contributions of code and developer time from organizations that use (or plan to use) Mozilla code in their own product offerings. Some of these products may be used by large populations of end users, many of whom may not often upgrade or check for recent security fixes. We understand and acknowledge the concerns of those who believe that too-hasty disclosure of exploit details can provide a short-term advantage to potential attackers, who can exploit a problem before most end users become aware of its existence. We believe that both sets of concerns are valid, and that both are worth addressing as best we can. We have attempted to create a compromise scheme for how the Mozilla project will handle reports of security vulnerabilities. We believe that it is a compromise that can be justified to those on both sides of the question regarding disclosure. General policies mozilla.org has adopted the following general policies for handling bug reports related to security vulnerabilities: Security bug reports will be treated as special and handled differently than "normal" bugs. In particular, the mozilla.org Bugzilla system will allow bug reports related to security vulnerabilities to be marked as "Security-Sensitive," and will have special access control features specifically for use with such bug reports. However a security bug can revert back to being a normal bug (by having the
whoops, the diff was garbled
Left the file extension off the diff file, which garbled it. So, I'm sending it again. -Mitch *** security-bugs-draft6.html Mon Oct 8 20:00:15 2001 --- security-bugs-draft7.html Mon Oct 8 20:26:16 2001 *** *** 1,6 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; - html head --- 1,5 *** *** 20,27 div class=version Version 1.0br ! DRAFT 6br ! September 30, 2001 /div --- 19,26 div class=version Version 1.0br ! DRAFT 7br ! October 8, 2001 /div *** *** 194,205 have visibility into all Bugzilla data hosted through mozilla.org.)/p ! pThe Mozilla security bug group will have a private mailing list to which everyone in the security bug group will be subscribed. This ! list will act as the well-known address to which users can submit ! new security bugs, as well as a forum for discussing group policy ! and the addition of new members, as described below./p ! h3Other participants/h3 --- 193,209 have visibility into all Bugzilla data hosted through mozilla.org.)/p ! pThe Mozilla security bug group will have a private mailing list, ! [EMAIL PROTECTED], 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./p h3Other participants/h3 *** *** 316,336 complete bug report)./li /ul ! pWhen 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./p pThe original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; --- 320,354 complete bug report)./li /ul ! pWhen a bug is put into the security bug group, the group members, bug reporter, and others associated with the bug ! will decide by consensus, either through comments on the bug ! or the group mailing list, whether an immediate warning ! to users is appropriate and how it should be worded. The goals ! of this warning are:/p ! ! ul ! lito inform Mozilla users and testers of potential security ! risks in the versions they are using, and what can be done to ! mitigate those risks, and/li ! ! lito establish, for each bug, the amount of information a ! distributor can reveal immediately (before a fix is available) ! without putting other distributors and their customers at risk./li ! /ul ! ! pA typical warning will mention the application or module ! affected, the affected versions, and a workaround (e.g. disabling ! JavaScript). 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 ! a href=http://www.mozilla.org/projects/security/KnownVulnerabilities.html; ! Known Vulnerabilities/a page. ! Mozilla distributors who wish to inform ! their users of the existence of a vulnerability may repost any ! information from the Known Vulnerabilities page ! to their own websites, mailing lists, release notes, etc., but ! should not disclose any additional information about the bug./p pThe original reporter of a security bug has the primary responsibility for deciding when that bug will be made public; *** *** 370,376 /ul pIf 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./p --- 388,394 /ul pIf disputes arise about whether or when to disclose information ! about a security bug,
Re: DOM access to disable saved passwords
I don't think it's a standard, but Netscape 6 and IE 6 both support it, to my knowledge. -Mitch dh wrote: This does seem to work, but is it a W3C standard? I've never seen this attribute before. Thanks Henrik Gemal wrote: You mean in forms? form autocomplete=off dh wrote: Is there a method for javascript to disable the saving of passwords for my site? If so, what is it? Thanks [EMAIL PROTECTED] -- Henrik Gemal, [EMAIL PROTECTED] Webmail Evangelist Opasia http://card.gemal.dk
Re: New proposal for handling security bugs
Mitchell Stoltz wrote: 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. Sorry, I meant to say the security bug group mailing list, not the security newsgroup. Ben, to reiterate, instead of shooting down our proposal point by point, how about giving us your own proposal? -Mitch
Re: security regarding of javascripting through xpconnect
Glad you asked... Chris Shen wrote: 1. a back-channel notification from javascript to the customised browser app which implements some kind of the callback (notification) service interface. I'm sure this is possible with XPConnect; don't know the details though. 2. no privilege popup dialog occurs. -- this may be done by pref conf. 3. the javascript only has certain permittable scripting into the customised xpcom callback service without requiring signing the scripts rather than access a range of xpcom services with signing. These are both currently possible, and without the need for any additional plugins or other security mechanisms. You can set prefs to make any XPCOM class accessible from unsigned JS with no confirmation dialog. The only requirement is that the class you want to give access to must implement nsIClassInfo. See http://lxr.mozilla.org/seamonkey/source/xpcom/doc/nsIClassInfo-overview.html for info on ClassInfo and http://www.mozilla.org/projects/security/components/configPolicy.html for how to configure the prefs. Please email me if you have any questions. -Mitch
Re: !somebody hacking my PC,HELP
Don't panic. Someone's probably just browsing your network shares. Cable modems are like Ethernets - anyone on the same circuit can see all trafic bound for others' machines. You might want to disable file sharing. You might also want to invest in some personal firewall software - there are several good packages to choose from. Just because you see your drive light blinking doesn't mean someone is attacking your computer - their computer could just be scanning the local network for active shares. -Mitch [EMAIL PROTECTED] wrote: My PC connect to internet through cable modem, this few days, something strange happened, my PC running Win2000, harddisk always read and write, I had share some directory, and when I disconnect the sharing, error message 1 files opened by . How should I know any attack and trace the illegal attack, like any file log to show the attack? any protection can recommend. thanks in advance please email [EMAIL PROTECTED]
Re: Better Popup Window Blocking has arrived
[EMAIL PROTECTED] wrote: Can you also start a timer to clear this condition? Or maybe clear it when the stop button is pressed? -Mike Not currently, but those are good ideas, so I think I'll use them. -Mitch
Re: Blocking a specific popup window
I think this is a bug. Try putting these lines in all.js (and use pref instead of user_pref. all.js is in the Mozilla application directory under defaults/pref. -Mitch Andreas Premstaller wrote: Found this problem on a german discussion forum: I try to block popup windows and warnings from this specific site http://www.burschenschaft-michelsberg.de; by using these lines in my prefs.js according to http://www.mozilla.org/projects/security/components/configPolicy.html;. ... user_pref(capability.policy.strict.Window.alert, noAccess); user_pref(capability.policy.strict.Window.confirm, noAccess); user_pref(capability.policy.strict.Window.open, noAccess); user_pref(capability.policy.strict.Window.prompt, noAccess); user_pref(capability.policy.strict.sites, http://www.burschenschaft-michelsberg.de/;); ... Yet both alert and popup-window come up. Am I doing something wrong, is this a bug or is the site using some smart workaround around the blocking? Thanks, Andreas
Re: Project Cheese - Mouse movements on website tracked
Ben Bucksch wrote: Really? How? As I see it, http://www.mozilla.org/projects/security/components/configPolicy.html describes only, how to disable JavaScript functions, not the triggers, i.e. HTML attributes. That's what bug 64737 is about, not? Correct - we can't disable JS by event just yet. -Mitch
Web content filtering - can we use this idea?
Privacy enthusiasts, take a look at 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). Could we incorporate any of this guy's ideas into Mozilla? Please look through his list of filters and let me know of any you'd particularly like to see implemented in Mozilla. Should we use a mechanism like his? I think we can do him one better by tying into the HTML parser and the security manager - for example, his regexps can remove onUnload handlers, but we can allow them to run while preventing them from opening windows. Thoughts? -Mitch
Re: NS6.1/Linux Security Manager stops/crashes browser
Reposting to .crypto, followup there. Just a hint, don't wait for the next release without finding out if a bug is going to be fixed. Be proactive - search at bugzilla.mozilla.org and see when the bug is scheduled to be fixed. -Mitch Iztok Kobal wrote: I installed NS6.0 as root, lately upgraded to 6.1 on Suse6.4 (2.2.14). When I try to access Security Manager as other user than root, NS6.1 (as well as 6.0 did) stops execution - only killing processes helps to get rid of stallen browser. As root it works well. I waited for 6.1 - thought that this matter would be corrected. Is this intentionally made on Linux, namely on WIN32 there is no such restriction ?!
Re: Better Popup Window Blocking has arrived
Giuseppe Verde wrote: Also, are there any plans to add something along the lines of NoAction (pretend that the function call worked so that the script thinks all is OK and doesn't get aborted, as happens with NoAccess)? Yes, I plan to add that. Although if we make window.open be a no-op, the script is likely to fail later when the object it's holding turns out not to be a valid window. -Mitch
Re: Better Popup Window Blocking has arrived
Jason Bassford wrote: I know you said that this patch may *sometimes* 1% give an unwanted popup. Is there any chance that it could also sometimes prevent a popup that you do want? Of course. This isn't perfect. Like I said, if you hit Stop during a load, the blocker bit may not be cleared, and no calls to window.open, wanted or unwanted, will work on that page until it is reloaded. 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. In all of these security type fixes (popups and cookies) I can see how it might sometimes be useful to get some kind of status or indication that somethings being prevented so that you can troublshoot cases like this. However, doing so in a non-intrusive manner is something else. (It would have to be a tray icon or something similiar that flashes briefly when the blocking is in effect, that would also let you click on it to get a log of recent activity.) That's a good idea - a tray icon. Best solution to that problem I've heard yet. The log of recent activity could be the JS console, which actually gives some status messages which don't pertain to JS. Let's do something like this - it could also handle the security error messages from CheckLoadURI and others for which people have complained that they can't tell when something's been blocked. -Mitch
Re: Security manager blocks basic functionality - is this intended?
Yes, this is intentional. A script from the web can't window.open a local file. This allows a number of exploits, generally involving running a javascript file in a well-known location on your local filesystem, or attempting to open a special device file which causes crashes and potential data loss. We're working on applying this restriction to images too, but we haven't yet. Will I be able to do this once signed scripts are supported in Mozilla? Signed scripts are supported in Mozilla, and have been for over a year (there's a bug in Netscape 6.1 that breaks signed scripts, but they're working on the Mozilla trunk right now and will be working in the next milestone release). See http://www.mozilla.org/projects/security/components/signed-scripts.html for instructions. -Mitch
Re: eternal life of signed objects?
Bernd Schmitt wrote: Thanks for your fast reply. I understand what you are saying, but i ask again because i don't know the security mechanisms thoroughly: does this mean, that my applet in the configuration stated below will work, even after the certificate has expired? yes or no will be sufficient 8-) thanks in advance Bernd Mitchell Stoltz wrote: I don't know about 'eternally,' but the signature itself never expires, even after the certificate used to generate the signature has expired. -Mitch Does this mean that i can put a signed and 'jar'ed applet on a cd-rom and it works in ie5 and ns4.x/mozilla *with* Sun's Java Plugin 1.3 eternally? Any contribution greatly appreciated. bernd
Re: NS_ERROR_DOM_PROP_ACCESS_DENIED received for no apparent reason in NS6.x
You shouldn't be seeing acces denied errors if both pages and the frameset are all on the same server. If the frameset is on a different server, you will get errors, but I'm planning to change this (see bug 52920). If everything's on the same server and you're still being denied, this is another bug but I can't diagnose it without a minimal testcase. -Mitch Heikki Toivonen wrote: A minimal testcase would help in analyzing the problem. In any case, n.p.m.security is probably a better place to discuss this, Cc Followup-To set. Todd Berry wrote: Accessing a form in a frame(which worked fine in NS 4.x) gives me the error access denied. The javascript is the following parent.parent.frames[left].frames[tree].document.forms[0] It doesn't matter how I reference the frame tree- I can use top. instead of parent.- same error. This doesn't occurr in every instance, so I'd like to know why I get this at all. All of the frames are on my domain, so I'm not references a different url(which is one reason it appears you can receive this error.) The error under 6.01 is NS_ERROR_DOM_PROP_ACCESS_DENIED (1010). In NS 6.1 it's simply uncaught exception: Permission denied to access property. This is occurring on Win2000 with NS 6.01 and NS 6.1. PLEAE HELP before we chunk NS 6 support. Thanks
Re: eternal life of signed objects?
I don't know about 'eternally,' but the signature itself never expires, even after the certificate used to generate the signature has expired. -Mitch Does this mean that i can put a signed and 'jar'ed applet on a cd-rom and it works in ie5 and ns4.x/mozilla *with* Sun's Java Plugin 1.3 eternally? Any contribution greatly appreciated. bernd
Re: Documentation of UIless cookie prefs?
Jason Bassford wrote: Are the UIless cookie prefs documented anywhere? I don't know of any documentation on this. The cookies themselves (including expiration times) are stored in cookies.txt, and the blocking information is in cookperm.txt, both in your profile directory. The formats of those files are pretty easy to comprehend in a text editor. Note that cookie prefs are NOT stored in prefs.js, or all.js, like JavaScript/DOM security prefs are. I'd like to do the following: * Enable persistent cookies for bugzilla.mozilla.org Not currently possible, that I know of. * Disable cookies from servers on a list Edit cookperm.txt * Accept all other cookies but discard after two hours (or failing that, at the end of the session) Not currently possible. If you figure the above out, let me know. I would also like to implement this. Jason, I would love it if you could implement this. File a bug and submit a patch, if you're interested. -Mitch
Re: hypertext linkage to file://...
This *is* a configurable setting. Open your prefs.js file in a text editor with Mozilla not running and add user_pref(security.checkloaduri, false); Chris Hoess wrote: In article [EMAIL PROTECTED], George Herson wrote: Thanks for the answer. Pls consider making this a configurable setting because i don't like being so dependent on Amaya (a browser which does allow file:// over a network). Given the resolution of similar security vs. convenience issues (salting profile directories, for instance), this seems unlikely. Why does everyone hate the salting so much? -Mitch
Microsoft and security
Russ Cooper, whose job title at the TruSecure Corporation is surgeon general and who speaks on computer safety issues, said customers should start demanding more secure software from Microsoft. But Scott D. Culp, security program manager for Microsoft's security response center, said that such criticism was unfair. Security is an issue that everyone in the industry is grappling with, he said. There isn't any vendor who is immune from security issues. At the same time, he said, We recognize at Microsoft that we do have a special responsibility because of the number of customers we're fortunate enough to have, and so we're doing our best to live up to that responsibility by designing systems that will make security updates more automatic.
Re: Interacting with MS-Proxy Server
Reposting to .netlib, follow-up there. [EMAIL PROTECTED] wrote: Looks like MS has found a way to prevent Mozilla from being used in a shop that is using the MS-proxy server. I had been using Mozilla after the proxy had been installed but then one day, the proxy login started to fail. It turned out that the proxy managers activated an additional field asking for a DOMAIN in addition to the ID and PASSWORD fields that were used to gain access to the proxy. In the proxy login window generated by mozilla, only the ID and PASSWORD appear. Is there a work-around for this? Is there any plan to allow Mozilla to interact with a proxy server which is asking for a DOMAIN?
Re: allow chrome URLs to be added to the sidebar
Seems reasonable to me. Could you file a bug and put this patch in the bug?
-Mitch
Martin Kutschker wrote:
Hi!
In
http://lxr.mozilla.org/mozilla/source/xpfe/components/sidebar/src/nsSidebar.
js there is the follwing check:
function sidebarURLSecurityCheck(url)
{
if (url.search(/(^http:|^ftp:|^https:)/) == -1)
throw Script attempted to add sidebar panel from illegal source;
}
Could we change it to this check?
function sidebarURLSecurityCheck(url, win)
{
var re = new RegExp((^chrome://[^/]+/content/),);
var res = re.exec(window.location.href);
// url is part of the same package as script source
if (res url.substring(0, res[1].length) == res[1])
return;
if (url.search(/(^http:|^ftp:|^https:)/) == -1)
throw Script attempted to add sidebar panel from illegal source;
}
It would allow a package to add itself to the sidebar. I anyone trusts a
package, she will probably trust it also in the sidebar.
Masi
Re: Refreshing RDF loaded from remote location
Well said. I think our security grant dialog is less complex and scary than the one in Netscape 4.x, but it could still have that effect on users. Ideally, we wouldn't have to ask the user at all, the browser would just make its own decision about the safety of the operation, but that's a difficult if not impossible proposition. -Mitch HOWEVER - i was trying to avoid having to prompt the user for as long as possible (i.e. here I thought that if the RDF comes from the same location as the XUL it is allowed). My experience with users is that they will happily download any program off the Internet and install/run it, without any regards for security or understanding that this program can do whatever it pleases - yet when I offer a completely secure, digitally signed XUL/JS-based-app-from-a-website, with no privileges (file access, etc) whatsoever, that needs to pop up a warning screen (for example to make an outgoing TCP/IP connection) the user panics, probably uninstalls Mozilla and all related components, scans for virusses, and blames the worm that infested their Word documents months ago on that dangerous remote Mozilla thing. :-)
Re: How to do this under Netscape 6?
What does Corba have to do with it? I didn't mention Corba. You can do everything you want to do with JavaScript and XPConnect. Yes, java should be able to solve the problem, but there are some bugs preventing signed applets from talking to Javascript. Basically, we haven't figured out how to get Java and JS to share security information, and frankly, it's not high on our priority list. Yes, Netscape supports Java, but it is no longer a core technology for us. My apologies - I don't determine Netscape's policy on this. I would like to see LiveConnect fully functional as well, but I don't know when that will happen. -Mitch Mark A Gregory wrote: I'm staggered to find you are saying the only solution under Netscape is to create an object that uses Corba? Surely this is not the way forward. Java must be able to solve the problem, or why is Java around? Is there an aliance between Sun and Netscape for NS6.01 or is this just marketing hype? What should be a simple task is turning into a nightmare. Mark
Re: How to do this under Netscape 6?
Unfortunately, you can't yet do this with Java in Netscape 6. I think you can run a signed applet, but signed applets can't communicate with JavaScript yet. An alternative is to write a signed JavaScript that uses XPConnect to access the local file system. Basically, you can create an nsIFile object in JavaScript and use that to read from a file. http://www.mozilla.org/scriptable/index.html gives some information about XPConnect. In order to use XPConnect, you have to sign your script and loading it using a URL of the jsr:http:// syntax. There's details on this in http://www.mozilla.org/projects/security/components/jssec.html. That document's a little out of date and has some errors, my apologies for that but I haven't had time to update it. Also, I don't think signed scripts work in NS6.01 for the Mac (Windows and Linux/Unix should work fine). If you want to give XPConnect a try, let me know if you run into any problems. -Mitch Mark A Gregory wrote: Hi, I would like to be able to read six characters from a file on a client computer using Netscape 6 and return the string to a javascript for processing client side in an ASP page. Please tell me how to do this, thank you mark
Re: Selectively *enabling* popup windows
Brandon, This is a known bug resulting from the Preferences API change that broke the capability.polciy mechanism. It will be fixed within a day or two. -Mitch Brandon Hume - BORG Redirect wrote: Mitchell Stoltz [EMAIL PROTECTED] wrote: user_pref(capability.policy.default.windowinternal.open,noAccess); This stuff USED to work for me, and it was beautiful. I even expanded upon it with the following: user_pref(capability.policy.default.windowinternal.open, noAccess); user_pref(capability.policy.default.windowinternal.moveTo, noAccess); user_pref(capability.policy.default.windowinternal.resizeTo, noAccess); and suddenly the web became tolerable once more. Now this stuff seems to have broken. I put these rules in place because of http://www.cvs.org/ (warning: extremely irritating site, though not in the denial-of-service type way) and I use that site as a test. I've noticed that recently JavaScript capabilities in the latest nightlies on Solaris aren't protecting me anymore. Did I miss a change, or has something broken?
Re: Selectively *enabling* popup windows
Brett, Sorry for the lack of documentation. Try this: user_pref(capability.policy.default.windowinternal.open,noAccess); user_pref(capability.policy.canpopup.sites,http://www.netscape.com http://www.etcetera.com;); user_pref(capability.policy.canpopup.windowinternal.open,allAccess); Obviously, replace the list of sites on line 2 with whatever list you want. Let me know if this works for you. -Mitch Brett Granger wrote: Sean Harding wrote: On Wed Apr 25 at 01:52:14 AM, David Hallowell wrote: There's instructions in the Release notes for 0.8@ http://www.mozilla.org/releases/mozilla0.8/ (at the end of the Whats new in this release section That only shows how to turn it *off* for specific sites while leaving it on by default. Turning it off by default while turning it on for specific site is what he was looking for, I think. sean Right... I've already successfully disabled all pop-ups by following the 0.8 release notes. Now i just need to figure out how to turn them on for certain sites. Anyone seen that done? Just thought I'd post here before I tried personal emails to Mitchell or Akkana... --Brett
Re: I need your advice on security checks
Ben Bucksch wrote: Mitchell Stoltz wrote: Open In New Window Are we still missing that one? I'm pretty sure I added a check for that. Might be that I misremember that. As components are added, this check will get missed, it's inevitable. Can we at least make sure that appropriate hints are added to the relevant APIs (e.g. in Necko?), so new programmers are less likely to miss that? Care to suggest what the hint should look like, and where it should go? -Mitch
Re: Netsape's signtool and HASH FAILED messages
Forwarding to .crypto
news.wirehub.nl wrote:
Hi all,
I am using a thawte developer certificate in pkcs12 format, which was
imported into netscape, to build signed .jar files. To do this, I use
Netscape's SignTool v1.3.
I have produced a signed .jar file from a directory, using the command
"SIGNTOOL -d ... -k ... -Z c:\x.jar c:\x". This worked fine. Using
SIGNTOOL -v c:\x.jar returns the following result:
archive "c:\x.jar" has passed crypto verification.
status path
---
HASH FAILED Documents/ADRES.DOC
HASH FAILED Java/Sources/nl/ois/common/oissplash.jpg
verified Java/Sources/nl/ois/osv/Application.class
It seems that only .html, .class and .jpg files work. On other files, which
we need to include like the splashscreen picture, signtool returns the HASH
FAILED error.
Any ideas?
Thanks in advance,
Remco Joosse.
Re: Password management
The wallet data is not stored in key3.db or cert7.db, those files just
store certificate information. I don't know the exact file those are
stored in, but maybe Steve Morse can shed some light on this. I've cc'd
him. The password file is not encrypted by default, but it is encrypted
if the user chooses "Encrypt Sensitive Info" from the Password Manager
menu. The data is then encrypted with a password supplied by the user.
It should be difficult for anyone to decrypt this information, even with
access to the Mozilla source code. In fact, the strongest encryption
schemes are those which have been open source for some time. To get at a
user's passwords, an attacker would need 1) access to the user's
password file, and 2) the user's master encryption password. Without
both of these things, there's no way to read those passwords.
-Mitch
I found that mozilla-the-browser has a password manager (called wallet ?),
which stores user's passwords. I'm just wondering where (in which file) the
passwords being saved, and how they being encrypted before saved in a file.
I found that there are key3.db and cert7db in ~/.mozilla. Are these files
where the passwords being stored ? If so, by reading the mozilla source
(such as those in mozilla/security/{nss|psm}), is it possible to decipher
(if this is the correct word) passwords of anyone else stored in those files
?
Since Mozilla is an open source, so that everyone can have the source and
see how the password is encrypted, I'm afraid that everyone can decrypt any
password of anyone else.
To tell the truth, we are planning to use Mozilla as a browser for our
product (a PDA). So, we are concerned if anyone is able to read our
customer's passwords stored in key3.db / cert7.db (if I'm correct).
Please point me some documents (if any) explaining of how mozilla manage
key3.db and cert7.db, and how the passwords being managed.
Thank you in advance.
Regards,
Bagus
Re: XUL Cross Domain Security FAQ
Henri Sivonen wrote: In article [EMAIL PROTECTED], Mitchell Stoltz [EMAIL PROTECTED] wrote: Once again, "XUL scripts" are no more trusted than HTML scripts unless they are cryptographically signed, or unless they are installed locally in the chrome directory. What extra priviliges do signed scripts get? Signing doesn't imply the script won't do bad things. Someone always calls me out on that one. I meant "signed and granted trust by the user." I was just too lazy to type that out. -Mitch
Re: non-local scripts in chrome
You could make a case for this, but as things stand right now, locally installed chrome can do anything native code can do. You wouldn't want to write an application in C++ that downloads and runs code from a non-local site, and you wouldn't want to write chrome that does this either. But that's up to the author of the chrome. Chrome is like a native executable - the user should trust it completely if they're going to download and install it. This isn't a bug, it's a design decision. We can't protect users from badly written chrome any more than from badly written native code. -Mitch Alex Fritze wrote: Hi, if I include some non-locally stored js into a chrome file, script src="http://www.myserver.com/script.js" / then the script gets full chrome privileges. Is this a bug? Shouldn't the script be restricted depending on where it came from? Thanks alex
Re: XUL Cross Domain Security FAQ
I'll try and answer your questions.
rvj wrote:
Would it be possible to have a page on Mozilla listing XUL cross domain
security FAQs
I have compiled a list of questions based on bug and newsgroup responses-
but I'm not entirely sure if the answers I've got back are consistant or
correct.
The premise of my FAQ is a XUL file containing two iframe windows, one of
which contains a document from a different domain.
iframe id="frame1" src="www.abc.com/file1.htm /
iframe id="frame2" src="about:blank" /
Any clarification/correction welcome.
METHODS
Q1. Using a XUL script, is it always possible to read the content tree of
any document from any domain without restriction?
A1. Yes (?)
There's a fundamental misunderstanding here. The security manager
doesn't care whether the source in question is XUL or HTML or Chinese or
any other language. What's important is where it's coming from. Scripts
running in XUL pages that are served from the Web have (in theory)
exactly the same security restrictions as HTML. When you say 'XUL
scripts,' do you mean XUL served from a Web server or XUL installed in
the chrome directory of the Mozilla distribution of the user's machine?
Content in the chrome directory, whether HTML or XUL or whatever, has
full privilege and should be able to access the content tree of any
document regardless of the document's origin.
Malicious sites can use XUL too. There's no reason why we should trust
some Web content more than others simply because of the language it's
written in. If you're talking about locally installed chrome XUL and
scripts, call it 'chrome,' not 'XUL.'
Q2. Using a XUL script, should it be possible to use the focus method to
direct keyboard events to a particular iframee.g.
window.frames[0].setfocus() ?
A2. Currently not because of cross domain security but will be changed see
69028
This is a *BUG* not a deliberate policy. It will be fixed after the DOM
implementation is changed to use XPConnect, in the late Mozilla 0.9 or
early 0.9.1 timeframe. Yes, a script should be able to set focus on any
window or frame regardless of origin. window.close() and several other
properties are also affected by this bug.
Q3. Using a XUL script, should it be possible to scroll the contents of a
particular iframe e.g. window.frames[0].scrollBy(0,30) or return the
document X and Y page offsets e. window.frames[0].pageYOffset ? (does XUL
support these methods and properties)
A3. Currently not because of cross domain security but will be reviewed. ?
I'll have to give this one a look but it seems reasonable to me.
Q4. Will XUL support the print method e.g window.frames[0].print() ?
A4 Currently not because of cross domain security
Ditto. A Web script, XUL or otherwise, should not be able to print
anything without the user's consent.
Q5. Will XUL eventually support silent printing via javascript of iframe
content ? Presumably a XUL script is trusted enough to do this (unlike an
HTM script) similar to the print button in IE
var contentViewerFile =
window.frames[0].docShell.contentViewer.QueryInterface(Components.interfaces
..nsIContentViewerFile);
contentViewerFile.Print(true, null, null);
A5. Unknown
Once again, "XUL scripts" are no more trusted than HTML scripts unless
they are cryptographically signed, or unless they are installed locally
in the chrome directory. Your code snippet above uses XPConnect, and a
script must be trusted to use XPConnect, again either by being signed
and asking the user's permission, or by being locally installed.
Q6 If you copy or merge iframe content from one or more cross domain iframe
sources, should all cross domain security be removed from the target iframe?
(is the security domain of iframe2 the same as the XUL file). Currently, the
content of iframe2 seems secured.
var sid = document.getElementById("frame1");
var tid = document.getElementById("frame2");
// copy sid
var copyOfNode = sid.cloneNode(true);
// replace tid with the copy of sid
tid.parentNode.replaceChild( copyOfNode, tid );
A6 Unclear
Looks like iframe2 starts as about:blank, and everyone is supposed to be
allowed to access about:blank. This is an issue I hadn't thought much
about. If a script does a document.write() to a frame, the owner of the
script assumes ownership of the written-to frame as well, for the
purposes of security. Should the same thing happen if we copy content
into a frame the way yo do above? Otherwise, a malicious script could
snoop on the content that was copied into that frame.
EVENTS
Q7. Will XUL support the creation of keyboard events such as page down/ page
up? i.e. can the CreateEvent and Event() method can be used to emulate such
keyboard events
A7. Unknown
You should probably ask this question on n.p.m.dom.
Q8. If true, then is it correct to assume it should be possible for XUL
script
Re: turning javascript on/off 15 times a day: don't bury it in preferences
Well, that one in particular has been stalled because it's a bit controversial, not for lack of expertise. But your point is well taken. -Mitch John Gardiner Myers wrote: Mitchell Stoltz wrote: Mr. Thumbs, on what evidence do you base your claim that "Mozilla currently treats security as a low priority item?" Take bug 28327 for example. It's a major privacy problem, but gets no attention from anyone with the expertise to code a fix.
Re: Security announce group
Making people aware that vulnerabilities exist and how to protect themselves is a good thing. However, I won't be able to participate in such a newsgroup, and if Mozilla security problems are going to be disclosed rapidly, this will seriously limit my and probably Netscape's ability to participate in Mozilla security discussions. Basically, the publishing of vulnerabilities will have to come from Netscape's PR department, not from me or any other security engineers. I make a distinction, as you apparently do, between technical discussion of security bugs between engineers from different organizations, and public disclosure of these bugs. I am much more interested in the former. Along those lines, I am opposed to any hard and fast deadlines on the public disclosure of any security bug information (such as requiring disclosure of a vulnerability within five days). Such a requirement is unnecessary, since the reporter of a bug has the option of taking it public at any time. -Mitch Ben Bucksch wrote: Even if we don't fully disclose bugs, it is very important to have notifications about them. - Views are mine, not Netscape's
