Tickets :: [#3795] Password protected ZIP attachments

6.0.0-beta1

11/22/25

Summary	Password protected ZIP attachments
Queue	IMP
Queue Version	4.1.1
Type	Bug
State	Not A Bug
Priority	2. Medium
Owners
Requester	ctofur (at) gmail (dot) com
Created	04/19/2006 (7157 days ago)
Due
Updated	04/19/2006 (7157 days ago)
Assigned	04/19/2006 (7157 days ago)
Resolved	04/19/2006 (7157 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

04/19/2006 08:16:46 PM	Michael Slusarz	State ⇒ Not A Bug

04/19/2006 07:53:51 PM	ctofur (at) gmail (dot) com	Comment #5	Reply to this comment
Can you provide an example message (full .eml with headers) for testing? If so please attach it to this ticket. The files in question are sent to us via a sensitve source so unfortunatly I can not send them to you. I did create an example password protected file and compaired it to the file in question which discovered an oddity of the archive. The file has a bad offset, which does not produce an error in viewing or decompression, but does produce an error when viewing the properties of the file. This is an error in relation to the ZIP file being `partially` broken and not an error in HORDE-IMP. --------------Properties of file in question-------------- Archive: C:\Documents and Settings\delete\Desktop\F0071553-S01.zip 315663 bytes 2006-04-19 13:33:00 End central directory record PK0506 (4+18) ========================================== current location of end-of-central-dir record: 315641 (0x0004d0f9) bytes expected location of end-of-central-dir record: 315565 (0x0004d0ad) bytes based on the size of the central directory of 105 and its relative offset of 315460 bytes part number of this part (0000): 1 part number of start of central dir (0000): 1 number of entries in central dir in this part: 1 total number of entries in central dir: 1 size of central dir: 105 (0x00000069) bytes relative offset of central dir: 315460 (0x0004d044) bytes zipfile comment length: 0 Current Location part 1 offset 315460 Central directory entry PK0102 (4+42): #1 ====================================== part number in which file begins (65535): 65536 relative offset of local header: 4294967295 (0xffffffff) bytes version made by operating system (00): MS-DOS, OS/2, NT FAT version made by zip software (45): 4.5 operat. system version needed to extract (00): MS-DOS, OS/2, NT FAT unzip software version needed to extract (45): 4.5 general purpose bit flag (0x0009) (bit 15..0): 0000.0000 0000.1001 file security status (bit 0): encrypted extended local header (bit 3): yes compression method (99): AES encryption file last modified on (0x00003492 0x00005d14): 2006-04-18 11:40:40 32-bit CRC value: 0x00000000 compressed size: 4294967295 bytes uncompressed size: 4294967295 bytes length of filename: 16 characters length of extra field: 43 bytes length of file comment: 0 characters internal file attributes: 0x0000 apparent file type: binary external file attributes: 0x00000020 non-MSDOS external file attributes: 0x000000 MS-DOS file attributes (0x20): arc Current Location part 1 offset 315506 filename:F0071553-S01.txt Current Location part 1 offset 315522 extra field 0x0001 (ZIP64 Tag), 4 header and 28 data bytes: 70 28 12 00 00 00 00 00 d7 cf 04 00 00 00 00 00 p(.............. 00 00 00 00 00 00 00 00 00 00 00 00 ............ ZIP64 Tag Value(s): Value #1: 1190000 Value #2: 315351 Value #3: 0 Part No: 1 extra field 0x9901 (AES Encryption Tag), 4 header and 7 data bytes: 02 00 41 45 03 08 00 ..AE... Encryption Tag Version: AE-2 Encryption Key Bits: 256 Compression Method (08): deflated Compression Sub-Type (deflation): normal note: didn't find end-of-central-dir signature at end of central dir. Possible cause: file transfer error Current Location part 1 offset 0 Local directory entry PK0304 (4+26): #1 ------------------------------------ operat. system version needed to extract (00): MS-DOS, OS/2, NT FAT unzip software version needed to extract (45): 4.5 general purpose bit flag (0x0009) (bit 15..0): 0000.0000 0000.1001 file security status (bit 0): encrypted extended local header (bit 3): yes compression method (99): AES encryption file last modified on (0x00003492 0x00005d14): 2006-04-18 11:40:40 32-bit CRC value: 0x00000000 compressed size: 4294967295 bytes uncompressed size: 4294967295 bytes note: "real" crc and sizes are in the extended local header length of filename: 16 characters length of extra field: 43 bytes caution: value of lrec.csize (compressed size) changed from -1 to 315351 caution: value of lrec.ucsize (uncompressed size) changed from -1 to 1190000 Current Location part 1 offset 30 filename:F0071553-S01.txt Current Location part 1 offset 46 extra field 0x0001 (ZIP64 Tag), 4 header and 28 data bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 ............ ZIP64 Tag Value(s): Value #1: 0 Value #2: 0 Value #3: 0 Part No: 1 extra field 0x9901 (AES Encryption Tag), 4 header and 7 data bytes: 02 00 41 45 03 08 00 ..AE... Encryption Tag Version: AE-2 Encryption Key Bits: 256 Compression Method (08): deflated Compression Sub-Type (deflation): normal Current Location part 1 offset 89 testing: F0071553-S01.txt OK Error in file #1: bad Zip file offset (Error extended local header signature not found): disk #1 offset: 0

04/19/2006 06:48:00 PM	Chuck Hagenbuch	Comment #4	Reply to this comment
Can you provide an example message (full .eml with headers) for testing? If so please attach it to this ticket.

04/19/2006 06:31:51 PM	ctofur (at) gmail (dot) com	Comment #3	Reply to this comment
NeIther file can be sucessfully downloaded because the archive becomes corrupt when saved to disk by IMP. This is a seperate issue. Can you be any more specific about what happens here? Are there errors in the file, etc.? Saving either file type, "application/stream" or "application/zip" to disk and opening with WinZip produces an error "Does not seem to be a valid archive". Confirming the file is valid, I used Thuderbird to save the same file attachment. and it opens in WinZip properly. For both methods of obtaining the attachment, I "save file to disk" before opening with a decompression program, WinZip in this case. The attachment file differs when saved to disk through Thunderbird as opposed to a 1 byte larger file size when saved to disk through IMP No errors are produced in horde.log or apache logs. Enviroment: Fedora 4, Php 5.1.2

04/19/2006 05:14:01 PM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
An attached password protected ZIP file is represented as 2 files with different file types. It's attached as application/octet-stream (technically "correct" but not useful); we guess that it's a zipfile based on the filename. This representation is false becuase there is only one(1) file attached No. This is how any attachment is represented when its mime type has to be guessed as a useful one is not provided by the email sender. NeIther file can be sucessfully downloaded because the archive becomes corrupt when saved to disk by IMP. This is a seperate issue. Can you be any more specific about what happens here? Are there errors in the file, etc.?

04/19/2006 05:05:53 PM	ctofur (at) gmail (dot) com	Comment #1 State ⇒ Unconfirmed Priority ⇒ 2. Medium Type ⇒ Bug Summary ⇒ Password protected ZIP attachments Queue ⇒ IMP	Reply to this comment
An attached password protected ZIP file is represented as 2 files with different file types. application/octet-stream application/zip This representation is false becuase there is only one(1) file attached NeIther file can be sucessfully downloaded because the archive becomes corrupt when saved to disk by IMP.