[rescue] NeWS

[Jonathan C. Patschke]

On Thu, 2 Feb 2006, Charles Shannon Hendrix wrote:

> Can you really blame a developer for using admin privs to work around
> that kind of tech support nightmare?

Yes.

When their application starts up it can check for some sort of
checkpoint flag in the Registry, and, if that flag is not present, the
program can spawn some setup widget when it is first run.

> As far as admin privs goes, part of the noise generated by Starforce
> is that installing filter drivers using a Windows priv elevation
> exploit is old news. That's a security flaw, and I don't think it has
> been fixed either.
>
> I worked with a Windows system hacker who showed me how he could do
> this with a standard user account and a C compiler, so I know it is
> possible.  I know he was able to do it up to Windows 2000, which
> shares an awful lot with Windows XP.

That depends on what you mean by "standard user account".  In Windows
2000, I believe that typically meant being a member of the Power Users
group, which means you can load some device drivers.  If you don't have
permissions to load device drivers, you can't exploit this.  Typical
users do NOT need permissions to load device drivers to do what they do.

This was a stark change from NT 4.0 and earlier where "regular users"
couldn't even adjust the workstation's clock.

>> Suppose I wrote a character device driver (which allowed writes from
>> UIDs > 0) for Unix that took pairs of ordered integers like this:
>
> Of course you can do bad things with UNIX.
>
> But I don't think we'll ever see things get as bad.
>
> For one thing, a UNIX system is a whole lot more visible than a
> Windows system, and has a lot of tools for preventing and finding
> problems like this.

Windows has regedit.  Troll HKLM\System\CurrentControlSet\Services and
HLMK\Software\Microsoft\Windows\CurrentVersion\Run* to find out what's
getting loaded when.  Yes, drivers can obscure that, but VFS patches
loaded into Unix can obscure configuration files and library files just
as easily.

> I can check just about everything on my UNIX boxes very quickly,
> including checking for unwanted kernel bits.

Not if one of the drivers you loaded patches the loadable-module list so
as to obscure itself.

> So I recognize the potential for problems, but also see that it would
> be a much different game than on Windows.

Administrator access is the same anywhere.  When you're -loading code
into the kernel-, you have the power to change the rules.  I don't care
if you're running VMS; if you can load code into a running copy of the
OS, any pretense of security is reduced to the level of faith you have
in the author of that code.

> Incidentally: I never hear anything about issues like this for MacOS
> X.  Is it just not popular enough yet?

Not enough people have complained.  The kernel extension system on Mac
OS X is very vulnerable to abuse by unscrupulous developers.

-- 
Jonathan Patschke    )   "A man who never dreams goes slowly mad."
Elgin, TX           (      --Thomas Dolby, "Valley of the Mind's Eye"