home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / alt / hackers / 1741 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  2.0 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!cs.utexas.edu!rutgers!ub!acsu.buffalo.edu!jcmurphy
  2. From: jcmurphy@acsu.buffalo.edu (Jeff Murphy)
  3. Newsgroups: alt.hackers
  4. Subject: Re: cracking login?
  5. Message-ID: <By6Ho1.C4J@acsu.buffalo.edu>
  6. Date: 23 Nov 92 16:55:10 GMT
  7. References: <1eorh6INN684@dixie.cs.ubc.ca>
  8. Sender: nntp@acsu.buffalo.edu
  9. Organization: UB
  10. Lines: 48
  11. Approved: by me.
  12. Nntp-Posting-Host: vodalus.acsu.buffalo.edu
  13.  
  14. In article <1eorh6INN684@dixie.cs.ubc.ca> hassan@cs.ubc.ca (Moustafa Hassan) writes:
  15. >I've thought of a scheme for logging in as any user in a given file system.
  16. >The only problem is that it's too easy.  I must be under some illusion.
  17. >I'd appreciate it if someone pointed out the flaw in my algorithm:
  18. >
  19. >1.  Obtain the code for login.c.  I've done this.  I'm having some trouble
  20.  
  21.     the code is trivial, and therein lies the flaw.
  22.  
  23. >3.  Remove the encryption step where the password is encrypted.
  24.  
  25.     doesn't matter. the password really has nothing to do with
  26.     changing to another user.
  27.  
  28. >5.  When executing login, give it (the publically available) user id and 
  29. >    encrypted password of any user on the system, and you're in.
  30.  
  31.     this is what login does:
  32.         read username
  33.         read password
  34.         encrypt password
  35.         compare encrypted password to encrypted version on file
  36.         if they are equal, setuid to uid of username
  37.             and setgid to gid of username and start a shell
  38.         else quit.
  39.  
  40.     so what *you* are actually doing is:
  41.  
  42.         setgid to gid of user
  43.         setuid to uid of user
  44.         start shell
  45.  
  46.     unfortunately, the flaw in this is that the only the superuser
  47.     can change uid and gid arbitrarily, so you will notice that the
  48.     login program has permissions set like this:
  49.  
  50.     -rwsr-xr-x root    ..... login
  51.  
  52.     the "s" on the owner field means that when login is executed it
  53.     runs as a root process with root privs, so your login program will
  54.     run as your process with your privs, and since you dont have root
  55.     privs, you can setgid and setuid. to sum up: your hack will fail.
  56.  
  57.     hope this clears things up for you.
  58.  
  59. .
  60. .
  61. Jm..
  62.