Java and Python have unpatched firewall-crossing FTP SNAFU Stop us if you've heard this one: Java and Python have a bug you can exploit to cross firewalls. Since neither are yet patched, it might be a good day to nag your developers for a bit. The Java vulnerability means protocol injection through its FTP implementation can fool a firewall into allowing TCP connections from the …
The internal developer training and security standards in Oracle were very clear, all inputs must be validated, and some of this training is several years old, so they had no excuses! Probably part of the reason is because some of the library code has been left rotting since Sun years and was still not modularised/modernised in Java 8, the last time I looked at the JDK source; it was easy to find the code rot with OSS static code checkers. I've even spotted dubious code in some of the issued JDK 8 demo code.
I can't say I'm surprised about Python; the way it does some stuff looks inherently insecure, and the lack of static typing probably makes security testing much harder.
@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.
The Java exploit sounds like the more serious problem of the two, as Java (unlike Python) is installed in a lot of web browsers.
Possibly not, as I don't think the SecurityManager would allow FTP connections from code running as an Applet. See the places in the relevant Java library code where I/O related stuff is wrapped in calls to AccessController.doPrivileged().
I can't say I'm surprised about Python; the way it does some stuff looks inherently insecure, and the lack of static typing probably makes security testing much harder.
The relatively low number of CVEs listed for Python would suggest that your hunch is ill-founded.
As thames says, static typing doesn't really help you when it comes to security testing, which is usually about handling conditions, including stuff in the protocols, you didn't plan for. In the right situation Java will be just as dynamic as Python. Gary Bernhardt's comparison is worth watching.
Security testing never ends: there will always be new exploits because there's always something you haven't thought of. The important thing is how we as developers respond when informed that our software is vulnerable. Personally, I've already fixed a potential XXE vulnerability this year. What have you done?
... same problem. Corporate says you can't look at other people's implementations lest we get sued. The self-confident say the standards docs are all I need to code this easy protocol. Only later do they look at other implementations and realize they didn't know the half of it.
If you are coding for you - only - go ahead and ignore the rest of the world's experiences. If you are coding for others, for correctness, or for the long-term, consult at least a few other implementations to find the corner cases you never would have thought of in a thousand years.
The last three times Apple has screwed up a date/time transition or computation proved that they never thought to check non-Apple sources. Almost anybody else's code would have opened their eyes.
Whether you find the language disagreeable or not, if you doubt the utility of checking the second oldest continually maintained network protocol libraries, on CPAN, you're being [[see title]].
One of the linked articles suggests most firewalls permit classic FTP by default. In my experience, almost no firewalls allow classic FTP through without additional rules to allow the dynamic port range and require the use of passive FTP. Classic FTP is known to be vulnerable to this type of client attack which is why firewalls force applications to use passive mode.
In addition, getting an FTP server to connect to a port less than 1023 for SMTP access shouldn't be permitted on any FTP server less than 20 years old - that was known to be a bad idea even on internal networks.
I.e. Is this an actual vulnerability or a demonstration that a poorly configured firewall doesn't protect a FTP server that could be poorly configured to allow access to other applications? A well configured firewall would only permit access to tcp/21 and restrict access from the untrusted side to the trusted side by default resulting in active connections being dropped when they attempt to establish a new connection inbound on an unknown port.
I'm a bit puzzled by the presence of FTP at all.
I don't run FTP as it requires near-cleartext logon credentials to travel over the network which is easy to sniff for even the most inexperienced of beginner. As far as I can tell, SFTP (basically SSH in file transfer mode) does not display this specific problem, especially not if you lock it down with certificate-only authentication. If we want to offer a file publicly it'll exported to a webserver that remains otherwise isolated from the main network.
That said, even for personal use I benefit from an ISP who has since long seen the light on security for website uploads and thus makes SFTP possible which is directly supported by tools such as FileZilla, Cyber Duck and even Mountain Duck (you can just mount an SFTP source as if it's a drive).
Not all service providers have yet arrived at that point.
Regarding SFTP, it doesn't have the control+data connection issue that FTP has, so you are correct in that it doesn't have the same compromise.
And yes, sending authentication credentials/data in plaintext via FTP when there are perfectly good alternatives that provide secure transfers isn't very wise and I'm sure auditors would love to know about it...
Regarding support by default for "classic" FTP, Timothy Morgan's blog post suggests it is common. In particular I think it is basically guaranteed for any consumer-grade equipment.
I think you missed that the SMTP vulnerability is about getting the *client* to initiate a control channel connection to port 25. Of course, this is just an example; any protocol/implementation tolerant of initial FTP chatter could be abused, unless (a) there is a firewall between the endpoints (quite possibly not for other "internal" hosts), and (b) it's blocked at the firewall (unlikely by default for consumer-grade equipment).
I'd say there are various ways to exploit this. Java being less likely to be installed on home machines may be the only thing stopping this being a major problem.
Agreed. The 1990's called and they want their exploit back. It sounds like a variation of the FTP Bounce attack way back when. The great part, though, is that many system and "security" admins are too young to remember those good old days or they're just GUI Drivers. If the GUI let's you do it, it must be OK. That's why things we thought we eradicated decades ago are showing up in code today. Kill off something in IPv4 and some new kid comes by and allows it in IPv6. <sigh>
Who the heck would ever write an FTP server in Java anyway? Certainly not Unbreakable Oracle!
"The Java vulnerability means protocol injection through its FTP implementation can fool a firewall into allowing TCP connections from the Internet to hosts on the inside."
I was going to say, surely this is a firewall vulnerability primarily? If this can be done by abusing the FTP protocol then clearly it can be achieved using other methods as well?
Does sound like a dodgy implementation of FTP though which needs sorting out. There is an interesting write-up of different Java implementations of FTP here -> http://www.javaworld.com/article/2073325/java-app-dev/java-ftp-client-libraries-reviewed.html ... which mentions that there is more than implementation in the JDK (one public, one internal and undocumented)
Given FTP's pretty widespread the former is going to be tough to fix. The latter rather less so.
Obvious I know but is this yet another example of why web external (and most internal) web servers should all services not directly and immediately needed to be either switched off or removed entirely?
Unless I've misunderstood there is no actual FTP server involved here. A URL is being crafted as if it were an FTP url but in fact points to an SMTP server rather than an FTP one, and the username embedded within the URL contains rather more than a username.
The bug is in the java code connecting to the URL, which assumes it is talking to an FTP server, when it's not, and as the article says, doesn't validate that username string.
Even the firewall is not guilty of passing FTP traffic, as there is no actual FTP traffic and the port would have to be the SMTP one.
So basically the java bug is that it doesn't properly validate DTD urls embeded in XML that is parsed with the java xml parser, which may cause it to blindly attempt to open an ftp connection to an smtp server if you abuse this ultimately opening you up to sending spam. So, maybe don't run an open smtp server and certainly not on your app server. Certainly would be nice for Oracle to patch this up but I don't think this will cause a lot of people to panic.
Running an smtp server and then not setting it up properly is in itself a bad idea. Honestly, you are better off using any of a wide range of hosted email solutions for programmatically sending email. Without an open smpt server on a known address, this is going to be hard to exploit.
I work for a small bank (Well, technically a Credit Union). They built their original infrastructure on top of several old HP 9000/T520 systems. They also created an online-banking system on those systems as well. That infrastructure and online banking site is still fully operational. The whole thing works on HTML with content created by C-based CGIs (The CGIs generate the HTML based on the user inputs).
It's been running smoothly since 1995 with minor upgrades to support new security standards (All https, TLS1.2 with SSL disabled, a simple two-factor authentication system implemented).
It still baffles me at how often people over-design things to the point of becoming over-complicated, where half the infrastructure exists only to support the other half. So many times I see people metaphorically build a hydrogen bomb when all they needed was a fly swatter. At least that is what I tend to feel when I see public facing websites that obviously use something like Java to generate content (the payment system for Sprint even shows the Sun Microsystems Logo as the Favicon for the page...).
But then, a lot of the technology sector is now based on "because we can" rather than what would actually make our lives better.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
