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

How we exploited a code execution vulnerability in math.js

capacitorset.github.io

Post reply on HN
Print view View original

21–30 of 32 posts

Re: How we exploited a code execution vulnerability in math.js

#21

Post by the8472 »

CapacitorSet wrote: post #16
emmab wrote: post #13

Blacklists are a losing game. Always use a whitelist.

This was actually the second fix I had in mind, after the author mentioned that they would like mathjs to have complete browser support (and therefore couldn't use the `vm` module from Node.js): >If, anyway, you want to make math.eval resistant against arbitrary code execution, I think it would be best to have a whitelist of methods and constructs (i.e. you parse the code that is meant to be evaluated and ensure that…

> and therefore couldn't use the `vm` module from Node.js

browsers do have isolated contexts these days, they're just cumbersome to use.

  1. spawn an iframe with sandbox="allow-script" and srcdoc="........."
  2. use window.postMessage to communicate between the parent page and the iframe running in a null origin
  3. send code to eval into that iframe

Re: How we exploited a code execution vulnerability in math.js

#23

Post by jmaa »

CapacitorSet wrote: post #20
jmaa wrote: post #19

Earlier quoted context omitted.

I'm not really an expert on JS, but I'm guessing that the constructor function is the same function object, although it can be accessed in different ways. Wouldn't it be possible to blacklist the function object itself, instead of the access path?

This is what the author attempted to do: if you read the first commit linked in the article, they made it so that math.js wouldn't execute Function when it encountered it (either an actual Function or a variable that equals Function). However, the trick is to make Javascript execute Function, through a function that math.js won't mind executing. What I found was simply using Function.apply and Function.call; the auth…

Alright, so there are simply too many unique functions accessible through the math.js API, for blacklisting to be feasible.

I'm curious why he didn't go down the whitelisting path in the first place. Basic maths don't require that many functions anyway, so he could've started with a small list, and expanded it as people asked for more. Alternatively he could have allowed for custom whitelists.

Re: How we exploited a code execution vulnerability in math.js

#26

Post by CapacitorSet »

yagop wrote: post #24

Nice article. I wrote that lua "wrapper" 2 years ago. I used math.js to avoid RCE on bots, turns out math.js API is vulnerable but doesn't affect the wrapper.

Did you also write the gnuplot plugin? Because that's also vulnerable, as found by the same @denysvitali: https://github.com/LucentW/s-uzzbot/issues/9

Re: How we exploited a code execution vulnerability in math.js

#28

Post by dvitali »

CapacitorSet wrote: post #26
yagop wrote: post #24

Nice article. I wrote that lua "wrapper" 2 years ago. I used math.js to avoid RCE on bots, turns out math.js API is vulnerable but doesn't affect the wrapper.

Did you also write the gnuplot plugin? Because that's also vulnerable, as found by the same @denysvitali: https://github.com/LucentW/s-uzzbot/issues/9

Proof: http://i.imgur.com/BpLtg0b.png

Re: How we exploited a code execution vulnerability in math.js

#29

Post by dvitali »

tyingq wrote: post #27
comex wrote: post #7

I was bored so I found a bunch more: https://github.com/josdejong/mathjs/issues/821

Ugh...that's not good. Are they using their own approach for (supposedly) safe eval(), or some library that other packages might be using?

Their own approach: although many other "safe eval" packages may be affected by similar issues

Re: How we exploited a code execution vulnerability in math.js

#30

Post by yagop »

CapacitorSet wrote: post #26
yagop wrote: post #24

Nice article. I wrote that lua "wrapper" 2 years ago. I used math.js to avoid RCE on bots, turns out math.js API is vulnerable but doesn't affect the wrapper.

Did you also write the gnuplot plugin? Because that's also vulnerable, as found by the same @denysvitali: https://github.com/LucentW/s-uzzbot/issues/9

That was from @francesco-p (he renammed his account from psykomantis) https://github.com/yagop/telegram-bot/commit/89b92b4cbf81ce1... its in my repo but disabled by default.
Post reply on HN