Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72402
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52F62B61.7030305@lsces.co.uk>
References: <52F61A78.1020401@lsces.co.uk>
	<CAF+90c9ZmeysC88ghHk50rpv_8T4jYhGCWEDwZxOR5EmPuDDLg@mail.gmail.com>
	<52F62B61.7030305@lsces.co.uk>
Date: Sat, 8 Feb 2014 14:55:42 +0100
Message-ID: <CAF+90c9-O=v0CkFHfTqURd1UTTuxK7N8X7iCqTa6hW2ova2YRw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122912c5e48cc04f1e576b9
Subject: Re: [PHP-DEV] Security Diligence
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0122912c5e48cc04f1e576b9
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Feb 8, 2014 at 2:04 PM, Lester Caine <lester@lsces.co.uk> wrote:

> 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?
>

If your system has many other open security concerns, then yes, timing
attacks are most certainly the least of your worries and you are very
welcome to ignore this issue until you have resolved the more pressing
ones. While I certainly appreciate working with secure software, it is not
a concern of this mailing list or its members whether or not you implement
mitigations against certain cryptographic attacks. It *is* however our
concern to provide the necessary means for the people who *do* wish to
implement the necessary safe-guards.

Also, I strongly suspect that you don't have sufficient cryptanalytic
background to assess the severity of certain attack vectors. While remote
string comparison timing attacks might be considered an exotic concern by
some people, usage of an unsuitable random number generator in the wrong
context is a most severe and typically easily exploitable vulnerability.
Dismissing it so easily certainly creates the impression that you have a
somewhat skewed perception of the severity of some attacks. You might
consider the possibility that your security consultant, given his line of
work, has a better understanding of application security than you do.

Thanks,
Nikita

--089e0122912c5e48cc04f1e576b9--