Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

unsafehttp.benren.au

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#31

Post by nneonneo »

If you want to make it actually decently safe, one approach would be to make a list of all the syscalls you critically need after you have loaded all the content in memory (strace can help), then write a seccomp filter to block all the others. Since you don’t need filesystem interaction or pretty much anything except socket I/O, your syscall allowlist can be pretty short. This will ensure that even if an attacker manages to exploit a bug (like a UAF) they’ll be dropped into a sandbox with very little useful functionality.

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#33

Post by nneonneo »

contingencies wrote: post #16

Are you near Sydney? I noted a possible link to the Central Coast. I will contribute a smaller device if you're game to host it. PS. You may be unaware that your shortened domain name 'benren' from your whois-available real name means "stupid person" in Mandarin. Only noted because there is a company registered with the same name since 1999. On the off chance it's yours, probably not the best marketing in a global wo…

It could be self-deprecating! Plus, I would more readily read it as 本人 (this person/me/myself) - than as 笨人 (stupid person).

Also, Pinyin is more susceptible to accidental interpretations than most writing systems due to ambiguity and tonality. For example, “mana” can be parsed into 32 different syllable-tone combinations (man/a or ma/na times 4x4 tone combinations for each syllable), and while most aren’t meaningful, that still gives you a ton of potential words to match against.

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#35

Post by cenamus »

nneonneo wrote: post #31

If you want to make it actually decently safe, one approach would be to make a list of all the syscalls you critically need after you have loaded all the content in memory (strace can help), then write a seccomp filter to block all the others. Since you don’t need filesystem interaction or pretty much anything except socket I/O, your syscall allowlist can be pretty short. This will ensure that even if an attacker man…

Or (if on openbsd), the pledge and unveil syscalls. Pretty similar effect, but much easier

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#36

Post by nullify88 »

Good to see more tiny / small http servers. I'm not a fan of sticking Nginx in a container which maybe bigger than the assets its serving. A statically compiled httpd from busybox has been great for this reason but its good to see more options.

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#38

Post by Joker_vD » 

    // it doesn't seem to love piping or redirecting output without this, even
    // with the newlines above
    fflush(stdout);
Ah, the full buffering mode. I believe it can be fixed by calling

    setvbuf(stdout, NULL, _IOLBF, BUFSIZ);
once at the start.

On the whole, it actually almost implements the minimally required amount of HTTP/1.1: I would suggest adding support for HEAD requests, it's just a single flag that you need to set in the try_parse_request_path(), and check in generate_response(). Also, probably check that the request path is followed by "HTTP/1." before sending the response? And I'd really recommend finishing reading out all of the request from the socket (that is, until you've seen "\r\n\r\n"), or you may run into the problem of your clients not being sent the complete response [0].

But other than that, yeah, it is an HTTP server. The HTTP protocol is decently well thought out so that you can be oblivious of most of the features you don't want to support.

[0] https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-... — the tl;dr is that if you do close() on a socket that still has the data from the client you haven't recv()d, the client will be sent an RST.

Re: Show HN: unsafehttp – tiny web server from scratch in C, running on an orange pi

#39

Post by JdeBP »

kjellsbells wrote: post #18
a1o wrote: post #17

Earlier quoted context omitted.

I don't understand this, could you explain?

around line 663. there's a call to strrchr, checking for a period in the filename. then immediately after that, there's a strlen that uses the results. Which is fine, unless the first call returns NULL, because there was no period in the name, and then the program will crash.

Much has been said about Daniel J. Bernstein eschewing the Standard C library in publicfile and other softwares. But Bernstein's str_rchr() function was designed to expressly avoid this well-known gotcha of the Standard C string functions.

Here's str_rchr() which uses the offset of the terminating NUL as the returned sentinel value:

* https://github.com/jdebp/djbwares/blob/trunk/source/str_rchr...

And here's it being used (by publicfile's httpd and indeed other programs) to find the basename's extension in order to infer a content type:

* https://github.com/jdebp/djbwares/blob/trunk/source/filetype...

The extension is always a non-NULL string, that can always be passed to str_equal(). It is just sometimes a zero-length string.

It's possible, but a bit clunky, to achieve the same effect with two successive calls to Standard C/C++ strrchr(), or strchr(), the second being:

        if (!result) result = std::strchr(s, '\0');
Here's me doing that in my own code:

* https://github.com/jdebp/nosh/blob/c8d635c284b41b483067d5f58...

One can get very lost in the weeds on the comparative merits on different instruction architectures of compiler intrinsics, explicit loop unrolling, whole program optimization, and whatnot. (-:

Post reply on HN