Next Page >>
proc
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 read-only fd, you also expect the file to appear as read-only in /
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
> hard links" can not be seen on link count.
Aye.
> > You can't actually use /proc/*/fd to gain access to files opened by
> > processes you do not own. Only ones you do (at least in a mainline kernel)
> > which is fair enough. This means that you can't have user a open a file
> > owned by user b and then let user c have access to it via
> > /proc/$pid/fd.
>
Making assumptions about directory search and acces permissions
is plain stupid.
>
> 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
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
> >>If the file owner in fact allows writing to it, why should Linux
> >>prevent that from happening?
> >
> >No, I do not think this is expected. You could not write to that file
> >under traditional unix, and you can not write into that file when
> >/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
Hi!
> 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.
True, we were just being sloppy with the words. But it does not matter
one iota.
> >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
> -----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.
> >>
>> If the file owner in fact allows writing to it, why should Linux
>> prevent that from happening?
>
> No, I do not think this is expected. You could not write to that file
> under traditional unix, and you can not write into that file when
> /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
> %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)
>
> b) unlike other hardlinks, you can't see it on the link count
>
> (and c) writing to file descriptor opened read-only is bad).
> > > directory permission. File access has nothing to do with directory
> > > permissions...!
> >
> > Right. However the whole point of this discussion is that that is a
> > non-obvious point, there was no other way that the user could have
> > opened that file without the use of /proc.
>
> The actual fallacy of the "problem report" is the flawed assumption
> about what a link count of 1 tells you.
>
> The link count of a files tells you the number of hard links that
> > 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
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
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
> directory permission. File access has nothing to do with directory
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, because you're passing a
read-only file descriptor.
A quick comment on the TclShell source code (v0.1) included in http://www.irmplc.com/content/pdfs/Creating_Backdoors_in_Cisco_IOS_using_Tcl.pdf
The echo procedure fails to close the client socket on EOF. This will cause the readable fileevent to trigger repeatedly consuming CPU and never freeing the socket. As the Tcl interpreter on Cisco devices has a relatively small number of sockets (255 total system wide if memory serves) repeated connections to the backdoor would exhaust all available (to Tcl) sockets on the device effectively DoS'ing other Tcl scripts and probes running.
I'd recommend rewriting the echo proc as:
proc echo {sock} {
global var
if {[catch {gets $sock line}] ||
Linux Kernel ALSA snd_mem_proc_read Information Disclosure Vulnerability
iDefense Security Advisory 09.25.07
http://labs.idefense.com/intelligence/vulnerabilities/
Sep 25, 2007
I. BACKGROUND
Linux is a clone of the UNIX operating system, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers
> > directory permission. File access has nothing to do with directory
> > permissions...!
>
> Right. However the whole point of this discussion is that that is a
> non-obvious point, there was no other way that the user could have
> opened that file without the use of /proc.
The actual fallacy of the "problem report" is the flawed assumption
about what a link count of 1 tells you.
The link count of a files tells you the number of hard links that
> On Wed, Nov 04, 2009 at 10:17:13AM +1100, psz@maths.usyd.edu.au wrote:
>
> > But, mount requires root (and root can do anything, including shooting
> > himself in the foot).
>
> Irrelevant. The statement was that if /proc is not mounted, then the
> link count tells if there are other ways to access the inode besides the
> path you have used to access it. I showed you that this statement is
> false.
You showed almost nothing. If you assume root interference, he can do
On Sat 2009-10-24 10:47:38, psz@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 /tmp/my_priv/unwritable_file /tmp/hardlink-to-object
>
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 easily
changed to read-write.
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 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
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 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
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 time. Being able to reopen file with additional
> > permissions looks like a security problem...
> >
> 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 time. Being able to reopen file with additional
>>> permissions looks like a security problem...
>>>
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
>> 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.
>
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 this proc-entry the user guest did have access to the
file and the path via tmp,
-rw-r--r-- 1 user1 group1 3 2009-10-27 16:22 bar
$ chmod 000 .
$ echo bye > bar
-bash: bar: Permission denied
The problem with the /proc interface is:
- it is automatic (if /proc is mounted)
- its file access semantics are not identical to the rest of the file system
(e.g. they are not really symlinks, and they are not really hard
links, and the link count is not incremented, and the average
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).
Next Page>>
|
