I'm using WinXP and have never been asked to set a permission for this file: <Windows Root>\\System32\\Ntoskrnl.exe. You pose an interesting question, since it a file that is targeted by
virii. Fortunately, MS made a
patch for this problem.
The trick is this: When you reinstalled Windows, you should have updated service pack 2 from a CD and installed your antivirus software BEFORE connecting to the internet. Once connected, the first stop should be to MS updates, to get all of the security updates. Otherwise, you run the risk of becoming re-infected... even with a brand new installation.
Description:Kernel initialization involves initialization of kernel modules and device drivers by NTOSKERNEL.EXE based on system registry entries. The CurrentControlSet and CloneControlSet registry areas are saved. A driver can report the following errors to the kernel.
Ignore - No error is displayed.
Normal - Booting continues with error displayed.
Severe - The LastKnownGood configuration is used to boot.
Critical - Booting fails if LastKnownGood configuration is being used to boot.
Exact problem:The interrupt 06h (#UD) handler in NTOSKRNL.EXE contains a branch of code for quickly handling C4h/C4h machine code byte sequences according to the control word specified in the two bytes that follow, when the sequence occurs in Virtual-8086 mode (bit 17 of EFLAGS is set). If a control word value other than 4250h or 4350h (both used for fast file I/O) is given, the "bop" is passed off to another section of code in the process hosting the VDM. In NTVDM.EXE, this transition normally corresponds to returning from a call to NtVdmControl(0) (VdmpStartExecution), but in actuality, execution can be redirected anywhere, since the switch is just accomplished by swapping out context structures. The VDM TIB (arrived at by way of [[[[FFDFF124h]+44h]+1DCh]+98h] on Windows 2000, FS:[F18h] on Windows NT 4.0, Windows XP, and Windows Server 2003) is used to hold a copy of the V86-mode context in effect at the time the fault occurred (at offset +CD0h on NT4 and 2000, +2D8h for XP and 2003), then the context for resuming execution of the host code is retrieved (from offset +A04h on NT4 and 2000, +0Ch on XP and 2003) and loaded into the appropriate registers.
As mentioned above, this context is contained in user memory but is not sanitized in any way by the #UD handler, so any process with or without a formally-initialized VDM can place arbitrary values in the host execution context and get the handler to IRETD to any CS:EIP, allowing kernel privileges to be retained while user-supplied code is executed. On any version of Windows, it is sufficient to modify the VDM TIB in a process with a properly initialized VDM (most easily done by code executing in a .COM file). For Windows NT 4.0, XP, and 2003, it is only necessary to set the pointer at offset F18h in the user-land TIB to reference a fake VDM TIB, then execute V86-mode code using NtContinue().
