Following a successful recvfrom(), a child process is
forked and the manage_request() function called to process the received packet.We need
to trace into manage_request() to see what happens with the user??™s input. We can see
right off the bat that none of the parameters passed in to manage_request() deals with
the size of buf, which should make the hair on the back of our neck stand up. The manage_
request() function starts out with a number of data declarations as shown here:
162: void manage_request(char *buf, int sock,
163: struct sockaddr_in* addr) {
164: char init_cwd[1024];
165: char cmd[512];
166: char outf[512];
167: char replybuf[65536];
168: char *user;
169: char *password;
170: char *filename;
171: char *keyword;
172: char *envstrings[16];
173: char *id;
174: char *field;
175: char *p;
176: int i;
Here we see the declaration of many of the fixed-size buffers noted earlier by RATS.
We know that the input parameter buf points to the incoming UDP packet, and the
buffer may contain up to 65535 bytes of data (the maximum size of a UDP packet).
There are two interesting things to note here??”first, the length of the packet is not passed
into the function, so bounds checking will be difficult and perhaps completely dependent
on well-formed packet content.
Pages:
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520