Move to Intel a Security Non-Issue for Apple

 
 
By Larry Seltzer  |  Posted 2006-01-30 Print this article Print
 
 
 
 
 
 
 

Opinion: OS vulnerabilities are a result of OS characteristics, and the CPU they run on is pretty much irrelevant.

I guess Black Hat just gets hackers excited and optimistic for more bad news. This leads them to believe, for example, that Apples move to x86 for the Mac will make the platform less secure.

Claims like these raise basic questions about what creates a vulnerability in an operating system and how attackers exploit them. The short answer is that rarely, if ever, are the existence of vulnerabilities related to the specifics of one processor architecture versus another.
And the fact that a programmer may be familiar with programming Windows on an x86-based system is of only small advantage to him (or her) when attacking Mac OS on that same system.

One other argument for why its easier to exploit x86 chips is the old CISC vs. RISC debate, but essentially in reverse. The notion is that its easier to program CISC processors in assembly language, so its easier to write exploit code. This has only the slightest suggestion of truth to it. On top of being largely irrelevant, its not even as true as it might seem. The PowerPC instruction set is famous for being the most complex of RISC instruction sets. It does have many RISC characteristics like regular instruction formats (all 32-bit), but it does many unRISCy things, like permitting misaligned data access.

For many, but not all types of vulnerability research, researchers need to be able to trace through programs in a debugger, examining their behavior at the most basic level to see if there are ways to exploit it. So you absolutely need some familiarity with assembly language programming, although you dont really need to be a good programmer. (Its always easier to break something than to build it.) To read more details about Apples Intel-based Macs, click here.

And once you find a vulnerability, you need to exploit it and, usually, to inject and execute "shell code," which is a software environment in which you can execute arbitrary commands. Most programmers pull existing shell code out of other exploits that are easily available and certainly there are some around for PowerPC. But even if you had to write one, I suspect it would be easier to write it in C and compile it. If you ever look at exploit code that gets passed around on the Internet, its usually mostly C with a big block of data that comprises the shell code declared as hex values. Theres a lot more assembly analysis than assembly programming to exploitation.

And its not uncommon for vulnerabilities on operating systems and applications that support multiple CPUs to be exploitable on all of those processors. The vulnerability is in the structure of the program, not strictly in the implementation generated by the compiler. Youre far more likely to be able to leverage an exploit from the PowerPC Mac OS on the x86 Mac OS than you are an x86 Windows attack on x86 Mac OS. Apple has had no shortage of vulnerabilities disclosed in the last several years. FRSirt lists 33 for the last year, and 13 of them are rated as "critical." Why were there no major exploits of these vulnerabilities? Was it because they were too hard to do? Of course not. They werent worth exploiting because there are a dearth of actual Mac systems out there, and they have reasonably good defenses available to them.

So what changes when the Mac moves to x86? If Apples market-share shoots up and attackers suddenly have a better shot of finding Macs to attack, then more malware will be written to the Mac. But it wont be any easier to exploit for being on x86.

Lots of real vulnerability news comes out of the average Black Hat conference, but theres also typically a share of weird ideas out of left field, and this is one of them. Perhaps those black hats are on a bit too tight for the arteries in the brain.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. More from Larry Seltzer Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel