On Fri, 10 Apr 2020, Chris Roberts via curl-users wrote:
This reply is deliberately top-posted so that everyone can see the full
original post as sent to curl-users as I think curl-library is the better list
for the discussion on what to do next. I'm CC'ing my reply to curl-users too
since Chris posted his first mail there.
Can I first highlight the fact that we have updated the advisory for this CVE
over at https://curl.haxx.se/docs/CVE-2019-15601.html and the update and new
view is very prominent. If you read the *real* and original advisory (ours)
it shouldn't be possible to miss the update.
It's a little curios, but there seems to be no way to official retract or
"take back" a CVE once filed. This would've been retracted if we could.
Since we don't consider this a security problem, I think the (insufficient)
mitigation should be removed. I agree!
----------------
Hi!
I have been running into some issues with the new changes included to
address CVE-2019-15601. After reading through the original CVE, I'm
not sure that I agree it is an issue with curl, nor do I believe it is
an issue which curl should be responsible for addressing. After
reading through some of the archives on this list, I found the thread:
"Warning: using file:// on Windows with curl"
That thread seemed to pretty well sum up my feelings around the change
implemented with regards to the reported CVE. It doesn't really seem
to be an issue with curl, and if it actually is an issue, it seems to
be more of an issue with Windows itself. Any other tool or application
that loads file paths will have the same behavior as described by the
CVE.
The request to revert the change:
https://github.com/curl/curl/commit/1b71bc532bde8621fd3260843f8197182a467ff2
is due to the fact that this change seems to result in an added
restriction to functionality (breaking functionality which was
previously working) without any significant gain. Network paths can
still be accessed in other ways, and as the documentation now states,
if that type of behavior is unacceptable then the file protocol should
be disabled. But for use cases where the file protocol is desired on
Windows, the restriction on paths with a double slash prefix is
breaking the expected behavior (in this case "expected behavior" being
both handling valid Windows paths and curl's previous behavior until
this changeset). Is reverting the behavior back to its original state
something that would be acceptable?
Thanks so much!
- Chris
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
--
/ daniel.haxx.se | Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
