[rescue] NeWS

[Jonathan C. Patschke]

On Tue, 24 Jan 2006, Charles Shannon Hendrix wrote:

>>> The Windows driver system allows layered drivers which not only
>>> allow software houses to install viral programs which hurt my system
>>> and my ability to use it, but open up security holes all the way to
>>> ring zero.
>>
>> To be fair, lots of Unix variants do this too.  Anything that
>> supports vendor-provided binary-only drivers has similar security
>> properties, whether it's Linux, OSX, or Windows.
>
> Which UNIX variants have the system Windows has for driver filters?

Once you're in the kernel, you're in the kernel.  Any operating system
with a monolithic kernel and facilities to load code into the kernel at
runtime suffers those vulnerabilities.  This is why security-conscious
operating systems disallow loading code into the kernel once the system
is running multiuser.

Case in point, I'm writing a kernel module for FreeBSD that snoops
mount/unmount events and, based on the type of filesystem mounted,
provides sysctl variables for tweaking filesystem parameters and
for activating code injected into the UFS and GEOM drivers to extend
filesystem functionality.

Now, I'm a Good Guy and don't write malware, but it'd be trivial to
adapt this same methodology for wrapping read and write syscalls to do
Bad Things (an age old trick) or for wrapping mount/unmount to disallow
mounting of ISO/Joliet filesystems without some weird garbage in a
comment field or some other anomaly detectable by querying the
underlying I/O device around the cd9660 filesystem driver.

> As far as I know, nobody else has been that stupid except for
> Microsoft.

Microsoft is a sad case because they have a microkernel operating system
and could be a lot more discrete about what they let touch the hardware
and kernel memory.  Supposedly Windows 6.0 addresses this problems by
(finally) gating I/O accesses in such a way that they can be done from
userland (given the kernel's blessing, of course).

> Binary only drivers definitely are *NOT* a similar security problem.
>
> I'm talking about something quite different.
>
> Read up on Starforce and things like that to see what I mean.

You think that'd be hard to implement in Linux or BSD or even Solaris?
Wrap the mount syscall.  If it sees their crap in the first N blocks of
the CD but can't verify the presence of some hidden trash in the areas
of the disc outside the ISO 9660 filesystem, return EINVAL.  Add a
character device that accepts queries to find out whether a program is
running from a directory that exists on a filesystem mounted from a
device that their kernel module blessed.  No kernel module implementing
that character device?  Oh well, the program won't load, then.

The main differences in the case of Windows are:
   1) "Normal users" generally are assumed to have "root" access, so the
      Win32 equivalent of the syscall table can be patched by anyone,
      making this sort of thing easy to do without prompting the user.
   2) Windows users seem to think that putting up with this sort of crap
      is a fair price to pay for a sucktastic operating system and sundry
      entertainment products.

If Windows users would wholesale disregard products that rape their
computers, this would be a non-issue.  However, a very large portion of
computer sales are driven by games, most of the products playing nasty
with the OS are games, and most games are played by whiny children who
would much rather no do productive things with their computers, anyway.

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