Yet another sendmail exploit
Tony Fitzgerald
Overnight there was a posting in the "Best of Security" mailing list
detailing yet another sendmail exploit advertised to work for sendmail
versions 8.7 through 8.8.2. The script required some reworking to work
on Solaris, however, worked as advertised on Solaris 1 (SunOS 4.1.3_U1)
and appears to have come close to working on Solaris 2 (SunOS 5.5).
I don't care to distribute either the original or my modified version of
the script, however, there was a suggested patch for 8.8.2 which I will
append below.
My question deals with why the script did not work on Solaris 2. I note
that the script did succeed in creating a SUID, root owned version of
/bin/sh as /tmp/sh, however, running the script did not result in a root
shell, just a sub-shell of the current user. Is there some special code
in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
something else here?
=============== Suggested patch for sendmail ================
From best-of-secu...@suburbia.net Sat Nov 16 05:28:11 1996
Resent-Date: Sat, 16 Nov 1996 20:23:43 +1100
Old-X-Envelope-From: mba...@hemi.com Sat Nov 16 19:00:23 1996
Message-Id: <1996111607...@hemi.com>
To: security...@freebsd.org
Date: Sat, 16 Nov 1996 00:59:43 -0700 (MST)
Cc: best-of-...@suburbia.net
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Approved: pr...@suburbia.net
Resent-Message-ID: <"CRpMg2.0.7v2.TWOZo"@suburbia>
Resent-From: best-of-...@suburbia.net
X-Mailing-List: <best-of-...@suburbia.net> archive/latest/508
X-Loop: best-of-...@suburbia.net
Precedence: list
Resent-Sender: best-of-secu...@suburbia.net
Subject: BoS: Re: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).
Content-Length: 1073
X-Lines: 33
Status: RO
> # This is exploit for sendmail smtpd bug
> # (ver. 8.7-8.8.2 for FreeBSD, Linux and may be other platforms).
Being very early in the morning on a Friday night and not having
time yet to really look at the problem, below is my quick hack that
appears to solve the problem (note, this *is* a hack, but at least
it will deter naive users with the exploit script). The patch is
relative to 8.8.2.
Regards,
-Ade Barkah
ps. We don't use a smtpd link anyway.
-------------------------------------------------------------------
Inet: mba...@hemi.com - HEMISPHERE ONLINE - <http://www.hemi.com/>
-------------------------------------------------------------------
*** main.c.orig Sat Nov 16 00:51:39 1996
--- main.c Sat Nov 16 00:51:39 1996
***************
*** 496,503 ****
--- 496,505 ----
OpMode = MD_INITALIAS;
else if (strcmp(p, "mailq") == 0)
OpMode = MD_PRINT;
+ /*
else if (strcmp(p, "smtpd") == 0)
OpMode = MD_DAEMON;
+ */
else if (strcmp(p, "hoststat") == 0)
OpMode = MD_HOSTSTAT;
else if (strcmp(p, "purgestat") == 0)
===================================================================
--
O- J. Anthony Fitzgerald, j...@UNB.ca, http://www.unb.ca/web/CSD/staff/jaf/ -O
Helmut Springer
Tony Fitzgerald (j...@sarastro.sun.csd.unb.ca) wrote in comp.security.unix:
> versions 8.7 through 8.8.2. The script required some reworking to work
> on Solaris, however, worked as advertised on Solaris 1 (SunOS 4.1.3_U1)
> and appears to have come close to working on Solaris 2 (SunOS 5.5).
just a short note
delta
--
helmut 'delta' springer Unix/Net Consulting, InfoSystems, StudBox
de...@RUS.Uni-Stuttgart.DE Stuttgart University, FRG
http://home.pages.de/~delta/
phone : +49 711 685-2003 "Freedom's just another word for
FAX : +49 711 685-2043 nothing left to lose" Kris Kristofferson
Gary Mills
>My question deals with why the script did not work on Solaris 2. I note
>that the script did succeed in creating a SUID, root owned version of
>/bin/sh as /tmp/sh, however, running the script did not result in a root
>shell, just a sub-shell of the current user. Is there some special code
>in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
>something else here?
Hi Tony. Do you perhaps have /tmp mounted with the `nosuid' option?
That's a good defensive move. We do it for all user-writable filesystems.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Meelis Roos
> after adjusting the kill-line, it worked well under AIX 3.2.5...
and on Solaris 2.5. This bug seems not to be OS-specific.
--
Meelis Roos CS student at Tartu University, Estonia
e-mail: mr...@ut.ee
www: http://www.cs.ut.ee/~mroos
Simon Karpen
Sendmail exploits and such have been getting even more and more common lately.
It seems that sendmail really needs a complete rewrite. I've switched to
zmailer and highly recommend it to anybody. I haven't heard of any
holes in it. Has anybody heard of any known security holes with zmailer
2.99.41 (plus current patch)? It's on ftp.funet.fi in /pub/unix/mail/zmailer
configuration is very different from sendmail, but was easy enough.
I've also heard good things about qmail, but zmailer seemed to me
to be a more mature program.
--
Simon Karpen
kar...@rpi.edu, s...@acm.rpi.edu, s...@karpes.stu.rpi.edu
"I'm not paranoid, it's just that everybody's out to get me."
--Linus Torvalds
Evan Jeffrey
Tony Fitzgerald (j...@sarastro.sun.csd.unb.ca) wrote:
: My question deals with why the script did not work on Solaris 2. I note
: that the script did succeed in creating a SUID, root owned version of
: /bin/sh as /tmp/sh, however, running the script did not result in a root
: shell, just a sub-shell of the current user. Is there some special code
: in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
: something else here?
On my linux system, creating a suid root copy of "bash" doesn't get you root
access. It appears that it automatically sets all permissions to the reuid
when it starts, which at least is a nice trick, though hardly comprehensive
security, since a little wrapper with setruid(geteuid()); will "take care"
of it. At least people who break in and leave untested backdoors might be
disappointed.
Evan Jeffrey
erje...@artsci.wustl.edu
Tony Fitzgerald
In article <56kfqf$s...@sol.sun.csd.unb.ca>,
Tony Fitzgerald <j...@sarastro.sun.csd.unb.ca> wrote:
>My question deals with why the script did not work on Solaris 2.
It was pointed out to me in private correspondence that Solaris 2
requires the -p switch to /bin/sh in order to use the set UID setting.
Adding this flag to the exploit script made it work in Solaris 2.
Thanks Gary.
Kari E. Hurtta
In article <56kfqf$s...@sol.sun.csd.unb.ca>
j...@sarastro.sun.csd.unb.ca (Tony Fitzgerald) writes
in comp.security.unix:
> Overnight there was a posting in the "Best of Security" mailing list
> detailing yet another sendmail exploit advertised to work for sendmail
> versions 8.7 through 8.8.2. The script required some reworking to work
> on Solaris, however, worked as advertised on Solaris 1 (SunOS 4.1.3_U1)
> and appears to have come close to working on Solaris 2 (SunOS 5.5).
>
> I don't care to distribute either the original or my modified version of
> the script, however, there was a suggested patch for 8.8.2 which I will
> append below.
Following patch is from Eric Allman. I take freedom to redistribute it.
- K E H
Message-Id: <1996111702...@knecht.Sendmail.ORG>
From: Eric Allman <er...@sendmail.org>
X-URL: http://WWW.InReference.COM/~eric
cc: sendma...@sendmail.org
Subject: Re: Security problem in 8.7.x and 8.8.x
Date: Sat, 16 Nov 1996 18:00:33 -0800
[ Text deleted. - K E H ]
------- main.c -------
*** - Wed Dec 31 16:00:00 1969
--- main.c Sat Nov 16 07:07:17 1996
***************
*** 493,507 ****
{
case MD_DAEMON:
case MD_FGDAEMON:
! # ifdef DAEMON
! if (RealUid != 0)
! {
! usrerr("Permission denied");
! exit(EX_USAGE);
! }
! vendor_daemon_setup(CurEnv);
! /* fall through ... */
! # else
usrerr("Daemon mode not implemented");
ExitStat = EX_USAGE;
break;
--- 493,499 ----
{
case MD_DAEMON:
case MD_FGDAEMON:
! # ifndef DAEMON
usrerr("Daemon mode not implemented");
ExitStat = EX_USAGE;
break;
***************
*** 899,904 ****
--- 891,904 ----
/* fall through ... */
case MD_DAEMON:
+ /* check for permissions */
+ if (RealUid != 0)
+ {
+ usrerr("Permission denied");
+ exit(EX_USAGE);
+ }
+ vendor_daemon_setup(CurEnv);
+
/* remove things that don't make sense in daemon mode */
FullName = NULL;
GrabTo = FALSE;
***************
*** 1932,1937 ****
--- 1932,1946 ----
syslog(LOG_INFO, "restarting %s on signal", SaveArgv[0]);
#endif
releasesignal(SIGHUP);
+ if (setuid(RealUid) < 0 || setgid(RealGid) < 0)
+ {
+ #ifdef LOG
+ if (LogLevel > 0)
+ syslog(LOG_ALERT, "could not set[ug]id(%d, %d): %m",
+ RealUid, RealGid);
+ #endif
+ exit(EX_OSERR);
+ }
execv(SaveArgv[0], (ARGV_T) SaveArgv);
#ifdef LOG
if (LogLevel > 0)
[ Rest of mail deleted. - K E H ]
Michael Fuhr
Simon Karpen <s...@karpes.stu.rpi.edu> writes:
>Sendmail exploits and such have been getting even more and more common lately.
>It seems that sendmail really needs a complete rewrite.
But, but...
According to the _Sendmail Installation and Operation Guide_,
section 4.7.1, "Sendmail can safely be made setuid to root."
;-)
--
Michael Fuhr
http://www.dimensional.com/~mfuhr/
Nir Oren
Evan Jeffrey (ejef...@eliot82.wustl.edu) wrote:
: On my linux system, creating a suid root copy of "bash" doesn't get you root
: access. It appears that it automatically sets all permissions to the reuid
: when it starts, which at least is a nice trick, though hardly comprehensive
: security, since a little wrapper with setruid(geteuid()); will "take care"
: of it. At least people who break in and leave untested backdoors might be
: disappointed.
On solaris 2.4, running bash 1.14.2(1), running bash with the setuid bit set
seems to give root access...
Bye
Nir
Brian Mitchell
Tony Fitzgerald (j...@sarastro.sun.csd.unb.ca) wrote:
: Overnight there was a posting in the "Best of Security" mailing list
: detailing yet another sendmail exploit advertised to work for sendmail
: versions 8.7 through 8.8.2. The script required some reworking to work
: on Solaris, however, worked as advertised on Solaris 1 (SunOS 4.1.3_U1)
: and appears to have come close to working on Solaris 2 (SunOS 5.5).
: I don't care to distribute either the original or my modified version of
: the script, however, there was a suggested patch for 8.8.2 which I will
: append below.
: My question deals with why the script did not work on Solaris 2. I note
: that the script did succeed in creating a SUID, root owned version of
: /bin/sh as /tmp/sh, however, running the script did not result in a root
: shell, just a sub-shell of the current user. Is there some special code
: in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
: something else here?
Solaris2's /bin/sh resets the euid if euid != uid. It does this,
presumably, to combat the many popen()/system() type holes in the past
with suid/sgid binaries.
--
#######################################################################
Brian Mitchell br...@saturn.net
#######################################################################
Paul Civati
In article <m3bucxe...@karpes.stu.rpi.edu>,
Simon Karpen <s...@karpes.stu.rpi.edu> writes:
> Sendmail exploits and such have been getting even more and more common lately.
> It seems that sendmail really needs a complete rewrite. I've switched to
Well, a sendmail that ran under a different UID/GID and as only root when
it really needed to might be a help, IMO.
> I've also heard good things about qmail, but zmailer seemed to me
> to be a more mature program.
There are some good alternatives to sendmail appearing lately.
-Paul-
--
Paul Civati =O= Home: pa...@xciv.org =O= http://www.xciv.org/
London UK =O= Home: pa...@xciv.demon.co.uk =O= Slackware is.
h...@globecom.net
On 18 Nov 1996, Brian Mitchell wrote:
> : My question deals with why the script did not work on Solaris 2. I note
> : that the script did succeed in creating a SUID, root owned version of
> : /bin/sh as /tmp/sh, however, running the script did not result in a root
> : shell, just a sub-shell of the current user. Is there some special code
> : in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
> : something else here?
>
> Solaris2's /bin/sh resets the euid if euid != uid. It does this,
> presumably, to combat the many popen()/system() type holes in the past
> with suid/sgid binaries.
The reason the script doesn't work isn't the euid != uid, but the fact
that solaris doesn't support the overwrite of argv[0]. You can still
use the bug though, by changing it a little.
Henrik
-----=<->=-----=</>=-----=<->=-----=<|>=-----=<->=-----=<\>=-----=<->=-----
Henrik Johansson email: h...@globecom.net tel: +46 (0)31-775 00 90
Systems Manager mobile: +46 (0)706-25 15 45 fax: +46 (0)31-775 00 85
GlobeCom Network "When communicating is your need" http://globecom.net/
-----=<->=-----=<\>=-----=<->=-----=<|>=-----=<->=-----=</>=-----=<->=-----
Bo
ejef...@eliot82.wustl.edu (Evan Jeffrey) writes:
>On my linux system, creating a suid root copy of "bash" doesn't get you root
>access. It appears that it automatically sets all permissions to the reuid
>when it starts, which at least is a nice trick, though hardly comprehensive
>security, since a little wrapper with setruid(geteuid()); will "take care"
>of it. At least people who break in and leave untested backdoors might be
>disappointed.
I'm not sure what you mean by "a suid root copy doesn't you root
access". I'd say an effective uid of 0 is enough for "most purposes" :-)
Regards,
Bo
--
I'm receiving too much ad-spam lately. Normal e-mail to: b...@ebony.iaehv.nl
"Heisenberg may have been here".
Dave Sill
pa...@xciv.org (Paul Civati) writes:
> In article <m3bucxe...@karpes.stu.rpi.edu>, Simon Karpen <s...@karpes.stu.rpi.edu> writes:
>
> > Sendmail exploits and such have been getting even more and more
> > common lately. It seems that sendmail really needs a complete
> > rewrite. ...
>
> Well, a sendmail that ran under a different UID/GID and as only root when
> it really needed to might be a help, IMO.
qmail does exactly that. It consists of a handful of small daemons
that run under their own UID's and don't trust each other. Only the
part that handles local delivery runs as root, and only long enough to
switch to the user's UID.
> > I've also heard good things about qmail, but zmailer seemed to me
> > to be a more mature program.
Sendmail is mature, if maturity is what you want. :-) qmail is coming
up on its first anniversary.
--
Dave Sill (d...@ornl.gov) <URL:http://www.wp.com/72300/home.html>
Lockheed Martin Energy Systems Oak Ridge National Lab Workstation Support
Secure, reliable, efficient. Pick three. <URL:http://pobox.com/~djb/qmail.html>
Ofer Inbar
Simon Karpen <s...@karpes.stu.rpi.edu> writes:
>Sendmail exploits and such have been getting even more and more common lately.
>zmailer and highly recommend it to anybody. I haven't heard of any
>holes in it. Has anybody heard of any known security holes with zmailer
>2.99.41 (plus current patch)? It's on ftp.funet.fi in /pub/unix/mail/zmailer
>configuration is very different from sendmail, but was easy enough.
>
>to be a more mature program.
That's not a good basis for comparion. Sendmail is in use on the vast
majority of SMTP-reachable Internet mail servers, probably far
outnumbering the combined total of all the others. For example, in a
recent survey of 48419 hosts from the InterNIC zone files, Dan
Bernstein found that 31671 of them responded on the SMTP port, and
22545 of those were running some version of Sendmail (that's over 70%)
Sendmail's source is widely available, and many people focus on it
when searching for security holes. So it may be more "secure" because
more of its vulnerabilities have been found. Or it may be less
"secure" because it is more likely that its remaining vulnerabilities
will be found before holes in other SMTP software are.
I suspect qmail is probably more secure than most, but I don't know.
-- Cos (Ofer Inbar) -- c...@leftbank.com c...@cs.brandeis.edu
-- The Left Bank Operation -- l...@leftbank.com http://www.leftbank.com/
"We all misuse the net for personal gain, one way or another."
-- Larry Wall <lw...@netlabs.com>
Roger Books
Ofer Inbar (c...@zax.leftbank.com) wrote:
> Sendmail's source is widely available, and many people focus on it
> when searching for security holes. So it may be more "secure" because
> more of its vulnerabilities have been found. Or it may be less
> "secure" because it is more likely that its remaining vulnerabilities
> will be found before holes in other SMTP software are.
> I suspect qmail is probably more secure than most, but I don't know.
The big reason other mail programs claim better security is they supposedly
haven't tried to go for the monolithic approach that sendmail uses. I'm
really not sure that just because you break your functionallity into multiple
programs that you have actually increased security. The other thing I'm
seeing that some of the sendmail alternatives do to increase security is
remove functionallity. If you remove the flexability from sendmail you
greatly reduce the amount of code needed and therefore should have an
easier time ensuring security. I personally find the loss of flexability
unacceptable.
Anyone have any experience with sendmail wrappers? With this approach
you break out some of the initial security into an easy to verify small
front end and let sendmail worry about mail stuff and not worry about
security stuff. I'm just wondering how well this works in practice.
Roger
Nothing takes the taste out of peanut butter quite like unrequited
love.
-- Charlie Brown
Thomas H. Ptacek
22 Nov 1996 16:23:09 GMT bo...@rtssec1.dms.state.fl.us:
>haven't tried to go for the monolithic approach that sendmail uses. I'm
>really not sure that just because you break your functionallity into multiple
>programs that you have actually increased security. The other thing I'm
Think about it.
"Breaking functionality" into multiple programs doesn't increase security.
"Breaking functionality" from a monolithic SUID program into smaller
programs that operate with least privilege, thus ensuring that a minimum
amount of code executes with higher creds than it needs, certainly
increases security.
The signal handlers in qmail's SMTP daemon aren't going break root,
because none of the code in qmail's SMTP daemon runs as root. Likewise, a
buffer overflow in qmail's handling of the EXPN command (hypothetically)
isn't going to give an attacker remote root access, for the same reason.
On the other hand, the same problems WILL give an attacker instant root on
a sendmail installation. Even if qmail was afflicted by the same coding
problems that caused the past couple sendmail holes, the vulnerabilities
wouldn't have allowed root to be comprimised.
--
----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tq...@enteract.com]
----------------
exit(main(kfp->kargc, argv, environ));
Paul Civati
In article <574k1d$1...@server.cntfl.com>,
bo...@rtssec1.dms.state.fl.us (Roger Books) writes:
> Anyone have any experience with sendmail wrappers? With this approach
Well, all the CERT advisories concerning sendmail advise the use of
smrsh.
> you break out some of the initial security into an easy to verify small
> front end and let sendmail worry about mail stuff and not worry about
> security stuff. I'm just wondering how well this works in practice.
The TIS firewall toolkit includes smapd, which is a better wrapper around
sendmail, actually handling the SMTP connections in a chrooted environment.
A secondary program then takes the delivered mail and feeds it to sendmail.
(I've not used either of these myself mind you, found a nicer MTA now :).
D. J. Bernstein
Soren Dayton claimed three months ago that ``it is reasonable to say
that it is possible that sendmail can be as secure as qmail.''
I downloaded the sendmail source, stared at it for a few minutes, and
reported a serious security problem to CERT.
They announced that hole two months ago. I downloaded the new sendmail
source, stared at it for a few more minutes, and reported another
serious security problem.
Now that they've announced that one, shall I do it again? Or has my
point been proven?
> 22545 of those were running some version of Sendmail (that's over 70%)
Yup. Almost all of them have well-known remotely exploitable root holes.
Frightening, isn't it?
---Dan
Sick of sendmail? Don't get mad; get qmail. http://pobox.com/~djb/qmail.html
D. J. Bernstein
Roger Books <bo...@rtssec1.dms.state.fl.us> wrote:
> The big reason other mail programs claim better security is they supposedly
Actually, there are seven big reasons that qmail offers better security.
``Do as little as possible in setuid programs'' is #2. Can't do that
with a monolith.
``Do as little as possible as root'' is #3. Can't do that with a
monolith.
``Move separate functions into mutually untrusting programs'' is #4.
Can't do that with a monolith.
> I'm
> really not sure that just because you break your functionallity into multiple
> programs that you have actually increased security.
Running unnecessary code setuid root certainly hurts security.
The hole fixed in 8.8.3 (run sendmail, set argv[0], kill -HUP: root)
happened because users can control the queue manager's process state.
The hole fixed in 8.8.1 (run sendmail -q, set LOCALDOMAIN: steal mail)
happened because users can control the SMTP client's process state.
One of the holes fixed in 8.7.6 (run sendmail, set resource limits:
daemon) was very easy to exploit because users can control the router's
process state.
The hole fixed in 8.7 (run sendmail -bi, set resource limits: possibly
daemon) was very easy to exploit because users can control the alias
writer's process state.
The hole fixed in 8.6.8 (run sendmail -oE: read any file) happened
because users can control the queue manager's process state.
The hole fixed in 8.6.7 (run sendmail -d: root) happened because users
can control a root program's process state.
> The other thing I'm
> seeing that some of the sendmail alternatives do to increase security is
> remove functionallity.
Funny. Seems to me that sendmail has been frantically trying to catch up
to qmail in functionality. Yes, the Tower of Hanoi program is cute, but
it doesn't compete with user-controlled virtual domains or automatic
cross-host mailing list loop prevention.
Chris Evans
On 24 Nov 1996, D. J. Bernstein wrote:
> They announced that hole two months ago. I downloaded the new sendmail
> source, stared at it for a few more minutes, and reported another
> serious security problem.
>
> Now that they've announced that one, shall I do it again? Or has my
> point been proven?
Go on then, post serious hole in sendmail 8.8.3 within 1 week from now,
and I'll be a qmail convert :-)
Chris.
ncE7bybm51AlajuSXwM3T39K1twK/Mf/xqpGuEQu/osMwxSH1R2IHr38r38tcC00otdYuCaQu/osG5FuSwLJbxZMMJwxZMMJM3
h...@globecom.net and friends:) wrote:
: > Solaris2's /bin/sh resets the euid if euid != uid. It does this,
: > with suid/sgid binaries.
: The reason the script doesn't work isn't the euid != uid, but the fact
: that solaris doesn't support the overwrite of argv[0]. You can still
: use the bug though, by changing it a little.
: Henrik
This doesn't mean we can't compile a seperate program in C or
the source code for /bin/sh, previously credited:). Logically this mod in
/bin/sh DOES NOTHING to combat popen()/system() holes. Its amazing how
some operatings systems take the best parts out of unix and just turn it
into plastic buffed up ice cream.
Am I right? ... _Really_ how would a program, that would basicly
be a modified /bin/sh, behave? Or is this not anything special at all--
... an old version of /bin/sh?
Hackers are geniouses, and machines are just ones and 0's.[A
figure in speech]. This is real security.
: -----=<->=-----=</>=-----=<->=-----=<|>=-----=<->=-----=<\>=-----=<->=-----
: Henrik Johansson email: h...@globecom.net tel: +46 (0)31-775 00 90
--
-Opus
The Micro$oft Corp. and its LEGAL software users software,
hardware, and network devices, are _PROHIBITED_ from processing
SUCH AS distributing, redistributing, computing, and VIEWING this work in
any form such as in whole, part, force, or encrypted. A onetime-user license
is is available to Micro$oft Corp. and its LEGAL software users for a fee
of $50. Please contact Copyright Clearing House to make payment.
PROCESSING WITHOUT PERMISSION CONSTITUTES AN AGREEMENT TO THESE TERMS.
Feel free to redistribute this disclaimer such as in your own signature.
th...@europa.com.
D. J. Bernstein
Chris Evans <ch...@ferret.lmh.ox.ac.uk> wrote:
> Go on then, post serious hole in sendmail 8.8.3 within 1 week from now,
Oh, c'mon. Do you realize how many frightened sysadmins are frantically
downloading the 8.8.3 source right now? I'll be amazed if I can even
connect to Berkeley. And staring at Eric Allman's code makes me want to
throw up; you're asking me to do it _again_?
Well, okay, if you insist. I just sent another one off to CERT. (Quick
workaround: restrictqrun.)
Trever Miller
: recent survey of 48419 hosts from the InterNIC zone files, Dan
: Bernstein found that 31671 of them responded on the SMTP port, and
You mean 50%, right?
--
b...@cyberdex.cuug.ab.ca Keeper of the Alberta B5 Mailing List
System Mangler babylon5...@cyberdex.cuug.ab.ca
"The stupider it looks, the more important it probably is." -- J.R. 'Bob' Dobbs
TWYG
Chris Evans <ch...@ferret.lmh.ox.ac.uk> writes:
>On 24 Nov 1996, D. J. Bernstein wrote:
>
>> They announced that hole two months ago. I downloaded the new sendmail
>> source, stared at it for a few more minutes, and reported another
>> serious security problem.
>>
>> Now that they've announced that one, shall I do it again? Or has my
>> point been proven?
>
>Go on then, post serious hole in sendmail 8.8.3 within 1 week from now,
>and I'll be a qmail convert :-)
several people have reported that 8.8.3 has in fact
been vulnerable (and has been successfully exploited)
using essentially the same technique used in the last
(released) sendmail exploit (8.7.6 to 8.8.2). others
say it hasn't worked, but some insist it has. anyone?
twyg.
D. J. Bernstein
Trever Miller <b...@cyberdex.cuug.ab.ca> wrote:
> You mean 50%, right?
That's a matter of interpretation. It's not unreasonable to exclude
connection failures from the tally; this weights servers by (late night)
reachability.
Anyway, I've done a second survey. Here are the results.
The InterNIC zone files contain 842937 different domains, counting both
the 2LDs and the glue, as of mid-November 1996.
I did an MX (falling back to A) lookup for each domain, obtaining 134601
different IP addresses. I excluded 0.*, 10.*, and 127.*. I did not retry
apparent soft failures. Note that these 134601 addresses do not entirely
include the 48419 IP addresses listed in the InterNIC zone files.
I tried connecting to port 25 at each address.
28043 connection attempts did not produce a greeting message:
10158 timed out
9044 connection refused
4930 host unreachable
3500 network unreachable
404 immediate disconnect
4 operation not supported
1 connection reset
1 protocol not available
1 machine not on network
106558 produced a greeting message. Most hosts responded to HELP. I have
a script to guess what server is running; here are the results:
69146 Sendmail
5366 not sure
5075 Post.Office
4575 NT Mail
2982 MS Exchange
2457 Netscape Mail Server
2188 AIMS
1912 smap
1361 SLmail
1323 Smail 3.1
1230 IMS SMTP Receiver
1220 IMail
720 MMDF
665 Zmailer
650 EMWAC SMTP Receiver
638 ``The normal sequence of events in sending a message'' (?)
615 GroupWise
516 PMDF
503 MetaInfo Sendmail
404 Lotus SMTP MTA
366 Connect2-SMTP
357 Worldgroup SMTP server
315 Generic SMTP Handler (Raptor firewall)
294 TGV/MultiNet
225 qmail
218 ``Simple Mail Transfer Service Ready'' (?)
180 VMS MX
173 AltaVista Mail
118 PP
112 MailSite SMTP Receiver
105 IBM VM SMTP
96 UCX
91 ``Help ... Not recognized'' (?)
82 SMTPXD
71 MailShare
67 SMTP-OpenVMS
44 NASTA Gate
41 Exim
24 CommuniGate SMTPGate
21 ListSTAR
12 Pony Express
Here's how the guesses work:
/Microsoft Exchange Internet Mail Connector/ { ++exchange; next }
/NT Server running Internet Shopper/ { ++ntmail; next }
/Simple Mail Transfer Service Ready/ { ++smtsrfoo; next }
/send comments to qm...@pobox.com/ { ++qmail; next }
/CommuniGate SMTPGate is ready/ { ++communigate; next }
/Apple Internet Mail Server/ { ++aims; next }
/post.office E-mail system/ { ++postoffice; next }
/TGV.MultiNet SMTP server/ { ++tgv; next }
/MailSite SMTP Receiver/ { ++mailsite; next }
/Worldgroup SMTP server/ { ++worldgroup; next }
/Generic SMTP handler/ { ++raptor; next }
/Netscape Mail Server/ { ++netscape; next }
/EMWAC SMTP Receiver/ { ++emwac; next }
/GroupWise SMTP.MIME/ { ++groupwise; next }
/MetaInfo Sendmail/ { ++metainfo; next }
/IMS SMTP Receiver/ { ++ims; next }
/running MailShare/ { ++mailshare; next }
/ListSTAR Package/ { ++liststar; next }
/TGV MultiNet V/ { ++tgv; next }
/AltaVista Mail/ { ++avmail; next }
/Lotus SMTP MTA/ { ++lotus; next }
/MX V.\..-. VAX/ { ++vmsmx; next }
/post.office v/ { ++postoffice; next }
/Connect2-SMTP/ { ++connect2; next }
/MX V.\.. VAX/ { ++vmsmx; next }
/MX V.\.. AXP/ { ++vmsmx; next }
/Zachariassen/ { ++zmailer; next }
/Pony Express/ { ++pony; next}
/SMTP.OpenVMS/ { ++openvms; next }
/IBM VM SMTP/ { ++ibmvm; next }
/NASTA Gate/ { ++nasta; next }
/SMTP.smap/ { ++smap; next }
/Smail3.1/ { ++smail31; next }
/SLmail95/ { ++slmail; next }
/SLmailNT/ { ++slmail; next }
/SLMAILNT/ { ++slmail; next }
/Sendmail/ { ++sendmail; next }
/PMDF V/ { ++pmdf; next }
/SMTPXD/ { ++smtpxd; next }
/IMail/ { ++imail; next }
/Exim/ { ++exim; next }
/UCX / { ++ucx; next }
/The normal sequence of events in sending a message/ { ++normalfoo; next }
/[pP][pP].*Pleased to meet you/ { ++pp; next }
/Help \.\.\. Not recognized/ { ++helpfoo; next }
/For more info use .HELP/ { ++sendmail; next }
/unimplemented..#5.5.1/ { ++qmail; next }
/Complaints.bugs to/ { ++mmdf; next }
The average time to handle one address was under 8 seconds; not counting
initial connection timeouts, 3.78 seconds. I used a concurrency of 250.
I expect my next survey, using the NW list of 13 million hosts, to run a
bit more slowly.
Dean Carpenter
Brian Mitchell wrote:
>
> Tony Fitzgerald (j...@sarastro.sun.csd.unb.ca) wrote:
<snip>
> : My question deals with why the script did not work on Solaris 2. I note
> : that the script did succeed in creating a SUID, root owned version of
> : /bin/sh as /tmp/sh, however, running the script did not result in a root
> : shell, just a sub-shell of the current user. Is there some special code
> : in the Solaris 2 /bin/sh to ignore SUID bits? Am I over looking
> : something else here?
>
> Solaris2's /bin/sh resets the euid if euid != uid. It does this,
> presumably, to combat the many popen()/system() type holes in the past
> with suid/sgid binaries.
The problem isn't with the actions of the shell, but rather with what the psuedo-sendmail
program can do, which is anything since it runs as root. Instead of just copying /bin/sh
to /tmp and setting it suid root, it could add an entry to /etc/passwd with root access,
or copy/ftp files anywhere, or anything.
My ISP thought they were OK after I warned them until I sent them the root mail file
from /var/mail ...
--
Dean Carpenter dcarp...@kraft.com
de...@areyes.com
Jonathan I. Kamens
In article <E1EvM...@cyberdex.cuug.ab.ca>, b...@cyberdex.cuug.ab.ca (Trever Miller) writes:
|> : recent survey of 48419 hosts from the InterNIC zone files, Dan
|> : Bernstein found that 31671 of them responded on the SMTP port, and
|> : 22545 of those were running some version of Sendmail (that's over 70%)
|>
|> You mean 50%, right?
How do you figure? 22545 / 31671 is 71.1%.
Perhaps you are implying that the denominator should be 48419 rather
than 31671, but that doesn't make sense because (a) hosts that do not
respond on the SMTP port are not relevant to this statistic, and (b)
besides, 22545 / 48419 is 46.5%, not more than 50%.
So what is your point, exactly?
--
Jonathan Kamens | OpenVision Technologies, Inc. | j...@cam.ov.com
Corey
D. J. Bernstein wrote:
[...]
>
> The InterNIC zone files contain 842937 different domains, counting both
> the 2LDs and the glue, as of mid-November 1996.
>
> I did an MX (falling back to A) lookup for each domain, obtaining 134601
> different IP addresses. I excluded 0.*, 10.*, and 127.*. I did not retry
> apparent soft failures. Note that these 134601 addresses do not entirely
> include the 48419 IP addresses listed in the InterNIC zone files.
>
> I tried connecting to port 25 at each address.
>
christ. another reason that bandwidth is so fucking bad on
the Internet. don't you have anything better to do?
---corey
Chris Walsh
In article <329F7C1B...@phix.net>, Corey <co...@phix.net> wrote:
>
>christ. another reason that bandwidth is so fucking bad on
>the Internet. don't you have anything better to do?
Pot. Kettle. Black.
--
Chris Walsh finger mac...@ece.nwu.edu
ECE Dept., Northwestern Univ. for PGP 2.6.2 public key
Evanston, IL 1-847-491-8141
*** Wanted: One garage space for motorcycle, please call or email ***
D. J. Bernstein
In article <329F7C1B...@phix.net>, Corey <co...@phix.net> wrote:
> christ. another reason that bandwidth is so fucking bad on
> the Internet.
No. Bandwidth is bad for the same reason that most programs are so slow:
programmers _guess_ where the bottlenecks are rather than _profiling_.
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
Dom De Vitto
On 30 Nov 1996 04:43:41 GMT, D. J. Bernstein (d...@koobera.math.uic.edu) wrote:
: In article <329F7C1B...@phix.net>, Corey <co...@phix.net> wrote:
: > christ. another reason that bandwidth is so fucking bad on
: > the Internet.
: No. Bandwidth is bad for the same reason that most programs are so slow:
: programmers _guess_ where the bottlenecks are rather than _profiling_.
No, they'd just rather go home and get a beer, 'cause the boss won't know
either way...
: ---Dan
: Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I'll go with that.
Dom
--
__________________________________________________________________________
Dom De Vitto dev...@ferndown.ate.slb.com
Schlumberger Automatic Test Equipment f...@bcs.org.uk
Board Systems Desk/voicemail: +44(0) 1202 850951
Wimborne, Dorset, Site reception: +44(0) 1202 850850
England, BH21 7PP Fax: +44(0) 1202 850988
__________________________________________________________________________
lar...@aol.com
>Anyway, I've done a second survey. Here are the results.
So it was you!!!
Damn, I wondered who the hell was screwing around on the smtp ports from
uic.edu.
Mike Bell
I need the latest smail remote exploit.. If someone could point me to the
right direction, Or send me it, it would be greatly apreciated.