[Fed-Talk] different bend to OSX vs Windows as most secure
[Fed-Talk] different bend to OSX vs Windows as most secure
- Subject: [Fed-Talk] different bend to OSX vs Windows as most secure
- From: Peter Link <email@hidden>
- Date: Mon, 15 Nov 2004 09:18:25 -0800
I read an article on one of MacCentral's forums last April
(might have been a year ago last April) that gave a very technical
reason why OSX is more secure than Windows and why Windows has
inherent security problems. I am not technical enough to challenge
what the author is saying about Windows, however what he says makes
sense to me. I use his technical justification every time someone
gives me the typical garbage about OSX being more secure only because
of its obscurity. The author did not include his(?) full name, only
his initials; JLL.
content follows, sorry for the length----
I'll address several issues here. I'm a programmer by trade, and have
been creating UNIX programs, filters, and drivers since '82. My name
is in the '94 and '94 Yggdrasil Linux "Plug-and-Play" books, so I've
obviously been a Linux hack since '92. I also write Windows programs
using Visual Studio, and have been porting my tools from Linux to OS
X since the beta. So, I think I *might* be qualified to say what I'm
about to say.
Remember: a "virus" is a set of invasive routines which have been
attached to a legitimate program. A "worm" is, in essence, a detached
background process.
Creating a UNIX "virus" would require the writer to muck with program
text and data segment pointers, and change the program initialization
pointer from the "crt0.o" equivalent to something else. The degree of
difficulty here is at least 9.5 on a scale of 1-10... even if you
*do* have the source to the runtime invocation routines. Then, to
screw up the system, you have to attain root privileges from within
the attached routines in that user-privileged program, which is
indeed quite a bit harder. It's not impossible with the default OS X
install, but it ain't easy. The easiest way to defeat this is to
create a root account with a scrambled password on *EVERY* *NIX
system you use, and that includes OS X.
Writing a UNIX "worm" is easier. Any program can create a detached
process. BUT, the same issues with user-level vs. root permissions
exist. Worms will run on properly protected systems, but they may
never be able to attain the privileges necessary to do significant
damage.
Now, these are not easy tasks. It's *much* easier to write a simple
script that fools Windows into thinking that an offending program is
actually something the user *wants* to run. Windows does *NOT* have
user-level protections - and that's why viruses and worms are so easy
to invoke on Windows.
Lastly: each task on a *NIX program runs in its own virtual memory
space. Programs running within these virtual spaces are not allowed
to "touch" devices or other system resources. Instead, programs make
requests to the system for system resources. Even the graphics
subsystem runs as a task under OS X. Hence, a "buffer overflow"
within the OS X desktop would cause the desktop to crash and restart,
but shouldn't cause any other problems.
Windows has incorporated graphics routines into its kernel. Hence, a
"buffer overflow" in one of the graphics routines causes the kernel
to respond with a handler. If you write your virus properly, the
handler will execute *virus code* as the handler... and the virus has
now attained system-level capabilities. The Windows kernel thinks it
is running legitimate code, but it is running the virus' code --
which just happens to now be running as the system-level error
handler. And, without user-level privilege protections, you can
do.... anything.
That's how it's done, folks.
-----
MS has several bedrock problems, which at this point sort of coalesce
into one problem. First, and deadliest sofar, is the lethal alchemy
between extraordinarily permissive interfaces (why, exactly, can Word
macros delete system files?!) and commingled code. Second is their
interpretation of user friendliness, which involves having all kinds
of things going on in the background automagically - and this is as
much of a problem as it is precisely because all the interfaces that
make this happen are permissive. Third, features always trump
security. This means on the one hand that (you guessed it) interfaces
are permissive (so that there are fewer obstacles for software
developers and power users - including dishonest ones) and also that
many security holes come with built-in disincentives to plug them:
There was a great deal of justified moaning when we ordered everyone
in the office to turn off message previewing in Outlook, because it
really is a nice feature. Lastly, MS still hasn't acted on the
information that 90% of security lies in picking sensible defaults.
This, again, is really another facet of the problem that every other
point here is a facet of: It's convenient and featureful for all the
services to be going, and a minimum of ports to be obstructed, and
for interfaces to be permissive - so they are.
This set of attitudes has been codified into years upon years of
legacy; into billions of dollars of investments, and into MS'
strategy of mollycoddling developers. Even their half-hearted attempt
at a competently engineered OS (NT/2000) went nowhere until they
rolled in a lot of compatibility with Win9x - which is, and has
always been, a security nightmare. So it doesn't really matter how
many security experts they hire, because the experts are left with
the unenviable task of turning a glass house into a fortress. That's
not how security works: Fortresses are designed from the get-go to be
fortresses, and for Microsoft it's years too late to go back to
blueprints.
Then, of course, there's the monster under the bed that nobody wants
to mention. All the armchair security analysts blathering on about
how OS X is only defended by security through obscurity (ha!) should
take note: MS CEO Steve Ballmer has come out and said, reluctantly,
that Windows Messaging - the core of every version of every one of
MS' operating systems - is a sieve, and if anyone found out just how
to take advantage of that... well, do the math. Unfortunately, one of
the things I learned talking at length to Microsoft developers is
that large portions of that code are black boxes. The people who
wrote them are long since gone, the code is ancient, nobody knows how
it works. Whole swaths of Windows are built by attempting an
implementation and hoping that it didn't break anything down in the
pit of the OS. NT didn't change this. 2000 didn't change this. XP
didn't change this. The security experts can't change it: first. you
can't change what you can't understand; second, since Messaging is
the foundation on which Windows is built, redesigning and
reimplementing it would be an unfathomable nightmare (you'd have to
test and make sure that nothing in Windows, or in Windows
applications, broke!); last, the interface is permissive, and secure
implementations of insecure interfaces are impossible - and again,
all of Windows and all Win16 and Win32 apps assume that interface.
The security experts are tasked with bandaging the Titanic.
I haven't even listed all of the ways Windows is insecure. This is
just one example.
This is why MS is trying to keep the Messaging code hidden by all
means, and protected by any number of big Federal laws with sharp
teeth. But this is all still security through obscurity, and Federal
laws mean nothing to hackers in, say, North Korea.
What nobody wants to face is the fact that 95% of the computing world
is built on a house of cards, and the current epidemic of viruses and
worms only hints at what could happen if someone really found the
soft spots in the world's de facto operating system.
We can all hope that that day doesn't come.
__________________
JLL
--
Peter Link
Organizational Information System Security Officer
System Manager for Initiatives
Administration and HR Directorate
Lawrence Livermore National Laboratory
P.O. Box 808, L-664
Livermore, CA 94550
email@hidden
(925) 423-1230
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden