Re: prominent message on website about "use only on trusted input"?

Quoting electricworry <[email protected]> (from Fri, 28 Jul 2017  
12:51:00 +0100):

> On 28 July 2017 at 10:56, Alexander Leidinger  
> <[email protected]> wrote:
>> given the recent messages about more attention by security researchers to
>> LAME, I suggest we add a prominent message (maybe even on the main page)
>> about using LAME only on trusted input.
>>
>> For me LAME was never developed with security in mind, just to be used on
>> trusted input (letting aside the question what trusted input is after the
>> rootkit-mistake Sony did in the past).
>>
>> Comments?
>
> If I may chime in, I would say that the security of LAME seems good.
> None of the issues I've seen allow for any remote code execution. At
> best they can crash the program (probably getting a CVSS score of
> around 2.5) or they only crash the program if caught by address
> sanitizer (so a normal build would get a CVSS score of 0.0).
>
> What would you be trying to achieve with such a disclaimer. If it's to
> avoid claims of liability, that's understandable but I would imagine
> you've already got that in the license already.
>
> If it's to protect the project from the work of having to deal with
> reports of security type issues, then I'm not sure that's a great
> idea. At some level, the LAME project wants to be used and trusted
> widely, and if a project was to ignore security reports, I think
> that's a problem for distros and other adopters. I think the best
> approach would be to deal with these small issues with the priority
> they deserve (low or none). I also think/hope that in the unlikely
> event of a higher severity remote code execution that you would want
> to resolve that.

The goal is to set the expectations of the users right.

Fact is, the last released version is 5 years old. Some parts of LAME  
can surely be improved, but it didn't really happen. Those people with  
write access to the source of LAME did not really produce some  
enhancements which seem to be worth a new release within 5 years.  
Patches which are available (either in a linux distribution or in the  
bugtracker) are not looked at and committed. I also don't have the  
impression that anyone had a look at the reports of security issues we  
got in the last month (not only from you). I would like to have a look  
at them and to fix them, I just don't have (/make) the time to do it.  
I expect the I'm not the only one in this regard.

Yes, any security issue in LAME may not be remotely exploitable (as we  
don't listen on the network) and as such doesn't get a high CVSS  
score. It will also only be exploitable in the context of the user  
which executes lame with the malicious input file and as such (let'S  
assume nobody runs it as root) is not related to a root-exploit (and  
again doesn't get a high CVSS score). What could happen is a DoS, if  
LAME is used in an automated music conversion service, but then it is  
on those which have setup such a service to protect it from a DoS.  
What also could happen is some kind of ransomware-infection (in the  
worst case), which may not be likely, but something you don't want to  
happen to you.

In the end the CVSS score doesn't matter, what matters is that there  
may be a disclosure of a security issue with no fix from our side (if  
we take the last 5 years as the benchmark of changes in LAME). Even if  
the issue is just a segfault, what is visible is "there is no fix for  
a security issue". We can even go further, we have an encrypted  
archive in the bugtracke. If it is encrypted and not readable for  
everyone, everyone who stumbles over this has to think that it has to  
be a serious issue, right? And it is not looked at or even fixed.

So why not being honest and tell to the people: look, we have a bad  
track record of reacting to reported issues/patches, and we know that  
nobody made sure that LAME is secure. If you use "good" input files,  
everything will be fine, but if you use malicious input files  
(specially crafted files to do harm to wherever the account which  
executes LAME has access to), then we don't know what will happen  
(best case only a segfault), so better make sure you only use "good"  
input files.

Maybe this is exagerated. Maybe it is not necessary. That's why I  
asked for comments.

Bye,
Alexander.

-- 
http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot