Launchpad has imported 10 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=543965.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-12-03T15:42:32+00:00 Paul wrote: Description of problem: There are a number of issues with the code of ytnef.c Version-Release number of selected component (if applicable): 1.5.5 How reproducible: By using libytnef. Steps to Reproduce: 1. Run the code (eg, run evolution with the experimental TNEF Attachment Decoder plugin). 2. 3. Actual results: Leaks. Invalid reads. Expected results: None of the above. Additional info: I'll try to attach a patch shortly. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/0 ------------------------------------------------------------------------ On 2009-12-03T16:05:10+00:00 Paul wrote: Created attachment 375822 Fix several issues in ytnef.c 0) This patch is the result of a discussion started at a evolution bugreport: https://bugzilla.gnome.org/show_bug.cgi?id=602177 1) The patch tries to fix these issues: - SwapWord(), SwapDWord() and SwapDDWord() can return a pointer to a local value (in big endian mode). They can also be simplified (though some might argue with my idea of simple here); - TNEFRendData() reads a 14 byte (packed) value in a TNEF stream as if it were a 16 byte (unpacked) struct; - leaks related to MAPIProps->properties->propnames; - buffer overflow in comp_Prebuf.data (in DecompressRTF()), fixed by a minor code reorganization; - one "if branch" in DecompressRTF() should have a return (though I have no way to test what that return should be). 2) Note that the code (even with this patch) generates a lot of compiler warnings. I haven't really looked at those. 3) Upstream looks dead to me. If (something like) the patch is accepted will the packager contact other packagers (as the patch does fix a buffer overflow)? Or should (something like) the patch just be dropped as upstream's page (at sf.net)? Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/1 ------------------------------------------------------------------------ On 2009-12-03T16:09:42+00:00 Paul wrote: (In reply to comment #1) > 1) The patch tries to fix these issues: > - SwapWord(), SwapDWord() and SwapDDWord() can return a pointer to a local > value (in big endian mode). They can also be simplified (though some might > argue with my idea of simple here); > - TNEFRendData() reads a 14 byte (packed) value in a TNEF stream as if it were > a 16 byte (unpacked) struct; > - leaks related to MAPIProps->properties->propnames; > - buffer overflow in comp_Prebuf.data (in DecompressRTF()), fixed by a minor > code reorganization; > - one "if branch" in DecompressRTF() should have a return (though I have no > way > to test what that return should be). Furthermore: - TNEFPriority() accesses a 2 byte WORD value as if it were a 4 byte DWORD value. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/2 ------------------------------------------------------------------------ On 2009-12-04T11:34:50+00:00 Paul wrote: Created attachment 376060 [RFC] Address all current gcc (default) warnings (In reply to comment #1) > 2) Note that the code (even with this patch) generates a lot of compiler > warnings. I haven't really looked at those. - gcc will compile ytnef.c without any warnings with this patch (that should be applied on top of my previous patch). - Most of the fixes are entirely trivial: one wonders why those changes have not been done earlier. - I had to resort to casting a few times; as far as I know all casts should be safe (but a review whether that is actually correct would be much appreciated). - I changed the definition of to_utf8(), which, sadly, is included in <ytneh.h>. Still seemed the best thing to do. - Please note the few remarks I added about the current interface. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/3 ------------------------------------------------------------------------ On 2009-12-18T11:13:40+00:00 Milan wrote: These are warnings I see on my 64bit machine. > ytnef.c: In function 'TNEFFillMapi': > ytnef.c:474: warning: format '%i' expects type 'int', but argument 2 has type > 'long int' > ytnef.c:475: warning: format '%i' expects type 'int', but argument 2 has type > 'long int' > ytnef.c:480: warning: format '%i' expects type 'int', but argument 2 has type > 'long int' > ytnef.c:481: warning: format '%i' expects type 'int', but argument 2 has type > 'long int' There is a format for them, like G_GUINT32_FORMAT, which might help here. I tested both patches and it otherwise looks good. I would recommend to use them personally. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/4 ------------------------------------------------------------------------ On 2009-12-18T12:31:26+00:00 Paul wrote: (In reply to comment #4) > There is a format for them, like G_GUINT32_FORMAT, which might help here. I > tested both patches and it otherwise looks good. I would recommend to use them > personally. Maybe something like: #include <inttypes.h> printf("%" PRIi32 " bytes missing\n", size - (d-data)); (I can't remember ever having used this.) Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/5 ------------------------------------------------------------------------ On 2009-12-18T13:46:16+00:00 Milan wrote: whatever you prefer. Yet another possibility might be to use "%d" instead of "%i" and cast the value to "(int) (size - (d-data))". I do not suppose there will be too large files, and, more than that, it's for debug only anyway. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/6 ------------------------------------------------------------------------ On 2010-03-15T13:26:12+00:00 Bug wrote: This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/7 ------------------------------------------------------------------------ On 2011-06-02T17:13:23+00:00 Bug wrote: This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/8 ------------------------------------------------------------------------ On 2011-06-27T14:38:08+00:00 Bug wrote: Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/comments/9 ** Changed in: libytnef (Fedora) Status: Unknown => Won't Fix ** Changed in: libytnef (Fedora) Importance: Unknown => Medium ** Bug watch added: GNOME Bug Tracker #602177 https://bugzilla.gnome.org/show_bug.cgi?id=602177 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1011839 Title: [Patch] libytnef buffer overflow To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libytnef/+bug/1011839/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
