7 ms·

> Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a p

> Offering a language playground to the general public and not sufficiently preventing that playground from compromising the very server on which it runs is a pretty glaring problem How it is a problem for anyone except project owners? Project owners were notified. There was no need to disclose it publicly. I say it's childish. > banning people from contributing to a project entirely merely because they pointed out glaring security issues Banning them because they: * don't do any good (in particular, zero code contributions in a year) * disrupt the work by telling the internet how to break their service * call the project "vaporware" I'd call it is enough reasons to ban them. And some personal argument. I have a service I'm running, for the random people in the internet. I implemented it long time ago, and I spend like 10 minutes a year supporting it. It is not protected seriously, because I don't have enough time to do so. I think any kid with basic knowledge of how internet works, can easily break it, or even can DOS it causing me to pay big bucks to the hoster for the consumed CPU. And I have full-time job. So if some person would notify me about the vulnerability, and give me one (!) day to fix it, I would probably give up what ever I'm doing, my work, my personal plans, and fix the issue, but I would be very unhappy about it, and I will probably be angry at that person, and I'll try to avoid that person like fire.

SahAssar 6y ago
> Project owners were notified. There was no need to disclose it publicly. I say it's childish. I don't think you understand how disclosure works within security.
- lightgreen 6y ago
  Well, I can only say you don't understand how disclosure works. When vulnerability is disclosed, there are usually good reasons for doing so. For example, when a vulnerability in operating system is found, it is disclosed, so users of that operating systems could upgrade operating system, or stop using it, or ask vendor to fix it or whatever. Disclosing this vulnerability makes the people (who are not project owners) safer from possible attacks from attackers who can independently find this vulnerability. How would disclosing vulnerability of V playground be beneficial for anybody? I can hardly find any significant reason. It's like you have accidentally found that your neighbour forgets to close the door when he leaves for a walk. You notified him, he did nothing. Disclosing this vulnerability would not make good to anyone except burglars. Good people don't do that.
yellowapple 6y ago
> How it is a problem for anyone except project owners? Because an infected machine can and often will participate in infecting other machines. Not to mention that if an attacker managed to extract credentials that happened to be shared between that server's accounts and, say, contributors' GitHub accounts... More relevantly for regular users of the playground, though, it ain't clear whether or not the playground server was separate from the web server. If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). And even if they were indeed separate servers, if the credentials to access those servers were shared between them, then compromising one exposes the other. I agree with you that maybe the author of that article should've waited more than a day, but that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing. > call the project "vaporware" I mean, for quite a while it did seem to have a lot of hype without much to show for it (as did Volt, its "killer app", so to speak), and it had a pretty rough release. It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Hopefully things have improved since then.
- lightgreen 6y ago
  > Because an infected machine can and often will participate in infecting other machines. OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process. > Not to mention that if That big if. > If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). That's good example. And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day. > that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects. The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited. > It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you. Saying he is dumb is not innaccurate. But it doesn't help constructive team work. The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.

SahAssar 6y ago

> Project owners were notified. There was no need to disclose it publicly. I say it's childish. I don't think you understand how disclosure works within security.

lightgreen 6y ago
Well, I can only say you don't understand how disclosure works. When vulnerability is disclosed, there are usually good reasons for doing so. For example, when a vulnerability in operating system is found, it is disclosed, so users of that operating systems could upgrade operating system, or stop using it, or ask vendor to fix it or whatever. Disclosing this vulnerability makes the people (who are not project owners) safer from possible attacks from attackers who can independently find this vulnerability. How would disclosing vulnerability of V playground be beneficial for anybody? I can hardly find any significant reason. It's like you have accidentally found that your neighbour forgets to close the door when he leaves for a walk. You notified him, he did nothing. Disclosing this vulnerability would not make good to anyone except burglars. Good people don't do that.

yellowapple 6y ago

> How it is a problem for anyone except project owners? Because an infected machine can and often will participate in infecting other machines. Not to mention that if an attacker managed to extract credentials that happened to be shared between that server's accounts and, say, contributors' GitHub accounts... More relevantly for regular users of the playground, though, it ain't clear whether or not the playground server was separate from the web server. If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). And even if they were indeed separate servers, if the credentials to access those servers were shared between them, then compromising one exposes the other. I agree with you that maybe the author of that article should've waited more than a day, but that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing. > call the project "vaporware" I mean, for quite a while it did seem to have a lot of hype without much to show for it (as did Volt, its "killer app", so to speak), and it had a pretty rough release. It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Hopefully things have improved since then.

lightgreen 6y ago
> Because an infected machine can and often will participate in infecting other machines. OK, so how disclosing this vulnerability will help preventing that? It is the opposite, disclosing this vulnerability only speeds up this process. > Not to mention that if That big if. > If not, then the playground having root access immediately exposes ordinary users to high risk of browser-based attacks (drive-by downloads, outright replacing the V downloads with compromised versions, etc.). That's good example. And that's one more reason to privately push the owners of the project owner to fix the issue instead of disclosing after one day. > that's really a drop in the bucket compared to the possibilities of running arbitrary user-supplied server-side code without sufficient sandboxing I agree, that's bad, and that's happen all the time in huge companies, not just single-person open source side projects. The correct response to vulnerability would be creating a post to pressure project owner by explaining the dangers of it without disclosing how exactly it can be exploited. > It's a bit of a harsh characterization, but at the time it wasn't all that inaccurate. Analogy. Your coworker is dumb. You can say he is dumb. And then he refuses to work with you. Saying he is dumb is not innaccurate. But it doesn't help constructive team work. The blog author could start by apologizing (or at least by redacting the post), if they wanted to work with the project team.