[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1149080254.34288889.1353412631370.JavaMail.root@redhat.com>
Date: Tue, 20 Nov 2012 06:57:11 -0500 (EST)
From: Jan Lieskovsky <jlieskov@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: Attila Bogar <attila.bogar@...guamatics.com>,
Raphael Geissert <geissert@...ian.org>,
oss-security@...ts.openwall.com
Subject: Re: CVE Request -- mcrypt: stack-based buffer
overflow by encryption / decryption of overly long file names
Hi Steve,
----- Original Message -----
> For my own clarification - where does this long file name come from? If
> it's only provided on the command line, then I don't see how this would be
> a vulnerability, since the person executing mcrypt would only be attacking
> themselves. (CVE-2012-4409 is still OK since one wouldn't expect code
> execution when decrypting the contents of a file.)
Was originally thinking of this being a security flaw more in the decryption scenario
(encryption one was noted only for completeness that it has the same issue) than
in the encryption one.
Previously considered scenario was remote user would trick the local one to
decrypt provided file (obviously the local user might not check if filename
isn't too long prior decryption). But after further review looks mcrypt doesn't
support asymmetric cryptography / keys (which I didn't know in the moment of requesting
a CVE id), only the symmetric one, which makes this scenario impossible / unlikely.
Considering the above, I think you are right and CVE-2012-4527 should be probably
rejected.
Right now I can't think of a case, how this could be possible to (mis)use for an
attack.
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
>
> Thanks,
> Steve
On Thu, 18 Oct 2012, Kurt Seifried wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/18/2012 07:50 AM, Jan Lieskovsky wrote:
>> Hello Kurt, Steve, vendors,
>>
>> Attila Bogar reported a stack-based buffer overflow
>> in the way MCrypt, a crypt() package and crypt(1) command
>> replacement, used to encrypt / decrypt files with overly
>> long names (longer than 128 bytes). A remote attacker
>> could provide a specially-crafted file that, when processed
>> by the mcrypt too, would lead to mcrypt executable crash [*].
>>
>> A different vulnerability than CVE-2012-4409:
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-4409
>>
>> Note: Using Red Hat bugzilla record for CVE-2012-4409 since
>> particular Mitre record is not described yet.
>>
>> References:
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=867790
>>
>> Patch proposed by Attila:
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=867790#c0
>>
>> Reproducer:
>> To reproduce let mcrypt encrypt / decrypt file with name
>> longer ~128 bytes.
>>
>> Could you allocate a CVE id for this?
>>
>> Thank you && Regards, Jan.
>> --
>> Jan iankko Lieskovsky / Red Hat Security Response Team
>>
>> [*] FORTIFY_SOURCE protection mechanism would mitigate this
>> deficiency to result into crash only. But on systems, without
>> FORTIFY_SOURCE protection being applied, the impact might be
>> higher.
>>
>> P.S.: I am not sure about relation of this issue to the issue
>> Raphael Geissert reported previously:
>> [4] http://www.openwall.com/lists/oss-security/2012/10/02/1
>>
>> so CC-in him too, he to clarify if [2] == [4], or if
>> they are yet different issues. Raphael, please clarify.
>> Thanks, Jan.
>>
>
> Please use CVE-2012-4527 for this issue.
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQgE3DAAoJEBYNRVNeJnmTP1UP/j6LR69c0tuOKaN/wWTtLu7J
> yfbsXmQLd7PfrqSl748bzLdGEVjvAZ/r2GvyPbNRv/Wl1zV6LGRkuOmuq7XRC5JB
> VGLsQlg6g8NZ7n1SGh+oDWSQ16CihzE25G0lf/qO4xCs6aKfcSfpYEM1rQANp9O4
> vZB7bWOZj1iBmUrrHsh/bnANAbaLdV/JN4747i0fMFB/aFhILvRFJk284FUFjQgY
> oE6Gqs5DIwFBZYyLYEj/2sqcvxw1vBMLE48QrIuVpJIColK7hU3fGIEBJRJUPVXn
> JkR3F0egpkkm7+p72OxayTt9YgY69GJCouY+xfY4Si5yZvwMaHvTy341TgT6H5F7
> 76SYtmoTGKWKa/L9TUAYQkxhzPkUP6syu3HyVvuPRdLEL7Bv3DX+LQAX5/a0QnwB
> B7SftW+yoH4/h/+wRCrza4cViuiF1pKjD+OVEXQUWH/Ih9OF0I9mZIbiequV4ZRB
> odHVOuyNwPdxYDtC63joBaPGO6ldL9t2HsJSbn5mmT27HIlrUiSkkxaRGfeYJaDE
> t2iUMiPqzP0VgmxwgrYgYdNgOrv+4T1p7QBWJ7w9Auy0fDMwyFo+ZxPo2xkfkoPh
> CcAev7nv5S53nUae/zfl15KLr/ta2j7pIaPgoHwZtlfaXy4u3Qsfoy1kKD6FGmEg
> 9RTi0YQOif4AYghYtb28
> =TH3z
> -----END PGP SIGNATURE-----
>
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.
