Red Hat Bugzilla – Full Text Bug Listing
|Summary:||CVE-2009-0582 evolution-data-server: insufficient checking of NTLM authentication challenge packets|
|Product:||[Other] Security Response||Reporter:||Tomas Hoger <thoger>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||bressers, dhensley, kreilly, mbarnes, mcrha, mjc, security-response-team, sipan, tyan|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-03-20 03:50:54 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||488280, 488281, 488293, 488439, 488440, 488441, 488442|
Description Tomas Hoger 2009-02-27 08:59:18 EST
It was discovered that camel's NTLM SASL authentication mechanism did not properly validate server's challenge packets (NTLM authentication type 2 packets, ). 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.  http://curl.haxx.se/rfc/ntlm.html#theType2Message
Comment 1 Tomas Hoger 2009-02-27 09:00:18 EST
Created attachment 333473 [details] Proposed patch from Matthew Barnes
Comment 21 Tomas Hoger 2009-03-12 10:56:46 EDT
Comment 22 errata-xmlrpc 2009-03-16 10:37:03 EDT
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2009:0354 https://rhn.redhat.com/errata/RHSA-2009-0354.html
Comment 23 errata-xmlrpc 2009-03-16 10:47:39 EDT
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009-0355 https://rhn.redhat.com/errata/RHSA-2009-0355.html
Comment 24 errata-xmlrpc 2009-03-16 10:54:08 EDT
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Via RHSA-2009:0358 https://rhn.redhat.com/errata/RHSA-2009-0358.html
Comment 25 Fedora Update System 2009-03-18 14:58:19 EDT
evolution-data-server-2.24.5-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Comment 26 Fedora Update System 2009-03-18 14:59:57 EDT
evolution-data-server-2.22.3-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
Comment 27 Red Hat Product Security 2009-03-20 03:50:54 EDT
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2009-0354.html http://rhn.redhat.com/errata/RHSA-2009-0355.html http://rhn.redhat.com/errata/RHSA-2009-0358.html Fedora: https://admin.fedoraproject.org/updates/F10/FEDORA-2009-2784 https://admin.fedoraproject.org/updates/F9/FEDORA-2009-2792
Comment 28 Milan Crha 2009-05-19 07:22:18 EDT
See bug #501222, the NTLM authentication in IMAP seems to be broken. I'm checking with a reporter there, but want to let you know soon enough.
Comment 29 Sergey Panov 2009-06-13 02:02:02 EDT
I am using 4 different Fedora 10 machines. When this bug fix was pushed through Fedora 10 update (evolution-data-server-2.24.5-4.fc10) it killed (one-by-one) password authentication with the SMTP server. The SMTP server is a Windows 2003 server running Exchange. Password type is set to NTLM/SPA . All machines are have evolution-data-server-2.24.5-5.fc10 installed. SMTP problem is still there. At least one of the systems developed problem similar to one described in Comment #29 -- it fails to authenticate with the real(evolution exchange module) exchange server.