lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 1 May 2007 20:52:51 +0300
From: no-reply@...ware.com
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk,
	vulnwatch@...nwatch.org, voipsec@...psa.org
Subject: Radware Security Advisory - Yate 1.1.0 Denial of
	Service Vulnerability

Yate 1.1.0 Denial of Service Vulnerability



Risk: Medium


Background:


Yate (Yet Another Telephony Engine) is a production-ready next-generation telephony engine.

More information about this application could be obtained from the following site:

http://yate.null.ro/


Description:


The SIP channel module of Yate contains a denial of service vulnerability, introduced by a
null pointer dereference, which could be provoked by having the SIP module process SIP messages
containing the "Call-Info" header, without the "purpose" parameter as part of its value.

The flaw can be seen in the following source code snippet:

File:    yate/modules/ysipchan.cpp
Lines:   1585 - 1594

1:    const SIPHeaderLine* hl = m_tr->initialMessage()->getHeader("Call-Info");
2:    if (hl) {
3:        const NamedString* type = hl->getParam("purpose");
4:        if (!type || *type == "info")
5:            mp type->addParam("caller_info_uri",*type);
6:        else if (*type == "icon")
7:            m->addParam("caller_icon_uri",*type);
8:        else if (*type == "card")
9:            m->addParam("caller_card_uri",*type);
10:   }

Once the "Call-Info" header is found in the SIP message (line 1), there is an attempt to extract
the "purpose" parameter (line 3).
Afterwards, a decision is made to set the "caller_info_uri" parameter (line 5) to the value of the
"Call-Info" header, though due to a programming error, instead of assigning the parameter with the
header value, it is being assigned with the value of the "purpose" parameter - allowing for a null
pointer dereference, when the call to getParam() (line 3) returns 0 in case of a missing "purpose" parameter.


Analysis:

Exploiting this vulnerability could allow for denial of service to Yate and disruption of the VoIP
infrastructure.

By default no authentication is required to exploit this vulnerability, allowing for spoofed UDP SIP
messages to trigger the flaw.


Radware DefensePro IPS Solution:

Radware DefensePro customers are protected against this vulnerability since the release of signature
database version 0006.0030.00 by RWID's 7334,7338 and 7342.


Detection:

Radware Security Operations Center has confirmed the existence of this vulnerability in Yate 1.1.0.
Previous versions are also suspected to be vulnerable.


Workaround:

A workaround for this vulnerability is currently not known.


Vendor Response:

The maintainers of Yate addressed this vulnerability with the release of Yate 1.2.0.


CVE Information:

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2007-1693 to this issue.


Disclosure Timeline:

March 25, 2007  -       Initial vendor notification
March 25, 2007  -       Initial vendor response
March 26, 2007  -       Vendor fixes flaw in CVS
April 16, 2007  -       Vendor releases fixed version
April 30, 2007  -       Attack database release
May 1, 2007     -       Advisory release


Credit:

Yuri Gushin, Radware Security Operations Center


Legal Information:

Disclaimer: The information in the advisory is believed to be accurate at the time of publishing
based on currently available information. Use of the information constitutes acceptance for use in
an AS IS condition. There are no warranties with regard to this information. Neither the author
nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage
arising from use of, or reliance on, this information.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ