(I need to add this to the post now that I write it). Implement strong IP based protections to prevent the large amount of requests that would be needed to collect enough data to analyze noisy environments. Make sensitive operations actually constant time.Ģ. There are two valid ways of protection IMHO:ġ. If you do too much, the attacker can leverage it to DOS your site (since even a sleeping process is non-trivially expensive). If you do it on the application level, and if you do too little, an attacker can use other expensive control (like larger input introducing memory allocation latency) to increase the runtime past the sleep clamp (hence allowing them to attack the vulnerability anyway). If you do it for every operation, that sleep time can become expensive (if you have a lot of them). You would either need to actively guess every single operation (and remember to clamp it) or clamp the overall application. However, there are two reasons I wouldn't recommend it: It requires guesswork and idle CPU. Again, it suffers the local attacker problem (which may or may not matter in your case). That might work (assuming you have a high enough resolution sleep function). What if we made the operation fixed-time? Now, what if we took a different approach. And over time (many requests), that will average out. Considering it depends on the system clock, and the original request comes in at a random point, it's functionally identical to calling sleep(random(1, 100)). It's basically identical to a random delay. It will introduce block-like patterns in the requests that should be pretty easy to detect with statistical means.ģ. Sleeping for blocks of microseconds or even milliseconds will be far to granular. We're talking about detecting differences down to 15 nanoseconds. The resolution of the sleep call is WAY too high.
#Check for valid utime php code
So, there are a few problems with this technique.Īn 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. 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. Usually this implies the attack not being remote but I do understand the mental exercise. Also, possibly just cache the hex value in memory and avoid the bin2hex conversion outright (with randomization of your cold cache times).Įdit: 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. Pecl is one route that was mentioned on internals. There are many ways to alleviate the problem specified in the pull request that may be better.
#Check for valid utime php how to
Anyone writing code with security in mind should understand how to avoid those flaws. It'd simply be nice if the scope of the discussion was about how all languages have more or less the same flaws. That is factually incorrect and hence misleading any reader to assume this article is about PHP's poor security against timing attacks. It's misleading because it implies this is a unique problem scoped in PHP.
0 kommentar(er)
