Hi Alex and Team,
i have got a security alert from my security team that i should run xibo server on only TLSv1.2(i.e i have to disable tlsv1.0, tlsv1.1, sslv2/sslv3 on server).
i am having xibo 1.7.5 on premise server running on windows 2008 r2 machine.
kindly lemme know if i disable all other protocols except tlsv1.2 my server will run properly.
That will depend on the Players and web browsers you connect to it rather than Xibo itself.
I’m sure modern versions of Chrome will support TLS 1.2 out the box, so if you’re using that for web management you won’t have an issue.
From the Player side, Android 5 supports it, so as long as your Android devices are running Android 5 or later, then they should be OK.
Windows Players again will depend on how Windows has been configured. I think the easiest thing will be for you to test on your environment and see.
If you’re having a focus on security, then 1.7.5 has known issues, and you should be keeping current in that regard. At least CMS 1.7.9 so any known issues are covered off.
Thanks for revert Alex,
Yes i have to upgrade to 1.8 latest version soon but before to it, i have few more query
i want to
Upgrade to the latest version of PHP|443
Upgrade to the latest version of PHP|80
question is which php version is supported in 1.8. series and does it have any secuity related issues for running on above ports.
PHP 5.6 is the latest supported version.
You won’t find any version of PHP that has no security issues, but the
latest version of PHP 5.6 is the best you can do.
Our Docker containers ship with PHP 5.6 as standard.
Hi Alex,
as per my security team they want xibo should have the latest version of PHP i.e PHP v7.2. is it do able in any way, in latest version of docker can we do it
Xibo doesn’t support PHP 7 at all currently.
PHP 5.6 is still supported by the PHP project for security issues, and that is what is required.
My main concern is security team, they gave me below initail update on fixing vulnerability.
We need to migrate the middleware components to the latest version and application code level changes. And also the application is integrated with different S/W components (Ex: Java, SDK JAVA, PHP, Patch list & etc …), Which cannot be migrated individually. Since, the component is bundled and packaged with the application.
Kindly check and let us know the confirmed solution for mitigating the below vulnerability.
Upgrade to the latest version of PHP|443
Upgrade to the latest version of PHP|80
Disable SSLv2, SSLv3, and TLS 1.0. The best solution is to only have TLS 1.2 enabled|443
And when i asked them to give Vulnerability details they said below.
As we have checked there is no CVE details available for the PHP but during scanning security team is able to connect via port 443 and 80.
The version recommended by server team is v7.2 to mitigate the vulnerability. Please check and let us know the next plan of action.
**if we upgrade to xibo docker container version of 1.8.2 can we hide that PHP vulnerability during scan from security team **
if it is doable on charge basis to please let me know the support charges for it.
i want to either upgrade PHP version or somehow hide it from security scan(if possible in docker to hide it away from security scan).
You can hide the PHP version in use with a change to your php.ini file, but that isn’t going to make anything more or less secure.
Xibo can’t run on PHP 7.2, or indeed 7.0 at present.
In Docker, it uses 5.6, which is still maintained for security fixes by the PHP project.
hi Alex,
i am still Badly stuck with latest Php Vulnerability support on Xibo Docker and Compatibility of Docker on Windows 2016/2012 Running on Virtual Machine, following to it i have below question please help me with answers
Can you please suggest me any tentative time(this year or next year) frame by Which PHPv7.2 will be included xibo docker.
Compatibility of Docker latest version on windows server 2016/2012 on VMWARE Machine is suitable or do we need Physical hardware machine Instead of Virtual Machine.(as i did testing of it on physical machine on windows 2010 OS it worked perfectly at one shot without any issues, but in windows 2012/2016 running on VMware i am still trying but no luck at)
please help me with above details.
PHP 7 support came with Xibo 1.8.5. That container runs PHP 7.0.
We’re not actively targetting 7.2. Using the very latest PHP version is fraught with issues as nobody supports it in all the libraries we use. I don’t see us using “latest” ever - we’ll always be a step or two beind.
Your auditers need to look at PHP properly and understand “latest” doesn’t equal most secure. Latest equals least tested.
PHP 7 is still supported for security fixes and is perfectly suitable for production use.
Docker works best on a Linux server. If you’re doing any heavy production use, a Windows server isn’t suitable in my opinion. If you must, then Docker on a physical machine is the best way to go. If you’re running a VM, then you can’t run Docker easily. You’d be much better off running a Linux VM, where you can then run Docker natively and take advantage of the performance benefits of that.
hi Alex
i am having xibo 1.7.5 on premise server running on windows 2008 r2 machine. let me know can these below vulnerabilities can be resolved if i upgarded latest version of xibo-docker 1.8.9
Vulnerabilities have been reported on Digital Signage application by our security team.
Apache HTTPD: HTTP_PROXY environment variable "httpoxy" mitigation (CVE-2016-5387
OpenSSL OOB write in BN_bn2dec() (CVE-2016-2182), OpenSSL Pointer arithmetic undefined behaviour (CVE-2016-2177)
Neither vulnerability are in Xibo itself, they’re in Apache and OpenSSL, which you’ve installed on your custom installation.
CVE-2016-5387 relates to Apache up to and including 2.4.23. Xibo in Docker uses 2.4.34, so is not affected.
CVE-2016-2182 and CVE-2016-2177 relate to OpenSSL up to and including 1.0.2h. Xibo in Docker doesn’t install OpenSSL directly, since SSL termination is handled by your upstream reverse proxy, but the version included in Alpine is 1.0.2o-r1 so again it’s not affected by this.
Upgrading to 1.8.11 with Docker will clear your system of those vulnerabilities, unless you use your existing webserver to be a reverse proxy for SSL termination, in which case it won’t resolve it. You’d also need to upgrade the locally installed Apache version as well.