Symantec Antivirus client locally created scheduled scan is not running if the local console is logged off

From: Eitan Caspi (eitancaspi_at_yahoo.com)
Date: 03/19/05

  • Next message: Kris Anderson: "Re: Few remote bugs in zPanel"
    Date: Sun, 20 Mar 2005 00:38:14 +0200
    To: bugtraq@securityfocus.com
    
    

    Suggested Risk Level: Low.

    Type of Risk: Security check not performed.

    Affected Software:
    Symantec Antivirus (SAV) Corporate Edition client (checked version):
            application version 9.0.0.338
            scan engine: 1.4.0.11
    Earlier versions are most likely to have the same behavior - but that should
    be checked separately.

    Host operating system:
            Windows XP with SP2
    (I assume this issue will be similar with any Microsoft windows operating
    system that can perform a "log in" / "log off" and that the SAV client can
    run on).

    Local / Remote activated: Local only.

    Summary: A scheduled virus / malware scan created locally at the SAV client
    interface (vs. a scheduled scan created at the central SAV server and
    enforced onto the client (Both types of scans can co-exist within a managed
    client)) - will not start running if at the specific date and time the scan
    should have run - the client's host console interface is logged off (i.e. no
    user is logged on at the local console).
    Hosts with a role of "server" are most of the time in a "log off" mode.

    Possible risk: Viruses / Malware that may have penetrated the host if the
    real time SAV client scanner was / is not running for any reason (First line
    of defense not operating) - will not be discovered for a long time (Second
    line of defense not operating).

    Reproduction:
    1. Locally on the host (NOT via a terminal session, but via the actual local
    console), where the SAV client is installed - created a scheduled scan, with
    any configuration desired, and save it.
    2. Log off from the host's local session.
    3. Wait for the next schedule of the created scan.
    4. Within the number of days configured in the "Handle Missed Events Within"
    scan configuration field, after the last date and time when the locally
    created scheduled scan should have run - Log into the local console of the
    SAV client host.
    You will notice an excessive disk operation beginning (the scheduled /
    missed scan) and within the "Task Manager" utility (a system utility built
    into Windows NT and above. press ctrl+shift+esc) you will see that the
    rtvscan.exe process is consuming processor utilization at a constant rate.
    Browse the SAV client application to the "Histories" category, and then to
    the "Scan History" section - You will notice that the date and time of the
    current running scan (with a status of "scanning...") is close to the time
    you have logged into the host.

    Exploit Code: Not needed.

    Direct solution: Not at the moment (middle of March 2005).

     
    Workarounds:
    1. Make sure the real time scanner is active at all times.

    2. Try to have all of your client installations to be in a managed mode
    (i.e. controlled by a central SAV server), and then make sure to create a
    central scheduled scan and enforce it to all of the clients. This kind of
    scan is not affected by the issue of this report.

    3. If the above is not possible due to any kind of the following scenarios:
    A. The client is not in a "managed" mode. This can be due to:
            1. The client is located in a DMZ / Web zone.
            2. The client is installed in secure and isolated environment.
    B. The client is in a "managed" mode but:
            1. Due to lack of configuration there is no central scheduled scan
    enforced onto the clients.
            2. There is a central scheduled scan enforced onto the clients, but
    there is also, alongside, a locally created scheduled scan for a
    specific purpose.
    C. The real time scanner is not running at all or is in effect for only part
    of the host structure due to any specific considerations.

    Then:
    Log into the local console of the SAV client host, within the number of days
    configured in the "Handle Missed Events Within" field, after the last date
    and time when the locally created scheduled scan should have run.
    The scan will begin.

    To make sure the scan is running:
    You should notice an excessive disk operation beginning (the scheduled /
    missed scan) and within the "Task Manager" utility (a system utility built
    into Windows NT and above. press ctrl+shift+esc) you will see the
    rtvscan.exe process is consuming processor utilization at a constant rate.

    You can also Browse within the SAV client application to the "Histories"
    category, and then choose the "Scan History" section - where you will notice
    that the date and time of the current running scan (with a status of
    "scanning...") is close to the time you have logged into the host.

    If the scan is configured not to show any interface while running - you can
    log off. The scan will continue running even though you have logged off.

    Vendor Notification: Symantec was notified of this issue.
    Its response following:

    "
    Thank you for bringing this issue to our attention. The issue you have
    raised with our product is important and was given a complete investigation.
    Our findings are that, while yes there is a minor issue for unmanaged
    environments, the majority of our customers -- 90% -- run in managed mode
    and are not affected. In addition, with the Real-Time Virus Scan capability,
    there is no threat of the system being infected during this "logged off"
    period even if the scheduled scan didn't run.

    Part of our effort is to also identify any mitigating steps that can be
    taken. One was identified: To work around this problem in an unmanaged
    environment a user would covert the client to managed mode. Alternatively,
    they could use our management tools (included with the product) to create a
    configuration file (called grc.dat) that could be installed onto the client
    that would fix the problem. This file could be installed onto the machine
    with any software distribution tool.

    When Symantec evaluates a potential vulnerability, we use publicly accepted
    definitions for vulnerability or exposure, such as the CVE (Common
    Vulnerability and exposure) definition, located at:
    http://www.cve.mitre.org/about/terminology.html
    I have included the definition here:

    A "universal" vulnerability is one that is considered a vulnerability under
    any commonly used security policy which includes at least some requirements
    for minimizing the threat from an attacker. (This excludes entirely "open"
    security policies in which all users are trusted, or where there is no
    consideration of risk to the system.)

    The following guidelines, while imprecise, provide the basis of a "universal
    vulnerability" definition. A universal vulnerability is a state in a
    computing system (or set of systems) which either:

    . allows an attacker to execute commands as another user
    . allows an attacker to access data that is contrary to the specified access
    restrictions for that data
    . allows an attacker to pose as another entity
    . allows an attacker to conduct a denial of service

    The following guidelines provide the basis for a definition of an
    "exposure." An exposure is a state in a computing system (or set of systems)
    which is not a universal vulnerability, but either:

    . allows an attacker to conduct information gathering activities
    . allows an attacker to hide activities
    . includes a capability that behaves as expected, but can be easily
    compromised
    . is a primary point of entry that an attacker may attempt to use to gain
    access to the system or data
    . is considered a problem according to some reasonable security policy

    Under this definition, the issue that you have brought to our attention does
    not fit the definition of a vulnerability. However, this does not mean that
    we are going to drop the issue. We recognize that this issue needs to be
    addressed. Based on the information you have provided to us, it will be
    addressed promptly in a product support update.
    "

    Credit:
    Eitan Caspi
    Israel
    Email: eitancaspi@yahoo.com

     
    Past vulnerability reports:

    1. Microsoft Exchange Inappropriate Registry Permissions Vulnerability

    http://www.microsoft.com/technet/security/bulletin/MS02-003.mspx

    http://support.microsoft.com/default.aspx?scid=KB;en-us;315085&

    http://online.securityfocus.com/bid/4053

    2. Microsoft Windows 2000/XP Full Event Log Administrative Alert Weakness

    http://support.microsoft.com/default.aspx?scid=kb;en-us;Q329350

    http://online.securityfocus.com/archive/1/295341

    http://online.securityfocus.com/bid/5972

    3. Microsoft Windows XP Fast User Switching Process Viewing Weakness

    http://www.securityfocus.com/archive/1/301624

    http://online.securityfocus.com/bid/6280

    4. HP Compaq Insight Manager/Compaq Web Agent Session Persistence
    Vulnerability

    http://online.securityfocus.com/archive/1/309442

    http://online.securityfocus.com/bid/6736

    Blogs:
    Blog (Hebrew): http://www.notes.co.il/eitan
    Blog (English): http://eitancaspi.blogspot.com

    Articles:
    You can find some articles I have written in
    http://www.themarker.com/eng/archive/one.jhtml
    (filters: Author = Eitan Caspi (second name set), From year = 1999, Until
    year: 2004)

    Quote:
    "Technology is like sex. No Hands On - No Fun." (Eitan Caspi)


  • Next message: Kris Anderson: "Re: Few remote bugs in zPanel"

    Relevant Pages

    • Symantec Antivirus client locally created scheduled scan is not running if the local console is logg
      ... Symantec antivirus (SAV) client ... missed scan) and within the "Task Manager" utility (a system utility built ... When Symantec evaluates a potential vulnerability, ...
      (Bugtraq)
    • Re: Symantec Antivirus & SBS
      ... BUT as anFYI I do set the firewall as disabled only in the domain profile. ... network receives an email with this _unknown by your AV solution_ virus. ... I ALWAYS turn off the XP firewalls on systems and SAV ... I had a client have their SBS system get hosed by the SAV client this way ...
      (microsoft.public.windows.server.sbs)
    • Re: Anti-Virus & Anti-Spam Suggestions?
      ... a week or so ago I switched a client from SAV to Trend, ... I spoke to the client a couple of days ago ... 'This Trend thing is wonderful!!! ... "appliances" or even server based software that Symantec uses. ...
      (microsoft.public.windows.server.sbs)
    • Symantec AV 10 CE issue...
      ... I just upgraded our 60 node network of win 2k and XP to Symantec 10 from a ... Uninstalling the SAV fixes the problem, ... re-install a managed version 9 client to my 10 server. ... problem, at least 1 other customer reported it, but no fix yet. ...
      (microsoft.public.windowsxp.security_admin)
    • [Full-disclosure] RE: [NT] Microsoft Multiple E-Mail Client Address Spoofing Vulnerability
      ... As a security professional working for a Corporate Office the "Multiple ... E-Mail Client Address Vulnerability" (please see original advisory attached ... Outlook 2003 and Exchange 2003 as far as I could tell. ...
      (Full-Disclosure)