Next Page >>
file descriptors
>
> 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.
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
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
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
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
>
> 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
> 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
|| > 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
> (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
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
> Dear Pavel,
>
>> ... that's exactly the problem.
>
> I see, the /proc/*/fd/* objects seem "confused": are they symlinks,
> hardlinks, or open file descriptors? I guess should always act as
> the latter, where access mode flags (O_RDONLY or O_RDWR) are set at
> open() and not changeable afterwards in fcntl(). Any open() on them
> should behave as a dup().
>
Paul, in authentic kernels /proc/<PID>/fd/<FD> are symlinks, not anything other.
Descriptors are preserved across exec() unless the FD_CLOEXEC flag is
set.
http://www.opengroup.org/onlinepubs/009695399/functions/execve.html
File descriptors open in the calling process image shall remain
open in the new process image, except for those whose close-on-
exec flag FD_CLOEXEC is set. For those file descriptors that
remain open, all attributes of the open file description remain
unchanged. For any file descriptor that is closed for this reason,
file locks are removed as a result of the close as described in
> %# 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
2. chown() this file to the user's id
3. Open the existing cronjob and copy it into the temp file
4. Call fstat() on the file descriptor to the temp file
5. Call stat() on the temp file's name
6. Compare the inode and device numbers returned by stat() and fstat(),
and abort if not equal
> >Dear Pavel,
> >
> >>... that's exactly the problem.
> >
> >I see, the /proc/*/fd/* objects seem "confused": are they symlinks,
> >hardlinks, or open file descriptors? I guess should always act as
> >the latter, where access mode flags (O_RDONLY or O_RDWR) are set at
> >open() and not changeable afterwards in fcntl(). Any open() on them
> >should behave as a dup().
> >
> Paul, in authentic kernels /proc/<PID>/fd/<FD> are symlinks, not
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
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
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,
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
======
kernel before 2.6.35 might allow local users to gain privileges
or cause a denial of service (system crash) via unspecified
vectors. (CVE-2010-2492)
The xfs_swapext function in fs/xfs/xfs_dfrag.c in the Linux kernel
before 2.6.35 does not properly check the file descriptors passed
to the SWAPEXT ioctl, which allows local users to leverage write
access and obtain read access by swapping one file into another
file. (CVE-2010-2226)
The gfs2_dirent_find_space function in fs/gfs2/dir.c in the Linux
Problem Description:
A vulnerability has been found and corrected in samba:
All current released versions of Samba are vulnerable to a denial of
service caused by memory corruption. Range checks on file descriptors
being used in the FD_SET macro were not present allowing stack
corruption. This can cause the Samba code to crash or to loop
attempting to select on a bad file descriptor set (CVE-2011-0719).
Packages for 2009.0 are provided as of the Extended Maintenance
$ mkdir /tmp/exploit
# Link to an suid binary, thus changing the definition of $ORIGIN.
$ ln /bin/ping /tmp/exploit/target
# Open a file descriptor to the target binary (note: some users are surprised
# to learn exec can be used to manipulate the redirections of the current
# shell if a command is not specified. This is what is happening below).
$ exec 3< /tmp/exploit/target
# This descriptor should now be accessible via /proc.
Last login: Tue Dec 13 12:48:54 2010
[root@localhost~]#nano full-nelson.c
[root@localhost~]#gcc-o full-nelson.c full-nelson
[root@localhost~]#./full-nelson
[*] Failed to open file descriptors.
[root@localhost~]# uname-a
Linux localhost.localdomain 2.6.18-194.26.1.el5 # 1 SMP Thu Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux
[root@localhost~]#
My 10 cents:)
(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.)
Can we continue on lkml?
A benchmark can also imply to analyze the following indicators:
- number of threads ran by process
- size of memory allocated by process/threads
- CPU consumption
- number of open handles, file descriptors, sockets, ...
- command line arguments, environment variables
etc.
You can think 'benchmarking attacks' as a higher level of attacks that also includes timing attacks.
Benchmarking attacks are simply based on all the indicators you can grab to analyze the way a
when that makes sense.
BTW, SIGKILL and SIGSTOP can be issued by an O_ASYNC file I/O also (look in
fcntl(2) at F_SETSIG section). If you use F_SETSIG for sending SIGKILL or
SIGSTOP, there's nothing to be done with that - that behaviour is well
documented and setuid root program must know which file descriptor should be
closed to prevent that, which is of course not possible. The only cure here is
closing every file descriptor above 2, but that is still insufficient, since
fcntl() might be issued on file descriptors from 0 to 2.
> Signals
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.
_______________________________________________________________________
Next Page>>
|
