4 ms·

I have provided protection against this.

by jpegqs 5y ago

Someone 5y ago
I don’t think it compiles on windows (netdb.h doesn’t exist there, I think), so you’re fine there, too, from a security viewpoint. However, if somebody did a quick and dirty “make it compile” port (include winsock2.h instead and, possibly, replace some functions/argument types), I think that would create security vulnerabilities because the fopen on Windows might support using backslashes as path separators. Even if it doesn’t, there’s UNC paths (https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention https://en.wikipedia.org/wiki/Path_(computing)#Universal_Nam...) to worry about. That made me wonder whether other OSes might have similar features. Reading https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd..., I’m not sure that forbids Unix from doing something similar. It says “A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.” That opens the door for doing special things for paths that start with //, for example by supporting “//machine:foo/bar/baz” on clusters.
- fao_ 5y ago
  I don't think anyone can blame someone for having security vulnerabilities on a platform that they explicitly do not support.
- jpegqs 5y ago
  I made a windows port on github, you can try exploit that. ".//machine:foo/bar/baz" - will it work if the dot is added at the beginning?
Arch-TK 5y ago
GET //etc/passwd HTTP/1.0 I noticed the check for "/." in the path and I chuckled. I think if you strip all leading forward slashes and check for "/." then you may have it be "secure" on linux at least. Your best bet for fixing this on windows is making sure the code never compiles on windows because god knows what on earth the path handling is like on windows.
- jpegqs 5y ago
  Good point, I need add something like b[3]='.', an then use b+3 as a path, not b+5, to fix that vulnerability. Update: I fixed this on github.
- jpegqs 5y ago
  And now it compiles on Windows, at least with Msys2. I'm updating the code on github.

I have provided protection against this.

by jpegqs 5y ago

I have provided protection against this.

I don’t think it compiles on windows (netdb.h doesn’t exist there, I think), so you’re fine there, too, from a security viewpoint. However, if somebody did a quick and dirty “make it compile” port (include winsock2.h instead and, possibly, replace some functions/argument types), I think that would create security vulnerabilities because the fopen on Windows might support using backslashes as path separators. Even if it doesn’t, there’s UNC paths (https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention https://en.wikipedia.org/wiki/Path_(computing)#Universal_Nam...) to worry about. That made me wonder whether other OSes might have similar features. Reading https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html https://pubs.opengroup.org/onlinepubs/007904975/basedefs/xbd..., I’m not sure that forbids Unix from doing something similar. It says “A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.” That opens the door for doing special things for paths that start with //, for example by supporting “//machine:foo/bar/baz” on clusters.

fao_ 5y ago
I don't think anyone can blame someone for having security vulnerabilities on a platform that they explicitly do not support.
jpegqs 5y ago
I made a windows port on github, you can try exploit that. ".//machine:foo/bar/baz" - will it work if the dot is added at the beginning?

Arch-TK 5y ago

GET //etc/passwd HTTP/1.0 I noticed the check for "/." in the path and I chuckled. I think if you strip all leading forward slashes and check for "/." then you may have it be "secure" on linux at least. Your best bet for fixing this on windows is making sure the code never compiles on windows because god knows what on earth the path handling is like on windows.

jpegqs 5y ago
Good point, I need add something like b[3]='.', an then use b+3 as a path, not b+5, to fix that vulnerability. Update: I fixed this on github.
jpegqs 5y ago
And now it compiles on Windows, at least with Msys2. I'm updating the code on github.