EXPLOITS :
DATE : Fri, 8 May 1998 01:33:26 -0700
From: Renos <[email protected]>
To: [email protected]
Subject: NSCA HTTPD (for Windows) bug.
Well, it seems that I found a bug in NCSA's httpd v1.4 (for Windows).
The bug can cause the server to crash. The problem seems to be that
the server has MAX_STRING_LEN defined to 256 characters. So, when a
client's request is larger than 256 characters the server crases.
I tested it on a PC running Windows 3.11, wich I believe are more
stable than Win95, with W32s driver. I TELNETed into the server on
port 80 (using 127.0.0.1 as the IP address). Then using the 'GET'
command I insert more than 256 characters. The server crashed showing
a message asking the user to terminate the program. I haven't try it
yet on other PC, but the problem it's the MAX_STRING_LEN, so it
doesn't make any differents.
The server crashes showing no messages to the clients screen. In the
Access Log files the client's request seems like a normal request nad
Ididn't found anything on Error Log file.I even tested with a Web
Browser calling a file with more than 256 characters and I had the
same results.
Since the server is not for commercial use the bug doesn't seem to be
serious. A fix would be to re-define MAX_STRING_LEN to a much bigger
number. As far as I know the Server Administrator cannot re-define
MAX_STRING_LEN.
Greetings
Renos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 4 May 1998 10:37:35 -0500
From: [email protected]
To: [email protected]
Subject: Netmanage Holes
Hello All,
He's some major holes that I have found in the Netmanage Chameleon
tools. Forwarded the info to Netmanange a few weeks ago, but no
response from them on patches and such.
All seem to exist in the older Chameleon 4.5 as well as the newer
Unixlink 97 tools. Most of the testing was done with NetCat for NT
on NT 3.51 and 4.0
Notes: Anything listed as a 'Buffer Overflow' means that a NT Dr.Watson
message was produced with the 'Exception: access violation' message. This
may or may not be an exploitable buffer overflow condition, but it
definitely looks like the programs are not always doing sanity checks on
user input.
1 - FTP server. You must have at least one user defined on the server.
-- Buffer overflows with username. Username needs more than 150 chars
to overrun. Very similar to the WAR FTPd probs.
-- passwd with lots of chars causes a 'local error processing' to
scroll on the screen.
2 - HTTP server [personal web server]. Not sure what exactly is
happening here, but if a URL request longer than 519 chars is
submitted to the server, it spontaneously unloads.....never produces
an error message.
example: GET more_than_519_characters<cr><cr>
3 - Email/Zmail -- The email package comes with both client and server
functions. POP3d and SMTPd are enabled while the email client is active.
POP3d
-- buffer overflow with 'USER username' and username over 152 chars
-- buffer overflow with 'PASS passwd' and password over 104 chars
-- buffer overflows with all of the commands [list, retr, dele, quit].
Don't even have to log in. Even QUIT with a bunch of garbage after
it will cause the POP3d to crash..........
SMTPd
-- buffer overflow with 'HELO hostname' and hostname over 471 chars.
-- buffer overflow with 'HELP topic' and topic over 514 chars.
4 - Finger client -- If you setup netcat to listen on the finger port,
and send back a reply of over 257 chars to any finger request from the
Chameleon client, an overflow will occur at the finger
client....strange, but who really uses finger anyway.... ;)
These are the only utilities that I have really looked into -- But
they all seem to have problems with validity checks. I have not
built test exploits yet, but there is a definate possibility that
some of these bugs are exploitable. They are definately DOS bugs.
Regards,
Anton Rager
[email protected]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Date: Fri, 1 May 1998 04:12:33 -0600 (MDT)
From: mea culpa <[email protected]>
To: InfoSec News <[email protected]>
Subject: [ISN] RSI.0001.05-01-98.ALL.QUAKE_SERVER
Forwarded From: RSI Advise <[email protected]>
RSI.0001.05-01-98.ALL.QUAKE_SERVER
|:::. |::::: |::::. |::::: |::::: |::::.
.. :: .. .. :: .. .. .. ::
|:::: |:::: |:::: :::::: |::::: |:::: |:
|: :: |: |: |:: |: |: ::
|: :: |::::: |: |::::: |::::: |:::::
Repent Security Incorporated, RSI
[ http://www.repsec.com ]
*** RSI ALERT ADVISORY ***
--- [CREDIT] ---------------------------------------------------------------
Vulnerability found by: Mark Zielinski <[email protected]>
Advisory Author: Mark Zielinski
--- [SUMMARY] --------------------------------------------------------------
Announced: May 1st, 1998
Report code: RSI.0001.05-01-98.ALL.QUAKE_SERVER
Report title: Vulnerability in the Quake server
Vulnerability: RCON (Remote Console)
Patch status: None currently available
Platforms: Quake 1/2, QuakeWorld, Linux/Solaris Quake2
Reference: http://www.repsec.com/advisories.html
Impact: If exploited, an attacker could remotely compromise
administrator access on any Quake server.
--- [DETAILS] --------------------------------------------------------------
Problem: The Quake server has a feature where it allows
administrators to remotely send commands to the Quake
console with a password. However, it is possible to
remotely bypass authentication.
In order for this to be exploited, the attacker would
have to create a handcrafted udp packet with a header
containing the rcon command and the password "tms" with
a source IP coming from ID Software's Subnet. (192.246.40)
The Quake server does not require an open connection for
sending the rcon packet. When this is exploited, no logs
are reported of the rcon command being used.
This vulnerability is present in Quake 1, QuakeWorld,
Quake 2, Quake 2 Linux and Quake 2 Solaris, all versions.
--- [FIX] ------------------------------------------------------------------
Solution: Filter all incoming packets from the subnet 192.246.40.
--- [PATCH] ----------------------------------------------------------------
Solution: No patches are currently available.
----------------------------------------------------------------------------
Repent Security Incorporated (RSI)
[email protected]
13610 N. Scottsdale Rd.
Suite #10-326
Scottsdale, AZ 85254
[ http://www.repsec.com ]
----------------------------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzU6dqAAAAEEAOHt9a5vevjD8ZjsEmncEbFp2U7aeqvPTcF/8FJMilgOVp75
dshXvZixHsYU7flgCNzA7wLIQPWBQBrweLG6dx9gE9e5Ca6yAJxZg8wNsi06tZfP
nvmvf6F/7xoWS5Ei4k3YKuzscxlyePNNKws6uUe2ZmwVoB+i3HHT44dOafMhAAUT
tBpSZXBTZWMgPGFkdmlzZUByZXBzZWMuY29tPg==
=ro8H
-----END PGP PUBLIC KEY BLOCK-----
Copyright April 1998 RepSec, Inc.
The information in this document is provided as a service to customers
of RepSec, Inc. Neither RepSec, Inc., nor any of it's employees, makes
any warranty, express or implied, or assumes any legal liability or
responsibility for the accuracy, completeness, or usefulness of any
information, apparatus, product, or process contained herein, or
represents that its use would not infringe any privately owned rights.
Reference herein to any specific commercial products, process, or
services by trade name, trademark, manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation or
favoring by RepSec, Inc. The views and opinions of authors expressed
herein do not necessarily state or reflect those of RepSec, Inc., and may
not be used for advertising or product endorsement purposes.
The material in this alert advisory may be reproduced and distributed,
without permission, in whole or in part, by other security incident
response teams (both commercial and non-commercial), provided the above
copyright is kept intact and due credit is given to RepSec, Inc.
This alert advisory may be reproduced and distributed, without
permission, in its entirety only, by any person provided such
reproduction and/or distribution is performed for non-commercial
purposes and with the intent of increasing the awareness of the Internet
community.
----------------------------------------------------------------------------