Helloall!
As stated in the subject, I suggest that gopher:// gets removed from the
default list ofallowedprotocolsforredirects.
For context, Gopher is a legacy protocol from the early days of WWW that
sees very little usage these days.
In case of vulnerabilities such as Server-Side Request Forgery - SSRF,
where the backend of a webserviceisforcedtomakerequestto
arbitrary hosts (usually internal services) when user-provided URLs are
passed to libcurl-based clients, gopher://greatlybroadenstheattack
surface because of its generic nature. It simply opens a TCP connection
and sends a payload that is fully contained in the gopher URI.
For more information about these issues, please refer to [1][2].
An example ofwhatanadversarycandowithgopher://
lookslikethefollowing:gopher://localhost:6379/_FLUSHALL.
What this
willdoifthebackendusestheCURLOPT_FOLLOWLOCATIONandthedefaultredir_protocols,
is drop all keys in a Redis instance running on localhost.
CurlcurrentlyfollowsredirectsfromHTTPtoall(supported)
protocolsexceptSMB, fileandtheirTLScounterparts.
SMB and file are excluded because an adversary could overwrite files on
the filesystem or leak their contents if the adversary are able to read
the response.
On the other hand,CURPROTO_GOPHERisincludedintheredir_protocolsbydefault.
As briefly described above, it is trivial to encode text-based protocols
(e.g. Redis protocol, SMTP) oraccess MySQL services through gopher://.
An adversary can even bypass the "safety" of REST APIs by forging
POST/PUT/PATCH/DELETE HTTP requests and smugglethemingopher:// URIs.
Tobefair,
theofficialdocumentationaroundthisissueisinfactaccurateandinformstheuseraboutpotentialpitfallsinthe"Redirects"
section
ofhttps://curl.haxx.se/libcurl/security.html, inthe meantimeI think a
slight improvement would be to also provide a
link to this section
underhttps://curl.haxx.se/libcurl/c/CURLOPT_FOLLOWLOCATION.html. Despite
that, in practice people tend to
use CURLOPT_FOLLOWLOCATION to save time and some code, rather than
implement their own redirect logic (which wouldn't necessarily be more
secure).
In addition, higher level bindings may not expose all functionality
needed to manipulateCURLOPT_REDIR_PROTOCOLS/CURLOPT_PROTOCOLS.
See for instance curb, a popular set oflibcurl bindings for Ruby.
Although this is not curl's issue per se and it should be fixed in curb
itself,
removing Gopher from the default list, can greatly help minimize the
exploitation surface there and in other occurrences of this issue.
Overall, the tradeoff between the inconvenience caused by removing
CURLPROTO_GOPHERfromredir_protocols(considering
it's seeing very little usage nowadays) versus the importance it holds
for exploitation is in my eyesin favor of the latter.
Therefore, I would propose to remove CURLPROTO_GOPHERfrom the default
value of CURLOPT_REDIR_PROTOCOLS in the same vein as file:// and smb://,
as it
can greatly assist adversaries in exploitation, and in thiscase,
readingtheresponseisnotrequiredtosuccessfullyexploitthis.
I would be happy to preparea pull request if we agree on this.
P.S: The same holds for other protocols such as CURLPROTO_DICT
Regards,
Linos
--
[1]:https://www.acunetix.com/blog/articles/server-side-request-forgery-vulnerability/
[2]:https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery#gopher
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
