[14355] in bugtraq
Re: a few bugs ...
daemon@ATHENA.MIT.EDU (Michal Zalewski)
Mon Mar 20 07:45:08 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.21.0003170951050.15849-100000@dione.ids.pl>
Date: Fri, 17 Mar 2000 10:07:45 +0100
Reply-To: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
X-To: Maurycy Prodeus <z33d@TENET.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000313143123.9899.qmail@tenet.pl>
On Mon, 13 Mar 2000, Maurycy Prodeus wrote:
> 1. In "Lotus Notes POP 1.0X" on NT platform. I'm not really sure ...
> if you send a very long username ( about 2kb ) it disconnects without
> any message. So it looks like classic buffer overflow :) I don't have
> enough time to check it ( to download this packet :) )
Have you noticed GPF popup or BSOD on this Windows box? Anyone may confirm
this?
> 2. Mail agent programs like: standard ;P 'mail' from Berkeley
> Distribution or mutt, elm perhaps other :), use sendmail arguments to
> put email adress where luser wants to send mail. It's similar problem
> to crontab's or lpd's bugs. Example: if you put line with Reply-To: -X
> /dev/hda1 ;P or something like that :> to mail message and luser ( in
> this case root ) stupid pushes OK,OK,OK :) ( ofz he'd want to reply )
> it may write/destroy file ( /dev/hda1 :] ). I know it isn't good
> example but I only wanted to show idea...
AFAIK most of mailers calls Sendmail with -bs (start in SMTP emulation
mode) or -t (scan headers for recipients) parameter. This is true eg. for
pine, mutt seems to be not vulnerable as well. Linux /bin/mail seems to
behave correctly, as well.
> 3. ntalkd from redhat distri or debian... in old version ( <=5.2rh and
> <=2.0db) (I don't want to be wrong so I will not write it's version -
> aleph bounced;P sic! ) it's known and patched but there wasn't
> official post and it may be dangerous. There is fprintf() without
> format. Another hard to exploit bug :)
Aham. According to ChangeLog:
26-Nov-1998:
Fixed bug: the talkd announce message is passed as the format
string to fprintf, so if it has %'s in it, we probably crash.
Announce message (assembled in ntalkd/announce.c) contains remote username
and remote hostname information, as well as some hardcoded texts like
"Talk request from...". Take a note - we're talking about fprintf, so,
assuming there's no interesting data in daemon address space (I don't
think so - it is not performing any authorization, etc, only reads utmp
entries), I don't think it might lead to anything except crash. And, as
it's started from inetd, I don't think it might have any security
implications ;)
Btw. Aleph, some time ago I described proftpd crash problem with LIST
parameter. Instead of playing with FUD, I've done some debugging and
realized it won't be _probably_ exploitable. As the result, you bounced
this post, but approved this one - for sure overFUDed ;>
_______________________________________________________
Michal Zalewski * [lcamtuf@ags.pl] <=> [AGS WAN SYSADM]
[dione.ids.pl SYSADM] <-> [http://lcamtuf.na.export.pl]
[+48 22 551 45 93] [+48 603 110 160] bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
