Bugzilla – Bug 521434
VUL-0: CVE-2009-3721, CVE-2009-3887: yTNEF/Evolution TNEF Attachment decoder vulnerabilities report
Last modified: 2020-12-16 09:43:56 UTC
This issue is not public yet, please keep any information about it inside SUSE. ocert would like to coordinate disclosure of the issue with us. Are you the right person to take care or could you reassign the bug to the proper person please? Date: Sat, 11 Jul 2009 11:10:49 +0100 From: Andrea Barisani <lcars@ocert.org> To: security@suse.de Subject: [security@suse.de] yTNEF/Evolution TNEF Attachment decoder vulnerabilities report CC: incidents@ocert.org Hi everyone, oCERT received a vulnerability report about yTNEF and the TNEF Evolution plugin. As this report affects two packages I'm addressing separately both authors at the same time for better coordination but we thought to contact security@suse.de as you are obviously tied to Evolution and might have some good contacts and/or be responsible for Evolution code. The TNEF Evolution author confirmed that the plugin is un-maintained and it's meant to be used as demonstration only, though some vendors ship packages of it. We are still waiting feedback from yTNEF maintainer. oCERT would like to receive feedback about the described issues and hopefully coordinate a patch release, we would like to pre-notify affected vendors with the patches (with a reasonable embargo time that we can agree on, so that vendors can prepare updated packages in advance) and then release an advisory along with the patched releases for both packages. Chances are that as the TNEF Evolution plugin is experimental and unmaintained the best we can do is advise distros to not package it anymore, we are compiling a list of affected ones. IMPORTANT: Please do not discuss this matter publicly and/or commit any public code related to it (including patches) as it is to be considered embargoed. I'm attaching the detailed report we received as well as PoC. Please do not hesitate to contact me if you have any questions/concerns. Thanks! -- Andrea Barisani | Founder & Project Coordinator oCERT | Open Source Computer Emergency Response Team <lcars@ocert.org> http://www.ocert.org 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E "Pluralitas non est ponenda sine necessitate"
looks like we don't have the tnef evolution plugin, reassigning to libytnef maintainer.
Andrea: libytnef as included in openSUSE comes from claws-mail-extra-plugins. The README there says that upstream libytnef is dead.
As the package is insecure and unmaintained can it then be removed (or updated with a stub, not sure how do you handle unsafe package removal)? We had no feedback from upstream (as expected) for libytnef and the Evolution plugin is also unmaintained. I'll email vendor-sec on monday with report details advising not to ship these anymore and proposing a (short) embargo time. Thanks!
(In reply to comment #5) > As the package is insecure and unmaintained can it then be removed (or updated > with a stub, not sure how do you handle unsafe package removal)? We had no > feedback from upstream (as expected) for libytnef and the Evolution plugin is > also unmaintained. We can't remove packages from already released distributions so we have to fix the bugs without help of upstream if necessary.
Ok, I brought the issue up on vendor-sec. Let's see what other vendors have to say and if anyone can come up with a patch.
libytnef as included in sylpheed-claws looks safe. It doesn't handle filenames itself. However, the vulnerable evolution tnef plugin source is part of evolution itself rather than an extra tarball as described at http://www.go-evolution.org/Tnef. According to the package content and build logs it looks like it's not actually built in our distros though. Nevertheless the evolution team should take care to get this fixed upstream.
Nirav, can you assign someone to this to look at it with prio? This is an vulnerability issue on Evolution.
I am looking into this now and will put up a fix for it in a couple of days.
The SWAMPID for this issue is 26354. Please submit the patch and patchinfo file using this ID. (https://swamp.suse.de/webswamp/wf/26354)
Philipp, do you have the time to check the source of the tnef package. It might be affected too.
oCERT would like to release an advisory next week, any chance to get a fix within that time? Thanks.
(In reply to comment #15) > oCERT would like to release an advisory next week, any chance to get a fix > within that time? Thanks. Feel free to release the advisory whenever you want.
This is public now. Philipp, were you able to look at the code in the meantime?
Path names coming from a tnef attachment are only used if the user explicitly requests it via command line option. The complete name is also checked via stat so it can't overwrite existing files. File name construction is also safe. So For me at least it looks like tnef isn't vulnerable.
CVE-2009-3721
just for the record: Reply-To: oss-security@lists.openwall.com Date: Fri, 6 Nov 2009 14:53:15 -0500 (EST) From: Josh Bressers <bressers@redhat.com> To: oss-security@lists.openwall.com Cc: mjc@redhat.com, coley <coley@mitre.org> Subject: Re: [oss-security] CVE request for oCERT advisory 2009-013 (yTNEF/Evolution TNEF) ----- "Steven M. Christey" <coley@linus.mitre.org> wrote: > On Wed, 28 Oct 2009, Mark J Cox wrote: > > > > > I checked and oCERT don't have a name, so use CVE-2009-3721 for this. > > This advisory covers both buffer overflows and path traversal in the same > data field. While these may stem from "input validation" (as many issues > do), we would typically assign two separate CVE names, since the fix for a > buffer overflow would not necessarily fix the path traversal (or vice > versa). > > Unless there's some deeper reason for using a single CVE, I think we should > assign separate CVEs here. If you agree Mark, we can use CVE-2009-3721 for > the overflow, and you could assign a new CVE for the traversal. > Let's use CVE-2009-3887 for the traversal then. Thanks. -- JB
Created attachment 406237 [details] Evolution Patch I tried to resolve the vulnerabilities and found the solution, which should work fine. I tried to test it but unfortunately couldn't test it. Can you please tell me the way to test it and if possible send me one winmail.dat file so i can check it well. Please review the patch and tell me about changes required. Thanks
Created attachment 406897 [details] Evolution Patch Thanks for review. I have added glib functions and have included one fix.
Created attachment 406989 [details] Evolution Patch Thanks Chen, this updated patch includes memory leak fixes and freeing ifilename.
p5->p3 mass change