in reply to Chat server impossible with Perl?

The following is a description of a protocol I designed for an job candidate examination: 
   Receives lines from a client:
      iam <id>
      need-done <args>
   In response to a need-done, sends to a client that has given
   an "iam" message:
      dothis <args>
   Server ignores any other lines
It's basically a trivial job dispatch protocol where clients register to do work with a central server and are also able to request jobs. Designwise, it's pretty much all that the described chat server would do.

The exam question asked them to describe the protocol given the following code and then identify at least three security holes (with proposed attacks) in the protocol as well as explain how you'd fix the security problems. Which is why it was written so badly. Sorry... 

use Socket;

socket S, PF_INET, SOCK_STREAM, getprotobyname('tcp') or die "$!";
setsockopt S, &SOL_SOCKET, &SO_REUSEADDR, 1 or die "$!";
bind S, sockaddr_in( 23456, INADDR_ANY ) or die "$!";
listen S, 5 or die "$!";

$SIG{__DIE__} = sub { close S; };

$rin = "";
vec( $rin, fileno(S), 1 ) = 1;
while( 1 ) {
   next unless select( $rout = $rin, undef, undef, undef ) > 0;
   if( vec( $rout, fileno(S), 1 ) ) {
      local *H;
      $p = accept( H, S );
      select( (select(H), $| = 1)[0]);

      push @known, *H;
      vec( $rin, fileno(H), 1 ) = 1;
   }
   foreach my $fd (@known) {
      if( vec( $rout, fileno($fd), 1 ) ) {
         $s = readline $fd;
         push @able, $fd if $s =~ /^iam\s+(.+)\s*$/io;
         if( @able and $s =~ /^need-done\s+(.+)\s*$/io ) {
            print { $able[(unpack "%32C*",$1) % @able] } "dothis ", $1
+, "\n";
         }
      }
   }
}

[download]
For some reason, only one candidate even attempted the question.

That aside, it's certainly possible to write a chat server in perl. It's not threaded, but I don't see why you'd really want a threaded server when so much state has to be shared between all the processes and the overhead of serving requests is so low.

c.

Replies are listed 'Best First'.
Re^2: Chat server impossible with Perl?
by tmoertel (Chaplain) on Feb 05, 2005 at 06:24 UTC
    It looks like there are many opportunities for denial of service attacks:
    • Because accepted connections are never closed, one attack would be to connect and disconnect repeatedly, until your server has used up all of its file descriptors.
    • Another attack would be to connect and send a packet not terminated by an end-of-line marker and then hold the connection open, causing readline in the server to block, thus preventing the server and its horde of worker bees from doing anything else.
    • Another would be to connect with a client that never reads from its end of the connection. Eventually, the server would block while trying to send the misbehaving client a message. The client could speed the process by sending repeated requests with incrementing need-done payloads to cause the checksum-based dispatcher to sweep across all of the "able" file descriptors, guaranteeing that the server would send a request to the misbehaving client. (The client could grab more "able" slots for itself by issuing lots of "iam" messages, but this isn't really necessary.)
    Were these the kinds of things you had in mind?

    Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]
      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.

[reply]
      The client could grab more "able" slots for itself by issuing lots of "iam" messages, but this isn't really necessary.

      Neat, I never noticed that attack. It's subtly different from a file descriptor DoS but probably nastier because there's no external limits on how much resources can be used.

      c.

[reply]

In Section Seekers of Perl Wisdom