[14367] in bugtraq
Re: a few bugs ...
daemon@ATHENA.MIT.EDU (Daniel Jacobowitz)
Tue Mar 21 02:00:35 2000
Mail-Followup-To: Daniel Jacobowitz <drow@false.org>,
Michal Zalewski <lcamtuf@DIONE.IDS.PL>,
BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-Id: <20000320210007.A5220@drow.res.cmu.edu>
Date: Mon, 20 Mar 2000 21:00:08 -0500
Reply-To: Daniel Jacobowitz <drow@FALSE.ORG>
From: Daniel Jacobowitz <drow@FALSE.ORG>
X-To: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.21.0003170951050.15849-100000@dione.ids.pl>; from
lcamtuf@DIONE.IDS.PL on Fri, Mar 17, 2000 at 10:07:45AM +0100
On Fri, Mar 17, 2000 at 10:07:45AM +0100, Michal Zalewski wrote:
> > 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 ;>
Actually, it was exploitable, if you are referring to the
username-passed-in-format-string bit. In my efforts for
crack.linuxppc.org (which I have not gotten around to writing up yet,
but will - there were a few interesting tidbits), I used that for two
tricks: to gain root access within the chroot and to disable dropping
of capabilities.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
