Windows Security Holes Go Mostly Unexploited

murky.waters writes "Wired News has an article with a decidedly different take on security holes in Microsoft Windows: Despite the thousands of known exploits and virii, most MS users aren't target of much harm, and the big guns such as Klez have had almost no effect on home users. An interesting read that, if true, challenges some common arguments."

Comments

Good thing

[terrymr]

Yeah just imagine the chaos if all of these flaws were exploited.

Wired should recognize the Mac security record.

[Anonymous Coward]

Wired should recognize the Mac security record. Especially when discussing remote exploits.

It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.

The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on historical evidence.

In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely.

That is why the US Army gave up on MS IIS and got a Mac for a web server.

I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits ) I am talking about current Mac OS 9.x and earlier.

Why is is hack proof? These reasons :

1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"

2> No Root user. All Mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.

3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The Mac avoids C strings historically in most of all of its OS. In fact even its ROMs originally used Pascal strings. As you know Pascal strings (length prefixed) are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.

4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.

5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.

4> Stack return address positioned in safer location than some intel Osses. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.

7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc). But some huge high performance sites use load-balancing webstar. Regardless, no mac has ever been rooted in history of the internet, except with a strange 3rd party tool in 1995.

8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.

Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.

One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event or a rouge 3rd party CGI tool ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc. They few mistaken defacements recently attributed to Mac OS are actually Mac OS X (unix) events.

I think its quite amusing that there are over 200 or 300 known remote exploit vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.

Not one remote exploit. And that includes Webstar and other web servers on the Mac.

A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.

BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.

--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.

BugTraq concurs! As does the WWW consortium.

you are confusing me.

[twitter]

I mean, think about what an exploit really is: Somebody has taken a feature of Windows and turned it against the user or the user's machine. The problem I see here is that you can't have a totally secure machine and have all those fancy features you like.

I'll give you an example: I use Outlooks's to do list to keep track of my tasks. There's a feature where you can attach shortcuts to each task. I've found this handy, whenever I need to do my time sheet I just pull up the task and double click the shortcut inside of it. Now, in order to 'crack down' on security on my computer, I turned off a bunch of those handy-dandy features and found myself unable to launch that shortcut anymore!

Now, before you start saying "Oh, MS could easily fix that...", instead think about the real problem here. Either I don't use that feature at all, or MS has to think of every single malicious use of a feature and only allow the non-dangerous ones. Sorry, that's not a good solution. You're holding MS (or anybody else) responsible for other people's creativity.

Umm, you might fault M$ for not using the reasonable and common security model of unprivlidged users to interact with an untrusted network. While I must congratulate you for figuring out how to make M$ and Lookout do things for you, have you ever considered the posibility of running Lookout as something other than "administrator" or super user so that tasks that can be assigned by others by email with links to malicious servers don't blow up your system files? Wow, what a concept. The rest of us will consider automatically executing code from email and tasks as root to be crimianal negligence. Not only was M$ aware of the problem before it shipped Lookout, but everyone with a clue warned that the results would be catasrophic.

Now, what was your point? That M$ is insecure because it has so many "features"? Get real.