-----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-----
