←back to thread

setBigTimeout

(evanhahn.com)
210 points cfj | 2 comments | 17 Oct 24 18:01 UTC | HN request time: 0.74s | source
Show context
n2d4 ◴[18 Oct 24 16:24 UTC] No.41880898[source]▶
The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected:

    const attackerControlled = ...;
    if (attackerControlled < 60_000) {
      throw new Error("Must wait at least 1min!");
    }

    setTimeout(() => {
      console.log("Surely at least 1min has passed!");
    }, attackerControlled);
The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better solution (imo) would be to throw an error, but I assume we can't due to backwards compatibility.
replies(6): >>41881042 #>>41881074 #>>41881774 #>>41882110 #>>41884470 #>>41884957 #
arghwhat ◴[18 Oct 24 16:37 UTC] No.41881042[source]▶
A scenario where an attacker can control a timeout where having the callback run sooner than one minute later would lead to security failures, but having it set to run days later is perfectly fine and so no upper bound check is required seems… quite a constructed edge case.

The problem here is having an attacker control a security sensitive timer in the first place.

replies(2): >>41881665 #>>41888952 #
1. chacham15 ◴[19 Oct 24 16:57 UTC] No.41888952[source]▶
I would imagine the intent behind this would be that the attacker has indirect control over the timeout. E.g. a check password input which delays you in between attempts doubling the length of time you have to wait in between each failed attempt. With this bug in place, the attacker would simply wait all the timeouts until the timeout exceeded 25 days at which point they could brute force the password check back to back.
replies(1): >>41890611 #
2. arghwhat ◴[19 Oct 24 20:38 UTC] No.41890611[source]▶
A login back off should be capped to a number of hours rather than be allowed to grow to a month though. I also have a hard time seeing this implemented as setTimeouts for every failed login attempt instead of storing a last login attempt time and counter in a user database with a time comparison when login is called.

It’s definitely suboptimal though, even if it is documented.