home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / security / misc / 1779 < prev    next >
Encoding:
Text File  |  1992-11-17  |  1.2 KB  |  26 lines
  1. Newsgroups: comp.security.misc
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!ulysses!smb
  3. From: smb@ulysses.att.com (Steven Bellovin)
  4. Subject: Re: gnumake SGID: potential security hole?
  5. Message-ID: <1992Nov17.165157.6769@ulysses.att.com>
  6. Date: Tue, 17 Nov 1992 16:51:57 GMT
  7. References:  <MELLAN.92Nov17131950@syst06.acri.fr>
  8. Organization: AT&T Bell Laboratories
  9. Lines: 15
  10.  
  11. In article <MELLAN.92Nov17131950@syst06.acri.fr>, mellan@syst06.acri.fr (Alain Mellan) writes:
  12. > 
  13. > I just discovered today that gnumake is installed with SGID bit, and
  14. > belongs to user root, group kmem.
  15. > 
  16. > Am I right to be suspicious ?  The kmem SGID will allow gnumake to
  17. > read into /dev/kmem the info needed for load balancing, but is that
  18. > all?
  19.  
  20. Someone who can read /dev/kmem can also read interesting things like
  21. typed passwords in tty input buffers, and disk blocks from read-protected
  22. files.  I have no idea whether or not it's possible to trick gnumake
  23. into doing those things -- for example, if it doesn't properly reset
  24. its setgidness and close the file descriptor before execing a user program.
  25. There's a definite risk here, if things weren't done properly.
  26.