zap.Open: Invalidate relative path roots #1398
Conversation
Add validation to ensure file schema paths passed to zap.Open are absolute since this is already documented. Curently, file schema URIs with relative roots e.g. "file://../" are parsed to "" by url.Parse and lead to errors when opening a "" path. Additional validation makes this problem easier to correct. Tests are also added to demonstrate that double dot segements within file schema URIs passed to zap.Open remaining within the specified file hierarchy. This change addresses https://cwe.mitre.org/data/definitions/23.html ref #1390 This PR succeeds #1397
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1398 +/- ##
==========================================
+ Coverage 98.28% 98.42% +0.14%
==========================================
Files 53 53
Lines 3495 3498 +3
==========================================
+ Hits 3435 3443 +8
+ Misses 50 46 -4
+ Partials 10 9 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Okay, so I had a chance to go over the issue again and the url.Parse behavior you mentioned. I see that you added the check to I've pushed a commit that does that but:
|
|
@abhinav by TestOpenRelativeValidated, I think that's TestOpenDotSegmentsSanitized because as that is the one that you skipped. This test is no longer required if we are updating the validation to reject all double dot segments from file schema paths. I've deleted that test wholesale given your updates to the validation to make it reject double dot segments. My original intention was to use that test to demonstrate that zap.Open would still function in a safe way even when provided with double dot segments in the path (this was because url.Parse only spits out absolute paths as mentioned above). |
| return nil, fmt.Errorf("file URLs must leave host empty or use localhost: got %v", u) | ||
| } | ||
|
|
||
| if strings.Contains(u.Path, "..") { |
There was a problem hiding this comment.
A filename can contain .., so I don't think this check is right
$ vim foo..bar
$ cat foo..bar
hello
should we instead look for an absolute path before calling newFileSinkFromPath?
There was a problem hiding this comment.
newFileSinkFromPath must support relative paths. Paths without the file:// form are allowed to be relative. This is documented and tested already.
Paths that take the file:// form will use net/url, and the path will always be absolute (because u.Path will always start with / for them).
The ask was to specifically reject path traversals with the URLs. We could check for /../ instead.
TBH, I'm not convinced that there's a vulnerability here, but I'll believe that a security expert could use some combination of symlinks and .. to get arbitrary file access.
There was a problem hiding this comment.
The path traversal security issue may be a false positive, since we have the hostname check above(file://foo/bar parses to host=foo, path=/bar).
Stepping back, what is the security vulnerability exactly? If the user has control over the paths, they can specify relative paths like ../foo which is a valid supported path -- does it matter if it's via URL or a relative path?
There was a problem hiding this comment.
As I said, I'm not convinced that there's a vulnerability here.
But you're right, given that the user has full control of this input, this is even less a question of sanitization.
If we want to appease the linter, we can add a filepath.Clean there, but the actual check may be unnecessary.
There was a problem hiding this comment.
Commented in #1390 (comment)
Add validation to ensure file schema paths passed to zap.Open are absolute since this is already documented.
Tests are also added to demonstrate that double dot segements within file schema URIs passed to zap.Open remain within the specified file hierarchy.
This change addresses https://cwe.mitre.org/data/definitions/23.html
ref #1390
This PR succeeds #1397