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

31–40 of 52 posts

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

#31

Post by MarkMc »

ircmaxell wrote: post #26
totony wrote: post #6

Interesting article, I never took the time to really think about this. For optimal security, OP mentions that we should fix the underlying code, but I kind of disagree. Understanding all the underlying code is a lot of work and, except for extremely secure application, is not really needed. Also, hindering performance for security is not always the way to go (he mentions returning only at the end). If you have ultra-…

OP here. Seeing as this question is getting asked a lot , I'll edit something into the post, but I wanted to answer you here as well. So, there are a few problems with this technique. 1. It ignores the local timing leak An attacker who can get code running on the server (shared hosts for example), can carefully monitor the CPU usage to see when the process is actually doing work, vs when it sleeps. So really, its not…

I'm not an expert on timing attacks, but without clamping it seems quite tricky to guarantee that sensitive operations actually take constant time. There can be numerous subtle ways that timing information leaks while the code appears to be constant time. And programmers who touch sensitive code can easily forget the requirement for constant-time behaviour. Yes, having constant time operation without clamping is the best solution but it seems too easy to accidentally slip from this ideal.

I'm leaning toward the approach of having a simple clamping library at the application level that (a) throws an exception if the sensitive code takes longer than the 'clamp time'; and (b) has some simple heuristic to determine the clamp time, such as "double the maximum execution time recorded during the first 20 runs". It might have a drawback if the CPU is not idle, but the benefit is that it is dead simple to implement. (Assuming the platform supports nanosecond wait times)

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

#32

Post by Xylakant »

contingencies wrote: post #30

I suppose preg_match() , previously popularly opposed on performance grounds, it now arguably better than a straight string comparison in security terms due to probable timing attack resistance. :)

Regular expressions will exhibit the same behavior. They will also short circuit if no match is possible/ In essence the behavior that causes the problem is a desirable performance optimization for the general case that you just need to prevent here.

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

#33

Post by invisible »

sarciszewski wrote: post #28
invisible wrote: post #24

I think the title on HN is a bit misleading. This issue applies to ALL languages and PHP has specific functions (since version 5.6) to avoid timing issues for you: hash_equals and password_verify. PHP is specifically trying to address poor authentication mechanisms by adding the (ingenious) password module to PHP's core.

I don't really find it misleading. It's about all sorts of remote timing attacks (including cache-timing attacks), not just passwords. I'm the author of the pull request that prompted the discussion, though, so I'm probably biased. :)

It's misleading because it implies this is a unique problem scoped in PHP. That is factually incorrect and hence misleading any reader to assume this article is about PHP's poor security against timing attacks.

It'd simply be nice if the scope of the discussion was about how all languages have more or less the same flaws. Anyone writing code with security in mind should understand how to avoid those flaws.

There are many ways to alleviate the problem specified in the pull request that may be better. Pecl is one route that was mentioned on internals. Also, possibly just cache the hex value in memory and avoid the bin2hex conversion outright (with randomization of your cold cache times).

Edit: As an aside, I want to also greatly express that the requirement to attack the bin2hex vulnerability is so high for most cases the attacker would require complete, private, 1-hop, uninterrupted access to a single target machine. Usually this implies the attack not being remote but I do understand the mental exercise.

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

#34

Post by sarciszewski »

invisible wrote: post #33
sarciszewski wrote: post #28

Earlier quoted context omitted.

I don't really find it misleading. It's about all sorts of remote timing attacks (including cache-timing attacks), not just passwords. I'm the author of the pull request that prompted the discussion, though, so I'm probably biased. :)

It's misleading because it implies this is a unique problem scoped in PHP. That is factually incorrect and hence misleading any reader to assume this article is about PHP's poor security against timing attacks. It'd simply be nice if the scope of the discussion was about how all languages have more or less the same flaws. Anyone writing code with security in mind should understand how to avoid those flaws. There are…

The second you say "install this PECL extension" people hop on the fast train to nopesville. That is the problem I ran into getting people to adopt libsodium :\

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

#35

Post by contingencies »

Xylakant wrote: post #32
contingencies wrote: post #30

I suppose preg_match() , previously popularly opposed on performance grounds, it now arguably better than a straight string comparison in security terms due to probable timing attack resistance. :)

Regular expressions will exhibit the same behavior. They will also short circuit if no match is possible/ In essence the behavior that causes the problem is a desirable performance optimization for the general case that you just need to prevent here.

I seriously doubt regex with grouping, greediness and repetition exhibit the temporal properties of purely linear character-by-character matches...

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

#36

Post by rbsn »

ircmaxell wrote: post #26
totony wrote: post #6

Interesting article, I never took the time to really think about this. For optimal security, OP mentions that we should fix the underlying code, but I kind of disagree. Understanding all the underlying code is a lot of work and, except for extremely secure application, is not really needed. Also, hindering performance for security is not always the way to go (he mentions returning only at the end). If you have ultra-…

OP here. Seeing as this question is getting asked a lot , I'll edit something into the post, but I wanted to answer you here as well. So, there are a few problems with this technique. 1. It ignores the local timing leak An attacker who can get code running on the server (shared hosts for example), can carefully monitor the CPU usage to see when the process is actually doing work, vs when it sleeps. So really, its not…

How can you actually make sensitive operations take constant time? This sounds impossibly hard. For example, your operating system could be context switching thousands of times per second. Your password comparison function could cause a page fault because the trailing end of the password spans onto another page of virtual memory. These are all factors that would throw any calculation for constant time out of the window.

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

#37

Post by coldtea »

contingencies wrote: post #35
Xylakant wrote: post #32

Earlier quoted context omitted.

Regular expressions will exhibit the same behavior. They will also short circuit if no match is possible/ In essence the behavior that causes the problem is a desirable performance optimization for the general case that you just need to prevent here.

I seriously doubt regex with grouping, greediness and repetition exhibit the temporal properties of purely linear character-by-character matches...

Doesn't have to exhibit "the temporal properties of purely linear character-by-character matches" and noone said that strawman.

It just has to exhibit the "correct matching strings return faster" property, whatever more complicated search it does.

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

#38

Post by homakov »

Timing attacks are not working in reality because of many things. You know how many times hackers actually used it? I bet 0. Just little bit faster than bruteforce.

But that's how you can make them faster http://homakov.blogspot.com/2014/07/timing-attack-666-faster...

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

#39

Post by homakov »

homakov wrote: post #38

Timing attacks are not working in reality because of many things. You know how many times hackers actually used it? I bet 0. Just little bit faster than bruteforce. But that's how you can make them faster http://homakov.blogspot.com/2014/07/timing-attack-666-faster...

And if you have a PHP app, timing attack is the very last thing to worry about... go prevent XSS first :) Re http://klikki.fi/adv/wordpress.html#details

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

#40

Post by contingencies »

coldtea wrote: post #37
contingencies wrote: post #35

Earlier quoted context omitted.

I seriously doubt regex with grouping, greediness and repetition exhibit the temporal properties of purely linear character-by-character matches...

Doesn't have to exhibit "the temporal properties of purely linear character-by-character matches" and noone said that strawman. It just has to exhibit the "correct matching strings return faster" property, whatever more complicated search it does.

Doesn't it have to exhibit "correctly matching strings return faster ... on a per-character or other tiny chunk basis" in order to work the match towards correctness?
Post reply on HN