Re: Security issues and concerns regarding soc addon

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

Hello Adolf,

> On 28 Jul 2023, at 13:51, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> To make it clear this is nothing to do with Core Update 177 Testing.
> 
> Someone on the forum reported a problem with trying to run the sox addon.

https://community.ipfire.org/t/sox-on-rpi-doesnt-work/10097

> I had a look at sox and tried to install it and then ran sox --version which then came up with a missing library.
> Installed the addon that provided that library and then there was another missing library and so on.
> 
> sox kept having missing libraries until I had installed all of the following:-
> 
> alsa
> flac
> libmad
> libid3tag
> lame
> 
> The only dependency listed in sox was libvorbis. All these others should really be present as well.

This is correct. /usr/bin/sox is directly linked against those.

> After installing all those dependencies I ran sox --version and basically sox just hangs with no response at all. Ctrl C was required to stop it.

> So I was wondering why sox was added to IPFire originally.

This was required for music-on-hold on Asterisk and encoding the voice prompts.

We no longer have Asterisk.

> Looking through the web site info I found that the current version was released in 2015. The last commit looks to have been in 2021.
> 
> I found that Arch Linux is taking a git snapshot version due to there being many unfixed security vulnerabilities. Additionally they are patching with a patch that was used in Openwall to deal with 8 CVE's plus a fix for a CVE fix that introduced a regression.
> 
> The above does not make me feel very comfortable at all with having sox in IPFire.

Not really, there is no way to execute it. We never accept anything from the network that we would pipe into sox, so there is no risk from my point of view.

> It is described as the Swiss Army knife of sound processing programs and my view, based on my investigation, is that it should be removed from IPFire.

It is. And I suppose we can lose it as it does not serve its original purpose any more.

> If users want to use it then it should be done on machines on the lan connected to IPFire, not on IPFire itself.
> 
> 
> Looking forward to feedback on my observations and conclusion.

Best,
-Michael

> 
> Regards,
> 
> Adolf.
> 
> -- 
> Sent from my laptop
>