Interesting fishing attempt that fails with Mozilla mail
I just received an obvious fishing message that was directing me to https://signin.ebay.com. It looked really interesting, fishing using an https site rings a bell, but this was the real ebay login site (I had a doubt at first, was that the comeback of some i18n trick ?), so I really wondered what happened. Until I saw the source of the message : HREF="https://signin.ebay.com/ws/eBayISAPI.dll?SignIn&sid=verify&co_partnerId=2&siteid=0";>name="mlhcsf">href="http://61.145.119.80/bbs/templates/.../";>SRC="cid:part1.02030507.09050505@support_id_6906286@ebay.com" border="0" usemap="#mlhcsf">my name is Solar Eclipse Freeware in 1981 how much Mozilla mail goes to the URL in the A tag, but there must be some other software that goes to the url in the area tag, and maybe while displaying the A url. Or is that a trick to get through anti-fishing software ? ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Multitab vs. unique session id
RML wrote: Yes, IE gives me 2 session id's. That what I expected to get on a multi-tab browser too. Are you *sure* of that ? If you click twice on the blue e, you'll get two instances of the application, and then two different session id. But if you get a new windows of the same instance with CTRL-N, connecting from that windows should get you the same ID. Just tested that and that worries me even more... Got the same session-id too. Which means that an administrator uses the same session id as a regular user does. Doesn't sound too good. If you start FF as a different user on XP, you'll get separate instance and separate ids. If you talk about identifying differently on your site, you will not be ablt to do that with cookie based identification. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Some of the help on offer...
Gervase Markham wrote: I don't care if the petnames toolbar was proposed by your grandmother, the man in the moon or Bruce Schneier. It will be evaluated in exactly the same way. What's more I see no connexion with the page Ian referenced (Application and not only user level rights definition) and petname. Application level rights definition is certainly the way of the future, They certainly are not the only one to have figured that out, but there are still some very serious problems to solve to make it work in the real life. In fact outbound firewalls implements a tiny subset of it, and already show where the problem lies. It's about impossible that the product determines only by itself what rights any application should get. If you leave it like that, you break useful applications. If you implement a priviledge escalation mechanism, the clueless user will not be able to make the difference between a legitimate escalation request and a bad one. That tech won't work as long as you don't find a proper solution to this problem, and that's anything but an easy one. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Revoking the Root
Peter Gutmann wrote: [...] Among other things, it says that CA root certs aren't subject to any verification (apart from signature and validity, obviously). No, the standard doesn't include signature and validity period checking for the trust anchor. I realize everybody does the validity period checking, and probably most everybody does the signature checking for self-signed certificates used as trust anchors. But formally the Basic Path Validation algorithm doesn't include those. Still, you know that it's allowed to use the information inside the trust anchor certificate as additional input to restrict the path validation or initialize the constraints it uses. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Revoking the Root
Ian G wrote: So if one wanted to "follow the standard" one could create two keys, Alice and Bob, and have Alice sign Bob's PK. Bob then becomes the root and is used to sign all lower level public keys. Alice is the trust anchor. Then, store Alice and Bob together, and if they ever get compromised, have Alice sign Bob's revocation. Yes, if you apply the standard, there is no need to check the trust anchor for being a valid CA. Which helps to trust the old Verisign X509 V1 root CA that have no element at all inside that says they can be trusted as CA, no basic constraint, no key usage. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Revoking the Root
Julien Pierre wrote: I'm saying the standard defines no way to revoke a lost CA root, because it doesn't make sense. When a root is compromised, there is no PKI standard that can fix this. To be precise, the standard says that path validation begins with a trust anchor, and that the trust anchor is outside of the path validation algorithm. In fact the trust anchor does not have to be a certificate, only a public key and a DN are required. So you can use anything you choose as your trust anchor, for example a non-self signed certificate. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Improving Authentication on the Internet
Gervase Markham wrote: Er, given that we have no OCSP and no-one's checking CRLs, I think losing a root cert which is embedded in 99% of browsers out there would be an _extremely_ big deal. But OCSP/CRL can not help in case of *root* cert compromission. There's nothing above it to sign the validity information. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Allow/Disallow Java applets per site
Fabrizio Marana wrote: 1.0.4 is the proof I needed to escalate this again. [...] So again: per site java plug-ins/applets control would make FireFox more secure... There is *no* connexion between the very serious problems that were fixed in 1.0.4 and java/applet. Honestly I was tempted to stop my answer your message there. But let's try to be constructive. What you seem to want would be best be solved, with a more generic thinking, by a method to filter content to remove/inactivate unwanted elements per site. This is very near to what Adblock does. Per site CSS, or grease scripts is another way. But still there's no way to know where the attackers will shoot before they do, so you don't know *what* to filter in advance. And when they've done it, the correct solution is to fix the vulnerabilities, not to do filtering around it. Don't try to create security by using filters, because people will do errors when setting them up, so they will end up insecure. It works well for pop-up or advertissement, because it's very obvious when you fail, and you can correct from them, but not for actual security risks. What you're saying here is that java/applets are so dangerous we should remove them. They are not so dangerous, they were the source of only recent vulnerability. And also the same argument could be construed about any functionnality, they always bring some level of security risks. The good solution is not to remove, but to make safe. Or suppress fully if there's no way to make it safe. But you'd better show why exactly it can't be safe, and not rely on generic FUD. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Extensions as a security risk [Re: More Phishing scams, still no SSL being used...]
Anthony G. Atkielski wrote: I want an option in Firefox that unconditionally disables all installations of any extensions. It exist. As well at the switch option to not use any installed extension. If I need an extension for basic browsing, there's something wrong with the browser. You don't. But there clearly is a market for an extended version of Firefox, with a number of preloaded extension, that are garanteed to have received the same level of attention as the core components of the browser. It's an excellent thing the basic Firefox is so slim, it's a less good thing that it becomes less stable, secure, etc., as soon as you need to extend it beyond that. Altenate solution : An established list of "tier 1" essential extensions that you can trust fully for that level of attention. That's a point I'd like to develop, with no time up to now. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Extensions as a security risk [Re: More Phishing scams, still no SSL being used...]
Peter Gutmann wrote: [...]. The problem with ActiveX controls isn't (apart from one or two proof-of-concept ones) someone creating a malicious signed control (or FF plugin, or whatever). Really ? Why is there a product dedicated to avoiding them, then ? http://www.javacoolsoftware.com/spywareblaster.html [...] The problem is the bad guys exploiting holes in controls created by others. That's a really interesting point. Still a little search shows me more poc discussion about how to use it for denial of service than actual exploits than anything else : http://catless.ncl.ac.uk/Risks/18.61.html#subj4 This is not to say it's not a very, very serious problem, just that I haven't found yet the proof it does today more damages in real life than the first point. This is more a security issue, so I'm redirecting the discussion to the security group, this is the group where the discussion of "Won't badly written extension represent a major security threat for firefox ?" will be adequate. To exploit that you must first get the personn to have the specific bad extension installed, at least it can not be done silently on Firefox. I pointed out a few messages earlier it's a bad thing that there is no description nor name of the extension in the signature, this is just one reason more this is needed. For now, you just see when installing an extension the filename and the name of the server you download it from, they have *no* proved connexion with the real content of the extension. The base of this problem with ActiveX is that very often their purpose is to install extensions to the browser that can be scripted from unsigned content. Very few Firefox extensions install code that is similarly world-executable. One possible reason ActiveX often fall to that, it's because they are fully written in C, so it's very tempting to have the low-level functionnality in the ActiveX and seperately the script on the page. Firefox extensions include javascript code more easily than platform specific code, so most only consists of javascript (which also lowers the risk of buffer overflow problems and the like). The second reason for this failure is that you can not have signed scripts for IE. To implement a remote application that must do powerful things in Firefox, the correct solution is not to install an extension that then allows the remote application to do all that from unsigned script, but to use remote signed script instead. After an extension is installed, you need an extra effort before it's functionnalities are available to unsigned code. The jsLib extension for example enables a lot of dangerous things but only to other extensions. Of course, it's still easy for the average developper to fail and open dangerous vulnerabilities in his extension, but I believe quite a few of the work currently done for Firefox 1.1 is to close some avenues for errors here. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Improving Authentication on the Internet
Gervase Markham wrote: As an example (and I don't know of anyone who is actually suggesting this), what if we made all CAs who issued non-zero accountability certs post a $1,000,000 bond against losses from phishing attacks performed using their certs? Would you consider that a lockout measure? Did you hear about insurance fraud ? I think if you do something like that it will become a very big problem for those CA :-) I think commercial CA would hate such a thing even more than cacert, so I don't see it at a lockout. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Allow/Disallow Java applets per site
Jean-Marc Desperrier wrote: There's a common comment that it's a good thing that FF only has one security zone, which removes the risk of priveledge escalation attacks. I couldn't help thinking today that Firefox in fact indeed has two security zone, and that the recent problems are privilege escalation exploits. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Allow/Disallow Java applets per site
Daniel Veditz wrote: Absolutely not true, there is a version of the ByteVerify Java attack that affects Sun's JRE 1.4.2_05 and older -- and Firefox users can be infected. If you have this older JRE then it's most definitely NOT harmless. Dan, what do you refer to exactly ? I've seen some discussions like what you say in the "2005-02-14 - Summary of mozilla.org staff", but nowhere else. Secunia refers to Trojan.ByteVerify only as the trojan that exploits the MS03-011 vulnerability of the Microsoft JVM, no reference . SUN too describes this as a Microsoft only vulnerability : http://www.java.com/en/download/help/cache_virus.xml " 1. Trojan.ByteVerify [...] However, in this instance, storing these applets in the cache directory can not cause any harm to your computer because they are designed to exploit a vulnerability in the Microsoft VM, not the Sun JVM. " I've been checking the list of corrections in that release, but still don't see what you could refer to : http://java.sun.com/j2se/1.4.2/ReleaseNotes.html#142_06 There might be variants of trojan incorporating the ByteVerify attack, that also incorporate something else to attack the SUN JVM, but I stand by my word that the ByteVerify attack does not affects the SUN JVM. Are you referring to the Sandbox Security Bypass Vulnerability ??? : http://secunia.com/advisories/13271/ Firefox has many site-specific settings already (images, popups, xpinstall whitelisting, cookie blocking), I wouldn't say this is against anyone's philosophy. There are a lot of people wanting to control plugins/applets per site, there are probably some extensions that can do it already (there's the flash-specific "FlashBlock", for example). I referred not to per-site settings, but to per site security level. There's a common comment that it's a good thing that FF only has one security zone, which removes the risk of priveledge escalation attacks. When arguing with FF developpers that *properly* used signing for extensions would be better as a better security measure than xpinstall whitelisting, I was replied that xpinstall whitelisting is not intended to be a security measure strictly talking. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Allow/Disallow Java applets per site
Fabrizio Marana wrote: It's just that in the last week I've been infected twice with the Java/ByteVerify Trojan/virus... No, you have not been infected. You accessed a page that contained this IE only trojan, the trojan got stored in the disk cache, so your anti-virus complains, but this is harmless, because this trojan can't affect Firefox. If no one is working on it, where should I go to enrol and pick it up? (Or alternatively, submit it to a more senior developer, lowly worm that I am) Flush your cache if the warnings annoys you. The philosophy of Firefox is not to do per-site protection, but not to be sensible to such things at all. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: uri.schemeIs as blocker
Michael Krax wrote:
[...]
It seems this function gets used to implement blocker conditions in the
code, to prevent that a malicious uri (e.g. javascript) gets used in a piece
of code with chrome priviliges:
if (uri.schemeIs("javascript"))
return
The problem that i see is, that if ever an extension adds support for other
schemes (a vbscript or jscript extension isn't that theoretical) the blocker
condition is useless and a bunch of security errors appear since
vbscript/jscript can basicly do the same as javascript.
I'm not much more competent about that either, but maybe a bug entry to
request more defensive programming would be useful ?
I did a check and it seems all the code assumes the list of protocol is
closed. Even if it were not possible to add one with an extension, it is
possible one more gets added later. Reading that code, I wondered if
things like 'wyciwyg:' (what you cache is what you get) have been taken
into account everywhere.
___
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
Re: Two downbeat articles on browser security
Anthony G. Atkielski wrote: The article is essentially correct. From what I've seen, Firefox is only slightly more secure than MSIE, and much of that is due to the fact that it does not support ActiveX components. I've always taken for granted that the browser would not be truly secure, as that would require a rigor in coding and a preoccupation with security that clearly doesn't exist with Firefox. No, the article's argument is a strawman. It's asking for a perfect browser with no vulnerabilities, and finding that Firefox is not that browser, so it concludes it's no better than Internet Explorer. But nobody ever pretended there would be no vulnerabilities in Firefox. The real thing that upsat everybody about IE is that it went monthes with a list of more than two dozen publicly known, upatched vulnerabilties. And that is not the case with Firefox. I know only one vulnerability that had to go public before it was fixed (*), but then in a few days, and many were fixed within a few days of being reported. If you want to stay at the tip of the most secure release with a stable browser, you can use the nighlies of 1.0.x. Then the public release in which it was made sure the fix did not cause regressions are released fairly often (**). It don't believe Firefox has done so bad in the last monthes, except the javascript problem that was really serious, but still could be fixed rapidly. It has been under a level of scrutiny that it never encountered before and that revealed a number of problem comparable to the number found for IE in the same period, despite IE has been under that level of scrutiny for years and has had no significant functional evolution. It probably will be fun to see how many things they will get wrong if they implement tab in IE 7. It's not unlikely for Firefox that after that initial period in addition to be fixed rapidly the rate of new security issues will be lower. But the most interesting part of the article is the solution the author suggests. Use a HTTP/Virus filter (or more use the HTTP filter I'm selling). That's the fun part. How can he know what will have bad effect on Firefox before the security issues are found ? Oh, he can't, so he can implement the filtering only after they are revealed. And if so, there is no interest in using his solution WRT using the latest version of Firefox that also fixes thoses problems very short after they are revealed. Even if he manages to be faster, FF is fast enough that it's not significant. And it's much cleaner to fix the problem in the browser, whereas content filter is an added layer that can break and can easily have a lot of unwanted effets. Some security issues can not be solved by his filter (like the one in (**) below), so I need the latest version of FF anyway, therefore where is the interest of the solution he's selling ? Not even talking about the fact I prefer the free update to the paying solution. (*) OK, it's known there are other vulnerabilities hidden since very long inside bugzilla. But I think the reason for that is that those vulnerabilities are either quite minor, or something that would require a very clever solution to fix without breaking the web as we know it today. (**) This said the fix that went in official releases for the problem when saving .lnk files, Security Advisory 2005-21, that broke browsing the disk using shortcuts in the save dialog, was quite poor in terms of the security benefit/loss of functionnality ratio, but Doug T is working on a better trade off. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Two downbeat articles on browser security
Ian G wrote: http://www.ebcvg.com/articles.php?id=673 Mozilla: The Honeymoon is over Well, this time it's the analysis by the expert who's selling antivirus/http filters. Unfortunately, many will fail to his incredibly specious assessments about the recent vulnerabilities in Mozilla without realizing how little objectivity he can have in the case. "Some of the common Mozilla exploits ScanSafe is stopping" : How long should I laugh ? Can they even tell they were faster at beginning filtering them than mozilla.org was at implementing the fix ? ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Remote Controlling A C++ XPCOM Component In A Signed JavaScript Page In a HttpS WebSite
Vincent THOREL wrote:
I have written a XPCOM C++ Components.
[...] It work in signed JAR and
requested privilege("UniversalXPConnect") is accepted from remote host
because it is signed.
But the problem is, I want to use this component into a HTTPS page.
And when I run this page, i got in Javascript console:
Error: uncaught exception: [Exception... "Component returned failure code:
0x80570018
> [...]
Did someone have any idear of what happen?
This code extremly little used. You probably have found a bug in which
the permissions are not correctly transmitted for htpps pages.
Why it work in http?
Why my https Site work too?
And Why "Remote Controlling A C++ XPCOM Component In A Signed JavaScript
Page In a HttpS WebSite don't work"?
What do you mean by the https site works too ? Do you mean the fact it
works as long as you don't try to run signed javascript from it ?
There's an old bug that looks very similar, but the reporter never gave
enough information for reproduction, so it was closed :
https://bugzilla.mozilla.org/show_bug.cgi?id=90310
Can you test what happens with a simpler script that uses
UniversalXPConnect, but not your XPCOM component, like the one in this
message :
http://groups.google.fr/groups?selm=96f084a3.0308190144.5e6d2c19%40posting.google.com
If it fails, then it would be good to attache it to 90310, and reopen
the bug.
I'm redirecting the discussion to netscape.public.mozilla.crypto
___
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
Re: Low security SSL sites
Ram A M wrote: Anyone know of a non-small site that operates SSL2 using a server that can't do SSL3? That would probably mean it's using a web sever that has major security vulnerabilities. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Secunia Advisory - Firefox and Mozilla Suite JavaScript Engine Vulnerability
Allen Farley wrote: Here's the Javascript advisories for Firefox 0.x and 1.x: http://secunia.com/advisories/14820/ [...] There is a test on the for this on the link pages. bug 288688 : https://bugzilla.mozilla.org/show_bug.cgi?id=288688 Fixed in trunk, and will be included in the FF 1.0.3/Mz 1.7.7 releases. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Low security SSL sites
Doug Wright wrote: Gerv suggested I post this here for discussion - copied from bug 288693 When visiting 'secure' sites that use outdated encryption, Firefox/Thunderbird should give a big ugly warning about the dangers of submitting information to this site. [...] My personal preference would be a dialog with a delayed OK button (like XPInstall) to force people to read it. I'm surprised nobody has said until now that there's already such a warning dialog for 40 bit crypto (at least in the suite, maybe FF removed it). I don't believe 512 RSA keys trigger it, though. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: about bug 286107 : Remember visited SSL details and warn when changes, like SSH
No time to comment, but just note that I had set the follow-up to npm.security in my newsgroup message. Apparently the mail gateway can't handle that. I think it would be better to continue discussing it in .security and not .crypto. I unfortunately probably will have to leave the discussion, as I'm from tomorrow in holiday for two weeks with little/none internet access. Jean-Marc Desperrier wrote: I have some comments about this request, but I'm not sure inside the bug is the best place. Anyway the bug is about implementing some things that have been discussed here recently. This one? https://bugzilla.mozilla.org/show_bug.cgi?id=286107 I'm not convinced by the "let's add another warning" side of this bug. Especially when I see the reporter suggesting to put it inside a pop-up dialog. Dialog have proven until now they don't work, so why would this one by any different ? I reckon the best way to do it is the red bar display that HJ or Gervase has indicated. It sits just below the chrome and it isn't invasive. It works well for SSH, because you decide what machine you connect too, and you keep connecting to the same set of machines, so when that dialog pops up, it rings a bell. Also the population of SSH users is *not* *exactly* the general population. Now the problem about SSL is that in most cases, you don't choose where you do an ssl connection, when you want to buy something, it's the sellers who chooses the secure site, same for entering password, etc... For phishing, the user is being phished from a site that she has a relationship to. It is her bank account, or her eBay account. In this case, she does precisely choose where she wants to go! So it's very apropos. OTOH, there is a modus operandi of phishing where the user is encouraged to go to a totally new site. I'd be happy if just the major cases - own bank account - were addressed as a first step as I think that's where the majority of the losses are. So in that case, when the seller tells you "go to that site for the transaction", what use will be the warning ? Users will get used to seeing regularly that annoying warning, and to click through it or ignore it. Sure, that's why I like the red bar effect. Users don't need to do any work to ignore it. But it's right there. Sometimes they will click on a link expecting that link to lead to a site they trust because they know it well, and there it's important to have the message, but how does the browser know *when* that happens ? Because if it outputs this warning too often, people will stop reacting to it. And will the average user react appropriately ? : "Why the hell is Firefox telling me it's the first time I go to ebay.com, they really have a bug !" Average users are getting more and more aware of identity theft and phishing. All you need to say I suspect is that "this is an anti-phishing check, please make really sure this is what you wanted!" iang ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
about bug 286107 : Remember visited SSL details and warn when changes, like SSH
I have some comments about this request, but I'm not sure inside the bug is the best place. Anyway the bug is about implementing some things that have been discussed here recently. I'm not convinced by the "let's add another warning" side of this bug. Especially when I see the reporter suggesting to put it inside a pop-up dialog. Dialog have proven until now they don't work, so why would this one by any different ? It works well for SSH, because you decide what machine you connect too, and you keep connecting to the same set of machines, so when that dialog pops up, it rings a bell. Also the population of SSH users is *not* *exactly* the general population. Now the problem about SSL is that in most cases, you don't choose where you do an ssl connection, when you want to buy something, it's the sellers who chooses the secure site, same for entering password, etc... So in that case, when the seller tells you "go to that site for the transaction", what use will be the warning ? Users will get used to seeing regularly that annoying warning, and to click through it or ignore it. Sometimes they will click on a link expecting that link to lead to a site they trust because they know it well, and there it's important to have the message, but how does the browser know *when* that happens ? Because if it outputs this warning too often, people will stop reacting to it. And will the average user react appropriately ? : "Why the hell is Firefox telling me it's the first time I go to ebay.com, they really have a bug !" ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Strawman proposal for SSL UI changes
Frank Hecker wrote: That pretty much completes my night-time excursion into the wonderful world of Firefox security UI discussions. Feel free to flame away. A few days ago, I reached pretty similar ideas as a conclusion of the recent debatting, reinforced by remembering how valid the old SSL usability rant of Matthew Thomas was (http://mpt.phrasewise.com/2003/11/11), but had no time to describe it in a coherent and convincing way like you just did. Just a few things : - There's too many cases. Only experts are actually interested in why the site is not secure, just tell the general public that it's not, and you have to open the details windows to learn why. So below I will discuss several ways of restricting the options to a minimum. - I see two parts in this plan. One is introducting the "high-assurance"/"low-assurance" distinction, the older is removing all warning dialogs nobody reads least understand, and reflecting the insurance in the GUI. There's quite a lot that can be debatted about the "high-assurance"/"low-assurance" distinction. It might be good to implement first the second, and allow more time to think about what we want for the first. - "high-assurance" is something new, I'd see a new icon. I think the solution is an icon representing a vault, and not a lock for "high-assurance". I think it's a symbol everyone understand the meaning of without explanation, and it means you don't need to tell some CA you removed them the 'lock' list, just that they don't meet the criterium for the new 'vault' list. We just need a good vault icon that doesn't look like something else for anybody. That way, we can keep the lock for the normal SSL case, and not change it's meaning with today. - If we take apart the "high-assurance"/"low-assurance" distinction, I'd go even further than you. I think the binary option is tempting. It's secure, fully, or it's nothing, and the GUI doesn't show anything. In any case, we need to limit the case as much as possible, so alternatively what I'd see is : nothing/a discreet check mark/lock. The discreet check mark would be something usually people would not notice, it should fail "look for the lock" (http://www.gerv.net/security/stay-safe/), but it would keep people happy who would find it unfair that any error in the checking means there is nothing in the GUI showing the communication is any different from ordinary http. Cliking the "check mark" would show the detail windows. This said, I'd see a closed eye icon, rather than a check mark for this. - About the non-matching cert name, many people misconfigure servers, it's not definitively showing an attack attempt. That's why, and also in order to limit the number of possible case, I'd just remove the warning (warning are bad, the blocked popups warning is less bad but is still bad), and display the normal GUI as if there's no encryption in that case. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Error Code: -8075
Nelson Bolyard wrote: I'll bet the error message you get contains more than just that number. Does it contain much more than : "couldn't establish a secure connection to xxx error code -8075" ? (at least this message use the correct format for the error, it's better than 'error e00b' when it should be -8181 as in the dialog for crl errors) I'm a bit surprised about the extensions, but hotmail send to a https URL when you send the password for your account. Maybe those extensions are signed extensions and mozilla verifies the signature. Why not refer him directly to this ? : https://bugzilla.mozilla.org/show_bug.cgi?id=220275#c5 "See http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html#1038501 for explanation of -8075. This error code suggests that you configured your profile to do OCSP checking but the URL for the OCSP server was invalid. Does that explain it?" ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Status bar reliability
Gervase Markham wrote: Ka-Ping Yee wrote: Yup. Here it is now, done up with a spoofing example: http://zesty.ca/popup/ I've reported this as bug 284551. Thanks :-) There's no point in security restricting the bug if the exploit is public. Even if you get Yee to close his page, I think it's too late. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: [...] OK, that's good to know that there is no number involved. That just leaves us with determining what information *is* in this cert, and how it is that it needs to be presented to the user, and what the legal and contractual ramifications of all this information is. We should refer directly to the documentation about that : http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101862v010201p.pdf (also http://www.ietf.org/rfc/rfc3039.txt for more generic qualified certificate information) The fact that it might be easy to parse doesn't make it easy to present. How do you envisage presenting this information? [...] What are the contractual ramifications for the parties? What happens if it goes wrong? (And, I don't think the answer to the above is "nothing" as if it was, there would be no need for a law and no need for a critical bit.) In the case of the hungarian CA, I'm not sure "nothing" is such a bad answer. To be more precise, the qualified CA cert is just one step toward producing a qualified signature, which would be present only if all components were qualified. So as long as Mozilla is not qualified, it's not a qualified signature, and the use of a qualified CA changes very little. What would seem to me adequate to present this information would be a text saying "this certificates claims to be a qualified certicate" in the certificat details. Nothing more. (OK, my wording is wrong, as the certificate is not a living being and can't claim anything) Actually, for the monetary limit, I'd just add another text at the same place : "this certificate can be used as a qualified certificate for transactions restricted to a maximum value of _Amount_ _CurrencyCode_". You're not giving an acurate representation of things. [...] Let me repeat what I said: "It certainly opens a can of worms." That statement is as I see it, and I'd dearly love to be corrected on that. My "not acurate" was refering the following kind of statements you did : ">> What happens if IangInsidiousIssues sells >> certs with the crit in it saying $100,000 but >> inside the crit text, there is a caveat saying >> that the limit only applies if spent in my >> shop buying my goods?" "what is inside the extension packets is open, *by definition*, and they may or may not be marked with a critical bit." About the can of worms, the one opened by those extensions does not really makes the situation worse for X509 certificates. We've had the "Non Repudiation" usage bit for a long time, and nobody agrees on what it means exactly to assert it. If you concerns were fully justified, the current Mozilla could already be considered liable by not showing in a very visible way that this flag is asserted. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: New EU requirement to display monetary limits for SSL pages
Ian G wrote: [...] So the task for the Euro cert in question [...] [...] What planet are these guys on? What are we supposed to do, run it through a web translation engine? It certainly opens a can of worms. I asked around for any experience of these things, but got no answers on the cryptography group. Ian, I have not much time now, but the hungarian cert in question is *not* using the monetary limit extension, only the extension to say it is a qualified certificate, which consists just of an OID and is therefore easy to parse. Also the monetary extension is *not* as you say arbitrary text, it's a perfectly defined format, and even if there might text for the monetary unit, it is restricted to the value defined in an ANSI norm for the representation of currencies. You're not giving an acurate representation of things. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: - The text used to explain the feature isn't at all clear to average users. What is an "encrypted security key"? What does it mean if it's missing? The message bar doesn't say. +1 I thought it would be *really* obscure for the average user. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Domain spoofing (and a personal greeting)
Ka-Ping Yee wrote: I came to this list after hearing about the widely publicized IDN spoofing attack on Firefox. [...] So, what happened? Yee, what you see as a list is primarily a newsgroup 'netscape.public.mozilla.security' on which it's easy to get all the old messages, and it would be very useful that you read all those related to this problem. I'm sure you can bring useful new ideas, but your questions find many answers in those messages. Read also the messages about it on the "fake URLs 'r us.." thread on the netscape.public.mozilla.crypto group : http://groups-beta.google.com/group/netscape.public.mozilla.crypto/browse_thread/thread/78c70cd8db419d55/289e4b1606a657fb See also what Gervase Markham concluded from all that : "A Plan For Scams" http://weblogs.mozillazine.org/gerv/archives/007569.html "New Short-Term Patch For IDN-based Spoofing" http://weblogs.mozillazine.org/gerv/archives/007586.html The links Gervase refers too from that message are also useful. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: security alert from Pandasoftware
Chagi wrote: Madrid, February 10 2005 - According to Mikx, three security problems have been detected in version 1.0. of the Firefox browser. I think it's a good thing that more people begin to checks for bugs in Firefox, and the project needs more people like Mikx to find anything that has to be fixed. There's only one point I would criticize in Mikx's method, it's the fact he discloses the problems so fast after a fix has been found. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: security alert from Pandasoftware
Chagi wrote: They can be exploited by remote users to carry out diverse actions on systems, such as uploading malicious software The first case should be "exploited by remote users to push the user to put malicious software on his computer while thinking it is not executable content". All three bug are fixed in the Firefox nightlies that you can download from here (just wait until tomorrow to be insured to get the fix for the third one that was only very recently checked in): ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/ Those nightlies only include safe and important bug and security fixes that are intended to be included in a future 1.0.1 version of Firefox. They are a lot less likely to have a problem that bleeding edge nightlies, but they are not reviewed, and there's alway a possibility that a bug fix that should have been perfectly safe has unexpected side effects. The first of the problems lies in the fact that when the browser copies an image -via drag and drop-, on validating it against the HTTP "Content-Type" header, it uses a file extension from the URL. This could be exploited to situate a valid image, with an arbitrary file extension, and include script code on the desktop, tricking the user to drag and drop. Bad description. The problem is that drag and drop of valid images to the desktop is allowed, but that the original extension is keeped, even if it's not a dangerous extension. If you can arrange so that the image both is displayable and has an executable content, there's the catch. The second problem consists of the non-validation of headers, when a "javascript:" URL is dragged to another tab. This vulnerability could be used to execute HTML code and arbitrary script in the user's browser session in the context of any other site. Wait a minute ! Doesn't the fix for this in https://bugzilla.mozilla.org/show_bug.cgi?id=280056 forbid to drop bookmarkslets to the personnal bar ? It looks so, and it's a pain in the ass. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: TrustBar is too late, Amazon.com is for sale
Julien Pierre wrote: Ian G wrote: LOL... Amazon.com domain for sale :) I couldn't resist taking screenshots of how this hack looks in Mozilla under Solaris. That's certainly distinctive ! Add Microsoft to the *guilty* list. The reused the same glyph for cyrillic caracters as for latin one. The *same* glyph. I cut&past them to word and enlarge to size 72 points to try to see a visual difference, and there is none. The whole story would be significantly less annoying if they had not done that. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Optional SSL Client Authentication
Nebergall, Christopher a écrit : If Optional Client Authentication is specified should /does Mozilla prompt the user for th eir PIN to access the i r certificates? Yes, it will prompt. And if the user clicks cancel, it will just connect without authentification which you should be able to detect and redirect to the password prompt page. But didn't it take no more than a few minutes to test ? ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: 2005 - The Year of the Snail
Duane a écrit : [...] I've been shoving people onto ubuntu [...] It's the second time in a short interval I read a recommendation of Ubuntu as a "No worries, everything just works" linux distribution. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: SHA1 within a firebird extension
Ian Grigg wrote: Jean-Marc Desperrier wrote: He does not compute the SHA1/MD5, he returns the cert.sha1Fingerprint, cert.md5Fingerprint value from a nsIX509Cert object he gets back from nsISSLStatus status. Darn. One supposes that this is authoritive, in that NSS will also If you don't trust NSS to be able to compute a SHA1 correctly, you shouldn't use it to do SSL ... Mostly the point is that low level crypto is not available to js (most of the components involved are not scriptable), except through the installation of a specific extension (like Secclab that I believe is not compatible with recents Mozilla) [...] the next wave of browser malware may be in Firefox extensions that act in ways nefarious and evil. Hence, I pondered, the interest in code signing as an application for the PKI (in addition to email and browsing). [...]. There is a closed as rejected bug about requiring XPI to be signed in the browser. https://bugzilla.mozilla.org/show_bug.cgi?id=238960 (of course, Mozilla bug are not the right place to advocate for another decision) Or, (still musing here) if the Mozilla Foundation were to be the root signer. Or something similar like the FSF. That's what I defended in the last comment of that bug. The rational for rejecting the bug was that if signed ActiveX failed for IE, signed XPI would fail for Firefox/Mozilla. I tried to describe a list of measure to take to avoid that, mostly both have only one trusted signer and require the presence of an up to date CRL to allow extensions to install. I'm convinced this would work better than the current site white list mechanism. My opinion is that white-list forces to take a bad compromise between : - allowing a small number of list, which will result in major bandwidth problems for those sites, and difficulties if the number of extension creators gets large to make their extension available from those few sites. - augmenting the number of sites, and taking a large risk that one of them gets somehow subverted to download a bad extension. I even think there's an intermediate threshold where you get hit by the inconveniences of both side at the same time. I xpost this message to netscape.public.mozilla.security. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: how to switch between certificates
Arnaud wrote: [...] Once you picked a given client cert to be used for a site, you cannot change it, or rather, Mozilla does not ask you to choose which cert to use. This is a pure Mozilla crypto component, PSM, question, so redirecting to the right group. Is it a bug? Yes, it can be seen as such, the problem has already been raised on this group. Is there a preference to force Mozilla to ask EVERY TIME for which cert to use? There is none. If not, is there a way to programmatically (via JavaScript) to make Mozilla forget about the previous choice (the choice must be stored somewhere) ? The choice seems to be stored through the fact Mozilla reuses the same SSL connexion to connect to the server. The crypto engine Mozilla uses, NSS, makes it possible to change the client cert used, but the PSM does not use that possibility, and it doesn't seem possible to change that from javascript ... PS: In fact, even if the server forces renegociation of the session, Mozilla will reuse the same certificate without asking. Earlier version (around 1.0) did not do that and would reask the user everytime. This has been corrected later, but I don't know if it is now memorizing the client certificate at the NSS or PSM level. Finding and reading the patch that fixed that would certainly bring of lot of useful information about how it would be possible to forget the initial cert choice. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: GDI+ JPEG vuln. Win32 Moz affected?
Rui Covelo wrote: I think the question here is, does Mozilla and Mozilla based applications use this library for processing jpeg files or does it use it's own code? Neither. It uses libjpeg, which itself had some failures revealed, which leaded mozilla.org to release a corrected version a little time ago ... ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: More info on "You cannot connect to x.y.z because SSL is disabled"
$Bill wrote: This are the messages I get when tryin to go to a secure site : "You cannot connect to x.y.z because SSL is disabled" "Could not initialize the browser's security component. The most likely cause is problems with files in your browser's profile directory. [...]" There is over 100MB of free space on the profile directory drive. It's really nice of them not to tell you which file might be the culprit here. [...] I probably should have tried them one at a time, but maybe the next guy can figure it out. Inside your profile there is a file secmod.db. It points to an element inside the GRE part of mozilla, that is stored inside the "common File". That might be the culprit if none of the file inside the profile directory seems to be impacted. Open the secmod.db binary file, and serahc for the string "Builtin Roots Module", the path is just after that. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: fewer virus, etc. attacks with Mozilla ?
Michael Lefevre wrote: On 2004-06-11, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: As 1.4.1 is it's most recent version publicly available [snip] Actually it's not - 1.4.2 was released a few weeks ago, and binaries are available. Mozilla.org didn't make a big announcement because it's not a build that they're aiming at end-users. And Mozilla.org forgot to add it to http://www.mozilla.org/releases/ which is the list I consulted before saying it didn't exist. Could be added to http://www.mozilla.org/releases/cvstags.html too. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: fewer virus, etc. attacks with Mozilla ?
Rui Pedro Figueira Covelo wrote: But was mozilla built thinking on security more than "user friendlyness"? It seems to me that a big problem with microsoft products is the way they valor more user friendly interface, features and eye candy forgeting about security. How about mozilla? Is security a primary goal? I think the big problem with Microsoft products is giving users what they want intead of what they need. The products have been too fast providing a feature providing a feature or solving a problem in a way that would never inconvenience users, even if on the long term the problems in doing that begin to surface. Mozilla has it's own default, but has always been willing to stand on technically sound solutions, even if that meant a little inconvenience to users. One good example of that is that Mozilla never tries to guess to real content of data sent with a wrong header on the net. This does annoy some users who will not be able to get correctly displayed something that 'works' with IE, but the IE mecanism has also been on several occasion abused to get it to execute code (viruses) in something that should have been innocent content. This said Ben Bucksch has had a rant here some time ago on Mozilla security that is far from unmotivated. You should therefore remember that Mozilla is not completely devoid of security bugs, and that it is necessary to use at least the latests available stable build to avoid them. Older version are not necessarily updated. BTW I notice that whilst 1.4 is still the most recent long-lived version of Mozilla until 1.7 goes out, it is not listed as a product on http://www.mozilla.org. Isn't that a bit strange ? As 1.4.1 is it's most recent version publicly available and dates back to October 10, 2003, it probably isn't recommendable security-wise to use it. I see some security fix are still checked in the 1.4 branch, that seems mostly maintained for the OS/2 port (most recent is bug 243699), but there is no end-user binary available with them. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Mozilla targeted malware in the wild
Daniel Veditz wrote: Ben and I, in person. Actually the argument's pretty much over, there's not much point in doing the work if the default (which 99% don't change) is to work the same way as today. I don't know about FireFox GUI, but please, please, if you do it as white list, *don't* add another "manager". There really should a sigle "rights" manager in Mozilla instead of the current accumulation of various managers. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Mozilla targeted malware in the wild
Daniel Veditz wrote: (I'm serious, by the way: we're most likely turning off XPInstall by default for most sites for Firefox 1.0) It does make more sense to sign XP package. Site-level restriction is a problem for load repartition (isn't mozdev strongly overloaded ?), and make the consequence of a site hacking more dire. There's no justification for seeing it as more difficult than site level filtering. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Importing certificate
Robert Irving wrote: I am trying to import a ".cer" security certificate, but I keep getting asked for a password and then getting the error message: [...] So far as I know, there is no password for this, [...] I'll fully agree with that :-) Any help? First the correct group for certificate related discussion is netscape.public.mozilla.crypto, so I'll redirect the discussion there. Second, the interface you use is there to import your *own* certificat together with it's private key, the two being assembled inside a file in PKCS#12 format. That's why it requires a password to decipher the private key. The file you have is someone else's public certificate in X509 format, and no private key of course. So in certificate manager, you need to click on the "Other People's" tab, and do import from there. You'll see that the interface then tells you are opening "Certificate Files", and only the ".cer" files will be displayed. If the certificate you're trying to import is a CA certificate, you must do the import from the "Authorities" tab. ___ Mozilla-security mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-security
Re: Firebird/Thunderbird and PKCS#11
Gervase Markham wrote: Jean-Marc Desperrier wrote: I'm surprised this problem has no solution. Well most database solutions seems to be available only under the GPL, but a special agreement could probably be negotiated. But unless the "special agreement" was a relicensing under the MPL/GPL/NPL (or a BSD-like license) then it wouldn't satisfy our licensing requirements. "You have special permission to use it in Mozilla only" does not make the software Free. Maybe I'm stupid, but if BSD would be OK, so why not work with PostgreSQL ?
Re: Firebird/Thunderbird and PKCS#11
Julien Pierre wrote: [NSS DB access not multi-process safe] Solving this problem involves using a new database format. The NSS team researched the issue of licensing other database code that didn't suffer from the single-process limitation, but none was found that would satisfy all licensing requirements - NPL/GPL/MPL. The only satisfactory databases we found were commercial. Unfortunately we didn't have the resources to write a brand new database, hence the situation we have today. I'm surprised this problem has no solution. Well most database solutions seems to be available only under the GPL, but a special agreement could probably be negotiated. [...] Nobody seems to have given any thought to this major problem, which basically means you can't share your cert and key databases between Firebird and Thunderbird if they are running at the same time. But the best solution would probably be a separate process that will handle all the crypto/NSS requests for the running aplications. It seems clear this is the most workable solution. If needed, it could be done with a proxy without changing anything in the current interface. Was not the PSM intended to work that way initially ?
Re: How to configure OCSP?
> I need to test with a recent build, but while I have been since a long > time been able to successfully validate web site with OCSP, despite > often hitting bug 141256 (the lines Kai quoted when opening 141256 > were my analyse of this problem), I have never been able to validate > mail certificates with OCSP inside the Certificate Manager. > And the very same OCSP responder worked very well for web sites. Good job on the recent nightlies, I could make OCSP work with them for mail messages. Tested on Windows 2000 with 2002070310 There is still two problems : - The key for the received mail is shown broken, but when I ask for details it says me wrongly that I do not trust tha CA used. Only if I choose the view the certificat do I get the correct information that the certificate is revoqued. - In the certificate manager, the Certificate Viewer shows me the status of certificate correctly, but my log show me that each opening of this windows results in 3 OCSP requests for a valid certificate, and 4 for a revoquated certificate. This is a lot too much, in deployment, the OCSP responder will be overloaded very fast because of that. Only the Certificate Viewer has this problem, when opening the mail, only one request is made. I think that for mail, the OCSP request result can be keeped in cache locally, because if at the time the message was received, OCSP responder told it it was valid, any future revocation of the key does not impair the validity of the mail that was received before that. With the current setting of checking everytime the message is opened, OCSP for mail means a lot of load for the OCSP responder. This said it's an excellent release. I had 4 opened problems, that I had not yet taken time to report (the main reason being I could not give you the necessary data to reproduce, I needed to find a way to reproduce with non confidential data - freely accessible web site), and I can no more reproduce with the latest 1.1a nightly. They were : - SSL access on a specific site that requires user authentification - Verifying some signed mail from Outlook - Decifering some encrypted mail from Outlook - This OCSP with email problem
Re: CN component & SubjectAltName Extension of the
dhiva wrote: > I have a Cert with CN as host name and multiple host name listed on > SubjectAltName extension, but i am getting "Domain name mismatch warning" ? I'm sorry, but I've never heard of this way of using SubjectAltName for server certificates being normalized anywhere. Can you supply information, if this is the case ?
Re: How to configure OCSP?
Julien Pierre wrote: > No. There was a code-freeze for mozilla 1.1a, and the checkin of this > fix also had to be delayed until after the 1.1alpha was built. So you > need a recent nightly build to get this fix (last night would have it > for sure). If this still does not fix your problem, please add to the > bug. If your server is on the internet, it would be very useful to > provide a test URL. Julien, this might be a separate bug. I need to test with a recent build, but while I have been since a long time been able to successfully validate web site with OCSP, despite often hitting bug 141256 (the lines Kai quoted when opening 141256 were my analyse of this problem), I have never been able to validate mail certificates with OCSP inside the Certificate Manager. And the very same OCSP responder worked very well for web sites.
