Security Diligence

Andrea Faulds wrote:

I'm sorry, but how does this relate to the internals mailing list?

I might be reading it wrong, but I think Lester's saying "don't change PHP in
ways that force people to make their code secure, because it doesn't matter if
my code's insecure".

You are reading me wrong - as is Nikita ...
My own code is doing exactly as it has done for many years now with a level of
security that the customer is happy with. Adding any more is unnecessary, but
'security advisors' dictate otherwise without actually accessing the risk!
But what I'm asking for is that the documentation of the attempts to fix these
perceived threats includes just a little more information so those of us who are
not so 'expert' can better understand the nature of the risk?
Simply quoting third party articles like the wikipedia one does not address how
a risk actually relates to PHP.

Specifically looking at the 'timing attack', as I understand it, if a comparison
process scans all elements and simply sets a flag when failure is detected which
is not used until all characters have been processed. Which is the reason for
establishing 'safely' the number of characters involved. Using 64bit functions
rather than 32bit will also change the way that process works?

Much of the difficulty I have with PHP these days is simply trying to understand
why the 'new' method of working is better than what we did 10 or more years ago.
Good examples of practice is still very lacking even in the latest
documentation, and what goes into rfc's these days is the basis for updating the
main documentation?

--
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

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

Hi,

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

http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-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-businesses-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 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

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 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 ...

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ádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative