TinySRP Buffer Overflow

`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 <[email protected]>  
Date: Wed, Jan 28, 2015 at 12:31 PM  
Subject: Potentially critical buffer overflow in TinySRP  
To: [email protected]  
  
  
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  
[email protected]  
+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 [email protected]  
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.  
`