home *** CD-ROM | disk | FTP | other *** search
/ Power Hacker 2003 / Power_Hacker_2003.iso / Exploit and vulnerability / hoobie / hpux-cue.txt < prev    next >
Encoding:
Text File  |  2001-11-06  |  2.5 KB  |  96 lines
  1.  
  2. We all know that HP-UX is insecure (out of the box), right? Here is some
  3. proof.
  4.  
  5. We are talking about HP-UX 10.20
  6.  
  7. One night I had nothing better to do, so I logged on to my college to
  8. play with the computers...
  9.  
  10. I was surprised to see in MOTD that we are upgraded to Hp-UX 10.20
  11.  
  12. So I decided to check for suid binaries...
  13.  
  14. Sure enough I found a ton of them (more than 50 I belive)
  15.  
  16. One of the programs that attracted my attention was cue (Hewlett Packard
  17. Character-based User Environment)
  18.  
  19. As it was possible to make it a login program, I decided to investigate
  20. further...
  21.  
  22. $ export LOGNAME=root
  23. $ cue
  24. Welcome root
  25.  
  26. That was encouraging, of course it gave up the suid priviledges when I
  27. got the shell, but a different problem exists...
  28. Since it was mislead by $LOGNAME (big oops in login programs :), it
  29. detected that I am in fact not root... BUT
  30.  
  31. When I did ls -la, among others I found this:
  32.  
  33. -rw------- root mygroup 0 IOERROR.mytty
  34.  
  35. So, it also follows my umask...
  36.  
  37. $ umask 000
  38. $ cue
  39. -rw-rw-rw- root mygroup  0 IOERROR.mytty
  40.  
  41. I decided to check whether or not it will follow symlinks, so I created a
  42. symlink  to /lost+found/test (unwriteable by anyone)
  43.  
  44. $ cue
  45. $ ls -la /lost+found
  46. -rw-rw-rw- root mygroup 0 test
  47.  
  48. So, it also follows symlinks...
  49.  
  50. However, it wipes out the target file. A symlink to /etc/passwd comes to
  51. mind.
  52.  
  53. But, since it follows the umask, it might be possible to replace binaries
  54. executed by system...
  55.  
  56. In any event, a very dangerous condition...
  57.  
  58. I do not have the access to source code, so I can't think of a patch.
  59. Probably replace getenv with getuid or something like that.
  60.  
  61. So the recommendation would be to remove the program's suid bit, as
  62. usual.
  63.  
  64.  
  65. ----------------------------------------------------------------------------------
  66.  
  67.  
  68. > However, it wipes out the target file. A symlink to /etc/passwd comes to
  69. > mind.
  70.  
  71. the file would retain permissions. permissions are set on create, it
  72. probably is simply truncating the file.
  73.  
  74. >
  75. > But, since it follows the umask, it might be possible to replace binaries
  76. > executed by system...
  77.  
  78. See above.
  79.  
  80. >
  81. > In any event, a very dangerous condition...
  82.  
  83. Indeed. .forward/.rhosts is the most obvious attack.
  84.  
  85. >
  86. > I do not have the access to source code, so I can't think of a patch.
  87. > Probably replace getenv with getuid or something like that.
  88.  
  89. It's kinda lame, but:
  90.  
  91. remove the s bit from the program, write a c program that clears the
  92. environment and exports those variables it needs (setting the user via
  93. getpwuid() or somesuch) then executes the program (while euid=0,
  94. ruid=you).
  95.  
  96.