Bugzilla – Bug 85842
VUL-0: CVE-2006-5639: AUDIT-0: OpenWBEM
Last modified: 2021-11-03 15:06:59 UTC
Date: Wed, 25 May 2005 10:39:57 +0200 From: Marius Tomaschewski <mt@suse.de> To: security-team@suse.de User-Agent: Mutt/1.5.9i Cc: okir@suse.de, choeger@suse.de Subject: [security-team] [dnuffer@vintela.com: [Openwbem-devel] RFC: New Secure OpenWBEM Architecture] Reply-To: security-team@suse.de Errors-To: security-team-bounces+thomas=suse.de@suse.de [-- Anhang #1 --] [-- Typ: text/plain, Kodierung: 8bit, GröÃe: 1,5K --] Hi Security-Team! Könntet Ihr Euch das Overview-Doc im Attachment bitte genauer unter die Lupe nehmen und auf openwbem-devel@lists.sourceforge.net (bzw. Dan Nuffer) kommentieren? Da OpenWBEM eine zentrale Rolle in unseren Management Tools spielen wird, wÀre es gut, es schon mal fÃŒr einen Security-Audit vorzumerken. Danke! ----- Forwarded message from Dan Nuffer <dnuffer@vintela.com> ----- Resent-From: Bart Whiteley <bwhiteley@novell.com> Resent-Date: Tue, 24 May 2005 15:10:46 -0600 From: Dan Nuffer <dnuffer@vintela.com> To: mt@suse.de Subject: [Openwbem-devel] RFC: New Secure OpenWBEM Architecture Reply-To: openwbem-devel@lists.sourceforge.net Date: Tue, 24 May 2005 15:11:42 -0600 For the past few weeks, Kevin Van Horn and I have been working on a new architecture for owcimomd with the primary goal to greatly reduce the chance of a sucessful privilege escalation attack. The overall goal has been to increase the security, so we have also considered some additional threats such as tampering with data, repudiation, information disclosure and denial of service. We have been storing documentation in CVS under doc/engineering/sec-*. I've attached the overview document, and I'd like to hear everyone's comments. -- Dan Nuffer Vintela, Inc. http://vintela.com/ ----- End forwarded message ----- Gruesse, Marius Tomaschewski <mt@suse.de> -- SUSE LINUX, Nuernberg --- Development, Server-Team PGP public key on: http://www.suse.de/~mt/mt.pgp DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0 [-- Anhang #2: sec-openwbem-arch.html --] [-- Typ: text/html, Kodierung: 7bit, GröÃe: 8,2K --]
Created attachment 38088 [details] sec-openwbem-arch.html
http://www.novell.com/coolsolutions/feature/14625.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)