Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdooring JavaScript using minifier bugs

zyan.scripts.mit.edu

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Backdooring JavaScript using minifier bugs

#11

Post by phpnode »

yoz-y wrote: post #3

I wonder. Should one ever use minified javascript code on a server? Assuming that you are using it on your own server and not distributing the code to clients. Is there any benefit to it?

> Is there any benefit to it?

Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower.

Whether that makes any meaningful difference to your application performance really depends on the application. In most cases it won't.

Re: Backdooring JavaScript using minifier bugs

#12

Post by nitrogen »

phpnode wrote: post #11
yoz-y wrote: post #3

I wonder. Should one ever use minified javascript code on a server? Assuming that you are using it on your own server and not distributing the code to clients. Is there any benefit to it?

> Is there any benefit to it? Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower. Whether that makes any meaningful difference to your application performance…

Interesting. Is there a reason why the parsed AST size isn't used instead of raw source code size?

Re: Backdooring JavaScript using minifier bugs

#13

Post by Kenji »

phpnode wrote: post #11
yoz-y wrote: post #3

I wonder. Should one ever use minified javascript code on a server? Assuming that you are using it on your own server and not distributing the code to clients. Is there any benefit to it?

> Is there any benefit to it? Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower. Whether that makes any meaningful difference to your application performance…

That's really odd. In my eyes, source code length is not a good way to measure the semantic size of a function. But what you're saying is very interesting; I learned something new.

Re: Backdooring JavaScript using minifier bugs

#14

Post by phpnode »

nitrogen wrote: post #12
phpnode wrote: post #11

Earlier quoted context omitted.

> Is there any benefit to it? Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower. Whether that makes any meaningful difference to your application performance…

Interesting. Is there a reason why the parsed AST size isn't used instead of raw source code size?

V8 doesn't use an AST, it uses a CFG, but I believe it comes down to efficiency - it's far cheaper to look at the length of a string than to traverse a graph, and by its nature JS needs very fast compilation times.

This is probably one of those heuristics that works well enough on enough real world code, even though everyone knows it's suboptimal. I've heard that the turbofan compiler will remove this limitation but that's still very much work in progress.

Re: Backdooring JavaScript using minifier bugs

#15

Post by tracker1 »

bcrypt wrote: post #8
jand wrote: post #5

Nice to read text on a clever find. Could somebody please confirm or invalidate my understanding, that this backdoor is just exploitable in addition with other (severe) issues? An attacker would have to have the ability to tailor/manipulate JS scripts which should be under control of the victim? Or am i mistaken?

That's correct. I did not discover vulnerabilities in existing libraries or add backdoors to any of them. :) The attack scenario described in the post is (1) attacker writes some plausible-looking patches to an existing library like jQuery, (2) attacker convinces library maintainer to merge the patches, (3) someone builds the library with a buggy minifier, which creates the actual backdoor.

It's interesting all the same, It's kind of why exploits in very popular things like wordpress become problematic for so many for so long.

Re: Backdooring JavaScript using minifier bugs

#16

Post by bluesign »

Kenji wrote: post #13
phpnode wrote: post #11

Earlier quoted context omitted.

> Is there any benefit to it? Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower. Whether that makes any meaningful difference to your application performance…

That's really odd. In my eyes, source code length is not a good way to measure the semantic size of a function. But what you're saying is very interesting; I learned something new.

it is not a good way for sure, but I think it is good enough for most of the cases.

Re: Backdooring JavaScript using minifier bugs

#17

Post by makomk »

samuellb wrote: post #2

This makes me think that there could be similar bugs in the browser, when it JIT-compiles or optimizes Javascript code. That could be used to take control of the whole browser/OS if used in an add-on/extension (given that it has sufficient privileges).

There have been similar bugs in browser JITs that allow websites to escape the sandbox - usually incorrect optimisations that cause the JIT to elide bounds checks when it can't safely do so, probably since those are the easiest to exploit.

Re: Backdooring JavaScript using minifier bugs

#18

Post by eru »

bluesign wrote: post #16
Kenji wrote: post #13

Earlier quoted context omitted.

That's really odd. In my eyes, source code length is not a good way to measure the semantic size of a function. But what you're saying is very interesting; I learned something new.

it is not a good way for sure, but I think it is good enough for most of the cases.

Especially if people are mostly minifying their code already.

Re: Backdooring JavaScript using minifier bugs

#19

Post by nallerooth »

phpnode wrote: post #11
yoz-y wrote: post #3

I wonder. Should one ever use minified javascript code on a server? Assuming that you are using it on your own server and not distributing the code to clients. Is there any benefit to it?

> Is there any benefit to it? Well, in theory yes. When determining whether a specific function can be inlined into its call site, V8 looks at the length of the function source code to try and guess whether it's worth it. Functions longer than 600 characters (including comments) cannot be inlined and therefore they will typically be slower. Whether that makes any meaningful difference to your application performance…

I did not know that, thanks!
Post reply on HN