Flaw Found in Apple Bug-Fix Tool

eldavojohn writes "The Month of Apple Bugs (MOAB) is well under way with a startling bug released Monday. From the description: 'Application Enhancer (APE) is affected by a local privilege escalation vulnerability which allows local users to gain root privileges.' APE is the same software used to deploy fixes during 'The Month of Apple Fixes' (MOAF). I know it's confusing but MOAB came first and MOAF was a developer's answer to the bugs — after all, the purpose of posting bugs is to have them identified, confirmed and eradicated. The article talks about potential remote root access by an intruder. Note that this is third party software that all of the bugs seem to be stemming from. I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards."

Comments

A HA!

[Thansal]

I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards.

I see it now. This entire MOAB thing is just there to tout how great and secure Apple Products are, and that the only bugs possible HAVE to come from 3rd party software!

It is all a plot by Jobs!

A PLOT I TELL YOU!

[/psycho]

Re:A HA!

[Overly Critical Guy]

Really, though, this is lame. Another third-party bug? Pointing out third-party bugs is great, but this was touted as a month of Apple bugs to point out insecurities that needed to be fixed in Apple software. Widening that to third-party bugs is a little disingenuous and misleading.

Story at 11

[teratogenicbenzene]

So, this is the best MOAB has to offer? A security bug in a third-party "enhancement"?

This is scaremongering at its best. Nothing to see here, move along.

Re:Story at 11

[Anonymous Coward]

And Quicktime. And Finder.

The Reality Distortion Field seems to be operating at peak effiency however. Your illusions are still quite secure.

Re:Story at 11

[paulpach]

So, this is the best MOAB has to offer? A security bug in a third-party "enhancement"? No, the best they have to offer are vulnerabilities in quicktime, iPhoto, Disk Management, Finder which are apple products. Why CNet and slashdot chose to report on this particular vulnerability, which to many is the least important in the list, is a mistery to me.

Re:Story at 11

[Rosyna]

This is scaremongering at its best. Nothing to see here, move along.

I disagree with "at its best". The example "exploit" installs what basically amounts to a rootkit. So, in other words, this security "researcher" is distributing malware that gives him access to anyone's computer that accesses it. Since when do real security researchers distribute malware? More information is in the comments here.

Not to mention he posted this thing with nothing but malice. It was done because Landon Fuller refused to work with LHM. LHM wanted to keep the bugs from the developers and said as a condition of such working together, that Landon Fuller must not tell anyone else about the bugs.

Re:Story at 11

[ResidntGeek]

That's a good point. Everyone knows that people target only the operating system. No self-respecting hacker would ever attack a third-party tool to gain access to a system, right?

Re:Story at 11

[egomaniac]

That's a good point. Everyone knows that people target only the operating system. No self-respecting hacker would ever attack a third-party tool to gain access to a system, right?

So it would be fair to declare a "Month of Microsoft Bugs" and then reveal bugs that Microsoft had nothing to do with?

Re:Story at 11

[Goaway]

Basically, LMH is a thin-skinned and borderline psychotic attention whore. He pretends he "does it for the lulz", but he's really lashing out at anybody who doesn't worship him for his l33t sk33lls, and posts incomprehensible rants about everybody who disagrees with him.

Re:Story at 11

[93 Escort Wagon]

"No, the best they have to offer are vulnerabilities in quicktime, iPhoto, Disk Management, Finder which are apple products. Why CNet and slashdot chose to report on this particular vulnerability, which to many is the least important in the list, is a mistery to me."

Look, while they have included some legitimate bugs it's pretty obvious the project is flailing around somewhat, given that it's only the 10th of "MOAB". In addition to the APE flaw, they've included a VLC flaw and an OmniWeb flaw - neither of which is part of OS X nor installed on any stock Apple box. Additionally they've included a PDF flaw, which isn't even specific to OS X! That's just plain silly.

Re:Story at 11

[Goaway]

It's attention whoring. And reading his blog, LMH seems to have quite the unstable personality, given to going on off on incomprehensible rants about those who disagree with him or refuse to acknowledge his greatness, thinly veiled as flippant ironic "lulz".

Re:Story at 11

[Jeremy Erwin]

The Month of Apple Bugs intended to identify 31 security problems in Apple Software. The Month of Apple Fixes intended to fix those bugs in short order, so that they would not represent as much of a security threat between announcement and release of an official bugfix. Because much of MacOSX is closed source, patched binaries were a means of distributing these fixes. The latest bug was found in the third party tool that was used to patch the binaries at runtime.

Re:Story at 11

[peragrin]

so out of 10 days in this month so far only 4 have been Apple security bugs. So far 40% have been holes that are apple's fault.

I don't know about you, but if some one found a bug in Windowblinds, or some other Windows skinning app, and said it was MSFT's fault then I would be suspicious too.

Also there is a bug in VLC. how is a VLC player bug that is also found in the windows and linux versions an "apple" bug.

If it's an apple product by all means go for it. But no one blames MSFT for bugs in Lotus Notes.

Re:Story at 11

[Lunar_Lamp]

I guess it depends if the purpose of publishing the bugs is to fix OS X, or whether it's to educate Apple users that just because you use OS X, you are not immune; it's possible (probable?) that somewhere on your system there will be vulnerabilities. I know as a Linux user I find it very easy to think "I don't need to be very aware of security because I use Linux". At minimum, it's a reminder that whilst OS X is more secure than Windows XP natively, it is not immune from vulnerabilities.

Re:Story at 11

[paulpach]

If it's an apple product by all means go for it. But no one blames MSFT for bugs in Lotus Notes. from the faq on the first page

3. Are Apple products the only one target of this initiative?

Not at all, but they are the main focus. We'll be looking over popular OS X applications as well.

So they are not blaming apple anywhere in their site or implying this vulnerability is apple's fault at all. Where did you get that idea? This is not a project to destroy or harm apple, quite the opposite, it will help them in the long run.

Re:Story at 11

[iluvcapra]

DOS ain't done until Lotus won't run?

Of course in that case, from MSFTs perspective that was a feature, not a bug.

Re:Story at 11

[99BottlesOfBeerInMyF]

I guess it depends if the purpose of publishing the bugs is to fix OS X, or whether it's to educate Apple users that just because you use OS X, you are not immune; it's possible (probable?) that somewhere on your system there will be vulnerabilities.

If you think that is the purpose of the MOAB then you're very, very optimistic, perhaps naive. The purpose is to gain publicity for a few, unscrupulous researchers. They've done this before with other vendors and even agreed to cancel one such project after being paid off. Apple users who know anything about security know there is the potential for security flaws, but they also know the potential is much less than if they are running Windows. Apple users and potential Apple who don't know anything, may be confused by this into thinking that OS X is no more secure than Windows and hence stay with Windows. The simple message "use a mac and you're unlikely to suffer from worms and viruses" is true and simple enough for most people. Complicating the message with, "but if you're using some third party utility, or even some included utilities there is the possibility someone could write a worm, but tso far no one has and they are unlikely to do so in the near future" is way too complex.

At minimum, it's a reminder that whilst OS X is more secure than Windows XP natively, it is not immune from vulnerabilities.

Finding vulnerabilities and not reporting them to the vendor or making them public until it will get you the most press, is detrimental to security and does more to help black hats than it does to help users. Trying to obscure and complicate the simple message that mac==more secure than windows, likewise is detrimental to overall security. The only thing this project is really accomplishing is publicity for themselves at the expense of everyone else. These guys are anti-security researchers. If they aren't willing to behave ethically, they can rot.

Re:Story at 11

[Anonymous Coward]

Nothing but malice? That could be true, but at least they're pointing out incompetant "developers" who get very, very simple things wrong. That seems like a useful thing to do regardless of the motivation behind it.

Re:Story at 11

[Anonymous Coward]

Then why call it the Month of Apple Bugs? By the virtue of the name they've chosen, they imply all vulnerabilities are Apple's fault. If they don't want to do so, surely smart researchers can come up with a name that does not imply all bugs stems from Apple? I don't buy the explanation, it's more like a cover your ass disclaimer.

Re:Story at 11

[Moofie]

"Where did you get that idea?"

Um, from the title of the "project", which is "Month Of Apple Bugs". Golly, how could I possibly have been mislead?

Re:Story at 11

[BorgCopyeditor]

So, the title "Month of Apple Bugs" doesn't imply anything? Yes, you could take it to mean "bugs that infect applications developed for use on the operating system running on most computers made by Apple," but that's just not as sexy, is it? If a similar project were called "Month of Microsoft Bugs" and mostly targeted 3rd party apps, I wager people would more quickly see the problem.

Re:Story at 11

[laffer1]

No, the price of using a computer is to patch it and not run untrusted software. It does not matter what OS you are using. If you tell people they are invincible because they have a Mac or use linux, you are doing them a disservice. You are also lying to them.

I tell people that Macs or anything but windows are safer because less people care to attack them. I tell them that they must run software update and every two versions of Mac OS they must upgrade. (Apple stops patching after 2 releases) There are many bad things I can say about microsoft, but they do provide patches for a much longer period. Covering 1 or 2 products with back patches is a lot of work, but with the windows release cycle you get 5-6 years of patches! With Mac OS X you get 2 to 3 years of patches. You can argue all day long about how that isn't important on Mac desktops, but after administering an OS X server, I can tell you its very important!

I have talked a few people into using open source software since they can not afford to buy new software constantly. Staying current isn't cheap and with Mac OS X you often need to buy upgrades to get software to work in new versions of the OS. This is true with Adobe software and to a lesser degree with other applications.

Re:Story at 11

[Anonymous Coward]

OMG. Now I know this is slashdot, but could people read the article in question. OK, OK, I know that's asking too much here. How about reading the first page http://projects.info-pull.com/moab/ , OK, yeah that sure is a lot of reading. How about just the text that is all in Bold so hopefully you won't miss it. Yeah, yeah, not enough time in the day. How about just reading bolded point 3 out of 9 points. Oh yeah, going off the forum page is too much work. well here it is for you...
 
  Are Apple products the only one target of this initiative?
Not at all, but they are the main focus. We'll be looking over popular OS X applications as well.

I'd explain that couple of sentences too, but I'm tired of zealotry about Mac's on Slashdot. It is another OS, pure and simple, like all other OS's out there security should be scrutinized. It's the zealots own fault for attracting attention in the bad manner for claiming such lofty security, of course someone is going to look at it. The moab is a over the top in it's presentation, but that's about it. I've also heard (but could be wrong) that they are starting with the most trivial bugs first, if that is the case, than wait until after the 30th then come back and say "is that it?", than it will actually mean something. maybe you'll be right, maybe you'll be wrong, but now seems hardly the time to speculate about everything they have found.

Re:Story at 11

[profplump]

While there are some valid bugs listed, the Disk Management one basically says "anyone in the admin group can arbitrarily set file permissions". I don't know about you, but given that the admin group has, by design, unrestricted access to `sudo` I wouldn't consider their ability to set file permissions in a convoluted way a very serious security threat.

The report talks about the ability to change permissions and then use those changed permissions to run programs as root. Maybe it's just me I'm pretty sure it would be easier to just type `sudo su` followed by your password. Follow that with `rm -f /var/log/asl.log` and you'll even delete the evidence.

Re:Story at 11

[99BottlesOfBeerInMyF]

No, the price of using a computer is to patch it and not run untrusted software.

Bullshit. That's like saying the purpose of forks is to eat vegetables, and if some forks happen to create a toxic substance when they touch other substances, it is not a concern. People want to run untrusted binaries, because the majority of binaries people run are untrusted to some degree or another. When malware is common, it makes sense to make sure that untrusted binaries are restricted by default.

It does not matter what OS you are using. If you tell people they are invincible because they have a Mac or use linux, you are doing them a disservice. You are also lying to them.

Yeah, now show me one example of a person with any authority seriously saying macs are invincible... just one. Apple doesn't say that. I've never seen a security researcher, or even sensationalist papers say that. If you do a Google search for "mac invincible" you find one blogger asking if Macs are invincible and one article explaining that your statement is a classic strawman argument.

I tell people that Macs or anything but windows are safer because less people care to attack them.

That is a fine message to spread, but if the paper is reporting, "30 bugs in Macintosh computers in a month demonstrate they are not secure," what do you think the average Windows user will take away from that headline? Do you think they will correctly derive from that headline that if they get a mac the chances of them getting malware are almost zero, or do you think they will take from that that it does not matter if they have a mac or a Windows machine, they are still going to get malware? Do you think it makes people more or less likely to be infected with malware, considering it may well dissuade people from moving to both Mac and Linux machines?

The poorly named MOAB is dropping vulnerabilities one after another intentionally spread out, with no prior notification in such a way that Apple either has to wait for all of them, or commit to not fixing some of them right away simply because of the time necessary for development and QA cycles. Can you think of a better way to encourage malware without actually creating exploit code yourself? Further, they're intentionally delaying releasing vulnerabilities they have found to the public, increasing the window for exploitation. Why? It gets them more press that way and a truly cynical person might say because it is the best way to encourage malware based upon their bugs so that they can get more press as they talk about how they discovered the hole first and were right about how Apple would get hacked. It is utterly irresponsible.

Re:Story at 11

[profplump]

Upon further investigate, the Finder vulnerability is also pretty weak. It's at least got the potential to allow code execution (but not privilege escalation) and I agree that it's sloppy programming that should be fixed.

But their report says that in trying to expliot the flaw their DMG failed validation test done before mounting the image and that they were therefore unable to create a working exploit. The rest of their report is based on the assumption that they could manipulate parts of the DMG file and bypass the validation already in place, without any real indication of how that might happen.

Re:Story at 11

[99BottlesOfBeerInMyF]

What they write on their Web page is pretty irrelevant when they create a project called "Month of Apple Bugs." To blatantly rip off The Simpsons, "...for every dollar of Krusty merchandise you buy I will be nice to a sick kid. For legal purposes sick kids may include hookers with a cold."

It's the zealots own fault for attracting attention in the bad manner for claiming such lofty security, of course someone is going to look at it.

This such such a tired and sad implicit assumption. Who on Slashdot has ever claimed that OS X was some super secure solution, or immune to malware? Lots of people tout it as secure, but that is because the most common OS that sets the measure is Windows. Compared to Windows, OS X is very secure and that message should be repeated as much as possible until the average person on the street knows it, in order to motivate people to switch and Microsoft to solve the problem.

The moab is a over the top in it's presentation, but that's about it.

Who cares about the presentation. I'm concerned about security. The guys running this obviously aren't worried about the security of users because they are compromising that security in order to make money. If I wanted to make most users less secure what would be a good way? First, I'd spread misleading press that convinces them OS X and other OS's (like that umm, Linkus OS, my cousin mentioned) are no more secure that Windows. Next, I'd search out vulnerabilities in the most common OS that is not regularly compromised, and try to encourage malware authors to write malware for them. A good way to do that would be to not inform the vendor before I released the vulnerabilities, so they don't have a chance to fix them. Then, I'd release them spread out over a long period of time, so that they can't do a development/QA cycle until all of them are released, unless they want to commit to not fixing some of them, thus maximizing the amount of time between publication and patch.

These guys are not responsible security researchers and they're maximizing their press coverage at the expense of everyone else. Nothing was stopping these guys from quietly finding a bug a day for a month, and immediately informing the relevant vendor, and then announcing afterwards what they had done after the vendors had a short time to fix the bugs. The only problem would be they would not get as much press coverage and the chances of a worm being created and spread would be less, thus making it less likely they can ride that short bus to more press coverage.

The fact that you see nothing wrong with this means either you haven't thought it through, you don't have any idea what responsible handling of vulnerabilities is, or you don't care about security at all and are just reacting emotionally because you don't like people talking about OS X being secure and ignoring whatever your favorite OS is. P.S. your favorite OS sucks.

Re:Story at 11

[elrous0]

Compared to Windows, OS X is very secure and that message should be repeated as much as possible until the average person on the street knows it, in order to motivate people to switch and Microsoft to solve the problem.

One of the biggest security advantages the OS X has is that Apple has such a small market share that hackers/malware and adware coders/etc. don't bother to mess with it. If everyone switched, then you would lose that advantage and OS X would end up just as much a malware/virus/trojan/exploit target as XP and Vista.

Be glad your little OS flies under the radar. You should pray it stays that way. If it ever becomes widely adopted like a real OS, it will only cause you grief.

-Eric

Re:Story at 11

[644bd346996]

Bad example. Nobody would need to look beyond MS branded products. A better example would be a "Month of Java Bugs" where half of the bugs were from Azureus and Eclipse.

While I agree that MOAB is not doing particularly well, VLC, Omniweb, and APE are all extremely common. The PDF bug is very dangerous, because PDF is so pervasive to the Aqua UI that almost any application could be the entry point.

Re:Story at 11

[Overly Critical Guy]

But this was supposed to be a month of Apple bugs. Not third-party bugs.

Why CNet and slashdot chose to report on this particular vulnerability, which to many is the least important in the list, is a mistery to me.

Because journalism is a business, and that means it isn't concerned with relevant truths; it wants "storylines" that will generate interest and therefore revenues. It's a cute storyline for them that the application enhancer used to patch bugs has a bug. Hence, it gets reported and others don't.

Re:Story at 11

[Overly Critical Guy]

So they are not blaming apple anywhere in their site or implying this vulnerability is apple's fault at all. Where did you get that idea?

In the title, which isn't "Month of Bugs, Some of Which Are In Mac Software."

Re:Story at 11

[larkost]

While that is probably true (there is little to no way of checking, so we have to admit that it is a guess), it misses the very important point that many of Microsoft's problems with security have been through really bad design decisions. The whole idea of letting email run scripts is just bad from the get-go, and that is exactly what Outlook was designed to do. Since then they have been trying to keep that functionality for the few corporate users who rely on it, while putting the majority of us who don't at major risk.

Re:Story at 11

[argent]

I tell people that Macs or anything but windows are safer because less people care to attack them.

Also because there are systematic security problems in Windows that are inherently unfixable without breaking working applications.

For example, simply not using Microsoft Office or Internet Explorer (or any other application that uses Microsoft's flawed HTML control or trusts random serialised COM objects... most of which are Microsoft apps) is a more effective anti-virus and anti-spyware solution than just about anything else... including running antivirus software, keeping the system updated, and applying patches judiciously every Tuesday. Combine that with an external firewall router and about the only way you're going to get infected is if you explicitly install infected software. That is the only antivirus I've used on Windows since 1997, and so far I'm batting 1.000.

Re:Story at 11

[Anonymous Coward]

The current flaw is pretty lame, too. Anyone with local access to the machine can just boot the thing into single-user mode and get a root prompt, or for that matter boot off an install disk and reset the admin password or format the whole damned drive.

This "Apple bug" should be called "bug in a third-party kernel hack that you need to have admin privs to install in the first place".

These guys are really scraping.

Re:Story at 11

[thelamecamel]

Remember that to use 'sudo' you have to type your password, so any malicious program that wanted to arbitrarily set the permissions using sudo would need to ask your password (or tailgate something else that did - I think you only need to type your password once every 5 mins for sudo)

Using this vulnerability, presumably any malicious program can change the file permissions without using sudo, so it doesn't need your password, so you'll never know.

Re:Story at 11

[SeaFox]

Why CNet and slashdot chose to report on this particular vulnerability, which to many is the least important in the list, is a mistery to me.

Well Application Enhancer is the software being used to apply the temporary bug fixes until the MOAB bugs are actually fixed by their vendors, and now a MOAB bug as been found in the APE software itself. So it's rather like those Microsoft patches a couple months back that while patching their venerabilities as designed created new holes.

Re:Story at 11

[Tim C]

it's possible (probable?) that somewhere on your system there will be vulnerabilities

Actually, it's absolutely certain that almost no matter what system you're using there will be vulnerabilities. Just because they haven't been found and exploited doesn't mean they're not there - lack of evidence is not evidence of lack, and all that.

Re:Story at 11

[profplump]

So what you're saying is "If you run a program that does nasty things while you're logged in as an admin user, that program could gain root privileges, even without your password"

You'd still have to run a program that does nasty things, and that program would still have to be launched with admin privileges. Once you get to that point, it doesn't really matter how the rest of the system behaves -- the best you can hope for is some sort of log. Anything else would prevent you from actually using the system.

For example, a malicious program running as your user could, without a password, install a script that runs automatically at loging and waits for you to run a privilege-elevating program (like sudo or the installer). It could then use hijack the privileges you get from that program to execute commands as root. Or it could sit around and look for recently created installer packages (like those downloaded by Software Update), and infect the package with a script that will be run as root after the user willingly types their password.

Re:Story at 11

[laffer1]

Yeah, now show me one example of a person with any authority seriously saying macs are invincible... just one. Apple doesn't say that. I've never seen a security researcher, or even sensationalist papers say that. If you do a Google search for "mac invincible" you find one blogger asking if Macs are invincible and one article explaining that your statement is a classic strawman argument.

Apple, Inc. did suggest that they can't get viruses. View their television ads. http://www.apple.com/getamac/ads/ (Viruses I believe)

Since I consider Apple an authority on Apple computers, I think that backs it up. Take the ad at face value look an end user would and you'll see the problem. Granted, you can also find lists on apple's website suggesting antivirus software too. I don't see those in their ads though. They are scared to tell people that any computer could be compromised just as you are.

Windows users don't care about security anyway. If they did, they wouldn't be using Windows. Lets face it, at least once a year there is a big worm scare in the media like the iloveyou worm, etc. My grandmother won't even get a computer at all because the media has scared her from them. Most of my family doesn't see a reason to upgrade from Windows ME or Windows 2000 because security isn't a concern, only price and functionality. The real deterrent to apple is that they won't advertise Mac OS X aggressively. There are many advantages to OS X over windows, and while we start to see progress in their ads, its still not enough to convince people Mac OS X is better than windows. Similarly, IBM's pro linux ads encouraged a few people but not a mass exodus from Windows on servers. (it did hurt Microsoft a bit) Now if apple were to focus on software included with Macintosh systems plus all the third party software available, they might see some progress. The ad mentioning Microsoft Office support encouraged a few people I know to ask me about it. If you believe slashdot, gaming is the real issue anyway.

I prefer vendors be notified prior to releasing information about an exploit. Time to fix it is even better. You act as if I like 0 day exploits against systems. I administer a Mac based network at work. I have good reason to want patches.

Re:Story at 11

[mstone]

Old meme, long-since discredited.

Yes, there may be network effects to consider when setting the desirability to attack a given platform, but the 'pure market share' idea is just plain bullshit.

Equally tired response #1: webservers -- Apache has the largest market share in httpds, but it lags well behind IIS in exploits.

Equally tired response #2: coefficient of correlation -- If market share is the only metric that matters, what's the CoC for exploitation? It can't be linear (N% market share equals N% of the exploits), because OS X's install base is certainly no less than 1/25th of Windows's, and OS X doesn't have 1/25th the number of exploits Windows does. Nor can the CoC be a square of the install base. That predicts no less than 1/625th of the exploits for OS X that we see for Windows, and the numbers don't support that rating either. How much market share does Apple need to get before it passes this magical tipping point you're talking about and suddenly sees just as many exploits as Windows? It can't be 50% or even beyond, because Apache has held that much install base relative to Windows and still doesn't have 1:1 parity with Windows in wild exploits.

Attack frequency is a function of both popularity and raw vulnerability. How much bang do you get for the buck? How many systems do you have to try before you can find one with a hole, and how much value can you get out of the hole you find?

Are you honestly willing to say that if Macs were 95% exploitable through some hole whose exploitation could be automated and distributed over the internet (just like all the other 'sploit kits script kiddies use), that the platform would remain completely unmolested because there are 'only' a few tens of millions of exploitable systems out there?

Get real.

Re:Story at 11

[Em Adespoton]

The problem here is that it's almost impossible to avoid using Internet Explorer. I had mine locked down tight, and eventually found that I needed to allow ActiveX components to get anything done; some third party software depends on the vulnrable parts of IE being exposed, or it won't function correctly.

Personally, I think the solution to this is for MS to break compatibility with those apps -- after all, they've been breaking compatibility with other apps ever since Windows 2000... Vista kills even more legacy support. Why not just patch the COM handling, and tell the TPDs they have to fix THEIR software?

Right now, I'm in a situation where I have to find and create workarounds and patches for both MS apps and third party apps in order to for my computers to stay both secure and functional. On OS X, I just have to avoid using dangerous apps, like you suggested. Of course, as soon as someone finds an attack vector usable with Apple Events, OS X will be the Emperor's new OS.

Re:Story at 11

[Em Adespoton]

Kind of, except it would be more like using some third party using a third party created kernel hacking tool to fix patches, only to discover that the kernel hacking tool was insecure.

APE has been known to be an attack vector for years... it's a third party piece of software that lets other third parties make untrusted changes to the OS X kernel using a simple API. There are some really neat things done with it, and there have also been a few really buggy plugins made for it that can mess up the OS. Using APE to apply bugfixes was just asking for trouble.

Re:Story at 11

[SeaFox]

Using APE to apply bug fixes was just asking for trouble.

The APE hacks were never meant to be permanent, but they were better than nothing. One of the nice things about this "solution" is the underlying code on disk is not changed, so users don't have to do clean installs before they add in the vendor approved patch.

I don't think it's a coincidence that this exploit came out. I'm sure the "researcher" hasn't been too pleased with the efforts to patch every flaw as soon as its released. It's taken quite a bit of PR-wind out of his project's sails. Now users will be more wary to use the APE patching since they will see it as adding exploits into their system.

Re:Story at 11

[DJ_Adequate]

And of course the people promoting the "Month of apple Bugs" weren't trying to sell a story-line when they named their little project. Or when they hype every find on Slashdot. Nope, they were just interested in the "Truth".

Re:Story at 11

[jt2377]

"Are you honestly willing to say that if Macs were 95% exploitable through some hole whose exploitation could be automated and distributed over the internet (just like all the other 'sploit kits script kiddies use), that the platform would remain completely unmolested because there are 'only' a few tens of millions of exploitable systems out there?"

yes. if Mac have 99% of the marekt share like Windows. it will crippled down like Windows but you won't believe it because we will never see it happen.

the underline OS that Apache run on *nix is not targeted like Windows. Thus, Apache have bigger marketshare with less exploits. IIS run on top of Winodws which is targeted by everyone.

Re:Story at 11

[argent]

The problem here is that it's almost impossible to avoid using Internet Explorer.

It's a LOT easier now than it was when the alternative was Netscape 4, friend. Don't "lock it down tight", just don't use it at all until you actually need to for something that matters (that would be 'you can't get to your bank account without it'... not 'Youtube is screwing up with Firefox').

Of course, as soon as someone finds an attack vector usable with Apple Events, OS X will be the Emperor's new OS.

Indeed. I am not at all happy that Safari accepts applescript://com.apple.scripteditor without a dialog, but I have been aware of this issue for a while. :)

Re:Story at 11

[Kesh]

Mod parent UP. This one is pretty clear bad-faith exploit on the MoAB folks' part.

Re:Story at 11

[Khabok]

no one blames MSFT for bugs in Lotus Notes.

Lotus Notes has not been removed from exhistence yet. In a way, I think this is everyone's fault.

Re:Story at 11

[Anonymous Coward]

'30 bugs in Macintosh computers in a month demonstrate they are not secure'

So that basically gives the fanboys the opportunity to behave as repulsively as they do, for attempting to counteract their behaviour only results in Windows users getting the wrong message.

Alternatively you could say that if MOAB hurts things by scaring away Windows users, it's the fanboys' fault.

Re:Story at 11

[99BottlesOfBeerInMyF]

Apple, Inc. did suggest that they can't get viruses... Since I consider Apple an authority on Apple computers, I think that backs it up.

No, Apple states that they don't get viruses, which is true, to date they have not had any in the wild viruses, with possible exceptions being so obscure and useless as to not really count. If you bought a Mac 5 years ago, the chances that you caught a virus on it are infinitesimal, unlike Windows, to which they are directly comparing OS X. Their commercial may not tell the whole story, but what it does tell is accurate.

They are scared to tell people that any computer could be compromised just as you are.

They're interested in making money. I'm speaking from the perspective of improving overall security. Do you really think overall security is served by addressing that .00001% chance that someone is likely to get a virus while running a Mac, keeping in mind most people would interpret that comment as "there is no reason to switch away from Windows since all OS's are the same."???

Windows users don't care about security anyway. If they did, they wouldn't be using Windows.

Bullshit. The average person doesn't know Windows is less secure than other offerings. They don't know what other offerings are. The only computers in the store (Walmart, Kmart, Meijer) run Windows. People are accustomed to free markets, not monopolized markets. Thus they assume if there was something better that would keep them from getting worms, it would be in the store.

Lets face it, at least once a year there is a big worm scare in the media like the iloveyou worm, etc. My grandmother won't even get a computer at all because the media has scared her from them. Most of my family doesn't see a reason to upgrade from Windows ME or Windows 2000 because security isn't a concern, only price and functionality.

Most people don't know that upgrading will help the situation and most people are incapable of performing said upgrade.

I prefer vendors be notified prior to releasing information about an exploit. Time to fix it is even better. You act as if I like 0 day exploits against systems.

You're arguing in favor of people who don't release info to the vendor or the public right away, but sit on vulnerabilities until it gets them more press. Worse, they intentionally space those announcements in such a way that a regular development/QA cycle has to wait an entire month before it can start in order to get all the vulnerabilities in, maximizing the exposure window. It is worse in multiple ways than even immediate public disclosure.

You act as if I like 0 day exploits against systems. I administer a Mac based network at work. I have good reason to want patches.

I don't care about your motivations, as they are not what I'm arguing against. I disagree with your statements supporting this unethical project and against your beliefs that it is helping somehow.

Re:Story at 11

[kcarlin]

So there are more exploits against Windows than OS X because of OS market share, but fewer exploits against Apache than IIS causing Apache's greater market share. (On occasions when I've been involved, general reliability, ease of use, and price point all weighed heavily in Apache's favor. The usual assumption being that aggressive patching would nullify any differences in exploitability.)

Assuming your observation is accurate, the long-term effect on OS X sales vis a vis Windows sales is left as an exercise for the investor.

Re:Story at 11

[Em Adespoton]

It's a LOT easier now than it was when the alternative was Netscape 4, friend. Don't "lock it down tight", just don't use it at all until you actually need to for something that matters (that would be 'you can't get to your bank account without it'... not 'Youtube is screwing up with Firefox').

The problem with not using it at all is that third party malware can still use it, as the core runtime library is ALWAYS LOADED IN MEMORY as long as you have Windows Explorer running. If you only use Norton Commander or something similar, and kill the start bar and desktop and Explorer windows, IE is truely gone. Otherwise, all you have to do is have the wrong file sitting on your computer and it can auto-inject itself into IE whenever a number of routine OS functions are performed. One solution, I guess, would be to dump Explorer for LiteStep, which works quite nicely on XP. It also has the bonus that anything compiled specifically for Windows OpenStep can usually run on x86 OS X without much hassle.

Re:Story at 11

[argent]

The problem with not using it at all is that third party malware can still use it

The point to not using IE isn't to keep "third party malware" from using it once you're already penetrated, it's to make it even possible keep it out of your computer in the first place. To reduce the problem to one where you can control it by controlling your own behaviour.

Yes, if you download a file containing an ActiveX exploit and open it from your desktop it can use the ActiveX exploit to bootstrap into execution and own your computer. But if you download a file to your desktop and open it you're risking getting owned regardless of whether ActiveX is in the loop at all. Saving untrusted documents to disk and opening them outside the browser's "sandbox" is risky behaviour. But you can learn not to engage in that risky behaviour.

With the HTML control, the decision to open a document and what to open it with is taken away from you. You no longer have the ability to consciously make that choice.

Yes, you do have to avoid more than just IE. You have to avoid Outlook, Windows Media Player (later then version 2), Realplayer, and other applications that use it. You have to learn what those applications are. But you can do that, and you can set your company's policies to match. I did that, starting in 1997, and we were the only location in our organization that didn't have a major virus incident during the years I kept that policy in place.

Re:Story at 11

[laffer1]

Public disclosure does help. Eventually someone will most likely find these bugs. What if an unethical person sat on the knowledge and used it for personal gain? I don't assume all bugs in software are reported or made public. There's also a small chance the programmers will notice other bugs or defects in the code when a bug or defect is published.

I'd much rather these people "play fair", but quite frankly things could be worse. As for meijer, they should replace those damn cash registers with something that doesn't lock up while ringing an order. Some stores use cash registers running on DOS or other systems. Maybe you could start a company to make point of sale solutions that don't run windows and make everyone's day.

I personally report any bugs or vulnerabilities I find in software whenever possible. In fact, I just reported something to apple today using bugreport.apple.com.

Well, well, well

[Anonymous Coward]

What do you have to say for yourselves now, Apple fanboys? With this glaring bug, coupled with the other devastating bugs, it now is clear that your smug castle is crumbling. Maybe it's time to give the rock-solid Vista another chance, no?

Re:Well, well, well

[Xugumad]

I dunno, I'm not sure paranoid and twitchy is an improvement in OS terms :)

(Vista really does seem terrified that someone else might be touching your computer)

Re:Well, well, well

[Anonymous Coward]

Vista is paranoid that you are touching your own computer in a way that Microsoft doesn't like...

Re:Well, well, well

[Divebus]

Crumbling? Hardly. The OS has been out for almost 6 years and they can only w00t about 30 bugs. This list probably took many months to figure out where there were probably 3,000 bugs in Windows during the same period.

For the Apple bugs, half of them so far are in 3rd party apps, many require you to install them sitting at the keyboard with the root password and the rest may actually do some damage if the operator can be coaxed into 8 simple steps... and now they probably won't any more. As obtuse as much of this is, it's good that someone is pointing these out so they'll get fixed.

And Vista? Puuullleeeezzz. It has a smaller installed base than BeOS and the exploits are out there already for Vista.

Personally I think

[0racle]

Note that this is third party software that all of the bugs seem to be stemming from. I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards.

Personally I think that the reason most/all of the bugs released are 3rd party apps and not OS X itself is that the people running the project are to lazy to try and find some actual Apple bugs.

Errr...

[WalterGR]

Note that this is third party software that all of the bugs seem to be stemming from.

So far MOAB has released 2 bugs for QuickTime, 1 for iLife, 1 for DiskManagement/diskutil, and 1 for Finder.

Re:Errr...

[jellomizer]

5 Bugs on 4 Apple products, 3 of these products that come default with the OS. 2 of these products are Core to the OS. and only one of these products a User can't use a mac without. 10 Days in. That is still darn good. The point is all these 3rd party apps that are being added to the list to make Macs look insecure, give me an Open BSD system, then install some 3rd party apps, misconfigure Open SSH, and bang it is not as secure as it use to be. I was expecing by this point to be 20-30 bugs found just on the products that comes with OS X and 15-20 bugs on Apples Bonus Products, and perhaps 10-15 holes on 3rd party applications that are actually popular for OS X (Photoshop, Flip for Mac, PageMaker...)

It seems like these guys are straining to find a hole a day, so they go into some marginally popular 3rd party apps to find ways in OS X.

Re:Errr...

[TheSkyIsPurple]

And also note that the OS is supposed to be secure, which means 3rd party stuff shouldn't be leaving the entire OS exposed like this without the user doing something very stupid and intentional.

I don't by the 3rd party thing as an excuse... and I AM an Apple fanboi

Re:Errr...

[e4g4]

2 of these products are Core to the OS Well, not exactly. Since you didn't say which, I'm going to assume that you mean 2 of the following 3: Quicktime, Finder, and DiskManagement.framework. Quicktime is just an app with a set of codecs and some plugins (all removable). Finder is just an app, and while the method for doing so is not GUI accessible, you can in fact turn it off and use something else (i.e. the terminal, or PathFinder). DiskManagement.framework is just an API for easier/higher level access (higher than say mount or umount) to disk management functions like mounting/unmounting, and repairing permissions (where the MOAB bug lies), and frankly, repairing permissions on an OS X machine is simply an automated process for setting permissions on disk should they get out of whack (which pretty much only happens when you let the Quark 6.0 installer stomp all over your system, assigning permissions like a blind sysadmin with digital diarrhea (digital as in 5 digits to a hand)).

Now I'm not saying these aren't bad or problematic, just quibbling with your statement that these are Core to the OS.

Re:Errr...

[jellomizer]

Well I did mean Finder and Disk Manager. Finder is the general tool used to manage the UI. It may not be a kernel module or irreplacable. But to keep OS X OS X Finder is a Core Application. It runs after boot automaticly code is there to make it difficult to throw it away, It is core for a GUI OS. The DiskManager while not as nessary as Finder is still and important tool for maintaing the OS. As well used for basic OS Work such as burining ISOs, creating Disk Images. A lot of things that OS X wants you do. By Core I wan't nessarly talking about Kernel level programs or a program if it was taken away the world will end with now way back. But without Finder and DiskManager so much functionality of your mac is loss that replaceing it or just not using it is not much of an option.

Re:Errr...

[Anonymous Coward]

Grammar tip: "Effect" is a verb. "Affect" is a noun.

No, "effect" is a verb AND noun. As is "affect." Look 'em up.

In Communist Moab

[solevita]

MOAF moabs you.

Or something like that.

Instead ...

[Salvance]

Rather than just tell people not to use APE, Landon Fuller (who reported this bug on his blog), should have written an APE SHell Investigative Tool to help people find and fix this error.

Technology needs more catchy acronyms

MOAB

[dr_strang]

Does that make it the Mother Of All Bugs?

Re:MOAB

[spellraiser]

Yeah ... guess they'll have to write a bug-fix tool for the bug-fix tool now.

I might be missing something, but....

[8127972]

Why would anyone who is serious about computer security use a THIRD PARTY app to fix a security issue?

Re:I might be missing something, but....

[Anonymous Coward]

You wouldn't. These third-party fixes are being done as an intellectual exercise, not a serious offering.

Re:I might be missing something, but....

[Anonymous Coward]

"Why would anyone who is serious about computer security use a THIRD PARTY app to fix a security issue?"

Ask your government IT people who secures MS-Windows for them - it won't be Microsoft.

Sour grapes?

[Anonymous Coward]

From reading the article it looks like the people over at MOAB are rather pissed at Landon and this is just being spiteful.

slight correction

[Anonymous Coward]

'Application Enhancer (APE) is affected by a local privilege escalation vulnerability which allows local users to gain root privileges.'

should be...

'Application Enhancer (APE) is affected by a local privilege escalation vulnerability which allows local ADMINISTRATOR users to gain root privileges.'

Anatomy of the Runtime MoAB Patches

[shawnce]

From Anatomy of the Runtime MoAB Patches

------

01:04 Tue, 09 Jan 2007 PST -0800
Anatomy of the Runtime MoAB Patches

Introduction

For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.

Here goes ...

Third Party Patches, Past and Present

Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.

This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.

Risks and Benefits of Third Party Patches

A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.

On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.

Patching (more) Safely with Application Enhancer

The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.

Application Enhancer provides a nice, easy to use GUI for installing Applicati

Re:The problem isn't really 3rd party apps

[Drizzt Do'Urden]

So it's Linus' fault if Apache or Sendmail has a security problem?

The software has to be secure from top to bottom. If your PHP app has a security problem, it can do bad things on your machine no mather the OS.

Sticking up for APE

[usermilk]

The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins. So a local admin can replace the APE executable and gain root privileges. Read that again. A local admin can replace the APE binary to gain root access.

A local admin, an effective root user account, can gain root access.

Or they could open up NetInfo Manager and enable the root account and enter in a password of their own choosing and then log into the GUI as root. Or they could open up Terminal and run sudo sh and get a root shell.

This is simple revenge. Rosyna called them trolls and linked to an APE fix for one of their bugs. I think Rosyna may be right of the 9 published bugs, 4 of them are not from Apple provided software.

Re:Sticking up for APE

[ioErr]

The problem is not that a malicious admin can gain root access -- of course he can, as you pointed out. No surprise there.

The problem is rather that a trojan or similar run by a clueless admin can gain root access without the user being prompted for his password. Most Mac home users do use an admin account for day-to-day work, and think that they'll be fine. So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.

Personally I've solved this by using a normal user account that's added to sudoers. I can wreak full havoc on my machine when I want to, without having to log in as my admin account, but can't do so unknowingly (I hope).

Re:Sticking up for APE

[Rosyna]

The problem is rather that a trojan or similar run by a clueless admin can gain root access without the user being prompted for his password.

You do realize there are about 50 brazillion ways to do this, correct?

Either way, as soon as you're running malicious code, you're already screwed. A malicious application does not need to be root to destroy your photos, movies, pornography or other personal documents. You should never run applications from a source you do not trust.

Re:Sticking up for APE

[ioErr]

You do realize there are about 50 brazillion ways to do this, correct? Indeed, which is why the default configuration for Macs is so troublesome. We may mock Windows users for having to run as admins to get their poorly written software to work, but most Mac users run as admins out of ignorance, because that's just the way the default configuration is. Or was, the last time I installed OS X at least, but I hope I'd heard if things had changed.

Either way, as soon as you're running malicious code, you're already screwed. A malicious application does not need to be root to destroy your photos, movies, pornography or other personal documents. At least with a non-root the damage is localized to one account. Daddy's porn may be gone, but his daughter's homework (and porn) is still safe inside her account.

You should never run applications from a source you do not trust. I certainly agree. Too bad people are so trusting, though.

Re:Sticking up for APE

[pigwin32]

Most Mac home users do use an admin account for day-to-day work, and think that they'll be fine. So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.

This is absolute bollocks. Most Mac home users do *not* use an admin account for day-to-day work. They use the account that was configured when they first turned on their shiny new machine. That account is a normal user account that by virtue of belonging to the admin group has the ability to use sudo. This is exactly the mechanism you have used to solve this problem.

Re:Sticking up for APE

[abhi_beckert]

The "admin" group (even though it's not really admin, just a sudoer) has write access to /Library (/System/Library is owned by root, but /Library is available to admins unless manually changed).

The security hole is that APE installs software that's being run as root in a directory that non-root users have write access too. All you have to do is modify the executable so it installs insert-evil-kernel-extension-here before executing the normal code, and bob's your uncle.

One of my apps is a competitor to a major ape-using-app (no names needed since it's irrelevant), and mine also requires root access to do it's magic. However we've done it the proper way: only root has write access to the executable file, and it can't possibly execute unless you have proper auth services access (or are logged in as root/using sudo). Auth services (part of Keychain.app) will remember the user's password, but ask for it again with an easy to understand warning message if anything suspicious has happened (eg: md5 of the executable is different).

This is very basic stuff and is clearly documented. But far too many small developers don't give a shit about security.

Re:Sticking up for APE

[Anonymous Coward]

Where do you store the executable file? Most of the "standard" locations are writable by admin users.

Re:Sticking up for APE

[Anonymous Coward]

I agree. And there's nothing more malicious than APE. So by your reasoning, anyone already running APE is screwed. And that's true!

So your reasoning is correct!

Why do you continue to hype this dangerous product? Do you have to bring down the house of Apple first? Will even that be enough for you?

Why don't you go write widgets or something?

Apple Bug-Fix Tool?

[Aqua OS X]

An Apple Bug-Fix Tool? Err, um, no and no.

APE is developed by Unsanity and it's not a "bug fix tool."
It's a third party framework and daemon used for a number of thing.

Re:If you use APE you don't mind bugs

[dogfriend]

Yes, my initial thought on using APE was: Its very cool of them to patch the bugs, but I'm not going to install APE on my system. A couple of years ago I read some info on APE that outlined how it modifies the system and because of that it is a potential security risk.

Perhaps they should have waited

[Anonymous Coward]

From what we're starting to see now, January 31 is going to be a long way off. Perhaps they should have waited until February for their Month of Apple Bugs. Less space to fill.

Canary Trap

[Anonymous Coward]

Even more interesting LMH ran a canary trap and caught Jason Harris of Unsanity in it.

The canary trap the leak and the mole:

http://applefun.blogspot.com/2007/01/canary-trap-l eak-and-mole.html

This is also enlightening reading:

http://rixstep.com/1/1/20070109,02.shtml

I wouldn't have used APE before, but you'd have to be out of your tree to use it after this idiocy and shenanigans.

Re:Canary Trap

[tbo]

A selection of quotes from the "Apple Fun" blog:

Thus, if you are bitching on a blog or public forum, or publishing somewhere about our evil "root kit", it's because you are the recipient of stolen property.

OMG! Pwnies!

Not just it isn't a root-kit, but you've been pwned (or caught molesting) by one of the most old tricks ever. Yay!

It sounds like it's written by a mildly clever hacker who is way, way too in love with himself, and has the emotional maturity of a ten year old.

It's hard to cut through all the bragging to figure out what actually happened, but it sounds like LMH was able to determine that Jason Harris of Unsanity was using a script to try to get the next day's bug as early as possible. LMH infers from this that Harris is helping Landon Fuller do the Month of Apple Fixes. The whole thing strikes me as some sort of hacker-dick-measuring contest, rather than a real effort to find or clean up Apple bugs. If LMH was an ethical security researcher, he'd be disclosing the bugs to Apple a couple weeks in advance to give them time to release patches. AFAIK, Apple's got a decent record of responding to security bug tips. They even give credit in the release notes for their patches.

Summary to date...

[shawnce]

Note that this is third party software that all of the bugs seem to be stemming from.

This statement doesn't make sense. The MOAB issues outlined to date have been a combination of Apple and 3rd party issues. See the following break down...

MOAB #1 - Apple issue
MOAB #2 - 3rd party issue
MOAB #3 - Apple issue
MOAB #4 - Apple issue
MOAB #5 - Apple issue
MOAB #6 - Apple and 3rd party
MOAB #7 - 3rd party issue
MOAB #8 - Apple and 3rd party
MOAB #9 - Apple issue

Re:Summary to date...

[99BottlesOfBeerInMyF]

How is number 8 an Apple issue? It is an overflow in a third party application.

Re:Summary to date...

[shawnce]

Issue #8 is not an overflow issue (buffer overrun I assume you mean).

#8 involves APE (Unsanity folks could make some changes to help avoid the issue) however IMHO the core of the issue is with file permissions that Apple has defined for various directories under /Library that Apple recommends 3rd parties install software into. That is why I outlined that it is a 3rd party and Apple issue.

Re:Summary to date...

[99BottlesOfBeerInMyF]

IMHO the core of the issue is with file permissions that Apple has defined for various directories under /Library that Apple recommends 3rd parties install software into.

The security hole is in APE. The fact that you disagree with Apple's permission choices is pretty irrelevant. OS X does not stop Adobe Acrobat from being installed either, does that mean any hole in that reader is also partially Apple's fault?

Re:Summary to date...

[EvanED]

I don't have enough sysadmin experience to judge, but IF Apple chose poor* permissions, then it is partially their fault.

After all, there seem to be a lot of people on /. who have jumped on MS for not making people run as non-admin before Vista; and what's that besides just choosing a poor set of default permissions?

* You could define poor as "not as strict as reasonably possible"

Re:Summary to date...

[99BottlesOfBeerInMyF]

After all, there seem to be a lot of people on /. who have jumped on MS for not making people run as non-admin before Vista; and what's that besides just choosing a poor set of default permissions?

There is a difference between a design not being as secure as possible and a vulnerability. I blame Microsoft for both poor security design for the current climate, and for lots of bugs, but I don't confuse the two and claim that because a local program was compromised, that is a bug in MS's OS. MS should provide a way to safely run untrusted binaries (which is a commonly performed task), but that particular bug is not an MS bug.

In this same way, it would be great if Apple ran all applications in a sandbox. That doesn't mean a bug in a third party program on OS X is an Apple bug either.

Re:Summary to date...

[nathanh]

The security hole is in APE. The fact that you disagree with Apple's permission choices is pretty irrelevant.

It's not a disagreement. Apple's default permissions on that directory are plain wrong. APE is just an example application that proves the point. The actual fault lies with Apple.

I think the real problem here is that the MOAB deniers are woefully ignorant of the problems. They think they can make up for their woeful ignorance with chest-beating. I've been nothing but disgusted with the Mac community's treatment of the MOAB and their collective denial of the problems. I use a Mac. I think it's great. I also work in the security field and I have done so for the past 5 years. I've been aware for the past 2 years that OS X is a horrendously insecure OS. Fedora is much better. OpenBSD is much better. OS X is below par. The best OS X can claim is that it's better than Windows - BFD. If the Mac pundits just admitted the problem exists and took steps to secure their OS they'd get the two thumbs up. Instead they stick their heads in the sand and pretend that it's all somebody else's fault. They blame the MOAB guys, or they start from an ignorant understanding of the issues and claim that the faults aren't faults. Part of fixing the problem is admitting that the problem exists.

I'm extremely surprised that nobody has released a security manager or lockdown tool for OS X. I suppose because the Mac community is in a collective denial there is no demand for such an application.

Re:Summary to date...

[99BottlesOfBeerInMyF]

Apple's default permissions on that directory are plain wrong. APE is just an example application that proves the point.

This is just wrong. The framework file is installed by a third party application, which sets the permissions. Giving administrators the right to set permissions is a design choice, and arguably a bad one, but it is not a bug in and of itself.

I think the real problem here is that the MOAB deniers are woefully ignorant of the problems.

Deniers? What the project isn't happening? I'm pissed because the MOAB is being conducted in an unethical way that decreases the security of the general populace in order to benefit the people running it. Your claim that I am ignorant, is, in itself ignorant. Take a look at my posting history.

I think it's great. I also work in the security field and I have done so for the past 5 years. I've been aware for the past 2 years that OS X is a horrendously insecure OS.

Gee, what a coincidence. I too am a long time worker in the security industry. OS X is horrendously insecure, if compared to a locked down server or ultra secure workstation solution. Compared to the average Linux desktop, it is very similar. It has different problems, mostly from Apple's new features and integration with existing code bases, but it benefits from active, motivated updates, and some of the best handling of the HCI portion of the security problems.

It's a consumer workstation. As a consumer workstation, its security is "good enough" for the average user. Sure an expert directly attacking it can probably break in, just like the average linux desktop. But it is "good enough" because the current level of security does not cause any problems for the average user, who are rarely if ever compromised.

If the Mac pundits just admitted the problem exists and took steps to secure their OS they'd get the two thumbs up.

Please. Apple does a very good job of working with the security community and fixing issues. My coworker submitted a bug a short time ago, they fixed it in a little more than a week and gave him credit. They're also proactive doing security audits and introducing new features like workable encryption for user accounts, mandatory access controls, dtrace, and application signing. They fix any real bug that is reported to them.

They blame the MOAB guys, or they start from an ignorant understanding of the issues and claim that the faults aren't faults.

I blame the MOAB guys because their disclosure is about as irresponsible as you can get. Intentionally providing a vendor who acts in good faith with no advance notice and intentionally spacing public disclosure to make development/qa cycles have the longest possible time between disclosure and patch. Imagine you're working on a product and security researchers announce one bug they already know about every few days. You can start a cycle and it won't get the next several bugs or you can wait a whole month. Either way your users are swinging in the wind. It's like they're intentionally trying to open big enough window for a worm to work. If you really are a person in the "security field" then you must be pretty clueless.

Part of fixing the problem is admitting that the problem exists.

Apple admits to and thanks those who submit bugs to them. I've never heard of them trying to cover one up. Who are they trying to convince to fix things?

I'm extremely surprised that nobody has released a security manager or lockdown tool for OS X.

Have you ever looked?

Sorry, but I wouldn't trust a security person with your attitude or ignorance anywhere near my boxes. Good luck with your career.

Re:Summary to date...

[nathanh]

Take a look at my posting history.

I have. And my estimation of your worth has diminished considerably.

I blame the MOAB guys because their disclosure is about as irresponsible as you can get. Intentionally providing a vendor who acts in good faith with no advance notice

Your factiness is compelling. Unfortunately the facts disagree with you. Despite your claim that these guys aren't notifying Apple of these bugs in advance, they claim that they have, and I find them a whole lot more convincing than you.

"Don't attempt to mount untrusted DMG files, disable Safari 'Open safe files' in it's preferences dialog, wait for Apple to release a fix (this issue has been reported to them circa a month ago)." -- http://projects.info-pull.com/moab/MOAB-09-01-2007 .html

And from another of the MOAB bugs.

"Don't attempt to mount untrusted DMG files, disable Safari 'Open safe files' in it's preferences dialog, wait for Apple to release a fix (this issue was confirmed to them via e-mail after public availability of the MoKB FreeBSD issues, > month ago)." -- http://projects.info-pull.com/moab/MOAB-10-01-2007 .html

Some of the other bugs stem from problems that were reported to Apple over 2 years ago. For example, why is Safari still shipping with "Open Safe Files" enabled by default? There have been continuous reports of exploits due to that default option. Apple refuses to use the sensible default of disabled. Here's another of your bogus claims.

The framework file is installed by a third party application, which sets the permissions.

Absolutely false. The permissions on /Library/Frameworks are broken out of the box before APE is even installed. The MOAB guys have this to say:

"The approach for fixing the MoAB issues is actually making Apple boost it's vulnerability handling process, and not leveraging the work to a jackass third-party which has no security background at all... -- http://projects.info-pull.com/moab/MOAB-08-01-2007 .html

Those guys are right on the money yet again. Creating a secure OS is not about setting the permissions roughly correct - and even that is a relatively recent concept for Apple - and then trusting every third party to do the right thing. It's about making it difficult or impossible for a third party to make a mistake. It's impossible for every third party to be an expert; Apple is supposed to create frameworks and tools to do that work. Allowing third parties to install setuid binaries in /Library/Frameworks is the perfect example of Apple dropping the ball; the installer should have simply denied the action. And this whole problem could even be avoided if the default account wasn't in the admin group because that's yet another fault that was reported to Apple several years ago, still without resolution.

Here's another of your bogus claims. Fedora took a bold step back in Fedora Core 2 when they introduced MAC. You claim that Apple will one day perhaps do something similar:

They're also proactive doing security audits and introducing new features like workable encryption for user accounts, mandatory access controls

But why has Apple silently dropped MAC from their list of supported features in the upcoming Leopard? Hopefully the feature will still be there when Leopard does finally hit the streets - the removal from the website might just be because most Mac users don't know what it mean

Re:Summary to date...

[99BottlesOfBeerInMyF]

I'm not going to address your points one by one, because I don't have the time and they don't deserve it. Some of the items you reply to were not even in my post. But I thought I'd address your conclusions.

Apple? I see complacency and rhetoric and outright deception . Then I see ignorant - yes, I think you are ignorant - pundits such as yourself who would attack the messenger rather than admit there's a problem.

Ahh, a problem eh? How many Macs have been compromised this year by worms? Oh yeah that would be zero. Well how many were compromised by viruses, umm zero. How many were know to be compromised by directed attacks from hackers? A handful. This is the problem? Mac security is just fine for a consumer desktop system where security is a lower priority than other parts of the OS, because they align with the priorities of the people using them. Sure I could switch my laptop to OpenBSD or SELinux. Of course it would take me twice as long to get my work done and every day would be an exercise in pain.

When macs are compromised in an automated fashion, regularly, the platform will have a problem. Ideally Apple will be proactive and introduce features to keep it from ever getting to that state, which they have so far. You complain that they haven't introduced MAC and it is not on the feature list. Sure it would be nice, but it sure as hell isn't needed to deal with the large number of trojans I have to deal with every day, which is to say none. There is no such thing as a "secure OS" only OS's that have low enough risk of compromise for some use. If that risk is not low enough for your use, use something else that is appropriate. Don't try to blow trivial vulnerabilities out of proportion in order to scare the general public into incorrectly believing their risk on OS X is high. Don't implement a project that is irresponsible by all security industry standards and which maximizes the risk to users in the hopes that can manufacture a problem that does not currently exist. You claim I'm attacking the messenger, but this particular messenger was trampling on people in order to try to gain publicity. They can rot and you need to take a course on ethics.

Re:Summary to date...

[nathanh]

Some of the items you reply to were not even in my post.

What a load of crap. I cut and pasted your comments directly from the Slashdot reply window. You are a liar.

Re:Summary to date...

[nathanh]

Ahh, a problem eh? How many Macs have been compromised this year by worms? Oh yeah that would be zero.

Lie #1.

Well how many were compromised by viruses, umm zero.

Lie #2.

Sure I could switch my laptop to OpenBSD or SELinux.

Do you even know what SELinux is? It's not a distribution like OpenBSD. You can't switch your laptop to SELinux.

When macs are compromised in an automated fashion, regularly, the platform will have a problem. Ideally Apple will be proactive and introduce features to keep it from ever getting to that state, which they have so far.

Lie #3. I even quoted the MOAB guys who said Apple was given one month's notice on several bugs. Apple is not being proactive.

You complain that they haven't introduced MAC and it is not on the feature list.

No, you claimed Apple had proactively introduced mandatory access controls and I refuted your bogus claim. Lie #4.

Don't implement a project that is irresponsible by all security industry standards and which maximizes the risk to users in the hopes that can manufacture a problem that does not currently exist.

Lie #5. Fulll public disclosure is not "irresponsible by all security industry standards". No security expert would ever make that claim. Take for example one of the MOAB bugs that was already in the wild. Actual boxes had been exploited by this hole well before MOAB announced it. The MOAB guys gave details that the average home user could follow to workaround the problem until Apple does fix the fault.

You claim I'm attacking the messenger, but this particular messenger was trampling on people in order to try to gain publicity. They can rot and you need to take a course on ethics.

The day I take ethics advice from a liar is the day hell freezes over.

Re:Summary to date...

[99BottlesOfBeerInMyF]

I even quoted the MOAB guys who said Apple was given one month's notice on several bugs. Apple is not being proactive.

Hmm, Apple hasn't commented and I certainly don't trust the MOAB guys. Who do I trust? I trust the CEO of OmniGroup who mentions in an interview on Arstechnica today that he was given zero notice and found out about the bug in OmniWeb when a friend e-mailed him after seeing the MOAB release.

No, you claimed Apple had proactively introduced mandatory access controls and I refuted your bogus claim.

No, I said they were being proactive by developing it. They obviously have not yet released such a feature, although they did mention it in some developer notes. Do you know what proactive means? It means working on solutions to problems you don't have yet. Apple does not yet have a problem with trojans or malware in general, but they are working on a solution.

Fulll public disclosure is not "irresponsible by all security industry standards".

I never said it was. Learn to read jackass. I said what MOAB is doing, which is intentionally hoarding bugs and not disclosing them to vendors or the public until a time frame that makes quickly patching them difficult, is irresponsible. Are you arguing it isn't?

The day I take ethics advice from a liar is the day hell freezes over.

I suspect that will be about two years before you learn to read properly.

InputManagers in general

[Lord Grey]

For those of you who don't know about APE: There exists in the OS X framework this concept of enabling alternate input mechanisms for already-installed applications. The mechanism is the InputManager. A properly-constructed bundle is simply copied to a designated location and the OS will happily load it whenever an application is launched. The bundle is loaded as part of the application, and the bundle has access to the application's internals. Some good information on InputManagers can be found on CocoaDev.

The "designated location" is actually one of several: /Library/InputManagers/ or ~/Library/InputManagers/. In other words, it doesn't take special privileges to make an InputManager bundle active on a given system for a specific user. You do have to have admin privileges to place the bundle into /Library/InputManagers/ so that all applications executed by all users are touched, but that's it.

Objective-C lets objects of one class "pose" as objects from another class. Posing is like dynamic subclassing; method dispatch happens against your class first and then on up to the original class if you didn't implement it or if your method specifically calls the "parent." This is where code injection comes in. You write a new class that poses as some class in the application and intercept the calls; your code starts executing.

Figuring out the application's classes isn't difficult. A free utility like class-dump can be used to grab an OS X application's class and data structure definitions, and from there it's easy write your own posing classes. Lots of bugs arising from injected code is due to sloppiness on the part of the programmer, and some of it is due to an InputManager modifying an application's data at the wrong time (which is easy to do, because the application rightfully believes that it owns its data).

I was going to write something about the security issues this entire scheme raises, spelling out how a nefarious programmer could hijack passwords and the like. I'll leave that to your imagination, though.

Shameless plug: While I didn't use APE, I did use InputManager technology in order to create Concierge (a bookmark manager for Safari, in the form of a drawer).

Re:InputManagers in general

[TheUser0x58]

Not quite... InputManager only works with Cocoa applications, as the CocoaDev page you cited mentions, and class posing will only work with parts of applications written using Objective-C classes.

APE uses mach_inject and mach_override to actually patch new code into applications loaded into memory. This works at the kernel level and thus is framework and language agnostic.

Re:InputManagers in general

[Rosyna]

APE uses mach_inject and mach_override to actually patch new code into applications loaded into memory. This works at the kernel level and thus is framework and language agnostic.

APE uses no part of mach_star. None of these work at the kernel level either. They're all user space.

Bugs in apples..

[FrostyCoolSlug]

When I find a bug in my apple, I throw it away..

Re:Bugs in apples..

[Thumper_SVX]

When I find half a bug in my apple, I usually feel a little nauseous.

What you are missing is called CLUE

[slyborg]

The vast majority of the virus scanning/blocking software is THIRD PARTY, as is much of the spyware detection software. For your reference:

http://www.symantec.com/
http://www.mcafee.com/

We need more acronymns

[cascadingstylesheet]

I suggest for the next few thing on this topic:

MOSES

BALAAM ;)

Re:MOAB = Massive Ordnance Air Blast Bomb

[Protonk]

This isn't necessarily off-topic, although it would benefit from an explanation that the new acronym used in the article and the story may be confused by those in the weapons industry for something else....for about 5 seconds.

Wow!

[Cervantes]

" I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards."

So, when Apple does it, it's OK, but when Microsoft does it, they've obviously made a flawed system and deserve to be beaten about the head with an office chair?

I know this is /. , but I have a relatively high user ID, so I just want to be sure I understand the logic...

Re:Wow!

[Divebus]

So, when Apple does it, it's OK, but when Microsoft does it, they've obviously made a flawed system and deserve to be beaten about the head with an office chair?

No, it's not OK when Apple does it, if they actually did it. When Microsoft does it for the 140,000th time, they should get beaten up. It would take decades to talk about all the Microsoft bugs.

Re:Wow!

[argent]

No, this one Apple needs to be nailed to the wall on. Leaving parts of the system writable as admin means that you're a quick framework patch away from being root... which means being in admin is almost as dangerous as being in the Local Administrators group on Windows. Not that that stops anyone from running as Local Administrator on Windows.

http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398

Not to mention Adobe and everyone else who shows up when you run that find command.

Misleading Title - APE is not a bug fixing tool

[hobbestcat]

APE is not a bug fixing tool. APE is a hack to the core of the OS. APE lets you run other hacks to reroute your audio, change the action of menu buttons and things like that.

I thought that the MOAB was going to look at Apple Software not software for Apple computers.

Moo

[Chacham]

MOAB came first and MOAF was a developer's answer to the bugs

What about MOOF???

Hah, security.

[Khyber]

"I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards." That's about right. *stares long and hard at Javascript and Flash*

APE has a bug??? I'M SHOCKED!!! SIMPLY SHOCKED!!!

[Anonymous Coward]

I'm surprised APE doesn't spontaneously mutate into a backdoor shell on port 6666 SIMPLY THROUGH A COINCIDENCE OF CODING ERRORS.

Seriously, if you're using APE, get it off your Mac NOW.

Re:The problem isn't really 3rd party apps

[spun]

It is one of the major jobs of an OS to keep one out-of-control app from hosing your entire machine, whether that app is out of control due to hacking, user error, or other bugs. If your PHP app has a problem on a good OS, the attacker may be able to change files owned by the apache user, while on a bad OS they might undetectably rootkit your machine.

In the words of Walter Sobchak:

[Night Goat]

"Fuck it dude, let's go bowling."

Reading that summary as a Mac user, I just can't be bothered to sort all of this out.

Re:The problem isn't really 3rd party apps

[Cervantes]

"So it's Linus' fault if Apache or Sendmail has a security problem?"

Why not? It's Bills fault whenever a bug on WinTel platforms is found.

It's not an APE bug, it's a big Apple bug.

[argent]

The bug is that /Library/Frameworks is group-writable by users in the admin group.

ANY application run setuid, or any framework or plugin used by any application run setuid, could have been used to demo it. It's got nothing to do with APE. This is no different from the many privilege escalation issues in Windows caused by writable executables and system directories.

To tell if your Mac is susceptible to this kind of privilege escalation attack, run this command:

find /Library /System /Applications -perm -022

If there are no results, then your system is probably safe. If there are more than a few results, then you're likely vulnerable.

Try it and see.

Re:It's not an APE bug, it's a big Apple bug.

[dedazo]

Hookay, I can see this in my MacBook. How do you fix it manually? By resetting the permissions? Won't that break something else?

Re:It's not an APE bug, it's a big Apple bug.

[adrenalinerush]

Maybe I'm just a security-clueless Mac FanBoy (TM), but you're basically telling me that a local admin user can change something in the system to give themselves root privileges?

How is this really any different from simply being an admin? AFAIK, they're basically the same thing on an OSX box.

Please, enlighten me if I'm wrong here.

Re:No Wonder Jobs Didn't Talk About OS X Yesterday

[Divebus]

Even funnier, Microsoft talks about how secure everything is in Windows. Marketing Machine in Motion. They never seem to talk about tens of thousands of flaws actually exploited in Windows. After 6 years of OS X and 6 years of XP, I'd say the percentages are dramatically in Mac OS X's favor.

It's not an APE bug.

[argent]

http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398

Re:Misleading Title - The bug is not in APE.

[argent]

http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398

Placing the blame in the right place... with Apple

[argent]

The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins.

Too many words. Let me fix that for you: The vulnerability is that /Library is writable by local admins.

Even if you don't install APE on your system, an attacker who has the ability to execute this exploit can simply drop an input manager or other plugin into /Library and piggyback their way to root on any privileged application.

That should be a surprise...

[argent]

The problem is not that a malicious admin can gain root access -- of course he can, as you pointed out. No surprise there.

A malicious application running as an "admin" should not be able to gain root access.

No wonder Apple didn't care that aliases bypass traverse checking. That's a *minor* problem by comparison.

So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.

The real problem is that admin users have too broad write permissions.

Re:No Wonder Jobs Didn't Talk About OS X Yesterday

[Anonymous Coward]

Tens of thousands? Hyperbole much?

Good point...

[argent]

Either way, as soon as you're running malicious code, you're already screwed.

Not to minimize the problem (and it IS a real problem) but this is important.

Security is like sex. Once you're penetrated you're fucked.

You should never run applications from a source you do not trust.

Don't forget to turn off "Open 'Safe' Files After Downloading" in Safari.

Re:The problem isn't really 3rd party apps

[Drizzt Do'Urden]

I don't agree to that neither.

It's Bill's fault if Internet Explorer automatically installs a spyware, but not if John Doe's software let's viruses through.

Remind's me of old times, when it was Win95 vs MacOS 7. A PC crashed, it was the application's fault. A Mac crashed, the Mac was the problem. It's still a lot like this these times...

Anyone got a scratch monkey?

[argent]

I don't know whether resetting those permissions will break anything or not.

I don't have a scratch Mac to test it on, anyone?

More fun...

[argent]

You may not even need to be admin.

Try "find /Library /System /Applications -perm -02". Any files or directories that show up there are world writable.

Re:The problem isn't really 3rd party apps

[Drizzt Do'Urden]

True, but the responsability still lies in the PHP app.

Not only it can change apps, but it execute commands with it's priviledges too. (like download a mass mailer and start sending junk mail).

Re:The problem isn't really 3rd party apps

[spun]

Well, privilege defines the difference: if an unprivileged app can be hacked in such a way as to escalate privileges, that is the fault of the OS, no matter what the app did wrong. If it can be hacked only so that a remote user can execute arbitrary commands with the privilege of the process they hacked, that is the fault of the app.

Third party software?

[skinfitz]

Note that this is third party software that all of the bugs seem to be stemming from. I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards."

Quicktime, Finder and iPhoto are third party now?

I guess the kernel is also third party by zealot logic then - or at least it will be after they start publishing the kernel level exploits. Kind of like what happens after a proof of concept virus gets announced for OSX - the zealots simply redefine what 'virus' means.

Better start looking for spyware in /Library

[argent]

While you're looking at APE, have a look in /Library... maybe you'll be the first to find some spyware hiding in there thanks to all the world-writable files and directories... ... because that's the real problem. They didn't need APE, they could have used their own Input Manager instead. They just picked APE to thumb their nose at Landon Fuller.

Windows comes with his bug pre-exploited.

[argent]

Hell, Windows depends on this bug. The bug is... Apple left parts of /Library writable. Microsoft requires that every user have write access to parts of the system file tree to handle things like printing and web-page caching. Instead of fixing that, they've added a subsystem to monitor it and undo changes to system files... and of course there are viruses that use that subsystem to hide in so they get put back after they're removed by AV tools.

But more importantly, in Windows everyone runs as a member of Local Administrators anyway... and you don't need an exploit to become "root" from there, you *are* root.

Re:No Wonder Jobs Didn't Talk About OS X Yesterday

[mstone]

Vocabulary issue, I think.

You're interpreting 'holes' to mean specific vulnerabilities, where the GP would have reasonable grounds for claiming a 'hole' is any vector for exploitation.

Due to the deeply and intricately connected nature of Windows, there are legitimate arguments either way. A buffer-overrun in, say, the PNG codec is a single vulnerability, but there are lots of different attack vectors. One vector would be the web browser. Another would be the email client. A third would be any file that reaches the computer by removable media.

To the average user, different paths of exploitation most likely equal different 'holes'.

Reminds me of a Red Hat bug awhile back.

[that this is not und]

I believe it was on Red Hat 5.0 that the 'graphical RPM installer' (was it called 'glint'??) had a bug in it. You couldn't use the graphical installer to install the fixed version. Whoops. _Everybody_ needed to know how to manually install an RPM-encumbered upgrade.

Real Professional Language there...

[DJ_Adequate]

"The approach for fixing the MoAB issues is actually making Apple boost it's vulnerability handling process, and not leveraging the work to a jackass third-party which has no security background at all... -- http://projects.info-pull.com/moab/MOAB-08-01-2007 .html [info-pull.com]" Gosh, yeah, that sounds real "professional' there. And despite all this, there has not been a real security breach on OSX. I agree with some people here that the MOAB people seem to want to create on, so that they can be proven right.

this makes no sense

[v1]

This is like building a list of windows bugs and submitting a norton product as an exhibit. If this is the week of APPLE bugs, why are we hearing about macintosh software developers? Must be slim pickins in Mac OS X for security holes?? I thought they were going to post some real apple bugs? This is very disappointing, though I suppose it's nice to see they are having this problem.

New Marketing Slogan for Apple

[DJ_Adequate]

MacOSX, almost as dangerous as Windows*. *In theory, actual results may vary. Offer not available in RI, WI. See you dealer for details.

Re:If you use APE you don't mind bugs

[dogfriend]

Wow, I got modded as a troll. I didn't mean it as a troll, I just don't want to install APE. I am glad that Landon Fuller and others are doing the patches.

Just say no to APE

[Anonymous Coward]

At one point 95% of all the crashlog submissions to Apple stemmed from APE. At that time Apple, upon receiving the crashlog, immediately searched for APE. If found, they discarded the log. And it's not because they're lazy. Because of the way APE operates, it1 can do very unexpected things that application developers aren't expecting, which can easily (very easily) cause applications to crash. There's nothing Apple can do about this - it's entirely APE getting in the way of what an Application expects to be norm and screwing with things.

I don't know if Apple's still receiving that high of a percentage of APE crashlogs, but I'm sure enough people are foolish enough to use that thing to make it fairly high. Eye Candy and Stupid GUI Tricks aren't "cool" enough to make up for all the lost time & work.

As for anyone releasing patches using APE, I don't know exactly what to say - install a framework that causes applications to crash, in order to fix a security hole that may or may not be a real-world problem? For christs sake, there's got to be a better way. Hell, third parties released updated Windows files for both VML & WMF vulnerabilities without any help from Microsoft, shouldn't someone be able to do something similar for OS X?

In short, screw haxies. The two OS X systems I interact with on a daily basis have been almost rock solid ever since I dumped APE oh-so-many years ago. I'm not going to open that can of worms and unleash the forces of bug hell on myself all over again.

Poster is an idiot

[Anonymous Coward]

Did he not even look at the list of errors? The majority exist as first party issues.

Canary Trap

[Anonymous Coward]

It was a canary trap.

Re:Placing the blame in the right place... with Ap

[Serious Callers Only]

The library folder has to be accessible to applications (and thus the current user) without authentication, because of the Application Support and Preferences directories, which they write to all the time.

Folders like Input Managers, Internet Plug-Ins, Widgets, and perhaps LaunchAgents need to have limited access though - that definitely needs to change, and I'd advise anyone who hasn't to change the permissions on those folders so that they require authentication for changes. Otherwise applications could silently install things in there without you knowing (some already do when they install things like 'Smart' Crash Reporter without asking for permission).

I stand corrected

[Lord Grey]

You are quite right about APE's implementation. I plead guilty to thinking I knew more about APE's internal structure than I actually do. I have to say, though, that using mach_inject and mach_override to patch code is somewhat scarier than using Objective-C's dynamic dispatching when you take into consideration that APE supports a plug-in methodology.

Thanks for the clarification!

Starting to get annoyed

[Steve Cowan]

Every few weeks another exaggerated headline of another Apple security "hole" is posted. In every case, closer examination reveals that the hole really isn't a hole at all, and it requires physical access to the machine, etc.

From TFA:

"The vulnerability is real--it is possible for a local administrator account on the computer to gain root access, without any user confirmation, by replacing pieces of Application Enhancer's installation," said Fuller in his blog. "While this cannot be exploited remotely, it could be used in combination with a remote exploit to acquire escalated privileges. However, a remote exploit alone is sufficient to allow an attacker full access to your important personal data."

No remote exploit. Nothing to see here. This only affects machines with the third-party "Application Enhancer" (APE), which I have always been reluctant to install (and I now know why)

I hope you're mixing up your directories.

[argent]

The library folder has to be accessible to applications (and thus the current user) without authentication, because of the Application Support and Preferences directories, which they write to all the time.

They should not be writing to /Library.

They should be writing to ~/Library (that is, the Library subdirectory in your home directory)

Any application that attempts to write directly to /Library without sudo-ing first is broken.

Re:I hope you're mixing up your directories.

[Serious Callers Only]

Yes I meant ~/Library by Library, not /Library : ~/Library is the one which has these very liberal permissions. Should have said 'User Library' instead to be clear.

It's not just "admin", and that shouldn't be root.

[argent]

you're basically telling me that a local admin user can change something in the system to give themselves root privileges?

It's worse, any user on an OSX box can probably give themselves root privileges with a little patience. The default permissions on /Library give any local user write access to an awful lot of files. All you have to do is drop a plugin somewhere under /Library and wait for a priviliged program to launch and execute it.

How is this really any different from simply being an admin? AFAIK, they're basically the same thing on an OSX box.

An admin user theoretically can only perform administrative duties by going through the security dialog that lets him run a program as root. Clearly this is not the case, but it should be.

The description of the flaw is misleading.

[argent]

This is like building a list of windows bugs and submitting a norton product as an exhibit.

This is not a flaw in APE. Any existing plugin or a new plugin could have equally well been used. The flaw is that /Library is writable... and in investigating I've found that even after "fixing permissions" there's an awful lot of /Library that's not just writable by administrators... but by anyone.

No, it's APPLE'S permissions that are wrong.

[argent]

This is just wrong. The framework file is installed by a third party application, which sets the permissions.

% ls -ld /Library
drwxrwxr-x 56 root admin 1904 Dec 27 16:07 /Library
% open -s "Disk Utility"
(pause for repair disk permissions)
% ls -ld /Library
drwxrwxr-t 56 root admin 1904 Dec 27 16:07 /Library
% ls -l /Library
[...]
drwxrwxr-x 4 root admin 136 Sep 12 12:09 InputManagers
drwxrwxr-x 19 root admin 646 Dec 15 12:16 Internet Plug-Ins
[...]
drwxrwxr-x 11 root admin 374 Dec 28 18:45 PreferencePanes
[...]
%

Any of these locations can be used to insert trojan horses.

In the course of running repair permissions, I noticed a number of disturbing lines like "Permissions differ on ./Library/Internet Plug-Ins/Flash Player.plugin/Contents/Resources/Flash Player.rsrc, should be -rw-rw-r-- , they are -rw-r--r--" where "Repair Permissions" actually decreased the security level of the application.

Apple needs to fix this. They should of course make sure there's nothing in the basic system that requires write permission there (there shouldn't be), then "Repair Permissions" should be updated to revoke non-root write for any file under /Applications, /Library, /System, /Local, or the BSD system directories like /usr, unless they are on an explicit exception list. If any application is broken by this, it's on the vendor to fix it.

As a consumer workstation, its security is "good enough" for the average user.

I used to think so, but after their stupid response to the Safari/Helpviewer hole and the subsequent holes (all of which could have been fixed for good in June 2004), and now this... I'm not so sure.

Compared to Windows, it's good. It may be comparable to Red Hat, I don't know... but Red Hat's local security isn't "good enough" either.

Apple admits to and thanks those who submit bugs to them. I've never heard of them trying to cover one up.

They don't cover them up, they just ignore them. I sent them a report on the way aliases bypass traverse checking and can be used to 'tunnel' through top level directory permissions between accounts, and I've had no response. They still haven't changed the default "Open 'Safe' Files After Downloading" behaviour in Safari, or fixed the LaunchManager design flaws. Their response is like Microsoft's... they will apply a patch to fix a specific instance of a bug, but they don't touch the root cause.

Re:No, it's APPLE'S permissions that are wrong.

[99BottlesOfBeerInMyF]

Compared to Windows, it's good. It may be comparable to Red Hat, I don't know... but Red Hat's local security isn't "good enough" either.

Good enough for what? What is the purpose of having security measures at all? The purpose is to stop people from hacking your machine and if people aren't successfully hacking your machine, they're good enough. Security can always be stronger, it just takes more work which costs money and time. I'd like to see Apple hit about 5 key technologies and integrate them and I'd like to see a more active internal security auditing crew. I'd like to see Apple post a bounty on bugs depending upon severity, with a public Website that announces the bug immediately, although perhaps not details. That said, I don't think most Apple customers have any problem today, and so Apple doing any of the above is strategic. They need to balance that with other development to give customers in general what they want.

They don't cover them up, they just ignore them.

For the most part, this doesn't seem to be true in my experience. All the bugs we've sent them have been acknowledged and fixed in a timely manner.

I sent them a report on the way aliases bypass traverse checking and can be used to 'tunnel' through top level directory permissions between accounts, and I've had no response.

That is one thing I'll fault them for, they're slow to answer. Still a local escalation between accounts, using aliases sounds pretty minor. It could be a pain in an education setting. How long has it been?

They still haven't changed the default "Open 'Safe' Files After Downloading" behaviour in Safari

This is a design choice. They favor ease of use over security in this instance. It is a hole and I certainly change it on all my machines, but thinking of it from a business perspective, I understand their choice. They have to balance making an OS people want with one that is secure and sometimes the tradeoffs are in favor of less security. If it ever begins to be widely exploited, I'm sure they'll change it.

Re:No, it's APPLE'S permissions that are wrong.

[argent]

The "ease of use versus security" dichotomy is a false dichotomy more often than not. You make a system more secure by designing it with security in mind, not by spending more money and time after the fact to "add security". If you're faced with chooseing "ease of use over security" (or vice versa) that probably means that you've made a design error somewhere, and fixing that as soon as practical is almost always going to be cheaper, more secure, and more convenient.

This is a design choice. They favor ease of use over security in this instance.

They think they're doing that. You apparently think they're doing that. The problem is, what they're doing was never any easier than following a more secure policy, and after the first few exploits it's resulted in an overall reduction of the ease of use of OS X, without any actual increase in security.

Instead of extending the sandbox to include those applications that themselves sandbox the documents they display (safe applications), they have added a bunch of extra dialogs into LaunchServices just in case Safari (or some other Webkit-based application displaying an untrusted document) calls LaunchServices.

The result of this decision is:

* Applications that use LaunchServices to run their own helper applications present the user with an unnecessary dialog the first time they're run. This is not only irritating, but it teaches the users that this dialog sometimes comes up for no obvious reason.

* Applications that run full-screen, for example Screen Effects (screen savers) and iTunes Visualisers can not use LaunchServices to run their own helper applications, because the first time they run it... the dialog will come up, but since they're obscuring the desktop the effect will be a lockup.

* The actual exploit that led to this change would not have been prevented by it, because the Help Viewer would still have been launched without a dialog... because it's a built-in application.

The alternative? Only open files in "safe" applications after downloading. Don't depend on LaunchServices having the expected bindings for desktop helper applications (that's already been a problem with BOMArchiver vs Stuffit Expander), give Webkit its own bindings database (either a parallel to LaunchServices or an alternate interface to LaunchServices). This has a number of advantages:

* You can put safer applications in this database. On Windows, since I was using Netscape/Mozilla browsers rather than IE, I could set the application for opening documents from email or the web to WordViewer instead of Word. Similar previewer tools (simpler, with no need for dangerous functionality, and this easier to make secure) can be used to protect general desktop applications from untrusted documents.

* LaunchServices can be returned to a "desktop" mode, where it's no more paranoid than Finder, because it's only used like Finder. This makes the system as a whole more convenient.

More convenient AND more secure. Why do anything else? Microsoft has already AMPLY proven that the path of asking the user "I'm about to do something that might be really stupid, should I?" doesn't work.

Re:No, it's APPLE'S permissions that are wrong.

[99BottlesOfBeerInMyF]

The "ease of use versus security" dichotomy is a false dichotomy more often than not.

I agree most of the time, and in the general case, but not necessarily for any given instance.

The problem is, what they're doing was never any easier than following a more secure policy, and after the first few exploits it's resulted in an overall reduction of the ease of use of OS X, without any actual increase in security.

If a person clicks on say, a PDF file. If they have auto-opening of PDF files disabled they then have to double click on the item in the downloads window. This is an extra step which Windows users are not accustomed to. As such, many of them find it harder, and some are confused as to why they aren't looking at a PDF instead of a list of downloads. Some might even assume Macs can't read PDFs. So in this particular instance, I think auto-opening them is easier. You say after the first few exploits, but those exploits are so rare and uncommon practically no one has ever seen them outside of a lab. If this becomes a common vector for exploits in the wild they will have to disable it by default or find a better way to work around it.

Instead of extending the sandbox to include those applications that themselves sandbox the documents they display (safe applications), they have added a bunch of extra dialogs into LaunchServices just in case Safari (or some other Webkit-based application displaying an untrusted document) calls LaunchServices.

Ideally, Apple will implement mandatory access controls and it won't matter if they auto open files in some program because that program won't be able to do anything anyway. That, however, is a lot more work than deciding the correct default setting in Safari.

More convenient AND more secure. Why do anything else? Microsoft has already AMPLY proven that the path of asking the user "I'm about to do something that might be really stupid, should I?" doesn't work.

I think your solution is a band-aid. (To be fair, so is Apple's current solution.) It does not address other downloads from other, non-Web-kit applications like mail. It is also missing graduated levels of trust. You ask users or the OS provider to decide if applications are safe or not safe. That is not sufficient granularity. If I have a PDF file, is it safe for Preview to open it? What if there is a buffer overflow in Preview and it takes over the process? Can it then start a mail server and send spam? I don't want Preview to ever send mail, and the OS should restrict it from so doing. The way to do this is with mandatory access controls and a system to determine the trust level of a given application. Apple is working on both.

Microsoft has implemented half of such a solution, in a broken way, without fixing a number of other problems that contribute to the issue and while completely ignoring the human part of the security equation. That does not mean such a system can't be done correctly.

Re:No, it's APPLE'S permissions that are wrong.

[argent]

If a person clicks on say, a PDF file. If they have auto-opening of PDF files disabled they then have to double click on the item in the downloads window.

You're mixing up two different things here. I'm not saying "don't provide helper applications and plugins", I'm saying "Don't use general purpose desktop applications to open untrusted files". The whole reason that everyone except Microsoft uses exclusively sandboxed interpreters in web browsers is because web browsers are applications designed for handling untrusted files. There can be (in fact there are) other applications with similar restrictions. These applications would be the ones that the browser and other "sandbox" applications would use.

It does not address other downloads from other, non-Web-kit applications like mail.

The distinction is not really "webkit" versus "not-webkit". It's "sandboxed" versus "non-sandboxed". There are webkit-based applications that aren't sandboxed, like Dashboard, and there are non-webkit-based applications that should be considered part of the sandbox, like mail and other web browsers. ANY application that is designed for handling untrusted files would use the "WebServices" API rather than the "LaunchServices" API.

The intent here is to creat an inherently safe design. An inherently safe design isn't perfectly safe... any program can have bugs... but the design is such that if there is a security flaw it can be fixed without breaking anything else. You don't have to change the behaviour of the program later on because there's a buffer overflow, you can fix the buffer overflow.

Apple's model is inherently unsafe: it deliberately exposes applications that are not (and can not be) sandboxed to untrusted content. To fix a security hole that results from this decision means either changing the behaviour of the unsandboxed application (which makes the system less convenient), changing the applications that the sandboxed viewer is allowed to use (which makes the system less convenient), trying to guess whether the action should be allowed or not (which leads to Microsoft's endless redefinition of what the 'trusted zone' is), or asking the user (which makes the system less convenient). AND you still have to deal with bugs in applications as well.

What if there is a buffer overflow in Preview and it takes over the process?

That's a bug in Preview, and it can be fixed in an update. Fixing buffer overflows doesn't break anything, so they can be fixed without having companies holding off security fixes because they're afraid it'll break software they depend on (as happens routinely with Windows).

Just because a system is inherently secure doesn't mean it's perfectly secure. An inherently secure system can have all the same coding flaws of an inherently insecure one... but the insecure one has an entire mechanism for exploits to use that the secure one avoids, and it's a mechanism that's harder to fix because it's pretty much impossible to guarantee you can allow applications that NEED to use the exploited interface legitimately working while preventing insecure ones from using it as an exploit.

You end up walking a tightrope, and it's one that you don't need to get on at all. Just don't expose any dangerous operations in the interface that's available to untrusted documents.

The way to do this is with mandatory access controls and a system to determine the trust level of a given application.

I've worked with systems that really do have fine grained mandatory access controls. If you're concerned about convenience, you REALLY don't want to go down that road.

But it's odd that you like MAC, when the scheme I'm talking about *is* a MAC regime... one that's deliberately designed to be as convenient as possible and stay out of the user's way as much as possible.

There's two trust domains: the desktop environment, where applications don't have to be sandboxed; and the sandboxed environment, that consists of applications (like the b