Mac and Linux Bastilles assaulted by new attacks A set of recently discovered security holes in Mac and Linux platforms reminds those over-confident in their superior protection that no one is immune to vulnerabilities. H Security reports on a series of actively exploited vulnerabilities in Apple's Mac OS X operating system that remain unpatched. A vulnerability in mounting …
To exploit this you need to be able to run privileged code on the machine, so you need to have access in the first place -- you can't access this remotely and compromising the web server probably won't help much.
The sad part is that this will be well protected if you run SELinux, except that most people don't understand how to configure it to enable their applications to run ... and so switch this off.
And...
The MAC attacks are DOS attacks, and reading through the PDF on the Linux attack, firstly is it x86 specific, and secondly, to exploit it you need WRITE access to /dev/mem or /dev/kmem (it's slipped in to the end of section 3 that this is required, and the test here is being run from a # prompt, indicating root access).
*NIX security 101 states that these should be protected from write (and even read in many cases), for just this reason.
Of course, if your vector runs as root, then all bets are off, and there are innumerable ways of making a *NIX system do bad things, even if you have SE turned on.
Am I missing something here? It seems that the researchers are saying that the attack can only be carried out by someone with root privileges. Two problems with that; they don't explain how the attacker gains root privileges in the first place; and if your attacker has root privileges you're in serious trouble anyway.
Unless I'm missing something pretty major here it appears that this isn't much of an exploit at all.
Paris? I've heard her backdoor is vulnerable.
"A vulnerability in mounting malformed HFS disk images creates a privilege elevation risk, allowing regular users to obtain root privileges."
Yes like we mount unknown HFS images images all the time. So not only does this mysterious person have to create a specifically malformed HFS disk image they then have to get it onto our systems and persuade us to mount it for some reason and then all that does is allow regular users to obtain root privs. So that person also has to have access to an account on said compromised machine.
Yes its a security problem that shouldn't go unfixed but its not exactly a run of a mill attack that is going to affect the average Mac user is it.
The test is how fast a hole gets patched, and in this regard the Linux community has proved incredible, providing a patch in a record -8 years (see http://www.grsecurity.net/). Yes that is a negative integer.
Wise cracks aside this was an issue, RedHat provided a kernel fix, mmap_mem(), which resolves it and the world moves on.
Before people start, the term "userspace" used in the PDF does not mean from a non-privileged process. It needs to be run as root or another ID with write permission to /dev/mem.
What "userspace" means here is a process run as a normal process controlled by the scheduler, and not added from inside the kernel codebase (like a loadable kernel module would).
Basically, all this technique is doing is re-vectoring one of the system calls, something that people have been doing for as long as table driven vector entry for system calls has existed. UNIX has done things this way since it first existed 40+ years ago (it was very convienient in the PDP/11 world, as it used the EMT instruction). The only real trick here is reserving memory in the kernel address space, and even this is not new (I could probably think of about hald-a-dozen candidates for locating the code off the top of my head).
Due to a design flaw in the MT10 magtape driver code in Bell Labs UNIX version 7 for the PDP/11 (circa 1978), we used to hang the tape device moderatly frequently. I used to go in and zap the lock bit in the driver status table using db (the original UNIX debugger) to use it again without re-booting. And the Keele Kernel Overlay system used to re-vector all of the system calls to allow segmentation registers 6 to be altered to point to the area of memory that had the required code, before actually jumping to it. This was all done in kernel space, of course, but show that the techniques are not new.
So. Stop frightening the ordinary users with things most of them will not understand, and just say that if you allow root access on your Linux box to any-old-code, expect your system to be 'pwned'
Attacker with root privileges can do nasty stuff on your Linux box, news as 11. Oh, and if you use a quality distro with SELinux even the root user cannot use this exploit.
Quoted:
"Users of RHEL and other distributions have been safe for some time now ... "
"Attackers with root privileges may use this to accomplish many standard rootkit behaviors ..."
Both the links for Linux are about installing a rootkit via "/dev/mem". You need to be root to access that device. There is nothing about how to get root access. Even given root access, the rootkits I have tried so far have failed to handle even simple security customisations.
Things would be very different if Linux users were limited to only x86/amd64, one or two secure kernel builds, and just a handful of customisable hoops to make crackers to jump through.
Most major distros actually ship with SEL turned off.
There are not that many applications that would break if it were turned on, but the administration of the Linux system would need to be changed. As a UNIX luddite, (and by this I mean someone who has been using it for so long that fundamental change appears abhorent), I can understand this, and I real uneasy about turning SEL on on my own systems. I am keenly aware that the UNIX security model, which Linux (pre SEL) copies almost exactly, has always been weaker than it could have been (although much better than Windows up to Vista). The MULTICS model that VMS and PRIMOS implemented would have been better from the start, but UNIX was intended to be lightweight compared to MULTICS.
But, as the major variant of UNIX that I use in my professional life is implementing Role-Based-Access as well, I guess that I will just have to learn to live with it.
When theres a trojen on windows (a trojan would be basically what is required, if all of these comments are true, to hit the linux machine ) its because its insecure. When its linux oh no its fine,
Before you say about running as admin on windows actually the majority of the time your not, admin accounts and the administrator account (i.e root) are different on xp, and even more different on vista and upwards.
Believe or not, every such story, no matter how it is written horrifies me about the future of security on my platform of choice (OS X).
Why? Sites all have "comments" and there are even sites which the content is basically comments. Every single mac user commenting about how impossible to breach OS X security, calls AV vendors snake oil sellers, blames the messenger makes me really afraid.
The black/grey hats does read them too and they are seeing "malware author's nirvana" when they read the tone of messages, people bragging about how they have never checked their machine (even while clam, trend housecall) is free and even... even not installing any updates including security.
It is more like "We leave our doors wide open and unlocked in (????) neighbourhood because our guards rocks, the neighbourhood is very neat anyway".
Damn you people making me install AV again :) I was happily waiting to let it expire.
AC wrote: "So that person also has to have access to an account on said compromised machine."
Correct.
However, anyone who has physical access to a Mac running OSX can reset an Administrator password, log in as that administrator and then cause all kinds of havoc anyway.
So as far as Macs go, this article seems to be just scare stories. "Someone who is sitting at your machine can compromise security". Yeah, and? It's the same for just about every OS I've ever seen. I don't know enough to comment on the Linux stuff but I can see that they seem to think this is all just scaremongering guff too.
I once changed the file system on a disc by hand (using low level binary access to the drive) so that I could remove security, break in and change the root password. I don't see El Reg publishing scare stories about that type of thing..!
Just a few things you should know:
1 'root' is not the admin account. I don't even have root enabled on any of my Macs.
2 I usually run my Macs from an standard user account, not an admin account. You can't even use sudo from a standard account, you have to have an admin username and password to get sudo privs.
3 I have no choice but to run my XP (and Vista!) systems using admin accounts, as there are certain applications (one recently used example: TaxCut) which will not install properly if not installed from an admin account and will not run properly if not used from an admin account (TaxCut will insist that it needs to be updated, and will not update except from an admin account, nor will it move forwards until updated.) Yes, this is a failing on the part of 3rd party vendors, not Microsoft, but it's still a very real and very common problem... which is not the case on Macs.
4 the bad guys can drop all the trojans they want, trojans simply don't work if they need root to run and users don't give them root access. Most of the Mac users around here don't know the admin username and password. This means that they cannot install software that requires admin access, because They. Are. Not. Admins. _I_ know the admin username and password... and I don't go around installing random HFS images.
This 'vulnerability' is not one which would affect any Macs at my location. Period. If this makes me smug, well, so be it.
A trojan is executed in the context of a user account with a defined set of privileges.
On Windows it's common to be running in an account with privilege sufficient to install or reconfigure software. Whether that's Administrator or some other Admin account is secondary to the ability, which can be usurped to install malware and take over the machine, by a trojan, by exploiting bugs in unprivileged software or by social engineering. I always set up a system with (a) non-admin account(s) for the user(s), but there's an awful lot of "reputable" software out there that won't work without running under an admin account.
On Linux rooot is reserved for the the sysadmins, who know not to use it except when they need it. Executables used by privileged or system software are never alterable by ordinary users. Ordinary users don't have privilege to install or modify system software. Neither do most user-facing or internet-facing services. This is why Linux in intrinsically more secure. It was designed secure, whereas Windows was designed with more holes than a swiss cheese.
This post has been deleted by its author
... you as the user has physical access to the machine.
Most windows stuff thats going around now requires user interaction, not that many that can properate fully without it. This is just another example of that, so stop saying "its not an issue", its just as much of an issue as any windows trojan like program is.
There seem to be a very large number of Linux/OSX security scare stories based on bullshit emanating from el Reg of late and a staggering number of anonymous WinTrolls going "Na-na-na-na-na" like stupid children.
As has been pointed out (and I'll point out again) I can't see how this can happen unless you already have root access to that machine, which kind of makes this a non-story from go.
*nix and Linux HAVE a concept of file ownership and executability (other than their file extension) which is a real and fundamental first principle. Windows does NOT -- and until this gets fixed by MS then their security will ALWAYS be by definition compromised. All of their security measures will simply be a grotesque end-user bothering mess endlessly tripping everything up forever.
MS and WinTrolls: start understanding *basic* computer science first principles.
OK, here is the difference.
On most Windows systems, people are running as a privileged user most of the time (they need to so their applications work). So if there is a hole in the browser that allows a remote-code exploit, it then has the required privilege to immediately add other back-doors, inject code into the core OS, and generally play havoc on the system in ways too many to mention.
On Linux, most users run as a restricted user by default. When they browse the internet, run applications etc, if there is a remote-code exploit, this code runs as a non-privileged user. So if it tries, for example, to write to /dev/mem, it fails. If it tries to change any system libraries, it fails. If it tries to change any binaries in system directories, it fails. In fact, pretty much everything damaging fails EXCEPT ON FILES OWNED by the user, which is their own data, and the configuration files for the apps they run.
Of course, it is possible to run most programs as root, but the normal state of affairs is that people don't. THIS IS THE DIFFERENCE.
By default, there is no way for code to cross the non-privileged/privileged divide without the user taking affirmative action, and unlike Vista, it does not ask for permission every two minutes, so as soon as it does, most Linux users will be wary.
Before you start, yes, it is possible to change the users path so that you run unintended programs, but normally, if you su or sudo, the path gets controlled again. Ditto the LD_PATH. Of course, you could try social engineering (go on, you really DO want to sudo this script I've dropped onto your system, even though you do not know what it does), but this is not a flaw in the OS. There really are people who know about security acting as gatekeepers-by-proxy for the dangerous things.
The UNIX model is not immune from exploits, but most of them are well known, and you can find out how to avoid them in any of the myriad of Linux or UNIX books that are available. Most distro's install pretty secure anyway, and they also contain information to avoid most of the pitfalls. And major distros patch new exploits as a result of code defects pretty quickly.
The plain truth is that *NIX security is too well understood to allow simple exploits any more. It's all in the pedigree.
Anyone with physical access to a mac basically owns the machine. Yes, contrarily to some opinions expressed here, I think it's a problem. Not for the home user, of course, but it makes "shared" or public Macs potentially insecure. Not new though.
As for the Linux threat, well it's all well and good but why would you bother? If you have root access, you can bloody well replace the damn whole kernel (an "exploit" which works on every architecture, not only unpatched x86 systems as the "attack" mentioned here).
Just another point: when you write "without creating much in the way of clues that an attack is taking place", I suppose you're aware that the actual "attack" ends with the gain of root access, way before any fiddling with /dev/mem takes place. That makes the technique described a "hacking trick" -in the noble sense of hacking-, NOT a vuln or an attack.
To put a rootkit on you need to be root, uh huh. Nothing to see here.. .move along!
If this was a news piece about how an outside attacker can gain root access then it would be news.
Regarding the Mac;
"A vulnerability in mounting malformed HFS disk images creates a privilege elevation risk, allowing regular users to obtain root privileges"
A "MALFORMED" HFS disk image... uh huh... and how does THAT happen? Again.. unless you want to talk about how a malformed HFS image can be created by an exploit and then that image used to.. oh wait.. wouldn't you already need to be root to create the HFS image in the first place? So no... this one is not news either. They're really stretching for vulnerabilities when you have to be root to implement them.
OK, so I use Linux, and I consider it more secure than Windows, so I guess I'm open to complaints of blind fanaticism here, but I've got to agree with several comments here that the vulnerability described isn't really anything of the sort. If I'm reading things correctly, all that's being described here is a kmem-based method of building rootkit-like behaviour. In fact, this is neither a new technique nor a new attack. At best, all the technique can achieve is hiding an existing attack. It does not (again, at least as far as I've read) point to an exploit which can be used to actually gain control of the machine.
As for the HFS exploit, I think there is probably more justification in calling it a potential exploit, but again, bugs in filesystem mount code are not exactly new, and have, to my knowledge, always been very much theoretical as opposed to something that has much of a chance of actually being workable "in the wild". That said, I don't know much about how OSX works. If (and only if) OSX formats USB sticks using HFS then I'd have to upgrade the risk from "theoretical" to "quite practical", but it would still require the user to insert a dodgy USB disk, meaning it's most likely only useful as a targetted physical attack (where the attacker either has physical access to the machine, or can trick someone who has into inserting the device) rather than being of any use as a means of spreading virus or worm functionality.
All in all, very little to see here... let's move along.
Life is risk. Otherwise there would be no evolution and no us.
The point can be seen more clearly in a simple comparison. Whenever I cross a road, I should look both ways. However, if I'm crossing a rural highway in the south on a Sunday morning, the likelihood of seeing a car coming my way, and thus the risk of being hit, is quite low. On the other hand, if I chose to cross the FDR Drive in lower Manhattan on a Monday morning, I take my life in my hands, no matter how cautious I might be. The same with my choice of OS. When I use a browser running under Linux, Unix, Solaris, BSD, or Mac OS X, I am much less likely to encounter "evil doers" because there's not much return in targeting an operating system the installed base of which hovers in the single digits of a per cent. Secondly, I am much safer, notwithstanding the existence of exploits, if there are no software in the wild capable of utilizing such exploits.
Is there risk involved in going on line? Of course. Are the risks equal across operating systems? Of course not. While reports of this kind are academically interesting, and remind us that we should all practice safer computing, it is scarcely adds up to the sky falling. Do please let us know, won't you, when something like Cornflicker makes its appearance on Linux or OS X?
A top of the site article that is nothing more than scaremongering? That's really what you all are going for today? It may be a slow news day guys but this kinda crap doesn't help matters at all. So I read the "attacks" that this "oh noes teh haXs0rz are comInG runnnnn" piece and all I have to say is this: Someone with local physical access can circumvent security and cause *NIX and Macs to do nasty things, really? Well no shit Sherlock, what ever gave you your first fucking clue???. News flash for ya, having that kind of access and running as a privileged user (particularly root or administrator) you can cause havoc on ANY system regardless of OS. This isn't new at all and it's not explicit to *NIX or OS X so can we turn down the hype/scaremongering machine by a order of... oh like 1000%.
Does that mean folks running OS X or Linux should be ignorant of the fact that both systems have been in the past, can now, and will be in the future some how or some way compromised? Not at all. However you're not informing, not educating, not attempting to get folks to think more seriously about the security of their computers. Articles like this do nothing to forward those efforts.
next story: linux is no more secure than windows: a researcher has found that a user with root access to the machine is able to replace system files.
During a test they reformatted the hard drive to NTFS, wrote a specially crafted boot sector (ripped from a windows machine) and placed a load of new files on to the drive (copied from a windows machine), they then issued a remote reboot command. Several minutes later the system booted up running windows - with all of its associated security flaws. The research paper therefore concludes that linux is no more secure than windows.
The article talks about most Linux distros turning off SELinux by default. I've been running Fedora since FC 6 and it's always come with it turned on. My sister's been running Ubuntu for over a year now, and that comes with it turned on. I won't say that this disproves the article's claim, but these are two very popular distros I'm talking about, and between them they have a pretty good percentage of all the desktops running Linux. From where I sit, this sounds more like FUD than anything else to me.
I just peed a little. I thought Linux was supposed to be secure, yet you tell me that if I give root privileges to someone, they can install stuff on my computer? Bawww. </sarcasm>
@AC:
"When theres a trojen on windows (a trojan would be basically what is required, if all of these comments are true, to hit the linux machine ) its because its insecure. When its linux oh no its fine,"
It's a bit harder than that. With Windows, this sort of exploit is like by playing a CD in your car stereo, someone can steal your car. With Linux, you'd still have to walk them to your car and hand them the keys (and disable your ignition kill-switch if you have one). No offense, but it sounds like you're the guy this article was intended for. It's pretty much a non-issue, but El Reg is reporting this in a Fox News like manner for the attention.
Seriously Reg, wtf? Shame on you.
It's nice to remind people they're vulnerable. There are some like me who are vulnerable because they're lazy, but others out there are just ignorant. However it would be nice if you didn't have to pretend to have some exploits to make a point. These are all just examples of how some people who have already found a way to compromise your system anyway can do so with a bit of class and make it harder to detect.
"A set of recently discovered security holes in Mac and Linux platforms reminds those over-confident in their superior protection that no one is immune to vulnerabilities"
The flaw does seem to be have already addressed (at least since 1999) and relies giving USER write access to /dev/mem. And is specifically referred to in comments in the paper.
"only root has acces to /dev/mem ?", Sep 1999
http://lkml.indiana.edu/hypermail/linux/kernel/9909.1/1016.html
"If this option is disabled you allow userspace (root) access to all of memory, including kernel and userspace memory"
http://www.dtors.org/papers/malicious-code-injection-via-dev-mem.pdf
"I'm having difficulty dumping the memory from a Ubuntu 6.10 PC. When I try and run it (yes both using sudo and as root) I get: dd: reading '/dev/mem': Operation not permitted"
http://www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=1453
I have, sitting right in plain sight in the main file cabinet in the Admin office, several CDs which will allow me to do exactly that: ERD Commander 2005 for the Windows machines, and OS X boot discs for the Macs. If I need to get into a system and I don't have the password and I'd not preset a backdoor, I can get in using one of those discs. Those discs allow me to change the admin password to whatever I choose, whenever I choose. Just so long as I have physical access. And once I have admin access, I can do anything I like. Indeed, even if I don't change the password, I can still do things such as remove the entire filesystem using one of those discs. it wouldn't take 5 minutes. Who needs complex rootkits and such, when you have physical access and easily available admin tools? Hell, _Apple ships a system disc with each and every Mac_, and that system disc can be used to access other Macs! I don't even have to go and buy anything extra! What a security hole... or maybe not.
If you have physical access to ANY computer, you can hack it. Yes, even Macs.
When Mac OS X 10.5 came out, I installed it on my PowerBook G4 and played with it on an overseas flight. Unfortunately, 10.5 had a bug that caused privilege DEMOTION, and both previously administrator-level accounts were demoted to standard users, with no "sudo" capability.
Since I had physical access to the machine (duh), I was able to get into the system and manually promote my access. Yes, on an airplane and without the Mac OS X DVD disc. No, I won't tell you how I did it.
The HFS+ bug is stupid. Without physical access, it doesn't work. I hope Apple patches it, but I don't see this becoming a huge issue for Macs.
@FUD.. spot on, this really is FUD. But, the proof-of-concept is x86-specific; the general technique isn't. (As a practical matter, of course, I doubt anyone is going to make a PowerPC, ARM, PA-RISC, etc exploits for it.)
Spot on though, the user already has to be root... this really just demonstrates stealth techniques (so there is not a process showing.) Not new either -- (even the article has an addendum saying this now)... inserting code into kernel interrupt handlers has been a proof-of-concept since the late 1990s, and there was an old Redhat-specific worm back then (Redhat-specific because directly patching a kernel will be pretty specific in what kernels it handles..)... The exploit would crash the system about 50% of the time though; if the interrupt triggered while the exploit was changing the interrupt table, crash city. If the exploit was successful, you had exploit code running in kernel mode, not showing in the process table. It would not survive beyond a reboot though.
@Linux already patched... it's not, but you have to be root to access /dev/mem anyway. I think /dev/mem support can be removed from a custom-built kernel, but it's possible the X server still uses it for video card access on some cards. I doubt /dev/mem support will be removed, it's not the UNIX way to remove capabilities from root, but rather prevent people/processes from gaining root access unless they should have it.
There are a lot of Asus Eee machines out there running Xandros Linux, and I have heard worrying claims about the security set-up. There seems to be something about how sudo is configured which leaves the security pretty weak, yet it seems to have to be that way to allow the system to boot.
How weak is it? Well, I never had to suppy a password to load a software update. Compared to the distro I currently run, that feels more than a bit flimsy. And if that pasticular distro is poorly protected, there are a lot of them out there.
>>How do I know
>>By Aaron Harris Posted Thursday 16th April 2009 12:47 GMT
>>What is it that makes my Ubuntu 8.10 install vulnerable or not?
>>A bit more info please
The whole point of FUD is to be obscure as possible. It is deliberate that some PR prawn for an AV company be as vague as possible - to sew the seeds of doubt. After all you should ONLY have a proper OS on your machine - that most secure one around - which I think is either VIsta or W7 according to the M$ fan club.
init=/bin/sh .. or boot an os off of different media and mount the filesystem(s) there instead....
Surprise surprise local access or root access to a machine makes it vulnerable.
N.B. Listening to anything 90% of Mac users have to say is pointless. When Mac's were PPC, they were better for being PPC even though Intel had faster chips out for half the price. Mac OSX is the greatest thing since sliced bread because it's "UNIX" yet most of their populous can't operate bash. And Mac users love to flap their heads about "security" without having the faintest understand of how anything below the brushed metal style buttons works.
I'm not an expert in this, but surely this is more of an issue than it's made out to be?
Sure, you need physical access. And yes, you can reset the admin password to a machine if you have physical access. But what use is resetting the admin password to a machine if the account is a network one, say in a workplace or school, for example?
As I see it, a user could come in with a corrupted HFS+ formatted USB drive, promote their privelages, and start causing havoc over the network...
Though, as I said, I'm no expert. Can anyone clarify whether the exploit could be used as I just described?
Some posters are concisely and knowledgeably explaining why this isn't that big a deal and that the El Reg is being a bit of a FUD merchant. Other posters are posting about how Mac/Linux users are living in denial because they seem to know what they are talking about. Lets hazard a guess at the OS choices of those two separate groups.
Meanwhile we all await the next flaw in a Microsoft program/OS that causes your Windows/IE machine to become a spam zombie simply by visiting the wrong website.
"Your best solution is to run your apps from a read-only device"
You mean like Live CD's? I like those. :)
I periodically do a cold start though, just in case something's living in RAM or whatever... I don't know if things in RAM can survive reboot in Linux though, or how such things would get there in the first place... just playing it safe I guess, maybe it's not necessary?
Unfortunately, I'm not smart enough to figure out complicated configuration stuff in regular versions of Linux, and no amount of study and reading is ever likely to change that unless it's spelled out, step by step, in idiot-proof instructions for total dummies (that's me).
Also, and I realize that this shows my other-OS backgrounds, but the dearth of real-time monitoring software (normal real-time anti-malware stuff) for Linux makes me feel less than confident with using an actual installed-on-the-HD (writable) Linux. So the Live CD's, to a dummy like me anyway, seem like a good way to go.
Right now I have one entire computer whose sole job is to let me do normal surfing and check email etc using a variety of different Live CD's (haven't decided which one I like best yet). My Windows machine hasn't been hooked up to the internet for a long time now, after some earlier malware problems which I had a hell of a time getting rid of (it had infected my backup disks too), and the extremely-legacy ;) Mac is too old and slow to bother with trying to surf with it anymore.
Maybe I just have a false sense of security with the Live CD's... if so, please advise. Otherwise, it's not much hassle at all to use them (except I had to hook up a CRT monitor 'cause they don't like my LCD screens for some weird reason), anyway provides some peace of mind... or at least the *illusion* of peace of mind...
1. If a bad guy can persuade you to run his program on your computer, it's not your computer anymore.
2. If a bad guy can alter the operating system on your computer, it's not your computer anymore.
3. If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
4. If you allow a bad guy to upload programs to your Web site, it's not your Web site any more.
5. Weak passwords trump strong security.
6. A machine is only as secure as the administrator is trustworthy.
7. Encrypted data is only as secure as the decryption key.
8. An out-of-date virus scanner is only marginally better than no virus scanner at all.
9. Absolute anonymity isn't practical, in real life or on the Web.
10. Technology is not a panacea.
And these exploits violate either rule one or three, so it's no suprise they lead to problems.
*sigh* Judging by some of the comments in this article, I see that the school holidays aren't over yet *sigh*
Like others have already mentioned, I fail to see the relevance of this sploit. If you've got root access already - which is a prerequisite to be able to write to /dev/mem - then you don't really need this exploit in the first place.
Similarly, if you've got physical access to a machine then all bets are off. That's why our data centre has servers physically locked away.
I'm sure the Windows users will read this article and think that Linux & Mac OS are insecure (just like their OS is) because they do not understand the reasons why one OS is considered insecure and another isn't. But then, if they were intelligent enough to understand why an OS is insecure (rather than just thinking it's good because it plays the latest games) they wouldn't be using Windows in any case.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
