45 replies to this topic

[army_of_one]

In my spare time, I try to design and engineer high assurance systems. There are usually some carefully chosen design goals, such as having no 0-days or total isolation of components in distributed design. There are systems that can nearly guarantee any one of these, but not all as complexity rises too quickly. Recently, I've been looking into a desktop system that stops known and unknown viruses cold. Essentially, one has to prevent them from executing. But how? virtualization? I'm looking at a different approach: PowerPC.

The idea is simple: malware is designed to target a specific platform. It hooks into a particular OS and executes on a particular CPU. One can make a cross-platform virus on the OS-level, but doing so on the CPU level is harder. x86 code doesn't run on PPC. So, let's just put linux on PPC? Maybe nice for servers, but not for Windows-grade desktop. There is one industrial-strength desktop OS on PPC: Mac OS X. There are many inexpensive PPC Mac OS X PC's on eBay. Additionally, Flash 9 is on Mac PPC. Flash support is a real stumbling block, as they are discontinuing PPC support and the open-source alternative on Linux doesn't support many popular web sites. This isn't all that disheartening: we still have a PowerPC desktop with [hardened] Mac OS X running up to Flash 9. And this system is likely immune to any shellcode that hits it. This greatly reduces attack surface of wild threats.

In order to defeat the shortcomings of limited Mac OS X support, I looked into virtualization. I believe there is a VirtualPC program that runs x86 Windows on Mac OS X PPC. A hardened version of WinXP could be used to surf .NET, Flash, Silverlight, etc. web sites. Most other stuff can be done using proprietary or open-source software in the Mac itself. Targeted exploits will still work in this scheme, but most infections aren't custom-designed to exploit just one PC. I think this general scheme of using a PPC desktop with non-Windows main OS will successfully most shell code in the wild. Specificially, a DOS attack (i.e. program crashed by exploit) is the best they will be able to do, while no botnet or similar logic will be able to run.

What do you guys think about this scheme? About PPC/Mac's providing convenience/ease-of-use + security in same package? Any comments on my WinXPx86 on MacOSX-PPC idea? Any suggestions?

Edited by army_of_one, 03 April 2009 - 02:35 PM.

[phasma]

Wait, so if x86 doesn't run on PPC then would allocating memory while coding be any different?

[G-Brain]

In my spare time, I try to design and engineer high assurance systems.

You're paranoid?

Recently, I've been looking into a desktop system that stops known and unknown viruses cold. Essentially, one has to prevent them from executing. But how?

Viruses / malware attempt to change the operating system for themselves to run at startup/hide themself, etc. As long as you need specific permissions to do this (by a root user, for example) and only allow normal users to change files that they own, you should be safe. Permissions done right™ as in Unices as opposed to Windows should do the trick. For vulnerabilities, just run stable versions of software and watch mailing lists.

I'm looking at a different approach: PowerPC.

The idea is simple: malware is designed to target a specific platform. It hooks into a particular OS and executes on a particular CPU. One can make a cross-platform virus on the OS-level, but doing so on the CPU level is harder.

You can write binary code that runs on Windows, OSX and Linux? Show me.

So, let's just put linux on PPC?

This has already been done.

Maybe nice for servers, but not for Windows-grade desktop. There is one industrial-strength desktop OS on PPC: Mac OS X. There are many inexpensive PPC Mac OS X PC's on eBay. Additionally, Flash 9 is on Mac PPC. Flash support is a real stumbling block, as they are discontinuing PPC support and the open-source alternative on Linux doesn't support many popular web sites. This isn't all that disheartening: we still have a PowerPC desktop with [hardened] Mac OS X running up to Flash 9. And this system is likely immune to any shellcode that hits it. This greatly reduces attack surface of wild threats.

Shellcode that hits it?



Sure, you can switch architectures and operating systems, but malware creators will catch up if that's the only change you make. Permissions done right™ have done the job for me for a long time now.

[army_of_one]

Viruses / malware attempt to change the operating system for themselves to run at startup/hide themself, etc. As long as you need specific permissions to do this (by a root user, for example) and only allow normal users to change files that they own, you should be safe. Permissions done right™ as in Unices as opposed to Windows should do the trick. For vulnerabilities, just run stable versions of software and watch mailing lists.

I agree and disagree. You proposed good tactics. Too bad many users don't (or sometimes can't) follow it. Using a PPC-Mac w/ very minimal security guidelines defeats native code malware without the user even needing to think about it. My server design combines ur suggestions with PPC by using enterprise Linux distro (usually SUSE) on PPC, with the usual Linux security practices. As for malware behavior, many exploit flaws in operating system and permission in order to do those things. If they can't even execute, exactly how are they going to exploit even an unpatched system?

You can write binary code that runs on Windows, OSX and Linux? Show me.

"Binary code" that's cross-platform? Funny misquote, there. I said a cross-platform malware: implementation was unspecified. There's already proof-of-concept code for virus that infects on Windows and Linux {1}. They are currently low-risk, as there is no practical need to hit anything other than unpatched Windows systems, but they are possible. I figure running same binary code on x86 and PPC much harder, if not impossible. There are other potential cross-OS methods, but I'd rather not give bad guys ideas to try. No legitimate use that I can think of...

So, let's just put linux on PPC?

This has already been done.

No shit. Reader comprehension lacking, there, or maybe I was unclear. Obviously not proposing to port linux, as this has been done. You could paraphrase it, in context, this way: "We could use PPC Linux to implement this scheme, but as a desktop & web-surfing OS that would leave much to be desired." One goal of the software is to protect lay people and support most Web sites (Flash included), so why would I use Linux? lol That's what i meant.

Shellcode that hits it?

"...malware creators will catch up..."

Shellcode is the payload of the exploit code. This is the attack, this is what they want to run. If the code can't execute, then the attack mostly (or totally) fails. x86 shellcode doesn't run on PPC. As for malware writers adapting, you are correct. That's why I published this on BinRev and any commercialization will be word-of-mouth or direct advertising. As long as its very uncommon, then we can reap the benefits of not being worth their time. As I said in original post, the scheme is vulnerable to focused attacks and attacks that have nothing to do with the ISA. However, if we combine it with basic security suite then it should make for a secure and easily used web browsing system for lay users. If they can use a Mac, they can use this. Exploit malware economics to provide extra security at little extra cost. That's the idea.

You're paranoid?

It's hard work, but someone has to watch out for your ass. I wouldn't say I'm paranoid, but I couldn't sleep at night knowing my critical software was running on OpenBSD: just not that safe.

References

{1} Cross-platform infection proof-of-concept
http://www.eweek.com...-Windows-Linux/

Edited by army_of_one, 03 April 2009 - 04:49 PM.

[Aghaster]

Data Execution Prevention

PPC won't really save you. What you need is a real way to prevent execution of data, which is what happens most of the time when you exploit a buffer overflow vulnerability.

To get a very general idea of how it works:

1) You need a place in your program where the input length is not checked, so you can overflow it.
2) If you input too much in an array for instance, then whatever overflows it overwrites other stuff. That's where the fun begins.
3) When you call a function, it saves the return address of the line following the function call so that it can return to that address after execution of the function. However, usually, your variables local to your function end up being right under your return address in your stack. What you want to do is overflow the unchecked input to the point where you overwrite the return address, so that when your function returns, it will return to what you've told it to go.
4) Still, you need to give it an address which will do what you want to do. That's where you want to do shellcoding: you're going to make a very small chunk of executable code which is going to open a shell. One problem that often happens is that you need to pass this chunk of code in the unchecked input. The input is usually expected to be text, which is terminated by a byte with the value of 0 (in C/C++). Your shellcode should not contain zeros, otherwise it won't get through.
5) The address you've put in 3) should point to your shellcode in 4), and that's one of the hard parts of writing an exploit: it is quite hard to determine where it ends up in memory.

This is just a VERY simplified explanation, and is nowhere near complete or completely accurate. I suggest you get the book "Hacker: The Art of Exploitation" or "The Shellcoder's Handbook". They are very good books on the subject.

[Ohm]

Lol, "hardened OS X." I just had to laugh at that.

You're going down the wrong road. A very, very wrong road. What you've done is essentially security through obscurity. No automated attacks will succeed because no one in their right mind would write automated malware targeted at OS X on PPC (a dead platform). Yet the sacrifices are pretty high, especially as time goes on.

You also speak of "having no 0-days." If this is your mindset, kindly remove any trace of your head from your colon. The whole point of a 0-day is that no one can see it coming. It was something no one anticipated at all, and can strike any software on any platform. But again, you have the advantage of running on a platform no one in their right mind would target.

This sounds like a solution to a problem that doesn't exist. What is the malware problem? If you're using a normal browser on a normal OS and keep both the OS and browser updated, what are the risks of malware? They're quite low to begin with. Add anti-virus, a firewall or even sandboxing to the mix (see Sandboxie) and the risks are approaching nil. It takes just a few minutes to set all these things up. So what problem are you trying to solve here? What justifies running an OS you probably don't want to run, that isn't being maintained (since you have to run older versions), and that you have to run on a dead platform?

I doubt you thought this through before you started. Identify a problem, analyze the problem, then think of a solution.

[R4p1d]

Lol, "hardened OS X." I just had to laugh at that.

You're going down the wrong road. A very, very wrong road. What you've done is essentially security through obscurity. No automated attacks will succeed because no one in their right mind would write automated malware targeted at OS X on PPC (a dead platform). Yet the sacrifices are pretty high, especially as time goes on.

You also speak of "having no 0-days." If this is your mindset, kindly remove any trace of your head from your colon. The whole point of a 0-day is that no one can see it coming. It was something no one anticipated at all, and can strike any software on any platform. But again, you have the advantage of running on a platform no one in their right mind would target.

This sounds like a solution to a problem that doesn't exist. What is the malware problem? If you're using a normal browser on a normal OS and keep both the OS and browser updated, what are the risks of malware? They're quite low to begin with. Add anti-virus, a firewall or even sandboxing to the mix (see Sandboxie) and the risks are approaching nil. It takes just a few minutes to set all these things up. So what problem are you trying to solve here? What justifies running an OS you probably don't want to run, that isn't being maintained (since you have to run older versions), and that you have to run on a dead platform?

I doubt you thought this through before you started. Identify a problem, analyze the problem, then think of a solution.

His method is a good method, analyze and fix the problem before it is a problem.
Taking extra steps in the security business isn't a bad thing, it's putting you ahead of the game before the other team comes up with a new game plan.

Edit: This isn't the most secured platform, not nearly, it's just another precaution one can take to prevent malware, and it's a cheap and easy alternative to implement.

Edited by R4p1d, 03 April 2009 - 05:28 PM.

[army_of_one]

Lol, "hardened OS X." I just had to laugh at that.

You're going down the wrong road. A very, very wrong road. What you've done is essentially security through obscurity. No automated attacks will succeed because no one in their right mind would write automated malware targeted at OS X on PPC (a dead platform). Yet the sacrifices are pretty high, especially as time goes on.

You also speak of "having no 0-days." If this is your mindset, kindly remove any trace of your head from your colon. The whole point of a 0-day is that no one can see it coming. It was something no one anticipated at all, and can strike any software on any platform. But again, you have the advantage of running on a platform no one in their right mind would target.

This sounds like a solution to a problem that doesn't exist. What is the malware problem? If you're using a normal browser on a normal OS and keep both the OS and browser updated, what are the risks of malware? They're quite low to begin with. Add anti-virus, a firewall or even sandboxing to the mix (see Sandboxie) and the risks are approaching nil. It takes just a few minutes to set all these things up. So what problem are you trying to solve here? What justifies running an OS you probably don't want to run, that isn't being maintained (since you have to run older versions), and that you have to run on a dead platform?

I doubt you thought this through before you started. Identify a problem, analyze the problem, then think of a solution.

I certainly thought this through, and it's only a thought experiment to begin with. You speak as if I'm actually doing all of this right now? lol. I run Vista on x86, all unnecessary services disabled. DEP is off because it prevents needed programs from running. I have aggressive antivirus w/ behavioral detection and firewall w/ IDS. I use Firefox w/ NoScript & Flashblock (or IE in protected mode). I religiously perform updates, think before I click "yes" to popups, and always have a backup handy. If I'm need high assurance web surfing, I have a VM w/ hardened WinXP Pro that uses either the same Firefox setup or Sandboxie & IE7. The VM only protects from exploits if their container files never leave it. I've still been hit hard with malware several times and that's really annoying.

The PPC desktop isn't a long term solution. If usable, I expected it to only work out for a year or so. "Hardened Mac" is a joke, but one can harden a Mac to make it more resistent to attacks. The plan would be to have a system for high-risk web browsing that's largely immune to viruses. That's useful. As for servers, one can currently run supported Enterprise Linux OS on commercially supported PPC hardware. The real issue is cost-benefit analysis. Is it worth the trouble? Yet to be determined: still thought experiment. Personally, I'd prefer a good browsing appliance or a minimalist XP/Linux laptop that I keep up-to-date and backed up. Then, if shit happens, I just clear it off and restore from backup, do any updates, etc. This is my current scheme and is more cost- and time-effective. I may still adopt a different ISA for servers though, seeing as OS and hardware support is still available in long-term. PowerPC and SPARC are the only two I'd consider.

[army_of_one]

Lol, "hardened OS X." I just had to laugh at that.

You're going down the wrong road. A very, very wrong road. What you've done is essentially security through obscurity. No automated attacks will succeed because no one in their right mind would write automated malware targeted at OS X on PPC (a dead platform). Yet the sacrifices are pretty high, especially as time goes on.

You also speak of "having no 0-days." If this is your mindset, kindly remove any trace of your head from your colon. The whole point of a 0-day is that no one can see it coming. It was something no one anticipated at all, and can strike any software on any platform. But again, you have the advantage of running on a platform no one in their right mind would target.

This sounds like a solution to a problem that doesn't exist. What is the malware problem? If you're using a normal browser on a normal OS and keep both the OS and browser updated, what are the risks of malware? They're quite low to begin with. Add anti-virus, a firewall or even sandboxing to the mix (see Sandboxie) and the risks are approaching nil. It takes just a few minutes to set all these things up. So what problem are you trying to solve here? What justifies running an OS you probably don't want to run, that isn't being maintained (since you have to run older versions), and that you have to run on a dead platform?

I doubt you thought this through before you started. Identify a problem, analyze the problem, then think of a solution.

His method is a good method, analyze and fix the problem before it is a problem.
Taking extra steps in the security business isn't a bad thing, it's putting you ahead of the game before the other team comes up with a new game plan.

Edit: This isn't the most secured platform, not nearly, it's just another precaution one can take to prevent malware, and it's a cheap and easy alternative to implement.

Seems like ur getting the idea. Current approach for lay users is do this, this, that, this, that, and hopefully nothing happens. This design has only one goal: stop all malware in the wild with no user consideration or involvement. All the real work, like proper configuration, would be done when its built. After its ready, it's backed up, then the end-user gets it. They just surf the web, send email, whatever. No worries about malware. The requirement to learn a new OS and the short-term nature due to discontinued support will probably prevent me from applying it. The only other scheme that prevents execution as well is DEP, as Aghaster mentioned. Unlike DEP, using different ISA provides the protection without breaking user's apps. Like you said though, it's by no means a secure system. I'd prefer improving on an HIPS like DefenseWall or a few architectural changes to Windows/Linux kernels. Would be much better in long run...

[R4p1d]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

[army_of_one]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

Your joking right? Funny I toss around an idea about a PPC box and u have a screenshot. lol. Yeah, I'm sure u don't have to much to worry about as far as malware goes on that one. PPC + Hardened SUSE for PPC + good habits is my main workable design in this thought experiment. That combines the security and support of an enterprise Linux desktop with the obscurity of PPC (Mac or IBM hardware). Flash and other plugin support was the only thing holding me back there. Forced me to have to consider Mac's, which I hate. Or keep relying on Windows VM's, with overhead and extra licensing costs. That's obviously Ubuntu, but what hardware is it running on?

Edited by army_of_one, 03 April 2009 - 05:45 PM.

[R4p1d]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

Your joking right? Funny I toss around an idea about a PPC box and u have a screenshot. lol. Yeah, I'm sure u don't have to much to worry about as far as malware goes on that one. PPC + Hardened SUSE for PPC + good habits is my main workable design in this thought experiment. That combines the security of an enterprise Linux desktop with the obscurity of PPC. Flash support was the only thing holding me back there. Forced me to have to consider Mac's, which I hate. That's obviously Ubuntu, but what hardware is it running on?

Have you ever considered gnash? It's an alternative to flash for PPC based machines.

I'm currently running this on one of my PS3's, hopefully I'll have my cluster up and running by the end of this month, I'm awaiting supplies.

Edit: It's not Ubuntu, it's YellowDogLinux with a GNOME interface.
When I get my cluster up, I'm going to be running a different OS.

Edited by R4p1d, 03 April 2009 - 05:49 PM.

[army_of_one]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

Your joking right? Funny I toss around an idea about a PPC box and u have a screenshot. lol. Yeah, I'm sure u don't have to much to worry about as far as malware goes on that one. PPC + Hardened SUSE for PPC + good habits is my main workable design in this thought experiment. That combines the security of an enterprise Linux desktop with the obscurity of PPC. Flash support was the only thing holding me back there. Forced me to have to consider Mac's, which I hate. That's obviously Ubuntu, but what hardware is it running on?

Have you ever considered gnash? It's an alternative to flash for PPC based machines.

I'm currently running this on one of my PS3's, hopefully I'll have my cluster up and running by the end of this month, I'm awaiting supplies.

Gnash is a good project. They've accomplished a lot. The problem is that they are still lacking full support for recent versions. For instance, they only have very limited support for Flash 9. Many websites always go with the latest version, which makes them unusable. I'm not sure about YouTube, but with IE I could only watch movies when I upgraded to Flash 9. Hopefully they will improve it in near future.

That's a PS3? I've never put Linux on PS3, but thought about it for like password cracking and a cryptosystem that relies on Cell processor security features. For instance, having signing code in one SPU and locking it while the system runs. Has a TRNG too. Nice stuff there. What were u using the cluster for?

[R4p1d]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

Your joking right? Funny I toss around an idea about a PPC box and u have a screenshot. lol. Yeah, I'm sure u don't have to much to worry about as far as malware goes on that one. PPC + Hardened SUSE for PPC + good habits is my main workable design in this thought experiment. That combines the security of an enterprise Linux desktop with the obscurity of PPC. Flash support was the only thing holding me back there. Forced me to have to consider Mac's, which I hate. That's obviously Ubuntu, but what hardware is it running on?

Have you ever considered gnash? It's an alternative to flash for PPC based machines.

I'm currently running this on one of my PS3's, hopefully I'll have my cluster up and running by the end of this month, I'm awaiting supplies.

Gnash is a good project. They've accomplished a lot. The problem is that they are still lacking full support for recent versions. For instance, they only have very limited support for Flash 9. Many websites always go with the latest version, which makes them unusable. I'm not sure about YouTube, but with IE I could only watch movies when I upgraded to Flash 9. Hopefully they will improve it in near future.

That's a PS3? I've never put Linux on PS3, but thought about it for like password cracking and a cryptosystem that relies on Cell processor security features. For instance, having signing code in one SPU and locking it while the system runs. Has a TRNG too. Nice stuff there. What were u using the cluster for?

Cluster?
I have a few ps3's hanging around.... and it will make a few tasks faster with a cluster.
All I can say

[army_of_one]

Data Execution Prevention

PPC won't really save you. What you need is a real way to prevent execution of data, which is what happens most of the time when you exploit a buffer overflow vulnerability.

To get a very general idea of how it works:

1) You need a place in your program where the input length is not checked, so you can overflow it.
2) If you input too much in an array for instance, then whatever overflows it overwrites other stuff. That's where the fun begins.
3) When you call a function, it saves the return address of the line following the function call so that it can return to that address after execution of the function. However, usually, your variables local to your function end up being right under your return address in your stack. What you want to do is overflow the unchecked input to the point where you overwrite the return address, so that when your function returns, it will return to what you've told it to go.
4) Still, you need to give it an address which will do what you want to do. That's where you want to do shellcoding: you're going to make a very small chunk of executable code which is going to open a shell. One problem that often happens is that you need to pass this chunk of code in the unchecked input. The input is usually expected to be text, which is terminated by a byte with the value of 0 (in C/C++). Your shellcode should not contain zeros, otherwise it won't get through.
5) The address you've put in 3) should point to your shellcode in 4), and that's one of the hard parts of writing an exploit: it is quite hard to determine where it ends up in memory.

This is just a VERY simplified explanation, and is nowhere near complete or completely accurate. I suggest you get the book "Hacker: The Art of Exploitation" or "The Shellcoder's Handbook". They are very good books on the subject.

Thanks for the reply. DEP is definitely superior. If it can operate without breaking user's needed apps, then I recommend they use it. It might even be a good reason to pick a different app. Your shellcode explanation is nice. Maybe you could help me answer the key question posed by the thought experiment: Does using an uncommon ISA prevent the execution of all shellcode except that which specifically targets the ISA? I could factor that into some designs where DEP might not be available, particularly for embedded systems running Linux. I'm not a shellcode programmer, so I can't be certain that PPC is immune to most wild viruses. Is it correct though? Not necessarily practical for desktop, but simple and effective way to prevent execution?

[army_of_one]

Here is one of my current PPC boxes that I'm VNC'ed into.

Cheap and easy alternative to preventing malware.

Screenshot:

Your joking right? Funny I toss around an idea about a PPC box and u have a screenshot. lol. Yeah, I'm sure u don't have to much to worry about as far as malware goes on that one. PPC + Hardened SUSE for PPC + good habits is my main workable design in this thought experiment. That combines the security of an enterprise Linux desktop with the obscurity of PPC. Flash support was the only thing holding me back there. Forced me to have to consider Mac's, which I hate. That's obviously Ubuntu, but what hardware is it running on?

Have you ever considered gnash? It's an alternative to flash for PPC based machines.

I'm currently running this on one of my PS3's, hopefully I'll have my cluster up and running by the end of this month, I'm awaiting supplies.

Gnash is a good project. They've accomplished a lot. The problem is that they are still lacking full support for recent versions. For instance, they only have very limited support for Flash 9. Many websites always go with the latest version, which makes them unusable. I'm not sure about YouTube, but with IE I could only watch movies when I upgraded to Flash 9. Hopefully they will improve it in near future.

That's a PS3? I've never put Linux on PS3, but thought about it for like password cracking and a cryptosystem that relies on Cell processor security features. For instance, having signing code in one SPU and locking it while the system runs. Has a TRNG too. Nice stuff there. What were u using the cluster for?

Cluster?
I have a few ps3's hanging around.... and it will make a few tasks faster with a cluster.
All I can say

I really don't need to know then...

[Ohm]

His method is a good method, analyze and fix the problem before it is a problem.
Taking extra steps in the security business isn't a bad thing, it's putting you ahead of the game before the other team comes up with a new game plan.

Edit: This isn't the most secured platform, not nearly, it's just another precaution one can take to prevent malware, and it's a cheap and easy alternative to implement.

Right, but my point is that given a few simple steps, there is almost no problem to begin with. Why put in so much effort to fix a problem that isn't a problem? Assuming you do get infected with some piece of malware, how long does it take to fix? Less time than it would to set up a PPC machine, even if you have to reinstall. If you want to cut down on that, use Ghost or something. It's not like if the machine gets infected with some malware that it'll evaporate or take weeks to fix.

There's just no problem here. It is interesting to think about this, but I don't see a problem that needs solving. Even if there is a problem, there are easier and more sane solutions than running a PPC machine.

[R4p1d]

His method is a good method, analyze and fix the problem before it is a problem.
Taking extra steps in the security business isn't a bad thing, it's putting you ahead of the game before the other team comes up with a new game plan.

Edit: This isn't the most secured platform, not nearly, it's just another precaution one can take to prevent malware, and it's a cheap and easy alternative to implement.

Right, but my point is that given a few simple steps, there is almost no problem to begin with. Why put in so much effort to fix a problem that isn't a problem? Assuming you do get infected with some piece of malware, how long does it take to fix? Less time than it would to set up a PPC machine, even if you have to reinstall. If you want to cut down on that, use Ghost or something. It's not like if the machine gets infected with some malware that it'll evaporate or take weeks to fix.

There's just no problem here. It is interesting to think about this, but I don't see a problem that needs solving. Even if there is a problem, there are easier and more sane solutions than running a PPC machine.

Sure there are, this is just another solution.

[G-Brain]

What you've done is essentially security through obscurity.

Literally. Using the most obscure operating system will save you from attacks directed at other operating systems, but that doesn't make the operating system secure.

As for malware behavior, many exploit flaws in operating system and permission in order to do those things.

That's why permissions need to be done right™ and the operating system and software needs to be kept up-to-date.

"Binary code" that's cross-platform? Funny misquote, there. I said a cross-platform malware: implementation was unspecified. There's already proof-of-concept code for virus that infects on Windows and Linux {1}. They are currently low-risk, as there is no practical need to hit anything other than unpatched Windows systems, but they are possible. I figure running same binary code on x86 and PPC much harder, if not impossible. There are other potential cross-OS methods, but I'd rather not give bad guys ideas to try. No legitimate use that I can think of...

Shellcode is the payload of the exploit code. This is the attack, this is what they want to run. If the code can't execute, then the attack mostly (or totally) fails. x86 shellcode doesn't run on PPC. As for malware writers adapting, you are correct. That's why I published this on BinRev and any commercialization will be word-of-mouth or direct advertising. As long as its very uncommon, then we can reap the benefits of not being worth their time. As I said in original post, the scheme is vulnerable to focused attacks and attacks that have nothing to do with the ISA. However, if we combine it with basic security suite then it should make for a secure and easily used web browsing system for lay users. If they can use a Mac, they can use this. Exploit malware economics to provide extra security at little extra cost. That's the idea.

You're talking out of your ass. The terms you throw around make your posts look very clever, but you don't seem to have any idea what you're talking about.

You said "a cross-platform virus on the OS level". If by this you don't mean binary code, what exactly is the OS level?

Shellcode is the payload of the exploit code. If the exploit code is compiled for x86 systems, you don't even need to worry about the shellcode. Hence my confusion and you not making any sense whatsoever.

A similar tactic to yours would be to switch around the opcodes on CPUs, or change our binary formats. You're not fixing anything. You're running from malware. It's a fundamentally stupid idea. Please get a clue.

Edited by G-Brain, 04 April 2009 - 02:37 AM.

[Ohm]

A similar tactic to yours would be to switch around the opcodes on CPUs, or change our binary formats. You're not fixing anything. You're running from malware. It's a fundamentally stupid idea. Please get a clue.

I think Transmeta actually tried to do something like that. Or at least I read something about it, it might just be conjecture. The Transmeta CPUs were a RISC core, on top of which you could add software compatibility layers. Essentially it had to emulate everything in order to run it. There was an x86 layer, which was packaged and sold as the Crusoe and Efficeon CPUs. A new compatibility layer could be made that's unlike any other machine out there. You'd have to recompile everything, but since the only thing changed would be the opcodes, and not how any of the instructions act, this could be easily done with an open source OS and software. The point is, no shellcode works. No one can even write shellcode unless they can figure out how the opcodes are written. And if you change them every month or so, there's no real window for attack by this method. This is a good, sane "security through obscurity" model. It's not your only line of defense, yet it provides a huge hurdle for any potential intruder.

Ultimately, this didn't work though. Transmeta CPUs... don't perform well. What use is this if the server is too slow? Just like your idea, the sacrifices and time needed to develop and maintain it were too great. The problem was better solved using traditional means: keeping up to date, using firewalls and IDS systems, and sandboxing software like SELinux.