eXtremail(ly easy) remote roots
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
useless!..
*) 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).
PoC: http://www.digit-labs.org/files/exploits/extremail-v3.pl
*) extremail-v4.c - trivial remote stack-overflow in the admin
interface.
PoC: http://www.digit-labs.org/files/exploits/extremail-v4.c
*) extremail-v5.c - remote heap overflow in CRAM-MD5 authentication.
PoC: http://www.digit-labs.org/files/exploits/extremail-v5.c
*) extremail-v6.c - trivial remote stack-overflow in PLAIN
authentication.
PoC: http://www.digit-labs.org/files/exploits/extremail-v6.c
*) 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().
PoC: http://www.digit-labs.org/files/exploits/extremail-v8.pl
- --
mu-b
(mu-b@xxxxxxxxxxxxxx)
"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
iD8DBQFHE0/EY0H9BP42EjwRCOMpAKDMa0qnZ3ZzDntbmwo505GjLUzcSACeIG00
3lsWit0K9ZIApcLXUg+CrgM=
=LkOe
-----END PGP SIGNATURE-----