Hidden backdoor API to root privileges in Apple OS X
truesecdev.wordpress.com
truesecdev.wordpress.com
What? So all OS X boxes are simply broken, privileges-wise, if they're not on 10.10?
Just because something is free doesn't make it better.
OS X has many merits on this front, but since 10.3 I've found that the first few dot releases of OS X have the same caveats often enough (both in terms of bugs/hazards and in terms of gratuitous UI "progress") that it usually seems better to wait past .x.4/5.
Now there's this, of course.
Since the problem showed up in 2011, maybe I should go back to Snow Leopard; I can't think of a single valuable change to OS X since then...
My reply to that has always been that Windows is only $300 if you don't value your time. (Preserving archaic cost of Windows to match JWZ quote.)
The implication that the one system is free and time-consuming and the other moderately in price but not time-consuming is entirely false. At the time, for many requirements, configuring and administering a Windows machine would have been more time-consuming than for Linux. It's also glossing over the fact that you can't horizontally scale your $-per-cpu/server solution once you do have the configuration worked out, without going back to the well for more money.
This amusing and glib quote also deliberately glosses over the "freedom" part of free software, which is essential. For example, I wonder if Google would exist today if not for a free unix workalike.
Haven't found that to be the case. And I'm an old UNIX hat, using SUN OS, HP UX et al in the early nineties and Linux from around 1998. My two observations:
1) Linux, even the most modern distro like Ubuntu, is a huge time sync for anyone that's not just content to browse the web and check mail in a system setup for them.
2) More users that we think are in that category (besides the proverbial "grandparents" perhaps).
You got a video from your wedding you need to edit? Might or might not work. You got a hobby that requires you to use a specific peripheral (like a soundcard) or software? Do you feel lucky? You got a new phone you need to sync? Prepare for an adventure...
Used to say? How long ago was that?
Ubuntu and many other distros are incredibly easy and effortless to use. I know devs using apple products who spend more time mucking about with brew and other tools trying to accomplish things that are very easy to do on the most popular linux distros.
My point is that Ubuntu is complex [as is Windows] and when something doesn't run quite right, the right answer is usually hard to find and hard to recognize because it will be embedded in a culture of highly technical cross referencing. The tradeoff for going down the rabbit hole is that Linux is really powerful and flexible.
I'm loving me some Xmonad this week, but I had to root around in xkb and xmodmap and write a little haskell and read about out how to switch layout engines in Ubuntu [and then translate that into xfce based Ubuntu Studio]. It's non-trivial and requires reading stuff on the Arch Linux Wiki. Ubuntu isn't really self contained in the way Windows is.
I have a USB disk with Snow Leopard on it that I can boot on my work's 2008 Mac Pro but that kernel panics on my 2012 MacBook Pro due to the i7 "from the future" according to Snow Leopard. It's a pity because it'd make a really great test system (I would like to check that my software runs on 10.6 OK).
Does anyone know of a way of booting Snow Leopard from disk inside a VM without many kernel kext kerfuffles? Parallels tells me that I stink if I try and install OSX inside it (I have the regular DVD, not the server edition)
I wish I had that option, but I'm an iOS developer, so I upgrade when Apple forces me to, and right now their forcing Mavericks and up.
> Linux is only free if you don't value your time.
Amazing how the largest server farms on earth are all run by administrators who don't value their time...
Yeah, like installing drivers for all your peripherals on Windows never takes time, right?
And now this crap. Ugh.
While "upgrading" to 10.10.3, my computer failed to reboot itself. It just sat there, black screen, with a little spinner, for about 2 hours. Hard reboot, everything is back to normal. For now.
I fully expect 10.10.4 to actually destroy my hard drive at this point, as well as cause my monitor to spontaneously get 30-40 dead pixels.
Sucky part is, I feel I have no alternative.
Windows is out of the question after seeing what a factory OEM image comes with nowadays. I'm not giving them money and spending 2 days formatting/reinstalling/seeking out drivers on slow Taiwanese servers just to make a half-usable computer. And then, after all that, spend another 2 days installing various adware infested shitware to get a fricking PDF viewer. And don't get me started on getting a half-decent dev environment going. Ugh.
Linux is almost there. It's a crap shoot for me, unless it's running in a VM. I never know which kernel update will fix my trackpad/break my sound/wifi and which will fix the wifi, break suspend, fix sound, but break xrandr or some other archaic XWindows-related technology.
So, OS X it is, for the time being.
Fair play. Research the manufacturer's policy if you're buying pre-built. If you build your own desktops, this is not an issue.
>I'm not giving them money and spending 2 days formatting/reinstalling/seeking out drivers on slow Taiwanese servers just to make a half-usable computer.
When's the last time you actually installed drivers on a fresh Windows install? I will concede this used to be the case, but nowadays the whole process is much more streamlined. Microsoft has made progress on supporting a lot of hardware drivers via Windows Update. Intel also has a great driver update tool that will scan your system and make recommendations.
>And then, after all that, spend another 2 days installing various adware infested shitware to get a fricking PDF viewer.
2 days is rather exaggerated. Most browsers display PDF. If you absolutely need to read a PDF, Foxit Reader is free, as in beer. Yes, you'll have to uncheck some boxes to avoid their bundled software. Big deal.
>And don't get me started on getting a half-decent dev environment going. Ugh.
Yeah, windows isn't great for a lot of developers' needs. You really could have just left your argument at this rather than spouting off the rest of that FUD.
I use Linux, OS X, and Windows all on a regular basis. They have their strengths and weaknesses, like any other products.
Just get Ubuntu Certified Hardware. They have over 500 models of laptops they certify. I have never had a kernel update break wifi. I don't know about all the other stuff, but most distributions store old kernels and allow you to boot back into the old kernel pretty easily. Don't know if this is an option on OS X.
FWIW the Signature series Wintel laptops sold through the Microsoft store are base Windows+driver builds, no crapware allowed.
Microsoft Signature PCs solve this problem. :)
http://www.microsoftstore.com/store/msusa/en_US/cat/Signatur...
Apple could easily write fully functional Linux drivers for their hardware if they wanted to, but they choose not to.
- My battery lasts longer, maybe 2-3 hours more per charge. I nearly never see < 50%, she's hitting 10% at the end of the day. (Note that both are good enough, but they're way different) - Mail search sucks on Yosemite. Today, we were searching for subjects that I know are there because I'm looking right at them, and nothing is coming up. - Safari does something funky with process per tab that manages to orphan process that take a bunch of cpu/memory. - Time machine is really touchy about backing up to the server over wifi. The last few times, it's had to make a new backup on the Yosemite machine. Mine misses a backup every day or so, but that's just an hourly miss, not a full rebuild.
We're considering blowing away her machine and pushing it back to mavericks with Time Machine/fresh install.
Maybe I've waited long enough before moving. Especially now that this vuln is known about.
Pity I can't actually boot it on my 2012 i7 (kernel panics ahoy).
If anyone knows how to get around this, I would appreciate it as it would be truly marvellous to be able to test software that I've written under it.
I generally put off doing a major Mac OS update for as long as possible.
My late 2011 13-in MacBook Pro became unbearably slow after doing a clean upgrade to Mavericks. Only upgrading the memory to 8GB (which was not supported by Apple for that model) fixed the issue. Yosemite works, but looks like crap on anything without a retina display. Newer versions of iOS have a habit of making older phones become sluggish when compared with the same phone model running an older version of iOS.
I'm not expecting Microsoft-level backwards compatibility, but as someone that has a somewhat complex development environment having to get everything to work on a new version of the OS can take up to a week of tweaking.
I've had little bugs and fiddly bugs with Safari and a few other things, but I really thinks it has worked fine for years and years on the machine. It noticeably improved when they added RAM compression (was that Mavericks?).
I don't find the graphics a problem at all, although they do look better on my Retina iMac. I got used to them pretty quickly.
I've been happy with most OS updates as they sped Safari up or fixed small bugs in it. Photos for OS X is a MASSIVE speed improvement over iPhoto.
I know some people run into pretty catastrophic bugs from time to time, I haven't had that experience personally. The idea that the OS doesn't run well on five-year-old hardware is bunk. I have no need to replace my MacBook Pro, The only thing it's not good at is 3D (and it was never very good at that).
If you have enough RAM and replace the spinning disk old Macs feel fantastic with a if you have enough RAM and replace the spinning hard drive old Mac still feel fantastic with a recent OS.
If you're on a 5400rpm drive with 2GB I'm sure it's painful. But I know even 4GB machines fair very well. SSDs just make an insanely big difference.
Upgrade was an easy drive pull and replace, and I just restored from Time Machine to get all my data back. No fuss.
But I don't have a windows partition or anything else special. I imagine it will be a bit more work for you since you'll need to backup the Windows partition and restore it.
Unless your hardware has been made "incompatible" by Apple (not for any technical reason, but simply because they wish you'd buy new hardware).
It has a quad-core Xeon processor.
[update]
I am wrong. It is the late 2008 X-Serve that won't upgrade ...
Specs: https://support.apple.com/kb/SP10?locale=en_US
Supported H/W:
iMac (Mid 2007 or newer)
MacBook (Late 2008 Aluminum, or Early 2009 or newer)
MacBook Pro (Mid/Late 2007 or newer)
MacBook Air (Late 2008 or newer)
Mac mini (Early 2009 or newer)
Mac Pro (Early 2008 or newer)
Xserve (Early 2009)
For us IT Shops, its almost exclusively about ensuring support for the hundreds of other software programs.
I see a lot of folks arguing otherwise, and I'm not sure they realize this.
Sure, it works fine for the 'isolated single user', but it's totally different in a large deployment model.
I was surprised just how well it's working tbh.
At my last office we had older macs, a mix of laptops and desktops. They all ran slow, with one user's mac pro using all 4GB RAM on a fresh boot with nothing loaded. These folks were normal users, not power users. When a new OSX release would come out, a few people would upgrade, have a ton of problems, and warn everyone else.
I ran linux myself, and was occasionally called over to help with an OSX problem, and I could never understand how my colleagues could stand to work on such slow computers. In my experience, older macs do not usually run well on newer OSX.
Only 50% on Windows 7 or 8: https://analytics.usa.gov
Oh, wait, Windows 7 is from 2009. Only 10% use a Windows younger than two years.
Microsoft would not be able to get away with the shenanigans that Apple are pulling here.
It's not only about support for "old" products, it's also about having a roadmap to begin with. It used to be common wisdom that Apple releases major updates for the current version of OS X, and security fixes for the last two versions. Well, that common wisdom is outdated now.
Also, backwards compatibility and security fixes are not really the same, and I'd say that the correlation between backwards compatibility and software quality is completely overrated. I know I'd rather trust my life to Windows 7 (the epitome of conservative OS design) than to OS X 10.10 or iOS 8 (speaking as an iOS developer).
In raw numbers, 45% of OS X users are now vulnerable (and probably don't even know about it), and Apple doesn't care. That's an insane number. And I thought not patching the ~10% iPhone 4 in the wild was dangerous!
I don't know any tech company that doesn't have that idea of a model customer :)
To their credit, I can run the latest on a pretty old Mac Mini at home. It's not as fast as it used to be, but it is supported long after the form factor of the Mini has undergone big changes. I don't consider myself being squeezed to upgrade.
Was it usable, speedwise, as a machine?
It worked with very little of the modern web, however.
Most developers don't bother, as Apple has successfully made it quite difficult.
We're talking about a security issue!
The majority of their user base doesn't know and wouldn't care about this type of thing even if they did.
Source: I'm a family "computer whiz" :/.
People understand if a system is insecure, and now apparently all non-Yosemite Macs are insecure. Folks will grok that. Whether or not they find out about it, well that's up to you and I, and everyone else on this website.
I agree it's up to us to proactively tell our parents, friends and colleagues who may be vulnerable about this problem.
An additional bonus is that you can get these things for free if you know where to look.
Of course, being 11 years old it also has its drawbacks. It won't fit more than 2GB of RAM. It is based around a single-core Pentium M which generally performs fine but shows its age mostly when meeting Javascript-hobbled web-related things.
BUT... and this is one of the main reasons why I use older hardware... if you develop software on this machine, and it works fine on that machine, it'll run circles around the stuff your neighbour made on his latest FlitzBang Fruitmachine. It'll but cause a blip on the CPU meter where his (or her, your choice) result maxes it out. It'll use memory like it was rationed, not like it was on sale.
Of course you can not develop software for the dark side on this older hardware. A small loss, in my opinion.
I notice that Windows 10 has had new bits shoe-horned in (a new settings screen!) whilst still keeping ALL the old stuff there (MMC as written in 1998? Control Panel is still there despite this new Settings page, duplication much? None of the icons match etc. etc. what a hodgepodge)
Ubuntu on a macbook pro is reasonably comparable. And the Dell offerings are looking damn good.
It would be nice to have a tiling window manager too.
https://support.apple.com/kb/DL1803 https://support.apple.com/kb/DL1802
from https://support.apple.com/en-us/HT204659:
> Admin Framework
> Available for: OS X Yosemite v10.10 to v10.10.2
> Impact: A process may gain admin privileges without properly authenticating Description: An issue existed when checking XPC entitlements. This issue was addressed with improved entitlement checking.
> CVE-ID
> CVE-2015-1130 : Emil Kvarnhammar at TrueSec
I can't really believe Apple will actually leave this unpatched, as opposed to just saying it won't at this time. The impact of this exploit and the number of affected systems is way too big, they really can't let this sit in OS X versions that were brand new only one or two years ago, that would be insane. With all the resources they have a statement like 'the impact of the changes would be too large' is quite ridiculous.
My guess is that they will patch it in a later update, but haven't finished it yet. Maybe they are even hoping for a few more people to upgrade to Yosemite before they release it. I would be willing to bet that they don't leave a gaping hole like this sitting indefinitely.
I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing.
[1] - https://developer.apple.com/library/mac/documentation/Darwin...
But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing.
The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.
That's like saying kernel memory protection is silly when the user is an admin because he could just as well load a driver into the system to wreak whatever havoc he wants.
Yes, he could. No, it's not silly.
If a user correctly has permission to do a thing via a series of ugly hacks then there is no reason not to just let the user do the thing directly.
Maybe, but the attacker can also get their certificate revoked when their activities are discovered.
It cannot simultaneously be easy for anyone to get a certificate and hard for an attacker to get a certificate.
- Start up the Mac whilst holding down ⌘-S. This boots the Mac into Single-User Mode and provides a method of interacting with OS X via the command-line, with full root privileges.
- Then check the filesystem to ensure there are no problems: "/sbin/fsck -fy"
- Then mount the filesystem for it to be accessible: "/sbin/mount -uw /"
- Now remove this file so OS X will re-run Setup Assistant: "rm /var/db/.AppleSetupDone"
Now just restart, and enjoy the cool introduction animation as you create your admin account.
But yes, this is not possible with a firmware password or with disk encryption (FileVault) enabled.
Think hardware keyloggers, fake MBRs, &c.
OP's trick won't work, but that's an "implementation detail;" there are plenty others that will.
EDIT: to clarify; that's not what you said, it's just a common enough misconception that it's worth being explicit about, here.
Most OSX boxes are probably single user devices. But you do not normally run as root/wheel, you need sudo (sometimes through a nice GUI) for software to get root privs.
It's not 'somebody' as if another person were logged into their own account. It's that malware running as you can now get root, to further compromise your system, without needing a sudo password.
You still need to find a way to execute code on the target system (also called "getting a shell"), but this can be done over the wire, too.
What's pretty bad here is that any user now has a backdoor to obtaining root privileges. That's an awful security flaw.
So its really, really not good. Apple need to fix this soon, or else every OSX machine out there is going to start being targeted for misuse. This is really a powerful security bug.
If someone really wants to protect their data, they have to count physical access as a possibility and rely on encryption and/or remote wiping - the operating system login isn't going to do much anyway.
What malware requires physical access? This is a local privilege escalation to root. It's only local because you need an account on the machine to make it work, but it can be bootstrapped to a remote exploit.
Luckily after some digging I came across this fix and was back in to my computer, albeit a little shaken up by the back door.
I really hate all the desktop IPC bullshit. IPC frameworks are pure fucking evil. COM, D-Bus, XPC, everything SUCKS.
If you want completely separate programs on one machine to talk, use UNIX domain sockets (with something like ZeroMQ or HTTP), FIFOs (named pipes), anything that you can chmod and chown, not a daemon that reinvents access control, badly.
This method wouldn't pass the most cursory of security checks. It's clear that it was never actually reviewed, and that the original programmer was relying on the proprietary nature of the OS X system for security. Something like this would never happen with Linux IPC - reviewing the methods published on dbus by services running as root by default is a basic check that any sane distro will do. Something as straightforwardly exploitable as this (literally just call the method while running as an admin user!) would never go in to Debian.
> If you want completely separate programs on one machine to talk, use UNIX domain sockets
D-Bus does use UNIX domain sockets. Your ruthless hate should probably try harder at informing itself.
It's like users who encounter a random problem in a program, and then blame it on the fact that the program is written in C++, simply because they do not like C++.
So, this was clearly intentional, because it's used by Apple directly. And it allows illicit access, because any program can use it to gain access.
Now, the fact that 'it takes too much effort' to backport would suggest that it was still in use. I don't see any other evidence, though. I'd be interested if someone found it!
systemsetup pointed to the Admin framework.
Admin framework analysis revealed use of "createFileWithContents". The function in which this use occurs is not named in the analysis.
An error message in the initial proof attempt led to "authenticateUsingAuthorization". Back to systemsetup to determine how to use "authenticateUsingAuthorization". (This is where I ended up mentally relinking the issue back to systemsetup.)
So, I concede that is is not stated where within the Admin framework this "createFileWithContents" method is invoked. However, I also agree that if that function was not used, it would be simple to remove it and the issue would be fixed.
Right, so the simplest explanation is that it's an unintentional bug. The absence of evidence that it was unintentional isn't evidence that it was intentional. If there were some magic string or default password or something, that'd be an obvious backdoor, but to me this looks like a pretty typical privesc bug, albeit in an undocumented api.
It was found through a chain of events that started with looking at the patch related to another privilege escalation vulnerability, one which no one seems to be claiming was a backdoor.
> Also, waiting to fix it until a researcher makes it public may have been intentional.
I'm guessing it's more likely the the researcher waiting to go public until it was fixed.
This is evidenced both by the fact that it was patched alongside other vulns (ie. not a rushed out one-off patch) and from the article's disclosure timeline, which shows 'Full disclosure' occurring 04/09, while the 'Release of OS X 10.10.3' occurred 04/08. This is a pretty typical disclosure timeline; they couldn't begin to fix it until it was tracked as a bug, after all.
Yes, there is. Sue Apple for willful negligence and subpoena the development logs.
I hate Apple's new yearly release cycle. There's not enough time to stabilize and improve OS's.
This update just rolled out, but it indicates the admin fixes are only for Yosemite:
https://support.apple.com/en-us/HT204659
How worried should I be about not having updated? There's still a risk I may lose some program compatibility by updating.
For a single-user desktop machine, realistically, user/root privilege separation doesn't matter, because all your important data is in your home directory and not protected by root privileges anyhow. The root-protected stuff is actually the stuff that's easiest to replace, because it's just a bunch of software that you can re-install. Viruses don't need to infect your software to stay resident; they can just as easily register a login hook without root permissions.
(That said, some people will violently disagree with me on this.)
It's dumbfounding how people here are simply shrugging this off and posting "So what? Just upgrade. Simples" type comments. This isn't acceptable. I know many people in creative industries alone who can't just upgrade immediately any time something comes out as they've to wait for their products to support the newer version. Similarly there are many who are using Macs in work whose corporate policies won't let them simply update immediately.
Then there's many who don't immediately upgrade versions as a point while bugs/other issues in that new version are found and resolved.
It's not an acceptable answer whatsoever.
The next one is a 3 year old Mac Mini. I upgraded to Yosemite and it performs TERRIBLY. It has 16G of RAM. I've tried everything. Yosemite just sucks. The machine is now much slower than the 6 or 7 year old iMac with only 4G or RAM. If it was practical to back out to Mavericks I would.
The last one is a 2 year old Macbook. I rely on it for my job. There is no way I'm going to risk the crappy Yosemite performance to upgrade. I'll live with the security flaw.
Here is what I now know about Apple: They will not support you for the lifetime of the product. They consistently release buggy code these days. Unless you are willing to shell out more money for new hardware every time they come out with something new, you will be stuck "as-is (with bugs)" until you get rid of it.
No more Apple anything for me. I'm thinking I'll switch the Mac Mini to Ubuntu if I can get it to work there. I'll use the iMac until it doesn't work any more, and when my Macbook is ready for an upgrade (in another year or two), I'll be trading in that still-Mavericks based system for a Linux laptop or maybe I'll go back to Windows.
I'd upgrade to Yosemite today with the latest updates. They just freed up 4 GB of ram for me. Sadly if I had known all of this beforehand I wouldn't have gone out of the way to buy some old Mac Pro where I could upgrade the memory to 32 GB or more, so I just wasted about $1500 for the whole setup.
Then again like you, I transitioned my work to an Ubuntu box, but even for my personal stuff my Mac was just really slow unless you get an SSD drive which is time consuming to install on an iMac.
For 2009 and up Mac Pros, there are plenty of hardware options for upgrades; and firmware as well for 2009.
Zero people is dumbfounding to you? Because that's how many people are saying that.
Reread the comments.
The second comment from the top when you go to
This is nothing close to "So what? Just upgrade." He's saying that from apple's perspective the best customer is one who upgrades their machine on every upgrade cycle which explains why they don't care about previous generation OSes. And how can you say this comment is apple-apologetic when he goes on to say that Microsoft does a better job maintaining backwards-compatibility?
If only it were that easy. Yosemite just seems to "break" some things and I've still been waiting it out.
> To be fair, OS X updates are free and usually run well even on 5+ years old hardware. OS X has kinda gone the way of Chrome, with most users on the newest version.
> While this is a significant vulnerability, I don't think the article is correct when it calls it a 'backdoor.' The term backdoor typically implies something that was intentionally left to allow illicit access, and while this is a significant bug, I don't see anything to indicate that's the case here.
> Title is a little generous about "hidden", the exploit revolves around API & Framework used to power the parts of the control panel, and its authorization scheme being broken.
> Smells like an oversight to me. Some new developer got assigned to implement or tweak the SSH enabling switch (or whatever), and this was their solution, which never got reviewed.
> Referring to Snow Leopard now not secure > Still pretty much the best OSX.
> Among other things upgrading (to 10.10.3) will do, it'll fix the issue in the article.
I don't intend that to be apologetic for Apple. I called it a 'significant vulnerability' but at the end of the day, it's a privilege escalation like those that have come before and will likely continue to be found occasionally, regardless of OS. I don't see what's apologetic about acknowledging a significant vulnerable while questioning whether it should be called a backdoor.
If you want to talk about Apple's response - I find it concerning that they aren't backporting the fix.
I have never seen Apple as being honest or making products for me as a nerd. So I live mostly in Linux nowadays.
I have no credibility since I don't like a company? What about the opposite people who like the company?
Credible people are always upfront with their biases. I never trust anyone that says they are neutral.
>Apple's model customer is one who upgrades often. If you want solid support for old products, stick with Microsoft, and accept that their products can be clunkier because of deliberate choices to maintain backwards-compatibility.
He was rebutting that regular upgrades are somehow a type of revenue to apple since they are free and work on some previous generation hardware. How is that apologetic?
A similar force seems to drive politics, or at least motivates disturbingly huge blocs of voters. :(
I don't like Apple's business practices, hard to hack devices and technology philosophy doesn't mean I am Tribal.
I have many machines that are over 5 years old.
I don't see a single comment in this thread that says that.
We do not allow developers to criticize our revolutionary and beautiful platform. Good luck ever getting an app featured again.
- Apple
"Backdoor" isn't quite right, since that implies that the intent was to allow unauthorized use.
"Security vulnerability" isn't quite right either, since that usually implies getting code to exhibit some sort of behavior it was never supposed to have.
I can't think of any other term. Of the two, "backdoor" seems closer. Maybe "unintentional backdoor"?
Local privilege escalation. In a huge number of established LPEs, the exploit is by leveraging a weakness in checking who makes the call that allows legitimate privilege escalation. This is a legitimate privilege escalation (sshd binds to port 22, among others tasks), that can be exploited through a weakness in checking who is making that request and if they can have that granted.
To me the term backdoor implies malevolence and purposeful decision to allow you to remotely access someone's system without their permission later.
And purposeful decision to allow you to remotely access someone's system without their permission later.
This seems more like a mistake, although a pretty big one. It seems like it was designed as a small escaped out to make some of Apple's scripts cleaner it wasn't locked down to the degree that should've been.
It's a big security hole, but I'm not sure backdoor fits.
(For values of 'nobody' which are not members of a set that includes such as Apple, obviously.)
Jargon and slang is needed for shortening the names of everyday things that people do, use or encounter.
If Apple has started a trend, we might need a new term, like "root kludge". A deliberate solution with negative attributes is a kludge (that much we have slang for, because we encounter such things with reasonable frequency). This type of kludge gets us root. So ...
Wait, if Apple starts a trend with this, then it will be cool, and have some name that begins with 'i'.
How about "iHole".
"An iHole was discovered in my wi-fi router's firmware".
Hmmm ...
This is pretty bad, and trivially exploitable. Basically anyone that has non-root access to your computer can trivially become root and take over the system.
Case in point: Antenna gate, Bend-gate etc.
Programs crash for a reason! Crashing when faced with nonsense is a good thing! Let us not forget this.
(Note: I, myself, do not ever rely on this functionality, and even disagree with it, but the context in which people use it is important to understand when judging it; and with that context, I consider my own objections mostly due to my biases and not something that I would argue is "correct".)
(Of course, no compilers actually do precisely that, but it is possible for compilers to delete virtual method calls entirely if it can prove the receiver had to be null...)
class Example {
public:
static bool do_it;
virtual void do_it_if() {
if (g_do_it) return;
/* otherwise do something that dereferences this... */
}
};
void test1() {
Example::do_it = false;
static_cast<Example *>(NULL)->do_it_if();
}
void test2() {
Example::do_it = true;
static_cast<Example *>(NULL)->do_it_if();
}
EDIT:
Also, it's worth explaining why test1 works even though do_it_if is virtual. Since there aren't any methods that override do_it_if, the virtual method lookup can be elided and you don't have to dereference this to find the vtable. If do_it_if had been overridden and the runtime type was unknown, you would need to dereference this to lookup do_it_if in the vtable, which would segfault in both tests.
I have a feeling it wouldn't work well in practice if you made the handler raise an exception. As the author notes, you're not the only one sending messages, and Cocoa will probably crash your program with a nil message send sooner or later. But you might be able to use it to find out where it's happening, at least.
if (input == nil)
haltAndCatchFire();
I was imagining something more like a modified version of the runtime's objc_msgSend() C function (which Obj-C method invocations get compiled into) that guarded against that, but you do make me realize that such checks could conceivably be automatically tacked on at build time.
Anyway, I'm not entirely sure how useful such a thing would be, but I am curious how often my code (unintentionally) makes calls against nil and I've just never noticed because it doesn't cause harm.
Static analysis could potentially go a long way here to expose values that could be potentially "infected" with nil. (And, for all I know, the JVM JIT could do exactly this to skip checks on provably non-null values.)
The first thing objc_msgSend does is check if foo is nil and, if so, returns 0/nil/the all-zero bit pattern/whatever. It can be extremely convenient, but it can also be extremely inconvenient.
Anyway, I'll carry on reading my ObjC book as obviously the language has uses, although there's a Swift book in the post. Which do I read first though, eh?
>Philip tried patching that function (replacing sete with setne), with success:
How do you patch the binary without root or the admin user password anyway?
Hint: the first sentence you quoted ends with a question mark.
If you're a regular user of an OSX system before 10.10.3, and you want to become root (admin user), you can use this exploit to become root.
If you're an author of malicious OSX software, and a user without admin permissions installs your malware, you can use this exploit to make your malware run as root.
Once you have root, you can do anything on a system.
If the system you're attacking is 10.10.3 or later, you won't be able to use this exploit because Apple has a fix in 10.10.3.
Apple will not make the fix available to anyone on 10.9 or earlier.
Sandboxed apps (from the app storr) may be blocked from doing this, I'm not sure.
Just tried. Sandbox lets this through. (As long as you pass nil to authenticateUsingAuthorizationSync:).
Impact: A local user may be able to cause a system denial of service
Impact: A local user may be able to cause unexpected system shutdown
These two made me laugh though.
Quite a few other security related things are fixed with this update that do apply to older versions of OS X.
Lion was cancer.
Are you sorry you upgraded? (I'm asking for a friend.)
I've managed to get it working after a fashion, although not reliably, and have come to the conclusion that Apple just don't do wireless well.
http://www.amazon.com/Samsung-Portable-250GB-External-MU-PS2...
USB 3.0 is pretty fast. Without TRIM performance will probably degrade but that will take time.
The only kernel panics I've experienced so far have been Parallels Desktop bugs that crashed the system. I'm regularly stressing my Macbook Pro to the max running vagrant images through Parallel Desktop with full integration tests running inside, and this tends to be pretty effective at finding strange bugs in Parallels Desktop.
Deleted comment
Deleted comment