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

Review vulnerabilities report #914

Closed
pavel-shelentsov opened this issue Jan 31, 2018 · 5 comments
Closed

Review vulnerabilities report #914

pavel-shelentsov opened this issue Jan 31, 2018 · 5 comments

Comments

@pavel-shelentsov
Copy link
Contributor

Hello,
We scanned JNA 4.5.1 artifact using static veracode analyzer and possible found some vulnerabilities.
Part of these have very-high severity level, these can be false positive, but need to be checked.

I attached detailed vulnerabilities report to the issue: jna_4.5.1_report.pdf

@matthiasblaesing
Copy link
Member

Thank you for your interest, but I think the report is indeed mistaken:
#114: "untrusted input passed to System.load": This is the whole point of the library to load developer specified ("the user") libraries. If the developer allowed an external source to control paths and library names, its a problem of the user.
#73: "External Control of File Name or Path" Same reasoning applies - the paths are either hardcoded, system properteries or user controled paths (this is intended)
#377: "Insecure Temporary File": It could be checked if the NIO variant is saver and still works.
#404: "Improper Resource Shutdown or Release" is valid - the resource is not properly closed if an exception occurs.

Labeling as feature request.

@nextgens
Copy link

nextgens commented Jul 7, 2018

Respectfully, I don't think it is. The code as is does not guarantee to the user that the library that will be loaded is the one that was intended to be loaded (it could be planted by an attacker at the "well known location" jna loads it from)... and this is why it is a security vulnerability.

As far as I know, it is non-straightforward to guarantee that this doesn't happen in Java... but improving upon the status quo is trivial and starts with introducing some randomness (something unpredictable to the attacker) in the temporary folder JNA operates from.

@matthiasblaesing
Copy link
Member

With #917 applied, all that still applies and is a confirmed potential security problem (which can be trivially worked around by JNA users) is now separatedy ly tracked as #985. So closing this issue.

@typelogic
Copy link

Is there a signature checksum check of the native library?

@matthiasblaesing
Copy link
Member

@typelogic please don't hijack random issue. The issue template mentions, that questions should be directed to the mailinglist.

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

No branches or pull requests

4 participants