|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2006-5639: AUDIT-0: OpenWBEM | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Thomas Biege <thomas> |
| Component: | Incidents | Assignee: | Bart Whiteley <bwhiteley> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | forgotten_bVpj-Jicuv, jon.carey, meissner, mt, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://openwbem.sourceforge.net/ | ||
| Whiteboard: | CVE-2006-5639: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 65423 | ||
| Attachments: |
sec-openwbem-arch.html
Audit report patch for buffer overflow vulnerabilities new patch |
||
|
Description
Thomas Biege
2005-05-25 10:25:28 UTC
Created attachment 38088 [details]
sec-openwbem-arch.html
This bug should somehow reference #65423. What would be the right way to do that? Here is some discussion about the design of openwbem: http://sourceforge.net/mailarchive/forum.php?thread_id=7358198&forum_id=1847 Ok, I started the audit. :-) Seems like the rpm could be installed :-) Will preint setup and architecture docs now. There is no cim-schema package in /work/... but the docs say one must install one. I would say, the *.mof files are in the novell-life package: /work/SRC/all/novell-life or better, the successor project NIM, that providers all cimv2.9 mof's as well as some of the new classes from v2.9.1pre: https://forge.provo.novell.com/modules/xfmod/project/?nim export CVSROOT=":ext:kulge.provo.novell.com:/cvsroot/nim" The actual / official MOF files are at: http://www.dmtf.org/standards/cim http://www.dmtf.org/standards/cim/cim_schema_v291_prelim/CIM_V2.9.1Preliminary-MOFs.zip bug #65423 may be worth reading. Created attachment 39970 [details]
Audit report
Attached the audit report. Please have a look.
To what extent can I share this audit report with OpenWBEM developers outside of the company? feel free to share with all openwbem developers. ping. anyone read the report yet? :-) Guys, anyone alive? There is a remotely exploitable buffer overflow condition in a product we ship. Nobody cares??? Hmm... I would say, it makes sense to reasign it to Bart (maintainer). The audit report mentioned many items. Could we get a separate bug specifically for this exploitable buffer overflow of which you speak? I think there are two: - HTTPChunkedIStreamBuffer() - HTTPLenLimitIStreamBuffer() Jon Carey, Dan Nuffer (external), and I did review the security audit in some detail soon after it was given to us. Sorry I didn't report our comments at the time. Let me see if I can summarize them, then later I'll try to address each one. Basic sentiments were: - Much appreciation for the audit. - Some items had already been fixed in CVS. - Some disagreement on some items. For example, audit complains that OW implements its own strtoll() instead of using the one in the system libs. Actually, the OW implementation of strtoll() is only used on plats that don't provide one, so on Linux the system strtoll() is used. - Some items were legitimate and weren't yet fixed in CVS. It's possible they have been fixed in CVS since. I'll have to check. I'll start checking CVS to see which, if any, of the items remain to be fixed. Then we need to decide which, if any, items need to be back ported for sles9 updates. Wouldn't it be appropriate for separate bugs to be created for these? Ok. Usually we dont create a single entry per bug to be fixed. The work to handle it grows non-linear. I think its easier to have everything in this bugzilla thread. And there are not that many bugs. We will just wait for the CVS diff which bugs actually have to be fixed and what needs to be backported. Created attachment 45841 [details]
patch for buffer overflow vulnerabilities
How about the attached patch?
Looks ok but the last chunk should also have a tmpLen < 0 check, just in case. I'd rather like to have all size fields as unsigned but this would probably require too many changes. As far as I see only the XMLUnEscape() is left. ping :-) WRT XMLUnEscape()
12:14 <dnuffer>In the XML code it may just be simpler to use: unsigned long
lval = strtoul
12:57 <whiteley>I thought about doing the strtoul().
12:57 <whiteley>but didn't like what the man page said.
12:57 <whiteley>if it's negative, it just flips the sign.
13:05 <dnuffer>either way, that fix isn't really necessary, because the lexer
first has to match the input. The regex is essentially [0-9]+
13:06 <dnuffer>so no way a - could be passed to strtoul()
Created attachment 47461 [details]
new patch
see if you like this patch better.
Yes, it looks ok from my perspective. I've submitted a patched OpenWBEM for sles9. Now what? I'm not sure if I'm still up to date with the patch process, but: It may make sense to set NEEDINFO to gp (SLES9, SLES9-SP3, no patch? ;) but I mean the decision is clear in case of security-team, and this is already done in Comment #24. Call "is_maintained openwbem" and create patchinfo file for the concerned distributions (should be done bellow) and send it via mail to suse-dist@suse.de and put it to /work/src/done/PATCHINFO/. If there already exists a SWAMPID, add it to the dummy bellow. If not, it will be assigned later. You can monitor the patch process at: http://w2d.suse.de/abuildstat/patch-status cat <<EOT >/work/src/done/PATCHINFO/openwbem-sles9.patchinfo DISTRIBUTION: sles9-i386,sles9-ia64,sles9-ppc,sles9-s390,sles9-s390x,sles9-x86_64 PACKAGE: openwbem PACKAGER: bwhiteley@suse.de BUGZILLA: 85842 SWAMPID: CATEGORY: security INDICATIONS: All users of openwbem should update. CONTRAINDICATIONS: None. DESCRIPTION: Enter a detailed description of the fix here. EOT Ahm... PACKAGER: bwhiteley@novell.com Anything happend here? Shall I submit patchinfos? I think its only a maintained product. I will open SWAMP if you decided to make updates for older distributions. I just followed the steps outlined by Marius. Now what? We are missing a SWAMP-ID should be provided by security team for security updates. I sent an eMail to security-team. Sebastian volenteered see comment #28 SM-Tracker 2377. Sorry for delay, last week I was on SuSE-Labs con and this week on vacation. I will update the patchinfos in /work/... bart, can you fill in the Swamp-ID into the patchinfo yourself? I am missing the proper permissions and its mode 0644. looks like someone already did it. Bart, the final patch was the one from comment #23 right? We`d like to inform the other vendors about it before releasing. That is correct. The patch is from #23. Looks like this isn't in SLES9-SP3-beta2. Should it be? It looks like it is in dist/full/full-sles9-beta-*. It is not however in machcd/SLES/SLES-9-SP-3-i386-Beta2/CD2/suse/i586/ Should it not be in SLES9-SP3-beta2? security fixes are done in the mainbranch, they will not show up in beta. They will be collected (as patch) on SP release. if you have another openwbem version in the BETA branch (for SP3), this one needs to be fixed too. does "mainbranch" mean sles9? "They will be collected (as patch) on SP release." What does this mean? Do I need to 'submitpac -dr sles9-beta openwbem' with my patched sources? no, you do not need to do anything anymore. SUSE QA: Do we have any specific bug fix tests for this patch/audit? Advisory and packages released. closing. mitre assigned: CVE-2005-3298 CVE-2005-3297 *** Bug 218684 has been marked as a duplicate of this bug. *** Mitre has also assigned CVE-2006-5639 out of confusion. CVE-2006-5639: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P) |