2012.10.14 19:50 "Re: [Tiff] Buffer Overflow Study at Auburn University - LibTIFF developers I would really appreciate your help!", by Frank Warmerdam
On 12-10-13 11:12 PM, Auburn Study wrote:
I am a graduate student at Auburn University, working with Dr. Munawar Hafiz on an empirical study project to understand the software engineering practices used in companies that produce secure software. In particular, we are concentrating on how developers write code to prevent buffer overflow and integer overflow vulnerabilities. We are interested in the software development process: how you develop software, how you test and analyze programs to detect vulnerabilities, and what processes you follow to remove bugs. We are looking into automated tools that software developers use, and are expecting that there is a common insight in the security engineering process that can be reusable.
We request your assistance by participating in this research study. We would greatly appreciate it if you would share your experience with us by answering the questions at the end of this email. We may send some follow up questions based on your response in future. Your response(s) will be kept confidential, and will only be aggregated with those of other reporters. Please let us know if you have any questions or concerns regarding the study. Thanks in advance for your support.
Software Analysis, Transformations and Security Group Auburn University
Working under the supervision of:
Dr. Munawar Hafiz
Dept. of Computer Science and Software Engineering
Questions: (There are ten questions.)
- How long have you been a software developer?
- How long have you been affiliated with LibTIFF? Were you part of the original development team for this software?
I've been using libtiff for around 19 years, and a contributor for about 18 years. I was not one of the original developers. It was originally developed by Sam Leffler starting I believe in the late 1980's.
- What is the size of the current code base?
approximately 40000 lines of code (based on raw line count).
- Did you follow a coding standard when developing this software? Is it a standard determined by your group?
I'm not sure what you mean by code standard, but I think the answer is safely "no".
- What did you use to manage bug reports in your software? Does it satisfy your requirements? Are there other software options that you would consider switching to?
We are currently using bugzilla to manage bug reports. It is adequately. I use Trac for other projects and like it's closer connection to the source repository history and wouldn't mind switching to that.
- Did you use any compiler options to detect integer overflow vulnerabilities? Do you think that they are useful?
I am not familiar with using compiler options to detect integer overflow.
- Did you use any automated (static or dynamic analysis) tools to detect buffer overflows, integer overflows, or any other bugs? Which tools did you use? Why these tools?
I have made some use of the coverity static analysis too.
I make extensive use of valgrid at runtime.
Security folks (at red hat and google) have also uses ASAN, an address sanitizer that does roughly similar things to valgrind.
- Did you use fuzzing? Which tools did you use and why? If you wrote your own fuzzer, why did you write it yourself? Was it written from scratch or by extending some other fuzzing tools?
Security folks at Google and elsewhere have made extensive use of fuzzing to provide me test files demonstrating crashability of libtiff.
- Did you have specific phases during development where you concentrated on fixing security issues? Did you have a test suite, unit tests, or regression tests?
No. With the exception of the libtiff4 "big tiff" project libtiff has been in maintenance mode for 15 years and there is no real effort to differentiate between development phases and fixing/testing phases.
We have a modest test suite mostly developed in recent years and with poor coverage. We do not have code unit tests. The test suite is to some extent a regression test suite.
- Buffer overflows often result from the use of unsafe functions, such as strcpy. Does your software use those? If you use a different string library, why is it used? Is it an in-house library or an off-the-shelf library? Did you migrate your code to use the string library?
We do use strcpy but that is not the primary source of buffer overflows in libtiff and we have not focused on avoiding it.
I set the clouds in motion - turn up | Frank Warmerdam, email@example.com
light and sound - activate the windows | http://home.gdal.org/warmerda and watch the world go round - Rush | Geospatial Software Developer