• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 99 subscribers
  • Views 3925 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.

  • 0 over 2 years ago in reply to Hanno Bunjes

    Hanno,

    thanks for the clarification.

    We noticed that the during compilation of the API itself, npm is being used, too. According to our tests, a connection to npm is needed to compile the API.

    How can we make sure that no security issues are introduced this way?

    How do you notify customers if there is a risk?

    What measures are you taking to protect customers?

    Thanks,

    Sebastian

  • 0 over 2 years ago in reply to Hanno Bunjes

    Following up on this discussion, we are providing an update that enhances package locking for the compilation processes. You can also contact support to obtain this update, referencing issue number 35119.

    As stated previously, there are also two alternate options to consider:

    1) install an offline NPM proxy for the compilation, which will prevent any outside connections to NPM.
    2) upgrading to 8.2 removes the requirement for NPM-based compilation when updating the system.

  • 0 over 2 years ago in reply to Hanno Bunjes

    Hallo Hanno

    Kannst du mir sagen wie das in 8.2 läuft. Hab das gleiche Problem wie oben beschrieben. Brauch eine Offline Variante. Kunde kann die Ports nicht öffnen. Danke für deine Hilfe

  • 0 over 2 years ago in reply to pvonarx

    Hallo,

    However, in 8.2 compilation does not require NPM access unless the customer has built a custom HTML app.

    In this case, please refer to this KB article: https://support.oneidentity.com/identity-manager/kb/266000/npm-dependencies-for-new-dbcompiler-options-api-project-compilation-and-html-applications-in-8-1 for offline compilation options.

    Hope this helps

    Hanno

  • 0 over 2 years ago in reply to Hanno Bunjes

    Hello Hanno

    This i saw already.. but also a proxy is a potential risk for malware and attack see top.. the customer needs a full offline compile.. is that possible? if not is it planned to come?

    Thanks for your help

    kind regards

  • 0 over 2 years ago in reply to pvonarx

    No, because at some point you need to load the packages from npm. We will never ship all the required packages as part of Identity Manager.

    The package locking mechanism protects against the risk of compromised packages. What is the malware scenario?

  • 0 over 2 years ago in reply to Hanno Bunjes

    Ok.. but a proxy prevents not from malware etc. risk it's only a buffer but the Server connected to the proxy is still taking the npm that is there if has malware or not.. hope only that the customer knows fast enough that the npm has malware before compiling with the proxy.. So in my opinion the main problem is not solved only 1 server in between.

    Can you explain me what is so difficult to do a full npm package .. normally customer needs not always the newest version only if you change mechanisms that work only on a newer version

  • 0 over 2 years ago in reply to pvonarx

    What you describe cannot happen due to package locking. OneIM expects a specific version of a package with a unique hash. If it finds a package containing malware, the hashes will not match and NodeJS will refuse to load the compromised package.

    This has nothing to do with having an NPM proxy or not.

Reply
  • 0 over 2 years ago in reply to pvonarx

    What you describe cannot happen due to package locking. OneIM expects a specific version of a package with a unique hash. If it finds a package containing malware, the hashes will not match and NodeJS will refuse to load the compromised package.

    This has nothing to do with having an NPM proxy or not.

Children
No Data