View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005729SOGoActiveSyncpublic2023-04-05 13:522023-09-07 13:10
Reporterleecher Assigned Toqhivert  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
PlatformServerOSLinux DebianOS Version10.9
Product Version5.8.2 
Fixed in Version5.9.0 
Summary0005729: sogod always crashes due to bug in libytnef0 parsing library
Description

Crash in libytnef.so.0 in DecompressRTF due to NULL pointer supplied. Seems to be a parsing bug in libtnef?
Seems to be a decoding error, becauseanother standalone PNEF-parse called TNEF (https://github.com/verdammelt/tnef) can read embedded data stream normally:

tnef --debug winmail.dat

(MESS) Date Modified <8020> [type: date <0003>] [len: 14] = Thu 2010/04/01 16:09:50
(MESS) Message ID <8009> [type: string <0001>] [len: 33] ='F9E6EA4538DF6E4989DE032F0BFB063D'
(MESS) MAPI Properties <9003> [type: byte <0006>] [len: 1219244] = 0x36 0x00 0x00 0x00 0x0b 0x00 0x02 0x00 0x01 0x00 0x00 0x00 0x03 0x00 0x26 0x00 0x00 0x00 0x00 0x00 0x0b 0x00 0x2b ...

But in SOGo, we have a NULL-pointer for data:

Apr 5 14:03:03 debmail kernel: [1911383.009407] sogod[28526]: segfault at 0 ip 00007f0043084280 sp 00007ffef7024420 error 4 in libytnef.so.0.0.0[7f0043083000+5000]
Apr 5 14:03:03 debmail kernel: [1911383.009414] Code: 00 00 00 64 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 83 fe 04 c7 44 24 04 00 00 00 00 0f 46 ce 85 f6 74 35 48 8d 74 24 04 <0f> b6 14 07 88 14 06 48 83 c0 01 39 c1 7f f1 8b 44 24 0
4 48 8b 7c

(gdb) run
Starting program: /usr/sbin/sogod -WOUseWatchDog NO -WONoDetach YES -WOPort 127.0.0.1:20000 -WOWorkersCount 1 -WOLogFile - -WOPidFile /tmp/sogo.pid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Apr 05 14:30:23 sogod [30967]: version 5.8.2 (build @sogo-build.alinto.int 202304041735) -- starting
Apr 05 14:30:23 sogod [30967]: vmem size check enabled: shutting down app when vmem > 384 MB. Currently at 113 MB
Apr 05 14:30:23 sogod [30967]: <0x0x5555558e7200[SOGoProductLoader]> SOGo products loaded from '/usr/lib/GNUstep/SOGo':
Apr 05 14:30:23 sogod [30967]: <0x0x5555558e7200[SOGoProductLoader]> Contacts.SOGo, ContactsUI.SOGo, ActiveSync.SOGo, SchedulerUI.SOGo, AdministrationUI.SOGo, PreferencesUI.SOGo, MailPartViewers.SOGo, Mailer.SOGo, CommonUI.SOGo, MainUI.SOGo, MailerUI.SOGo, Appointments.SOGo
Apr 05 14:30:23 sogod [30967]: All products loaded - current memory usage at 124 MB
Apr 05 14:30:23 sogod [30967]: |SOGo| WOHttpAdaptor listening on address 127.0.0.1:20000
Apr 05 14:30:43 sogod [30967]: <0x0x5555559b90c0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds
Apr 05 14:30:43 sogod [30967]: <0x0x5555559b90c0[SOGoCache]> Using host(s) 'localhost' as server(s)
Apr 05 14:30:43 sogod [30967]: <0x0x555555f8e2e0[SOGoWebDAVAclManager]> entry '{DAV:}write' already exists in DAV permissions table
Apr 05 14:30:43 sogod [30967]: <0x0x555555f8e2e0[SOGoWebDAVAclManager]> entry '{DAV:}write-properties' already exists in DAV permissions table
Apr 05 14:30:43 sogod [30967]: <0x0x555555f8e2e0[SOGoWebDAVAclManager]> entry '{DAV:}write-content' already exists in DAV permissions table
Apr 05 14:30:43 sogod [30967]: <0x0x555555780ec0[SOGoActiveSyncDispatcher]> Change detected using Ping, we let the EAS client know to send a Sync.
Apr 05 14:30:43 sogod [30967]: 11.222.333.44 "POST /SOGo/Microsoft-Server-ActiveSync?Cmd=Ping&User=xxx&DeviceId=31225DB663334E86AD5021CE7D526B14&DeviceType=WindowsOutlook15 HTTP/1.1" 200 122/860 0.657 - - 7M - 14
Apr 05 14:30:44 sogod [30967]: <0x0x555555fcc820[SOGoActiveSyncDispatcher]> Change detected during Sync, we push the content.
Apr 05 14:30:44 sogod [30967]: 11.222.333.44 "POST /SOGo/Microsoft-Server-ActiveSync?Cmd=Sync&User=xxx&DeviceId=31225DB663334E86AD5021CE7D526B14&DeviceType=WindowsOutlook15 HTTP/1.1" 200 141/617 0.066 - - 788K - 15
Apr 05 14:30:44 sogod [30967]: <0x0x555555f7eef0[NGImap4Client]> Note: no key found for sorting, using 'DATE': (null)
2023-04-05 14:30:44.855 sogod[30967:30967] parseTimeZone: cannot parse time notation 'CET'
2023-04-05 14:30:44.855 sogod[30967:30967] parseTimeZone: cannot parse time notation 'CET'
2023-04-05 14:30:44.928 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
Apr 05 14:30:44 sogod [30967]: [WARN] <0x5555564539e0[SOGoTNEFMailBodyPart]:2> Unidentified extension .csv
Apr 05 14:30:44 sogod [30967]: [WARN] <0x5555564539e0[SOGoTNEFMailBodyPart]:2> Unidentified extension .csv
2023-04-05 14:30:45.002 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.055 sogod[30967:30967] parseTimeZone: cannot parse time notation 'CET'
2023-04-05 14:30:45.056 sogod[30967:30967] parseTimeZone: cannot parse time notation 'CET'
2023-04-05 14:30:45.195 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.281 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.675 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.743 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.874 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:45.947 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.044 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.116 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.187 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.403 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
Apr 05 14:30:46 sogod [30967]: [WARN] <0x555556f42ac0[SOGoTNEFMailBodyPart]:2> Unidentified extension
2023-04-05 14:30:46.487 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
Apr 05 14:30:46 sogod [30967]: [WARN] <0x5555564943f0[SOGoTNEFMailBodyPart]:2> Unidentified extension .gif
2023-04-05 14:30:46.564 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.650 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:46.722 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
Apr 05 14:30:46 sogod [30967]: [WARN] <0x5555564893f0[SOGoTNEFMailBodyPart]:2> Unidentified extension .jpg
2023-04-05 14:30:46.832 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
Apr 05 14:30:46 sogod [30967]: [WARN] <0x555557dc0b90[SOGoTNEFMailBodyPart]:2> Unidentified extension .jpg
2023-04-05 14:30:46.912 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
2023-04-05 14:30:47.068 sogod[30967:30967] File NSConcreteMapTable.m: 567. In NSFreeMapTable Null table argument supplied
ERROR: invalid alloc size 1217899 at ytnef.c : 529, suspected corruption (exceeded 524288 bytes)
ERROR Parsing MAPI block

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff685a280 in SwapDWord () from /lib/x86_64-linux-gnu/libytnef.so.0
(gdb) bt
#0 0x00007ffff685a280 in SwapDWord () from /lib/x86_64-linux-gnu/libytnef.so.0
0000001 0x00007ffff685ce3a in DecompressRTF () from /lib/x86_64-linux-gnu/libytnef.so.0
0000002 0x00007ffff1196837 in -[SOGoTNEFMailBodyPart decodeBLOB] (self=0x5555564943f0, _cmd=0x7ffff11cb380 <_OBJC_SELECTOR_TABLE+96>) at SOGoTNEFMailBodyPart.m:324
0000003 0x00007ffff11960c1 in -[SOGoTNEFMailBodyPart initWithName:inContainer:] (self=0x5555564943f0, _cmd=0x7ffff7f807f0 <_OBJC_SELECTOR_TABLE+112>, _name=0x55555644f440, _container=0x555557f41a70) at SOGoTNEFMailBodyPart.m:190
0000004 0x00007ffff7ee14d6 in +[SOGoObject objectWithName:inContainer:] (self=0x7ffff11cb2a0 <_OBJC_Class_SOGoTNEFMailBodyPart>, _cmd=0x7ffff11c52c0 <_OBJC_SELECTOR_TABLE+2304>, _name=0x55555644f440, _container=0x555557f41a70)
at SOGoObject.m:123
0000005 0x00007ffff118f42f in -[SOGoMailObject lookupImap4BodyPartKey:inContext:] (self=0x555557f41a70, _cmd=0x7ffff0b112c0 <_OBJC_SELECTOR_TABLE+1312>, _key=0x55555644f440, _ctx=0x5555561414b0) at SOGoMailObject.m:1257
0000006 0x00007ffff0ae3b53 in -[SOGoMailObject(ActiveSync) _calendarFromParts:parent:] (self=0x555557f41a70, _cmd=0x7ffff0b112f0 <_OBJC_SELECTOR_TABLE+1360>, parts=0x5555572030c0, parent=0x555557f41a70) at SOGoMailObject+ActiveSync.m:835
0000007 0x00007ffff0ae40e2 in -[SOGoMailObject(ActiveSync) calendarFromIMIPMessage] (self=0x555557f41a70, _cmd=0x7ffff0b11440 <_OBJC_SELECTOR_TABLE+1696>) at SOGoMailObject+ActiveSync.m:903
0000008 0x00007ffff0ae4bf3 in -[SOGoMailObject(ActiveSync) activeSyncRepresentationInContext:] (self=0x555557f41a70, _cmd=0x7ffff0b0cf70 <_OBJC_SELECTOR_TABLE+2128>, _context=0x5555561414b0) at SOGoMailObject+ActiveSync.m:999
0000009 0x00007ffff0adb8b6 in -[SOGoActiveSyncDispatcher(Sync) processSyncGetChanges:inCollection:withWindowSize:withMaxSyncResponseSize:withSyncKey:withFolderType:withFilterType:inBuffer:lastServerKey:defaultInterval:mergeFolders:] (
self=0x555555fb3250, _cmd=0x7ffff0b0d0a0 <_OBJC_SELECTOR_TABLE+2432>, theDocumentElement=0x5555559f7720, theCollection=0x555555e432f0, theWindowSize=100, theMaxSyncResponseSize=5296128, theSyncKey=0x555555e45f00,
theFolderType=ActiveSyncMailFolder, theFilterType=0x0, theBuffer=0x555555dddbb0, theLastServerKey=0x7fffffffb9e8, theDefaultInterval=30, theMergeFolder=0 '\000') at SOGoActiveSyncDispatcher+Sync.m:1724
0000010 0x00007ffff0addf7b in -[SOGoActiveSyncDispatcher(Sync) processSyncCollection:inBuffer:changeDetected:maxSyncResponseSize:] (self=0x555555fb3250, _cmd=0x7ffff0b0d170 <_OBJC_SELECTOR_TABLE+2640>, theDocumentElement=0x5555559f7720,
theBuffer=0x555555dddab0, changeDetected=0x7fffffffbb9f "", theMaxSyncResponseSize=5296128) at SOGoActiveSyncDispatcher+Sync.m:2150
0000011 0x00007ffff0ae0227 in -[SOGoActiveSyncDispatcher(Sync) processSync:inResponse:] (self=0x555555fb3250, _cmd=0x555555b60030, theDocumentElement=0x55555603eea0, theResponse=0x5555560d0f20) at SOGoActiveSyncDispatcher+Sync.m:2662
0000012 0x00007ffff0ad0e92 in -[SOGoActiveSyncDispatcher dispatchRequest:inResponse:context:] (self=0x555555fb3250, _cmd=0x7ffff0b5fc60 <_OBJC_SELECTOR_TABLE+128>, theRequest=0x555556143d60, theResponse=0x5555560d0f20,
theContext=0x5555561414b0) at SOGoActiveSyncDispatcher.m:4442
0000013 0x00007ffff0b55c1c in -[SOGoMicrosoftActiveSyncActions microsoftServerActiveSyncAction] (self=0x5555557695c0, _cmd=0x555555b60060) at SOGoMicrosoftActiveSyncActions.m:59
0000014 0x00007ffff79ac06d in ?? () from /lib/libNGObjWeb.so.4.9
0000015 0x00007ffff7a3a2ac in ?? () from /lib/libNGObjWeb.so.4.9
0000016 0x00007ffff7a3a3d8 in ?? () from /lib/libNGObjWeb.so.4.9
0000017 0x00007ffff7a349bd in ?? () from /lib/libNGObjWeb.so.4.9
0000018 0x00007ffff7a36dee in ?? () from /lib/libNGObjWeb.so.4.9
0000019 0x00007ffff79bd96f in ?? () from /lib/libNGObjWeb.so.4.9
0000020 0x00007ffff797e968 in ?? () from /lib/libNGObjWeb.so.4.9
0000021 0x00007ffff797ec81 in ?? () from /lib/libNGObjWeb.so.4.9
0000022 0x000055555555d56d in -[SOGo dispatchRequest:] (self=0x5555559f25e0, _cmd=0x7ffff7b61180, _request=0x555556143d60) at SOGo.m:584
0000023 0x00007ffff7a25122 in ?? () from /lib/libNGObjWeb.so.4.9
0000024 0x00007ffff7a25498 in ?? () from /lib/libNGObjWeb.so.4.9
0000025 0x00007ffff7a2122d in ?? () from /lib/libNGObjWeb.so.4.9
0000026 0x00007ffff7a2143d in ?? () from /lib/libNGObjWeb.so.4.9
0000027 0x00007ffff7a21843 in ?? () from /lib/libNGObjWeb.so.4.9
0000028 0x00007ffff7a21cbf in ?? () from /lib/libNGObjWeb.so.4.9
0000029 0x00007ffff710b357 in -[NSNotificationCenter _postAndRelease:] (self=0x5555557220f0, _cmd=<optimized out>, notification=0x5555560ba500) at NSNotificationCenter.m:1198
0000030 0x00007ffff75d3d3c in ?? () from /lib/libNGExtensions.so.4.9
0000031 0x00007ffff7221899 in -[GSRunLoopCtxt pollUntil:within:] (self=<optimized out>, _cmd=0x7ffff7414a60 <_OBJC_SELECTOR_TABLE+1184>, milliseconds=<optimized out>, contexts=0x555555acb0d0) at GSRunLoopCtxt.m:600
0000032 0x00007ffff71534ff in -[NSRunLoop acceptInputForMode:beforeDate:] (self=0x555555a18360, _cmd=0x7ffff7414a90 <_OBJC_SELECTOR_TABLE+1232>, mode=0x7ffff7415840 <_OBJC_INSTANCE_2>, limit_date=0x5555559e8e30) at NSRunLoop.m:1224
0000033 0x00007ffff7153294 in -[NSRunLoop runMode:beforeDate:] (self=0x555555a18360, _cmd=<optimized out>, mode=0x7ffff7415840 <_OBJC_INSTANCE_2>, date=0x5555559e8e30) at NSRunLoop.m:1304
0000034 0x00007ffff797e1a4 in ?? () from /lib/libNGObjWeb.so.4.9
0000035 0x000055555555c70c in -[SOGo run] (self=0x5555559f25e0, _cmd=0x7ffff7ae5eb0) at SOGo.m:337
0000036 0x00007ffff79a8307 in WOApplicationMain () from /lib/libNGObjWeb.so.4.9
0000037 0x00007ffff79c8ec7 in WOWatchDogApplicationMain () from /lib/libNGObjWeb.so.4.9
0000038 0x000055555555b2fe in main (argc=13, argv=0x7fffffffeb88, env=0x7fffffffebf8) at sogod.m:51
(gdb) frame 2
0000002 0x00007ffff1196837 in -[SOGoTNEFMailBodyPart decodeBLOB] (self=0x5555564943f0, _cmd=0x7ffff11cb380 <_OBJC_SELECTOR_TABLE+96>) at SOGoTNEFMailBodyPart.m:324
324 SOGoTNEFMailBodyPart.m: Datei oder Verzeichnis nicht gefunden.
(gdb) print filedata
$1 = (variableLength ) 0x555557f01b00
(gdb) print filedata
$2 = {data = 0x0, size = 1217899}

(gdb) print tnef
$3 = {version = "TNEF1.0\000\000\000\000\000\000\000\000", from = {data = 0x0, size = 0}, subject = {data = 0x555557db2ed0 "The subject of my mail", size = 23}, dateSent = {wYear = 2010, wMonth = 4, wDay = 1, wHour = 16, wMinute = 9,
wSecond = 38, wDayOfWeek = 4}, dateReceived = {wYear = 0, wMonth = 0, wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0}, messageStatus = "\000\000\000\000\000\000\000\000\000",
messageClass = "IPM.Microsoft Mail.Note", '\000' <repeats 26 times>, messageID = "F9E6EA4538DF6E4989DE032F0BFB063D", '\000' <repeats 17 times>, parentID = '\000' <repeats 49 times>, conversationID = '\000' <repeats 49 times>, body = {
data = 0x0, size = 0}, priority = "normal\000\000\000", starting_attach = {Date = {wYear = 0, wMonth = 0, wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0}, Title = {data = 0x0, size = 0}, MetaFile = {data = 0x0,
size = 0}, CreateDate = {wYear = 0, wMonth = 0, wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0}, ModifyDate = {wYear = 0, wMonth = 0, wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0},
TransportFilename = {data = 0x0, size = 0}, RenderData = {atyp = 0, ulPosition = 0, dxWidth = 0, dyHeight = 0, dwFlags = 0}, MAPI = {count = 0, properties = 0x0}, next = 0x0, FileData = {data = 0x0, size = 0}, IconData = {
data = 0x0, size = 0}}, dateModified = {wYear = 2010, wMonth = 4, wDay = 1, wHour = 16, wMinute = 9, wSecond = 50, wDayOfWeek = 4}, MapiProperties = {count = 54, properties = 0x555557c57f70}, CodePage = {
data = 0x555557dd8a70 "\344\004", size = 8}, OriginalMessageClass = {data = 0x0, size = 0}, Owner = {data = 0x0, size = 0}, SentFor = {data = 0x0, size = 0}, Delegate = {data = 0x0, size = 0}, DateStart = {wYear = 0, wMonth = 0,
wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0}, DateEnd = {wYear = 0, wMonth = 0, wDay = 0, wHour = 0, wMinute = 0, wSecond = 0, wDayOfWeek = 0}, AidOwner = {data = 0x0, size = 0}, RequestRes = 0, Debug = 0, IO = {
InitProc = 0x7ffff6859320 <TNEFMemory_Open>, ReadProc = 0x7ffff6859540 <TNEFMemory_Read>, CloseProc = 0x7ffff6859330 <TNEFMemory_Close>, data = 0x7fffffffacc0}}

(gdb) p *tnef.MapiProperties.properties@54
$8 = {{custom = 0, guid = '\000' <repeats 15 times>, id = 131083, count = 1, namedproperty = 0, propnames = 0x0, data = 0x555556935d80}, {custom = 0, guid = '\000' <repeats 15 times>, id = 2490371, count = 1, namedproperty = 0,
propnames = 0x0, data = 0x555557bc28a0}, {custom = 0, guid = '\000' <repeats 15 times>, id = 2818059, count = 1, namedproperty = 0, propnames = 0x0, data = 0x5555576a4400}, {custom = 0, guid = '\000' <repeats 15 times>,
id = 3014659, count = 1, namedproperty = 0, propnames = 0x0, data = 0x5555570f4410}, {custom = 0, guid = '\000' <repeats 15 times>, id = 3538947, count = 1, namedproperty = 0, propnames = 0x0, data = 0x55555780c950}, {custom = 0,
guid = '\000' <repeats 15 times>, id = 3735616, count = 1, namedproperty = 0, propnames = 0x0, data = 0x5555569f85b0}, {custom = 0, guid = '\000' <repeats 15 times>, id = 3997726, count = 1, namedproperty = 0, propnames = 0x0,
data = 0x555558028de0}, {custom = 0, guid = '\000' <repeats 15 times>, id = 4653314, count = 1, namedproperty = 0, propnames = 0x0, data = 0x5555566a3e30}, {custom = 0, guid = '\000' <repeats 15 times>, id = 7340062, count = 1,
namedproperty = 0, propnames = 0x0, data = 0x555557d81240}, {custom = 0, guid = '\000' <repeats 15 times>, id = 7405826, count = 1, namedproperty = 0, propnames = 0x0, data = 0x555556dab2b0}, {custom = 0,
guid = '\000' <repeats 15 times>, id = 202833931, count = 1, namedproperty = 0, propnames = 0x0, data = 0x55555731add0}, {custom = 0, guid = '\000' <repeats 15 times>, id = 203030558, count = 1, namedproperty = 0, propnames = 0x0,
data = 0x5555577a52a0}, {custom = 0, guid = '\000' <repeats 15 times>, id = 236781598, count = 1, namedproperty = 0, propnames = 0x0, data = 0x555556929980}, {custom = 0, guid = '\000' <repeats 15 times>, id = 269025538, count = 1,
namedproperty = 0, propnames = 0x0, data = 0x555557f01b00}, {custom = 0, guid = '\000' <repeats 15 times>, id = 0, count = 0, namedproperty = 0, propnames = 0x0, data = 0x0} <repeats 40 times>}

Testing with https://github.com/Yeraze/ytnef/tree/master/ytnefprint yields same result:

./ytenfprint winmail.dat
ERROR: invalid alloc size 1217899 at ytnef.c : 529, suspected corruption (exceeded 524288 bytes)
ERROR Parsing MAPI block
ERROR processing file

Seems that embedded image is too big for limit imposed on inline attachments in PREALLOCCHECK macro?
But this assumption is wrong, size is valid. Verbose output:

DEBUG(3/3):Reading 1 blocks of 4 size
DEBUG(2/3):Size = 1219244
DEBUG(2/3):Header says type=0x69003, size=1219244
DEBUG(2/3):Header says type=430083, size=1219244
DEBUG(3/3):Reading 1219244 blocks of 1 size
DEBUG(3/3):Reading 2 blocks of 1 size
DEBUG(3/3):Type id = 000b, Prop id = 0002
DEBUG(3/3):Type id = 0003, Prop id = 0026
DEBUG(3/3):Type id = 000b, Prop id = 002b
DEBUG(3/3):Type id = 0003, Prop id = 002e
DEBUG(3/3):Type id = 0003, Prop id = 0036
DEBUG(3/3):Type id = 0040, Prop id = 0039
DEBUG(3/3):Type id = 001e, Prop id = 003d
DEBUG(3/3):Type id = 0102, Prop id = 0047
DEBUG(3/3):Type id = 001e, Prop id = 0070
DEBUG(3/3): Got a Subject
DEBUG(3/3):Type id = 0102, Prop id = 0071
DEBUG(3/3):Type id = 000b, Prop id = 0c17
DEBUG(3/3):Type id = 001e, Prop id = 0c1a
DEBUG(3/3):Type id = 001e, Prop id = 0e1d
DEBUG(3/3): Got a Subject
DEBUG(3/3):Type id = 0102, Prop id = 1009
ERROR: invalid alloc size 1217899 at ytnef.c : 529, suspected corruption (exceeded 524288 bytes)
ERROR Parsing MAPI block
DEBUG(3/3):Closing file /tmp/tnef-1.4.18/winmail.dat
ERROR processing file

winmail.dat contains an embedded image.

Steps To Reproduce

Create a calendar entry in Outlook 2016, watch it parse mail instead and watch sogod crashing.

Additional Information

winmail.dat unfortunately is confidential and cannot be supplied on public bugtracker. Is there some way to pass on affected winmail.dat privately?

TagsNo tags attached.

Activities

leecher

leecher

2023-04-05 14:11

reporter   ~0016801

Currently I'm working around with:

--- ytnef.c.old 2023-04-05 16:05:21.116680661 +0200
+++ ytnef.c 2023-04-05 16:05:31.720680621 +0200
@@ -526,7 +526,7 @@
// now actual object
if (vl->size != 0) {
SIZECHECK(vl->size);

  • PREALLOCCHECK(vl->size, 524288);
  • PREALLOCCHECK(vl->size, 2097152);
    if (PROP_TYPE(mp->id) == PT_UNICODE) {
    vl->data =(BYTE) to_utf8(vl->size, (char)d);
    if(vl->data == NULL)

But a proper limit should be chosen.
sebastien

sebastien

2023-04-05 15:12

administrator   ~0016802

libytnef is not developed by SOGo, and this issue can't be resolved here

Sebastien
leecher

leecher

2023-04-05 15:34

reporter   ~0016803

Limit still seems to be too low, just got:
ERROR: invalid alloc size 6739472 at ytnef.c : 529, suspected corruption (exceeded 2097152 bytes)

Where to report the error then, as SOGo relies on a broken library?
I saw that the source code of the original library has other limits than the libytnef that ships with SOGo and is fetched from SOGo-Repository, so reporting to original project doesn't seem reasonable.?
sebastien

sebastien

2023-04-05 15:52

administrator   ~0016805

Ok so you mean to update the library in SOGo packages ? What is the libytnef version that fixes this issue ?
leecher

leecher

2023-04-05 15:54

reporter   ~0016806

Just for the sake of completeness, here are other limits that also are too low:

ERROR: invalid alloc size 111 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: invalid alloc size 176 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: Checksum mismatch. Data corruption?:
ERROR: invalid alloc size 104 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block
ERROR: invalid alloc size 121 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: invalid alloc size 121 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: Field with size of 0
ERROR: Field with size of 0
ERROR: Field with size of 0
ERROR: invalid alloc size 110 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block
ERROR: invalid alloc size 110 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block
ERROR: invalid alloc size 110 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block
ERROR: Field with size of 0
ERROR: invalid alloc size 137 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: invalid alloc size 117 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block
ERROR: invalid alloc size 101 at ytnef.c : 309, suspected corruption (exceeded 100 bytes)
ERROR: invalid alloc size 111 at ytnef.c : 611, suspected corruption (exceeded 100 bytes)
ERROR Parsing MAPI block

At least, sogo should check for NULL data pointer to not crash on libytnef0 parsing error:
https://github.com/Alinto/sogo/blob/02f855059babc7e01b25c1cf01d44dae52c777a1/SoObjects/Mailer/SOGoTNEFMailBodyPart.m#L321
leecher

leecher

2023-04-05 15:56

reporter   ~0016807

To my knowledge, there is no version available that fixed the issue, you have to patch it yourself like mentioned above.
What I did:

wget https://packages.sogo.nu/nightly/5/debian/pool/buster/liby/libytnef/libytnef_2.0.orig.tar.gz
tar -xzvf libytnef_2.0.orig.tar.gz
cd ytnef-2.0
./autogen.sh
./configure
vi lib/ytnef.c (patch as mentioned above)
make
make install

I can attach .patch files, if needed
leecher

leecher

2023-04-05 16:01

reporter   ~0016808

Here is a patch with more reasonable limits for affected lines

ytnef.patch (1,052 bytes)    
--- ytnef.c.bak	2023-04-05 16:05:21.116680661 +0200
+++ ytnef.c	2023-04-05 17:59:47.700654467 +0200
@@ -306,7 +306,7 @@
     TNEF->subject.data = NULL;
   }
 
-  PREALLOCCHECK(size, 100);
+  PREALLOCCHECK(size, 1000);
   TNEF->subject.data = calloc(size+1, sizeof(BYTE));
   ALLOCCHECK(TNEF->subject.data);
   TNEF->subject.size = size;
@@ -526,7 +526,7 @@
         // now actual object
         if (vl->size != 0) {
           SIZECHECK(vl->size);
-          PREALLOCCHECK(vl->size, 524288);
+          PREALLOCCHECK(vl->size, 10485760);
           if (PROP_TYPE(mp->id) == PT_UNICODE) {
             vl->data =(BYTE*) to_utf8(vl->size, (char*)d);
             if(vl->data == NULL)
@@ -608,7 +608,7 @@
         if (TNEF->subject.size == 0) {
           int i;
           DEBUG(TNEF->Debug, 3, "Assigning a Subject");
-          PREALLOCCHECK(vl->size, 100);
+          PREALLOCCHECK(vl->size, 1000);
           TNEF->subject.data = calloc(vl->size+1, sizeof(BYTE));
           ALLOCCHECK(TNEF->subject.data);
           TNEF->subject.size = vl->size;
ytnef.patch (1,052 bytes)   
sebastien

sebastien

2023-04-17 13:47

administrator   ~0016835

As I said previously, this code concerns libytnef not SOGo. You need to open an issue in the lib bug tracker and ask them to apply your patch.
Once done you can open a new issue to update libytnef in SOGo repositories.

Sebastien
francis

francis

2023-04-17 20:01

administrator   ~0016840

ytnef has been patched.
sebastien

sebastien

2023-05-15 07:34

administrator   ~0016960

Thanks Francis, we will update packaging :)
qhivert

qhivert

2023-07-13 07:36

administrator   ~0017113

Hello the new version of ytnef 2.1.2 has been published in our repos.
Let me know if there are any problems to install it.

Issue History

Date Modified Username Field Change
2023-04-05 13:52 leecher New Issue
2023-04-05 14:11 leecher Note Added: 0016801
2023-04-05 15:12 sebastien Note Added: 0016802
2023-04-05 15:34 leecher Note Added: 0016803
2023-04-05 15:52 sebastien Note Added: 0016805
2023-04-05 15:54 leecher Note Added: 0016806
2023-04-05 15:56 leecher Note Added: 0016807
2023-04-05 16:01 leecher Note Added: 0016808
2023-04-05 16:01 leecher File Added: ytnef.patch
2023-04-17 13:47 sebastien Note Added: 0016835
2023-04-17 13:48 sebastien Assigned To => sebastien
2023-04-17 13:48 sebastien Status new => resolved
2023-04-17 13:48 sebastien Resolution open => won't fix
2023-04-17 20:01 francis Note Added: 0016840
2023-05-15 07:34 sebastien Status resolved => assigned
2023-05-15 07:34 sebastien Note Added: 0016960
2023-07-13 07:36 qhivert Assigned To sebastien => qhivert
2023-07-13 07:36 qhivert Status assigned => feedback
2023-07-13 07:36 qhivert Note Added: 0017113
2023-07-17 07:13 sebastien Status feedback => resolved
2023-07-17 07:13 sebastien Fixed in Version => 5.9.0
2023-07-17 07:14 sebastien Resolution won't fix => fixed
2023-09-07 13:10 qhivert Status resolved => closed