From owner-freebsd-security Tue May 30 0:52:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by hub.freebsd.org (Postfix) with SMTP id 68C4F37B98A for ; Tue, 30 May 2000 00:52:38 -0700 (PDT) (envelope-from sen_ml@eccosys.com) Received: (qmail 24678 invoked from network); 30 May 2000 07:48:21 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 30 May 2000 07:48:21 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: QPOPPER: Remote gid mail exploit From: sen_ml@eccosys.com In-Reply-To: References: <20000530113403A.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000530165232H.1001@eccosys.com> Date: Tue, 30 May 2000 16:52:32 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: Kris Kennaway Subject: Re: QPOPPER: Remote gid mail exploit Date: Tue, 30 May 2000 00:31:53 -0700 (PDT) Message-ID: > On Tue, 30 May 2000 sen_ml@eccosys.com wrote: > > > > As with the IMAP exploit, this will give people a shell, which they usually > > > didn't have beforehand, when they are just popusers. > > > > since the problem has to w/ a pop command that's issued after > > successful authentication, if the user already has shell access, then > > there isn't anything to worry about, is there? or is the shell > > running as some other user? > > I don't believe this (the text you replied to above) is true. As I > understand it the vulnerability is that an attacker can send a email with > a certain header which will be parsed by the pop server when a client > downloads the email using the EUIDL command, at which point the buffer > overflows and can execute arbitrary code as gid mail (or whatever the pop > server runs as). So it's much worse than the imap hole. thanks a lot for the explanation. > As a consolation, it's harder to exploit on FreeBSD because of a fix > we made in the port, but it's still reportedly exploitable. i'm a bit confused here -- does this mean the current port is still vulnerable or that the port available at the time of the exploit announcement happened to be hard to exploit? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message