lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAnPQpmkc/vBG8Jfb3ldblgcKAAAAQAAAAYrzN7lrX/EmbYffgcb7RXQEAAAAA@yahoo.com>
Date: Sun, 20 Mar 2005 00:38:14 +0200
From: Eitan Caspi <eitancaspi@...oo.com>
To: bugtraq@...urityfocus.com
Subject: Symantec Antivirus client locally created scheduled scan is not
 running if the local console is logged off


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@...oo.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)





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ