Announcement

Collapse
No announcement yet.

Google Engineers Argue For Linux "ASI" To Better Deal With Speculative Execution Attacks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lilunxm12
    replied
    Originally posted by hotaru View Post

    most of the things people would want to steal (credentials, encryption keys, etc.) are only a few bytes. restarting your browser more than once per second is probably not something that most people would want to do.
    those information are small but I believe to identify the exact alignment of your interest you need much more. It's binary data after all.

    Leave a comment:


  • hotaru
    replied
    Originally posted by carewolf View Post

    Before or after all the browsers added random noise to the JS accessible timers?
    https://alephsecurity.com/2018/06/26...r-query-cache/

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by carewolf View Post

    Before or after all the browsers added random noise to the JS accessible timers?
    Sorry but I do not remember the details.

    Leave a comment:


  • carewolf
    replied
    Originally posted by NobodyXu View Post

    I remembered reading that the researcher was able to pull off a timing based attack in javascript...
    Before or after all the browsers added random noise to the JS accessible timers?

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by lilunxm12 View Post

    Or browser vendors could develop a deep refresh feature, restart the page in a new process and close the old one. Then we could use those existing tab refresher extensions.
    Emmm, it's a bad idea to do this without user consent, because this would basically reset any state of the page rendered.
    If you are doing banking or performing some critical operations that uses Javascript, then refreshing would cause all these pages to be invalidated and potentially requires you to start from scratch to refill information.

    Providing an API so that some plugins to do it might be OK, but still the performance of this is going to be terrible.

    Leave a comment:


  • hotaru
    replied
    Originally posted by lilunxm12 View Post
    Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
    If that's the case maybe periodically restart browser is all we need as desktop users running random js?
    most of the things people would want to steal (credentials, encryption keys, etc.) are only a few bytes. restarting your browser more than once per second is probably not something that most people would want to do.

    Leave a comment:


  • lilunxm12
    replied
    Originally posted by NobodyXu View Post

    Even temporarily closing the tabs of untrusted websites might work.
    But seriously though, I don't think a lot of people can do that.
    Or browser vendors could develop a deep refresh feature, restart the page in a new process and close the old one. Then we could use those existing tab refresher extensions.

    Leave a comment:


  • NobodyXu
    replied
    Originally posted by lilunxm12 View Post
    Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
    If that's the case maybe periodically restart browser is all we need as desktop users running random js?
    Even temporarily closing the tabs of untrusted websites might work.
    But seriously though, I don't think a lot of people can do that.

    Leave a comment:


  • lilunxm12
    replied
    Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
    If that's the case maybe periodically restart browser is all we need as desktop users running random js?

    Leave a comment:


  • marlock
    replied
    browsers had to impair js timers on purpose as a temporary measure to avoid js exploitation of spectre when it first came up... back then they intended to give js back the ability to use more precise timers, but since the vulnerabilities didn't stop popping up those degraded timers might still be in place...

    ...and then there is dev ingenuity, crafting ways to increase timer precision by joining several methods creatively, etc... so that was explicitly only a stopgap measure to buy OSs time to devise more proper mitigations

    Leave a comment:

Working...
X