On Mon, Oct 26, 2009 at 9:01 AM, Tony Finch 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).
Dear Casper and Dan,
> If you can control, 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 http://www.mat
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 l
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
> -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
Asterisk Project Security Advisory - AST-2009-007
++
| Product | Asterisk |
|+---|
Disclaimer: [This code is for Educational Purposes , I would Not be
responsible for any misuse of this code]
[*] Download Page : http://www.cherokee-project.com/download/windows/
[*] Attack type : Remote
[*] Patch Status : Unpatched
[*] Exploitation :
#!/usr/bin/perl
# Cherokee Web Server 0.5
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 lik
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 Wieche
On Oct 23, 2009, at 3:56 PM, Pavel Machek 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 ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1920-1 secur...@debian.org
http://www.debian.org/security/ Stefan Fritsch
October 26, 2009
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
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.
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 secu
Pavel Machek 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 >
>unwritable_file
>#
> >>>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.
>
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//fd/are symlinks ..
On 26.10.2009 18:30, casper@sun.com wrote:
In Solaris, you don't have permission to access a file in /proc//fd unless
you can control the process.
$ ls -l /proc/1/fd
/proc/1/fd: Permission denied
If you can control, then clearly you have access the file anyway
simply by controlling it using
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
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 t
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//fd/ are symlinks ...
> >>>
> >>>They appear
>> 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) cal
Digital Security Research Group [DSecRG] Advisory #DSECRG-09-010
http://dsecrg.com/pages/vul/show.php?id=110
Application:Oracle Database 10G
Versions Affected: Oracle 9.2.0.8, 9.2.0.8DV, 10.1.0.5, 10.2.0.4
Vendor URL: http://oracle.com
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200910-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1919-1 secur...@debian.org
http://www.debian.org/security/ Thijs Kinkhorst
October 25, 2009
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1918-1 secur...@debian.org
http://www.debian.org/security/ Thijs Kinkhorst
October 25, 2009
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 un
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().
On 26.10.2009 13:54, p...@maths.usyd.edu.au wrote:
Dear Dan,
... in authentic kernels /proc//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
Jetty 6.x and 7.x Multiple Vulnerabilities
Name Multiple Vulnerabilities in Jetty
Systems Affected Jetty 7.0.0 and earlier versions
Severity Medium
Impact (CVSSv2) Medium 5/10, vector: (AV:N/AC:L/Au:N/C:P/I:N/A:N)
Vendorhttp://www.mortbay.org/jetty/
Advis
Advisory
Date2009-10-26
Program squidGuard
URL http://squidguard.org/
Found byMatthieu BOUTHORS
Application description
SquidGuard is a URL redirector used to use blacklists with the proxysoftware
Squid. There are two big
> >
> > 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
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:
>
>
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 permiss
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//fd/ are symlinks ...
> >
> >They appear to /bin/ls as symlinks, but observation suggests that they
> >"act" as hardlinks. Could that be fixed som
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//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
On 24.10.2009 20:59, Anton Ivanov wrote:
Not to tell about
that /proc//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 c
Dear Dan,
> ... in authentic kernels /proc//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 bugtraq
[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
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 wa
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, t
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//fd/ are symlinks ...
They appear to /bin/ls as symlinks, but observation suggests that they
"act" as hardlin
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
>
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
permissio
===
Summary
===
Name: SharePoint Team Services source code disclosure through download
facility
Release Date: 21 October 2009
Reference: NGS00532
Discover: Daniel Martin
Vendor: Microsoft
Systems Affected: SharePoint 2007 (12.0.0.6219, 12.0.0.4518 and
possibly others)
Risk: Medium
Status:
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 exp
http://retrogod.altervista.org/
software site: http://www.runcms.org/
vulnerable code in /modules/forum/post.php near lines 16-34 :
...
if ( empty($_POST['forum']) ) {
redirect_header("index.php", 2, _MD_ERRORFORUM);
exit();
}
else if ( e
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 thi
Product:
Novell eDirectory 8.8 SP5 for Windows
Vulnerability Type:
Buffer Overflow
Attack Vector:
Network Request
Where:
>From Remote or Local Network
Solution:
Unpatched
Description:
Vulnerability is in dhost module.
A malformed http get request (to /dhost/modules?L:) cause a buff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1917-1 secur...@debian.org
http://www.debian.org/security/ Giuseppe Iuculano
October 24, 2009
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1916-1 secur...@debian.org
http://www.debian.org/security/ Giuseppe Iuculano
October 23, 2009
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-1912-2 secur...@debian.org
http://www.debian.org/security/ Steffen Joeris
October 23, 2009 h
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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
___
Mandriva Linux Security Advisory MDVSA-2009:288
http://www.mandriva.com/security/
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 co
> >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 c
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 permissio
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 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 06
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 Linu
-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 h
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
63 matches
Mail list logo
