Comment any docs on using that exploit? (Score 1) 127
I admin NT boxes (and merely have 'heightened' access on a few *nix boxes). The exploit the mentioned seems plausible - but only in theory.
There is no builtin way to mess with the Object Tree in NT4. Even WinObj (www.sysinternals.com) doesn't let you actually edit the tree. Furthermore, the permissions can be reset with the proper kernel patches.
As to the complaints of HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Run, simply make it read-only to non-administrative accounts. Setting file and registry permissions to read-only can actually make a machine pretty safe.
NT was never intended to be a multi-user platform, at least in the traditional sense. It was designed so that different users could login and use the same programs, with their own unique preferences, _serially_, and carry those preferences to any other computer they used.
The biggest problem Ive found with NT is not inherent to the OS. It has to do with third-party parogrammers (and, sadly, some M$ programmers too) not programming with the assumption that the user will only have read access. Netscape, Corel, Adobe, M$ Office 95/97 (but not 2000), and most stat packages all require unacceptably high access to the registry and/or filesystem. (Most _require_ write access to non-user specific preferences files, or a few application-specific registry entries).
Give me apps that adhere to NT profile policies, and that can run in an entirely read-only environment, and you'd be surprised how secure I can make that workstation.
There is no builtin way to mess with the Object Tree in NT4. Even WinObj (www.sysinternals.com) doesn't let you actually edit the tree. Furthermore, the permissions can be reset with the proper kernel patches.
As to the complaints of HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Cur
NT was never intended to be a multi-user platform, at least in the traditional sense. It was designed so that different users could login and use the same programs, with their own unique preferences, _serially_, and carry those preferences to any other computer they used.
The biggest problem Ive found with NT is not inherent to the OS. It has to do with third-party parogrammers (and, sadly, some M$ programmers too) not programming with the assumption that the user will only have read access. Netscape, Corel, Adobe, M$ Office 95/97 (but not 2000), and most stat packages all require unacceptably high access to the registry and/or filesystem. (Most _require_ write access to non-user specific preferences files, or a few application-specific registry entries).
Give me apps that adhere to NT profile policies, and that can run in an entirely read-only environment, and you'd be surprised how secure I can make that workstation.
