Hacker News Reader

Comment by gberger | Hacker News Reader

I know this is just for fun and not intended for production use. But what could be potential exploits and vulnerabilities in this server?

View on HN

Regarding availabiltiy: It only handles a single connection, and has no timeouts. If someone just connects, and does nothing else, the server will be unavailable.

For the interested: this is called (or at least similar to) a slow loris attack: https://en.wikipedia.org/wiki/Slowloris_(computer_security)

I tried to make it secure and protect from such things. If someone finds vulnerabilities, please let me know.

use strncpy() instead of strcpy()

It's calculated that strcpy() should never cause a buffer overflow here.

You should still never use functions which have well known security flaws if there is a widely available alternative which avoids the flaws. Secure programming isn't just about calculating whether your current code has a bug, it's also about writing code that avoids bugs.

If I look at the code as posted then "it uses strcpy instead of strncpy" is very low on the list of "problems".

"Problems" in quotes because, you know, this is IOCCC entry. You're taking a joke way to serious.

The author literally asked for security advice, and then ignored it. I'm trying to explain why one should not just ignore it. There's a lot of novice programmers who read these threads and might think it's perfectly fine to use strcpy (outside of IOCCC submissions). And by the way, who the hell cares about security vulns in IOCCC submissions anyway? It's not supposed to be secure, it's supposed to be obfuscated.

I don't think anyone asked for free advice from a foul-mouthed anonymous throwaway on how to secure their computer. If I was building a website I'd want to secure it from you not with you.

so every secure programming C book ever written that tells people to never use strcpy() is wrong? please explain...

GET ../../../etc/passwd

sandbox it? e.g. docker, OpenBSD chroot?

that's not cross-platform tho. it should still be secure even if it was running on MS-DOS 5.0

That's an environmental thing, the program itself can't protect against the class of attacks those sorts of environmental setups protect against.

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_Nam...) to worry about.

That made me wonder whether other OSes might have similar features. Reading 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.

I don't think anyone can blame someone for having security vulnerabilities on a platform that they explicitly do not support.

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?

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.

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.

And now it compiles on Windows, at least with Msys2. I'm updating the code on github.

Looks like you didn't even bother to test your claim.

GET %C0%AE%C0%AE/%C0%AE%C0%AE/%C0%AE%C0%AE/etc/passwd

It won't be a problem in this code because "%" is not handled. But could be a vulnerability for more implemented HTTP servers, and a few days ago I got this idea too.

Reply on news.ycombinator.com