SEC Consult Vulnerability Lab Security Advisory < 20180207-0 > ======================================================================= title: Multiple buffer overflow vulnerabilities product: InfoZip UnZip vulnerable version: UnZip <= 6.00 / UnZip <= 6.1c22 fixed version: 6.10c23 CVE number: CVE-2018-1000031,CVE-2018-1000032,CVE-2018-1000033 CVE-2018-1000034,CVE-2018-1000035 impact: high homepage: http://www.info-zip.org/UnZip.html found: 2017-11-03 by: R. Freingruber (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "UnZip is an extraction utility for archives compressed in .zip format (also called "zipfiles"). Although highly compatible both with PKWARE's PKZIP and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, our primary objectives have been portability and non-MSDOS functionality. UnZip will list, test, or extract files from a .zip archive, commonly found on MS-DOS systems. The default behavior (with no options) is to extract into the current directory (and subdirectories below it) all files from the specified zipfile." Source: http://www.info-zip.org/UnZip.html InfoZip's UnZip is used as default utility for uncompressing ZIP archives on nearly all *nix systems. It gets shipped with many commerical products on Windows to provide (un)compressing functionality as well. Business recommendation: ------------------------ InfoZip Unzip should be updated to the latest available version. Vulnerability overview/description: ----------------------------------- 1) Heap-based buffer overflow in password protected ZIP archives (CVE-2018-1000035) InfoZip's UnZip suffers from a heap-based buffer overflow when uncompressing password protected ZIP archives. An attacker can exploit this vulnerability to overwrite heap chunks to get arbitrary code execution on the target system. For newer builds the risk for this vulnerability is partially mitigated because modern compilers automatically replace unsafe functions with length checking variants of the same function (for example sprintf gets replaced by sprintf_chk). This is done by the compiler at locations were the length of the destination buffer can be calculated. Nevertheless, it must be mentioned that UnZip is used on many systems including older systems or on exotic architectures on which this protection is not in place. Moreover, pre-compiled binaries which can be found on the internet lack the protection because the last major release of InfoZip's UnZip was in 2009 and compilers didn't enable this protection per default at that time. The required compiler flags are also not set in the Makefile of UnZip. Compiled applications are therefore only protected if the used compiler has this protection enabled per default which is only the case with modern compilers. To trigger this vulnerability (and the following) it's enough to uncompress a manipulated ZIP archive. Any of the following invocations can be used to trigger and abuse the vulnerabilities: >unzip malicious.zip >unzip -p malicious.zip >unzip -t malicious.zip 2) Heap-based out-of-bounds write (CVE-2018-1000031) This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip). InfoZip's UnZip suffers from a heap-based out-of-bounds write if the archive filename does not contain a .zip suffix. 3) Heap/BSS-based buffer overflow (Bypass of CVE-2015-1315) (CVE-2018-1000032) This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip). InfoZip's UnZip suffers from a heap/BSS-based buffer-overflow which can be used to write null-bytes out-of-bound when converting attacker-controlled strings to the local charset. 4) Heap out-of-bounds access in ef_scan_for_stream (CVE-2018-1000033) This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip). InfoZip's UnZip suffers from a heap out-of-bounds access vulnerability. 5) Multiple vulnerabilities in the LZMA compression algorithm (CVE-2018-1000034) This vulnerability only affects UnZip 6.1c22 (next beta version of UnZip). InfoZip's UnZip suffers from multiple vulnerabilities in the LZMA implementation. Various crash dumps have been supplied to the vendor but no further analysis has been performed. Proof of concept: ----------------- 1) Heap-based buffer overflow in password protected ZIP archives (CVE-2018-1000035) Unzipping a malicious archive results in the following output: (On Ubuntu 16.04 with UnZip 6.0 which was installed via aptitude install unzip) *** buffer overflow detected ***: unzip terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x**)[0x************] /lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************] /lib/x86_64-linux-gnu/libc.so.6(+0x*****)[0x************] /lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x**)[0x************] /lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0x**)[0x************] /lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x**)[0x************] /lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x**)[0x************] unzip[0x40c02b] unzip[0x4049ac] unzip[0x40762c] unzip[0x409b60] unzip[0x411175] unzip[0x411bdf] unzip[0x404191] Function names can be mapped to the backtrace by compiling the application with debug symbols: (gdb) backtrace #0 0x000000000040c706 in UzpPassword () #1 0x00000000004043ce in decrypt () #2 0x000000000040731c in extract_or_test_entrylist () #3 0x00000000004094af in extract_or_test_files () #4 0x00000000004149a5 in do_seekable () #5 0x000000000041540f in process_zipfiles () #6 0x0000000000403921 in unzip () The vulnerability resides inside the UzpPassword function in the following code snippet (file ./fileio.c): [1591] if ((prompt = (char *)malloc(2*FILNAMSIZ + 15)) != (char *)NULL) { [1592] sprintf(prompt, LoadFarString(PasswPrompt), [1593] FnFilter1(zfn), FnFilter2(efn)); ... [1595] } The allocation at line 1591 allocates a fixed size buffer and then writes into it at line 1592. It writes the following format string (PasswPrompt) into the buffer: "[%s] %s password: " This string has a length of 15 including the null-termination which explains the +15 in the allocation. The developer allocated 2*FILENAMESIZ which corresponds to 2 * PATH_MAX for the two format strings (zfn and efn). zfn is the archive filename and can therefore not exceed PATH_MAX. efn is the current processed filename inside the ZIP archive which should typically be smaller than PATH_MAX for normal files. However, since an attacker can manipulate the archive file the name can arbitrarily be chosen which leads to a heap-based buffer overflow. As already mentioned, modern compilers replace unsafe functions with safe alternatives as a defense in depth mechanism. This feature is called BOSC (Built-in object size checking) and is part of the FORTIFY_SOURCE=2 protection. The following link shows the source code (and vulnerability) inside the Ubuntu package: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/unzip/trusty-updates/view/head:/fileio.c#L1593 By checking the installed compiled binary the following code can be seen: (UnZip 6.0 from Ubuntu 16.04) 0x40bfc6: mov edi,0x200f 0x40bfcb: mov r13,r8 0x40bfce: mov QWORD PTR [rsp+0x8],r9 0x40bfd3: call 0x401d30 <malloc@plt> ... 0x40c01a: mov edx,0x200f 0x40c01f: mov esi,0x1 0x40c024: xor eax,eax 0x40c026: call 0x401f40 <__sprintf_chk@plt> The code allocates 0x200f (=4096*2 + 15) bytes but the unsafe sprintf function was replaced with the length-checking sprintf_chk() function which receives as argument the size of the buffer (0x200f at address 0x40c01a). The risk is therefore mitigated on Ubuntu (and other modern operating systems), at least with the currently used compiler default flags. However, many pre-compiled UnZip binaries can be found on the internet which are not compiled with this protection. For example, the following three links are the first links which can be found when searching for InfoZip UnZIP on the internet and which contain unprotected binaries: http://gnuwin32.sourceforge.net/packages/unzip.htm https://oss.oracle.com/el4/unzip/unzip.tar http://www.willus.com/archive/zip64/ 2) Heap-based out-of-bounds write (CVE-2018-1000031) When uncompressing ZIP archives the following code gets executed (file fileio.c:345 function set_zipfn_sgmnt_name() in UnZip 6.1c22): #define SGMNT_NAME_BOOST 8 ... if (G.zipfn_sgmnt == NULL) { [1] G.zipfn_sgmnt_size = (int)strlen(G.zipfn)+ SGMNT_NAME_BOOST; if ((G.zipfn_sgmnt = izu_malloc(G.zipfn_sgmnt_size)) == NULL) ... [2] zfstrcpy(G.zipfn_sgmnt, G.zipfn); /* Expect to find ".zXX" at the end of the segment file name. */ [3] sufx_len = IZ_MAX( 0, ((int)strlen(G.zipfn_sgmnt)- 4)); [4] suffix = G.zipfn_sgmnt+ sufx_len; ... else // No .zip extension { [5] zfstrcpy( (suffix+ sufx_len), ZSUFX); [6] suffix += sufx_len+ 2; } /* Insert the next segment number into the file name (G.zipfn_sgmnt). */ [7] sprintf(suffix, "%02d", (sgmnt_nr+ 1)); G.zipfn is the filename / path of the archive file. Line [1] allocates space for this name plus 8 (SGMNT_NAME_BOOST). Line [2] copies the name. [3] and [4] calculate the end address minus 4 which should point to a suffix if one is present. After [4] the variable suffix already points to this address. However, line [5] adds sufx_len again to suffix, the write target is therefore the base address + 2*(allocation_length - 4) but the buffer can only hold allocation_len bytes. Line [7] is another out-of-bounds write because of line [6]. Memory trace of the crash: #1 0xf7af3c2f in memcpy (/usr/lib/i386-linux-gnu/libasan.so.2+0x8ac2f) #2 0x80969be in set_zipfn_sgmnt_name unzip610c22/fileio.c:424 #3 0x808eb82 in find_local_header unzip610c22/extract.c:4469 #4 0x808eb82 in extract_or_test_entrylist unzip610c22/extract.c:4745 #5 0x808eb82 in extract_or_test_files unzip610c22/extract.c:5698 #6 0x80cf6ca in extract_archive_seekable unzip610c22/process.c:1314 #7 0x80cf6ca in extract_archive unzip610c22/process.c:1465 #8 0x80d5676 in process_zipfiles unzip610c22/process.c:2033 #9 0x80636a2 in unzip unzip610c22/unzip.c:1840 #10 0x804a5b6 in main unzip610c22/unzip.c:1280 #11 0xf78cb636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636) Please note that this vulnerability must not lead to a crash. If the overwritten memory is not used, the program works as expected. 3) Heap/BSS-based buffer overflow (Bypass of CVE-2015-1315) (CVE-2018-1000032) During parsing ZIP archives the function charset_to_intern() can be called (unix/Unix.c:2427) with the "string" argument pointing to attacker controlled data. This function converts the string in-place to another charset (string is an INOUT argument). The following code performs this task in the function: [1] slen = strlen(string); [2] s = string; [3] dlen = buflen = 2 * slen; [4] d = buf = izu_malloc(buflen + 1); if (d) { [5] memset( buf, 0, buflen); /* 2015-02-12 William Robinet, SMS. CVE-2015-1315. * Added FILNAMSIZ check to avoid buffer overflow. Better would * be to pass in an actual destination buffer size. */ [6] if ((iconv(cd, &s, &slen, &d, &dlen) != (size_t)-1) && [7] (strlen(buf) < FILNAMSIZ)) { [8] strncpy(string, buf, buflen); } izu_free(buf); } The input string pointer is stored in the variable "string" and "s" (see [2]). Line [6] tries to convert the input ("s") via iconv() to another charset. The destination is "d" / "buf" (see line [4]). This destination buffer has a size of two times the input length plus one ([3]). The first problem can be found in line [5] which just initializes "buflen" bytes and not "buflen+1" bytes. Consider the input string is empty, therefore slen=0. This will allocate 1 byte at line [4] because of the +1. However, [5] calls memset with buflen=0 which leaves the 1-byte buffer uninitialized. In line [7] strlen() can therefore access data out-of-bounds if the uninitialized byte does not contain a null-byte. This flaw is not critical because it can just crash the application. Nevertheless, it should be fixed. The second problem is harder to identify. The function do_string() is used to parse strings from ZIP archives. If the option DS_FN gets passed, the string is written into the filename[] array from the global variable G. The code at extract.c:5584 (in the function extract_or_test_files()) calls for example this function with this option: do_string(__G__ G.crec.filename_length, DS_FN)) != PK_COOL) Inside do_string() the following code can be found (fileio.c:3225): Ext_ASCII_TO_Native(G.filename, G.pInfo->hostnum, G.pInfo->hostver, G.pInfo->HasUxAtt, (option == DS_FN_L)); The "Ext_ASCII_TO_Native" is a define which redirects to charset_to_intern(). The first argument (G.filename in this case) is passed to this function and can be accessed with the "string" argument in the above code. At line [6] iconv() is used to convert the input string from one charset (e.g.: CP850) to another (e.g.: UTF-8). Therefore "buf" contains the converted string after this call. With line [8] this converted string should be copied over the original location from the argument (G.filename in our case). The strncpy at [8] limits the number of written characters to buflen. Because of [3] buflen is two times the input length and therefore a buffer overflow can happen (the real size of the input buffer is not passed to the function). This vulnerability was CVE-2015-1315 and an additional check was added to prevent this buffer overflow. The additional check at [7] checks the length of the converted string with this line: [7] (strlen(buf) < FILNAMSIZ)) Only if this check is passed the code at [8] gets executed: [8] strncpy(string, buf, buflen); This should logically limit the number of bytes which can be written to be smaller than FILNAMSIZ (even if the wrong, higher number, is passed to strncpy). For example: G.filename is defined in globals.h:372 (inside the Uz_Globs struct): char filename[FILNAMSIZ]; FILNAMSIZ is defined in unzpriv.h and is equal to PATH_MAX (4096). Therefore, filename can hold a buffer of size 4096. When the above code gets executed and G.filename gets converted to another charset, this code gets executed: [6] if ((iconv(cd, &s, &slen, &d, &dlen) != (size_t)-1) && [7] (strlen(buf) < FILNAMSIZ)) { [8] strncpy(string, buf, buflen); } Let's assume that our input string had a length of 2940. Because of [3] buflen will be 5880 (2*2940). That means if [8] is reached a strncpy with a limit of 5880 gets executed, however, the destination buffer only has a size of 4096 bytes (G.filename). The check at [7] should protect against this because if strlen(buf) (the source from strncpy) is bigger or equal than FILNAMSIZ (4096), the strncpy does not get executed. And since strncpy just copies until the first null-byte, it should just be possible to copy at maximum strlen(buf) bytes in this strncpy. This assumption is wrong though. Strncpy() always writes n bytes - in the above case it will always write 5880 bytes and therefore a buffer overflow will always occur. This behavior can be found in the manpage of strncpy: "If the length of src is less than n, strncpy() writes additional null bytes to dest to ensure that a total of n bytes are written." The strncpy can therefore be used to write null-bytes out-of-bound in the BSS or heap segment. Since the input string length is under attacker control, the write length can be manipulated. That means that an attacker can perform a partial overwrite to exploit this vulnerability. For example, the attacker can overwrite data in the Uz_Globs struct after G.filename with null-bytes. One attack target can be heap addresses. They can be partially overwritten (lower bytes) to change the heap address to point to an attacker controlled heap chunk to get control over the data and therefore also over the execution. 4) Heap out-of-bounds access in ef_scan_for_stream (CVE-2018-1000033) The first two arguments to the function ef_scan_for_stream() (extract.c:1167) are: ef_ptr and ef_len. This function is for example called at: extract.c:4795 sts = ef_scan_for_stream( G.extra_field, (long)G.lrec.extra_field_length, &btmp_siz, &bitmap[ 0], &xlhdr, &cmnt); The second argument (ef_len) stores the length / size of the first argument (ef_ptr) and access checks must be performed to ensure that no out-of-bounds access occurs. Code line extract.c:1233 can access data out-of-bounds because length checks are missing: bitmap = *(ef_ptr+ (data_byte++)); Debugger output: Program received signal SIGSEGV, Segmentation fault. ef_scan_for_stream (...) at extract.c:1233 1233 bitmap = *(ef_ptr+ (data_byte++)); (gdb) print /x ef_ptr $10 = 0x7ffff7ed5f3b (gdb) print /x data_byte $11 = 0xc6 (gdb) print /x ef_len $12 = 0xc5 5) Multiple vulnerabilities in the LZMA compression algorithm (CVE-2018-1000034) Invalid access attempts can occur at: szip/LzmaDec.c:275 - IF_BIT_0(probLen) szip/LzmaDec.c:242 - IF_BIT_0(prob) szip/LzmaDec.c:217 - IF_BIT_0(prob) szip/LzmaDec.c:299 - TREE_6_DECODE(prob, distance); szip/LzmaDec.c:189 - GET_BIT2(probLit, symbol, offs &= ~bit, offs &= bit) szip/LzmaDec.c:264 - IF_BIT_0(probLen) szip/LzmaDec.c:201 - IF_BIT_0(prob) szip/LzmaDec.c:213 - IF_BIT_0(prob) szip/LzmaDec.c:290 - TREE_DECODE(probLen, limit, len); szip/LzmaDec.c:233 - IF_BIT_0(prob) No further analysis has been performed on the LZMA compression code. The vendor will remove this code entirely in future releases. Vulnerable / tested versions: ----------------------------- Versions before and including 6.10 / 6.1c22 of InfoZip's Unzip have been found to be vulnerable. Version 6.0 was the latest major release at the time the security vulnerabilities were discovered. The next beta version is 6.1c22 which has been tested as well. Vendor contact timeline: ------------------------ 2017-11-03: Vulnerability 1 identified, further internal analysis 2017-11-06: Attempt to contact the developers via bug report page 2017-11-10: Initial contact to the developer via sms@antinode.info 2017-11-10: Information from the main developer: A new beta version (6.1c22), which will be released soon, incorporates some security features. A link to the new beta version was provided. 2017-11-12: Sending encrypted advisory to sms@antinode.info Informed developer of the latest possible release date (2017-12-30). 2017-11-13: Developer confirms the vulnerability and notes that it should be easy to fix. The developer asks for a notification if vulnerabilities are found in version 6.1c22. 2017-11-21: Vulnerability 2-5 in UnZip 6.1c22 identified, the updated encrypted advisory with crash files was sent to the developer. 2017-11-23: Developer confirmed the e-mail containing the updated advisory. 2017-12-06: Asking the developer when an update will be available and to coordinate the release of the advisory together. 2017-12-11: E-mail from the developer: All vulnerabilities (except LZMA vulnerabilities) are fixed in version 6.1c23. A link to the new version was provided. The LZMA code / feature will likely be disabled until a better solution is available. 2017-12-13: Asking the developer for a coordinated release of the advisory. 2018-01-04: Informing the developer about the changed release date because of the holidays. Distribution mailing lists will be informed on 2018-01-17, the advisory will be released about one week after that. Asking the developer for an InfoZip version with LZMA disabled. 2018-01-10: Informing the developer again that the current solution is to upgrade to version 6.10c23 which still contains the LZMA vulnerabilities and if a version without LZMA is available. 2018-01-17: Informing distros@vs.openwall.org about the upcoming advisory. 2018-02-01: Received CVE numbers. 2018-02-07: Publication of the advisory Solution: --------- Update to version 6.10c23: http://antinode.info/ftp/info-zip/unzip610c23.zip Please note that the LZMA vulnerabilities are not yet fixed in this version. Workaround: ----------- None Advisory URL: ------------- https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://www.sec-consult.com/en/career/index.html Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://www.sec-consult.com/en/contact/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF R. Freingruber @2018