RE: Norton antivirus fails to scan files

From: garberoaat_private
Date: Thu Jul 11 2002 - 11:31:27 PDT

  • Next message: Bill Weiss: "Re: [7.8.2002 44916] Notice of Copyright Infringement"

    Bone Machine,
    
    I realized that I failed to mention that possibility a short time after I
    sent my reply yesterday. If the ACL does not contain the SYSTEM account or
    any groups that SYSTEM is a member of then it will fail as well. So even
    without an explicit deny, the read operation would still fail. If you have a
    resource that only has ACEs for one principal to the exclusion of others,
    then it is essentially off-limits (barring any creative use of the backup
    files right or a little defrag api wizardry). If you decide to do something
    like add an explicit Full Control ACE for SYSTEM, I'd be interested in
    hearing whether it fixes the problem or not.
    
    Best Regards,
    
    Andrew Garberoglio, MCSE, CISSP
    Wells Fargo Services, Internet Technology Services
    
    "Let us prepare to grapple with the ineffable itself, and see if we may not
    eff it after all"
    -Douglas Adams
    
    -----Original Message-----
    From: BoneMachine [mailto:BoneMachineat_private]
    Sent: Thursday, July 11, 2002 10:55 AM
    To: garberoaat_private
    Cc: bonemachat_private; vuln-devat_private
    Subject: Re: Norton antivirus fails to scan files
    
    
    Actually, I've removed all other users from the ACL that have no business to
    my files. So there are no explicit denies.
    
    NAV is started as system account as defined in control
    panel->services->startup
    
    I have not yet found the time to look at logs so I cannot that the read fail
    occurs.
    
    It would be a method for a virus to keep itself rrom being scanned though.
    
    greetings 
    Bone Machine
    
    --
     
     "Hey! been trying to meet you" - The Pixies
     
    --
     
     
    
    On Wed, 10 Jul 2002 18:06:04 -0700
    garberoaat_private wrote:
    
    > BoneMachine,
    > 
    > What do you mean by "a file has no Administrator read privileges"? Is the
    > principal/group simply not present in the ACL for the object, or is an
    > explicit deny set? Also, are you referring to the local administrators
    > group, or the local administrator account (RID 500)? It matters. If, for
    > instance, you had NAV running as NT AUTHORITY\SYSTEM and it attempted to
    > open the file (ACLed with "deny read" set for the Local Administrators
    > group) for a read operation, it will fail. A glance at the group
    membership
    > for NT AUTHORITY\SYSTEM on an NT 4.0 or Win2k box reveals why:
    > 
    > [User]     = "NT AUTHORITY\SYSTEM"  S-1-5-18
    > 
    > [Group  1] = "BUILTIN\Administrators"  S-1-5-32-544
    > [Group  2] = "Everyone"  S-1-1-0
    > [Group  3] = "NT AUTHORITY\Authenticated Users"  S-1-5-11
    > 
    > If an explicit deny is set for the local admins group (that NT
    > AUTHORITY\SYSTEM) is a member of, then the operation will fail. See
    attached
    > zip archive for neato-keen screen shots of the read fail in action. If
    this
    > is the problem you are encountering, which I suspect it is, you should be
    > seeing audit failures in the security log that confirm this (you are
    > auditing, aren't you?).
    > 
    > It's a common misconception that the NT AUTHORITY\SYSTEM account doesn't
    > have to play by the same rules as any other account when it comes to
    > accessing ACLed resources. You can set explicit deny ACLs for the SYSTEM
    > account on just about anything (File System objects, registry keys, system
    > objects... get used to looking at blue screens with white letters if you
    > decide to be silly with this functionality).
    > 
    > 
    > HTH, 
    > 
    > Andrew Garberoglio, MCSE, CISSP
    > Wells Fargo Services, Internet Technology Services
    > 
    > "Let us prepare to grapple with the ineffable itself, and see if we may
    not
    > eff it after all"
    > -Douglas Adams
    > 
    >  <<cant_scan_me.zip>> 
    > 
    > -----Original Message-----
    > From: BoneMachine [mailto:bonemachat_private]
    > Sent: Wednesday, July 10, 2002 4:47 AM
    > To: vuln-devat_private
    > Subject: Norton antivirus fails to scan files
    > 
    > 
    > I have a problem with NAV corporate edition 7.6. When a file has no
    > Administrator read privileges assigned on a Windows 2000 or Windows NT
    host,
    > NAV fails to scan the file for viruses.
    > This is a bit odd because the NAV client runs with system privileges and
    > according to my NT knowledge this should be enough to read those files.
    > 
    > I've searched on the Symantec knowledge base and all I found was this:
    > Error: "Application Log is Full" upon startup of Norton AntiVirus
    Corporate
    > Edition
    >
    http://service1.symantec.com/SUPPORT/ent-security.nsf/552ba2f7636bedf0882568
    > 18006f78bf/304b3eb399b43ab588256a780056e5d7?
    > 
    > I have also used the webform to post this issue to symantec about two
    months
    > ago, but I had no response
    > 
    > Also it is not possible to use an other account than administrator as the
    > 'scan' account. So it is impossible to protect documents from accidental
    > access by removing administrator privileges from a file (yes, I know that
    > administrators can add themselfs to the ACL of a file, but that does
    require
    > an extra action thus excluding accidental access)
    > 
    > My thoughts are that there are two vulnerabilities to this behavior of NAV
    > 1. A virus can protect itself from being scanned by removing administrator
    > read privileges from itself and its copies.
    > 2. The administrator needs read privileges on all files, files therefore
    > cannot be protected from accidental access by administrators.
    > 
    > Does anyone have the same experience ? 
    > Does anyone know of a virus that uses this technique to hide ?
    > 
    > greetings
    > Bone Machine
    > 
    > --
    > 
    > "Hey! been trying to meet you" - The Pixies
    > 
    > --
    > 
    > 
    



    This archive was generated by hypermail 2b30 : Thu Jul 11 2002 - 18:12:52 PDT