|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2003-0564: mozilla S/MIME overflow | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Sebastian Krahmer <krahmer> |
| Component: | Incidents | Assignee: | Wolfgang Rosenauer <stark> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Critical | ||
| Priority: | P3 - Medium | CC: | aj, hhetter, hmuelle, kukuk, meissner, mls, rf, ro, security-team, stark |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | CVE-2003-0564: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) | ||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 47963 | ||
|
Description
Sebastian Krahmer
2003-12-27 17:53:40 UTC
<!-- SBZ_reproduce --> I will ask them to send me these "testcases" It would be interesting in which mozilla versions this bug was discovered. Because this is a very vague information I will wait for more input for now. any news? From vendor-sec: Date: Mon, 19 Jan 2004 11:25:25 +0000 (GMT) From: Mark J Cox <mjc@redhat.com> To: vendor-sec@lst.de Cc: blizzard@redhat.com, Cameron <Cameronr@niscc.gov.uk> Subject: [vendor-sec] Mozilla S/MIME vulnerabilities Looks like the Mozilla folks have done some updates to fix security issues in S/MIME parsing; now semi-public: http://groups.google.com/groups?q=niscc&hl=en&lr=&ie=UTF-8&oe=utf-8&scoring=d&se lm=bu22ub%24d861%40ripley.netscape.com&rnum=2 http://groups.google.com/groups?q=niscc&hl=en&lr=&ie=UTF-8&oe=utf-8&scoring=d&se lm=mailman.1072205941.26375.mozilla-reviewers%40mozilla.org&rnum=3 I'd probably class these issues as critical since a carefully crafted S/MIME message can cause Mozilla to crash and, I'd bet, run arbitrary code. I don't have CVE names for these issues; Cameron did you get any for this? .... I asked for fixes and their testprogram, but I fear mozilla will only fix this in their newest version. they promised to maintain the 1.4 tree, which is at least used on SLES SP3 and for newest SLEC updates. So we can still hope. At vendor-sec we have been told that theres little chance to have it fixed in 1.4. * Is it possible that we can update to the newest version (1.6 ?). * If not, we might can hope and wait for RH to backport the fixes but the chance is little. We got some new message from vendor-sec telling that it seems they have backported some patches. However I do not know whether it applies to 1.4. Have you asked whether it is possible to update to 1.6? I think it would safe us a lot of headache. I don't think that project managers will do it and I can understand it. Mozilla.org stated that 1.4 is a stable branch and will be maintained. This should really include security-fixes. Update to 1.6 will break almost all APIs and need more packages to be updated. At least for SLEC. We just did an update to 1.4.1 on SLEC because we can hopefully make updates to 1.4.2 and so on without breaking too much. From my point of view an update to 1.6 or newer is no option. But you are specialist for security. If it has enough impact and is not solvable without updating to a newer "unmaintained" version you should discuss this with corresponding project managers. As your a talking about a version update on a maintained product - especially SLEC i put the project manager into CC. I would also say - a version update is a NO GO! We have to fix the problem anotherway! OK, here is some more information. The problem has been fixed in 1.4 branch and is included now. Mozilla 1.4.2 is not released yet but the branch had its version bumped to 1.4.2. There are some minor changes too in the tree and the "fix" was an update of the internal NSS (network security services) code in Mozilla. Now the project-managers have to decide what to do. This affects SLES and SLEC, so adding rf to the CC list. A reminder note for all: The 1.4 branch is a maintained tree from mozilla.org. Only critical fixes and no API changes go in here usually. Any decision yet what to do? Chris, would you please make a decision for SLEC what we should do here? I see no risk to update to 1.4.2. (We still could name it 1.4.1 ;-) Holger, do you expect problems with depending packages on SLEC? After several request for an decision by the maintainer and no reaction of any prjmgr nor the security-team it set the bug to critical. My suggestion upgrade to Version 1.4.2. 1.4.x is the mozilla maintenance line, that should garuantee a stable api. Even so there are some not security-related bugfixes in 1.4.2, it is IMHO the best solution for SUSE: - we could build SLES and SLES from one source "- we could build SLES and SLES from one source" I don't understand this sentence, but the rest sounds reasonable. Wolfgang, please update. I will provide test-packages for first inclusion-tests with galeon. Holger, you can find them in Hygiea-stark-162 when it's finished. Please check if we get problems with galeon (are there others?) Ok, I'll quick build and test galeon with these packages. I suspect no problems. Which dists exactly are involved? SLEC uses Galeon 1.2.13 -> no problems building your mozilla with it. This will work -> tested. original 8.1, SLES uses Galeon 1.2.5, it has no support for the Mozilla 1.4 branch. It must be updated to version 1.2.13 (at least), and I currently don't know how much dependencies are involved (will see tommorrow). Wolfgang, go ahead for SLES8 too. I got the ok from Thorsten Kukuk by proxy of Ralf. But we should check against galeon before submitting it to abuild Focus is on maintained products. SLEC is tested by Holger and SLES8 doesn't contain galeon IMHO. So for this we should be on the safe side. I'm not sure about our consumer products. It seems that all Mozilla packages before 1.6 are affected. So we would have to update 8.0 - 9.0 ? Security-Team? In the past we mentioned mozilla updates in a security announcement to be on pub/projects/mozilla. Yes, makes sense. I think this issue can be put into a section 2. Would all of SL 8.0-9.0 then have 1.4.2 packages? adding aj for box-products to CC Andreas, how should we handle updates for box products from 8.0 to 9.0? Only Mozilla 1.4.2 or >= 1.6 will fix these issues. A backport is almost impossible to some versions and would make very much work. We have on 8.0: 0.9.8 8.1: 1.0.1 8.2: 1.2.1 9.0: 1.4 The dependencies for version upgrades besides the 1.4 branch are like hell (Holger?). One possibility would be to make an announcement as in http://www.suse.com/de/security/2002_22_apache.html (section 2) Andreas, please clarify what to do with security-team. THX 8.1 can be updated to galeon 1.2.13 / moz 1.4.2 without further dependencies, no problem there. 8.0 has galeon 1.0.5 (really old), checking update possibility... 8.0 can be updated to galeon 1.2.13 /moz 1.4.2 too. Now please decide what to do. Comment to#21: Yes, make an announcement like section 2 and only update 9.0. Ok, then let's do try it... OK, will check in version for UL / SLEC / 9.0 soon. And one additional note (please tell me if someone doesn't want it that way): As Mozilla 1.4.2 is not officially released yet (and I don't know when) I want to name the RPM version 1.4.1 while Mozilla is talking internally (about) as version 1.4.2. Any objections? No problem with the versioning packages and patchinfos have been submitted CVE-2003-0564: Multiple vulnerabilities in multiple vendor implementations of the Secure/Multipurpose Internet Mail Extensions (S/MIME) protocol allow remote attackers to cause a denial of service and possibly execute arbitrary code via an S/MIME email message containing certain unexpected ASN.1 constructs, as demonstrated using the NISSC test suite. CVE-2003-0564: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) |