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 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.