Live data from Hacker News

Backdooring JavaScript using minifier bugs

zyan.scripts.mit.edu

21–30 of 37 posts

Re: Backdooring JavaScript using minifier bugs

#21
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?

Even if you don't use a minifier on the server, a library built using any kind of transpiler (babel, coffeescript, typescript...) could be susceptible to this kind of attack.

Re: Backdooring JavaScript using minifier bugs

#22
post #11
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…

Wait, what if you have really really long comments? Or do they get stripped out beforehand?

Re: Backdooring JavaScript using minifier bugs

#24
post #11
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 surprising. Thanks!

Re: Backdooring JavaScript using minifier bugs

#25
post #14

Earlier quoted context omitted.

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…

... and people wonder why we want a web bytecode so, so badly.

Re: Backdooring JavaScript using minifier bugs

#26
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's actually a fair number of security researchers looking at browser-level exploits like those in JIT (c.f. pwn2own). My colleague Chris Rolhf co-authored a cool study on attacking JIT: https://www.nccgroup.trust/us/about-us/resources/jit/

Re: Backdooring JavaScript using minifier bugs

#27
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…

Wait, what if you have really really long comments? Or do they get stripped out beforehand?

Comments affect this heuristic, so yeah, commented code can be slower.

Re: Backdooring JavaScript using minifier bugs

#28
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?

This may sound entirely wacky, but I have seen it make a major performance impact on nodejs.

The reason is that V8 uses heuristics to decide which functions get inlined, and the raw source code length is one of the heuristics. Making the source for a function shorter may cause V8 to inline it more aggressively.

Re: Backdooring JavaScript using minifier bugs

#29
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…

Wait, what if you have really really long comments? Or do they get stripped out beforehand?

Some libraries use annotations in comments. Therefore they cannot be stripped. Off the top of my head I know of some JavaScript testing libraries that do this.

Re: Backdooring JavaScript using minifier bugs

#30
post #11
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 never know this before! Thanks for sharing.
Post reply on HN