Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's All About Time – Remote timing attacks in PHP

blog.ircmaxell.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: It's All About Time – Remote timing attacks in PHP

#11

Post by umsm »

totony wrote: post #9
umsm wrote: post #5

> NOTE In general, it's not possible to prevent length leaks. So it's OK to leak the length. I would imagine that you can prevent length leaks by looping through the characters of the known value and then returning that comparison with an additional check of length. function timingSafeEquals($safe, $user) { $safeLen = strlen($safe); $userLen = strlen($user); $result = 0; for ($i = 0; $i

The for loop duration here will vary depending on the length of the string

That was a quick copy/paste.

But imagine the loop would be the string we know (i.e. the password). Looping through the 10-character pass should be identical every time, regardless of what the user entered.

Re: It's All About Time – Remote timing attacks in PHP

#12

Post by totony »

hnmcs wrote: post #10
totony wrote: post #7

Earlier quoted context omitted.

I don't know how to do [code] tags

At this time, these few options are available: https://news.ycombinator.com/formatdoc >Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)

Thank you!

Re: It's All About Time – Remote timing attacks in PHP

#13

Post by totony »

umsm wrote: post #11
totony wrote: post #9

Earlier quoted context omitted.

The for loop duration here will vary depending on the length of the string

That was a quick copy/paste. But imagine the loop would be the string we know (i.e. the password). Looping through the 10-character pass should be identical every time, regardless of what the user entered.

I imagine the strlen() function is not constant-timed, so I'd remove it, but it might work yes (but you'd have to check PHP's source code and have a deep understanding of it to really be sure).

Re: It's All About Time – Remote timing attacks in PHP

#14

Post by pjbrunet »

How viable is this in the real world? I could imagine it working on a lone, quiet server at 4am with no other people on it. The average server with 100s of accounts, 1000s of users all doing various stuff, that's going to introduce enough random delay to throw off your analysis. Maybe you could try to calculate averages but that's going to increase the number of requests. Would a good hosting company block an attack like this at the hardware level? I'd guess yes, but I don't know.

Re: It's All About Time – Remote timing attacks in PHP

#15

Post by rosenjon »

lucb1e wrote: post #2

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.

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.

Re: It's All About Time – Remote timing attacks in PHP

#16

Post by Xylakant »

umsm wrote: post #5

> NOTE In general, it's not possible to prevent length leaks. So it's OK to leak the length. I would imagine that you can prevent length leaks by looping through the characters of the known value and then returning that comparison with an additional check of length. function timingSafeEquals($safe, $user) { $safeLen = strlen($safe); $userLen = strlen($user); $result = 0; for ($i = 0; $i

If you follow the link in the post you'll find a pretty convincing explanation why it's not possible to prevent leaking the length in the general case. I'm not certain that this applies to PHP code as well, since the problem is pretty low level.

However, leaking the length is much less of a problem than allowing the attacker to guess characters one by one.

Re: It's All About Time – Remote timing attacks in PHP

#17

Post by mappu »

totony wrote: post #13
umsm wrote: post #11

Earlier quoted context omitted.

That was a quick copy/paste. But imagine the loop would be the string we know (i.e. the password). Looping through the 10-character pass should be identical every time, regardless of what the user entered.

I imagine the strlen() function is not constant-timed, so I'd remove it, but it might work yes (but you'd have to check PHP's source code and have a deep understanding of it to really be sure).

libc `strlen()` is O(n), but PHP strings are binary safe (i.e. http://3v4l.org/47iaP ) so it must be storing a length as part of the string zval. So PHP strlen should be constant time.

+1 for recommending checking the PHP source code to be sure, though

Re: It's All About Time – Remote timing attacks in PHP

#18

Post by TazeTSchnitzel »

totony wrote: post #13
umsm wrote: post #11

Earlier quoted context omitted.

That was a quick copy/paste. But imagine the loop would be the string we know (i.e. the password). Looping through the 10-character pass should be identical every time, regardless of what the user entered.

I imagine the strlen() function is not constant-timed, so I'd remove it, but it might work yes (but you'd have to check PHP's source code and have a deep understanding of it to really be sure).

strlen() in PHP is constant-time O(1), we don't use C strings. (Well, we do, but we store length information and reference count them)

See: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_builtin_function...

Re: It's All About Time – Remote timing attacks in PHP

#19

Post by aj-code »

pjbrunet wrote: post #14

How viable is this in the real world? I could imagine it working on a lone, quiet server at 4am with no other people on it. The average server with 100s of accounts, 1000s of users all doing various stuff, that's going to introduce enough random delay to throw off your analysis. Maybe you could try to calculate averages but that's going to increase the number of requests. Would a good hosting company block an attack…

I think the reality is that this style of attack is difficult enough that it would be something of a last resort, and probably only tried on high value targets. It'd take a long time (you'd probably need 100s of millions of requests) and could be easily noticed.

That said, while it's not instant game over, you don't really want this vulnerability if you can avoid it. Especially in things like authentication libraries.

Re: It's All About Time – Remote timing attacks in PHP

#20

Post by Eridrus »

pjbrunet wrote: post #14

How viable is this in the real world? I could imagine it working on a lone, quiet server at 4am with no other people on it. The average server with 100s of accounts, 1000s of users all doing various stuff, that's going to introduce enough random delay to throw off your analysis. Maybe you could try to calculate averages but that's going to increase the number of requests. Would a good hosting company block an attack…

> How viable is this in the real world?

Not really viable against a native code memcmp. Potentially viable against a comparison implemented in PHP or Java.

Here's a video looking at actually implementing such attacks over LAN and internet: http://rdist.root.org/2010/11/09/blackhat-2010-video-on-remo...

> Would a good hosting company block an attack like this at the hardware level? No, there's no generic way to defeat this. The only real limit is how granular your attacker can measure. If you're on shared hosting, you're probably the most vulnerable you can get to this (but also the most screwed already, so you probably don't cate).

Post reply on HN