News for hackers. Stuff that matters.
Re:It's All About Time – Remote timing attacks in PHP by lucb1e on Friday November 28, 2014 @03:12PM (#8672027)
I've looked into timing attacks in the past but failed to exploit one. Even running php locally from the command line, eliminating any possibility of network randomness, I couldn't get even a few bytes with any amount of certainty.

Not saying it's not an issue, but I'm not so sure it's a big deal either.

Re:It's All About Time – Remote timing attacks in PHP by aj-code on Friday November 28, 2014 @03:23PM (#8672047)
I wrote a tool a while ago for testing network based timing attacks. Getting the measurement right is really hard, just taking the average doesn't generally work while the 10th percentile measurement is much better. I did find PHP fairly hard to exploit though, but I was trying over a network which much more difficult than locally.

The code for the tool (and a presentation pdf) is here if you're interested: https://github.com/aj-code/TimingIntrusionTool5000

Re:It's All About Time – Remote timing attacks in PHP by lucb1e on Friday November 28, 2014 @04:58PM (#8672278)
> just taking the average doesn't generally work

Oh, well yeah that's what I did. Guess I'll have to look further.

> the 10th percentile measurement is much better

That sounds like something to try, thanks!

Re:It's All About Time – Remote timing attacks in PHP by TheLoneWolfling on Friday November 28, 2014 @03:34PM (#8672068)
Even taking the straight minimum may be better.
Re:It's All About Time – Remote timing attacks in PHP by aj-code on Friday November 28, 2014 @03:48PM (#8672111)
You'd think so! But that's not what I found, I found the minimum, max, and average were all crap. Even the median wasn't very good compared to the 10th percentile (which I got the idea from for here http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf)
Re:It's All About Time – Remote timing attacks in PHP by rosenjon on Friday November 28, 2014 @04:11PM (#8672189)
This is also what I think. Start adding in database latency and other functions that execute alongside your string comparison, and this seems incredibly unreliable. It's not like most calls to a page only execute a single string comparison. Good to know, but seems low on the attack vector priority list.