dxbjavid commented on PR #403: URL: https://github.com/apache/commons-net/pull/403#issuecomment-4886586515
right, that null is the parserKey argument, and it's actually the null that makes this reachable. when createParser gets a null key it falls through to the autodetect branch (the else at ~1236 in FTPClient): it calls getSystemTypeOverride(), which with no FTP_SYSTEM_TYPE property set just returns getSystemType(), and that's the server's SYST reply, _replyLines.get(last).substring(4). that string is then passed straight into createFileEntryParser(systemType). so the value that reaches the factory isn't null, it's whatever the server put in its SYST response. normal servers answer UNIX/WINDOWS/etc and hit the alias path, but if a server replies to SYST with something shaped like a qualified class name (say some.pkg.Foo) it matches JAVA_QUALIFIED_NAME_PATTERN and goes down the Class.forName branch instead. nothing constrains the SYST text to the known aliases. full chain for listFiles(path): initiateListParsing(null, path) -> createParser(null) -> else/autodetect -> getSystemTypeOverride() -> getSystemType() -> SYST reply substring(4) -> createFileEntryParser(systemType). as noted it's narrow (needs a class already on the client classpath with a side effect in its static block), so it's more defence-in-depth than a sharp vuln, but loading without init keeps a remote SYST reply from initialising unrelated classes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
