CVE-2013-2221: Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119)
value: Heap-based buffer overflow in the ZRtp::storeMsgTemp function in GNU ZRTPCPP before 3.2.0 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a large packet.
CWE description: The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Published: 2013-10-04T17:55Z
Repository: https://github.com/wernerd/ZRTPCPP
Language: Other
Files changed: CMakeLists.txt, NEWS, README.md
Commit date: 2013-06-26 09:00:33 +0200
Commit message: Change build files to generate version 3.2.0

Diff: diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2ecb0c7..61760ef 100755
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,14 +11,14 @@
 cmake_minimum_required(VERSION 2.6)
 
 PROJECT(libzrtpcpp)
 
 SET(CPACK_PACKAGE_VERSION_MAJOR 3)
-SET(CPACK_PACKAGE_VERSION_MINOR 1)
+SET(CPACK_PACKAGE_VERSION_MINOR 2)
 SET(CPACK_PACKAGE_VERSION_PATCH 0)
 
-set (VERSION 3.1.0)
+set (VERSION 3.2.0)
 set (SOVERSION 3)
 
 # Define supported command line parameters.
 #
 # Example to build the tivi client: cmake -DTIVI=true ..
diff --git a/NEWS b/NEWS
index 6224923..f4bed2b 100755
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,101 @@
+
+== GNU ZRTP 3.2.0 ==
+
+The main ZRTP modules contain fixes for three vulnerabilities found by Mark
+Dowd. Thus we advise application developers to use this version of the
+library. The vulnerabilities may lead to application crashes during ZRTP
+negotiation if an attacker sends prepared ZRTP packets. The fixes remove these
+attack vectors.
+
+Some small other enhancements and cleanup, mainly inside client code.
+
+Some enhancements in cache handling and the handling of retained shared
+secrets. This change was proposed by Phil, is a slight security enhacement and
+is fully backward comaptible.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+For details please refer to the Git logs.
+
+
+== GNU ZRTP 3.1.0 ==
+
+This version adds some new features and code that supports some other
+client and this accounts for the most changes inside this release. 
+
+The ZRTP core functionality was not changed as much (bug fixes, cleanup
+mainly) and remains fully backward compatible with older library
+versions. However, one nice enhancement was done: the addition of a standalone
+SDES support module. This module supports basic SDES only without the fancy
+stuff like many other SDES implementations. Thus it's pretty interoperable.
+
+Some other features are:
+- add some android support for a client, may serve as template for others
+- documentation and code cleanup
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+
+== GNU ZRTP 3.0.0 ==
+
+This is a major enhancement and restructuring of the overall ZRTP
+distribution. This was necessary because more and more other clients use ZRTP
+and add their specific glue code. Also some clients are not prepared to use
+openSSL or other crypto libraries to their code and distributions. 
+
+Here a summary of the changes
+- a new directory layout to accomodate various clients
+- add standalone crypto modules, for example for AES, to have a real
+  standalone ZRTP/SRTP library that does not require any other crypto library
+  (optional via CMake configuration)
+- Re-structure ZRTP cache and add SQlite3 as optional storage backend
+
+The default settings for CMake build the normal ZRTP library that use openSSL
+as crypto backend, use the normal file based cache and include the GNU ccRTP
+modules. This is a librray that is to a large degree compatible with the
+earlier builds.
+
+Please refer to the top level CMakeFile.txt for options how to switch on the
+standalone crypto mode or the SQlite3 based cache storage.
+
+
+== GNU ZRTP 2.3.0 ==
+
+Add a "paranoid" mode to ZRTP. If and applications switches to this mode then
+the ZRTP stack _always_ asks the user to confirm the SAS thus ZRTP behaves as
+if it does not have a cache to store the retained secrets. However, setting
+the paranoid mode does not diable the cache, only the GUI behaviour.
+
+Enhance the CMake scripts to build a ZRTP library that does not contain GNU
+ccRTP modules and does not require ccRTP dependencies.
+
+== GNU ZRTP 2.2.0 ==
+
+Add stubs, callbacks and other provisions to prepare the full implementation
+of the SAS signing feature, see RFC6189, section 7.2. This feature needs
+support from applications and is rarely used if at all.
+
+As usual smaller fixes, code clean up etc.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+== GNU ZRTP 2.1.2 ==
+
+The main topic of this release was to add SRTCP support and some missing
+optional features of ZRTP. 
+
+As such I've added some new API and classes that applications may use to add
+SRTCP or to use the new ZRTP features. the ZRTP stack now supports PBX
+handling, refer to RFC6189 section 7.3ff.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
 == GNU ZRTP 2.0.0 ==
 
 Modify some files to use the new uCommon/commoncpp libraries instead
 of the GNU CC++ commoncpp2. This affects the ccRTP depended modules
 such as ZrtpQueue and the Timeout stuff.
diff --git a/README.md b/README.md
index b1fadfd..7ab769a 100644
--- a/README.md
+++ b/README.md
@@ -18,14 +18,13 @@ C++ supports the following features:
 * The SRTP authentication methods HMAC-SHA1 with 32 bit and 80 bit length and
   the Skein MAC with 32 bit and 64 bit length
 * The Short Authentication String (SAS) type with base 32 encoding (4
   characters)
 
-Enhanced features like PBX SAS relay aka *trusted Man-in-the-Middle* or
-preshared mode are not supported but the GNU ZRTP C++ implementation defines
-the necessary external interfaces and functions for these enhanced features
-(stubs only).
+Some features like preshared mode or signed SAS are not supported but the GNU
+ZRTP C++ implementation defines the necessary external interfaces and
+functions for these enhanced features (stubs only).
 
 ### SDES support
 This release also provides SDES support. The SDES implementation does not
 support all of the fancy stuff but is usable in most cases. This implementation
 however supports the new SDES crypto mixing to overcome some security issues

Vulnerable code: SET(CPACK_PACKAGE_VERSION_MINOR 1)
set (VERSION 3.1.0)
Enhanced features like PBX SAS relay aka *trusted Man-in-the-Middle* or
preshared mode are not supported but the GNU ZRTP C++ implementation defines
the necessary external interfaces and functions for these enhanced features
(stubs only).
Fixed code: SET(CPACK_PACKAGE_VERSION_MINOR 2)
set (VERSION 3.2.0)

== GNU ZRTP 3.2.0 ==

The main ZRTP modules contain fixes for three vulnerabilities found by Mark
Dowd. Thus we advise application developers to use this version of the
library. The vulnerabilities may lead to application crashes during ZRTP
negotiation if an attacker sends prepared ZRTP packets. The fixes remove these
attack vectors.

Some small other enhancements and cleanup, mainly inside client code.

Some enhancements in cache handling and the handling of retained shared
secrets. This change was proposed by Phil, is a slight security enhacement and
is fully backward comaptible.

Because of some API changes clients must be compiled and linked with the new
library.

For details please refer to the Git logs.


== GNU ZRTP 3.1.0 ==

This version adds some new features and code that supports some other
client and this accounts for the most changes inside this release. 

The ZRTP core functionality was not changed as much (bug fixes, cleanup
mainly) and remains fully backward compatible with older library
versions. However, one nice enhancement was done: the addition of a standalone
SDES support module. This module supports basic SDES only without the fancy
stuff like many other SDES implementations. Thus it's pretty interoperable.

Some other features are:
- add some android support for a client, may serve as template for others
- documentation and code cleanup

Because of some API changes clients must be compiled and linked with the new
library.


== GNU ZRTP 3.0.0 ==

This is a major enhancement and restructuring of the overall ZRTP
distribution. This was necessary because more and more other clients use ZRTP
and add their specific glue code. Also some clients are not prepared to use
openSSL or other crypto libraries to their code and distributions. 

Here a summary of the changes
- a new directory layout to accomodate various clients
- add standalone crypto modules, for example for AES, to have a real
  standalone ZRTP/SRTP library that does not require any other crypto library
  (optional via CMake configuration)
- Re-structure ZRTP cache and add SQlite3 as optional storage backend

The default settings for CMake build the normal ZRTP library that use openSSL
as crypto backend, use the normal file based cache and include the GNU ccRTP
modules. This is a librray that is to a large degree compatible with the
earlier builds.

Please refer to the top level CMakeFile.txt for options how to switch on the
standalone crypto mode or the SQlite3 based cache storage.


== GNU ZRTP 2.3.0 ==

Add a "paranoid" mode to ZRTP. If and applications switches to this mode then
the ZRTP stack _always_ asks the user to confirm the SAS thus ZRTP behaves as
if it does not have a cache to store the retained secrets. However, setting
the paranoid mode does not diable the cache, only the GUI behaviour.

Enhance the CMake scripts to build a ZRTP library that does not contain GNU
ccRTP modules and does not require ccRTP dependencies.

== GNU ZRTP 2.2.0 ==

Add stubs, callbacks and other provisions to prepare the full implementation
of the SAS signing feature, see RFC6189, section 7.2. This feature needs
support from applications and is rarely used if at all.

As usual smaller fixes, code clean up etc.

Because of some API changes clients must be compiled and linked with the new
library.

== GNU ZRTP 2.1.2 ==

The main topic of this release was to add SRTCP support and some missing
optional features of ZRTP. 

As such I've added some new API and classes that applications may use to add
SRTCP or to use the new ZRTP features. the ZRTP stack now supports PBX
handling, refer to RFC6189 section 7.3ff.

Because of some API changes clients must be compiled and linked with the new
library.

Some features like preshared mode or signed SAS are not supported but the GNU
ZRTP C++ implementation defines the necessary external interfaces and
functions for these enhanced features (stubs only).