5 ms·

I'm failing to see how that post is a "childish attempt" at anything. Offering a language playground to the general public and not sufficiently preventing that

I'm failing to see how that post is a "childish attempt" at anything. 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. At worst, you might criticize her for publishing that post immediately after discovering the exploit (instead of the more "polite" approach of allowing someone to patch it first, within a reasonable deadline), but that's pretty minor in comparison to, you know, V's playground being vulnerable to major security issues. In any case, banning people from contributing to a project entirely merely because they pointed out glaring security issues is considerably more childish than the actual pointing out of security issues, no matter how distastefully the latter might've been done (and again, aside from the lack of a responsible disclosure period, I ain't seeing anything particularly glaring in that post).

lightgreen 6y ago
> 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.
xena 6y ago
I considered it not an issue to post about it because the server was down and confirmed to not come back up (I think someone ace'd it and installed a rootkit then rebooted).
- lightgreen 6y ago
  And that very important fact ("confirmed to not come back up") was not even mentioned in the "advisory" blog post.

lightgreen 6y ago

> 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.

xena 6y ago

I considered it not an issue to post about it because the server was down and confirmed to not come back up (I think someone ace'd it and installed a rootkit then rebooted).

lightgreen 6y ago
And that very important fact ("confirmed to not come back up") was not even mentioned in the "advisory" blog post.