4 ms·

> 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

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

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.