Re: Oops, especially for Oracle
@Anonymous Coward said: "I can't say I'm surprised about Python; ... the lack of static typing probably makes security testing much harder."
You may wish to consider how the Python version of the bug is much less severe than the Java version before jumping to any conclusions. The great degree to which Python is dynamic makes testing easier, not harder.
Relying on compiler type checking to find your bugs is horribly insecure. That's not what it's there for. It exists to give the compiler hints about the data so that it can generate more efficient code. With this type of application all the relevant user data are byte streams, and that is all the compiler would know. To find this sort of bug, you need to test, test, test, and then test some more using automated tests.
There is a bug opened on the Python bug tracker related to the post linked in the story. The bug initiator has looked at the FTP spec and apparently the problem is inherent in the FTP spec. The solution may be to raise an exception if CWD commands contain any blacklisted characters, but it's hard to know if that will work with all legitimate FTP servers.
The Java exploit sounds like the more serious problem of the two, as Java (unlike Python) is installed in a lot of web browsers.
For a vulnerable Python client, you would need to be using something like some sort of web crawler that uses urllib. For that sort of application you are more likely to be using either the "requests" library or something like "Twisted" rather than rolling your own using urllib.
If you are using "urllib" and you don't need to handle FTP, then at the application level you might simply replace the default FTP handler with something that raises an exception. That may be as simple as writing a class with the same interface as the FTP handler that simply does nothing other than raise an exception (to give you reasonable log messages). Then it should simply be one line of code to point the the FTP handler to your own class instead of at the default one. If you do need to handle FTP as well as HTTP, you could do something similar to insert your own filter before deciding whether to pass the request on to the FTP library. And if you don't need all the automatic bells and whistles in urllib and just need basic HTTP (or HTTPS), then why not simply call the relevant standard protocol library directly instead of going through urllib?
Since the bug seems to be inherent in the FTP spec (when combined with NAT and permissive firewalls), I would not be surprised if the same problem were to be found in libraries used with many other programming languages.