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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 19 Aug 2006 23:46:46 +0000
From: "Ray P" <sixsigma98@...mail.com>
To: cfaigle@...hmond.edu, full-disclosure@...ts.grok.org.uk
Cc: 
Subject: RE: Symantec Anti-Virus Corporate Edition:
	DownloadProduct Upd

Hi Chris,

That stupid check box has been there since v7.0.0 when Symantec first bought 
that product from Intel LanDesk. One would think that after six years, they 
would have removed it since it has never worked.

Even worse, their "management" system does not have any way to queue 
changes. You cannot move one client to another server, for example, unless 
it is physically communicating with the server. This is a real issue for us 
because we have sales people around the world who work in different time 
zones.

I know I've submitted this request several times over the years to no avail. 
I do not understand their resistance to implementing it because the people 
who don't want it can simply turn it off.

Ray


>From: "Faigle, Chris" <cfaigle@...hmond.edu>
>To: <full-disclosure@...ts.grok.org.uk>
>Subject: [Full-disclosure] Symantec Anti-Virus Corporate Edition: 
>DownloadProduct Updates Using LiveUpdate Feature in Central ConsoleDoes Not 
>Work Date: Wed, 16 Aug 2006 09:51:26 -0400
>
>
>Issue:
>
>	Symantec Anti-Virus Corporate Edition clients controlled via the
>Symantec System Center Console do not follow the "Download product
>updates using LiveUpdate" setting. This feature has been disabled by
>Symantec according to their technical support.
>
>
>Impact:
>
>	Clients cannot be told to automatically update to new releases
>and maintenance patches from the SSC and this then must occur via
>another mechanism, or pushed using the "Client Remote Install" option
>which only works when a client is actively on-line and also does not
>queue.  This leaves installs of this "First-Line-of-Defense" product out
>of date if any scan-engine or other vulnerabilities are found, until
>they are upgraded using one of these other mechanisms, which may or may
>not be possible within a reasonable period of time for any given client.
>
>
>Background:
>
>	We have moved towards only installing software that can
>automatically upgrade itself, due to the vast number of vulnerabilities
>in software - need I say more.
>
>	We install (and require!) Symantec Anti-Virus Corporate Edition
>(currently version 10.1.x.x) for faculty, staff and student machines.
>
>	Clients point to our SAV server, which controls their behavior,
>or they can be put in a group where the machine administrator can
>control the client behavior.  This is controlled via a "GRC.dat" file
>which is updated on the server when a change is made using the SSC and
>then pulled down by the client.
>
>	Faculty and Staff machines are on the domain and are in general
>managed by SMS, which does allow us to put together an upgrade package
>for SAV, but requires manual effort on my part.
>
>        Student machines may or may not be on the domain, but are not
>managed by us in any way.  They also may also not be on our network for
>long periods of time (e.g. summers, study abroad). The only way we have
>to enforce an upgrade here is to pull our student network registration
>file and update our Active X control
>(http://is.richmond.edu/security/Downloads.htm) to check for the new
>version and then force re-registration. This will only work for student
>machines on our network and will have no effect on students over the
>summer, etc.  Re-registration is also a business interrupting event.
>
>	The SAV client is considered first LOD, since it scans e-mail,
>web and disk files before they are opened by the OS or application. It
>also has a set of ports it communicates via.
>
>	I spoke with Symantec's Platinum support about why these clients
>do not upgrade themselves even though I have this set on our server for
>machines which are not in a specific administrator controlled group.
>
>	The helpful tech person said that support for this was removed
>since corporate customers did not want machines to reboot and the AV
>upgrade requires a reboot, however the check box still exists.
>
>	I responded that most modern software (Windows, Mac, IE, Abobe,
>etc) has this feature in the standard Install Now/Install Later and
>Reboot Now/Reboot Later format.
>
>	He also said that we would not want these clients to suck down
>large updates via the internet, however I responded that is standard for
>updates for e.g. Macs, Windows, Adobe, etc. and I am much more worried
>about mass compromise of machines that I am about network traffic.
>
>	He said he understood the issue and that I was welcome the make
>a feature request via the Platinum Support web page, however I figured
>FD might draw a faster and better response and that others would want to
>know this information.
>
>Conclusion:
>
>	Installing this software without a mechanism for automatic
>upgrades on unmanaged machines poses a potential security risk.
>
>	I welcome any response from Symantec in the FD forum and in
>particular I welcome any corrections if I have unintentionally erred in
>any way in the description above.
>
>
>Regards,
>Chris Faigle
>University of Richmond
>IS Security
>
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ