The First Cleo Loves Mac's Thread

[MrMaryLou]

Come on Cleo

[DangerDave]

NO! NO! NO!



DD

[Surfn]

Mac who? Mac Davis? |rasta|

[digifan]

Please Cleo...

don't even listen to these bad boys

[Cleo]

Yeah Macs…
That brand of fruit that doesn't have worms. :p

[Surfn]

Originally posted by Cleo
Yeah Macs…
That brand of fruit that doesn't have worms. :p

What brand of worms DO you have?

[amber438]

hehe..

omg..hope ya got to see the MacQuarium before the board crashed..

[Extreme John]

Are we talking about MacDonalds? Mac & Cheese, the IMac Theatre?

[Cleo]

Cleo takes the MacBait…

Here are two posts from MacCentral and AppleInsider:

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.

[Greenguy]

We can't call Cleo a Mac Daddy, so I guess she's a Mac Mommy