Date: Thu, 11 Jun 1998 00:02:38 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 8 Jun 1998 to 10 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980611040447Z80816-31370+24@brimstone.netspace.org>
There are 11 messages totalling 1259 lines in this issue.
Topics of the day:
1.
2. ISSalert: ISS Security Advisory - nisd
3. RSI.0003.05-15-98.HP-UX.RWRITE
4. more named software
5. Scanning Attacks from apple.com are spoofed addresses
6. Correction on IBM "3com" 8237 (and others ?) "feature"
7. AMD K6 Bug
8. Administrivia.
9. Full Armor
10. Sambar Server Beta BUG..
11. Sun Security Bulletin #00171
----------------------------------------------------------------------
Date: Tue, 9 Jun 1998 20:56:26 CDT
From: Aleph One
Subject:
>From aleph1 Tue Jun 9 19:17:05 1998
Return-Path:
X-Received: from coal.cert.org by dfw.dfw.net (4.1/SMI-4.1)
id AA05538; Tue, 9 Jun 1998 19:16:13 CDT
X-Received: (from cert-advisory@localhost) by coal.cert.org (8.6.12/CERT) id RAA21070 for cert-advisory-queue-40; Tue, 9 Jun 1998 17:47:14 -0400
Date: Tue, 9 Jun 1998 17:47:14 -0400
Message-Id: <199806092147.RAA21070@coal.cert.org>
From: CERT Advisory
To: cert-advisory@coal.cert.org
Subject: CERT Advisory CA-98.06 - nisd
Reply-To: cert-advisory-request@cert.org
Organization: CERT(sm) Coordination Center - +1 412-268-7090
ReSent-Date: Tue, 9 Jun 1998 20:56:21 -0500 (CDT)
ReSent-From: Aleph One
ReSent-To: BUGTRAQ@NETSPACE.ORG
ReSent-Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT* Advisory CA-98.06
Original issue date: June 09, 1998
Last revised: --
Topic: Buffer Overflow in NIS+
- -----------------------------------------------------------------------------
The CERT Coordination Center has received a report from Internet
Security Systems regarding a vulnerability in some implementations of
NIS+. The NIS+ service is offered by the rpc.nisd program on many
systems.
We recommend installing a vendor patch as soon as possible. Until you
are able to do that, we encourage you to implement applicable
workarounds as described in section III.
We will update this advisory as we receive additional information.
Please check our advisory files regularly for updates that relate to
your site.
- -----------------------------------------------------------------------------
I. Description
NIS+ and NIS are designed to assist in the administration of
networks by providing centralized management and distribution of
information about users, machines, and other resources on the
network. NIS+ is a replacement for NIS. A buffer overflow exists
in some versions of NIS+. At this time, we do not believe any
versions of NIS are vulnerable to this buffer overflow. Note that
this vulnerability exists independently of the security level at
which the NIS+ server is running.
II. Impact
Depending on the configuration of the target machine, a remote
intruder can gain root access to a vulnerable system or cause
the NIS+ server to crash, which will affect the usability of any
system which depends on NIS+.
Additionally, if your NIS+ server is running in NIS compatibility
mode and if an intruder is able to crash the NIS+ server, the
intruder may be able to masquerade as an NIS server and gain
access to machines that depend on NIS for authentication.
Finally, if an intruder is able to crash an NIS+ server and
there are clients on the local network that are initialized by
broadcast, an intruder may be able to provide false
initialization information to the NIS+ clients. Clients that are
initialized by hostname may also be vulnerable under some
circumstances.
III. Solution
A. Obtain and install a patch from your vendor.
Appendix A contains input from vendors who have provided
information for this advisory. We will update the appendix as
we receive more information. If you do not see your vendor's
name, the CERT/CC did not hear from that vendor. Please
contact your vendor directly.
B. Until you are able to install the appropriate patch, we
recommend the following workaround.
1. As with any software, particularly network services,
if you do not depend on NIS+, we encourage you to disable
it.
C. If you must operate with an unpatched version of NIS+, the
risk may be mitigated using the following strategies.
1. Limit external access to your portmapper by blocking access
to port 111 at your firewall or router. Additionally, if
you have not already done so, apply the patches referenced
in VB-97.03, available at
ftp://ftp.cert.org/pub/cert_bulletins/VB-97.03.sun
Note that restricting access to the portmapper does not
necessarily prevent an intruder from connecting directly
to the port on which NIS+ is running. For this and other
reasons we recommend that any port that is not explicitly
required be blocked at your router or firewall.
2. Configure your system to mark the stack as non-executable.
For example, on Solaris systems running on sun4m, sun4d
and sun4u platforms, the variable noexec_user_stack in the
/etc/system file can be used to mark the stack as
non-executable by default. While this will prevent an
intruder from gaining root access, it will not prevent an
intruder from crashing the NIS+ server. For more
information on the noexec_user_stack variable, see
http://docs.sun.com:80/ab2/coll.47.4/SYSADMIN1/@Ab2PageView/
91907?DwebQuery=executable+stacks
Marking the stack as non-executable is highly dependent on
hardware and software configurations. For information on
marking the stack as non-executable on other platforms,
consult your vendor or operating systems manuals.
3. Initialize newly installed NIS+ clients using a method that
does not rely on unauthenticated network information. For
example, on Solaris systems you can copy the
/var/nis/NIS_COLD_START file from an already existing NIS+
client, and use that file as input to the nisinit command.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Appendix A - Vendor Information
Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, the CERT/CC did not hear from that
vendor. Please contact the vendor directly.
Data General
- ------------
Data General is investigating. They will provide an update when their
investigation is complete.
Digital Equipment Corporation
- -----------------------------
This problem is not present for Digital's ULTRIX or Digital UNIX
Operating Systems Software.
FreeBSD, Inc.
- -------------
FreeBSD is not vulnerable.
Hewlett-Packard Company
- -----------------------
HP-UX is Vulnerable. Patches in process.
IBM Corporation
- ---------------
AIX is not vulnerable.
NEC Corporation
- ---------------
Some NEC systems are vulnerable. Patches are in progress and will be
available from ftp://ftp.meshnet.or.jp/pub/48pub/security.
The NetBSD Project
- ------------------
NetBSD is not vulnerable.
OpenBSD
- -------
OpenBSD is not vulnerable.
The Santa Cruz Operation, Inc.
- ------------------------------
No SCO products are vulnerable.
Sun Microsystems, Inc.
- ----------------------
Patches were released for Solaris 5.4, 5.5, 5.5.1, and 5.6.
The patch numbers are as follows.
5.4 sparc 101973-35
5.4 intel 101974-35
5.5 sparc 103187-38
5.5 intel 103188-38
5.5.1 sparc 103612-41
5.5.1 intel 103613-41
5.6 sparc 105401-12
5.6 intel 105402-12
Sun estimates that a patch for SunOS 5.3 will be available in about 12
weeks. The expected patch number is 101318-91.
- -----------------------------------------------------------------------------
We wish to thank Josh Daymont of ISS who reported the vulnerability
and provided technical assistance.
- -----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
- ----------------------------
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
- ---------------------------------------------------------------------------
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
- ---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.06.nisd
http://www.cert.org/nav/alerts.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNX2Wy3VP+x0t4w7BAQEfzQP+L5Ffb8F0WytM7jpLxbTD3Ft0Yrvv/ZUv
ekltUlT26Q0u2k7llZfXKTiQ0AFFpYULMUl17XFtT2CjBaWvMpttWCBVy2oWdVOZ
xQAJYAMLZdB2jNCJnMSaHZH0v2egyh2qmSKVs4zsNgCmbPIzBOAbq3aJsbA/2zk9
6OUCIItvraM=
=c/k6
-----END PGP SIGNATURE-----
------------------------------
Date: Wed, 10 Jun 1998 09:36:44 -0500
From: Aleph One
Subject: ISSalert: ISS Security Advisory - nisd
Date: Tue, 9 Jun 1998 16:27:42 -0400
From: X-Force
To: alert@iss.net
Subject: ISSalert: ISS Security Advisory - nisd
-----BEGIN PGP SIGNED MESSAGE-----
ISS Security Advisory
June 10, 1998
Remote Buffer Overflow in the rpc.nisd program.
Synopsis:
A stack-based buffer overflow exists in some versions of the
Solaris 2.x rpc.nisd, which allows attackers to gain root access on
the vulnerable machine.
Recommended Action:
Disable the rpc.nisd daemon if you are not running NIS+.
If you are running NIS+, determine if you are vulnerable. If you
are vulnerable, contact Sun for a patch.
Determining if you are vulnerable:
On a Solaris machine, issue the following commands to determine if
you are running rpc.nisd:
solaris% rpcinfo -p localhost | grep 100300
If you see the following output, or something similar, and you
have not installed a patch then you are vulnerable:
100300 3 udp 32773 nisd
100300 3 tcp 32771 nisd
Description:
The rpc.nisd program is an ONC RPC agent that implements the
NIS+ service. Generally, the data sent to an RPC daemon has explicit
maximum length, ensuring that it will not overflow buffers of any
reasonable size. However, one NIS+ argument: nis_name, has no specific
maximum length. In this case the max length defaults to an unsafe value.
Because NIS+ copies this argument onto fixed length buffers in the stack,
an attacker can corrupt the stack and cause the daemon to execute arbitrary
machine code.
Affected Versions:
Solaris 2.3 - 2.6 are vulnerable.
Fix Information:
For Solaris, install one of the following patches:
105401-12: Solaris 5.6
105402-12: Solaris 5.6_x86
103612-41: Solaris 5.5.1
103613-41: Solaris 5.5.1_x86
103187-38: Solaris 5.5
103188-38: Solaris 5.5_x86
101973-35: Solaris 5.4
101974-35: Solaris 5.4_x86
Additional Information:
This problem was discovered by Josh Daymont of ISS
________
Copyright (c) 1998 by Internet Security Systems, Inc.
Permission is hereby granted for the redistribution of this Alert
electronically. It is not to be edited in any way without express consent
of X-Force. If you wish to reprint the whole or any part of this
Alert in any other medium excluding electronic medium, please
email xforce@iss.net 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.
X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html
as well as on MIT's PGP key server and PGP.com's key server.
X-Force Vulnerability and Threat Database: http://www.iss.net/xforce
Please send suggestions, updates, and comments to:
X-Force of Internet Security Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBNX2LajRfJiV99eG9AQH9VQP9EurMFs3YnRkYTeBooLxe9fLCSbNQV9bp
aHVCnhzuJVP3cDHdekLIXQfcN2yFjqKNYUq9QpuQjcyIWYdQMyBTEAfYcHGQD5JY
EYzC+YYKRMB5vgZzgel+gDHSgHpOdOtIA1eWJso3S3AezMJFCXPcYRblC/FMSPji
gd4LNCo5XVM=
=VNGV
-----END PGP SIGNATURE-----
------------------------------
Date: Mon, 8 Jun 1998 17:32:28 -0700
From: RSI Advise
Subject: RSI.0003.05-15-98.HP-UX.RWRITE
RSI.0003.05-15-98.HP-UX.RWRITE
|:::. |::::: |::::. |::::: |::::: |::::.
.. :: .. .. :: .. .. .. ::
|:::: |:::: |:::: :::::: |::::: |:::: |:
|: :: |: |: |:: |: |: ::
|: :: |::::: |: |::::: |::::: |:::::
Repent Security Incorporated, RSI
[ http://www.repsec.com ]
*** RSI ALERT ADVISORY ***
--- [CREDIT] --------------------------------------------------------------
'Bwana Brian': Research and development
Mark Zielinski: Author of advisory
--- [SUMMARY] -------------------------------------------------------------
Announced: May 15, 1998
Report code: RSI.0003.05-15-98.HP-UX.RWRITE
Report title: HP-UX rwrite/rlpdaemon
Vulnerability: Remote users can send commands to your terminal via
escape sequences sent to the rlpdaemon
Vendor status: Sun, 31 May 1998
Patch status: No patch currently available
Platforms: HP-UX 9.X, 10.X
Vulnerable: Systems running rlpdaemon where users use hpterm
Reference: http://www.repsec.com/advisories.html
Impact: If exploited, an attacker could remotely compromise an
account on your system, including root
--- [DETAILS] -------------------------------------------------------------
Problem: If a user has an hpterm session logged in to an HP-UX that
is running rlpdaemon, it is possible for an attacker to
remotely compromise the active account.
By sending carefully selected packets to the rlpdaemon, an
attacker can force a user's terminal to display a message
that contains escape sequences with embedded commands that
reprogram the soft-keys of the hpterm, allowing for arbitrary
playback and key remapping. The user does not need to have
'mesg y' on for this to happen.
This problem is present in any HP-UX running the current
version of rlpdaemon.
--- [FIX] -----------------------------------------------------------------
Solution: Disable rlpdaemon until Hewlett-Packard can provide
a patch.
--- [PATCH] ---------------------------------------------------------------
Solution: No patches are currently available.
---------------------------------------------------------------------------
Repent Security Incorporated (RSI)
advise@repsec.com
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 express
herein do no necessarily state or reflect those of RepSec, Inc., and may
not be used for advertising or product endorsement purposes.
RSI Member Alert Advisories are expressly prohibited from release of any
and all information contained in this advisory, in any and all forms
into the public domain by RepSec Members, their personnel, or other
related or affiliated personnel, to other advisory groups and/or other
security incident response teams (both commercial and non-commercial) -
during the period RSI Member Alert Advisories are released to RSI
Member's only. The material in this advisory alert may be reproduced
and distributed, without permission, only after it has been released by
RepSec, Inc. into the public domain. After release by RepSec, Inc. into
the public domain the material in this RSI Member Alert Advisory may be
reproduced and distributed, without permission in its entirety only,
provided the copyright is kept intact and due credit is given to RepSec,
Inc.
Subject to the timing of release restrictions above, this RSI Advisory
Alert 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.
---------------------------------------------------------------------------
RepSec, Inc. are trademarks of RepSec, Inc. All other trademarks are
property of their respective holders.
------------------------------
Date: Tue, 9 Jun 1998 00:21:34 -0400
From: "Joshua J. Drake"
Subject: more named software
This may or may not be a large problem depending on what you consider a breach
of security. The attached program allows someone to view your name server's
inverse query
support status and the version of named that you run from remote. As mentioned
in the "named warez" post, you can use dig to get the version information. IMHO
certain information should not be given out to anyone that asks for it. When a
system cracker scans your machine for faulty software, they will most likely
be looking for version numbers of the software you are running. Almost all
exploits are version dependent. For example, sendmail, httpd, named, and not to
mention some local exploits too.
So to sum it up, giving out version numbers and similar information aids a
cracker when attacking a system. This will by no means prevent someone from
"owning" you, but it may discourage inexperienced "script kiddies" from trying
some attacks.
Joshua James Drake
jdrake@pulsar.net
http://www.pulsar.net/~jdrake/
Attached file: binfo-udp.c
--- code begins here ---
/*
* This code was written by:
* Joshua James Drake (jdrake@pulsar.net)
*
* Published 6/9/98 @ 12:02 AM
*
* The following lines of code are, in a nutshell, written to pry
* some information from a nameserver. The information it gives
* you may or may not be useful. That is for you to decide.
*
* However, it will tell you if the server supports IQUERY and, if
* possible, what version of bind (by Paul Vixie) it is running.
*
*/
/* local type includes */
#include
#include
#include
#include
#include
#include
#include
#include
/* network type includes */
#include
#include
#include
#include
#include
#include
/* bulky shit for printing dnspkts need to link dnspkt.o from dnspkt.c too */
#ifdef DEBUG
#include "dnspkt.h"
#endif
/* prototypes */
int lookup_host(struct sockaddr_in *ra, char *hn, unsigned short rp);
void probe_bind(struct sockaddr_in ra);
int talk(int sd, char *pkt, int pktl, char opc);
int make_keypkt(char *pktbuf, char opc);
void print_ver(char *host, int vul, char *buf);
void handle_alarm(int signum);
/*
* here we simply check arguments, resolve the hostname given and
* if all is well, initialize the radom seed and probe away.
*/
void
main(argc, argv)
int argc;
char *argv[];
{
struct sockaddr_in ra;
if (argc != 2)
{
printf("usage: %s \n", argv[0]);
return;
}
if (!lookup_host(&ra, argv[1], NAMESERVER_PORT))
return;
srand(time(NULL));
probe_bind(ra);
}
/*
* resolve a hostname to a sockaddr_in struct.
* we first try treating it like an ip address in a.b.c.d notation
* then, if that fails, we try to resolve using DNS ways
* if all fails, we return 0. (failed)
* if we get the sockaddr_in struct all filled out, we return 1.
*/
int
lookup_host(ra, hn, rp)
struct sockaddr_in *ra;
char *hn;
unsigned short rp;
{
struct hostent *he;
ra->sin_family = AF_INET;
ra->sin_port = htons(rp);
if ((ra->sin_addr.s_addr = inet_addr(hn)) != -1)
return 1;
if ((he = gethostbyname(hn)) != (struct hostent *)NULL)
{
memcpy(&ra->sin_addr.s_addr, he->h_addr, 4);
return 1;
}
herror("Unable to resolve hostname");
return 0;
}
/*
* here we allocate some space for our packets and make sure it's
* "fullanull". then we attempt to allocate and setup our socket.
* if failure occurs, we shall report error and return.
* the we attempt to reverse our address in the sockaddr_in structure
* passed as the only argument into a dns name, if that fails, we go
* with the ascii ip address representation. then we attempt to
* communicate the remote server, if failure, we return. after we
* have successfully got our packets back, we close the socket and
* print out a summary of what we got.
*/
void
probe_bind(ra)
struct sockaddr_in ra;
{
int sd;
char iquery[512], vquery[512], rname[256];
struct hostent *he;
HEADER *dh = (HEADER *)iquery;
memset(vquery, 0, sizeof(vquery));
memset(iquery, 0, sizeof(iquery));
if (((sd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) ||
(connect(sd, (struct sockaddr *)&ra, sizeof(ra)) == -1))
{
perror("Unable to connect");
if (sd != -1)
close(sd);
return;
}
if ((he = gethostbyaddr((char *)&ra.sin_addr, sizeof(ra.sin_addr), AF_INET)) == (struct hostent *)NULL)
sprintf(rname, "%s", inet_ntoa(ra.sin_addr));
else
strncpy(rname, he->h_name, sizeof(rname));
if (!talk(sd, iquery, sizeof(iquery), IQUERY))
return;
if (!talk(sd, vquery, sizeof(vquery), QUERY))
return;
close(sd);
/* if dh->rcode == 0, then our iquery request was answered and the remote server
supports iquery */
print_ver(rname, dh->rcode == 0, vquery);
}
/*
* write our packet from pkt, wait for a response and put it in pkt.
* if the alarm goes off or the read fails, we print error
* and return 0. otherwise, our response packet is in pkt and we return 1.
*/
int
talk(sd, pkt, pktl, opc)
int sd, pktl;
char *pkt, opc;
{
int pktlen;
pktlen = make_keypkt(pkt, opc);
if (!write(sd, pkt, pktlen))
{
perror("write failed");
close(sd);
return 0;
}
#ifdef DEBUG
printf("write() success\n");
#endif
siginterrupt(SIGALRM, 1);
signal(SIGALRM, handle_alarm);
alarm(3);
pktlen = read(sd, pkt, pktl);
if (pktlen <= 0)
{
if (errno == EINTR)
errno = ETIMEDOUT;
perror("read failed");
close(sd);
return 0;
}
#ifdef DEBUG
printf("read success\n");
#endif
alarm(0);
return 1;
}
/*
* this forms a valid dns packet based on the op code given by opc.
* only two opcodes are supported because that's all we need to support.
* the packet ends up in pktbuf and the length of the packet is returned.
*/
int
make_keypkt(pktbuf, opc)
char *pktbuf;
char opc;
{
HEADER *dnsh;
char *ptr = pktbuf;
int pktlen = 0;
dnsh = (HEADER *) ptr;
/* fill out the parts of the DNS header that aren't 0 */
dnsh->id = htons(rand() % 65535);
dnsh->opcode = opc;
dnsh->rd = 1;
dnsh->ra = 1;
/* one answer for IQUERY, one question for QUERY */
if (opc == IQUERY)
dnsh->ancount = htons(1);
else if (opc == QUERY)
dnsh->qdcount = htons(1);
pktlen += sizeof(HEADER);
ptr += sizeof(HEADER);
/* we have to make a QUERY, fill out the question section */
if (opc == QUERY)
{
/* version.bind. == elite */
char qstr[] = "\007version\004bind\000";
int qlen = strlen(qstr) + 1;
memcpy(ptr, qstr, qlen);
ptr += qlen;
pktlen += qlen;
PUTSHORT(T_TXT, ptr);
PUTSHORT(C_CHAOS, ptr);
pktlen += sizeof(short) * 2;
}
/* add a resource record for the inverse query */
else if (opc == IQUERY)
{
unsigned long addr = inet_addr("1.2.3.4");
unsigned long ttl = 31337;
unsigned short addrlen = 4;
*(ptr++) = '\0';
pktlen++;
PUTSHORT(T_A, ptr);
PUTSHORT(C_IN, ptr);
PUTLONG(ttl, ptr);
PUTSHORT(addrlen, ptr);
PUTLONG(addr, ptr);
pktlen += (sizeof(short) * 3) + (sizeof(long) * 2);
}
/* if we're debugging, show what we just made */
#ifdef DEBUG
print_dnspkt(pktbuf, pktbuf + pktlen);
#endif
return pktlen;
}
/*
* This function takes a DNS packet in buf, and whether or not it reponds to IQUERY in vul.
* We cast the packet and extract the response as long as there is one.
* If there isn't one, then we assume that the remote server is an old version of bind.
* this is the end of the line.
*/
void
print_ver(host, vul, buf)
char *host, *buf;
int vul;
{
HEADER *dnsh = (HEADER *)buf;
char *ptr, *verstr;
int len;
if (dnsh->rcode != 0)
{
printf("%s's named that %s iquery does not respond to version.bind.\n", host, vul ? "supports" : "errors on");
return;
}
/* So we actually have a response. Lets skip the crap, starting with the header */
ptr = (buf + sizeof(HEADER));
/* then the question section domain name. */
while (*ptr != '\0')
ptr++;
/* then the trailing null and the type/class of the question */
ptr += 1 + (sizeof(short) * 2);
/* now we skip the answer section domain name. (should be the same as the question) */
while (*ptr != '\0')
ptr++;
/* don't forget the trailing null, type, class, and time to live. */
ptr += 1 + (sizeof(long) + (sizeof(short) * 2));
/* Here we are at the resource record data length, extract it */
GETSHORT(len, ptr);
/* avoid the need to decompress the string (treat it as one) */
ptr++;
/* allocate space for and copy the version response txt */
verstr = (char *)malloc(len);
memset(verstr, 0, len);
memcpy(verstr, ptr, len-1);
/* run through the vesion string and replace non-printable and non-whitespace characters
with a '.' */
for (ptr = verstr; ptr - verstr != len - 1; ptr++)
if (!isprint(*ptr) && !isspace(*ptr))
*ptr = '.';
/* print the version and iquery support status, woo hoo */
printf("%s's named that %s iquery is version: %s\n", host, vul ? "supports" : "errors on", verstr);
}
/*
* handle the alarm signal by resetting the alarm timer and
* the signal handler for SIGALRM. This stuff probably isn't needed,
* but I did it anyway. It's good for debugging, ran into some problems with
* alarm() not doing its job.
*/
void
handle_alarm(signum)
int signum;
{
alarm(0);
signal(SIGALRM, SIG_DFL);
#ifdef DEBUG
printf("recieved alarm\n");
#endif
}
--- code ends here ---
------------------------------
Date: Tue, 9 Jun 1998 16:46:09 -0700
From: Lloyd Vancil
Subject: Scanning Attacks from apple.com are spoofed addresses
In the last few days several people have complained that scanning
activity has been observed from various well known apple.com addresses.
Recently www.apple.com (17.254.0.91) was accused. In every case we have
determined that those attacks were not coming from the addresses
associated with the reports. In the case of www.apple.com, the 91
address is a virtual address that cannot be used in this way. If you
have evidence of such an attack's actual origination, or a method to
easily traces the actual origination point -I- would like to know of it.
Thank you
Lloyd Vancil
lev@ _/_/_/_/ _/_/_/_/ _/_/_/_/ _/ _/_/_/
searchmaster@ _/ _/ _/ _/ _/ _/ _/ _/
_/ _/ _/_/_/_/ _/_/_/_/ _/ _/_/_/ .com
_/_/_/_/ _/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/_/_/
------------------------------
Date: Tue, 9 Jun 1998 20:21:27 +0000
From: pmsac@TOXYN.ORG
Subject: Re: Correction on IBM "3com" 8237 (and others ?) "feature"
Sorry to bother you all again, this will be my last mail about the subject.
I managed to overcome the checksum problem and have written a dirty little
program that will, based on a chunk of the firmware, ask for a new login and
password and then show how that chunk must be rewritten (you still have to
do this by hand). The program source is available on demand. The login is
reduced to 9 characters instead of the usual 14, and some of the missing
bytes are used to make an checksum correct image.
Thanks go to Russell Coker (bofh@coker.com.au), who's mail made me go back
and see what gross mistakes I had made on previous attempts.
Have a nice day.
------------------------------
Date: Wed, 10 Jun 1998 09:17:54 -0700
From: Jared Proudfoot
Subject: AMD K6 Bug
Greetings,
I haven't seen much chatter about this, but if this as been addressed before
I apologise. Any thoughts?
http://www.tux.org/hypermail/linux-kernel/1998week23/0093.html
Regards,
Jared Proudfoot
----------------------------------------------------------------------
Jared Proudfoot jared_proudfoot@ismbc.com
Information Systems Management (B.C.) Corp. http://www.ismbc.com/
------------------------------
Date: Wed, 10 Jun 1998 11:55:55 -0500
From: Aleph One
Subject: Administrivia.
I am killing all ICKill and other trojan posts. There a literally hundreds
of such programs and I don't plan to discuss them all here. If you
download something as dubious as ICKill from IRC or some hacker website
and don't expect to be burned you deserve what you get. Also any new posts
on things such as IRC or ICQ spoofing, or browser denial of service
attacks will be looked down upon unless they contain real security
threats.
Finally, if you are going to report to the list that you are being under
attack by some new type of network attack at least try to obtain something
like a network trace.
Lets try to keep the noise level down.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
------------------------------
Date: Tue, 9 Jun 1998 17:17:56 -0400
From: Kimmie Dicaire
Subject: Full Armor
Version: Full Armor Network Configurator and Full Armor Zero Administration
Operating System: Win95/NT
This is an alert for Full Armor made by Micah Software and rated very high
in PC Week. While being a part of a team that was to install and
standardize all the desktops throughout a company this hack was
discovered. The software itself is a desktop protection software that has
many many more options than the regular poledit that comes with Win95,
although it does utilize and expand on the poledit program. The
problem/hack comes into play when you get the Full Armor warning that you
don't have rights (or any other Full Armor dialog box) if instead of just
clicking the ok button to remove the dialog box, instead you choose
+ + to get to the task manager you can end task on Full Armor
and remove all the protected areas, thus having full access to everything
on your destop/PC.
The has been tested on both 486 and Pentium machine's all running Win95
and the hack is reproduced everytime. There is no current work around for
this hack.
I have been in contact with the software developer's at Micah and they are
currently re-working the code that should have a fix for this by tomorrow
morning (6-9-10). If you are running Full Armor it is recommended that
you get this fix when it becomes available.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
K&R Information Technologies
http://asd.dyn.ml.org/ -- http://asd.dyn.ml.org/asdw
kdicaire@vic.com -- kdicaire@asd.dyn.ml.org -- paris@asd.dyn.ml.org
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------
Date: Wed, 10 Jun 1998 18:12:57 +0200
From: Michiel de Weerd
Subject: Sambar Server Beta BUG..
Sambar Server Beta's have a serious bug! it is possible to view the
victim's HDD.
This is how it's done:
Asume you find a computer running Sambar Server by searching the
Internet with these key-words: +sambar +server +v4.1
If you find a site like: http://www.site.net/
then do a test, run a little perl script...
http://www.site.net/cgi-bin/dumpenv.pl
Now you see the complete environment of the victims computer, including
his path. Now you can try to login as the administrator by adding this
to the url: /session/adminlogin?RCpage=/sysadmin/index.stm
so: http://www.site.net/session/adminlogin?RCpage=/sysadmin/index.stm
The default login is: admin and the default password is blank.
If the victim hasn't changed his settings, you now can control his
server.
Another feature is to view the victims HDD. If you were able to run the
perl script you should also be able (in most cases) to view directory's
from his path. Most people have c:/program files and c:/windows in the
path line, so what you can do is:
http://www.site.net/c:/program files/sambar41
FIX:
1) Upgrade to a non-beta version of Sambar Server.
2) Don't alow directory browsing if index.html or default.html isn't
found.
3) Change the admin username and password before someone else changes it
for you.
CC to Tod Sambar - http://www.sambar.com
------------------------------
Date: Wed, 10 Jun 1998 18:59:36 -0500
From: Aleph One
Subject: Sun Security Bulletin #00171
---------- Forwarded message ----------
Date: Wed, 10 Jun 1998 13:34:09 -0700
From: Sun Security Coordination Team
To: CWS@sunsc.Eng.Sun.COM
Subject: Sun Security Bulletin #00171
-----BEGIN PGP SIGNED MESSAGE-----
________________________________________________________________________________
Sun Microsystems, Inc. Security Bulletin
Bulletin Number: #00171
Date: June 10, 1998
Cross-Ref:
Title: ftpd
________________________________________________________________________________
The information contained in this Security Bulletin is provided "AS IS."
Sun makes no warranties of any kind whatsoever with respect to the information
contained in this Security Bulletin. ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY WARRANTY OF NON-INFRINGEMENT OR
IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, ARE
HEREBY DISCLAIMED AND EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW.
IN NO EVENT WILL SUN MICROSYSTEMS, INC. BE LIABLE FOR ANY LOST REVENUE,
PROFIT OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL
OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF ANY THEORY OF LIABILITY
ARISING OUT OF THE USE OF OR INABILITY TO USE THE INFORMATION CONTAINED IN
THIS SECURITY BULLETIN, EVEN IF SUN MICROSYSTEMS, INC. HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.
If any of the above provisions are held to be in violation of applicable law,
void, or unenforceable in any jurisdiction, then such provisions are waived
to the extent necessary for this disclaimer to be otherwise enforceable in
such jurisdiction.
________________________________________________________________________________
1. Bulletins Topics
Sun announces the release of patches for Solaris(tm) 2.6, 2.5.1, 2.5
and 2.3 (SunOS(tm) 5.6, 5.5.1, 5.5 and 5.3), which relate to a
vulnerability in ftpd.
Sun estimates that the release of patches for Solaris 2.4 (SunOS 5.4)
that relate to the same vulnerability will be available within 6 weeks
of the date of this bulletin.
Sun strongly recommends that you install the patches listed in section 4
immediately on systems running SunOS 5.6, 5.6_x86, 5.5.1, 5.5, and 5.3
which use in.ftpd.
2. Who is Affected
Vulnerable: SunOS 5.6, 5.6_x86, 5.5.1, 5.5.1_x86, 5.5, 5.5_x86,
5.4, 5.4_x86 and 5.3.
Not vulnerable: All other supported versions of SunOS.
3. Understanding the Vulnerability
The in.ftpd daemon is the Internet File Transfer Protocol (FTP) server
process. The server is invoked by the Internet daemon inetd each time
a connection to the FTP service is made. A vulnerability has been
discovered which could be exploited to launch an denial of service
attack against the ftp server.
4. List of Patches
The following patches are available in relation to the above problem.
SunOS Patch ID
_____ _________
SunOS 5.6 106301-01
SunOS 5.6_x86 106302-01
SunOS 5.5.1 103603-08
SunOS 5.5.1_x86 103604-08
SunOS 5.5 103577-08
SunOS 5.5_x86 103578-08
SunOS 5.4 101945-59 (to be released in 6 weeks)
SunOS 5.4_x86 101946-52 (to be released in 6 weeks)
SunOS 5.3 104938-02
_______________________________________________________________________________
APPENDICES
A. Patches listed in this bulletin are available to all Sun customers via
World Wide Web at:
B. Checksums for the patches listed in this bulletin are available via
World Wide Web at:
C. Sun security bulletins are available via World Wide Web at:
D. Sun Security Coordination Team's PGP key is available via World Wide Web
at:
E. To report or inquire about a security problem with Sun software, contact
one or more of the following:
- Your local Sun answer centers
- Your representative computer security response team, such as CERT
- Sun Security Coordination Team. Send email to:
security-alert@sun.com
F. To receive information or subscribe to our CWS (Customer Warning System)
mailing list, send email to:
security-alert@sun.com
with a subject line (not body) containing one of the following commands:
Command Information Returned/Action Taken
_______ _________________________________
help An explanation of how to get information
key Sun Security Coordination Team's PGP key
list A list of current security topics
query [topic] The email is treated as an inquiry and is forwarded to
the Security Coordination Team
report [topic] The email is treated as a security report and is
forwarded to the Security Coordination Team. Please
encrypt sensitive mail using Sun Security Coordination
Team's PGP key
send topic A short status summary or bulletin. For example, to
retrieve a Security Bulletin #00138, supply the
following in the subject line (not body):
send #138
subscribe Sender is added to our mailing list. To subscribe,
supply the following in the subject line (not body):
subscribe cws your-email-address
Note that your-email-address should be substituted
by your email address.
unsubscribe Sender is removed from the CWS mailing list.
________________________________________________________________________________
Copyright 1998 Sun Microsystems, Inc. All rights reserved. Sun,
Sun Microsystems, Solaris and SunOS are trademarks or registered trademarks
of Sun Microsystems, Inc. in the United States and other countries. This
Security Bulletin may be reproduced and distributed, provided that this
Security Bulletin is not modified in any way and is attributed to
Sun Microsystems, Inc. and provided that such reproduction and distribution
is performed for non-commercial purposes.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNX63gbdzzzOFBFjJAQETnAQAprMPrKXOYB6IhSWtkyCJWZ1rdKPEL9bd
brSobIVcVMsgRucCSjN/V8QQW8N0bZzsZkSPBrlH9WQWH+KSQPqUWap5OYoXYsqZ
jjmJdYXnVjzLUFA/FSwjsZo5mHpqGXJLQXUXbf18EqkNAG3RaLe1rjL7++F+Xiij
XHZTfqiqaYk=
=7Mv9
-----END PGP SIGNATURE-----
------------------------------
End of BUGTRAQ Digest - 8 Jun 1998 to 10 Jun 1998
*************************************************