proc filesystem
...
508 return len;
509 }
On line 494, snprintf is called to generate the output for the proc file
system entry. By supplying a count value of 1, snprintf will only write
a single byte to the destination buffer. However, the function will
return the number of bytes that would have been written if enough space
were available. The "*eof" value is never set, and the "*ppos" value is
never used.
> or test this. The POSIX standard mandates that link() shall fail if
> the user has no search
> permission for any of the directories in the path prefix of oldpath or newpath.
>
> Therefore, setting the directory permission to 0700 protects from hardlink
> creation (read that again!) and this bug in the /proc filesystem
> indeed lead to a
> change in access control semantics. Under POSIX, the file IS unwriteable,
> because it is protected by the permissions on the parent directory.
>
> (2) While it's irrelevant for his argument, the script by Pavel Machek has a
> >permissions protect the file. Please look at original mail; it was
> >subtle but I believe I got it right, and file would not be writable
> >with /proc unmounted.
> >
> I remember the original mail content. You're right, you can't reach
> the file if the procfs is not mounted, but you forget about the
> race, allowing the guest to create a hardlink to the file in an
> unrestricted location before the directory access becomes
> restricted. Again, procfs is just another, specific kind of
> hardlinks.
> permissions protect the file. Please look at original mail; it was
> subtle but I believe I got it right, and file would not be writable
> with /proc unmounted.
>
I remember the original mail content. You're right, you can't reach the file if
the procfs is not mounted, but you forget about the race, allowing the guest to
create a hardlink to the file in an unrestricted location before the directory
access becomes restricted. Again, procfs is just another, specific kind of
hardlinks.
--
>>> permissions protect the file. Please look at original mail; it was
>>> subtle but I believe I got it right, and file would not be writable
>>> with /proc unmounted.
>>>
>> I remember the original mail content. You're right, you can't reach
>> the file if the procfs is not mounted, but you forget about the
>> race, allowing the guest to create a hardlink to the file in an
>> unrestricted location before the directory access becomes
>> restricted. Again, procfs is just another, specific kind of
>> hardlinks.
>
[Please pause here for a while before reading how guest did it.]
Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so.
So what did happen? User guest was able to work around directory
permissions in the background, using /proc filesystem.
guest@toy:~$ bash 3< /tmp/my_priv/unwritable_file
# Running inside nested shell
guest@toy:~$ read A <&3
guest@toy:~$ echo $A
or test this. The POSIX standard mandates that link() shall fail if
the user has no search
permission for any of the directories in the path prefix of oldpath or newpath.
Therefore, setting the directory permission to 0700 protects from hardlink
creation (read that again!) and this bug in the /proc filesystem
indeed lead to a
change in access control semantics. Under POSIX, the file IS unwriteable,
because it is protected by the permissions on the parent directory.
(2) While it's irrelevant for his argument, the script by Pavel Machek has a
> [Please pause here for a while before reading how guest did it.]
>
> Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so.
>
> So what did happen? User guest was able to work around directory
> permissions in the background, using /proc filesystem.
>
> guest@toy:~$ bash 3< /tmp/my_priv/unwritable_file
> # Running inside nested shell
> guest@toy:~$ read A<&3
> guest@toy:~$ echo $A
Pavel Machek wrote:
> So what did happen? User guest was able to work around directory
> permissions in the background, using /proc filesystem.
>
> guest@toy:~$ bash 3< /tmp/my_priv/unwritable_file
Although having an already open handle to the file is kind of cheating. :-)
(well, it isn't, but I think it's a mitigating factor).
to a denial of service or privilege escalation. The Common Vulnerabilities and
Exposures project identifies the following problems:
CVE-2011-1020
Kees Cook discovered an issue in the /proc filesystem that allows local
users to gain access to sensitive process information after execution of a
setuid binary.
CVE-2011-1576
> >> Not to tell about
> >> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
> >> understand, how the original reporter managed to gain access to the file in the
> >> restricted directory using that symlink.
> >
> > The perms are definitely broken and without a code audit on procfs I
> > would not bet that this is limited just to this rather obscure test
> > case.
> >
> > To be honest, I hope that it is limited to this rather obscure test
> > case. If it is not there may be entertaining ramifications.
write access.
The real concern appears to be that user2 can write to a file descriptor
opened for read access.
A fix would be to have a mask against every procfs "fd" entry that matches
the open() mode of the file descriptor (or perhaps the mode of the file
when it was opened?). Thus a write to /proc/$$/fd/4 would fail because
the mask on fd4 would be "read".
I think this is of (very) small concern (no one in their right mind
with physical access to a system's USB ports could obtain elevated
privileges using a specially crafted USB device.
CVE-2011-1020
Kees Cook discovered an issue in the /proc filesystem that allows local
users to gain access to sensitive process information after execution of a
setuid binary.
CVE-2011-2209
> /proc/<PID>/fd of that process is accessible only by root. Not to tell about
> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
> understand, how the original reporter managed to gain access to the file in the
> restricted directory using that symlink.
The perms are definitely broken and without a code audit on procfs I
would not bet that this is limited just to this rather obscure test
case.
To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.
> > 0700 mode from the origin, you would be right, and procfs wouldn't allow
> > opening files in that directory too, but if you let others to traverse
> > that directory and open your believed to be secure files from the origin,
> > it's your fault.
>
> I can do the example with fd passing and 700 directory, but it would
> be lot of C code. Feel free to play, my example was not nearly the
> only way to demonstrate it, and no, it was not racy.
Here is an example that shows the behavior where a passed read-only fd
>> Not to tell about
>> that /proc/<PID>/fd/ contains only symbolic links, not files, so I can't
>> understand, how the original reporter managed to gain access to the file in the
>> restricted directory using that symlink.
>
> The perms are definitely broken and without a code audit on procfs I
> would not bet that this is limited just to this rather obscure test
> case.
>
> To be honest, I hope that it is limited to this rather obscure test
> case. If it is not there may be entertaining ramifications.
> >/proc is unmounted.
> >
> >I do not think mounting /proc should change access control semantics.
> >
> It didn't in fact change anything. If the guest created hardlink to
> that file in a unrestricted location, what would you say? Procfs is
> in that respect just another sort of hardlinks, whether you like
> that or not. If you didn't in fact restrict an access to the file,
> you're on your own.
Now... go back to my original email:
> /proc is unmounted.
>
> I do not think mounting /proc should change access control semantics.
>
It didn't in fact change anything. If the guest created hardlink to that file in
a unrestricted location, what would you say? Procfs is in that respect just
another sort of hardlinks, whether you like that or not. If you didn't in fact
restrict an access to the file, you're on your own.
> Plus, you may run traditional unix/POSIX application, expecting
> directory access controls to prevent the write. (Or can you see a way
pavel might have detected this attack if he checked the number of
hardlinks on "unwritable_file" between the chmod's. But he did not
check that.
Yes, procfs makes it possible to circument directory permissions
but it does not mean you are not playing with an armed grenade whenever
you mix chmod with the number of the Beast.
--
Pavel Kankovsky aka Peak / Jeremiah 9:21 \
> >guest@toy:/tmp/my_priv$ cat unwritable_file
> >cat: unwritable_file: Permission denied
> >guest@toy:/tmp/my_priv$ echo got you>&3
> >bash: echo: write error: Bad file descriptor
> >
> ># ...until we take a way around it with /proc filesystem. Oops.
> >guest@toy:/tmp/my_priv$ echo got you> /proc/self/fd/3
> >
> That can hardly be called a real security hole, since the behaviour
> described above is expected, and is as it was conceived by design.
> If the file owner in fact allows writing to it, why should Linux
> Do you still remember about openat()? If the directory was created with
No, you said you can do hardlink, and you can't. Try
it. openat(O_SEARCH) does not seem to exist.
> 0700 mode from the origin, you would be right, and procfs wouldn't
>allow
> opening files in that directory too, but if you let others to traverse
> that directory and open your believed to be secure files from the origin,
> it's your fault.
> -----Original Message-----
> From: nomail@nomail.com [mailto:nomail@nomail.com]
> Sent: Monday, October 26, 2009 9:15 AM
> To: bugtraq@securityfocus.com
> Subject: Re: Re: /proc filesystem allows bypassing directory
> permissions on Linux
>
> >> I do not think mounting /proc should change access control
> semantics.
> >>
to a denial of service or privilege escalation. The Common Vulnerabilities and
Exposures project identifies the following problems:
CVE-2011-1020
Kees Cook discovered an issue in the /proc filesystem that allows local
users to gain access to sensitive process information after execution of a
setuid binary.
CVE-2011-1576
>> check and conditionally do chmod in an atomic manner.
>
> 0700 on directory prevents hardlink creation, see?
>
Do you still remember about openat()? If the directory was created with 0700
mode from the origin, you would be right, and procfs wouldn't allow opening
files in that directory too, but if you let others to traverse that directory
and open your believed to be secure files from the origin, it's your fault.
--
Sincerely Your, Dan.
Marco
On 29 okt 2009, at 21:10, Jim Paris wrote:
>>> 0700 mode from the origin, you would be right, and procfs wouldn't
>>> allow
>>> opening files in that directory too, but if you let others to
>>> traverse
>>> that directory and open your believed to be secure files from the
>>> origin,
Marco
On 29 okt 2009, at 21:10, Jim Paris wrote:
>>> 0700 mode from the origin, you would be right, and procfs wouldn't
>>> allow
>>> opening files in that directory too, but if you let others to
>>> traverse
>>> that directory and open your believed to be secure files from the
>>> origin,
|
