Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE Request -- mcrypt: stack-based buffer overflow by encryption / decryption of overly long file names
From: Jan Lieskovsky <jlieskov () redhat com>
Date: Tue, 20 Nov 2012 06:57:11 -0500 (EST)

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]