Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.177 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:59:16 +0000
Message-ID: <CALwr1Gkhxh1geHTa8b_hvHgRbeVYkdjdMMcNb3Ym5nMvV9Jv2A@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Security Diligence
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

Hi,

On 8 February 2014 13:04, Lester Caine <lester@lsces.co.uk> wrote:
> Hopefully to put some of the discussions into context of where they fit i=
n
> the real world. Is the 'timing attack' or problems created by an 'insecur=
e'
> random number a practical proposition? The only physical proof that I hav=
e

http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Rando=
m-Values.html

I wrote that as detailed as I could for a general audience. The
weaknesses of various PRNGs has been exhaustively studied.

> seen presented for the 'timing attack' is 10 years old and relates to a

My blog references research from 2010 and I've referenced blog article
and two live talks from around the same year in an earlier email to
you. You keep insisting on having physical proof in a realm of study
where the research must be carried out both legally and ethically, and
actual exploits are rarely disclosed by the criminals who use them.
The exploit was proven to be practical which means it has surpassed
the bar where it needs to be actively defended against.

There was no physical proof that you could hack a refrigerator in 2013
but we've already had a long history of warning people about default
passwords and poor configuration of home devices. Under your logic,
that would mean we have no need to audit and secure refridgerators.
There was no physical proof that an attack had ever occured. Of
course, that line of thinking looks remarkably poor when someone
actually does hack a refridgerator, because all those security people
were right afterall. This really happened - it got detected (not
publicised by the hacker!) by a research team:
http://www.businessinsider.com/hackers-use-a-refridgerator-to-attack-busine=
sses-2014-1

> '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 somethi=
ng
> 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 doe=
s
> 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? Ground=
ing

That's a loaded gun because nobody here has audited your application
so I can't assess the risk of any given vulnerability for your
specific context. If I assume a worst case scenario, e.g. passwords
hashed using MD5, then a timing attack might well be high risk since
reversing the hash is so simple. If you use bcrypt, the risk would be
lower but you'd still need to go ask users to change their passwords
and suffer the negative publicity that may prompt. If you create CSRF
tokens using mt_rand(), again the risk would be higher compared to
using a strong random source - read the book chapter. Of course how
are you interpreting risk? Is it the possibility of an attack
occuring, or the possibility of an attack being successful? The
general principle is that the former is a given. As I implied before,
a lot of people didn't take MITM attacks as seriously as they should
have until Edward Snowden came along. That erroneous sense of
priorities is something we should try not to fall victim to.

You need to get out of the box where security is your enemy. It's an
evolving animal and PHP 5.6 is evolving to meet that challenge. Your
auditor is perfectly entitled and correct to raise questions over PHP
5.2. He's correct to raise concerns over timing attacks. He's doing
his job. If he didn't raise and press those concerns, I'd fire him in
favour of someone more competent.

>Why is this all so futile?
>The system is still using the same 4 digit 'pin number' to identify a staf=
f id that was instigated
>when the system was first designed back in 1992, and when many access posi=
tions were just
>numeric pads with small displays!
>No sensitive data is stored ...

Unless you own the data, you don't get to say it's not sensitive. It's
not your data. Is your place of work in the habit of releasing Staff
IDs to the public so I can ring some poor ignorant soul at a service
desk and beg them to reset my passwords inside your network? Is it in
the habit of disclosing on a public forum that it runs vulnerable
software that protects Staff IDs so that I can find that in a Google
search and start winding up my social engineering cannon and
penetration skills?

Your consultant is trying to bolster security and this is unlikely to
be the first time they've met resistance to their recommendations.
It's actually quite a common part of the job, and it's also why
consultants get called in in the first place - to be independent of
your concerns and those of the IT dept so that they can offer an
objective expert opinion. In their view, you are the refrigerator.

I can be a harsh judge, but don't take this the wrong way. You need to
put a little trust in the expertise of others and not put it all on
you. When security researchers are running scared over an issue, they
usually don't do so without some compelling motivation. By all means,
do your own research, but you need to also develop a sense of risk and
a skill in gauging the implications of any given threat. You see PHP
5.2 as being acceptable. I see it as a frickin' bomb waiting to go
off. Yet, we both agree that it's not secure? That our risk assessment
differs significantly is probably putting it mildly ;).

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative