Bug 838449 - [PATCH] fix possible buffer overflow
[PATCH] fix possible buffer overflow
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libytnef (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Petr Pisar
http://sourceforge.net/tracker/?func=...
: EasyFix, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-09 03:10 EDT by Petr Pisar
Modified: 2012-07-09 03:22 EDT (History)
0 users

See Also:
Fixed In Version: libytnef-1.5-8.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: CVE-2010-5109
Environment:
Last Closed: 2012-07-09 03:22:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Pisar 2012-07-09 03:10:43 EDT
+++ This bug was initially created as a clone of Bug #831322 +++

Created attachment 591258 [details]
proposed patch to fix possible buffer overflows.

Description of problem:
compiler warning: call ... will always overflow destination buffer.
indeed, there is a trivial bug in the code, no space is reserved for trailing \0.
patch to fix:
--- libytnef-1.5/ytnef.c        2004-08-26 17:09:05.000000000 +0000
+++ libytnef-1.5/ytnef.c        2012-06-08 19:34:07.826123387 +0000
@@ -1327,7 +1327,7 @@
     ULONG compressedSize, uncompressedSize, magic, crc32;
 
     comp_Prebuf.size = strlen(RTF_PREBUF);
-    comp_Prebuf.data = calloc(comp_Prebuf.size, 1);
+    comp_Prebuf.data = calloc(comp_Prebuf.size+1, 1);
     strcpy(comp_Prebuf.data, RTF_PREBUF);
 
     src = p->data;


Version-Release number of selected component (if applicable):
libytnef-1.5-7.fc17

--- Additional comment from ppisar@redhat.com on 2012-07-04 13:59:40 GMT ---

The comp_Prebuf.data[] is never accessed beyond the end. I think more suitable is do memcpy() instead of strcpy() to copy comp_Prebuf.size only bytes without the trailing zero.

Actually the comp_Prebuf.data is never freed which leaks memory.

--- Additional comment from ppisar@redhat.com on 2012-07-04 14:07:56 GMT ---

This issue has been already tracked by upstream <http://sourceforge.net/tracker/?func=detail&aid=2949686&group_id=70352&atid=527487>.

--- Additional comment from ppisar@redhat.com on 2012-07-04 14:40:26 GMT ---

Reproducer:

(1) Obtain a tnef archive with binary document (e.g. the winmail.dat from <http://sourceforge.net/tracker/?func=detail&aid=756215&group_id=70352&atid=533948>).

(2) Explore the archive with ytnefprint tool (from ytnef package) that uses the libytnef library:

$ ytnefprint winmail.dat
Attempting to parse winmail.dat...
---> In TNEF1.0 format
Message Priority: normal
Date Received: Tuesday June 17, 2003 10:23:00 am
Message Class: IPM.Microsoft Mail.Note
    MAPI Properties: 39
   #0: Type: [ BOOLEAN ]  Code: [PR_ALTERNATE_RECIPIENT_ALLOWED]
    Size: 4    Value: True
   #1: Type: [ BOOLEAN ]  Code: [PR_ORIGINATOR_DELIVERY_REPORT_REQUESTED]
    Size: 4    Value: False
   #2: Type: [  LONG   ]  Code: [PR_PRIORITY]
    Size: 4    Value: 0
   #3: Type: [ BOOLEAN ]  Code: [PR_READ_RECEIPT_REQUESTED]
    Size: 4    Value: False
   #4: Type: [  LONG   ]  Code: [PR_SENSITIVITY]
    Size: 4    Value: 0
   #5: Type: [ STRING8 ]  Code: [PR_CONVERSATION_TOPIC]
    Size: 5    Value: [test]
   #6: Type: [ BINARY  ]  Code: [PR_CONVERSATION_INDEX]
    Size: 22    Value: [..4.p...s,j~O...I....L]
   #7: Type: [ BINARY  ]  Code: [PR_SENDER_SEARCH_KEY]
    Size: 26    Value: [SMTP:JGERLAND@SYNACOR.COM.]
   #8: Type: [ BOOLEAN ]  Code: [PR_DELETE_AFTER_SUBMIT]
    Size: 4    Value: False
   #9: Type: [SYS TIME ]  Code: [PR_MESSAGE_DELIVERY_TIME]
    Size: 8    Value: Tuesday June 17, 2003 3:23:00 pm
   #10: Type: [ BINARY  ]  Code: [PR_SENTMAIL_ENTRYID]
    Size: 24    Value: [......3.v#'N..I..G......]
   #11: Type: [  LONG   ]  Code: [PR_SUBMIT_FLAGS]
    Size: 4    Value: 0
   #12: Type: [ BOOLEAN ]  Code: [PR_RTF_IN_SYNC]
    Size: 4    Value: True
   #13: Type: [ BINARY  ]  Code: [PR_RTF_COMPRESSED]
    Size: 217    Detected Compressed RTF.Decompressed text follows
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
*** buffer overflow detected ***: ytnefprint terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x3045708af7]
/lib64/libc.so.6[0x3045706a70]
/usr/lib64/libytnef.so.0(DecompressRTF+0x3a)[0x3045a0470a]
/usr/lib64/libytnef.so.0(MAPIPrint+0x4c8)[0x3045a04e08]
ytnefprint[0x4010e9]
ytnefprint[0x400909]
/lib64/libc.so.6(__libc_start_main+0xed)[0x304562169d]
ytnefprint[0x40097d]

--- Additional comment from ppisar@redhat.com on 2012-07-04 14:53:35 GMT ---

One need to configure with CFLAGS='-O2 -g -Wp,-D_FORTIFY_SOURCE=2' to provoke the abort.

--- Additional comment from ppisar@redhat.com on 2012-07-04 15:10:12 GMT ---

Created attachment 596239 [details]
Better fix for the heap overflow

This fixes the bug by copying only needed bytes.
-----

RHEL-7.0 (libytnef-0:1.5-7.el7.x86_64) is affected.

Note You need to log in before you can comment on or make changes to this bug.