It was found that curl can be fooled into writing a zero byte out of bounds. This bug can trigger when curl is told to work on an FTP URL, with the setting to only issue a single CWD command (`--ftp-method singlecwd` or the libcurl alternative `CURLOPT_FTP_FILEMETHOD`). curl then URL-decodes the given path, calls strlen() on the result and deducts the length of the file name part to find the end of the directory within the buffer. It then writes a zero byte on that index, in a buffer allocated on the heap. If the directory part of the URL contains a "%00" sequence, the directory length might end up shorter than the file name path, making the calculation `size_t index = directory_len - filepart_len` end up with a huge index variable for where the zero byte gets stored: `heap_buffer[index] = 0`. On several architectures that huge index will wrap and work as a negative value, thus overwriting memory *before* the intended heap buffer. By using different file part lengths and putting %00 in different places in the URL, an attacker that can control what paths a curl-using application uses can write that zero byte on different indexes.
Acknowledgments: Name: the Curl project Upstream: Duy Phan Thanh
Created attachment 1405333 [details] upstream patch
Mitigation: Preventing application from using non-default CURLOPT_FTP_FILEMETHOD will avoid triggering the vulnerable code.
External References: https://curl.haxx.se/docs/adv_2018-9cd6.html
Created mingw-curl tracking bugs for this issue: Affects: fedora-all [bug 1555207] Created curl tracking bugs for this issue: Affects: fedora-all [bug 1555209] Created mingw-curl tracking bugs for this issue: Affects: epel-7 [bug 1555208]
Upstream commit: FTP: reject path components with control codes https://github.com/curl/curl/commit/535432c0ad
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:3157 https://access.redhat.com/errata/RHSA-2018:3157
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.4 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Via RHSA-2018:3558 https://access.redhat.com/errata/RHSA-2018:3558
I have used 7.35 version ... In my version following code compared to diff more mismatches ... lstArg = NULL; if((data->set.ftp_filemethod == FTPFILE_NOCWD) && data->state.path && data->state.path[0] && strchr(data->state.path,'/')) { lstArg = strdup(data->state.path); if(!lstArg) return CURLE_OUT_OF_MEMORY; /* Check if path does not end with /, as then we cut off the file part */ if(lstArg[strlen(lstArg) - 1] != '/') { /* chop off the file part if format is dir/dir/file */ slashPos = strrchr(lstArg,'/'); if(slashPos) *(slashPos+1) = '\0'; } } cmd = aprintf( "%s%s%s", data->set.str[STRING_CUSTOMREQUEST]? data->set.str[STRING_CUSTOMREQUEST]: (data->set.ftp_list_only?"NLST":"LIST"), lstArg? " ": "", lstArg? lstArg: "" ); Note: Curl_urldecode() not added in this ftp_state_list() in 7.35 ....will you please clarify me
I am not sure what you are trying to say but this is the patch that was applied on RHEL-7 to fix this CVE: https://git.centos.org/rpms/curl/blob/f0f8d7eb/f/SOURCES/0063-curl-7.29.0-CVE-2018-1000120.patch
Kamil, we have used curl 7.35.0 version and founded some vulnerabilities including "CVE-2018-1000120" Here patches or diff available "https://bugzilla.redhat.com/attachment.cgi?id=1405333&action=diff" ------> for CVE-2018-1000120 My curl 7.35.0 lib/ftp.c Curl_urldecode() calling function not there in ftp_state_list(struct connectdata *conn) But here the diff "https://bugzilla.redhat.com/attachment.cgi?id=1405333&action=diff" Curl_urldecode() changes the arguement value as "False" My code 7.35.0 lib/ftp.c =========================== static CURLcode ftp_state_list(struct connectdata *conn) { CURLcode result = CURLE_OK; struct SessionHandle *data = conn->data; /* If this output is to be machine-parsed, the NLST command might be better to use, since the LIST command output is not specified or standard in any way. It has turned out that the NLST list output is not the same on all servers either... */ /* if FTPFILE_NOCWD was specified, we are currently in the user's home directory, so we should add the path as argument for the LIST / NLST / or custom command. Whether the server will support this, is uncertain. The other ftp_filemethods will CWD into dir/dir/ first and then just do LIST (in that case: nothing to do here) */ char *cmd,*lstArg,*slashPos; lstArg = NULL; if((data->set.ftp_filemethod == FTPFILE_NOCWD) && data->state.path && data->state.path[0] && strchr(data->state.path,'/')) { lstArg = strdup(data->state.path); if(!lstArg) return CURLE_OUT_OF_MEMORY; /* Check if path does not end with /, as then we cut off the file part */ if(lstArg[strlen(lstArg) - 1] != '/') { /* chop off the file part if format is dir/dir/file */ slashPos = strrchr(lstArg,'/'); if(slashPos) *(slashPos+1) = '\0'; } } cmd = aprintf( "%s%s%s", data->set.str[STRING_CUSTOMREQUEST]? data->set.str[STRING_CUSTOMREQUEST]: (data->set.ftp_list_only?"NLST":"LIST"), lstArg? " ": "", lstArg? lstArg: "" ); if(!cmd) { if(lstArg) free(lstArg); return CURLE_OUT_OF_MEMORY; } result = Curl_pp_sendf(&conn->proto.ftpc.pp, "%s", cmd); if(lstArg) free(lstArg); free(cmd); if(result != CURLE_OK) return result; state(conn, FTP_LIST); return result; } ================================================================================================================ Just compare the my code with diff given by the link (in my comments above) ..... where Curl_urldecode() here .... How to apply this patch....
The attachment contains the original upstream patch that applies on curl 7.58.0. It is not surprising that the patch does not cleanly apply on curl 7.35.0. In comment #15 I pointed you to the actual patch that Red Hat applied on top of curl 7.29.0, which RHEL-7 packages of curl are based. Feel free to use any of the patches as you like. As far as I know, curl 7.35.0 is not used in any products currently supported by Red Hat. So we are not going to provide patches for this upstream release of curl. That is not our business. Thanks for understanding!
This issue has been addressed in the following products: JBoss Core Services Apache HTTP Server 2.4.29 SP2 Via RHSA-2019:1543 https://access.redhat.com/errata/RHSA-2019:1543
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.5 Extended Update Support Via RHSA-2020:0544 https://access.redhat.com/errata/RHSA-2020:0544
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Advanced Update Support Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions Red Hat Enterprise Linux 7.4 Telco Extended Update Support Via RHSA-2020:0594 https://access.redhat.com/errata/RHSA-2020:0594