Bug 117987 - read(2) on directories might leak filenames of deleted files
Summary: read(2) on directories might leak filenames of deleted files
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-BETA2
Hardware: Any Any
: Normal Affects Only Me
Assignee: Robert Watson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-11 20:20 UTC by Pierre Riteau
Modified: 2018-05-28 19:44 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Riteau 2007-11-11 20:20:00 UTC
On FreeBSD, any user can open(2) and read(2) a directory when he has read rights to it. read(2)ing a directory dumps the content of the inode of that directory, which might leak filename of deleted files.
Those filenames may be secret.

Fix: 

On OpenBSD read(2)ing a directory always returns 0 (end-of-file) (on a FFS1 filesystem).
How-To-Repeat: $ cd /home/pierre
$ ls
.               .history        .login_conf     .profile
.              .lesshst        .mail_aliases   .rhosts
.cshrc          .login          .mailrc         .shrc
$ chmod 700 . # no one should list the content of this directory now
$ touch secretfilename # no one should see this filename
$ rm secretfilename
$ chmod 755 . # ok, I can make it public, secretfilename is gone

Another user can now do :
$ cat -v /home/pierre
Ym
^@^L^@^D^A.^@^@^@Xm
^@^L^@^D^B..^@^@Zm
^@^P^@^H^F.cshrc^@M-L[m
^@^P^@^H^F.login^@M-L\m
^@^T^@^H^K.login_conf^@]m
^@^P^@^H^G.mailrc^@^m
^@^T^@^H^H.profile^@M-+M-^WM-L_m
^@^P^@^H^E.shrc^@M-^WM-L`m
^@^X^@^H^M.mail_aliases^@OM-Bam
^@^P^@^H^G.rhosts^@bm
^@^T^@^H^H.history^@M-;^NM-Mcm
^@D^A^H^H.lesshst^@^K^MM-Mdm
^@0^A^H^Nsecretfilename^@M-B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

and he sees the secretfilename.
Comment 1 K. Macy freebsd_committer 2007-11-16 17:44:12 UTC
State Changed
From-To: open->feedback


I don't think a user should have read access to a directory that is considered private.  
I would like to just close this. 


Comment 2 K. Macy freebsd_committer 2007-11-16 17:44:12 UTC
Responsible Changed
From-To: freebsd-bugs->cperciva


I don't think a user should have read access to a directory that is considered private.   
I would like to just close this.
Comment 3 K. Macy freebsd_committer 2007-11-16 18:13:56 UTC
State Changed
From-To: feedback->open


Robert has committed to commenting. 


Comment 4 K. Macy freebsd_committer 2007-11-16 18:13:56 UTC
Responsible Changed
From-To: cperciva->rwatson


Robert has committed to commenting.
Comment 5 Robert Watson freebsd_committer 2008-01-13 18:35:18 UTC
State Changed
From-To: open->analyzed

This has long been considered a BSD feature, but it does have downsides. 
In particular, Common Criteria requires that data deleted using an 
operating system interface not be exposed to unprivileged processes 
(similar to memory zeroing requirements).  I'm unclear on whether 
applications have come to depend on read(2) working on directories, but 
one can certainly imagine that they might have (perhaps dump?). 

I think the right path forward here is to introduce a new sysctl that 
controls whether or not direct directory read is permitted for 
unprivileged processes.  We can try setting it by default and fall back 
to having it be a policy option if that doesn't work out. 

I don't have a patch for this currently, but will investigate doing that 
sometime this year.  This is made somewhat tricky because we don't 
distinguish VREAD and VREADDIR with our vaccess() interface, so we can't 
just do it in vaccess() without modifying file systems to also make the 
distinction.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:44:49 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.