GNU tar extract-path bypass vulnerability analysis CVE-2 0 1 6-6 3 2 1-the vulnerability warning-the black bar safety net

ID MYHACK58:62201680979
Type myhack58
Reporter 佚名
Modified 2016-11-08T00:00:00


0x00 summary The GNU tar documentation Management Command is a linux system used a packaged, compressed command, the CSS(FSC1V Cyber Security Services team of researcher Harry Sintonen discovered that the tar command in decompress the When the presence of a path name bypass vulnerability, in some specific scenarios, the use of this vulnerability may even lead to remote code execution. The vulnerability to get the CVE number CVE-2 0 1 6-6 3 2 to 1. 0x01 details If an attacker exploit the vulnerability, the carefully constructed a special package of documents, the victim in the use of the tar command to unzip operation, whether specified on the command line of the target path is and what can be the attacker to bypass, and will submit the prepared document and the directory to unzip to the attacker-specified place. By this way, can a specific file be overwritten and rewritten, if the decompression operation is a privileged identity, such as the root account, then you can overwrite the file content is more also more important, in the worst scenario, the attacker can use this vulnerability on the system full control as root under the remote code. This vulnerability ranges from GNU tar 1.14 to 1.29 (contains 1. 2 9), The impact of including Red Hat,Alphine Linux, Red Star OS, and all other use GNU tar on Linux system. Next, We from tar official online download 1. 2 9 of version for source code audit, the[download to] is. In lib/paxnames. c file, there is a safer_name_suffix()function, if absolute_names variable is 0, Then the file name, the file system prefix to remove, and will for file_name carried out some security checks. if ( absolute_names ) p = file_name; else{ / Skip file system prefixes, leading file name components that contain "..", and leading slashes. / size_t prefix_len = FILE_SYSTEM_PREFIX_LEN( file_name ); for ( p = file_name + prefix_len; p; ) { if ( p[0] == '.' && p[1] == '.' && (ISSLASH( p[2] ) || ! p[2]) ) prefix_len = p + 2 - file_name; do { char c = p++; if ( ISSLASH( c ) ) break; } while ( p ); } for ( p = file_name + prefix_len; ISSLASH( p ); p++ ) continue; prefix_len = p - file_name; if ( prefix_len ) { const char prefix; if ( hash_string_insert_prefix( &prefix_table[link_target], file_name, prefix_len, &prefix ) ) { static char const *const diagnostic[] = { N_( "Removing leading %s' from member names" ), N_( "Removing leading%s' from hard link targets" ) }; WARN( (0, 0, _( diagnostic[link_target] ), prefix) ); } } } //... return p ; From the above code can be read out, after safer_name_suffix after the operation, whether specified on the command line of the target path is what, as long as the filename contains"../", then the“../”sequence after the part of the file name and your current working directory becomes the relative relationship. This vulnerability of the historical situation is somewhat complex, 1. In 1 3. 1 2. 1 9 9 9 the commit before the compressed file entries by“../”string directly, bypassing the decompression path problem, and write the file to any location. 2. In 1 3. 1 2. 1 9 9 9 a commit after the code has some fixes, will warn that the compressed file the file name in there..the strings, and will jump joust processing these files.

[1] [2] [3] next