Re: [security-report]Lame multi memory error bug && CVE Request

I'm sorry, but I just feel it necessary to give my opinion here.  It is absolutely legal and tested in the courts, for any individual or entity to copy and convert copyrighted media for which they hold a license to (ie, a CD) into alternate formats for backup and playback that does not copy beyond the original license holder.


That said, it is a poor argument to excuse a security flaw as some kind of moral reckoning for those who would break the law.  Especially when we know all too well how certain media producers (ie, Sony) have and continue to infect malicious code into their commercial works.


The last thing LAME needs is for all desktop, mobile and embedded devices that rely on LAME to become target of the next Sony Root Kit™.


Respectfully,

- I. Digress


From:"Alexander Leidinger" <[email protected]>
Date:Sat, Jan 2, 2016 at 1:11 AM
Subject:Re: [Lame-dev] [security-report]Lame multi memory error bug && CVE Request

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



------------------------------------------------------------------------------
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev

------------------------------------------------------------------------------
_______________________________________________
Lame-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev