Zarafa Unauthenticated remote denial of service

2014.02.13
Credit: Robert Scheck
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-20


Ogólna skala CVSS: 5/10
Znaczenie: 2.9/10
Łatwość wykorzystania: 10/10
Wymagany dostęp: Zdalny
Złożoność ataku: Niska
Autoryzacja: Nie wymagana
Wpływ na poufność: Brak
Wpływ na integralność: Brak
Wpływ na dostępność: Częściowy

I discovered a flaw (CVE-2014-0079) in Zarafa that allows a remote unauthenticated attacker to crash the zarafa-server daemon with a segmentation fault, preventing access to any other legitimate Zarafa users. This flaw is not to be confused with CVE-2014-0037 from 2014-01-31. Affected product: Zarafa Collaboration Platform <= 7.1.8 Access Vector: Network Access Complexity: Low Authentication: None Confidentiality Impact: None Integrity Impact: None Availability Impact: Complete The interesting thing is that the official RPM/DEB packages provided by Zarafa are not affected, however all community/self-build binaries seem to be affected (such as shipped e.g. in Fedora and Fedora EPEL). As I don't know the build environment at Zarafa, I tried to do binary analysis with the following results: Binaries built by Zarafa contain the objects GLIBC_2.3.4 and GLIBCXX_3.4.11 while Fedora EPEL binaries have the objects GLIBC_2.4 and GLIBCXX_3.4.11 (this example is based on RHEL/CentOS 6). This leads me to the conclusion that at least GLIBC < 2.4 is used in Zarafa's build environment. However I unfortunately can not exclude that Zarafa also uses different build-time flags having some impact, too. Finally all Zarafa binary packages in Fedora and Fedora EPEL are affected where RHEL/CentOS 5 (with the oldest software) ships GLIBC 2.5 and Fedora Rawhide ships GLIBC 2.18.90 (currently as the latest). As Zarafa has not released any update so far, downstreams should use the following patch (which has been proposed to upstream already): --- snip --- --- zarafa-7.1.8/provider/libserver/ECSession.cpp 2014-01-21 15:38:53.000000000 +0100 +++ zarafa-7.1.8/provider/libserver/ECSession.cpp.rdos 2014-01-29 01:26:49.000000000 +0100 @@ -865,10 +865,10 @@ { ECRESULT er = erSuccess; - if (!lpszName) + if (!lpszName || !lpszPassword) { // Commandment 2: Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end. - m_lpSessionManager->GetLogger()->Log(EC_LOGLEVEL_FATAL, "Invalid argument lpszName in call to ECAuthSession::ValidateUserLogon()"); + m_lpSessionManager->GetLogger()->Log(EC_LOGLEVEL_FATAL, "Invalid argument %s in call to ECAuthSession::ValidateUserLogon()", (!lpszName) ? "lpszName" : "lpszPassword"); er = ZARAFA_E_INVALID_PARAMETER; goto exit; } --- snap --- See also: https://bugzilla.redhat.com/show_bug.cgi?id=1059903 - thanks to the Red Hat Security Response Team, specifically to Vincent Danen. I finally would like to thank my employer, the ETES GmbH (www.etes.de), who allowed me to spend time to research this issue and thus to provide a patch to upstream. With kind regards Robert Scheck -- Fedora Project * Fedora Ambassador * Fedora Mentor * Fedora Packager

Referencje:

http://cxsecurity.com/issue/WLB-2014020003


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top