• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 99 subscribers
  • Views 3926 views
  • Users 0 members are here
Options
Related

Security issues with npm dependencies in Operations Support Portal?

sebastian.eberhard
over 2 years ago

Hi,

the Operations Support Portal and also API Server UI have dependencies to NPM packages. (KB 266000)

Recently, popular npm libraries, such as ua-parser, rc and coa were hijacked and infected with malware. 

See Embedded Malware in NPM: Coa, Rc, Ua-parser - FOSSA, Unbekannte infiltrieren Paketmanager npm und verseuchen Tools mit Schadcode | heise online

If packages used by One Identity HTML5 applications were compromised, our fear is that we might be using those packages when compiling One Identity Manager HTML 5 applications. This would compromise the security and integrity of our OIM customer installation, as well as potentially our systems and data. 

We are not experts in npm security. Therefore, as One Identity seems to shift more and more to HTML 5, we have the following questions:

- Is that a risk for OIM customers at all?

- If so, how do you mitigate security and integrity risks for npm packages compiled into OIM?

- How is One Identity protecting customers?

Thanks,

Sebastian

Parents
  • 0 over 2 years ago

    First of all there is to mention that we have a secure build process to ensure as much integrity as possible. More details can be obtained via our Security Director at One Identity.

    Part of this is a software compoistion scanning process, that is run with every bulld and keeps us notified constantly. There are goals defined for delivering fixes to such findings in a certain amount of days.

    Regarding the latest issue: In fact coa is part of the npm package dependcy list of our new web ui. In the specific coa case that just happened recently we were pinning the npm package to the latest not infected version (2.0.2). So nothing to do for us.

  • 0 over 2 years ago in reply to Matthias.Bauer

    We have investigated this issue with the 8.1 release. We have verified that the 8.1 HTML5 compilation process does not install any of the "rc", "ua-parser" or "coa" packages in any version.

    See npm's official advisory here:

    https://github.com/advisories/GHSA-g2q5-5433-rhrf

    One small addition regarding the last paragraph of Matthias' post; "coa" is indeed part of the build process for 8.2, but in a known-good version.

    To globally disable compilation of the Operations Support Portal HTML5 application, you can disable the QBM\HtmlDevelopment\Compiler configuration parameter.

  • 0 over 2 years ago in reply to Hanno Bunjes
    I think you don't get the importance we see here. Supply chain attacks like these are very common, are on the rise, and have a huge impact.

    Most of the time, there are "fuzzy version declarations" (^ and ~) in the package.json files, e.g. "^2.5.3" (means "2.5.3", "2.5.4", "2.6.2", ...but not "3.0.0"), or "~2.5.3" (means "2.5.3", "2.5.4", ...but not "2.6.0"). And that is true for your package.json as well as the package.json of every dependency.
    So even if you stick to fixed versions in your package, you get minor patches from your subdependencies.

    That's the whole reason behind the package.json.lock file (that you are explicitly switched off in .npmrc of QBM\install\bin\QBM\ApiServerWebUi, QBM\install\bin\QBM\OpsWeb, and {AppData}\ApiDesigner\ApiResources\imx-api). With a lock-file you can pin the versions of the complete dependency tree you have tested and make sure, we customers all install the very same versions.

    If I had a fresh npm install last week (just before the npm advisory was released), and any subdependency had a dependency to coa in version "^2.0.0", I would have got coa in the hijacked version "2.0.3" (and executed its install scripts with the same permissions that the caller of npm install has). So yes, this is critical.

    The compromised versions are withdrawn at the moment of the release of the advisory - so every analysis of this in the aftermath is not meaningful enough - you have to look at the version string in the package.json (I can't say that for v8.2). If you are looking now, you will always see the harmless versions.
    It's all about the time between the publication of a compromised version (of literally any package) and the proper advisory report. Once you install such a package it is already too late.

    And no, we don't want to switch off the compilation process (we are looking forward to version 8.2 and its new shop) - but we don't want to have malware, too. As I can see, even with disabled QBM\HtmlDevelopment\Compiler, you will execute npm install/npm run build while compiling API projects (imx-api).
    Thus we are trying to minimize the threat. Therefore Sebastians and my questions.

    I even go a bit further and ask you to investigate the use of npm install --ignore-scripts (maybe it's sufficiant for the builds) and the use of the package.json.lock file/npm ci. Only with this sticking/pinning of versions your internal tests are relevant for your customers at all (and with npm ci it could be even much faster).

    The other questions (especially docker) are still open, while the first question from Sebastian is clearly answered: yes - it's a threat.
  • 0 over 2 years ago in reply to wolfgang.kluge

    The reason we have not fully activated package locking in 8.1 is that we are on a version of nodeJS that has known issues with package locking. And nodeJS is tied to a specific Angular version (range).

    We have to evaluate the options at hand on how to remediate this problem. But I agree that upgrading to full package locking -including all sub dependencies- this would be the most desirable option for the 8.1 build process.

    We have looked at --ignore-scripts. Unfortunately it does not help, as some packages still rely on install scripts.

Reply
  • 0 over 2 years ago in reply to wolfgang.kluge

    The reason we have not fully activated package locking in 8.1 is that we are on a version of nodeJS that has known issues with package locking. And nodeJS is tied to a specific Angular version (range).

    We have to evaluate the options at hand on how to remediate this problem. But I agree that upgrading to full package locking -including all sub dependencies- this would be the most desirable option for the 8.1 build process.

    We have looked at --ignore-scripts. Unfortunately it does not help, as some packages still rely on install scripts.

Children