Buffer overflow in Sylpheed before 1.0.3 and other versions before 1.9.5 allows remote attackers to execute arbitrary code via an e-mail message with certain headers containing non-ASCII characters that are not properly handled when the user replies to the message. https://bugzilla.redhat.com/beta/show_bug.cgi?id=150687 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0667 ------- Bug moved to this database by dkl 2005-03-30 18:32 ------- This bug previously known as bug 2451 at https://bugzilla.fedora.us/ https://bugzilla.fedora.us/show_bug.cgi?id=2451 Originally filed under the Fedora Legacy product and Package request component. Unknown priority P2. Setting to default priority "normal". Unknown platform PC. Setting to default platform "All". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
There's a further update http://lwn.net/Articles/129716/ which indicates that 1.0.4 fixes yet another problem. FWIW. For RHL9, sylpheed is all the way back on 0.8.9. Not so sure what the right course is here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are updated sylpheed packages to QA: Changelog: * Thu Apr 14 2005 Marc Deslauriers <marcdeslauriers> 0.9.7-1.1.legacy - - Added backported CAN-2005-0667 security fix from 1.0.3 - - Added backported stack buffer overflow fix from 1.0.4 a0bcb2151b7ca67bd13432df2aacd4a17f512699 7.3/sylpheed-0.7.3-1.1.legacy.i386.rpm 949fb57e28aea3dc22dfcd78ce1fea0e421112a2 7.3/sylpheed-0.7.3-1.1.legacy.src.rpm b9285face20d573d6dd3c11af7aa96746bf0deee 9/sylpheed-0.8.9-3.1.legacy.i386.rpm 088bf3907d561b00d2c8e2f47aab6ddffd83c0c9 9/sylpheed-0.8.9-3.1.legacy.src.rpm 04625e1a7b9b9dd2b564b9a35afa292cfaab680b 1/sylpheed-0.9.7-1.1.legacy.i386.rpm 248137cc1023f93dda493b52a699ca5135e02d45 1/sylpheed-0.9.7-1.1.legacy.src.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/sylpheed-0.7.3-1.1.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/7.3/sylpheed-0.7.3-1.1.legacy.src.rpm http://www.infostrategique.com/linuxrpms/legacy/9/sylpheed-0.8.9-3.1.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/9/sylpheed-0.8.9-3.1.legacy.src.rpm http://www.infostrategique.com/linuxrpms/legacy/1/sylpheed-0.9.7-1.1.legacy.i386.rpm http://www.infostrategique.com/linuxrpms/legacy/1/sylpheed-0.9.7-1.1.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCXw+aLMAs/0C4zNoRAkxhAJ96YGsYejW261hwmQE9tFNGYhEpcQCdEyWt YyOxZEEy408eF5jdn8ZFVYo= =qbmT -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA for sylpheed-0.8.9-3.1.legacy.src.rpm for RHL9: * only change to spec file is the addition of the two patches to fix these issues. * verified that these patches are backported from the 1.0.3 and 1.0.4 sylpheed versions * package build and installs fine * seems to run fine +PUBLISH RHL9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCeSyaz8vebpLJCdYRAgLHAKDbn+zyqXd/DXRxKMRfPQps+ICKCACgxs7C BCBE43F3YM+236XRODHTtrQ= =5jV3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 QA w/ rpm-build-compare.sh: - source integrity good - spec file changes minimal - FC1 patches OK; RHL73 0667 patch OK. The lack of 1.04 patch for RHL73 is analyzed below: unmime.c: there is no need to change strdup to strndup, because in each case, the buffer is dynamically allocated to be sufficiently large; in 1.0.3, this was not done. codeconv.c: UnMimeHeader() seems to roughly correspond to unmime_header(); it is not clear whether this is affected or not; in UnMimeHeader, the same buffer is used, with the assumption that the output is always shorter than the input. This may be actually the case, and then this code would probably be OK. procmime.c: this fragment, which applies cleanly, removes the dynamic allocation and passing the string length and replaces it with passing the maximum buffer length. I guess the stack overflow could still occur if the user inputted string was too long for dynamic allocation, but otherwise the code looks reasonably safe. ........ CAN-2005-0667 also seems to fix non-security related bug, but this is OK: "A memory leak of the composition window was fixed." ... Therefore, I'm not 100% sure RHL73 is completely unaffected; it would seem to me that at least procmime.c might be vulnerable to the same stack overflow as the rest; unmime.c and codeconv.c, on the other hand, appear to be unaffected. (The vendor site claims that both bugs only affect 0.8.0 and upwards, but is clearly wrong..) I can't give a PUBLISH for RHL73 because of this uncertainty; either procmime.c also needs to be fixed and/or someone else needs to do some analysis whether these issues should be considered or not. +PUBLISH FC1 949fb57e28aea3dc22dfcd78ce1fea0e421112a2 sylpheed-0.7.3-1.1.legacy.src.rpm 248137cc1023f93dda493b52a699ca5135e02d45 sylpheed-0.9.7-1.1.legacy.src.rpm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFCgIYrGHbTkzxSL7QRAhBLAKDJsW+TY0J7X3BUr4jwZk+Antgg/gCfUntm dGHBT20JoJSDO91eEm+4VxY= =i9cv -----END PGP SIGNATURE-----
Adding 'needswork'.
No activity in almost two years. Fedora Legacy has ended, and this ticket appears in the default search results, so: WONTFIX