5 ms·

You run untrusted code every day you browse the web.

deleted 6y ago
[deleted]
asveikau 6y ago
One of the recent times where I pointed this out somebody retorted that the browsers got rid of js access to high resolution timers, making a timing attack infeasible. Is this true?
- georgyo 6y ago
  Not true, at most it increases the number of samples required. But the are other ways to simulate timers with adequate resolution.
  - saagarjha 6y ago
    (Such as a loop.)
    - namibj 6y ago
      Not without shared memory.
      - saagarjha 6y ago
        There are apparently ways to get around even this requirement.
        namibj 6y ago
        Are you able to substantiate that with a link or an explanation?
        saagarjha 6y ago
        I just realized that my comment made it appear as if you can get a high-resolution timer without SharedArrayBuffer; I don't know of anyone who has done that yet. But people have made exploits that don't rely on it: https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c...
  - namibj 6y ago
    There is a point where you re-key faster than your key leaks through that specific timing attack. Or re-randomize memory layout, etc. Or where the payoff (due to limits/quotas) implies a cap on the effort that's still worth it. It's like Backups: you do as much as you want to pay for, considering the amount of risk you'll be left with.
  - mahkoh 6y ago
    Please post an example showing that this works. I'll run the example with OS-mitigations disabled to confirm.
    - dijit 6y ago
      This is a browser checker that does not use the high precision timers: https://jsfiddle.net/lukelol/43015xpv/1/ https://jsfiddle.net/lukelol/43015xpv/1/
      - mahkoh 6y ago
        It shows "Browser not exploitable." even after rebooting with mitigations=off.
        dijit 6y ago
        Congratulations! Now pray that there is not another exploit that can be used. :) Like many things; security is an onion, there are layers to it and removing some of those layers can be fine because the outer layers may protect you, but ultimately you just increase risk.
        mahkoh 6y ago
        Why did you even post if you were going to resort to "but can you prove that there isn't an exploit?" anyway? I could have saved myself two reboots if you had started with that.
        dijit 6y ago
        I assume good faith, you asked for an exploit that works without precision timers to test, I provided one. Don’t get mad about the fact it didn’t work, I’m glad it didn’t work, but you can’t walk away with the knowledge that something like that will _never_ work. I’m not sure what you were trying to prove, but you can’t tell people to prove you wrong without any knowledge of what browser you’re running with, or what version or what you’re expecting to see. A “fully working” exploit for the most modern browser is probably possible frankly, but it’s not something that anyone is looking at with seriousness because everyone has mitigation’s enabled anyway. It’s the very definition of high work low reward.
jillesvangurp 6y ago
And the reason it's mostly not an issue for companies and people to stay safe is that we have many layers of protection around that. Being able to run untrusted code is required in a world where the combined code you run on a daily basis containes millions/billions of lines of code coming from a wide variety of sources. IMHO in the cloud a sane mechanism to protect users would be to guarantee exclusive access to CPUs. The primary risk in the cloud is sharing CPUs with other cloud users. Cache flushing sounds like a sane thing to do in non performance critical applications where CPU sharing happens. There's a performance penalty but if you'd care about that you'd be using a different instance type anyway where you are guaranteed to have dedicated CPUs. For bare metal/desktop use, flushing caches makes less sense.
clarry 6y ago
And I think that is madness. The web should have never gone down that route. People should push back.
- asah 6y ago
  So all webpages should be simple forms, not even validation? I remember those days, and actually shipped "dynamic" webpages before JavaScript/AJAX/DOM. I'll take cache flushing. Imagine if every like/upvote button required a screen refresh... imagine Google maps...
  - clarry 6y ago
    You are indeed very good at imagining a world where the only choices are the web exactly as it was in the 90s, and exactly as it is today. That's a rare display of creative ability, but also a false dichotomy.
    - mcherm 6y ago
      Illuminate it for us, then. What is the middle ground that permits SOME computation in the client, yet is so restricted that it cannot take advantage of timing or cache attacks to steal information from other processes running on the same machine. The difficulty with both timing and cache attacks is that a "sandbox" approach is not possible... at least not without special hardware and OS level support like the ability to tell the OS to flush caches on context switches for certain processes.
      - clarry 6y ago
        > What is the middle ground that permits SOME computation in the client You already went down the wrong road there. Can you imagine how to add functionality declaratively? The middle ground is extending user agents to support features that improve the browsing experience and enable new functionality, without turning it into an arbitrary application delivery framework. And yes, this means rejecting and scoping out some things that people do in browsers today. Just like in the past, you as a developer would get to choose whether to write a website (ubiquitous, accessible, runs on grandma's old potato, relatively easy and cheap to maintain; these are the things that made the web popular and businesses around the world decided that it's ok to to make their product a website even if that meant they couldn't have all the features you could with a desktop application), a native application (more effort, more complex, more expensive, more invasive, more friction, more concerning w.r.t. security), or both. To illuminate you, let's pick some examples from the false-dichotomy post... Consider form validation. In fact, this is already done (and could always be extended to support more cases). HTML5 has built-in form validation that works without javascript. And of course it's still perfectly backwards compatible with old browsers that don't do validation; they might send you invalid fields, but you will have to validate them server side anyway because you can't trust the client. https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va... Static maps have already been done. Not a super smooth experience, but you could always improve that by speccing a zoomable & pannable tiled image element that'll send requests to the specified URL when you pan outside of the loaded area or zoom in. Add a set of loadable elements that are embedded into this image element and you get something that starts to resemble SVG. No JS required. Information about points of interest could already be shown with the hover selector, but there's no reason we couldn't spec an element whose visibility can be toggled with a click, no js needed. Upvote/downvote buttons just need an attribute that tells the browser to post the request but stay on the current page. (This also degrades trivially with browsers that don't support the attribute) You could even toggle the visibility of the arrows after posting; similar CSS selectors for checked inputs already exist. In general, there's no reason we can't have post or get requests that display the response in a new element without reloading the entire page. Semantically, not very different from target="_blank" or whatever you use to load something in a new tab / windows, except this time you want the target to be an element. (At this point I'd also like to note that frames exist and yes they suck but hilariously a lot of the new web does exactly the kind of stateful non-linkable things that framesets were derided for; only worse, because you actually could right-click a frame and link directly to it, but you can't right-click and link the arbitrary DOM that was cooked by your client-side javascript) Going with the tiled image element theme, there's no reason we can't have more elements that instruct the browser how to load more data on demand. These same elements could let the user agent decide whether to paginate or scroll infinitely, or how many items to display per page. (There's no reason we can't load images progressively and on demand.. progressive JPEG exists already, but for some reason devs still insist on giving me a blur and nothing more will load unless I enable scripts) The way we currently do things really sucks for the user (because they have very little control over how the script behaves; the user agent is degraded to a mere dumb client with little meaningful configurability) and it sucks for developers who would rather just focus on the content and let the browser provide whatever UX fits the user & their platform best. Web devs are in a hurry to paper over the deficiencies of browsers but in doing so (and not fixing browsers), we end up with something worse and every goddamn website becomes a complex application. We're stuck in a worst-of-both-worlds state, where the browser runs applications that lack the power of desktop applications, yet are invasive, heavyweight -- don't run on grandmas old potato, complex & expensive to develop and maintain (every website shipping complex UI logic that should be part of the browser instead), increasingly less accessible and less reliable, less linkable & crawlable, less secure.. it's all I never wanted.

deleted 6y ago

[deleted]

One of the recent times where I pointed this out somebody retorted that the browsers got rid of js access to high resolution timers, making a timing attack infeasible. Is this true?

georgyo 6y ago
Not true, at most it increases the number of samples required. But the are other ways to simulate timers with adequate resolution.
- saagarjha 6y ago
  (Such as a loop.)
  - namibj 6y ago
    Not without shared memory.
    - saagarjha 6y ago
      There are apparently ways to get around even this requirement.
      - namibj 6y ago
        Are you able to substantiate that with a link or an explanation?
        saagarjha 6y ago
        I just realized that my comment made it appear as if you can get a high-resolution timer without SharedArrayBuffer; I don't know of anyone who has done that yet. But people have made exploits that don't rely on it: https://alephsecurity.com/2018/06/26/spectre-browser-query-cache/ https://alephsecurity.com/2018/06/26/spectre-browser-query-c...
- namibj 6y ago
  There is a point where you re-key faster than your key leaks through that specific timing attack. Or re-randomize memory layout, etc. Or where the payoff (due to limits/quotas) implies a cap on the effort that's still worth it. It's like Backups: you do as much as you want to pay for, considering the amount of risk you'll be left with.
- mahkoh 6y ago
  Please post an example showing that this works. I'll run the example with OS-mitigations disabled to confirm.
  - dijit 6y ago
    This is a browser checker that does not use the high precision timers: https://jsfiddle.net/lukelol/43015xpv/1/ https://jsfiddle.net/lukelol/43015xpv/1/
    - mahkoh 6y ago
      It shows "Browser not exploitable." even after rebooting with mitigations=off.
      - dijit 6y ago
        Congratulations! Now pray that there is not another exploit that can be used. :) Like many things; security is an onion, there are layers to it and removing some of those layers can be fine because the outer layers may protect you, but ultimately you just increase risk.
        mahkoh 6y ago
        Why did you even post if you were going to resort to "but can you prove that there isn't an exploit?" anyway? I could have saved myself two reboots if you had started with that.
        dijit 6y ago
        I assume good faith, you asked for an exploit that works without precision timers to test, I provided one. Don’t get mad about the fact it didn’t work, I’m glad it didn’t work, but you can’t walk away with the knowledge that something like that will _never_ work. I’m not sure what you were trying to prove, but you can’t tell people to prove you wrong without any knowledge of what browser you’re running with, or what version or what you’re expecting to see. A “fully working” exploit for the most modern browser is probably possible frankly, but it’s not something that anyone is looking at with seriousness because everyone has mitigation’s enabled anyway. It’s the very definition of high work low reward.

jillesvangurp 6y ago

And the reason it's mostly not an issue for companies and people to stay safe is that we have many layers of protection around that. Being able to run untrusted code is required in a world where the combined code you run on a daily basis containes millions/billions of lines of code coming from a wide variety of sources. IMHO in the cloud a sane mechanism to protect users would be to guarantee exclusive access to CPUs. The primary risk in the cloud is sharing CPUs with other cloud users. Cache flushing sounds like a sane thing to do in non performance critical applications where CPU sharing happens. There's a performance penalty but if you'd care about that you'd be using a different instance type anyway where you are guaranteed to have dedicated CPUs. For bare metal/desktop use, flushing caches makes less sense.

clarry 6y ago

And I think that is madness. The web should have never gone down that route. People should push back.

asah 6y ago
So all webpages should be simple forms, not even validation? I remember those days, and actually shipped "dynamic" webpages before JavaScript/AJAX/DOM. I'll take cache flushing. Imagine if every like/upvote button required a screen refresh... imagine Google maps...
- clarry 6y ago
  You are indeed very good at imagining a world where the only choices are the web exactly as it was in the 90s, and exactly as it is today. That's a rare display of creative ability, but also a false dichotomy.
  - mcherm 6y ago
    Illuminate it for us, then. What is the middle ground that permits SOME computation in the client, yet is so restricted that it cannot take advantage of timing or cache attacks to steal information from other processes running on the same machine. The difficulty with both timing and cache attacks is that a "sandbox" approach is not possible... at least not without special hardware and OS level support like the ability to tell the OS to flush caches on context switches for certain processes.
    - clarry 6y ago
      > What is the middle ground that permits SOME computation in the client You already went down the wrong road there. Can you imagine how to add functionality declaratively? The middle ground is extending user agents to support features that improve the browsing experience and enable new functionality, without turning it into an arbitrary application delivery framework. And yes, this means rejecting and scoping out some things that people do in browsers today. Just like in the past, you as a developer would get to choose whether to write a website (ubiquitous, accessible, runs on grandma's old potato, relatively easy and cheap to maintain; these are the things that made the web popular and businesses around the world decided that it's ok to to make their product a website even if that meant they couldn't have all the features you could with a desktop application), a native application (more effort, more complex, more expensive, more invasive, more friction, more concerning w.r.t. security), or both. To illuminate you, let's pick some examples from the false-dichotomy post... Consider form validation. In fact, this is already done (and could always be extended to support more cases). HTML5 has built-in form validation that works without javascript. And of course it's still perfectly backwards compatible with old browsers that don't do validation; they might send you invalid fields, but you will have to validate them server side anyway because you can't trust the client. https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_va... Static maps have already been done. Not a super smooth experience, but you could always improve that by speccing a zoomable & pannable tiled image element that'll send requests to the specified URL when you pan outside of the loaded area or zoom in. Add a set of loadable elements that are embedded into this image element and you get something that starts to resemble SVG. No JS required. Information about points of interest could already be shown with the hover selector, but there's no reason we couldn't spec an element whose visibility can be toggled with a click, no js needed. Upvote/downvote buttons just need an attribute that tells the browser to post the request but stay on the current page. (This also degrades trivially with browsers that don't support the attribute) You could even toggle the visibility of the arrows after posting; similar CSS selectors for checked inputs already exist. In general, there's no reason we can't have post or get requests that display the response in a new element without reloading the entire page. Semantically, not very different from target="_blank" or whatever you use to load something in a new tab / windows, except this time you want the target to be an element. (At this point I'd also like to note that frames exist and yes they suck but hilariously a lot of the new web does exactly the kind of stateful non-linkable things that framesets were derided for; only worse, because you actually could right-click a frame and link directly to it, but you can't right-click and link the arbitrary DOM that was cooked by your client-side javascript) Going with the tiled image element theme, there's no reason we can't have more elements that instruct the browser how to load more data on demand. These same elements could let the user agent decide whether to paginate or scroll infinitely, or how many items to display per page. (There's no reason we can't load images progressively and on demand.. progressive JPEG exists already, but for some reason devs still insist on giving me a blur and nothing more will load unless I enable scripts) The way we currently do things really sucks for the user (because they have very little control over how the script behaves; the user agent is degraded to a mere dumb client with little meaningful configurability) and it sucks for developers who would rather just focus on the content and let the browser provide whatever UX fits the user & their platform best. Web devs are in a hurry to paper over the deficiencies of browsers but in doing so (and not fixing browsers), we end up with something worse and every goddamn website becomes a complex application. We're stuck in a worst-of-both-worlds state, where the browser runs applications that lack the power of desktop applications, yet are invasive, heavyweight -- don't run on grandmas old potato, complex & expensive to develop and maintain (every website shipping complex UI logic that should be part of the browser instead), increasingly less accessible and less reliable, less linkable & crawlable, less secure.. it's all I never wanted.