Evolution Camel NTLM SASL Processing Bug Lets Remote Users Obtain Potentially Sensitive Information
|
|
SecurityTracker Alert ID: 1021845 |
|
SecurityTracker URL: http://securitytracker.com/id/1021845
|
|
CVE Reference:
CVE-2009-0582
(Links to External Site)
|
Date: Mar 13 2009
|
Impact:
Disclosure of system information
|
Fix Available: Yes Vendor Confirmed: Yes
|
Version(s): 2.25.92 and prior versions
|
Description:
A vulnerability was reported in Evolution. A remote server can obtain potentially sensitive information from the target client.
A remote server can send specially crafted NTLM SASL authentication challenge packets (NTLM authentication type 2 packets) to cause the target client to return a portion of system memory.
The flaw resides in the ntlm_challenge() function in 'camel/camel-sasl-ntlm.c'.
|
Impact:
A remote user can obtain potentially sensitive information from system memory.
|
Solution:
The vendor has issued a source code fix.
The vendor's advisory is available at:
http://mail.gnome.org/archives/release-team/2009-March/msg00096.html
|
Vendor URL: projects.gnome.org/evolution/ (Links to External Site)
|
Cause:
Access control error
|
Underlying OS:
Linux (Any), UNIX (Any)
|
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Fri, 13 Mar 2009 08:05:57 -0500
Subject: http://mail.gnome.org/archives/release-team/2009-March/msg00096.html
|
This is for CVE-2009-0582. I'm hereby making it public.
Camel's NTLM SASL authentication mechanism does not properly validate
server's challenge packets (NTLM authentication type 2 packets, [1]).
In the ntlm_challenge() in camel/camel-sasl-ntlm.c, length of the domain
string that was copied from type 2 to type 3 packet (client's reply to
server's challenge) was not properly validated against the rest of the
data received from the server.
127 ntlm_set_string (ret, NTLM_RESPONSE_DOMAIN_OFFSET,
128 token->data + NTLM_CHALLENGE_DOMAIN_OFFSET,
129 atoi (token->data + NTLM_CHALLENGE_DOMAIN_LEN_OFFSET));
Server could specify larger length than the actual data sent in the
packet, causing the client to disclose portion of its memory, or crash.
Note: length value was not properly extracted from the packet too, as it
is not passed as string, rather as 16-bit LE value.
Red Hat security verified the patch for this and it was sent to other
vendors on March 4. I would like to get this committed before 2.26.0
releases.
[1] http://curl.haxx.se/rfc/ntlm.html#theType2Message
|
|
