A Different "Access Denied" Thread

I have been using NOD32 on one XP Pro system and three Vista Ultimate systems for about six months at this point. I switched from Norton because I was tired of the overhead that could drag down even the most powerful systems.

I have a couple of general questions about the "Access Denied" messages for cases when the files do not show up as "Locked". I have also read a thread (which I couldn't relocate today) which basically stated that we see these and the "Locked" messages because ESET chooses to show these cases while other AV providers just don't fess up that they can't scan these files.

I'll buy this in general and I do appreciate the "full disclosure"; however, something seems amiss here in the case of the System Volume Information files which show up with "Access Denied", but not as "Locked". I'm sure I've read many times that AV scanners find issues in these volume recovery files after an infection, and in fact, the recommendation is often to turn off volume recovery and delete these files as part of the cleanup.

Am I off base in saying that I see NOD32's inability to scan these files as unusual and a potential liability?

My second question relates to finding a pointer to some list of "Access Denied" files that can be considered "normal". ..or, potentially building such a list through the people on this forum. When I scan through the files and registry hives that show up as "Locked", they generally seem quite logical. (Often system/process/application log files and consistent across my multiple Vista systems.)

The bulk of the "non Locked" files showing "Access Denied" seem to be the System Volume Information files that I mentioned above. Others are the \user...\AppData\Local\Temporary Internet Files\AntiPhishing\... files that I imagine IE7 protects.

On the Vista systems, there are also system32\Logfiles\WMI\RfBackup\ETWRTE*.etl files that always seem to show up with "Access Denied". I don't run Spybot or Spysweeper on my Vista systems, but on the XP system, Spybot's files show up as password protected and Spysweeper's files show up as locked.

Has anyone tried to compile a general list so that we could all generally know what "normal" is?

 

I’ll rescind part of my question. I was able to find the threads I that originally found last spring when I first started running NOD32. I just didn’t follow some of the FAQ pointers far enough. The exchanges started in October ’06 by DVD+R and mypenry do a pretty good job of covering this topic and alglove’s response to DVD+R even has a list of sorts of XP files that are commonly locked.

I am still bothered by the inability to access the System Volume Information files where I know from personal experience that these have showed up as infected using another AV product. It was well over a year ago and I wish I could remember if I was when I was still using McAfee or if I had switched to Norton. I believe it was Norton, and if so, would others agree that this is something significant that NOD32 should be able to handle?

I am out of date and have never written privileged code in a Windows environment, but I wrote extensive amounts of system/privileged code on platforms running MVS, multiple flavors of UNIX and VMS and was able to bypass things like access restrictions and locked files. These were systems that had better security than any Windows OS except possibly Vista.

I guess what I am saying is that I would expect any good AV product to bypass normal access restrictions and install itself as a privileged piece of code with the permission of the person installing it. You can do anything outside of any operating system once you are in a privileged mode of execution. This is related to how hypervisors work too. Virus code has a little harder time of it because no one is going to give it permission intentionally. It needs to trick you into giving it privileged access or exploit an OS flaw.

If this was just something new with Vista, I might understand it since I know the AV vendors have had to adjust to new restrictions, but NOD32 can’t access the System Volume Information files on XP either. I am not trying to be critical of NOD32, just accurate as how it stacks up to finding things in comparison to other AV products. Has anyone else had experience where another AV product could scan these files or others that NOD32 can’t seem to access?

 

I'll see if someone from ESET can elaborate on this.

Cheers

 

Bump...

Any feedback on this? I looked at some older threads and ran a test on the one XP Pro system I have left and I was wrong about there being a problem under XP scanning the System Volume Information files. It only seems to be an issue with Vista.

 

Hello,

I am not sure if I understand your question, but let me try to reply. If this was not the information you are looking for, please let me know.

In order for software to access the \System Volume Information\ directory under Microsoft Windows Vista, it either has to be run from the SYSTEM account or the permissions on the directory have to be changed so that software can access it.

In the case of NOD32 v2.x, the NOD32 Kernel Service (filename: NOD32KRN.EXE) runs as a service, so it should have been started by the SYSTEM account, which means it should have access to the \System Volume Information\ directory, which has the same owner.

When you talk about NOD32 not being able to access the \System Volume Information\ directory, how exactly are you trying to scan the directory? Are you right-clicking on it and selecting the NOD32 antivirus system from the context menu, performing an on-demand scan or a scheduled scan?

Understanding the exact steps you are taking will be very helpful in determining what sort of access NOD32 has to your system, because under Windows Vista an application running under an account with Administrator privileges typically is not going to have administrative rights unless it is elevated. An earlier message here in the forum discusses the "split-token" model being employed.

Regards,

Aryeh Goretsky

 

Thank you for getting back to me. I believe you did understand the question. I get the following log output running NOD32 scans on Vista Ultimate:

Scan performed at: 12/7/2007 1:00:03 AM
Scanning Log
NOD32 version 2708 (20071207) NT
Command line: /local /adware /ah /all /antistealth+ /arch+ /clean /cleanmode /delete /heur+ /log+ /mailbox+ /ntfs+ /pack+ /quarantine /scanboot+ /scanmbr+ /scanmem+ /scroll+ /sfx+ /unsafe /unwanted /wrap+
Operating memory - is OK

Date: 7.12.2007 Time: 01:00:30
Anti-Stealth technology is enabled.
Scanned disks, folders and files: C:; F:; G:; H:; N:; P:
C:\hiberfil.sys - error opening (File locked) [4]
C:\pagefile.sys - error opening (File locked) [4]
C:\Program Files\Nero\Nero8\Nero BackItUp\BackItUp_ImageTool\root.img »GZ - archive damaged
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\MSS.log - error opening (File locked) [4]
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\MSStmp.log - error opening (File locked) [4]
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\tmp.edb - error opening (File locked) [4]
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb - error opening (File locked) [4]
C:\System Volume Information\{10182a4c-a290-11dc-9e93-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
C:\System Volume Information\{10182a6a-a290-11dc-9e93-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
C:\System Volume Information\{1401674d-9fb0-11dc-8cd7-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
C:\System Volume Information\{14016785-9fb0-11dc-8cd7-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
C:\System Volume Information\{140168b5-9fb0-11dc-8cd7-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
C:\System Volume Information\{140168d4-9fb0-11dc-8cd7-00508d9f870f}{3808876b-c176-4e48-b7ae-04046e6cc752} - error opening (Access denied) [4]
…..

This is running NOD32 as a scheduled task per BlackSpear’s recommendations w/ NOD32 Kernel – Execution of an external application. I get the same results letting it run as scheduled or by bringing up the scheduled task within NOD32 and running it by right clicking on the task and selecting “Run Now”.

Nod32.exe and nod32krn.exe show up as being run under the SYSTEM process in the Windows Task Manager. Nod32ui.exe shows up under my account. Note that I do not get these errors on XP. I described the difference in behavior between XP Pro and Vista Ultimate in another thread (NOD32 2.7 Stuck on Cleaning). Below is an extract from that thread:

Since responding to the thread mentioned above, I have verified that the logs of scans that ran per the scheduler as scheduled versus clicking “Run Now” have the same output…access denied on the System Volume Information files. In fact, the output snippet I show above was run via the scheduler as scheduled, not using “Run Now”.

While writing up this reply, I executed the scheduled task again via “Run Now” and noticed the following:

It creates a new nod32.exe task under the SYSTEM account (verus the one already sitting there) which is the one whose CPU time I watch to verify when it is done. During the execution, nod32krn.exe does not appear to be active or to use any CPU time.

 

I was able to get around the “stuck” in waiting state issue by scheduling an “on-demand” profile scan versus scheduling the scan as the “Execution of an external application”. What are the pros and cons of using the “Execution of an external application” option and why is that part of Blackspear’s recommendations?

There was no difference regarding the System Volume Information files. NOD32 V2.7 still couldn’t scan them. This doesn’t seem to be an issue with V3 (or V3 just doesn’t report that they can’t be scanned).

Edit: I asked my question too soon (w/o a search first). I found a thread from last year where Blackspear basically said that there isn't a difference between scheduling "on-demand" versus "Execution of an external aplications" as far as anything I care about. From my experience, there is a difference when using V2.7 w/ Vista and that is whether you have to reboot to get the scan results flushed to the log.

All water under the bridge for me at this point. After experimenting w/ V3 for a day, I am convinced I like it better and will switch my remaining systems over today. I understand the concerns about using it with independent firewalls like Comodo, but I have seen enough ideas in the forum threads that should allow ways to detect unwanted outbound connections. Bye to V2.7! Cheers!