WatchGuard is very pleased to announce that Fireware XTM 11.3.3, the latest operating system for our Firebox X e-Series appliances, is now available for download.
XTM 11.3.3 is a maintenance release that demonstrates WatchGuard’s commitment to quality, with a significant number of bug fixes and enhancements.
Please note, the 11.3.3 firmware is only intended for e-Series hardware. XTM appliance owners should install 11.4, or continue using 11.3.2 or lower. There is no new WatchGuard System Manager release for Fireware XTM v11.3.3. You can use either WatchGuard System Manager v11.4 or WatchGuard System Manager v11.3.2 to connect to a Firebox e-Series device that runs Fireware XTM v11.3.3, although you must use WatchGuard System Manager v11.4 if you want to configure FireCluster in drop-in mode.
XTM 11.3.3’s primary enhancements include:
- Ability to configure proxy settings from the Fireware XTM Web UI
- Support for active/passive FireCluster in drop-in mode (with 11.4 WSM only)
Some XTM 11.3.3 fixes of note include:
- The OpenSSL package used on Firebox devices has been upgraded to 0.9.8o to resolve several reported vulnerabilities.
- Server load balancing and policy-based routing no longer stops working when your LiveSecurity subscription expires.
- Single Sign-On accuracy and scalability has been improved.
- You can now import the WatchGuard Products MIB without errors.
- XTM 11.3.3 now includes CLI commands that enable you to see the number of concurrent connections through your Firebox.
- You can now use addresses from a drop-in network as Mobile VPN (IPSec and SSL) pool addresses.
- File transfer through the SIP proxy no longer fails in hairpin configurations.
- You can now bridge wireless to a trusted or optional interface that is bridged to another trusted or optional interface.
- WatchGuard log traffic, syslog traffic, and Single Sign-On authentication requests are now correctly routed through VPN tunnels.
- …and many other fixes — please see the Release Notes for complete details.
If you’re an active e-Series LiveSecurity subscriber, you can upgrade to Fireware XTM 11.3.3 free of charge.
NOTE: Besides posting Software Update announcements to the WatchGuard Security Center, we typically also email Software Update alerts directly to our customers base. However, due to some list maintenance, we may not be able to send our typical direct announcement for awhile.
Does This Release Pertain to Me?
Fireware XTM 11.3.3 is a maintenance release that contains a significant number of bug fixes and enhancements. If you have any Firebox e-Series appliances, and wish to take advantage of any of the enhancements listed above, or those mentioned in the Release Notes, you should consider upgrading to version 11.3.3. However, XTM appliance owners should not install 11.3.3, but rather stick with 11.4 or earlier 11.3.x releases. Please read the Release Notes before you upgrade, to understand what’s involved.
How Do I Get the Release?
Firebox e-Series owners who have a current LiveSecurity Service subscription can obtain this update without additional charge by downloading the applicable packages from the Software Downloads web page, which also includes clear installation instructions. As always, if you need support, please enter a support incident online or call our support staff directly. (When you contact Technical Support, please have your registered Product Serial Number, LiveSecurity Key, or Partner ID available.)
- U.S. End Users: 877.232.3531
- International End Users: +1.206.613.0456
- Authorized WatchGuard Resellers: +1.206.521.8375
Feb 16th, you reported 21 security vulnerabilities with java, and now the the latest WSM update, Watchguard is STILL installing a semi-hidden, non-disclosed private, insecure, unpatched JRE in %programfiles%Common FilesWatchGuardjava.
Cory, I KNOW you know better than that. Before you cast stones at HBGary, look in the mirror. Your own dev team is making Watchguard a hypocrite with not following best practices by installing undisclosed, unrelated, insecure software on a customer’s machine without clear disclosure.
Although a malicious website probably couldn’t access the private JRE, I’m sure a creative mind like yours could think of a few quick examples of how (in HBGary fashion) that hole could be used as part of a larger suite of exploits to own root on a machine.
Please ask your dev team to remove the private JRE from WSM soonest, and just make the installer require java to be “officially” installed, where we can see it, update it, and manage it ourselves.
Chris,
Sorry for the late reply, I was in an all day event on Friday, so just noticed your comments today.
First, thanks for commenting. I’m excited to turn WatchGuard Security Center into a community for open discourse, so I welcome all comments and look forward to having some great discussions.
I’d like to take your comment in two parts, first the HBGary part and then the WSM Java reference.
As far as the HBGary part, I’m disappointed that I come off as “cast[ing] stones at HBGary.” That was not my intention. At the end of my post, I made a point of saying that I didn’t want to point fingers at HBGary. As I mentioned, studies have shown that 90% of breached businesses have also messed up basic best practices. The point I was trying to make was… I feel that all of us sometimes make these basic security mistakes (mostly when strong security conflicts with convenience). It’s rare for the public to get the detailed scoop on how a real-world breach happened, and I thought looking at the HBGary incident would provide great learning opportunity, and may motivate readers to improve some of their security practices (it certainly motivated me to double check my own password vault usage). I really didn’t want to come off as saying “look how badly HBGary did,” but I did want to point out their failures, and hopefully have my audience learn from them, and wonder whether or not they might not be making similar mistakes.
Next, let me reply to your comment about WatchGuard’s JRE usage.
For other readers, who may not know what Chris is talking about, WatchGuard ships a version of Sun’s JRE component with our WatchGuard System Management (WSM) software. Some aspects of our software rely on Java, which isn’t present on every computer, so we install a version of it for our software to use. We don’t particularly call attention to our use of Java in the installer, but we don’t hide our use of Java either. One place you can learn about our Java usage and other packages is in our Copyright and Licensing Guide [http://www.watchguard.com/help/docs/wsm/11-XTM/en-US/v11_4_copyright_licensing_guide.pdf]. We also install Apache, postgresql, and python, which are other packages our software relies on (not to mention, many other open source packages in the appliance firmware itself).
Chris, you seem to be alluding that our installation and use of this Java runtime is as big a security risk as some of the stuff that happened to HBGary. I’m not sure I agree. You are right that the version of Java JRE we use is no longer the latest, and thus suffers from security flaws. However, there are two points I want to make about that, 1) we continually update our Java package and 2) our implementation of Java doesn’t expose flaws to attackers in a way that they could leverage practically.
As far as updating… We update our Java package regularly (as well as many other packages we use). If you look at WSM 11.3.2, it used J2RE 1.6.0_05. However, WSM 11.4 uses JRE 1.6.0_20 (or update 20). Granted, that still isn’t that latest Java update (24), but that’s only because our 11.4 code went “final” quite awhile ago, and update 20 was the latest at the time. When the next version of our WSM software comes out, you’ll see our JRE installation update again.
However, more to the point is whether or not our Java installation really feasible exposes any real vulnerability or risk.
First, I want to make clear that vulnerabilities in Java are very serious. Right now, web-based Java exploits are one of the top risks that web users face. However, the only real-world Java risks that users are exposed to are Java attacks exploited via their web-browsers. When you install the “normal” Java implementation, it makes many changes to the Windows “PATH,” and to the registry, and to various other places, to allow other programs, like your web browser, to use Java. This means the normal Java installation exposes Java flaws via your web browser.
Our Java implementation DOES NOT do this. We do not make all those system wide Java configuration changes I mentioned. The only program that uses our Java implementation is our program. For example, let’s say you have never installed Java on your computer, but then you install our WSM (including the version of Java that ships with it). You might think your system now has Java… but your browser doesn’t think so. If you open your browser (IE,
Firefox, whatever) and visit a web site with a Java applet, the Java applet will NOT work, and your browser will tell you that you don’t have Java installed, and that you need to go install it. This is because we do not add all those path and registry changes that let windows know where to find the “official” version of Java. We install it to only work with our application. So in short, though we have our own installation of JRE, we don’t expose your system to Java attack surfaces in the same way that a normal, OS-wide JRE installation does. Thus our Java installation really poses very little real-world risk.
While I agree that someone that gains local access to your computer, and found our JRE installation, may be able to leverage it for something like an EoL attack. I don’t think this poses a big risk in the real world (furthermore, is some attacker has enough local access to your computer to do this, you already have bigger things to worry about.) BTW, this is NOT to say that we don’t plan on continuing to patch all the public packages we use in our product, including Java. We take all security vulnerabilities seriously, including low severity ones. As you saw between 11.3.2 and 11.4, we do patch JRE, and we will continue to do so. However, since we don’t release WSM as often as Sun releases Java update, we may not always have the latest, but I really don’t think our JRE installation exposes you in any significant way.
All that said, I do like your idea about exposing our Java package (and perhaps others) in the installer as an option. Granted, that would mean if you don’t install certain packages, some things won’t work. I also believe this could have implication on “ease of use”. One of the reasons we included Java, is because normal Windows users don’t do well installing software that requires dependencies. While you or I may be fine understanding that we need to install a few extra packages to get something to work, most users would hate that. So we’d need to design around that. Nonetheless, I will approach the other product managers, and our engineers, to see why we can’t just make the Java package optional, and to see whether we could make our program work with your installation of Java instead.
Thanks again for the comments.
Cheers,
Corey
Yes, this is a necropost, because (for the same reason I find your blog so valuable) I just don’t find much time to deal with these things. 🙂
I disagree with the assertion that the private JRE is not a risk. Too many developers do that that it’s trivial to search for java.exe on a server and you are very likely to find an old JRE to exploit. Moving past that though…
As long as the quick setup wizard can install and function without java, and thus novice users can perform the initial setup of the firewall without understanding Java installation, the “ease of use” argument holds no water with me.
In short, there is just a time to say that there is a certain bar that if a user is not ready to understand how to install java, they are not ready to mess with their certain functions of their firewall. Every Watchguard device that is not EoL has a very easy to use web interface to do all the functions taht you can with the firewall… oh wait… you have to install Adobe Flash Player… and that is not part of the installer… That’s just not consistent. You can’t have it both ways.
Where is the mental disconnect here?
Don’t let the sarcstic tone above put you off. That’s just my sarcastic sense of humor at work, rather than real venom. I still think overall WSM is a great product, and like all great products, will attract a lot of users, who then want to make it just a little better. 🙂
@ other posters: I can’t fix my grammar retroactively, so please don’t grammar-nazi me to death. Yes, I see several grammar mistakes. And I was repetitive. It comes from over-editing and too much cutting here, and pasting there, etc. 😀
And to be clear, I *like* Watchguard products. I recommend them, and the company I work for resells them. I’m critical of products that do a great job, so that they can get better. I’m hardly worthy of being called Cory’s peer, so I guess this is more “review by inferiors” rather than peer-review. 😀
Heh… I sure won’t grammar-nazi you… You should see some of my internal emails. While I try to use my best grammar in official public posts, I rarely edit internal correspondence and quick comments, so some of my emails can be pretty ugly, grammar-wise. In fact, I didn’t spend much time editing my first response to you, so I’m positive it contains mistakes and repetition too.
Also, all this “hardly worthy of being called Cory’s peer” stuff is poppycock, and I hope you don’t believe it. 🙂 While I hope that I know a few things about security, I sure don’t believe that I’m the super, end-all guru. I learn new things from people everyday, and there are many other researchers that I think know so much more than me. In fact, one of the things that excites me the most about having comments to our posts now, is the opportunity to learn from and share with others. I’m sure there are many tips and pieces of expertise that you and others could share as well, which I simple don’t know yet. I hope you feel comfortable sharing your knowledge here.
Anyway, thanks again for the comments
No, your points were well said Chris. Good post.
Dear WatchGuard,
For the XTM 11.3.3 now includes CLI commands that enable us to see the number of concurrent connections through your Firebox.
In my company, we’ve used the WatchGuard XTM 810 as Cluster with fireware 11.3.2. We face problems, whenever the Front Panel “connection” shows the total active connections over 10000 connections, the primary member of cluster did fail-over to the secondary member of cluster.
Normally, if we calculate the number of concurrent connection which equals the total active connections plus the total of proxy connection, we get around 10000 connections. But the capacity of Watchguard XTM 810 can hold 500000 concurrent connections.
So how could we count the connections which are in a waiting state to be fully closed (FIN/IDLE)? And do we include this kind of connection in the concurrent connection?
And how could we see the number of concurrent connection through our Firebox?
Thanks,
Sincerely,
Simuch IM
you’re truly a just right webmaster. The web site loading pace is amazing. It kind of feels that you are doing any unique trick. Moreover, The contents are masterpiece. you have done a fantastic job on this matter!
I blog frequently and I truly thank you for your content.
This article has truly peaked my interest. I will take a note of
your website and keep checking for new details about once per week.
I opted in for your Feed too.