Back to list
eXtremail(ly easy) remote roots
Oct 15 2007 11:32AM
mu-b (mu-b digit-labs org)
-----BEGIN PGP SIGNED MESSAGE-----
The attached either exploit or demonstrate a rash of remotely
exploitable bugs in eXtremail <=2.1.1 which perhaps should be
renamed to the more apt name of eXtremely-rootable-mail...
of course, in the grand schema, these are more-or-less completely
*) extremail-v3.pl demonstrates two vulnerabilities, the first
a denial of service caused by an integer underflow into the
length argument of a call to memmove(). This is caused due to
the author replacing every occurrence of "%s" with "%%s" (before
logging the resulting string to a file, perhaps the author is
still somewhat paranoid after the re-occurrence of older format
string vulnerabilities :-)) whilst forgetting to take
into account that the string actually gets longer by a single-byte
after each replace!. The second bug is rather interesting and is
either a failure in GCC points-to analysis or a consequence of
the author neglecting the possibility that a temporary pointer
to a heap buffer may have changed after a call to realloc
(ifReservaMasMem) and refreshing the pointer to the heap
buffer given as argument (which may have been free()'d).
(I would tend to believe the later..)
This results in the overwriting of potentially free'd memory
with user-definable data (albeit very restricted).
*) extremail-v4.c - trivial remote stack-overflow in the admin
*) extremail-v5.c - remote heap overflow in CRAM-MD5 authentication.
*) extremail-v6.c - trivial remote stack-overflow in PLAIN
*) extremail-v7.c - THIS PAGE UNINTENTIONALLY LEFT BLANK
(I appear to have misplaced it, but given that eXtremail is
holier than the pope himself, I shouldn't think it would take
too long to fill.)
*) extremail-v8.pl demonstrates a remote heap overflow in the
recv()-loop whereby the author has mistakenly assumed that the
string length of all currently received data is at least equal to
the sum of all return values from each call to recv().
(trivial contradiction follows if we send() the first buffer
containing \x00). This causes an incorrect number of bytes to
be reallocated and a remote heap overflow in a call to memcpy().
(mu-b (at) digit-labs (dot) org [email concealed])
"Only a few people will follow the proof. Whoever does will
spend the rest of his life convincing people it is correct."
- Anonymous, "P ?= NP"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
[ reply ]
Copyright 2010, SecurityFocus