Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Sep 2012 14:44:54 -0600
From: Vincent Danen <>
Subject: Re: CVE request - mcrypt buffer overflow flaw

* [2012-09-06 15:11:27 -0500] Raphael Geissert wrote:

>On Thursday 06 September 2012 09:37:14 Vincent Danen wrote:
>> A buffer overflow was reported [1],[2] in mcrypt version 2.6.8 and
>> earlier due to a boundary error in the processing of an encrypted file
>> (via the check_file_head() function in src/extra.c).  If a user were
>> tricked into attempting to decrypt a specially-crafted .nc encrypted
>> flie, this flaw would cause a stack-based buffer overflow that could
>> potentially lead to arbitrary code execution.
>I'm attaching a patch that makes mcrypt abort when the salt is longer than
>the temp buffer it uses.
>While working on it, I noticed the err_ functions do not have a constant
>printf format, yet there are calls such as:
>      sprintf(tmperr, _("Input File: %s\n"), infile);
>      err_info(tmperr);
>[print_enc_info in src/extra.c]
>And a few others in src/mcrypt.c; for instance:
>$ mcrypt --no-openpgp ""
>mcrypt: h?????????Fn???`.nc is not a regular file. Skipping...
>I'm attaching another patch that prevents the format string attacks.

Fantastic, thanks for this.  I suppose the format string issues may
require another CVE name?  I'm not sure if they're exploitable or not
(no chance right now to look at it further).

Vincent Danen / Red Hat Security Response Team 

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.