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
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
will be accessed as an
Marco Verschuur wrote:
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.
Yes, I totally agree.
Therefor it's totally of no influence what you do with the original
Jim,
Sorry, but your 'prove' below is wrong!
You are opening the locked down file as root and passing that
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,
Pavel,
Proc does not need to be fixed, because /proc is referring to a file
inode.
And due to the fact that it's being presented in /proc as an fd, you
treat it
as an fd, therefor your expectations do not match.
Your assumptions is; because you accessed the world writable file via
a
Hi!
(no html, please).
Proc does not need to be fixed, because /proc is referring to a file
inode.
Well, that does not mean /proc does not need fixing.
You are expecting transactional behavior in /proc, where /proc only
registers object information.
...
And I think you
... another solution -- allow fcntl() to remove read-only and
append-only limitations, so that behaviour is at least explicit.
Do not lower security, just to emulate /proc sloppiness. (That would be
like fixing a root security bug by doing away with the root password.)
Is there anything
On Wed, Oct 28, 2009 at 10:30:37PM +0100, Pavel Machek wrote:
On Tue 2009-10-27 11:49:32, CaT wrote:
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
and testing them. Remember the scenario from the original mail and try
finding a window, during which creating a hardlink
Dear Dan,
You wrote:
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
Hi!
Not that I would have expected anything different considering who posted
it in the first place.
Thus Debian kernel team should be blamed for that misbehaviour. Don't
worry,
hardlinks behave just the same way, as you describe. Use authentic Linux
kernels, if you dislike
On Tue 2009-10-27 11:49:32, CaT wrote:
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
and testing them. Remember the scenario from the original mail and try
finding a window, during which creating a hardlink would still work thus
evading directory permissions check.
The
On Tue, Oct 27, 2009 at 08:09:57PM +0300, Dan Yefimov wrote:
|| On 27.10.2009 14:04, Vincent Zweije wrote:
|| After chmodding the directory to 0700, *first*
|| check the link count, *then* chmod the file to 0666:
||
|| User1 creates file with permissions 0644
||
Hi!
That race is easily fixed.
No, you're not right.
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
On Tue, Oct 27, 2009 at 03:34:04PM -0500, Derek Martin wrote:
$ mkdir foo
$ cd foo
$ echo hi bar
$ ls -la
total 12
drwxr-xr-x 2 user1 group1 4096 2009-10-27 16:22 ./
drwx-- 57 user1 group1 4096 2009-10-27 16:22 ../
-rw-r--r-- 1 user1 group13 2009-10-27 16:22 bar
$ chmod 000 .
On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
My buy.. :-( I persumed a re-use of the read-only FD, but that's not
the case.
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
On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
No, you're not right.
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
p...@maths.usyd.edu.au wrote:
According to POSIX, if you open the directory with O_SEARCH then openat()
does not re-check search (+x) permissions.
My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
But anyway... even if openat() does not re-check permissions, it
On Thu 2009-10-29 18:24:01, Dan Yefimov wrote:
On 29.10.2009 0:27, Pavel Machek wrote:
That race is easily fixed.
No, you're not right.
After chmodding the directory to 0700, *first*
check the link count, *then* chmod the file to 0666:
User1 creates file with permissions 0644
On Tue, Oct 27, 2009 at 4:29 AM, Tony Finch d...@dotat.at wrote:
According to POSIX, if you open the directory with O_SEARCH then openat()
does not re-check search (+x) permissions.
I stand corrected. (Though my test system doesn't appear to have O_SEARCH.)
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
My buy.. :-( I persumed a re-use of the read-only FD, but that's not
the case.
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
On Mon, Oct 26, 2009 at 07:37:38PM +0100, Ansgar Wiechers wrote:
On 2009-10-24 Derek Martin wrote:
1. It circumvents the fact that to write to a file, you MUST be able
to write to its directory, so that the file attributes can be updated.
Wrong, because the file's attributes aren't stored
Tony Finch d...@dotat.at wrote:
According to POSIX, if you open the directory with O_SEARCH then openat()
does not re-check search (+x) permissions.
My 2.6.26 kernel (or Debian lenny) does not seem to know about O_SEARCH.
But anyway... even if openat() does not re-check permissions, it should
On Sat, Oct 24, 2009 at 10:36:11PM +0400, Dan Yefimov scribbled thusly:
Thus Debian kernel team should be blamed for that misbehaviour. Don't
worry, hardlinks behave just the same way, as you describe. Use authentic
Linux kernels, if you dislike that.
Shall we blame Red Hat too? Just tested
Tony Finch d...@dotat.at wrote:
Attacker opens [directory] and waits. ...
Attacker uses openat() to open and modify the private file.
Surely if the permissions do not allow lookup then openat() will fail.
[The attacker opened directory when it was searcheable; then permissions
were closed;
On Tue, Oct 27, 2009 at 12:29:09AM +0300, Dan Yefimov wrote:
and testing them. Remember the scenario from the original mail and try
finding a window, during which creating a hardlink would still work thus
evading directory permissions check.
The main thing this does is allow a hardlink-like
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
||
On Mon, 26 Oct 2009, Matthew Dempsky wrote:
On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch d...@dotat.at wrote:
Attacker uses openat() to open and modify the private file.
At least with Linux 2.6.18, you still need +x permission on the
directory to access its contents using openat(2).
Marco Verschuur ma...@osp.nl wrote:
And due to the actual file permissions the read-only fd can easily
changed to read-write.
How would you do that? Cannot use fcntl() as that would not let you.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School
Hi!
pa...@toy:/tmp$ uname -a
Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
GNU/Linux
pa...@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits.
...
pa...@toy:/tmp/my_priv$ cat unwritable_file
this file should never be writable
Attacker uses
Why not?!?
File permissions allow everybody write access to the file.
The path via /proc to the file has been created when the initial path
via /tmp was wide open.
Closing the initial path via /tmp has no effect on the /proc path
And due to the actual file permissions the read-only fd can
On Mon 2009-10-26 16:05:18, Tamber Penketh wrote:
On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
Check it again. There's no race; I check link count before chmod 666.
And between checking the link count and the chmod?
At that point directory permissions will already disallow any
On 26.10.2009 23:05, Isara Beaumont wrote:
Dan Yefimov said:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dan Yefimov wrote:
Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an
attacker? No, that was the owner of 'unwritable_file', nobody else. What
the 0666 file mode means? It means, that everybody can write to the
file, can't he?
On Sat 2009-10-24 01:24:49, Dan Yefimov wrote:
On 24.10.2009 1:08, Pavel Machek wrote:
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
On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who issued 'chmod 0666
On 24.10.2009 2:05, Pavel Machek wrote:
On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please
On 24.10.2009 1:56, Pavel Machek wrote:
Now... go back to my original email:
%pa...@toy:/tmp/my_priv$ chmod 700 .
%# 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
Original owner did chmod 666... after making sure traditional unix
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
On 24.10.2009 2:39, Pavel Machek wrote:
Original owner did chmod 666... after making sure traditional unix
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
Dear Pavel,
... can you see a way to write to that file when /proc is unmounted?
While there is legitimate access to do so (after file is created and
before pavel issues 'chmod 700 /tmp/my_priv'), guest to use commands:
ln /tmp/my_priv/unwritable_file /tmp/hardlink-to-object
and then use
Pavel Machek wrote:
So what did happen? User guest was able to work around directory
permissions in the background, using /proc filesystem.
gu...@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
On Fri, Oct 23, 2009 at 11:57:58PM +0400, Dan Yefimov wrote:
That can hardly be called a real security hole, since the behaviour
described above is expected, and is as it was conceived by design.
Lots of security holes can fall into that category! The code matches
its design, and works as
Following your logic we should all abandon directory permissions and
stick to file-only ones. Hmm... Dunno, probably the blood level in my
coffee subsystem is too high this morning, but I do not quite relish
that idea.
There is a very valid case of trying to restrict access via directory
On Mon 2009-10-26 13:42:17, Dan Yefimov wrote:
On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
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,
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as
On 24.10.2009 10:47, Anton Ivanov wrote:
Following your logic we should all abandon directory permissions and
stick to file-only ones. Hmm... Dunno, probably the blood level in my
coffee subsystem is too high this morning, but I do not quite relish
that idea.
I didn't affirm that. I only told,
On Sun, 25 Oct 2009, Pavel Kankovsky wrote:
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.
I stand corrected. He did it--in a comment:
# check link count on unwritable_file. We would not want
[snip]
If the application sets wrong permissions on files, it is by definition
broken.
Yes, setting more restrictive directory permissions can to some extent
mitigate
the problem, but not really fix it. What if that application is used by
multiple
users?
There have been cases and
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not make much sense to me...)
BTW: did you notice how
On 24.10.2009 20:59, Anton Ivanov wrote:
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
On Sat, 2009-10-24 at 21:39 +0400, Dan Yefimov wrote:
On 24.10.2009 20:59, Anton Ivanov wrote:
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
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as hardlinks. Could that be fixed somehow? (I
On 24.10.2009 22:05, Anton Ivanov wrote:
It works on Debian 2.6.26 out of the box. It is not an obscure patched
kernel case I am afraid.
If you redir an FD to a file using thus redir-ed FD in /proc allows you
to bypass directory permissions for where the file is located.
Thankfully, file
On Sat 2009-10-24 10:47:38, p...@maths.usyd.edu.au wrote:
Dear Pavel,
... can you see a way to write to that file when /proc is unmounted?
While there is legitimate access to do so (after file is created and
before pavel issues 'chmod 700 /tmp/my_priv'), guest to use commands:
ln
Not that I would have expected anything different considering who posted
it in the first place.
Thus Debian kernel team should be blamed for that misbehaviour. Don't worry,
hardlinks behave just the same way, as you describe. Use authentic Linux
kernels, if you dislike that.
Just
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
act as hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not
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().
Consider this scenario, pavel's actions are the same as in yours:
pavel guest: cd /tmp
pavel: mkdir my_priv; cd my_priv
pavel: echo this file should never be writable unwritable_file
guest: mkdir pirate_chest
guest: ln my_priv/unwritable_file pirate_chest
pavel: chmod 700 .
pavel: chmod 666
On 25.10.2009 2:40, p...@maths.usyd.edu.au wrote:
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
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?
Do your homework and test it. You can't create the hardlink - the link(oldpath,
newpath) call
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FD are symlinks ...
They appear to /bin/ls as
Pavel Machek wrote:
On Sat 2009-10-24 01:12:51, Dan Yefimov wrote:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who
On Sat, Oct 24, 2009 at 02:31:47AM +0400, Dan Yefimov wrote:
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
On 26.10.2009 18:30, casper@sun.com wrote:
In Solaris, you don't have permission to access a file in /proc/pid/fd unless
you can control the processpid.
$ ls -l /proc/1/fd
/proc/1/fd: Permission denied
If you can controlpid, then clearly you have access the file anyway
simply by
On 26.10.2009 18:26, Pavel Machek wrote:
On Mon 2009-10-26 18:11:56, Dan Yefimov wrote:
On 26.10.2009 18:06, Pavel Machek wrote:
On Mon 2009-10-26 15:37:50, Dan Yefimov wrote:
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc/PID/fd/FDare
guest certianly does not have permission to ptrace() pavel's
processes, so...
But guest has permissions to ptrace() his own processes. If we
remember your original report, he abuses input redirection of bash
run by himself. So again, there's no real security hole here.
guest abuses
Pavel Machek pa...@ucw.cz wrote:
pa...@toy:/tmp$ uname -a
Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel
GNU/Linux
pa...@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits.
pa...@toy:/tmp/my_priv$ echo this file should never be writable
On 26.10.2009 18:58, Pavel Machek wrote:
guest certianly does not have permission to ptrace() pavel's
processes, so...
But guest has permissions to ptrace() his own processes. If we
remember your original report, he abuses input redirection of bash
run by himself. So again, there's no real
On Friday 23 October 2009 23:39:24 Pavel Machek wrote:
Check it again. There's no race; I check link count before chmod 666.
And between checking the link count and the chmod?
signature.asc
Description: This is a digitally signed message part.
Am Samstag, den 24.10.2009, 01:12 +0400 schrieb Dan Yefimov:
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who issued
On Oct 23, 2009, at 3:56 PM, Pavel Machek pa...@ucw.cz wrote:
Demonstrate how to get access to the file with /proc unmounted and you
have a point. Demonstrate how to get access on anything else then
Linux and you have a point. Otherwise there's a security hole.
If the directory is mounted via
On 2009-10-24 Derek Martin wrote:
1. It circumvents the fact that to write to a file, you MUST be able
to write to its directory, so that the file attributes can be updated.
Wrong, because the file's attributes aren't stored in the directory, but
in the respective inode.
Regards
Ansgar
Dan Yefimov said:
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
-Original Message-
From: nom...@nomail.com [mailto:nom...@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
On 26.10.2009 18:14, nom...@nomail.com wrote:
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?
Do your homework and test it. You can't create
Pavel Machek wrote:
Check it again. There's no race; I check link count before chmod 666.
Which creates a race condition, as the link could be created after the
check but before the chmod.
You can't safely rely upon directory permissions if the directory was
created 0777 then chmod'ed down
Dear Casper and Dan,
If you can controlpid, then clearly you have access the file anyway
simply by controlling it using a debugger.
Sorry, but no. The attacker has the file opened O_RDONLY, and cannot
upgrade that to O_RDWR.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au
On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch d...@dotat.at wrote:
Attacker uses openat() to open and modify the private file.
At least with Linux 2.6.18, you still need +x permission on the
directory to access its contents using openat(2).
Hi!
This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...
Jamie Lokier said:
a) the current permission model under /proc/PID/fd has a security
hole (which Jamie is worried about)
I believe its bugtraq
On 23.10.2009 21:16, Pavel Machek wrote:
Hi!
This is forward from lkml, so no, I did not invent this
hole. Unfortunately, I do not think lkml sees this as a security hole,
so...
Jamie Lokier said:
a) the current permission model under /proc/PID/fd has a security
hole (which Jamie is
pa...@toy:/tmp/my_priv$ chmod 700 .
# 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?
pa...@toy:/tmp/my_priv$ chmod 666 unwritable_file
On 24.10.2009 0:35, Matthew Bergin wrote:
doesnt look like the original owner is trying to write to it. Shows it
cant, it had guest write to it via the proc folders bad permissions.
Looks legitimate
Please tell me, who issued 'chmod 0666 unwritable_file'? Was that an attacker?
No, that was the
83 matches
Mail list logo
