Vulnerability Development mailing list archives

Re: Securax Advisory 13 (from bugtraq)


From: John Herron <john.herron () RRC STATE TX US>
Date: Fri, 5 Jan 2001 17:17:01 -0600

I appologize for this stupid program as well as my ignorance in unix and
most likely computer security as well.  (This GroupWise program I always
forget that for some reason its not saving the breaks that it automatically
puts in its autowrap ability).

Ok, my point originally was I didn't realize that the ls -a command was being
run AFTER the more command finishes (since the more command gets
broken off once a connection to that tty is made I thought the actual tty
may have been in charge (or some higher level program) of sending my
command instead of it just waiting and running).  Again, I thought perhaps
if a PROGRAM for tty emulation (or the tcpd or something) was the program
feeding my buffered command then my command would perhaps have
enhance my commands privalidges to perhaps root level then in that case
I would moronically be able to type out the master.passwd file.

My idea of a symlink attack/error was also incorrect.  I was thinking if I
could get the program to call a LINKED ttyp1 and really run my script called
bla then it would perhaps also run it with higher permissions than usual
again allowing me to do something as root or another guid.  I just now
learned (or atleast assume --no comment please ;o) that symlink attacks
are just that the program opens the file (thats linked), ACTUALLY openning
the file that you linked to (usually? being a file with higher permissions that
you'd like to overwrite (like the master.passwd file) hence getting you
access or deleting a restriction to further give you access (again, I'm
still new and learning these techniques so my understandings I'm sure are
sketchy at best).  My latest stunt I haven't had time to try and doubt would
work anyway was an attempt at my new understanding of a symlink attack.
$ cd /dev
$ ln ttypw /etc/passwd  /*or any other file to test with*/
$ telnet localhost /*(however many times to fill up the amount of available ttyp's and see if it would be dumb (it most 
likely wouldn't) enough to use my ttypw since in my FreeBSD 4.1.1 installation I only go up to ttypv and then maybe it 
would follow the link and do whatever*/

Again, I haven't tried it since I got tied up most of the day but I can't see it being dumb enough to fall for that.

Lastly yes, you were correct since I was creating a file in the /tmp directory which is owned by root and in group 
wheel it was my files were automatically placed in the group wheel (I just didn't know that bsd variants worked like 
that.  I expected to see it be under MY own/grp).

Thanks for the response and correcting :o)
-John

"Crist Clark" <crist.clark () globalstar com> 01/05/01 12:41PM >>>
[Ouch. Your paragraphs are all on one line. Could you wrap at 72 characters
or so?]

<my original idea which was incorrect>

Hmmm... You do this?

  $ more /dev/ttyp1
  ls -a

So, uh, what's the point/exploit? That's pretty much the same as,

  $ sleep 60
  ls -a

Provided you can type the 'ls -a' in a minute. The 'ls -a' is just waiting
for the 'more' to finish before running. Or more accurately, your input
is being buffered until the 'more' is done running. But I don't see anything
special about using /dev/ttyp1.

<my link attempt>
 
As you noticed, creating a hardlink gives you nothing. And what does
making the hardlink have to do with /dev/ttyp1? You can just,

  $ cd /tmp
  $ ln /etc/master.passwd .

And do who what you say, right? This is normal behavior.

<my symlink attempt using ttyp to run my command (which isn't how it
 works)>

Again, where are you going here? What is the security hole you are
trying to exploit? Anyone can create a symbolic link pointing to anything
they'd like provided they can write the parent directory.

<my file creation/group wheel question>

This is probably the expected behavior. In BSD-type OSes, a new file
is created with the group of its parent directory. Is that the group
of the directory you are in?
-- 
Crist J. Clark                                Network Security Engineer
crist.clark () globalstar com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926


Current thread: