Please note: this document primarily applies to systems running 10.4 and later. ![]() I reference prior blog posts here you can read for more details, but this guide will cover the basic notions and try to give you an idea of priority. This post is hardly comprehensive and you should not assume it covers all relevant deficiencies, but, for the record, these are the recommendations I myself use on my own systems. So as promised, here's an updated practical guide to keeping your beloved Power Mac safe, or at least safe r, today 11 years and nine operating system releases after the last Power Mac rolled off the assembly line. In the worst case, an attacker could gain administrator access and complete control of the system, and because the exploit is not architecture-dependent, we could potentially run the poisoned code too. In the second case, applications on your computer could be duped into performing tasks on behalf of an attacker using a payload that is not specific to a particular machine type, but can run anywhere the cross-platform environment they utilize exists (such as Java, Flash, Microsoft Word macros, scripting languages like shell scripts, JavaScript, etc.) and is able to exploit flaws in that environment to take over any machine that can run the code. In the first case, unsecured networking, weak encryption or other flaws could leak private data such as passwords, credentials or personal data from our computers to an attacker in the worst case they could allow an attacker to masquerade as you to other services or sites. ![]() Where we are most practically vulnerable falls under two major categories: information leakage, and cross-platform attacks. No current Intel Mac can easily generate code that will run on a Power Mac without a lot of work either.īut our systems definitely do not sail above the fray. Attackers go where the money is, and it's not our machines. While the more security conscious amongst you will (correctly) point out this is a special example of "security by obscurity," that doesn't mean this heterogeneity isn't an advantage. At worst, an non-PowerPC exploit of this type would just crash the application or, in extreme cases, the machine. The vast majority of presently extant low-level exploits like buffer overflows and use-after-frees broadly depend on being able to deposit Intel or ARM machine code in memory and have it executed by the victim application, but our instruction set and (often) memory layout are completely different, so any such exploit would have to be specific to PowerPC to successfully execute. The most important thing to keep in mind is that, as virtually all the regular readers of this blog know, Power Macs use a completely different architecture than the majority of what's out there today, and this has important security ramifications. If some easily remotely exploitable bug surfaces that cannot be mitigated or blocked, I'll change my tune here, but that's not presently the case. ![]() However, doing so is absolutely imperative and absolutely your responsibility. You just have to understand where the vulnerabilities lie, patch the holes you can, and mitigate the vulnerabilities that you can't. The second part is, at least right now, not. The usual advice well-meaning but annoying people will give us Power Mac users is, "there are many security holes in your machine, so you shouldn't ever use it on the Internet." The first part is true. Way back in 2012 I wrote a fairly basic piece on Power Mac security, and ever since then I've promised repeatedly to do an update for what's happened in between.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |