5 ms·

I don’t think this is JavaScript specific. It’s like saying “BMW cars in Paris stop working if you pour sugar in tank”.

bestham 5y ago
The point is not that the vulnerability is a trait of javascript but to make a demonstration on how different unicode characters can be used to create a vulnerability, exemplified by a piece of javascript.
- mirekrusin 5y ago
  Yes, I understand it, but title and content doesn't explicitly mention this "detail" that same attact vector exists for other languages and data formats.
dspillett 5y ago
> I don’t think this is JavaScript specific. It isn't, any relatively dynamic language is going to have these or similar issues. Many moons ago I saw similar examples in bash, I'm sure they are possible in PHP, ..., ..., ... In fact, even the more strict languages probably do to: the “accidentally run something malicious via care-free use of exec” is an issue in just every language that has “exec”/similar - it is a data trusting error in the programmer's logic not an issue with the language itself. The dynamic nature of some of JS's syntax is just one way to pollute the data being fed to exec amongst the other sources (user input, being too trusting of config in the DB or filesystem, and so forth). Javascript is a very good option to use for examples though: most devs know it well enough and it is everywhere so the potential scale of the danger is obvious, even more so in light of people being far too trusting of dependencies pulled via NPM and the recent examples of malicious updates getting into common packages. Maybe the title could be a bit less click-baity, though I'm not sure what would be used instead that wouldn't be overly wordy for a punchy article title.
- fergie 5y ago
  Strong typing doesn't fix the issue that invisible characters can be used as variable names.
UncleMeat 5y ago
This whole story has been stupid. These ideas have been around for ages and are not novel to the security community. Yet we've seen headlines like "all programs ever are vulnerable to this new hack." The root cause is not unicode characters but instead untrusted text. It isn't like a malicious library would be unable to sneak backdoors in through ascii source anyway. Heck, we just had a big kerfuffle over this happening in the linux kernel this year. Or worse! Go look at the dependencies for some large enterprise system built in java. How many raw jars do you think are being included in there? Has anybody looked at the bytecode of these jars?
pumpum 5y ago
Good point. FYI, sugar in the gas tank is a myth. The sugar will cause basically no harm at all, I've witnessed it attempted.

The point is not that the vulnerability is a trait of javascript but to make a demonstration on how different unicode characters can be used to create a vulnerability, exemplified by a piece of javascript.

mirekrusin 5y ago
Yes, I understand it, but title and content doesn't explicitly mention this "detail" that same attact vector exists for other languages and data formats.

dspillett 5y ago

> I don’t think this is JavaScript specific. It isn't, any relatively dynamic language is going to have these or similar issues. Many moons ago I saw similar examples in bash, I'm sure they are possible in PHP, ..., ..., ... In fact, even the more strict languages probably do to: the “accidentally run something malicious via care-free use of exec” is an issue in just every language that has “exec”/similar - it is a data trusting error in the programmer's logic not an issue with the language itself. The dynamic nature of some of JS's syntax is just one way to pollute the data being fed to exec amongst the other sources (user input, being too trusting of config in the DB or filesystem, and so forth). Javascript is a very good option to use for examples though: most devs know it well enough and it is everywhere so the potential scale of the danger is obvious, even more so in light of people being far too trusting of dependencies pulled via NPM and the recent examples of malicious updates getting into common packages. Maybe the title could be a bit less click-baity, though I'm not sure what would be used instead that wouldn't be overly wordy for a punchy article title.

fergie 5y ago
Strong typing doesn't fix the issue that invisible characters can be used as variable names.

UncleMeat 5y ago

This whole story has been stupid. These ideas have been around for ages and are not novel to the security community. Yet we've seen headlines like "all programs ever are vulnerable to this new hack." The root cause is not unicode characters but instead untrusted text. It isn't like a malicious library would be unable to sneak backdoors in through ascii source anyway. Heck, we just had a big kerfuffle over this happening in the linux kernel this year. Or worse! Go look at the dependencies for some large enterprise system built in java. How many raw jars do you think are being included in there? Has anybody looked at the bytecode of these jars?

pumpum 5y ago

Good point. FYI, sugar in the gas tank is a myth. The sugar will cause basically no harm at all, I've witnessed it attempted.