It looks like there are many opportunities for denial of service attacks
Heaping piles of 'em, yeah, and your attacks are correct but you lose marks on 1 and 2 for not describing any fixes.
Here's some of the "guideline" answers I wrote up at the time (I work for the Canadian government... they want a fairly comprehensive list of expected answers submitted with the questions so there's no "dirty pool" during marking).
- blocking I/O. don't block waiting for complete requests from clients
or you have a DoS. Fix with either handler threads with timeouts,
just timeouts, or select/read into multiple buffers.
- no verification of clients. Need something like a host list. Shared
secrets, crypto, etc won't work because of the backwards compatibility
constraint.
- no checking of scripts. Need to ensure that the things like
"unlink /etc/passwd" or embedded perl command aren't sent. Server
sandboxing (chroot), some kind of safe/taint
mode, etc would be needed. In this case, sanitizing the scripts is
critical but might not actually be feasible. Some might
naively think this is a client problem, but we specifically asked for
fixes that would be backwards compatible with older clients so it has to
be fixed in the server. In this case, we never actually identified what
these scripts do or how they work other than they have to be on one
line. 1 of 4 points is for mentioning this as a problem in providing
a complete answer.
- no checking the length of the input. This provides the opportunity
for a resource-based DoS. The answer needs to explain that there
has to be a limit to request length. 1 of the 4 points require mentioning that
there's no way to determine what that limit actually is without a concrete
client implementation.
- lack of error checking in the implementation means that when a
client goes away, we don't know and continue to send "dothis" messages
to it. Enough of those clients will cause a resource-based DoS
(file handles) as well as polluting the list of hosts enough that
we couldn't process requests. Server needs to see when things go away
and remove hosts from the list.
Hmmm... forgot to mention the backwards compatibility constraint. Any proposed "fix" was supposed to be backwards compatible with the original protocol. This does mean that some problems could never really be fixed, but... Well, the question was supposed to reflect some work we do regularly... take a really old and badly (un)documented piece of code, understand (and document) how it works, and fix/improve it without breaking the entire infrastructure.
c.
