Next Page >>
file descriptor
>
> The /proc/self/fd/X appears to be a symlink, but it is not; it
> operates on underlying objects directly. And IMNSHO it should honor
> restrictions opened filedescriptors have, like append-only or
> read-only.
/proc/self/fd/X is something virtual, not something real. It is
state as held by the kernel, it is not persisted anywhere.
On 27.10.2009 14:04, Vincent Zweije wrote:
> On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
>
> || User1 creates file with permissions 0644
> || User2 opens file for read access on file descriptor 4
> || User1 chmod's directory to 0700
> || User1 chmod's file to 0666
> || User1 verifies no hard links to file
> || User2 can not open the file for read or write access
> || User2 can not write to file descriptor 4
On Mon, Oct 26, 2009 at 12:14:36PM -0400, Stephen Harris wrote:
|| User1 creates file with permissions 0644
|| User2 opens file for read access on file descriptor 4
|| User1 chmod's directory to 0700
|| User1 chmod's file to 0666
|| User1 verifies no hard links to file
|| User2 can not open the file for read or write access
|| User2 can not write to file descriptor 4
|| User2 _can_ write to /proc/$$/fd/4
Hi!
> There are two conceivable approaches to implementing the open() for
> a filedescriptor shown in /proc. Either go throuh the inode and
> check the access permissions on the file at the current time
> (which is a sensible implementation and what the kernel seems
> to be currently doing), or implement it as a dup() and transfer
> of the filedescriptor. (Tranfering open filedescriptors between
> processes can also be done by IPC). Implemetenting it via dup()
> would probably keep the original filedescriptor attributes
> On 24.10.2009 1:56, Pavel Machek wrote:
> >a) this kind of hardlink does not exist when /proc is mounted (and on
> >non-Linux)
> >(and c) writing to file descriptor opened read-only is bad).
> Did you think of creating a hardlink to the file in an unrestricted
> location?
Pavel considered that in his original mail, where he checked there were
I replayed it on a test-box and did some strace meanwhile and also
took a look
at the sourcecode of kernel/fs/proc.
It seems that the /proc filedescriptor is directly referring the file
inode
When creating this proc-entry the user guest did have access to the
file and the path via tmp,
therefore a successfull filedescriptor straight to the file inode is
being created, while checking
|| > After chmodding the directory to 0700, *first*
|| >check the link count, *then* chmod the file to 0666:
|| >
|| > User1 creates file with permissions 0644
|| > User2 opens file for read access on file descriptor 4
|| > User1 chmod's directory to 0700
|| > User1 verifies no hard links to file
||
|| Here's a window, during which User2 is able to create a hardlink
|| and that will remain unnoticed by User1. There's no way to perform
>
> I replayed it on a test-box and did some strace meanwhile and also
> took a look
> at the sourcecode of kernel/fs/proc.
>
> It seems that the /proc filedescriptor is directly referring the
> file inode
> When creating this proc-entry the user guest did have access to the
> file and the path via tmp,
> therefore a successfull filedescriptor straight to the file inode is
> being created, while checking
Topic: array overrun in RPC library used by kadmind
CVE-2008-0947, CVE-2008-0948
VU#374121
Use of high-numbered file descriptors in the RPC library, used by
kadmind, can cause references past the end of an array.
CVSSv2 Vector: AV:N/AC:L/Au:N/C:C/I:C/A:C/E:P/RL:T/RC:C
CVSSv2 Base Score: 10
Topic: array overrun in RPC library used by kadmind
CVE-2008-0947, CVE-2008-0948
VU#374121
Use of high-numbered file descriptors in the RPC library, used by
kadmind, can cause references past the end of an array.
CVSSv2 Vector: AV:N/AC:L/Au:N/C:C/I:C/A:C/E:P/RL:T/RC:C
CVSSv2 Base Score: 10
Asterisk Project Security Advisory - AST-2011-005
Product Asterisk
Summary File Descriptor Resource Exhaustion
Nature of Advisory Denial of Service
Susceptibility Remote Unauthenticated TCP Based Sessions (TCP SIP,
Skinny, Asterisk Manager Interface, and HTTP sessions)
Severity Moderate
Exploits Known Yes
Reported On March 18, 2011
fd as input to the nobody process.
So nobody is not opening /dir/file.txt (he can't because he hasn't
access to it via /dir) but root is...
Therefor the write to the fd is failing, because you're passing a
read-only file descriptor.
Try to replay your scenario in separate shells, without the use of
sudo and redirection.
Best regards,
Jim,
Your assumption that the same file descriptor is being re-opened is
wrong!
The file descriptor retrieved via /proc is a new one. It is not the
same as the
initial read-only.
Do a strace on your test and you will see that the 'file descriptor'
in /proc
> (To recap:
>
> While file permissions allow writing, directory permissions do not
> allow any access at all.
>
> guest has open file descriptor for reading.
>
> Trouble is that guest can upgrade file descriptor to one that allows
> writing.)
>
Enough substituting terms. guest doesn't upgrade file descriptors, he only gets
> %# relax file permissions, directory is private, so this is safe
> %# check link count on unwritable_file. We would not want someone
> %# to have a hard link to work around our permissions, would we?
> %pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
>
> Yes, you are right, open file descriptor acts as a kind of hardlink
> here. Except that
>
> a) this kind of hardlink does not exist when /proc is mounted (and on
> non-Linux)
>
templates, which allows remote attackers to conduct cross-site
scripting (XSS) attacks and HTTP response splitting attacks via vectors
related to (a) the product's web interface, (b) the configuration of
the print system, and (c) the titles of printed jobs (CVE-2009-2820).
Use-after-free vulnerability in the abstract file-descriptor handling
interface in the cupsdDoSelect function in scheduler/select.c in the
scheduler in cupsd in CUPS 1.3.7 and 1.3.10 allows remote attackers
to cause a denial of service (daemon crash or hang) via a client
disconnection during listing of a large number of print jobs, related
to improperly maintaining a reference count. NOTE: some of these
templates, which allows remote attackers to conduct cross-site
scripting (XSS) attacks and HTTP response splitting attacks via vectors
related to (a) the product's web interface, (b) the configuration of
the print system, and (c) the titles of printed jobs (CVE-2009-2820).
Use-after-free vulnerability in the abstract file-descriptor handling
interface in the cupsdDoSelect function in scheduler/select.c in the
scheduler in cupsd in CUPS 1.3.7 and 1.3.10 allows remote attackers
to cause a denial of service (daemon crash or hang) via a client
disconnection during listing of a large number of print jobs, related
to improperly maintaining a reference count. NOTE: some of these
return CL_SUCCESS;
}
This function, cli_gentempfd, uses a custom function to generate a
(more or less)
unique file name which is then opened, and the file descriptor is returned via
an output parameter.
The problem with this code is that a race condition exists: if the attacker is
able to guess the generated file name, he/she is able to create such a named
file between the call of cli_gentemp() and open(), making it possible to
References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3889
Description:
Previous versions of the postfix package are vulnerable to a local
Denial of Service attack due to a file-descriptor leak during execution
of external commands (as may be found in a .forward file, for example).
http://wiki.rpath.com/Advisories:rPSA-2008-0311
Copyright 2008 rPath, Inc.
When a process opens a file (and other file system objects, such as
directories), it specifies access flags indicating its intent to read,
write, or perform other operations. These flags are checked against
file system permissions, and then stored in the resulting file
descriptor to validate future operations against.
The sendfile(2) system call does not check the file descriptor access
flags before sending data from a file.
III. Impact
Description
===========
lighttpd contains a calculation error when allocating the global file
descriptor array (CVE-2008-0983). Furthermore, it sends the source of a
CGI script instead of returning a 500 error (Internal Server Error)
when the fork() system call fails (CVE-2008-1111).
Impact
======
The Common Vulnerabilities and Exposures project identifies the
following problems:
CVE-2008-0983
lighttpd 1.4.18, and possibly other versions before 1.5.0, does not
properly calculate the size of a file descriptor array, which allows
remote attackers to cause a denial of service (crash) via a large number
of connections, which triggers an out-of-bounds access.
CVE-2007-3948
connections.c in lighttpd before 1.4.16 might accept more connections
Hanno boeck reported an error in libclamav/chmunpack.c when processing
CHM files (CVE-2008-1389). Other unspecified vulnerabilites were also
reported, including a NULL pointer dereference in libclamav
(CVE-2008-3912), memory leaks in freshclam/manager.c (CVE-2008-3913),
and file descriptor leaks in libclamav/others.c and libclamav/sis.c
(CVE-2008-3914).
Impact
======
Problem Description:
A vulnerability in Postfix 2.4 and later was discovered, when
running on Linux kernel 2.6, where a local user could cause a denial
of service due to Postfix leaking the epoll file descriptor when
executing non-Postfix commands (CVE-2008-3889).
The updated packages have been patched to correct this issue.
_______________________________________________________________________
primitives: BSD kqueue (also present in MacOS X), Linux epoll, and
Solaris /dev/poll. These implement more scalable event handling
than the older select() and poll() primitives.
With 2.6 Linux kernels, Postfix 2.4 and later has an epoll file
descriptor leak when it executes non-Postfix commands in, for
example, a user's $HOME/.forward file. A local user can access a
leaked epoll file descriptor to implement a denial of service attack
on Postfix. The attack may result in reduced Postfix performance,
or in automatic Postfix shutdown when an internal safety mechanism
triggers. Some possible attacks are discussed in the last paragraph
Description
===========
Florian Grandel reported that Syslog-ng does not call chdir() before
chroot() which leads to an inherited file descriptor to the current
working directory.
Impact
======
# su nobody -c 'echo "hacked" > /dir/file.txt'
sh: /dir/file.txt: Permission denied
# cat /dir/file.txt
safe
If we provide an open read-only file descriptor (as stdin, fd 0), they
can read it:
# su nobody -c 'cat <&0' < /dir/file.txt
safe
>>>
>>>> After chmodding the directory to 0700, *first*
>>>> check the link count, *then* chmod the file to 0666:
>>>>
>>>> User1 creates file with permissions 0644
>>>> User2 opens file for read access on file descriptor 4
>>>> User1 chmod's directory to 0700
>>>> User1 verifies no hard links to file
>>>
>>> Here's a window, during which User2 is able to create a hardlink and
>>> that will remain unnoticed by User1. There's no way to perform link
>>
>>> After chmodding the directory to 0700, *first*
>>> check the link count, *then* chmod the file to 0666:
>>>
>>> User1 creates file with permissions 0644
>>> User2 opens file for read access on file descriptor 4
>>> User1 chmod's directory to 0700
>>> User1 verifies no hard links to file
>>
>> Here's a window, during which User2 is able to create a hardlink and
>> that will remain unnoticed by User1. There's no way to perform link
>
> > After chmodding the directory to 0700, *first*
> >check the link count, *then* chmod the file to 0666:
> >
> > User1 creates file with permissions 0644
> > User2 opens file for read access on file descriptor 4
> > User1 chmod's directory to 0700
> > User1 verifies no hard links to file
>
> Here's a window, during which User2 is able to create a hardlink and
> that will remain unnoticed by User1. There's no way to perform link
Next Page>>
|
