ini 1.3.5 - dependency vulnerability in npm audit

[zhuweid]

after running npm audit, there is one vulnerability found in @datorama/akita": "6.2.0"

"1589": {
"findings": [
{
"version": "1.3.5",
"paths": [
"@datorama/akita>schematics-utilities>@schematics/update>ini"
]
}
],
"id": 1589,
"created": "2020-12-09T22:25:48.568Z",
"updated": "2020-12-10T16:49:29.595Z",
"deleted": null,
"title": "Prototype Pollution",
"found_by": {
"link": "",
"name": "Anonymous",
"email": ""
},
"reported_by": {
"link": "",
"name": "Gur Shafriri",
"email": ""
},
"module_name": "ini",
"cves": [],
"vulnerable_versions": "<1.3.6",
"patched_versions": ">1.3.6",
"overview": "ini before version 1.3.6 has a Prototype Pollution vulnerability.\n\n### Impact\n\nIf an attacker submits a malicious INI file to an application that parses it with ini.parse, they will pollute the prototype on the application. This can be exploited further depending on the context.\n\n### Patches\n\nThis has been patched in 1.3.6\n\n### Steps to reproduce\n\npayload.ini\n\n[__proto__]\npolluted = \"polluted\"\n\n\npoc.js:\n\nvar fs = require('fs')\nvar ini = require('ini')\n\nvar parsed = ini.parse(fs.readFileSync('./payload.ini', 'utf-8'))\nconsole.log(parsed)\nconsole.log(parsed.__proto__)\nconsole.log(polluted)\n\n\n\n> node poc.js\n{}\n{ polluted: 'polluted' }\n{ polluted: 'polluted' }\npolluted\n\n",
"recommendation": "Upgrade to version 1.3.6 or later.",
"references": "- Fix Commit\n- GitHub Advisory",
"access": "public",
"severity": "low",
"cwe": "CWE-471",
"metadata": {
"module_type": "",
"exploitability": 3,
"affected_components": ""
},
"url": "https://npmjs.com/advisories/1589"
},

can we upgrade the ini to a newer version > 1.3.6 to fix this issue?

[cnestor1]

Any update on that issue found in the latest Akita lib version 7.1.1:

[nunoarruda]

I have the same issue:

@NetanelBasal is there something you can do about this? I would prefer to use the latest version of Akita instead of downgrading.

[NetanelBasal]

You're welcome to submit a PR

[cnestor1]

The problem is that schematics.utilities depends on schematics.update and schematics.update has been deprecated:
This package is deprecated and will not be updated beyond Angular v11 (0.1102.x). It should no longer be used..

Looks like the schematics.utilities team is aware of that but doesn't have a solution either:
nitayneeman/schematics-utilities#49

Doesn't seem to be an easy one to solve but would definitely cause a security issue for whoever downloads the schematics.update module and uses Angular 13. (weekly download 1,007,298!)

[NetanelBasal]

For these reasons, I decided not to use schematics anymore in Elf.

[cnestor1]

@NetanelBasal Is Elf the latest version of Akita? Any targeted date?
Thank you.

[NetanelBasal]

https://ngneat.github.io/elf/

[cnestor1]

So if I understand correctly, you are replacing Schematics-utilities with Elf although I don't see any relevance between the two.
To get a sense for it, in which 2022 quarter do you project to have that completed?
Thx fort a great Library!

[zhuweid]

@NetanelBasal my understanding is Elf does not have this issue, and it is recommended to switch to elf from akita?

And I guess the syntax of elf is similar with akita and the migration effort is low?

[NetanelBasal]

Correct

[cnestor1]

@NetanelBasal
Ok, I see now. It looks like all my questions have been answered here

What About Akita?[​](https://ngneat.github.io/elf/docs/faq#what-about-akita)
Akita is still actively maintained. Elf is merely another option. Furthermore, Akita is Datorama driven, and therefore performing significant changes was difficult. Elf was created to be more community-driven. See the [comment](https://github.com/ngneat/elf/discussions/5#discussioncomment-1437641) for more information.

So Akita will be deprecated since there is no resolution for this security issue. I have no issue migrating to Elf besides the fact this is an unplanned effort...

Any migration documentation from Akita to Elf or store conversion example available?

[NetanelBasal]

This is not related to the security issue. Elf is similar to Akita. The migration should be easy.

[ZanMarolt]

Would it be possible to remove schematics from akita all together for ng v13? 🤔 We have this security issue as well, and for the size of our application migrating to elf is not that straightforward 😐

[NetanelBasal]

That means we remove the schematics feature from Akita. You'll need to create all the code manually instead of using the generators.

[NetanelBasal]

To be honest I don't see how this affects your application. https://overreacted.io/npm-audit-broken-by-design/

[zhuweid]

currently @schematics/[email protected] has 3 vulnerabilities, they are Y18n, Ini and Tar 4.4.13.
We have been talking with our Security Officers and they seem to be fine with Y18n and Ini. However they have concern about Tar.

@datorama/[email protected]
└─┬ [email protected]
└─┬ @schematics/[email protected]
└─┬ [email protected]
└── [email protected]

@NetanelBasal , can I ask if schematics/update is only used as the code generator during dev time? If that is the case, we can safely ignore those issues.

[ZanMarolt]

Yes, @zhuweid it is only used during development and not shipped to production. But I still think upgrading the packages and staying up to date is the ideal scenario regardless

[NetanelBasal]

@ZanMarolt of course, when you control it :)

[ZanMarolt]

Yeah, I am in no way trying to put the blame on the akita team or you @NetanelBasal. I am actually forever grateful for the awesome project and ongoing support, just trying to find a solution and possibly fix it myself.

@NetanelBasal do you see some alternatives for the schematics package?

[NetanelBasal]

Yes, we can use a native CLI as I did with Elf, but it will take time to develop it.

[NetanelBasal]

You can also create a post-script that deletes schematics and use https://datorama.github.io/akita/docs/enhancers/cli/

[SchVladyslav]

Hi @NetanelBasal !
Could you explain what you mean by creating a post-script that deletes schematics, please? I mean some examples, how to do it.
It sounds useful for big projects which don't plan migration.

[vipina1019]

Any update on this issue? I am facing vulnerability with ini 1.3.5 .

[butcher51]

I'm also waiting for the fix. Btw, does anyone tried to fix this with the npm overrides option? I couldn't solve with it but theoretically it should work somehow.

[ftadra]

One solution is to just override the ini version being used by one that doesn't present the vulnerability in your package.json

"overrides": { "ini": "^1.3.7" },

[NetanelBasal]

The repo is updated now. I'll release new versions soon.