Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 28 subscribers
  • Views 2470 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Action Required: XG Firewall Remote Code Execution Vulnerability - Did you have questions about the Sophos email from Nov 8 2019?

Chris Shipley

The email with subject "Action Required: XG Firewall Remote Code Execution Vulnerability" has a reference in it to check KBA 134852.  It doesn't really tell you a lot and you have to take a bit of it on assumption.  I checked all my XG firewalls and they were all ok, with the exception of 1 that was running old firmware.  I do have the SFOS Hotfix "Allow auto-install of hotfixes" setting enabled on the Firmware download page for all my firewalls.  I did expand a bit upon the KBA in my own article on Google Docs Check for Emergency Hotfix on Sophos XG.  It's set for public viewing.  I was able to grab an example of a non-patched dropbear installation on the 17.5.8 firmware I just updated that other firewall to, and included that in my doc.

I found the Sophos official KBA 134852 not terribly helpful in really making me comfortable in knowing I'd had the correct hotfix installed.  I immediately had questions:

  • what even is dropbear (it's the SSH implementation in the sophos firewall OS/XG platform)
  • why is the md5 hash I'm looking to compare my result to listed as an example, instead of as "THE RIGHT ANSWER"?
  • what are examples of not good MD5 hashes?
  • what if I have an earlier than 17.5.8 MR-8 firmware installed?

And with the email in general:

  • what if i don't want to introduce problems with my configuration with a new untested firmware like 17.5.9?
  • are there any fixes available for other firmware not 17.5.8 or 17.5.9?

I hope the extra detail I wrote for my customer who has 3 firewalls I can't access at the moment might help some of you.  Any questions, by all means ask here :)



This thread was automatically locked due to age.
Parents
  • +1

    As best practice, always restrict SSH access from trusted networks/zones only.

     

    To help add some information to this:

    The md5sum of the “dropbear” binary (which handles SSH access) on the appliance should match to the below value on all models/versions:

    • f2f938a6eccaf4a5114abeb2e0819c31 

    Note: To verify value of md5sum, run the following in advanced shell on the XG in question:

    • #md5sum /bin/dropbear
    • The u2d.log events should also show the related “sfsysupdate_NC-51939“ .gpg file being downloaded to the appliance.

    The related KBs have been updated accordingly for reference as well:

  • 0 in reply to FloSupport

    Flo, maybe you should edit the KB articles.  Your information is much clearer.  The articles you linked are still pretty bare.  It's like they were written by an engineer that expects you to know 90% of the situation entirely already, and this is just a missing piece of the puzzle - just not really the case.  They need a more polished touch.

Reply
  • 0 in reply to FloSupport

    Flo, maybe you should edit the KB articles.  Your information is much clearer.  The articles you linked are still pretty bare.  It's like they were written by an engineer that expects you to know 90% of the situation entirely already, and this is just a missing piece of the puzzle - just not really the case.  They need a more polished touch.

Children
No Data