Some formatted output operations can be buried deep
within library calls and are therefore not apparent at first glance. In the past, this
has been the case in many logging functions created by application programmers.
Example Using find.c
Using find.c as an example, how would this process work? We need to start with user
data entering the program. As seen in the preceding ITS4 output, there is a recvfrom()
function call that accepts an incoming UDP packet. The code surrounding the call looks
like this:
char buf[65536]; //buffer to receive incoming udp packet
int sock, pid; //socket descriptor and process id
sockaddr_in fsin; //internet socket address information
//...
//Code to take care of the socket setup
//...
while (1) { //loop forever
unsigned int alen = sizeof(fsin);
//now read the next incoming UDP packet
if (recvfrom(sock, buf, sizeof(buf), 0,
(struct sockaddr *)&fsin, &alen) < 0) {
//exit the program if an error occurred
errexit("recvfrom: %s\n", strerror(errno));
}
pid = fork(); //fork a child to process the packet
if (pid == 0) { //Then this must be the child
manage_request(buf, sock, &fsin); //child handles packet
exit(0); //child exits after packet is processed
}
}
Gray Hat Hacking: The Ethical Hacker??™s Handbook
286
The preceding code shows a parent process looping to receive incoming UDP packets
using the recvfrom() function.
Pages:
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519