Re: [security-report]Lame multi memory error bug && CVE Request
Alexander Leidinger <[email protected]>
| Newsgroups | gmane.comp.audio.mp3.lame |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 30 Dec 2015 15:33:20 +0800 ChenQin <[email protected]> wrote: > reproduce: > lame 2 > lame 3 [segfault and heap overflow] Thanks for your report / security review. Could you please explain where 2 and 3 comes from? I assume it is a specially crafted input file to cause issues in LAME. After looking at the code I have to say that we already have code to make sure we don't go to a negative offset (2 "assert" before line 606), so I would have expected a SEGV instead of the heap overflow. Could you please explain which configure options you used to compile LAME? Could you please repeat the same test with a LAME compiled with "--enable-debug=norm" (I hope you can understand that I do not want to run LAME on my system with "unknown input"). I suspect we do the wrong thing in the no-debug case (= we should have the asserts always active). Regarding your request for a CVE I would like to share my personal opinion (= other project members may think differently). - LAME was not developed with security in mind (= trusted input). - As such I would be positively surprised if this is the only issues in the code. - Using a specially crafted input to cause issues inside LAME means to use untrusted input (instead of your own audio files). - There's a big legal minefield if you use anything which is not "your audio files", which means either illegal activity (which the LAME project doesn't support), or you need to have had already legal advice = this is a business case. - In case of business involved, it is responsible to make sure that the input is well formed for the use in LAME (= to make the input trusted). - Given above, I would consider your report as a robustness issues of LAME, not a security issue (I could imagine that there could be legal implications if we consider anything else than "our own audio files" as a valid input and asking for a CVE could be understood that we do that to the extend that it requires immediate action). Bye, Alexander. -- http://www.Leidinger.net [email protected]: PGP 0xC773696B3BAC17DC http://www.FreeBSD.org [email protected] : PGP 0xC773696B3BAC17DC ------------------------------------------------------------------------------