Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72400
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
Message-ID: <52F62B61.7030305@lsces.co.uk>
Date: Sat, 08 Feb 2014 13:04:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <52F61A78.1020401@lsces.co.uk> <CAF+90c9ZmeysC88ghHk50rpv_8T4jYhGCWEDwZxOR5EmPuDDLg@mail.gmail.com>
In-Reply-To: <CAF+90c9ZmeysC88ghHk50rpv_8T4jYhGCWEDwZxOR5EmPuDDLg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Security Diligence
From: lester@lsces.co.uk (Lester Caine)

Nikita Popov wrote:
> On Sat, Feb 8, 2014 at 12:52 PM, Lester Caine <lester@lsces.co.uk
> <mailto:lester@lsces.co.uk>> wrote:
>
>     I think an explanation of my recent posts is probably due.
>
>     The bulk of my income is from council and other local authority customers
>     who are required to jump through many often difficult to identify hoops.
>     They are currently being put through another round of 'security assessments'
>     and I had a second visit to a site which we have yet to upgrade from PHP5.2
>     earlier this week. The system is doing exactly what the 'customer' wants (
>     the client is the customer services team ), and while the IT department has
>     been providing network access since it was installed in 2007, it has no
>     outside access other that a VPN/VNC link so I can carry out maintenance. As
>     a result it has not been necessary or easy to upgraded to later 'security
>     patches'.
>
>     It's the last of my 'CMS' sites that I have to upgrade to PHP5.4 and that
>     was the discussion before Xmas, but the IT department have now realised that
>     they should be managing the network better :) Driven by their current
>     security assessment, linked to removing Windows XP from it. Since two of the
>     CMS machines are running XP, these will need to be replaced, but it is the
>     Apache/PHP stack which the 'security consultant' has been targeting
>     insisting that only a CURRENT version of both will be acceptable, and PHP5.4
>     is not current in his eyes despite it getting security updates independent
>     of PHP5.5.
>
>     I am more than happy that within the constraints applied I have maintained
>     the PHP5.2 setup as 'safe' as I can and since these sites are all ring
>     fenced inside the site network personally I do not see a problem. This view
>     is actually supported by the IT staff, it is the independent consultant who
>     is now putting up objections to our continuing to supply the CMS service.
>     Unpatched reported security problems are one of his objections and timed
>     attack was one brought up probably because it's discussion is currently
>     happening! We are currently trying to work out how to move forward, and
>     since the service provides an essential part of the handling of visitors
>     there is a desire by the users to maintain it ;)
>
>     Why is this all so futile?
>     The system is still using the same 4 digit 'pin number' to identify a staff
>     id that was instigated when the system was first designed back in 1992, and
>     when many access positions were just numeric pads with small displays! No
>     sensitive data is stored ...
>
>     ( Firebird's password is still limited to 8 characters for historic reasons,
>     so the length is a known and the hash decode is designed to check all
>     characters even if an earlier compare fails ... so maintains a fixed test time )
>
>
> I'm sorry, but how does this relate to the internals mailing list?

Hopefully to put some of the discussions into context of where they fit in the 
real world. Is the 'timing attack' or problems created by an 'insecure' random 
number a practical proposition? The only physical proof that I have seen 
presented for the 'timing attack' is 10 years old and relates to a 'small local 
network'? Processor speed has increased a little in 10 years and we now tend to 
work in 64bit chunks rather than 8 or 16bit? Although that does also enhance the 
power of the hackers ... So discussing something based on timing 8bit characters 
seems a little strange? Firebird code dropped the 10 year old process a few 
versions back. I was trying to establish where the risk was in PHP and while I 
am more than happy it does not exist in my own applications, while it remains an 
'unpatched security risk' others will not accept that fact. What is still 
missing from the discussion is the level of risk these 'security problems' 
present? Grounding the security RFC's in a little factual base would be 
appreciated so that proper defence can be presented when required. Obviously 
'fix in X' is ideal, but only if the full risk has been assessed?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk