Pavel Machek
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, psz@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
t
From: WebDawg [mailto:webdawg@gmail.com]
Sent: Thursday, December 03, 2009 1:58 PM
To: Pavel Machek
Cc: Patrick Webster; Thor (Hammer of God); bugtraq@securityfocus.com
Subject: Re: Millions of PDF invisibly embedded with your internal disk paths
While the risk may not be large it is still information that should not be leaked. Leaky computers should always be plugged.
On Thu, Dec 3, 2009 at 4:01 AM, Pavel Machek <pavel@ucw.cz> wrote:
t
From: WebDawg [mailto:webdawg@gmail.com]
Sent: Thursday, December 03, 2009 1:58 PM
To: Pavel Machek
Cc: Patrick Webster; Thor (Hammer of God); bugtraq@securityfocus.com
Subject: Re: Millions of PDF invisibly embedded with your internal disk
paths
While the risk may not be large it is still information that should not be
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 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
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 file descriptor 4
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 would still work thus
> > > evading directory permissions check.
> >
> > The main thing this does is allow a hardlink-like attack to work across
> > mountpoints afaics.
>
On 9/26/2009 5:54 AM, Pavel Machek wrote:
> Well... mujmail.org email client also does not validate ssl
> cerificates -- optionaly. Reasoning is that SSL with unverified
> certificate is still better than sending plaintext passwords.
>
> Does that count as a vulnerability?
Yes; it's not that difficult for someone on the same network segment to
proxy all your traffic, and if you don't check your certificate then you
might as well have sent it plaintext.
Pavel Machek wrote:
>
> > IMHO; no bug or security issue, just a misunderstanding of the
> > mechanism...
Correct. It is a completely flawed assumption.
In Unix, an open() of a file checks access permissions as
specified in the files inode. If someone wants access control
applied to a file, then he MUST do so using the permission in
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 security hole here.
>>>
>>> guest abuses ptrace permissions on his own processes to write to
>>> pavel's files... no, that obviously is not security hole :-).
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?
Pavel Machek <pavel@ucw.cz> wrote:
>
>pavel@toy:/tmp$ uname -a
>Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux
>pavel@toy:/tmp mkdir my_priv; cd my_priv
Attacker opens my_priv and waits.
>pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file
># lock down directory
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
race condition. The 'chmod 700 /tmp/my_priv' should be done before the
file is created, not
afterwards. Otherwise there is a window where the file exists, but hardlink
creation is not prevented by the directory permissions.
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 worried about)
On 24.10.2009 1:56, Pavel Machek wrote:
> Now... go back to my original email:
>
> %pavel@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?
> %pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file
>
> Yes, you are right, open file descriptor acts as a kind of hardlink
On Oct 23, 2009, at 3:56 PM, Pavel Machek <pavel@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 NFS or is exported there are several
ways...so software written to assume directory permissions are
sufficent to protect users from other unpriveliged users is broken in
general. Even if it is usually secure enough on non-Linux. It is not
because that's definitely NOT my intention).
Best regards,
Marco
On 30 okt 2009, at 18:38, Pavel Machek wrote:
> Hi!
>
>> Your assumption that the same file descriptor is being re-opened is
>> wrong!
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 later. It needs to be created with the
On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
> > The link count of a files tells you the number of hard links that
> > are persisted within the same filesystem. It is _NOT_ a promise
> > that there are no other means to access the inode of the file.
>
> It used to be promise before /proc was mounted.
"mount --bind" behaves like a hard link and it does not increment the link
count.
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, psz@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
> 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
> race condition. The 'chmod 700 /tmp/my_priv' should be done before the
> file is created, not
> afterwards. Otherwise there is a window where the file exists, but hardlink
> creation is not prevented by the directory permissions.
>
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
>> 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.
>
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 changes.
Pavel
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
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.
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 file in an unrestricted
> location?
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).
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 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
> >>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.
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, psz@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 make much sense to me...)
Gabor Gombas wrote:
>
> On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
>
> > > The link count of a files tells you the number of hard links that
> > > are persisted within the same filesystem. It is _NOT_ a promise
> > > that there are no other means to access the inode of the file.
> >
> > It used to be promise before /proc was mounted.
|
