i don't see how the processor is going to make the OS any less secure. i mean, that's like saying powerpc versions of linux and the bsds are more secure than their intel counterparts.

LOL. Yeah there's lot of viruses written in assembly out there that exploit the processor architecture. Please. Those "experts" are just looking to get some press coverage. Almost every PC virus out there runs in user mode and is designed to exploit some flaw in Windows.

Nuff said.

When a writer cannot differentiate between an OS and a CPU, along with their relative structure and coding, then they have absolutely NO RIGHT to write their comments for the general public and pass them off as real/valid information. This is obviously per HYPE... pure FUD (Fear, Uncertainty and Doubt)... to get more hit son their article's webpage. Sad... very sad and pathetic indeed!

Please, note that one of these "experts" works for Symantec Corp., a company that lives on the users' fear of exploits and another one for IBM, whose processor has been replaced by Intel's in iMacs.

So are we to believe that Linux running on PPC is more secure than Linux running on x86?

I'm sure glad we have these "experts" around to keep us informed.

It's amazing the lengths people will go to, making apologies for Windows. As if its awful security is all the fault of x86 processors.

Sorry, Paul F. Roberts, but there are some operating systems that manage to run on Intel x86 chips AND be secure at the same time.

But you'd rather that people never get a clue, because as long as they think Windows-level insecurity is an embedded flaw of x86 processors, they'll be lenient towards the shoddiness of Microsoft's OS and chalk up all its problems to Intel. Which, as an added bonus, means that the anti-malware industry would be constantly showered with money as people brace for the deluge of virii and trojans and exploits that will hit every x86 operating sytem, which is "inevitable" according to all the computer security experts looking to sell a product. Because let's be honest here, Mcafffe and Symantec and the like are essentially terrorists.

Well, i have to agree on one point; Microsoft has had more practice in fixing security exploits after they have become public.

=)

It's not the processor people are hacking into it's the OS and that OS is Windows because it's not safe. OSX on the other hand was built with security features in mind from the very beginning and that includes the Intel version they have been developing all along side the PowerPC version. This is just a bunch of non-sense thrill seeking reporting to spread a lot of FUD about OSX because they have no sensational news to write about it otherwise. 5 years and counting and still no viruses, spyware, trojans, or hackers have been able to get into an OSX machine.
That's why I'll stick with Apple and OSX hardware and software.

Hardware exploits can lead to severe damage. Security is not just about the OS. Its the OS and the hardware.

Intel Core Due Bugs

http://geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif

"The typical x86 exploit, for example, finds a way to cause a buffer overflow, and then uses the overflow to get the CPU to execute code it shouldn't.

It seems pretty clear from the record that people have been a lot more successful at part one of this with Windows systems than with Linux or other Unix systems. However, if an exploitable software problem is found, the exploit itself is no more difficult to write for Linux on x86 than for Windows on x86 because such exploits are hardware, not OS, dependent.

Those hardware weaknesses do not, however, exist in the same way or to the same effect in non Intel chipsets like those of the G5, the UltraSPARC, Cell, or Xenon. As a result finding a part two method on these CPU sets is at least as difficult, if not significantly more so, than part one. That's why there have been hundreds of widely publicized Solaris and MacOS X vulnerabilities for which there are no actual exploits and therefore no victims.

So, bottom line: when Darwin/MacOS X goes x86 the people who focus on finding and exploiting vulnerabilities may still have a harder time with part one of the usual exploit process than they do with Windows, but the part two hardware barrier to real success will be gone."

http://blogs.zdnet.com/Murphy/index.php?p=431

X86 is a bad choice, and will lead to OS X exploits. If you learn anything about circuits you'll learn that everything you can code in software can be design in a circuit... code ends up turning into 0's and 1's.... Dangerous stuff.

http://www.macobserver.com/article/2006/01/26.14.shtml

First, web browsers - and any other programs that access the internet - should not be able to delete or modify any file in your home directory (or anywhere else that you have write permission.) [The capability already exists in OS X - and most other Unix systems - in the form of "chroot jails" or just simple setuid with permissions and/or access control lists, and will also be implemented as Vista's "IE Sandboxing" feature.]

Second, the firewall should prevent applications from both accepting *and making* unauthorized connections to and from the internet. [Little Snitch already does this on the Mac, as does ZoneAlarm on the PC and the upcoming Windows Defender feature in Vista.] Suspicious behavior - for example sending bulk e-mail, or accessing the net when you aren't using your machine - should require specific permission.

Third, stack and data segments should not be executable. [This is known as "NX" (i.e. no-execute) bit support on the x86, and already exists in several operating systems including NetBSD and 64-bit Windows, and Vista will support it on 64-bit chips.]

Although OS X has a great track record, there are certainly features and bug fixes that could - and should - be added to make it more secure and reliable.

Although Linux and Solaris on x86 have had fewer security vulnerabilities than Windows, the fact remains that there are going to be more hackers attacking OS X on x86 than there were on PowerPC.

My x86 Linux box was vulnerable to a security hole in Apache, the web server which ships with Mac OS X (it was hit before Red Hat incorporated the bug fix.) Linux has a different system call interface, but it would be relatively easy to modify an x86 Apache exploit to run on the intel version of OS X.

Quote

Guest wrote:
"The typical x86 exploit, for example, finds a way to cause a buffer overflow, and then uses the overflow to get the CPU to execute code it shouldn't..."

HAHAHAHAHA!!!! Right about this point you can disregard this post as crap. Man thats worse that the original article. Wow and all this time I thought CPUs did operations on registers! How is a buffer overflow an x86 exploit?!? It's up to the OPERATING SYSTEM to manage memory usage.

Dude in the future please try to at least have some knowledge on a subject before making some big post about it. Geez.

Quote

Biff wrote:
HAHAHAHAHA!!!! Right about this point you can disregard this post as crap. Man thats worse that the original article. Wow and all this time I thought CPUs did operations on registers! How is a buffer overflow an x86 exploit?!? It's up to the OPERATING SYSTEM to manage memory usage.

Dude in the future please try to at least have some knowledge on a subject before making some big post about it. Geez.

http://en.wikipedia.org/wiki/Memory_buffer_register

http://en.wikipedia.org/wiki/Buffer_overflow#Buffer_overflows_on_the_stack

you can't have memory with out registers

http://en.wikipedia.org/wiki/Processor_register

I'm going to suggest that you actually read the original article to see what we said would and would not translate.

Quote

Guest wrote:
Third, stack and data segments should not be executable. [This is known as "NX" (i.e. no-execute) bit support on the x86, and already exists in several operating systems including NetBSD and 64-bit Windows, and Vista will support it on 64-bit chips.]

If you look at MacOS X developer technotes, you will find a recent technote about how one C extension of the gcc compiler (local functions like in Pascal) cannot be used on MacOS X for Intel, because their implementation conflicts with a security feature that makes code on the stack non-executable...

That's at least one thing that the security "experts" think would be needed to make MacOS X on Intel safe, that is already there.

The CPU <does> have something to do with security - it's not entirely the OS.

In particular, old Intel CPUs allowed execution of code on data pages (==stack). Easy exploit for overflows. Newer CPUs, including the one in Macintels does not allow this, from what I understand. So that exploit's restricted.

Secondly, instructions on PowerPC must be word-aligned. So smashing the stack has a one-in-four chance of having something word-aligned. Not aligned -> exception -> exploit fails. Intel instructions don't require alignment, so if an exploit can get it onto a code page (this ought to be very difficult) it will succeed.

Quote

Guest wrote:
http://en.wikipedia.org/wiki/Memory_buffer_register

http://en.wikipedia.org/wiki/Buffer_overflow#Buffer_overflows_on_the_stack

you can't have memory with out registers

Yeah thanks chief. No kidding. My point was that the concept of overwriting memory to get new commands sent into the CPU is not some x86-specific concept. It's like, you know, how CPU's work, dude.

Thanks to the last poster for actually knowing what he was talking about when he posted. Newer CPU's do offer execution protection that the OS can take advantage of for increased security. And this will be critical moving forward for helping to prevent numerous exploits. But this is just a fix for a general problem. It's not patching some fundamental flaw in x86.

I believe the article meant well. It might be expecting a little too much for someone who writes for TMO to truely understand things at such a low level. I'm not saying that to be mean. Seriously very few software developers even have a clue about this stuff. So without a real understanding, this might seem like a valid concern. But the reality of the situation is that we will see no difference due to the processor architecture switch.

At the time context of the CPU switches to a process other than the OS, the OS does not know what the CPU does. So the OS has to set the CPU into the right state before the context switch and trust the CPU to enforce the restrictions set on the following instructions. This is particular to memory read/write procedures, in which the CPU must know what memory the current process is allowed to read/write. Of course, it's a lot more complex than that. The essence is that the OS cannot directly control the flow of another process once it is in a running state.