| New User, Welcome! Login |
Dan Yefimov
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
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
do that.
By tightening up the protection on the directory the sysadmin can
mitigate the problem. It is in fact the standard way of doing this.
On Sat, 2009-10-24 at 01:12 +0400, 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
> >
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.
Instead of making hardlink you run something that keeps an fd open to the
file.
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.
* Dan Yefimov <dan@ns15.lightwave.net.ru> [2007-08-17 05:27 +0400]:
> 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
Looking in that man page I see:
F_GETSIG and F_SETSIG are Linux-specific.
Nicolas
Dan Yefimov wrote:
> > > Really? An what if we fork right after startup and perform operations as a
> > > child?
> >
> > That would work, but might have undesirable consequences of its own.
> >
> > In particular, it prevents a non-malicious caller from using PDEATHSIG
> > to send e.g. SIGINT, which the setuid program may reasonably handle.
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
> the file, can't he? So why do you believe that pretension
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 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 using that symlink.
> >
> > The perms are definitely broken and without a code audit on procfs I
> > would not bet that this is limited just to this rather obscure test
> > case.
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...)
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.
(1) This is WRONG, and I find it interesting that nobody bothered to check
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?
Dan Yefimov wrote:
> > > If setuid program just
> > > trusts the environment in that it doesn't properly handle or block signals
> > > whose default action is terminating the process and doesn't perform it's
> > > actions in a fail-safe manner, it is certainly broken. Setuid program must
> > > always be careful in signal handling and data processing.
> >
> > Ordinarily, a process can assume that certain signals (those which can
Dan Yefimov wrote:
> > > The signal in question in the given situation is issued by PRIVILEGED process,
> > > no matter how.
> >
> > And that's the bug,
>
> The case we consider is of course a bug. But generally privileged process
> sending a signal to another privileged process is of course not a bug.
Dan Yefimov wrote:
> > However, the bug in question allows sending signals which cannot be
> > blocked or ignored (SIGKILL, SIGSTOP). Moreover, the cause (PDEATHSIG)
> > cannot be disabled
>
> Really? An what if we fork right after startup and perform operations as a
> child?
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...)
> >
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.
>
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
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.
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 '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? So why do
> you believe that pretension legitimate?
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 expected... it's just that the author had no
idea what he was getting himself into. =8^)
> If the file owner in fact allows writing to it, why should Linux
> prevent that from happening?
-----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? So why do you believe that pretension legitimate?
I think he means the 0700 on the containing directory for the "unwritable_file".
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 on 2.6.18-164.2.1.el5,
although with a single user since I don't actually run RHEL on
any of my own computers.
Ivan
On Mon 2009-10-26 13:42:17, Dan Yefimov wrote:
> On 25.10.2009 2:40, psz@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 at
> >open() and not changeable afterwards in fcntl(). Any open() on them
On Fri, 17 Aug 2007, Nicolas Rachinsky wrote:
> * Dan Yefimov <dan@ns15.lightwave.net.ru> [2007-08-17 05:27 +0400]:
> > 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
>
> Looking in that man page I see:
> F_GETSIG and F_SETSIG are Linux-specific.
>
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.
Yes, plus it allows "hardlinks" on deleted files, and this "strange
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
|| > User2 opens file for read access on file descriptor 4
|| > User1 chmod's directory to 0700
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
Dan Yefimov wrote:
> > An unprivileged local user may send arbitrary signal to a child process
> > despite security restrictions.
> I'm not sure this is a real security issue. If some process has the same
> effective UID as the given one, the former can always send any signal to the
> latter. Thus the behaviour you described is IMHO normal.
|
|
|
