Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plan to fix CVE-2022-30284 [Critical] - python-libnmap 0.7.2 ? #131

Closed
ajaySec opened this issue May 17, 2022 · 3 comments · Fixed by #133
Closed

Any plan to fix CVE-2022-30284 [Critical] - python-libnmap 0.7.2 ? #131

ajaySec opened this issue May 17, 2022 · 3 comments · Fixed by #133

Comments

@ajaySec
Copy link

ajaySec commented May 17, 2022

Would like to know if there is any plan on fixing CVE-2022-30284 in python-libnmap pack 0.7.2 for Python ? This library is part of scheduled network scan in my org so require action on this

@underdarknl
Copy link

underdarknl commented Jun 3, 2022

It looks like there is no active maintenance on this module at the moment, as no valid commits have been made for about a year, and obvious issues (black issue) on the last commits have not been addressed.
It looks like a fork would be useful at this point. Seeing that this lib also contains a whole lot of application code its not really a lib anymore, and would benefit from being a little bit smaller and broken into smaller parts.

Judging by the response noted on the CVE page, a fix is not forthcoming.

NOTE: the vendor believes it would be unrealistic for an application to call NmapProcess with arguments taken from input data that arrived over an untrusted network, and thus the CVSS score corresponds to an unrealistic use case. None of the NmapProcess documentation implies that this is an expected use case.

Seeing that the author feels no need to mitigate against this very easily exploited issue should send shockwaves to any user of this lib.

@savon-noir
Copy link
Owner

Just a note here, I don't exactly know where this dispute quote comes from but these are not my words. When the bug hunter found the issue, I've accepted it as a security issue but could not provide a fix short/mid-term. Since he was waiting for publication of the issue I said the following:

Bug hunter: "Ok, I'm waiting for the new release."
Yours truly: "ok, but you can already apply for cve and disclose if you want. its not really a problem. I think there are enough means to ensure proper inputs are passed to the lib if being used otherwise."

Which translates to: since this lib (or helper if you prefer to call it like that) would most likely be interfaced, filtering should be straight forward for the developers using it.

Hope it clarifies.

@savon-noir
Copy link
Owner

It looks like a fork would be useful at this point. Seeing that this lib also contains a whole lot of application code its not really a lib anymore, and would benefit from being a little bit smaller and broken into smaller parts.

@underdarknl interesting proposal! Now the world is waiting for your PR and/or your refactoring of the lib/helper. Keep me posted on your progresses.

regards,
Ronald

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants