antivir updates not working anymore under 10.0?
Hi For about 3 weeks I'm unable to update my antivir on my suse 10.0 machine. I get this error: - error updating the VDF database (inc) error updating the VDF database See log files for details. - The logs say: May 24 13:28:12 server antivir[31553]: Error: unable to verify runmode of update May 24 13:28:12 server antivir[31553]: AntiVir FAILED to update itself Unfortunately I wasn't able to find anything about this runmode problem... I tought it might be a license problem but neither with the license included in the 10.1 rpm (valid till june 2006, COMMERCIAL) nor with the license from the latest tarball (valid till july 2006, PERSONAL) i was able to perform an update. It works perfectly on the 10.1 machine tough !!! I've reinstalled it several times from the rpm or from the tarball - each time removing all occurences i knew about (/etc/(antivir¦avguard).conf, /usr/lib/AntiVir).... Right now I'm using the tarball license: # antivir --version 6.34.1.32 operating system: Linux (glibc 2.2) product version: 2.1.6-31 engine version: 6.34.1.32 packlib version: 7.1.0.1 (supports 31 formats) vdf version: 6.34.1.134 product: AntiVir Workstation key file: hbedv.key registered user: PersonalEdition Classic serial number: 0000149996 key expires: 31 Jul 2006 run mode: PERSONAL product: AntiVir (command line scanner) key file: hbedv.key registered user: PersonalEdition Classic serial number: 0000149996 key expires: 31 Jul 2006 run mode: PERSONAL Any ideas?? Thanks Matt
Matthias Keller wrote:
For about 3 weeks I'm unable to update my antivir on my suse 10.0 machine. I get this error:
[...]
Any ideas??
What does the output of antivir --update --check --debug show? Also, make sure the partition where /tmp resides doesn't have the noexec flag set. Arjen
Matthias Keller wrote:
Hi
For about 3 weeks I'm unable to update my antivir on my suse 10.0 machine. I get this error:
- error updating the VDF database (inc) error updating the VDF database See log files for details. -
The logs say: May 24 13:28:12 server antivir[31553]: Error: unable to verify runmode of update May 24 13:28:12 server antivir[31553]: AntiVir FAILED to update itself
Unfortunately I wasn't able to find anything about this runmode problem... I tought it might be a license problem but neither with the license included in the 10.1 rpm (valid till june 2006, COMMERCIAL) nor with the license from the latest tarball (valid till july 2006, PERSONAL) i was able to perform an update. It works perfectly on the 10.1 machine tough !!!
I've reinstalled it several times from the rpm or from the tarball - each time removing all occurences i knew about (/etc/(antivir¦avguard).conf, /usr/lib/AntiVir)....
I finally found the problem after reading a thread of someone with not enough free space on /tmp This wasn't my problem, BUT, I've set the noexec flag on /tmp for security reason - and this seems to make updates impossible !! I've added the --temp option now and it seems to work I hope this helps someone else in the future with the same problem..... Matt
Matthias Keller wrote:
I finally found the problem after reading a thread of someone with not enough free space on /tmp This wasn't my problem, BUT, I've set the noexec flag on /tmp for security reason - and this seems to make updates impossible !!
This is a well known problem with people not understanding what the noexec flag really does. It really adds no additional security at all (since the ways to circumvent this are well known for years already) and potentially crash other applications as well.
I've added the --temp option now and it seems to work
The best solution is to remove the 'noexec' flag. Regards, Arjen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-05-24 at 14:47 +0200, Arjen de Korte wrote:
This is a well known problem with people not understanding what the noexec flag really does. It really adds no additional security at all (since the ways to circumvent this are well known for years already) and potentially crash other applications as well.
Could you expand on that, or give a link, please? I'm interested in knowing how 'noexec' can be circunvented. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEdGqxtTMYHG2NR9URAsJRAKCPRa7yMsp+bey528AJKKpj5B4dzgCfbPKK iF4WTG7kUriKl4vNkRNpzqE= =1u7U -----END PGP SIGNATURE-----
Carlos E. R. wrote:
This is a well known problem with people not understanding what the noexec flag really does. It really adds no additional security at all (since the ways to circumvent this are well known for years already) and potentially crash other applications as well. Could you expand on that, or give a link, please? I'm interested in knowing how 'noexec' can be circunvented.
Being well known for years already, a Google search on for instance 'circumvent noexec' will give you plenty of pointers where to look. The basic idea behind the noexec flag may be nice, but there are so many loopholes around it, that the amount of applications that it breaks are really not worth all the trouble. Regards, Arjen
On Wed, 24 May 2006, Arjen de Korte wrote:
Being well known for years already, a Google search on for instance 'circumvent noexec' will give you plenty of pointers where to look. The basic idea behind the noexec flag may be nice, but there are so many loopholes around it, that the amount of applications that it breaks are really not worth all the trouble.
I think this is a little contentious. The important question is not whether noexec *can* be circumvented, but whether it *is* circumvented by a typical script-kiddie's exploit. If noexec stops some exploits working then you have gained a valuable extra layer of security. People's mileage will vary depending on what applications they run, you shouldn't assume one size fits all. Bob
Bob Vickers wrote:
Being well known for years already, a Google search on for instance 'circumvent noexec' will give you plenty of pointers where to look. The basic idea behind the noexec flag may be nice, but there are so many loopholes around it, that the amount of applications that it breaks are really not worth all the trouble. I think this is a little contentious. The important question is not whether noexec *can* be circumvented, but whether it *is* circumvented by a typical script-kiddie's exploit. If noexec stops some exploits working then you have gained a valuable extra layer of security.
I doubt that many script kiddies will be stopped by it. The loophole for shell scripts is as simple as running /bin/sh /tmp/<insert your favourite script here> instead of just firing up the script. You can even run binaries in a similar fashion. That doesn't add a lot of work for them and I really doubt if this has not become the standard already. Since setting the 'noexec' flag creates real problems in legitimate applications, antivir being just one of them, I don't think setting this flag is worth the trouble. Of course, YMMV. Arjen
participants (4)
-
Arjen de Korte -
Bob Vickers -
Carlos E. R. -
Matthias Keller