Who said I was misunderstood? Actually, I am.

I have now come to grips with MoAB and frankly, I don't like it. Or to be more concise, I don't like the way it's been executed. But as for the rest of your post Hal, you really did lose me this time.

Well, that takes care of that then.

http://www.appleinsider.com/article.php?id=2497

About time, I knew Apple would come through :D

You might want to remember that before starting another thread like this one.

It's very nice to see this quick response from Apple. :)

Are we saying that Security Update 2007-002 patches MOAB's #5, #15 and/or #21?

I'm not seeing that. But I agree, it's a step in the right direction... a new way
forward, rather than stay the course. Apple is supporting its troops.

I yield the balance of my time Mr. Speaker. ;)

Same question for the 10.4.9 Update/Security Update 2007-003.

Doesn't seem as if #5 and #15 were done by tweaking group & permissions.
Could they have implemented some other workaround?

--

With #21, I can't recall if I added the PATH that's there or not.
I probably did, and then rolled back the date, but I'm not sure.
Plus, I don't see /sbin/service in the list of items...

Please someone tell me: can you see a PATH in /sbin/service ?
Here's what I get:

PATH='/bin:/sbin:/usr/bin:/usr/sbin'
export PATH

If not, is there some other way they may have solved that one?

I made more or less the same modifications to '/sbin/service' that you did. My file's modification is January, and all of my # comments are still in place so the file hasn't been replaced at least.

Regarding #15, because Apple has left them an opening, one of the Intego antivirus products is actually going around changing permissions on the Apple files, and they are telling their customers that they need to do this because Apple's permissions are too weak. They are basically saying that "you are safer with Intego because Apple by itself is insecure". And with >80% of respondents on this site using an "admin" account for day to day use, they might even be justified in their actions.

On the plus side, these updates do seem to take care of the problem with corrupted dmg triggering kernel panics. The two corrupt dmgs that I had saved both trigger the error message, without the KP. I'm glad they put out a patch for 10.3.9 as well, though I haven't tested that one yet.

Would greatly appreciate it if someone would please answer the following questions, thanks... :)

1) I notice that you say that your file "hasn't been modified", are you implying that a rogue website could take advantage of these unpatched exploits? if so how? I don't see any web browser vulnerabilities that would allow that...

2) in addition don't these exploits all require a user to be running with a admin account thus meaning that those of us (like me) who use limited accounts instead aren't vulnerable to these exploits even though they aren't patched by apple?

3) Does 10.4.9 resolve anymore of these moab exploits?

4) Else, should I apply the fixes for #5, 15, and 21 as mentioned on the moab site (what does the (...) mean, is that just their way of shortening the path and implying that it's not the full path to the file that needs fixing?)? Any other moab exploits that are unpatched that I should patch according to moab's guidelines?

thanks again! :)

***bump***, can someone please answer my above questions? :( thanks! :)

on a sidenote I did decide to file a bug report for the reportedly still unpatched month of apple bugs #5, 15, and 21...the report got closed within a day and I got this response from Apple:

Please include the line below in follow-up emails for this request.

Follow-up: 26291396

Hello hexstar,

Thank you for reporting this issue via Apple's Bug Reporter. We take any report of a potential security issue very seriously.

This message is being sent to you by a security analyst who has reviewed your note. We are well aware that some of the MoAB issues remain unpatched, and we are tracking the fixes for these individually. They will be addressed as soon as possible. Therefore, the radar you filed will be closed.

Best regards,



italics represent my real name being replaced with my user name for privacy reasons

so it does look like Apple is indeed aware of this issue and is working towards a fix...hopefully they'll come up with ones soon as the issues that remain unpatched are potentially dangerous...

I don't see anything implying 'remote' attacks. (Guess you didn't mean me).
Anyway... #5, #15, and #21 --in-and-of-themselves-- are 'local' by nature.


You're safe, to the extent that (again, in-and-of-themselves) they require admin
to get to root. I seem to recall other methods which would get from non-admin
to admin... but I don't recall those specifics. So -- if enough weak-points exist--
a clever attacker could "puddle-jump" (or leapfrog? or whatever the term may
be) from level to level. I'm not sure. Anyone?


I believe it does. I've been too lazy of late to determine all of them. (The ones I
understood best were 5, 15 and 21... so I've focused on those for the most part).


Given what you said in part 2) about running as limited, you should have no worries.

Thanks for posting that Apple reply. It seems to answer my question.

Nope, I was just responding to "Hal Itosis" - it looks like we both have "/sbin/service" files modified with versions of the "fix" proposed on the MOAB page, and the question was whether the 10.4.9 update was responsible, or if we had made the changes and forgotten about. In my case at least, it doesn't look like the updater did anything, i.e. the file hasn't been modified by the recent update, and the "hole" remains unpatched.

Regarding point 2, I think that by not using an "admin" account, you eliminate the greater part of the risk from the ones that are possible because of what can be done with just "admin" level privileges. MOAB #21 is sort of borderline - a user that uses a "standard" account might be inclined to authenticate to unlock secure pref panes from that "standard" account at some point, and if the "Require password to unlock each secure system preference" setting isn't enabled, it might be possible to exploit the hole in the standard account while the pref panes are unlocked (easy if "access for assistive devices" is enabled - which it isn't by default).

Also note that any time you 'su adminuser' from a non-admin account to do a quick admin task, that act unlocks all of your secure pref panes, making you vulnerable as well.

It looks like the 10.4.9 update does address a bunch of the MOAB holes - seven of the changes are listed as being in response to MOAB:
http://docs.info.apple.com/article.html?artnum=305214

As for doing the rest yourself (eg. #5, #15, #21), I'm not about to tell anybody not to. But apart from basic "safe computing" practices, not using an "admin" account for casual use, only logging in to an "admin" to do administrative tasks, and in light of things like #21, only doing administrative tasks from an "admin" account should cut the risk.

thanks you guys for your replies...glad I changed to a limited account for all my normal work and day to day activity which should keep these exploits at bay :) ...I am rather security paranoid so I have my mac non-wirelessly networked (via cable), blue tooth, and AirPort off (due to at least at one point (I believe this has been patched by now but it's not needed anyways so maybe it saves some system resources) there being wireless exploits for the mac), firewall on, autologoff on, a strong password for my limited account, a even stronger one for my admin account, the require auth for all prefs option enabled, require auth to turn off screensaver option on, turned off the mac mini remote thingy, have none of the sharing services on, I actively back up my important files to at least two mediums (often a hard drive and a cd-r/dvd-r depending on file size, preferably two hard drives instead but it all depends on file size and disk space available), and last but not least I don't have the login window list the usernames (boy what a security risk that is) but instead have it do the username and password fields format...yep I'm security paranoid and plan to stay that way as long as scammers and hackers/crackers (whichever you like to call 'em) stay on the internet

so I belive I'm pretty well shielded from these exploits since they either need admin privilages or in the case of #21, unlocked prefs huh? :)

thanks again for your replies guys, greatly appreciate it! :)