File Permission (BUG/Security Hole?)

File Permission (BUG/Security Hole?)

Post by Grahame M. Kell » Mon, 09 Jun 2003 07:27:32



Hi Everyone.

If I move (as root) a file to my home directory say
readme2.txt from /root and then "ls -l" I get

-rw-r--r--    1 root     root        
2032 2003-06-08 08:05 Readme.txt

which is what I would have expected.

my account ID is:

uid=500(gmkelly) gid=100(users) groups=100(users)

if I now "vi Readme.txt" as myself which is owner/group
root and modify the file, then force write (w!) it back
this changes the file permissions as follows:

-rw-r--r--    1 gmkelly  users        
2033 2003-06-08 08:14 UART_Readme.txt

Is this correct functional operation or a bug?

I would have thought that the vi editor would not have
been able to write to the file as it is root owned, and
my account is not a member of the root group.
Doesn't seem right to me.

Comments?
I am running Linux Kernel 2.4.19 on SuSE 8.1 (i386)

--
Cheers. Grahame
grahame (at) wildpossum (dot) com

 
 
 

File Permission (BUG/Security Hole?)

Post by Grahame M. Kell » Mon, 09 Jun 2003 07:29:59



> if I now "vi Readme.txt" as myself which is owner/group
> root and modify the file, then force write (w!) it back
> this changes the file permissions as follows:

Should read:

if I now "vi Readme.txt" as myself and modify the file,
then force write (w!) it back this changes the file
permissions as follows:

--
Cheers. Grahame

 
 
 

File Permission (BUG/Security Hole?)

Post by Allen McInto » Mon, 09 Jun 2003 10:46:21




Quote:>if I now "vi Readme.txt" as myself and modify the file,
>then force write (w!) it back
>this changes the file permissions [and ownership]
>Is this correct functional operation or a bug?

It is possible to argue this either way.  In similar
circumstances, the Solaris version of vi won't write.
Vim is also more agressive about writing to files that
you own but don't have write permissions on.

Quote:>I would have thought that the vi editor would not have
>been able to write to the file as it is root owned, and
>my account is not a member of the root group.
>Doesn't seem right to me.

Vi doesn't actually write into the file.  Because you have write
permission on the directory in which the file resides, you are
allowed to remove the file [try it sometime].  Vi does that, then
re-creates the file, owned by you.  Vi won't do this if the file
has multiple links to it, and it can't do it if the file is
somewhere like /tmp where removing files owned by someone else
is prohibited.
 
 
 

File Permission (BUG/Security Hole?)

Post by David Schwart » Tue, 10 Jun 2003 11:45:04




> Hi Everyone.

> If I move (as root) a file to my home directory say
> readme2.txt from /root and then "ls -l" I get

> -rw-r--r--    1 root     root
> 2032 2003-06-08 08:05 Readme.txt

> which is what I would have expected.

> my account ID is:

> uid=500(gmkelly) gid=100(users) groups=100(users)

> if I now "vi Readme.txt" as myself which is owner/group
> root and modify the file, then force write (w!) it back
> this changes the file permissions as follows:

> -rw-r--r--    1 gmkelly  users
> 2033 2003-06-08 08:14 UART_Readme.txt

> Is this correct functional operation or a bug?

    This is correct. The system is just doing what you asked it to do.

Quote:> I would have thought that the vi editor would not have
> been able to write to the file as it is root owned, and
> my account is not a member of the root group.
> Doesn't seem right to me.

    The editor doesn't have to write to the file. It can read the file's
contents into memory, remove the file, and then create a new file with the
same name. You have read/write permissions to the directory.

    DS

 
 
 

1. Really serious security hole in Microport Unix (Re: SECURITY BUG IN INTERACTIVE UNIX SYSV386)

[I've crossposted this widely because there should be a lot of
people who care about this; however, I've directed followups to
comp.unix.sysv386.]

Interactive's Unix isn't the only one with a really serious
security hole. Microport 3.0e, and possibly others from
Microport, has an equally awful hole and it is unfixable without
kernel hacking. Microport knows about it since I told them about
it; I don't know what, if anything, they are going to do about it.

If anyone out there wants information on this bug, I will send it
to you. Also, I have created a replacement for the offending
kernel module of 3.0e and can send that. However, I will only

your site is reasonably secure. If you are at the end of an
insecure (in my opinion, and I won't change it) path and you still
want this information, I will arrange a direct uucp connection to
send it. If that won't work, I'll try to arrange something.

I won't immediately describe the bug on the net in order to give
admins a chance to fix their systems before the crackers get a
whack at it. I can't even describe the general area that this bug
compromises without making it too easy to trigger it.

In a few weeks, after the expected deluge of "what *is* that bug"
messages, I will post the informational message I'm sending out.

--

Consider said various vicious and incendiary comments about brain
dead programmers and inadequate QA. These bugs should *never*
have made it out the door and, having done so, they should never
have lasted as long as they have. Of course, we can't blame the
guys at Interactive and Microport too much; they have had the
example (and largely uncomment code) of those guys who gave us
the still unfixed (or so I hear) System V inode bug.

2. MAILTO

3. BUG: AppleTalk security hole

4. ICMP ping effecting network flow?

5. NIS+ bug a security hole?

6. Need 'as' and possibly 'ld' for gcc

7. Network Security hole (was -> Re: arp bug )

8. Patrol freezes, net lockup

9. Security Hole on webservers run on variuos OS, How to close UNIS hole

10. best-of-security mailing list (was: Solaris 2.5 Security Hole: local users can get root)

11. Solaris Security Hole -- uudecode can create SUID files

12. Copying files with holes in them, without filling the holes