PDA

View Full Version : SLES 12 SP2 PHP 7 version



bkesting
18-Jul-2018, 22:22
I have a SLES 12 SP2 system running with PHP 7.0.7 installed. I don't see any PHP updates via YaST. I need, for security, to update to at least version 7.0.8.

Is there an official build of 7.0.8 for SLES 12 SP2 anywhere? Alternatively, what version of PHP 7 is available with SP3 for SLES 12?

Thanks

malcolmlewis
18-Jul-2018, 23:29
I have a SLES 12 SP2 system running with PHP 7.0.7 installed. I don't see any PHP updates via YaST. I need, for security, to update to at least version 7.0.8.

Is there an official build of 7.0.8 for SLES 12 SP2 anywhere? Alternatively, what version of PHP 7 is available with SP3 for SLES 12?

Thanks
Hi
The current version I see for SLE 12 SP3 is;


Repository : SLE-SDK12-SP3-Updates
Name : php7
Version : 7.0.7-50.38.2


Now, version numbers especially minor ones don't mean much if you have some tool that uses version numbers for security checks. What is done on SLE is security fixes are backported. So the first thing you should do on your current system is check the installed version changelog either via YaST Software Management of via rpm -q <some-package> --changelog |grep <your CVE>.

Perhaps check this first, also is the system registered for updates and up to date?

ab
18-Jul-2018, 23:33
SLE 15 has PHP 7.2.5 it would seem, in case that helps:



/mnt/tmp/Module-Web-Scripting/x86_64/apache2-mod_php7-7.2.5-2.9.x86_64.rpm
/mnt/tmp/Module-Web-Scripting/x86_64/php7-7.2.5-2.9.x86_64.rpm


Before getting into human-added version numbers, could you help us
understand exactly which security fixes you are hoping to get with PHP
7.0.8? I ask because the version numbers that you may expect from
upstream do not exactly align forever within SLE because SUSE tries to
maintain a stable base, meaning they will backport fixes from 7.0.8,
7.1.x, and beyond back into 7.0.7. You can see these fixes either on
SUSE's security pages, or else in package changelogs themselves.

In summary, if your auditors merely state, "You must be on 7.0.8 or later"
then that is a meaningless request, because the number 7.0.8 is
meaningless. If you have proper security folks (or if that is you) who
insist on being patched for issue X or vulnerability Y, then you may find
it is already done. This page may help you with those:
https://www.suse.com/security/cve/

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

bkesting
19-Jul-2018, 02:13
My ISP audits my internet facing services and has logged several issues with my current php setup. Like this for example:

https://www.tenable.com/plugins/nessus/91899

bkesting
19-Jul-2018, 02:14
I am currently up to date within SLES 12 SP2

malcolmlewis
19-Jul-2018, 03:01
My ISP audits my internet facing services and has logged several issues with my current php setup. Like this for example:

https://www.tenable.com/plugins/nessus/91899
Hi
So you need to advise your ISP to test for vulnerabilities, not versions..... ;)

So, if you follow the link provided by Aaron to the CVE list but the first one points to CVE-2016-5766 which was fixed (fixed 2016-08-16) with bsc#986386
https://bugzilla.suse.com/show_bug.cgi?id=986386

The others in the list will likely be there as well...

So check the changelog as the other non CVE reference may be present, you will also note that those fixes also included PHP5 if you where running that...

Email your ISP the changelog perhaps?

bkesting
19-Jul-2018, 03:19
Okay...I will do that.

Thanks

smflood
19-Jul-2018, 11:20
On 19/07/18 03:04, malcolmlewis wrote:

> So you need to advise your ISP to test for vulnerabilities, not
> versions..... ;)
>
> So, if you follow the link provided by Aaron to the CVE list but the
> first one points to CVE-2016-5766 which was fixed (fixed 2016-08-16)
> with bsc#986386
> https://bugzilla.suse.com/show_bug.cgi?id=986386
>
> The others in the list will likely be there as well...
>
> So check the changelog as the other non CVE reference may be present,
> you will also note that those fixes also included PHP5 if you where
> running that...
>
> Email your ISP the changelog perhaps?

My guess is the ISP has scanned the server and got a response back when
hitting the web port(s) revealing the server is running Apache with PHP
configured that also includes the version numbers and then making an
assumption.

This information can be controlled via the ServerTokens directive in the
Apache configuration files which you can easily set by changing
APACHE_SERVERTOKENS in /etc/sysconfig/apache2 then restarting Apache. My
guess if it's revealing the PHP version is that it's currently set to
Full (or unset). Please see
http://httpd.apache.org/docs/2.4/mod/core.html#servertokens for an
explanation of possible options.

HTH.
--
Simon
SUSE Knowledge Partner

------------------------------------------------------------------------
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------

bkesting
19-Jul-2018, 14:14
On 19/07/18 03:04, malcolmlewis wrote:

> So you need to advise your ISP to test for vulnerabilities, not
> versions..... ;)
>
> So, if you follow the link provided by Aaron to the CVE list but the
> first one points to CVE-2016-5766 which was fixed (fixed 2016-08-16)
> with bsc#986386
> https://bugzilla.suse.com/show_bug.cgi?id=986386
>
> The others in the list will likely be there as well...
>
> So check the changelog as the other non CVE reference may be present,
> you will also note that those fixes also included PHP5 if you where
> running that...
>
> Email your ISP the changelog perhaps?

My guess is the ISP has scanned the server and got a response back when
hitting the web port(s) revealing the server is running Apache with PHP
configured that also includes the version numbers and then making an
assumption.

This information can be controlled via the ServerTokens directive in the
Apache configuration files which you can easily set by changing
APACHE_SERVERTOKENS in /etc/sysconfig/apache2 then restarting Apache. My
guess if it's revealing the PHP version is that it's currently set to
Full (or unset). Please see
http://httpd.apache.org/docs/2.4/mod/core.html#servertokens for an
explanation of possible options.

HTH.
--
Simon
SUSE Knowledge Partner

------------------------------------------------------------------------
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------

Great info...I will look into that too. Thanks!