Package vulnerabilities

General
1

While updating my computers to the latest and fixing other problems I got this warning shown to me.

pi@PortaPi:~/.node-red $ sudo npm uninstall node-red-node-rbe
npm WARN node-red-project@0.0.1 No repository field.
npm WARN node-red-project@0.0.1 No license field.

audited 416 packages in 10.079s
found 17 vulnerabilities (2 low, 13 moderate, 2 high)
  run `npm audit fix` to fix them, or `npm audit` for details
pi@PortaPi:~/.node-red $ sudo npm uninstall node-red-node-rbe
npm WARN node-red-project@0.0.1 No repository field.
npm WARN node-red-project@0.0.1 No license field.

audited 416 packages in 9.417s
found 17 vulnerabilities (2 low, 13 moderate, 2 high)
  run `npm audit fix` to fix them, or `npm audit` for details
pi@PortaPi:~/.node-red $ sudo npm audit fix
npm WARN deprecated hoek@2.16.3: This version is no longer maintained. Please upgrade to the latest version.
npm WARN deprecated boom@2.10.1: This version is no longer maintained. Please upgrade to the latest version.
npm WARN deprecated cryptiles@2.0.5: This version is no longer maintained. Please upgrade to the latest version.
npm WARN node-red-project@0.0.1 No repository field.
npm WARN node-red-project@0.0.1 No license field.

added 62 packages from 57 contributors, removed 94 packages and moved 44 packages in 22.822s
fixed 17 of 17 vulnerabilities in 416 scanned packages

(That is but one of a couple which spat out a big list of problems.)

Now, I (now) know I shouldn't have uninstalled the RBE node.

I am running the latest version of NR.

I was advised to run "npm audit fix" to resolve the problems. (Done with sudo prefix)

I understand that some of the packages are dated and no longer maintained. It happens.

But I am putting this out there for others so they don't become/get too complacent with updates.

As my machines are pretty well off the net, it isn't a big issue for me, but I do hope that one day they will be accessible from the net, so these holes need fixing now rather than later.

I read Nick was saying there are problems with the mixture of version numbers of: NR, node.js npm and other things.

(sorry for not looking before posting)

Is there an "IDIOT's GUIDE" to getting all the pieces up to date (RPI and UBUNTU) to mitigate this from happening in the future?

2

It might have been worth searching the forum for
npm audit fix first, then you would have found More security considerations

3

Well, yes, thanks.

Interesting and I guess it shows there isn't a "magic answer" to the problem.

Although now kind of going off topic a bit, it is interesting that you quoted the "Done with sudo prefix" part of my post.

Only because that in itself is interesting to me.
(Whether or not the SUDO is needed)
When I ran the command this is part of the reply:

pi@CameraPi:~/.node-red $ sudo npm audit fix

> serialport@6.2.2 install /home/pi/.node-red/node_modules/serialport
> prebuild-install || node-gyp rebuild

prebuild-install WARN install EACCES: permission denied, access '/root/.npm'
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/.node-gyp/8.11.4"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/tmp/.node-gyp"
gyp ERR! configure error 
gyp ERR! stack Error: EACCES: permission denied, mkdir '/home/pi/.node-red/node_modules/serialport/build'

Note the line:

gyp WARN EACCES user "root" does not have permission to access the

So it begs the question (rhetorical or otherwise):
If "root" doesn't have permission: WHO has?

Ok, this is a unixy thing and is a whole different issue, and I should get more up to speed with things like this.

It is just every now and then I am "blind sided" by messages like that which to me are way out of context.

Given "root" is supposed to be "all access"........

I can't believe I am "hacked" or anything like that. These machines don't really run on the net.
Yeah, ok. They are now as that is how I am updating them, and there is nothing to stop them being hacked at this point.

But I think it is a different problem.
(Me, not understanding the bigger picture.)
(wink)

4

I quoted the "Done" because the link I pointed to advised against doing it.

I believe the permissions issue is because you need to specify --unsafe-perm when installing some nodes as npm spawns off to the compiler and does not pass on the root permissions (which could be a security issue) unless you give it permission.

1 Like
5

Sorry.

The message was received, but obviously I goofed with how it was flagged.

Shall do it without the sudo.

(Need new brain, or battery to keep memories valid)

6

The advise was not to do it at all, with or without sudo.

1 Like
7

Now I'm getting confused.

Ok, you are saying DON'T DO IT. Ok. I'm happy with that.

But when I am going about things and installing the newer version of "rbe" and NR says there are errors (I don't have the exact words now as I don't keep everything) and to run:
npm audit fix
to fix the problem....... I do it.

Granted the "sudo" didn't help.
Putting that aside, the program told me to.

Now, before you attack me for the stupidity of me saying that:
I have to draw the line somewhere with TRUST.

I TRUST NR to do the right thing - as much as possible.

(The story)
I went through a few weeks ago and updated all the machines to 19.4.

Recently I needed to do some updates on ALL the machines with their flows.
Before I did this, I decided to get all the nodes up to date, so there wouldn't be problems with different machines having different node versions and any complications from that.

I sat there and went through.
(Sort of regretting it now.....)
Seems now when updating any node: a restart is needed.
I was really not wanting to do that on ubuntu/rpi machines. Had enough of "perpetual updates abd needed restarts" from M$.

But be that as it is, I updated the nodes. Squillions of restarts in the process.

As I was going through I was seeing errors with serial-port and telegram nodes.
(and others. I don't remember them all.)

As I didn't use them I let it slide.

But when "rbe" came up on all/most of them, I got worried.

I found the post where you have to UNINSTALL them to fix the problem.

Started down that road and found errors about vulnerabilities and that took me down another path of fun and confusion.

I have 7 of the 10 RPIs ok. I hope. rbe is up to date.
But the other 2 (or 3?) just will NOT update the rbe.

I did exactly the same on all.

Why it doesn't work on these remaining few is beyond me.
But now I am "stuck" with this problem and I want to resolve it before it does become something serious.

Given I have now (on one machine):

cd ./node-red
npm uninstall node-red-node-rbe

or what ever....
Restarted the computer - just as easy to do than restart node-red.
Gone back and checked.
OLD VERSION.

Went in and:

cd ./node-red
npm install node-red-node-rbe

And sometimes get complaints about packages/nodes....

Still won't get to 2.4 for rbe.

So-o-o.......

If I am NOT supposed to:

npm audit fix

I ask that the program be told this and not me.
It says there are problems/vulnerabilities and they need fixing.

How else am I supposed to do it?

8

Is that machine running at least Node-RED 0.19.4? (See the comment earlier tonight from @knolleary in your other thread).

9

Yes it is running 19.4

As far as I know ALL machines are 19.4. They were updated weeks ago.

10

The only part of Node-RED you should ever be installing or updating using SUDO is Node-RED itself. And only if you've installed Node-RED globally. A global installation of a Node.JS module (e.g. Node-RED) generally requires root (LINUX) or admin (Windows) rights. The Node-RED installation guide has the details.

If you want to expose Node-RED to the Internet, you would be wise not to do the standard global installation since that gives at least some parts of Node-RED root access which might be a way in for an attacker (theoretical at this point). In addition, you would sensibly set up a dedicated user to run Node-RED and lock down access. You might also want to put something like NGINX (or HAProxy or other reverse proxy) as the externally accessible service rather than Node-RED itself since NGINX is generally more battle hardened. You will also need a well set up certificate for TLS/HTTPS and a user login on at least the admin UI. Indeed, you might choose to prevent external access to the admin interface altogether.

You will also need to make absolutely sure that there are no other avenues for an attacker to access your device.

If using a Pi, recognise that they, by default, are set up for ease of use not for security. They are not configured out of the box to be connected to the Internet safely.

11

As shown in my other post, this is not really very sensible advice as at least some of the modules have major version changes that imply breaking changes. Better to go back to the authors of any nodes with outdated dependencies and raise issues so that they know to update them. But also recognise that Node-RED itself supports a number of versions of Node.JS which sometimes prevents it from using the latest versions of modules. When Node-RED can finally drop Node.JS v4 compatibility, the situation should get somewhat better.

12

No. They were not errors. They were warnings. You did not need to run npm audit to get the node to work. Just install the rbe node as normal, ignore the audit warning, and carry on.

13

just to note - the only recent change to the rbe node was to update the Japanese locale messages... if you don't need them you can save a lot of hassle and not upgrade it.

14

Hi (again) Nick.

Ok. But "how" this presented itself to me was ....... confusing.

And I apologise for calling them ERRORS, rather than warnings. I know there is a big difference but that part of me which saw them flagged them as needing attention.
I'll get to that shortly.

So, the time line of what was/is going on:

1 -
I installed NR, way back when.
I installed nodes.
I kept most of the nodes up to date.
Updating them seldom required restarts. This was good as I could start at the top of the list and work my way down. (Note this is 99% done on REMOTE machines.)

2 -
I updated to a newer version of NR.
I tried to keep nodes up to date.
I installed some nodes in a trial for things but it didn't work always.
Sometimes I removed them, other times not. I saw some potential for future use.

3 -
Recently NR updated to 19.4. Woo Hoo - I think is the general feeling.
The new edit screens and a few bugs fixed. It was good.
My NR skills have come on somewhat from what they were at the start. Sure I am still learning. But I believe the only time you don't learn is when you are dead. No one knows EVERYTHING.
So, anyway....
My RPI population has somewhat grown and I have 9 RPIs on my network doing their own little job.
I know I said 10. Sorry.
One of the RPIs is my NTP server and WAP. It is on 24/7. Its connection to the net is only when it is needed.
Anyway, I thought it would be a good time to get them all "on the same page" so if/when I am designing a flow, it can work on any/all of them.

A few weeks ago I powered them all up and make sure they were 19.4.

4 -
A few days ago I decided to get them all 100% up to date. Unknown to me the time it will take.
(Stating how it happened here. No blame allocated.)
Rather than being able to open the Manage palette and start at the top and scroll through and update the nodes as needed, just about every node upon updating told me I needed to restart NR.
I don't know the finer details of that, and being a remote machine, a reboot seemed simpler.
(Too many notes. Yeah, I shall have to file the NR restart command better, but anyway...)
Also to my detriment: I am not sure I can update "all" the nodes (requiring a restart) and do ONE restart to get them all up to date. What ever. Academic now.

While going through the list I saw "rbe" said it was needing updating. Strange. I have seen it doesn't always meet my needs, but it could be useful so I will update it.
While going through the list, I also saw "twitter", "serial-port", "telegram" and other weird ones also needed updating and/or had red triangles on them. Huh?

So I have 9 RPI's sitting there (well: 8 as the NTP one is pretty well up to date and is an OLD RPI. Rebooting it is painfully slow.)

I asked about the rbe problem and was pointed to "uninstall it and the new version of NR will fix it." was basically what I read.
I went through uninstalling all the rbe nodes on all the machines.
Some came back happily and there was no other things said.
They would then be rebooted and (I think) rbe would then be happy and up to date.

Others would complain and I would get warnings in one format.
Others would complain (probably about the same stuff) but in a different format. Huh?
One of them told me to update npm also. Ok......

So, all the uninstalls done, some now happy with rbe. Some not.
That got me to "you shouldn't have un-installed them, simply install the new version." (implied from npm.)

Ok, tried that.

More new warnings and messages. What can of worms have I opened?
NR says to run npm audit fix to resolve the problems/warnings/incompatibilities.... What ever...

So I seemed to have opened another can of worms.

Now -
I have a couple of machines which are not up to date with rbe.
I see (from dceejay) that I don't need to update them as the update was to do with Japanese locale stuff. Good.
The "twitter", "email" (don't know why I forgot that one), "feed-parser", "ping", "serial-port" and a couple of others are not up to date.

I get that NR is an "amalgamation" of programs/stuff to make the bigger thing.
But I am at a loss why "twitter" can't be removed/un-installed. As I don't need/use it (I hope I never need it.) Having it in the package is leaving an attack vector open. Isn't it?
Sure, I can/will get around to disabling it soon.

Looking at the bigger picture:
So with NR 2.x coming soon and the dependency on the earlier stuff (node.js) will be removed....
That will fix the update stuff?

I'd better stop here. I am becoming distracted/disoriented to where I am wanting to go and where I am going.

But this is also (I hope) an external view of how this (what ever "this" is) happened and maybe a bit of help to anyone else like me: a noob.

15

It is not me saying that. I pointed you to thread consisting of three posts, the last of which said that it is not advisable to run audit.

I think you are confused about where those messages come from. When you use the command npm to update or install a node then you are not using a utility provided by the node-red developers, it is a general purpose tool provided with node.js. I agree with you that the messages npm produces can be confusing. I think there have been several decisions made by the npm developers which are less than ideal, for example the fact that a recent update deleted without warning all the locally installed nodes that were not specified in package.json. In fact I think it would be better if any npm command that is going to install or remove nodes should have the option of prompting the user with a description of what it is going to do and asking for y/n before proceeding. I can't see a command line switch to do that though. Also there does not seem to be a log of exactly what it did to make it easier to recover from accidents. However there is no point complaining about that here, that would have to be done in an npm forum.

16

That came from me and it was my recommendation not to run it. But it is important to understand why I recommended that.

In order to make sense of npm, you need to understand also about something called "semver" - Semantic Versioning.

https://docs.npmjs.com/getting-started/semantic-versioning

Simply, that means that the version numbering that developers use should have a meaning. Typically, if you have a Node.JS module with a version 1.0.0, it should change to 1.0.1 if there is a minor change - a small bugfix for example. If a new feature is added but it is backward compatible then the version would become 1.1.0. But if there are changes that mean that some features no longer work the same way - they are not backward compatible - then it should become 2.0.0.

So my comment was that if you run npm audit, you will see that some of the modules have changed major versions meaning they are no longer backward compatible. This means that it is possible that some Node-RED nodes that use those modules might break.

And so the recommendation not to try to use audit fix. Audit fix cannot be done against specific packages either, it is all or nothing. You are welcome to try it but it may break your Node-RED installation.

17

This happens to all of us from time-to-time.

If I were you, I would be thinking about whether it was time to do a full reinstall of my Pi's. I've occasionally done that and it can really help tidy things up and get rid of niggly problems. You will have learned a lot since you started and would be most likely able to install things in a lot tidier fashion now. Thankfully, this is fairly easy to do on the Pi. Though it will help if you've kept notes on what you've installed and how you've configured it.

If you decide not to reinstall completely, it may be useful to take Node-RED out and start again at least.

However, you may decide that you've got things sorted now and don't need to do any of that. At the least though, now would be a good time to work out what settings and other things you should be backing up and make sure that you are doing so. A good backup is always essential before making any big changes.

1 Like
18

... although I don't know what you are using the 9 pi's for, is there an opportunity to combine functions so you could reduce the number of pi's that you need to update/maintain (and also reduce your energy footprint).
I'm just using one pi, which I use as a file server, a media player for both audio & video, energy & weather display and storage, a lighting controller, home security, the list goes on...

19

Hopefully you mean version 0.20.0... we are are a long way from version 2.0... (see comments re semantic versioning above)... they are completely different :slight_smile:

What it will do is update all the core nodes to the latest levels at that time - and also any of their dependencies. What it won't do is update any extra nodes you may have installed or their dependencies.

Obviously that is still a point in time statement and (say) two months later on some new vulnerabilities may have been found. So the situation will remain until 0.20.v+1 or 0.21.v+1 whatever number v is at the time.

20

Would it be practical to get some sort of indication in the Palette as to which nodes are ones installed with node-red, and therefore should not normally be updated from there, if at all.