[CharlesS]

Gah, I just tried it, and you're right. Okay, that's bad.

All this time, I had thought you needed to use sudo when repairing permissions with diskutil (and why on earth shouldn't RP be something you should need to authenticate for, anyway?)

[Chuckit]

This is, however, a good reason not to use an admin account for everyday use — this exploit is only possible if the user is in the admin group.

[Person Man]

Originally Posted by Chuckit 

This is, however, a good reason not to use an admin account for everyday use — this exploit is only possible if the user is in the admin group.

Yes, but Apple defaults to creating the first user as an admin, so it should still be fixed regardless.

[JKT]

MOAB-07-01-2007: OmniWeb Javascript alert() Format String Vulnerability

These people can't even identify the software that the bug is in and they obviously don't have a clue about the software they are reporting on. This is identified as an OmniWeb issue (later clarified as being a WebKit issue - but they don't know why Safari doesn't suffer from it... that'll be because OmniWeb uses a newer version of WebKit and KJS you dummies).

FWIW, this was fixed within a few hours by OmniGroup but the MOAB bunch haven't had the courtesy to update their website to inform people of this yet.

[Horsepoo!!!]

The daily quotes are grade school level humor...how old is LMH again? 12?

[Horsepoo!!!]

LMH has just informed me that he's an idiot and that he doesn't know the difference between Apple and Mac OS X apps. He told me that all of you should stop spending time on his website because he has no more actual Apple bugs to report.

[Hal Itosis]

It's a thin line between love and hate, huh?
Horsepoo!!! I do believe you're jealous.

[Person Man]

Um... the last several moab bugs have been all disk image issues. Can't the guy come up with anything better?

[Angus_D]

AppleTalk panic. Sigh.

[Person Man]

Originally Posted by Angus_D 

AppleTalk panic. Sigh.

He sure likes finding things that are only exploitable for denial of service...

He's either holding out on releasing the really big guns, or he hasn't found any yet.

[Tee]

At least one of MOABs is in the wild.

Do any of the Mac scanners detect it...?
Nope.

Keep on believing that there is no Mac malware...
And when your machine gets compromised and some hacker uses it commit crimes and everything traces back to you - you will gladly take the responsibility because 'there is no Mac malware' so you must be the hacker then...

[wingdo]

Originally Posted by Tee 

Keep on believing that there is no Mac malware...
And when your machine gets compromised and some hacker uses it commit crimes and everything traces back to you - you will gladly take the responsibility because 'there is no Mac malware' so you must be the hacker then...

I know that wasn't directed at me but .....

Never said there was no Mac malware nor did I ever say we are 100% secure. I am not sure how long LMH and his friend have been sitting on some of these bugs waiting to get a list of 30 or so to post, but I am surprised at how relatively inoffensive most of these hacks are. Yes, a couple of them concern me, but for the most part I find that there could be a lot worse out there.

I think most of us agree that one of the Mac's best strong points for anti-virus / anti-malware is the small market share we hold. That and the fact most businesses run Windows, and the real "fun" is in crippling businesses.

[Horsepoo!!!]

Originally Posted by Tee 

At least one of MOABs is in the wild.

Which one? Most of the MOABs are local exploits that may cause kernel panics. More than half of them are related to DMGs...if you only download trusted disk images, LMH is out of a job.

I've known a number of OpenGL apps a few years ago that caused kernel panics. Whoopteedoo...you lose whatever you working on if you didn't think about saving your file. This is a far cry from losing *everything* on your HD due to some remote exploit or unknowingly giving access to your files to a hacker.

And don't get me going on the AppleTalk one...sheesh...what next? A Sherlock exploit?

[Chuckit]

Originally Posted by Tee 

At least one of MOABs is in the wild.

Do any of the Mac scanners detect it...?
Nope.

Oh no, if I keep opening this disk image that panics my computer, that could really be a problem!

[Hal Itosis]

$ 2>/dev/null find -x / -type f -user 0 -not -group 0 -perm -4130 -print0|xargs -0 ls -Gold
-rwsrwxr-x 1 root admin - 54388 Jan 31 2006 /Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool
-rwsrwxr-x 1 root admin - 57336 Mar 24 2005 /Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy
-rwsrwxr-x 1 root admin - 23172 Jan 31 2006 /Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool


Nod if you can hear me.

[Person Man]

Originally Posted by Hal Itosis 

$ 2>/dev/null find -x / -type f -user 0 -not -group 0 -perm -4100 -perm +022 -print0|xargs -0 ls -Gold
-rwsrwxr-x 1 root admin - 54388 Jan 31 2006 /Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool
-rwsrwxr-x 1 root admin - 57336 Mar 24 2005 /Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy
-rwsrwxr-x 1 root admin - 23172 Jan 31 2006 /Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool


Nod if you can hear me.

Yes, we hear you. Apple will most likely fix the permissions, probably via a security update that will fix all the MOAB bugs, once they've all been disclosed.

[Chuckit]

What Apple really needs to do is find some way not to have everybody running as admins all the time. It seems silly to have a "normal" user be something you have to specially set up.

[Big Mac]

Apple probably thinks most people will be confused by having to create two users on initial setup. It would be good for the Setup Assistant to provide such an option, though.

[Horsepoo!!!]

Jeebus...no Jan 16 exploit? LMH must be scrounging for something but can't find anything. My guess is he'll post something pathetic in the middle of the night and call it MOAB-16-01-2007.

I feel somewhat unsatisfied to go to bed without a Jan 16 exploit.

[Hal Itosis]

I would count #15 as three myself.

What if there were a total of 200
admin-editable setuid executables
(which diskutil kindly refurbishes)?
Would you count them as 1 vector?

Even if he stops today, he has shown
Apple's take on "security" for the joke
that it is. (I would expect some heads
should roll in that department).

Your focus on LMH earns you an
honorary Apple Apologist award.

[Horsepoo!!!]

I would count #15 as 30. 10 for each app. No, wait...32. 12 for the first 2 and 8 for the last one, because I bet there are more people that use Keychain Access and Activity Monitor than ODBC Admin.

Originally Posted by Hal Itosis 

Your focus on LMH earns you an
honorary Apple Apologist award.

Thanks! I'm stoked. That almost counts as 2, right? Because being an AA means that I'm an Apple bug that may be exploited to escalate permissions.

Grand total of 34 exploits for #15.

[Gossamer]

Originally Posted by Hal Itosis 

Even if he stops today, he has shown Apple's take on "security" for the joke that it is.

Compare OS X's authentication (enter admin password) to Vista's authorization (blindly click 'ok') and see where the joke is.

[indigoimac]

All this does is make 10.5 that much better, also it seems like Apple is working feverishly on 10.4.9 to address some of these issues.

[mduell]

Originally Posted by Gossamer 

Compare OS X's authentication (enter admin password) to Vista's authorization (blindly click 'ok') and see where the joke is.

[goMac]

Originally Posted by mduell 

My Windows Vista box never asked for my password. I just hit "allow" or whatever. Dunno why yours is asking for a password.

[mduell]

Originally Posted by goMac 

My Windows Vista box never asked for my password. I just hit "allow" or whatever. Dunno why yours is asking for a password.

It's not my screenshot, just one I found on Google Image Search.

Different actions require different levels of approval; some are just an Ok/Cancel, others require a password.

[- - e r i k - -]

It is the difference between an admin and a normal user apparently. As with OS X, Vista uses admin as the default users, only requiring authorisations, not authentications.

[TETENAL]

heise Security - Beginners' mistakes in Mac OS X

For well over twenty years, setuid programs have been a standard mechanism on Unix systems to execute specific activities with other rights than those of the user who is logged in. The security risk this poses and the minimal security precautions that need to be taken have also been known for just as long. However, word on this does not yet seem to have reached the developers of MacOS X. […] What is a great deal more unsettling than the basic problem is the fact that such elementary security concepts were evidently not taken into consideration during the development of Mac OS X. What is truly alarming is that this problem escaped the notice of the internal quality control system. Because Setuid programs are the starting point for anyone looking for security loopholes to exploit in a system, they should be checked rigorously. And errors of this type are easy to track down. It is therefore highly likely that Mac OS X has more errors of the same type.

[Horsepoo!!!]

Originally Posted by TETENAL 

heise Security - Beginners' mistakes in Mac OS X

Yes...the starting point...yet *nobody*, and by nobody I mean NOBODY, has ever taken advantage of the setuid problem.

[TETENAL]

In OS X or are you saying this type of problem in general can not be exploited?

In other news:

RISE Security: RISE-2007001

[Hal Itosis]

Originally Posted by Horsepoo!!! 

Yes...the starting point...yet *nobody*, and by nobody I mean NOBODY, has ever taken advantage of the setuid problem.

And this you know of course, because you have monitored every university, business,
government agency, and military computer network in the world... so you can assure
everyone that their data has *never* and by never you mean NEVER been compromised.



[ exploits don't need to be used in an obvious destructive manner. Silently stealing stuff
is also quite popular... and that's the sort of activity we will hardly ever "hear" about. ]

[Horsepoo!!!]

Originally Posted by Hal Itosis 

And this you know of course, because you have monitored every university, business,
government agency, and military computer network in the world... so you can assure
everyone that their data has *never* and by never you mean NEVER been compromised.



[ exploits don't need to be used in an obvious destructive manner. Silently stealing stuff
is also quite popular... and that's the sort of activity we will hardly ever "hear" about. ]

Tell me about it...I just stole $4.34 from you. Did you notice? Probably not.

I'm just saying that after 5 years, this is the first time we hear about this setuid exploit on Mac OS X. I think we would have heard of it sooner if this hole was exploited fairly often...even silently. Unless there was some Code of Honor thing going on between people that knew about this...for 5 long years.

Be realistic for once, Hal.

Theories and assumptions are nice and all but your theory and assumptions are much less realistic than my theory.

[CharlesS]

Originally Posted by Horsepoo!!! 

I'm just saying that after 5 years, this is the first time we hear about this setuid exploit on Mac OS X. I think we would have heard of it sooner if this hole was exploited fairly often...even silently.

This particular one. But I'm pretty sure there have been other setuid-related exploits in the past.

[Horsepoo!!!]

Originally Posted by CharlesS 

This particular one. But I'm pretty sure there have been other setuid-related exploits in the past.

Probably.

Anyway...yesterday's MOAB focuses on a deprecated API. Apple's never gonna fix it...especially considering nobody uses PICTs anymore.

I'm frankly disappointed by the whole thing...LMH showed us maybe 3 or 4 critical exploits, the rest should be quite low on the priority list.

[TETENAL]

Originally Posted by Horsepoo!!! 

Anyway...yesterday's MOAB focuses on a deprecated API. Apple's never gonna fix it...especially considering nobody uses PICTs anymore.

Although QuickDraw is deprecated Apple will have to provide security fixes for it indefinitely. And whether PICTs are still used is irrelevant. Someone could put a malformed PICT into a website and you could do nothing to prevent it from being displayed.

Yesterday's problem sounds pretty serious.

Apple has now fixed the issue of January 1st.

http://docs.info.apple.com/article.html?artnum=304989

Why didn't they wait until MOAB is over and fix all problems at once?

[Catfish_Man]

Originally Posted by TETENAL 

Why didn't they wait until MOAB is over and fix all problems at once?

Because that would leave security holes exploitable longer?

[CharlesS]

Originally Posted by Horsepoo!!! 

Anyway...yesterday's MOAB focuses on a deprecated API. Apple's never gonna fix it...especially considering nobody uses PICTs anymore.

Uh, if a picture that loaded in my browser caused my machine to get invaded by a security flaw, I know that I sure wouldn't care if the API that enabled this was deprecated or not or what format the picture was in.

[Chuckit]

Originally Posted by Horsepoo!!! 

Anyway...yesterday's MOAB focuses on a deprecated API.

Apparently it affects QuickTime.

[villalobos]

Well yesterday's software update seems to be crediting him.

'Impact: Attackers on the wireless network may cause system crashes
Description: An out-of-bounds memory read may occur while handling wireless frames. An attacker in local proximity may be able to trigger a system crash by sending a maliciously-crafted frame to an affected system. This issue affects the Core Duo version of Mac mini, MacBook, and MacBook Pro computers equipped with wireless. Other systems, including the Core 2 Duo versions are not affected. This update addresses the issue by performing additional validation of wireless frames. Credit to LMH for reporting this issue. '

[Person Man]

Originally Posted by villalobos 

Well yesterday's software update seems to be crediting him.

'Impact: Attackers on the wireless network may cause system crashes
Description: An out-of-bounds memory read may occur while handling wireless frames. An attacker in local proximity may be able to trigger a system crash by sending a maliciously-crafted frame to an affected system. This issue affects the Core Duo version of Mac mini, MacBook, and MacBook Pro computers equipped with wireless. Other systems, including the Core 2 Duo versions are not affected. This update addresses the issue by performing additional validation of wireless frames. Credit to LMH for reporting this issue. '

Credit where credit is due, but I believe that it should only be given to people who practice responsible disclosure, and LMH's disclosures have been anything BUT responsible.

[TETENAL]

The bug of the 29th hangs my Safari.

[Person Man]

Originally Posted by TETENAL 

The bug of the 29th hangs my Safari.

Yup. Because of a malformed JPEG2000 file included on the page.

If you look at the page source, you'll see this little gem:

<img src="bug-files/heat-up.jp2" alt="" height="1" width="1" />
<!-- Never use the macbook at bed again when browsing the MoAB or you will fry your balls, looper -->

Apparently the image causes in an infinite loop condition in CoreGraphics' implementation of JPEG2000.

[jbruner]

After reading the last headline blurb about MoAB I felt I had to find the thread for this and chime in. One question in particular is anyone ACTUALLY using APE to patch these holes? Who would think that's a particularly good idea? It seems the most ludicrous thing of all. Using a piece of software that hijacks functions in a running app and interposes its own functions. Wow. Is that security? Having an app running as root that can inject code into an app is ... unsane. Seriously. I'll admit when I was green I thought MenuExtra and WindowBlinds were great throwbacks to OS 9 ways of working, but as I learned more about what it was doing and why it broke things with each Apple update, I realized -- it's crap like this that will make an OS X Conflict Catcher a possibly viable product!

[Chuckit]

I get really sick of all this APE FUD. The technology is not inherently bad. For the record, Apple has accidentally released a program that wiped out entire hard drives; Unsanity has not. Thus, in practice, you're much more at risk updating iTunes than you are running APE. If you don't want the functionality provided by haxies, sure, don't use them. But the silly hyperbole is getting old.

[goMac]

Originally Posted by Chuckit 

I get really sick of all this APE FUD. The technology is not inherently bad. For the record, Apple has accidentally released a program that wiped out entire hard drives; Unsanity has not. Thus, in practice, you're much more at risk updating iTunes than you are running APE. If you don't want the functionality provided by haxies, sure, don't use them. But the silly hyperbole is getting old.

Actually all patchers, including Apple's Input Manager, and Unsanity's APE have a security issue. Namely, they allow additional patches to be installed without root privileges, and provide a vector for attack. The only saving grace is such an attack requires a second vector. Here is an example:

• A preliminary vector is used. Either through Safari, or a trojan, a new APE module/Input Manager is installed, without needing root privs (admin privs are sufficient, and if you are logged in as an admin, you've got admin privs).
• UsersFavoriteApp is started. APE or Mac OS X (Input Manager) loads in a patch.
• UsersFavoriteApp does an operation that the user trusts, and the operation requires root rights. The user trusts the application and proceeds to give the application their admin password through the standard security dialog.
• The patch installed into UsersFavoriteApp takes over, now with the root privileges the user gave UsersFavoriteApp, fires up the rm tool, and proceeds to wipe the entire hard drive.
• User cries.

Now again, this has never been a problem because there has never been a first vector to use to insert these rouge patches. Trojans are of course a way this could work, but at that point you could just wipe out the hard drive as part of the trojan. MOAB has however revealed attack vectors that could be used to exploit Input Managers or APE.

A fix would be to keep a list of permitted patches somewhere owned by root. Unless a patch was in that list, APE/OS X would not load that patch. The user would have to elevate to root privs in order to add a patch to the "allowed" list, thus keeping a rogue app from modifying that list and forcing a patch to be allowed.

(Of course if a rogue app was elevated to root privs, it could modify the list of allowed patches, but at that point, the rogue app has enough power to wipe your drive anyway.)

[CharlesS]

Originally Posted by Chuckit 

I get really sick of all this APE FUD. The technology is not inherently bad. For the record, Apple has accidentally released a program that wiped out entire hard drives; Unsanity has not. Thus, in practice, you're much more at risk updating iTunes than you are running APE.

Yeah... if you install iTunes 2.0 or whatever ancient version that was.

Honestly, to say a thing like that, and then follow it with this:

But the silly hyperbole is getting old.

The iTunes installer is pretty much running according to the specs of the people who designed it - thus, for it to do nasty thing requires the programmers to really screw up, which I really doubt will ever happen again, after the PR fiasco with the iTunes 2.0 installer. APEs, however, patch other people's code to make apps do things their designers never intended or anticipated for them to do, so the only thing required for nasty things to happen is for both pieces of code, neither of which has any knowledge of what the other does, to interact in an unforseen way.

[Chuckit]

Originally Posted by CharlesS 

APEs, however, patch other people's code to make apps do things their designers never intended or anticipated for them to do, so the only thing required for nasty things to happen is for both pieces of code, neither of which has any knowledge of what the other does, to interact in an unforseen way.

The same is true of any given system update, input managers, CMMs, apps that communicate with or alter the Dock, apps that affect other apps without using APE, or even just new RAM. And as I said, in practice, the odds of "nasty things happening" have been greater for iTunes updates than for APE. Just because something could happen in the far-flung reaches of Bizarro World doesn't make it right to defame a perfectly serviceable product. Lots of people use APE, and their computers do not explode or go on a murderous rampage through downtown Tokyo.

[goMac]

Originally Posted by Chuckit 

The same is true of any given system update,

These are controlled by Apple. If Apple is not trusted, you might as well get off of OS X.

Originally Posted by Chuckit 

input managers, CMMs,

Agreed, and this issue needs to be fixed.

Originally Posted by Chuckit 

apps that communicate with or alter the Dock, apps that affect other apps without using APE,

Patching is the only way to accomplish this sort of attack. If by "affect other apps without using APE" you mean stuff like Mach_Inject, yes, Mach_Inject apps also need to be secure. But simply switching around a few dock images or swapping some icon files is not going to open you to an attack where malicious code can take root privs.

Originally Posted by Chuckit 

or even just new RAM.

New RAM would not likely allow someone to wipe your hard drive.

Originally Posted by Chuckit 

And as I said, in practice, the odds of "nasty things happening" have been greater for iTunes updates than for APE. Just because something could happen in the far-flung reaches of Bizarro World doesn't make it right to defame a perfectly serviceable product. Lots of people use APE, and their computers do not explode or go on a murderous rampage through downtown Tokyo.

I think you're missing the point. The responsible thing to do, for both Apple and any other company that ships a patcher, is to secure their software. Just because someone hasn't exploited these security issues yet, doesn't mean it will never happen. Any way that a potential security hole can be closed is an overall positive for the platform.

[Person Man]

Originally Posted by goMac 

I think you're missing the point. The responsible thing to do, for both Apple and any other company that ships a patcher, is to secure their software. Just because someone hasn't exploited these security issues yet, doesn't mean it will never happen. Any way that a potential security hole can be closed is an overall positive for the platform.

And you are missing his point, too.

He's not talking about the security issues. He's talking about APE itself, which is doing what it is designed to do: alter the function of the operating system by patching things in memory. His point is that people (developers) shouldn't be going around saying "APE is evil! NEVER use it under any circumstances!!!!!1111111oneoneeleven"

Yes, the presence of APE has been known to interfere with applications in unknown ways (such as CharlesS' Pacifist). But to say that APE is evil and should never be used is too much. What's wrong with asking the user if APE (or any other third party system like an Input Manager, etc) is on the system and to try disabling it and see if the bug is still there?

Also, someone else said he couldn't believe that APE was being used to fix the bugs. (And implied that using APE was irresponsible because "APE is teh devil's child.") This is only TEMPORARY, and they are third party patches. This is actually the best way to fix it right now because they don't change the files on the disk. Patching the actual files may interfere with any official fixes that come from Apple later.

Also, they released third party patches to protect people from the irresponsible way that the bugs were disclosed. "This is a bug and this is how to exploit it. And oh, Apple just found out about it the same way you did, just now." (With an implied "go out and have fun and do bad things because NOBODY is protected!")

So, what does the average person do to protect themselves until Apple releases their official fix? Use APE and the third party fixes.

[Person Man]

Originally Posted by jbruner 

After reading the last headline blurb about MoAB I felt I had to find the thread for this and chime in. One question in particular is anyone ACTUALLY using APE to patch these holes? Who would think that's a particularly good idea? It seems the most ludicrous thing of all. Using a piece of software that hijacks functions in a running app and interposes its own functions. Wow. Is that security? Having an app running as root that can inject code into an app is ... unsane. Seriously. I'll admit when I was green I thought MenuExtra and WindowBlinds were great throwbacks to OS 9 ways of working, but as I learned more about what it was doing and why it broke things with each Apple update, I realized -- it's crap like this that will make an OS X Conflict Catcher a possibly viable product!

You're missing the point.

LMH was highly irresponsible in how he disclosed the bugs. He did it this way: "This is a bug and this is how to exploit it. And oh, Apple just found out about it the same way you did, just now." (With an implied "go out and have fun and do bad things because NOBODY is protected!")

Now, it takes time to properly implement an official bug fix. It's not as simple as "fix the bug and you're done." It's "fix the bug, then test the hell out of it to make sure that the fix doesn't break anything else, then release it after it passes the test. If not, change the fix, then test it again, etc."

During that time period, innocent people are WIDE OPEN to potential attacks, so they can use APE and the third party fixes to protect themselves temporarily until Apple's official fixes come out.

And why did they use APE? Precisely because it patches things in memory. If they had patched things on disk (by patching the actual files), there could have been problems caused when Apple's fixes come out later. (People will tend to forget that they installed the third party patch and forget to run the "undo" program before installing Apple's fixes. And then they blame Apple and start threads on MacNN that say "Do not install the ANY security update")

So relax, these APE patches are temporary and protect people until Apple's official fixes come out. Later they can be removed. So it's not irresponsible at all. Be glad that there are people out there who ACTUALLY CARE ABOUT THE LITTLE GUY, unlike LMH who just wants to hide behind his initials to feed his ego.