Dear Fulldisclosure,

I submitted the below vulnerability to the HP Zero Day Initiative. They
responded that they are not interested in vulnerabilities in this
"product".  Further, I tried to contact one of the authors Eric A. Young;
the email bounced.

I am busy with my day job and do not have the resources to identify a fix
team for TinySRP. I hope this potential vulnerability finds its way to
someone who can evaluate it critically.

Regards,
Doug

---------- Forwarded message ----------
From: Douglas Held <doug@douglasheld.net>
Date: Wed, Jan 28, 2015 at 12:31 PM
Subject: Potentially critical buffer overflow in TinySRP
To: eay@cryptsoft.com


Hi Eric,

I have submitted a potential security vulnerability to HP's Zero Day
Initiative.  Their business model is they purchase vulnerabilities from
discoverers, and they manage the responsible disclosure (or 0-daying of the
knowledge in some circumstances).

The reason why I am contacting you directly is that ZDI has now reported to
me a lead time of 4 months to review the vulnerability.  I would like to
let an expert review the pattern I've found, and see whether you agree
there is a problem.

I can understand fully that TinySRP is probably not your code! But your
email address is peppered throughout, as a number of people have taken your
code and wrapped it into something else.  I am not a C programmer and don't
know enough context to judge this beyond what I have written below.

Below my signature is the full submission text.  There is also a
screenshot, attached to the bottom of this email.

Kind Regards,
Douglas Held
-- 
Douglas Held
doug@douglasheld.net
+447775733093


*General*

The Tiny SRP library is a stripped-down version of srp-1.7.1 and
openssl-0.9.6 that contains only what is necessary for secure remote
passphrase authentication. No other libraries are required. If you already
have libsrp installed on both server and client then you don't need this.
Tiny SRP is designed for embedded or mini distributions, and is also a
quick and easy way to add secure authentication to small client/server
projects. Also included is the TSRP protocol, which reduces socket
authentication to one function call on each of the client and server.

According to http://freecode.com/projects/tinysrp/ the project is last
updated in 2001 and it does authentication. Good enough for me!!

*Summary*

There is a critical buffer overflow in the username field of the TinySRP
authentication library. The username is expected to be a maximum of 32
bytes, but the size of the string read from the network is provided by the
remote, anonymous attacker and not the program.


*Steps to reproduce*

1. Start with an Ubuntu 14 LTS server with 4 GB RAM
2. sudo apt-get install git g++ zlibc zlib1g zlib1g-dev gcc-multilib
subversion gawk libncurses5-dev
3. git clone git://git.openwrt.org/12.09/openwrt.git
4. cd openwrt
5. make (this opens a menu; set the target configuration to "Linux
Userspace")
6. OPTIONALLY: Install HP Fortify SCA version 4.21. Contact doug.held@hp.com
to get a license.
7. cd ./package/ead/src/tinysrp/
8. OPTIONAL: sourceanalyzer -b tinysrp make
9. OPTIONAL: sourceanalyzer -b tinysrp -Xmx3g -scan -f ~/tinysrp.fpr
10. OPTIONAL: Open the FPR and search for the issue instance ID
EF37705E7C9976DC2C0B5850B95A485D.
11. On tinysrp.c:157, the 32 byte username field is filled from the network
packet, up to "j" bytes.

*Expected results:*
j would be expected to be an integer ranging from 0 to 32.

*Actual results:*
j is the value of the first byte received from the network, set on
tinysrp:156. This can be greater than 32 and in my observation, is not
validated as such anywhere else in the program.

*Conclusion:*
A specifically malformed packet, with a value in the first byte unexpected
by the programmer, could overflow the username buffer and modify the
program in memory.


*Remarks*

This code could be relatively unused, or it could be widely deployed.
I did not try to contact the 2001 maintainer, the "professortom" user on
freecode.com. There are also many other email addresses and names contained
within the code.

I am happy to collaborate on forming a fix team, if the vulnerability can
be verified as exploitable. But I am not myself a C programmer.


*About the author*

Douglas Held is an application security professional specializing in the
identification of security vulnerabilities in source code. He is currently
the Chief Solutions Strategist for Hewlett-Packard Software's Fortify
business unit. He has been poking around in technology for approximately 30
years, and joined Fortify in 2007. Using Fortify SCA, he discovered the
buffer overflow in Ron Rivest's proposed md6 hash algorithm in December
2008. Until 2014, he had been running Fortify Professional Services in
Europe, Middle East and Africa. Outside of work, Doug enjoys learning human
languages, cooking, and flying light aircraft.