Bug 18232

Summary: uglify-js new security issue CVE-2015-8858
Product: Mageia Reporter: David Walser <luigiwalser>
Component: SecurityAssignee: Nicolas Lécureuil <mageia>
Status: RESOLVED OLD QA Contact: Sec team <security>
Severity: normal    
Priority: Normal CC: joequant, lewyssmith, thomas
Version: 5Keywords: has_procedure
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: uglify-js-2.4.24-3.mga5.src.rpm nodejs-async CVE:
Status comment:
Bug Depends on: 18243    
Bug Blocks:    

Description David Walser 2016-04-21 16:01:27 CEST
Upstream has issued an advisory on October 24:
https://nodesecurity.io/advisories/48

The issue is fixed upstream in 2.6.0.

Mageia 5 is also affected.
David Walser 2016-04-21 16:01:38 CEST

CC: (none) => thomas
Whiteboard: (none) => MGA5TOO

Comment 1 Thomas Spuhler 2016-04-21 18:45:31 CEST
fixed in cauldron
Comment 2 David Walser 2016-04-21 18:49:28 CEST
Thanks Thomas.

Version: Cauldron => 5
Whiteboard: MGA5TOO => (none)

Comment 3 Thomas Spuhler 2016-04-21 20:07:22 CEST
This bug has now been fixed in mga5. The following packages are now in updates_testing:
uglify-js-2.6.2-1.mga5.src.rpm
uglify-js-2.6.2-1.mga5.noarch.rpm
js-uglify-2.6.2-1.mga5.noarch.rpm

assigning it to qa

Status: NEW => ASSIGNED
Assignee: joequant => qa-bugs

Comment 4 David Walser 2016-04-21 20:11:47 CEST
Thanks Thomas!

PoC is on the upstream advisory.

Advisory:
========================

Updated uglify-js packages fix security vulnerability:

uglify-js before 2.6.0 is vulnerable to regular expression denial of service
(ReDoS) when certain types of input is passed into .parse() (CVE-2015-8858).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8858
https://nodesecurity.io/advisories/48

Whiteboard: (none) => has_procedure

Comment 5 Thomas Spuhler 2016-04-22 17:08:09 CEST
Need to push release of Bug 18243 first, upgrade nodejs-async to vers. 1.5.0
claire robinson 2016-04-22 17:16:34 CEST

Depends on: (none) => 18243

Comment 6 claire robinson 2016-04-23 14:05:06 CEST
The PoC fails, unable to find module uglify-js. I suspect this is a node failure rather than uglify-js failure though as uglify-js from cli works fine.

This is from pre-update but the results are the same post-update too.

$ time node test.js 10000

module.js:340
    throw err;
          ^
Error: Cannot find module 'uglify-js'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/home/claire/test/test.js:1:71)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)

real    0m0.040s
user    0m0.036s
sys     0m0.004s


but..

$ uglifyjs test.js 
var u=require("uglify-js");var genstr=function(len,chr){var result="";for(i=0;i<=len;i++){result=result+chr}return result};u.parse("var a = "+genstr(process.argv[2],"1")+".1ee7;");


Looking at the file structure under /usr/lib/node_modules/ shows uglify-js is a maze of symlinks, which might be the cause.

Not sure whether to OK this or not, Thomas, David wdyt?

Whiteboard: has_procedure => has_procedure feedback

Comment 7 Thomas Spuhler 2016-04-23 19:33:49 CEST
Could you upload the test.js file?
I would like to run the test here.

I think we use uglify-js only on roundcubemail-plugin-kolab and the uglify part has not problem
Comment 8 claire robinson 2016-04-23 19:58:47 CEST
Follow the nodesecurity link in the advisory Thomas
Comment 9 Thomas Spuhler 2016-04-24 20:33:51 CEST
I get the same error as you do. On the other hand. roundcubmail-plugins-kolab uses it in the build and I don't see any errors.
Since there is no regression, we may should just go ahead with the release.
I saw in an e-mail this morning that nodejs is being upgraded to 5.11.(from 5.6.0) in cauldron
Comment 10 David Walser 2016-04-26 21:54:09 CEST
Yes, I think we can go ahead with this one.

Whiteboard: has_procedure feedback => has_procedure

Comment 11 claire robinson 2016-04-27 17:40:41 CEST
Testing mga5 64

tl;dr; Still errors. Appear related to this package.

When run under strace it's clear why this is failing. It searches for modules in current directory, home directories and then /usr/lib/node.

From https://nodejs.org/api/modules.html

$ export NODE_PATH=/usr/lib/node_modules   
$ echo $NODE_PATH
/usr/lib/node_modules


Before
------

$ node test.js

/usr/share/javascript/uglify-js-2/parse.js:204
    throw new JS_Parse_Error(message, filename, line, col, pos);
          ^
Error
    at new JS_Parse_Error (/usr/share/javascript/uglify-js-2/parse.js:196:18)
    at js_error (/usr/share/javascript/uglify-js-2/parse.js:204:11)
    at parse_error (/usr/share/javascript/uglify-js-2/parse.js:314:9)
    at read_num (/usr/share/javascript/uglify-js-2/parse.js:340:13)
    at handle_dot (/usr/share/javascript/uglify-js-2/parse.js:516:15)
    at Object.next_token [as input] (/usr/share/javascript/uglify-js-2/parse.js:560:27)
    at next (/usr/share/javascript/uglify-js-2/parse.js:666:25)
    at vardefs (/usr/share/javascript/uglify-js-2/parse.js:1087:48)
    at var_ (/usr/share/javascript/uglify-js-2/parse.js:1100:27)
    at /usr/share/javascript/uglify-js-2/parse.js:848:30

After
-----

# urpmi uglify-js js-uglify
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Updates Testing")
  js-uglify                      2.6.2        1.mga5        noarch  
  nodejs-async                   1.5.0        1.mga5        noarch  
  uglify-js                      2.6.2        1.mga5        noarch  
45KB of additional disk space will be used.
141KB of packages will be retrieved.
Proceed with the installation of the 3 packages? (Y/n)

$ node test.js

undefined:1533
    throw new JS_Parse_Error(message, filename, line, col, pos);
          ^
Error
    at new JS_Parse_Error (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1525:18)
    at js_error (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1533:11)
    at parse_error (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1646:9)
    at read_num (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1672:13)
    at handle_dot (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1853:15)
    at Object.next_token [as input] (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:1897:27)
    at next (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:2011:25)
    at vardefs (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:2432:48)
    at var_ (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:2445:27)
    at eval (eval at <anonymous> (/usr/lib/node_modules/uglify-js@2/tools/node.js:24:4), <anonymous>:2193:30)

Whiteboard: has_procedure => has_procedure feedback

Comment 12 Lewis Smith 2016-05-10 21:06:48 CEST
Trying x64
 js-uglify-2.6.2-1.mga5
 uglify-js-2.6.2-1.mga5
 nodejs-async-1.5.0-1.mga5

With the given test script from: https://nodesecurity.io/advisories/48
 $ node test.js
gave exactly the same erroneous result as for Claire Comment 6.
If Comment 11 matters:
 $ export NODE_PATH=/usr/lib/node_modules
once again, should this be part of the package? Trying this also yielded the same results as Comment 11.

This has been hanging around for weeks. I am uneasy about simply pushing it (with 18243). We seem to be at sea.

CC: (none) => lewyssmith

Comment 13 claire robinson 2016-05-12 11:50:27 CEST
Closing bug 18243 for clarity. The nodejs-async package is required as part of this update so we will handle using one bug.

nodejs-async-1.5.0-1.mga5.src.rpm
nodejs-async-1.5.0-1.mga5.noarch.rpm


Thomas, any progress with the issues mentioned in this bug?
claire robinson 2016-05-12 11:51:18 CEST

Source RPM: uglify-js-2.4.24-3.mga5.src.rpm => uglify-js-2.4.24-3.mga5.src.rpm nodejs-async

Comment 14 Thomas Spuhler 2016-05-13 16:26:54 CEST
Claire:
No, not really. I propose to push it as it is not a regression. What do you think David?

I used pretty much the Fedora spec, but noticed that if the tests are enabled, the package doesn't build.
I wonder if we are missing a symlink in the top package (nodejs). Maybe the maintainer of nodejs, joequant (Joseph Wang) could shed some light into it? I cc him

CC: (none) => joequant

Comment 15 claire robinson 2016-05-13 16:29:29 CEST
Not much point pushing a security update for it if it doesn't work Thomas.
Comment 16 David Walser 2016-05-13 16:47:53 CEST
Is there some use case for which this package works and then one where it doesn't, or is it a totally useless package?
Comment 17 Thomas Spuhler 2016-05-13 16:53:31 CEST
roundcubemail-plugins-kolab as it as a build BuildRequires and it actually works.
Comment 18 David Walser 2016-05-13 16:55:58 CEST
I would be inclined to let this one go for now then and file a bug for the remaining issue.
Comment 19 claire robinson 2016-05-13 18:05:23 CEST
Asking for other packagers to gang up with you is counter productive. I've no intention of validating this obviously broken package. If anybody else wishes to do so, that's up to them.

There is very little point in us testing updates if the packager is then unwilling to fix them when we find them badly broken. Thomas, I don't understand your unwillingness to fix it, surely it could have been done in the time it has taken to find reasons not to?
Comment 20 Joseph Wang 2016-05-13 19:50:11 CEST
The basic problem is that all of the nodejs packages are dependent on all of the other packages.  upgrading async caused a lot of cascading dep problems in the nodejs stack.

Right now, I'm trying to just sync up the Mageia nodejs stack with Fedora.  This needs to be done before release of Mageia 6 or else we will have hell fixing security issues with Mageia 6.

Don't know how this works with Mageia 5.

Personally, I'd like to remove as many packages from the nodejs stack as possible, but the trouble is that you have some core packages that then have a mess of dependencies.

Ultimately we need to work with Fedora to create an automated system for updating rpms.
Comment 21 Joseph Wang 2016-05-13 19:51:07 CEST
Also if anyone what's to reassign nodejs packages to me, I can handle them.  It's a matter of putting on the rubber boots.
Comment 22 claire robinson 2016-05-14 02:04:46 CEST
Talking with Thomas privately, he is simply unable to work on this as much as he'd like to.

Joseph would you be good enough to handle this update please?

It appeared to be broken before and after the update so I'm not certain that async is the only issue with it.

Our policy for stable is to prefer patching over version bumps where it's practical to do so, so perhaps it is possible to roll back and patch the CVE instead to avoid version incompatibilities?

Thanks
Comment 23 Joseph Wang 2016-05-14 02:23:37 CEST
Yes.  I'm handling this by doing a sync with the Fedora packages.

Sync isn't the only issue.  The basic issue is that our nodejs stack is really, really divergent.

I don't think that a rollback and patch will work.  The trouble is that nodejs uses an "app store" model in which you have a lot of tiny packages that are constantly changing.  Trying to figure out a patch off ancient code is likely to cause more long term pain.  Also unlike the "old way" where you have big stable patches, the response from upstream is likely to just bump the version.

Syncing the nodejs tree to Fedora is a temporary fix to make sure that we have something usable for Mageia 6.  Ultimately we need to work with the other distros to come up with some sort of standard system to deal with nodejs.
Comment 24 Joseph Wang 2016-05-14 10:35:27 CEST
After going crazy trying to get a runnable version for Mageia 6, I'm starting to be of the opinion that we should just drop the uglifyjs package and most of the nodejs stack for Mageia 6.  

The way this would work is that we'd have a clean bootstrap npm and nodejs, and if someone wants to install uglify they can use the npm mechanism.
Comment 25 claire robinson 2016-05-18 18:58:31 CEST
Assigning Joseph til it's ready.

Assignee: qa-bugs => joequant
Whiteboard: has_procedure feedback => has_procedure

Comment 26 Joseph Wang 2016-05-19 04:14:48 CEST
Reassigning to neoclust.  He's agreed to deal with the nodejs stact.
Joseph Wang 2016-05-19 04:16:22 CEST

Assignee: joequant => neoclust

Samuel Verschelde 2016-10-13 22:38:05 CEST

Assignee: neoclust => mageia

Comment 27 Nicolas Lécureuil 2016-11-26 14:52:12 CET
I will update nodejs stack on cauldron.

Should i do the same for mga5 too ?
Comment 28 Nicolas Lécureuil 2017-08-21 15:58:29 CEST
just a reminder of the packages added or modified for the new nodejs:


nodejs
libuv
Comment 29 Nicolas Lécureuil 2017-08-21 16:18:21 CEST
http-parser
Frédéric "LpSolit" Buclin 2017-09-06 16:09:37 CEST

Keywords: (none) => has_procedure
Whiteboard: has_procedure => (none)

Comment 30 David Walser 2017-12-27 00:52:56 CET
We can't fix this.  We should probably drop it (and roundcubemail-plugins-kolab which BR's it, because it's unmaintained).

Resolution: (none) => OLD
Status: ASSIGNED => RESOLVED