Jump to content

MrWrighty

Members
  • Posts

    87
  • Joined

  • Last visited

  • Days Won

    1

Kudos

  1. Upvote
    MrWrighty received kudos from mallard65 in Log4J Vulnerability   
    The use of TOMCAT in Eset products clearly states that that Juli is used and not log4j. It is irrelevant that TOMCAT can be configured to use log4j in this scenario. 
  2. Upvote
    MrWrighty gave kudos to TonyK in Log4J Vulnerability   
    You're comparing apples to oranges here:
     
    ESET Endpoint products (inclusive of 'Server-branded' AV engines - unaffected, they don't use apache- the installs do not place any form of Apache on these systems
     
    --------
    Your endpoints aren't at risk directly, if you're solely utilizing HTTP Proxy to distribute content to those systems or connectivity to ESET's public servers, then there is a potential issue (though again ESET saying they don't utilize those components)
     
    ESET PROTECT (management console) - there are two web-engines on this system:
    The TOMCAT engine, which runs the front-end ESET PROTECT UI Webpage, again not applicable
    The only component that is potentially impacted is the APACHE HTTP PROXY component, ESET did release 9.0.10.2 of the Protect console -- but those not wanting to download a gig to update a 12MB install, the literal only change is that under the HTTP Proxy component download, that is showing 2.4.51.0 for downloads
     
    So there is either potential on the Log4J or just simply keeping up with the latest release of Apache (which being a security company, makes sense)...
     
    In the time it took to explain this, updating the 12mb installer and hopping your config file changes, you'd be done 
     
    And the statement is correct about it's not up to ESET to patch endpoints is true -- you deploy your own version updates to your endpoints (though if you're already running 9 on console and endpoints, automation for workstation-version ESET is already in place)
×
×
  • Create New...