[HN Gopher] Listen to the whispers: web timing attacks that work
       ___________________________________________________________________
        
       Listen to the whispers: web timing attacks that work
        
       Author : saikatsg
       Score  : 91 points
       Date   : 2024-11-21 18:08 UTC (4 hours ago)
        
 (HTM) web link (portswigger.net)
 (TXT) w3m dump (portswigger.net)
        
       | ssklash wrote:
       | I look forward to James Kettle's yearly research results, he's
       | the most incredible appsec researcher I know of.
        
         | markandrewj wrote:
         | I have never met James, but I agree his research is great. I
         | always enjoy reading or watching his content.
        
       | miki123211 wrote:
       | Timing attacks are such a pernicious idea.
       | 
       | You look at the code and see that there's an auth check in place,
       | you test the code to verify that the auth check has no bugs, you
       | make sure that information is never shared with people who don't
       | have authorization to access it, and yet it turns out it can be
       | accessed as if there was no auth check at all.
       | 
       | To make matters worse, everything can be fine for some time, and
       | then some clever optimization in the CPU, the compiler, cache
       | layer or the database engine introduces a completely unexpected
       | side channel.
        
         | GoToRO wrote:
         | would adding random delays prevent this?
        
           | tptacek wrote:
           | It depends on the kinds of attacks you're thinking of. For
           | the stuff Kettle is doing, probably yes. For cryptographic
           | side channels, probably no.
        
           | wiredfool wrote:
           | One thing that I've done where I previously had a random
           | delay is implement a delay till a constant time from the
           | start of the request. So all of the timing you get out is
           | effectively how well sleep can target a time.
        
           | jack_pp wrote:
           | or you could benchmark the functions that compare secrets to
           | user input and figure out how much time it's supposed to
           | take, add 0.5s to the average and always add time before
           | responding to get to that target so essentially your response
           | time is constant regardless of input
        
             | tptacek wrote:
             | Important to keep in mind here that the timing attacks
             | Kettle is talking about generally _do not_ take the form of
             | "providing secret input to a function with variable
             | timing".
        
           | Filligree wrote:
           | Random delays specifically do not, as they average out.
           | Delays until a specific point in time do work, so long as the
           | delay is never negative.
        
           | pwagland wrote:
           | No, it only makes it take longer to get the underlying
           | secret.
           | 
           | Timing attacks are already dealing with "noisy" data, task
           | scheduling et al, so they all boil down to some level of
           | statistical analysis on the response times. Adding noise to
           | that slows you down, but the underlying bias on the timings
           | is still there.
        
       | tptacek wrote:
       | A fun thing about this work is that it's following different
       | threads than the remote timing attack research in cryptography
       | follows; high-end remote timing in cryptography involves some
       | signal processing work, which isn't really present here. Which
       | means Kettle's attacks are likely to get more powerful.
        
       ___________________________________________________________________
       (page generated 2024-11-21 23:00 UTC)