home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / expect_bug.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  2.0 KB  |  50 lines
  1.  
  2.         I checked various FAQs and archives relating to both
  3. Expect and security and haven't seen any previous mention of this.
  4.         The version of Expect I am using is 5.14 but I would be very
  5. surprised if this didn't apply to all versions of Expect.
  6.  
  7.         Expect is used frequently to automate login sessions on remote
  8. machines. This is done via a pseudo tty opened bidirectionally to allow
  9. interaction with programs either suited to or needing terminal behavior.
  10. This pseudo tty is (under Linux and Solaris at least) owned by root and
  11. mode 666. It is possible to obtain a password passed to the login process
  12. by reading from the slave end of the tty.
  13.  
  14.         Example:
  15.  
  16. expect1.1> spawn ssh somewhere.com
  17. spawn ssh somewhere.com
  18. 22239
  19. expect1.2>
  20.  
  21. Now on another window as a different user:
  22.  
  23. $ ps -u tex | grep ssh
  24.  22239 ttyp1    0:00 ssh
  25. $ cat < /dev/ttyp1
  26.  
  27. Now back at the original window:
  28.  
  29. expect1.2> expect ":"
  30. tex's password: expect1.3> send "Hrd2Cr@k\r"
  31.  
  32. At which point the username shows up on the second window. Normally this
  33. would be automated and someone trying to exploit this would have to make a
  34. decent educated guess as to when to read from the tty.
  35.  
  36.         The reason this occurs is because Expect never makes the handle
  37. inaccessible to other processes. AFAIK there are only two ways to do this:
  38. change the ownership/permissions of the tty or lock it.
  39.         The former seems to be possible to do on some platforms. Solaris
  40. includes a grantpt() C function which changes the ownership (temporarily?)
  41. of the tty pair. This function is probably used normally by login to
  42. change permissions on a tty for use by users. The methods for
  43. accomplishing this seem to be completely different from Unix to Unix.
  44.         The other method would be to lock the tty before spawning the
  45. process. As I discovered while working on a Perl port of Expect, there are
  46. some programs that get very angry if you keep them from accessing
  47. /dev/tty. If you know the program you're spawning doesn't require the use
  48. of /dev/tty then maybe it's possible to lock it on a case by case basis.
  49. I'm not sure.
  50.