5 ms·

You're (and most likely all downvoters) completely missing the point. I never said that opensource software is not affected, I said "not being affected as a us

You're (and most likely all downvoters) completely missing the point. I never said that opensource software is not affected, I said "not being affected as a user". Because opensource software, being peer-reviewed, will never try to exploit a CPU bug. Opensource software is, by default, non-malicious.

Dylan16807 9y ago
> Opensource software is, by default, non-malicious. So is closed source software. You seem to be deeply confused about the scenarios people are worried about. The main ones are 1. untrusted users being hosted 2. javascript off the web. All the open source in the world doesn't help in either scenario. You're focused on someone deliberately running a malicious program. But if they do that, these exploits aren't even necessary to do severe harm. It's a marginal scenario at best.
- siwatanejo 9y ago
  > > Opensource software is, by default, non-malicious. > So is closed source software. Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected. > The main ones are 1. untrusted users being hosted 2. javascript off the web. I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user. WRT 2: that's precisely why I mentioned NoScript. Nowadays the only untrusted software that could be run in your computer if you were using opensource OS and opensource apps exclusively is javascript from the web (which is by default closed source).
  - zingmars 9y ago
    Your stats need a citation, otherwise they mean nothing. CVE lists have plenty of entries for FOSS software, so it's definitely not '99.whatever' you're claiming.
    - siwatanejo 9y ago
      Are you fucking serious? CVEs are for security vulnerabilities, not for malware. It's you who has to demonstrate to me that it isn't the case. Just find more than 3 cases in history of opensource malware, and you refute my theory.
  - Dylan16807 9y ago
    > Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected. There is plenty of open-source malware, and most closed source software is not malware. You seem to be conflating "is in a trusted open source distribution, listed as non-malware" with mere "open source". Code that is openly malicious, or has never been peer-reviewed, is still perfectly capable of being open source. > I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user. That's cool but the workstation use case is not why people are freaking out. The workstation is the place where you don't even need this bug to take over and ruin everything, because it's all under one account anyway. Saying it's a "way to not be affected by these bugs" is pretty myopic.
zingmars 9y ago
Being open source and peer-reviewed doesn't mean software won't have bugs, exploits, or that backdoors can't be hidden in it. 'Peer-reviewed' sounds good on paper, but people can still miss things, be lazy, or not understand the code they are reviewing (but it works, so accept merge!). It's hardly the silver bullet to this problem. As for your original post - moving to FOSS only is not viable for a lot of people. Linux has no good video-editing software, no good CAD tools, gimp has nothing on photoshop and even Libreoffice is rather lackluster when compared to the MS Office package. On top of that, javascript is used pretty much in every site these days, many of which require javascript to run. You can't seriously expect an average user to manually whitelist javascript in the sites they browse. If the FOSS world had software that worked for everyone, people would use it. Right now, the only major group this is true for however, are developers. Until this changes there will be no 'year of the Linux Desktop' or whatever.
- siwatanejo 9y ago
  > moving to FOSS only is not viable for a lot of people I never advocated for people moving to FOSS. I just said it's a way to not be affected by these bugs, end of story. If the disadvantages of people moving to FOSS don't outweight the benefits, fine for them. > You can't seriously expect an average user to manually whitelist javascript in the sites they browse. Fair enough, that's why I only added "NoScript add-on" as an after thought. > Until this changes there will be no 'year of the Linux Desktop' Good to know your PoV on this.
anon1385 9y ago
So what you are saying is that if you never install closed source software, you will never (intentionally) install malware because you define all malware as closed source. This is a meaningless tautology. The advice you are giving is both objectively wrong and actively dangerous. Firstly not all security issues involve installing 'malware'. Take heartbleed; a major security vulnerability in open source software. To be hit by that you didn't need to install any non-open source software. You could have had the most pure and open stack of software and hardware ever created and it would have made no difference because the flaw was an information leak that didn't involve installing software or even unintended remote execution of code. That bug was due to the existing already installed open source code copying past the end of a buffer. Similar information leaking bugs could feasibly exist due to CPU bugs or compiler bugs or undefined behaviour in the code etc (i.e. all sorts of ways that don't involve installing malware and aren't even obvious from reading the code). Secondly, even exploits that do involve "running malware" are very often not because the user intentionally installed malware. They happen because the user did something like download and decode an image file which took advantage of a vulnerability in their (open source!) image decoding library to execute code on their machine. Again in this scenario it doesn't matter that the user would only ever intentionally install open source software, because the malware was executed unintentionally when they performed an activity they didn't expect to lead to code execution (viewing an image). E: These CPU issues are fundamentally timing attacks that leak information. I don't need to execute code on your computer at all to run a timing attack against you that leaks valuable information - I can do it by sending packets of pure data and don't need to be able to execute arbitrary code on your machine at all. Side channels like timing attacks don't necessarily require any kind of code execution on the target machine (although obviously having a high precision local timer makes it easier). This isn't just theoretical, it has been demonstrated in reality. For example see this paper[1] which demonstrates doing timing attacks against a browser to reveal the users browser history without the need to execute javascript at all. It's all done by sending CSS, which isn't code. [1] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07...

Dylan16807 9y ago

> Opensource software is, by default, non-malicious. So is closed source software. You seem to be deeply confused about the scenarios people are worried about. The main ones are 1. untrusted users being hosted 2. javascript off the web. All the open source in the world doesn't help in either scenario. You're focused on someone deliberately running a malicious program. But if they do that, these exploits aren't even necessary to do severe harm. It's a marginal scenario at best.

siwatanejo 9y ago
> > Opensource software is, by default, non-malicious. > So is closed source software. Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected. > The main ones are 1. untrusted users being hosted 2. javascript off the web. I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user. WRT 2: that's precisely why I mentioned NoScript. Nowadays the only untrusted software that could be run in your computer if you were using opensource OS and opensource apps exclusively is javascript from the web (which is by default closed source).
- zingmars 9y ago
  Your stats need a citation, otherwise they mean nothing. CVE lists have plenty of entries for FOSS software, so it's definitely not '99.whatever' you're claiming.
  - siwatanejo 9y ago
    Are you fucking serious? CVEs are for security vulnerabilities, not for malware. It's you who has to demonstrate to me that it isn't the case. Just find more than 3 cases in history of opensource malware, and you refute my theory.
- Dylan16807 9y ago
  > Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected. There is plenty of open-source malware, and most closed source software is not malware. You seem to be conflating "is in a trusted open source distribution, listed as non-malware" with mere "open source". Code that is openly malicious, or has never been peer-reviewed, is still perfectly capable of being open source. > I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user. That's cool but the workstation use case is not why people are freaking out. The workstation is the place where you don't even need this bug to take over and ruin everything, because it's all under one account anyway. Saying it's a "way to not be affected by these bugs" is pretty myopic.

zingmars 9y ago

Being open source and peer-reviewed doesn't mean software won't have bugs, exploits, or that backdoors can't be hidden in it. 'Peer-reviewed' sounds good on paper, but people can still miss things, be lazy, or not understand the code they are reviewing (but it works, so accept merge!). It's hardly the silver bullet to this problem. As for your original post - moving to FOSS only is not viable for a lot of people. Linux has no good video-editing software, no good CAD tools, gimp has nothing on photoshop and even Libreoffice is rather lackluster when compared to the MS Office package. On top of that, javascript is used pretty much in every site these days, many of which require javascript to run. You can't seriously expect an average user to manually whitelist javascript in the sites they browse. If the FOSS world had software that worked for everyone, people would use it. Right now, the only major group this is true for however, are developers. Until this changes there will be no 'year of the Linux Desktop' or whatever.

siwatanejo 9y ago
> moving to FOSS only is not viable for a lot of people I never advocated for people moving to FOSS. I just said it's a way to not be affected by these bugs, end of story. If the disadvantages of people moving to FOSS don't outweight the benefits, fine for them. > You can't seriously expect an average user to manually whitelist javascript in the sites they browse. Fair enough, that's why I only added "NoScript add-on" as an after thought. > Until this changes there will be no 'year of the Linux Desktop' Good to know your PoV on this.

anon1385 9y ago

So what you are saying is that if you never install closed source software, you will never (intentionally) install malware because you define all malware as closed source. This is a meaningless tautology. The advice you are giving is both objectively wrong and actively dangerous. Firstly not all security issues involve installing 'malware'. Take heartbleed; a major security vulnerability in open source software. To be hit by that you didn't need to install any non-open source software. You could have had the most pure and open stack of software and hardware ever created and it would have made no difference because the flaw was an information leak that didn't involve installing software or even unintended remote execution of code. That bug was due to the existing already installed open source code copying past the end of a buffer. Similar information leaking bugs could feasibly exist due to CPU bugs or compiler bugs or undefined behaviour in the code etc (i.e. all sorts of ways that don't involve installing malware and aren't even obvious from reading the code). Secondly, even exploits that do involve "running malware" are very often not because the user intentionally installed malware. They happen because the user did something like download and decode an image file which took advantage of a vulnerability in their (open source!) image decoding library to execute code on their machine. Again in this scenario it doesn't matter that the user would only ever intentionally install open source software, because the malware was executed unintentionally when they performed an activity they didn't expect to lead to code execution (viewing an image). E: These CPU issues are fundamentally timing attacks that leak information. I don't need to execute code on your computer at all to run a timing attack against you that leaks valuable information - I can do it by sending packets of pure data and don't need to be able to execute arbitrary code on your machine at all. Side channels like timing attacks don't necessarily require any kind of code execution on the target machine (although obviously having a high precision local timer makes it easier). This isn't just theoretical, it has been demonstrated in reality. For example see this paper[1] which demonstrates doing timing attacks against a browser to reveal the users browser history without the need to execute javascript at all. It's all done by sending CSS, which isn't code. [1] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07/09/DSN_paper.pdf https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07...