11–20 of 63 posts
Thanks in advance.
Edit: I "know" C and C++ and would like to remain in one of these languages, if it's not asking too much.
I am always on the look out for a small, lightweight and secure web server for impromptu file sharing. Right now I use publicfile from djb.[^1] My only complaint is that there is no debian package for publicfile so I have to build my own package. I would love to find an equivalent (ftp not necessary) daemon that is included in debian. Is anyone aware of a something in debian repos that I am overlooking? [^1]: http://…
ruby -e 'require "rack"; include Rack; \
Server.start :app => Directory.new(".", \
Static.new(nil, :urls => ["/"], :root => "."))'I am always on the look out for a small, lightweight and secure web server for impromptu file sharing. Right now I use publicfile from djb.[^1] My only complaint is that there is no debian package for publicfile so I have to build my own package. I would love to find an equivalent (ftp not necessary) daemon that is included in debian. Is anyone aware of a something in debian repos that I am overlooking? [^1]: http://…
This is hardly in the category of "lightweight and secure", but for impromptu stuff, this Ruby+Rack one-liner serves directory listings and static files from the current directory: ruby -e 'require "rack"; include Rack; \ Server.start :app => Directory.new(".", \ Static.new(nil, :urls => ["/"], :root => "."))'
python -m SimpleHTTPServerMy C is a little rusty, but it seems like this web server is definitely not safe. The very first function in the code has a local stack variable and uses sprintf() to fill it. That's almost a textbook example of a buffer overflow vulnerability, if I'm not mistaken. Even if they try and compensate for that by checking the data length before it's passed to that function, it's still scary to see someone using sprintf()…
* BUFSIZE is 8096.
* logbuffer (the local variable) is BUFSIZEx2
* s1 looks like it's always trusted and an order of magnitude smaller than BUFSIZE.
* The format strings and numbers are nowhere near big enough to make up the difference.
* Where s2 is untrusted data, I think it's always guaranteed to be But there are definitely other possible issues I haven't looked at closely, and I'm certainly troubled that this mess has showed up on an IBM site as an example of a "safe" web server.
Earlier quoted context omitted.
This is hardly in the category of "lightweight and secure", but for impromptu stuff, this Ruby+Rack one-liner serves directory listings and static files from the current directory: ruby -e 'require "rack"; include Rack; \ Server.start :app => Directory.new(".", \ Static.new(nil, :urls => ["/"], :root => "."))'
python -m SimpleHTTPServer
Also, casting function calls to (void) is nonsensical.
You can perhaps forgive the sprintf() call because, AIX. (Believe it or not, there was a time when snprintf was a portability problem). You can't forgive the log() function that doesn't explicitly bounds check its argument (though it's not exploitable in this code).
Adding to what everyone else has said, this also "how not" to write socket code; for instance, the assumption that you can read a whole HTTP request "in one go" with a single large read call is false. Also, casting function calls to (void) is nonsensical. You can perhaps forgive the sprintf() call because, AIX. (Believe it or not, there was a time when snprintf was a portability problem). You can't forgive the log()…
Does extremely pedantic C require the results of function calls to be used?
I know the correct way to mark a variable as unused is to cast it to void, but I'm not sure if you're supposed to do that for function return values as well.