Re: Request to revert Windows path restrictions

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-users
Etiquette:   https://curl.haxx.se/mail/etiquette.html