[
https://issues.apache.org/jira/browse/IO-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482826#comment-16482826
]
Gregg Yost commented on IO-559:
-------------------------------
It is in fact IO-556 that the Black Duck vulnerability report refers to, and
IO-556 was marked as a duplicate of this issue. Black Duck uses various
sources for the vulnerabilities that it reports, and this one came from the
VulnDB database, which I think is proprietary. But if you have access to it,
the VulnDB issue id is 177199. I don't have direct access to VulnDB myself, I
am only seeing this indirectly though Black Duck. Black Duck is associating
this VulnDB issue with Commons IO versions 2.2 through 2.6.
The issue description in Black Duck says that the flaw allows traversing
outside of a restricted path, and that the issue is due to
FileNameUtils.normalize not properly sanitizing user input, specifically path
traversal style attacks (e.g. '../'). It goes on to say that with a specially
crafted request, a remote attacker can disclose arbitrary files.
I understand the Commons community's position regarding validating filenames
that originate from untrusted sources. On the other hand, few developers know
how to write abuse-proof code for handling file paths, and so lots of us rely
on popular third-party packages and the fact that those packages get analyzed
by software such as Black Duck. So anything that the Commons community does to
help harden against security vulnerabilities is a great service to the world,
and I appreciate you taking the time to push for peer review of your pull
request.
> FilenameUtils.normalize should verify hostname syntax in UNC path
> -----------------------------------------------------------------
>
> Key: IO-559
> URL: https://issues.apache.org/jira/browse/IO-559
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 2.6
> Reporter: Stefan Bodewig
> Priority: Major
>
> {{FilenameUtils.normalize}} will accept broken file names as UNC path even if
> their hostname part doesn't match the syntax of a proper hostname. Using
> certain hostnames like "." this may lead to strange side effects.
> Most likely the best fix will be to make {{getPrefixLength}} verify the
> hostname part of a suspected UNC path and return a value of {{NOT_FOUND}} if
> it is not a valid hostname - much like it does for triple slashes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
