5 ms·

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

by totony 12y ago

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-secure tasks to do, you might want to do something like calculating the execution time of the function and sleep()'ing to add padding. Example code (doesn't work): function login(){ execstart = utime() // whatever code execduration = utime() - execstart; sleep( execduration % 100 ); // pad on at 100 boundary } You'd have to carefully choose your padding so the execution time is (normally) not revealed in the code.

totony 12y ago
I don't know how to do [code] tags
- hnmcs 12y ago
  At this time, these few options are available: https://news.ycombinator.com/formatdoc 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.)
  - totony 12y ago
    Thank you!
  - AgentConundrum 12y ago
    I've been on this site for something like five years, but... I never knew that this functionality existed
mifreewil 12y ago
I'm not quite sure I understand what you are saying here. I don't think anyone is saying that you need to understand all the underlying code, but this is just something you should be aware of as you are building network-connected applications. Just like a web developer needs to be aware of CSRF, XSS, etc. Every language that I know of short-circuits string comparisons like this. You should know that you need to seek out a constant-time compare though when comparing hashes or other secrets. Your sleep hack is probably less secure. I remember reading somewhere that doing random sleep() calls is flawed and doesn't completely mitigate the attack, but does increase the number of requests needed to get a good statistical analysis.
ircmaxell 12y ago
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 hiding anything. 2. The resolution of the sleep call is WAY too high. We're talking about detecting differences down to 15 nanoseconds. Sleeping for blocks of microseconds or even milliseconds will be far to granular. It will introduce block-like patterns in the requests that should be pretty easy to detect with statistical means. 3. It's basically identical to a random delay. 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)). And over time (many requests), that will average out. Now, what if we took a different approach. What if we made the operation fixed-time? execstart = utime() // whatever code // clamp to always take 500 microseconds sleep( 500 - utime() - execduration) That might work (assuming you have a high enough resolution sleep function). Again, it suffers the local attacker problem (which may or may not matter in your case). However, there are two reasons I wouldn't recommend it: It requires guesswork and idle CPU. You would either need to actively guess every single operation (and remember to clamp it) or clamp the overall application. If you do it for every operation, that sleep time can become expensive (if you have a lot of them). 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 too much, the attacker can leverage it to DOS your site (since even a sleeping process is non-trivially expensive). There are two valid ways of protection IMHO: 1. Make sensitive operations actually constant time. 2. Implement strong IP based protections to prevent the large amount of requests that would be needed to collect enough data to analyze noisy environments. (I need to add this to the post now that I write it). Personally, you should be doing #2 anyway. But since I also believe in defense-in-depth, I'd do #1 as well.
- totony 12y ago
  Thank you for answering, it is true that if someone has access to the server you might be in trouble, but if he has access to a cpu monitor, he might also have access to RAM and could just get the data from there. For the precision of sleep, http://php.net/manual/en/function.time-nanosleep.php http://php.net/manual/en/function.time-nanosleep.php might be more appropriate Also, you would only need to slightly clamp very important functions, so DoS attacks aren't that likely on it (and a constant timed function would also take the same time).
bmm6o 12y ago
Here's part of the response I wrote last time this came up (https://news.ycombinator.com/item?id=8602494 https://news.ycombinator.com/item?id=8602494): An approach where you watch the clock will be inherently less portable and actually much harder. Not only will the timing calls be hardware or OS specific, but so will the worst-case time. Imagine having to deal with a chip going into low power mode during your computation. Also you probably don't want to count time that your thread wasn't scheduled to run, so now you're talking about integrating with the scheduler.

by totony 12y ago

totony 12y ago

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

hnmcs 12y ago
At this time, these few options are available: https://news.ycombinator.com/formatdoc 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.)
- totony 12y ago
  Thank you!
- AgentConundrum 12y ago
  I've been on this site for something like five years, but... I never knew that this functionality existed

mifreewil 12y ago

I'm not quite sure I understand what you are saying here. I don't think anyone is saying that you need to understand all the underlying code, but this is just something you should be aware of as you are building network-connected applications. Just like a web developer needs to be aware of CSRF, XSS, etc. Every language that I know of short-circuits string comparisons like this. You should know that you need to seek out a constant-time compare though when comparing hashes or other secrets. Your sleep hack is probably less secure. I remember reading somewhere that doing random sleep() calls is flawed and doesn't completely mitigate the attack, but does increase the number of requests needed to get a good statistical analysis.

ircmaxell 12y ago

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 hiding anything. 2. The resolution of the sleep call is WAY too high. We're talking about detecting differences down to 15 nanoseconds. Sleeping for blocks of microseconds or even milliseconds will be far to granular. It will introduce block-like patterns in the requests that should be pretty easy to detect with statistical means. 3. It's basically identical to a random delay. 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)). And over time (many requests), that will average out. Now, what if we took a different approach. What if we made the operation fixed-time? execstart = utime() // whatever code // clamp to always take 500 microseconds sleep( 500 - utime() - execduration) That might work (assuming you have a high enough resolution sleep function). Again, it suffers the local attacker problem (which may or may not matter in your case). However, there are two reasons I wouldn't recommend it: It requires guesswork and idle CPU. You would either need to actively guess every single operation (and remember to clamp it) or clamp the overall application. If you do it for every operation, that sleep time can become expensive (if you have a lot of them). 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 too much, the attacker can leverage it to DOS your site (since even a sleeping process is non-trivially expensive). There are two valid ways of protection IMHO: 1. Make sensitive operations actually constant time. 2. Implement strong IP based protections to prevent the large amount of requests that would be needed to collect enough data to analyze noisy environments. (I need to add this to the post now that I write it). Personally, you should be doing #2 anyway. But since I also believe in defense-in-depth, I'd do #1 as well.

totony 12y ago
Thank you for answering, it is true that if someone has access to the server you might be in trouble, but if he has access to a cpu monitor, he might also have access to RAM and could just get the data from there. For the precision of sleep, http://php.net/manual/en/function.time-nanosleep.php http://php.net/manual/en/function.time-nanosleep.php might be more appropriate Also, you would only need to slightly clamp very important functions, so DoS attacks aren't that likely on it (and a constant timed function would also take the same time).

bmm6o 12y ago

Here's part of the response I wrote last time this came up (https://news.ycombinator.com/item?id=8602494 https://news.ycombinator.com/item?id=8602494): An approach where you watch the clock will be inherently less portable and actually much harder. Not only will the timing calls be hardware or OS specific, but so will the worst-case time. Imagine having to deal with a chip going into low power mode during your computation. Also you probably don't want to count time that your thread wasn't scheduled to run, so now you're talking about integrating with the scheduler.