The macosxhints Forums

The macosxhints Forums (http://hintsforums.macworld.com/index.php)
-   The Coat Room (http://hintsforums.macworld.com/forumdisplay.php?f=8)
-   -   Why isn't Apple releasing patches for the Month of Apple Bug exploits??? (http://hintsforums.macworld.com/showthread.php?t=67421)

maclova 02-05-2007 01:26 AM

Why isn't Apple releasing patches for the Month of Apple Bug exploits???
 
Why is it that there still has been just one patch released from Apple (that one that fixed the QuickTime exploit) to address just one of the many Month of Apple Bugs? These bugs need to be fixed and I really hope that Apple is actively working on patches for all of the exploits related to Mac OS X that the MOAB team found...is it because they're putting all their programmers energy into 10.5? If that's true they really should take a few of the programmers and assign them to making patches for these exploits...what's the chances of these exploits being fixed in 10.5? c'mon Apple...get on it already! :(

bramley 02-05-2007 03:19 AM

Quote:

Originally Posted by maclova (Post 355072)
c'mon Apple...get on it already! :(

http://www.apple.com/macosx/feedback/

6502 02-05-2007 04:23 AM

Which bugs and exploits do you suggest that Apple fix?

Should Apple fix the bugs found in VLC, in AIM, in APE, in Adobe's PDF spec or perhaps the bugs found in Flip4Mac?

The month of Apple Bugs was a bit of a letdown. There were a few bugs found in Apple software -- most of which could at worst result in a crash or DoS -- one exploit that was already patched and a few vulnerabilities in third-party products that Apple has little control over.

A valid criticism that I've heard is that VLC is GNU open source, so if the MoAB guys found a vulnerability, why didn't they post a fix themselves?

If they wanted to post the list to improve the security of the Mac OS, they look like hypocrites for not fixing the stuff that was within their power to fix.

Mikey-San 02-05-2007 04:47 AM

Maybe next time the people at MoAB will be responsible enough to notify the developers first, instead of jumping onto their Web site and acting like asshats.

And echoing what 6502 said, it's not Apple's responsibility to fix bugs in third-party software, which constituted the majority of the bugs reported on MoAB.

styrafome 02-05-2007 04:47 AM

How do you know they are not already "on it?"

The software I've seen, when you do a patch, sometimes you can't just write the code and send it out. It's good to test it, and also to verify that your fix does not introduce new bugs or exploits, and you have to run those tests on all combinations of supported Mac hardware and OS versions. I don't think all that is easy to do in an afternoon.

Hamo 02-05-2007 01:09 PM

Quote:

Originally Posted by Mikey-San (Post 355096)
bugs in third-party software, which constituted the majority of the bugs reported on MoAB.

Majority would be more than 15.

Even counting all of the .dmg issues as one still makes 16 Apple issues.

It is also worth noting that all of the third-party apps (except Flip4Mac) have already been updated...

ThreeDee 02-05-2007 01:22 PM

Although security is a good thing, some people are really paranoid and overreact.

Hamo 02-05-2007 06:39 PM

Quote:

Originally Posted by ThreeDee (Post 355181)
Although security is a good thing, some people are really paranoid and overreact.

That guy was concerned that he 'caught' something by viewing one of the MoAB pages.

But, his concern was actually prophetic given the discovery that the write-up of MOAB 29 contained a denial of service/crash exploit... (link is to description of issue, not actual crasher)

ThreeDee 02-05-2007 07:45 PM

Anyway, I think it's probably gonna all be fixed in 10.4.9.

Hal Itosis 02-06-2007 12:35 AM

Quote:

Originally Posted by 6502 (Post 355091)
The month of Apple Bugs was a bit of a letdown. There were a few bugs found in Apple software -- most of which could at worst result in a crash or DoS -- one exploit that was already patched and a few vulnerabilities in third-party products that Apple has little control over.

A valid criticism that I've heard is that VLC is GNU open source, so if the MoAB guys found a vulnerability, why didn't they post a fix themselves?

If they wanted to post the list to improve the security of the Mac OS, they look like hypocrites for not fixing the stuff that was within their power to fix.

Oh I agree.

That's just like all these stupid newspapers and TV shows... making a big
deal about Iraq. Why doesn't Katie Couric fix all our "so-called" problems?

</sarcasm>

Study MOABs #5, #15, and #21... thoroughly. Then, re-read your post...
and see if it may need to be rephrased. (As I've said elsewhere, Leopard
better arrive tighter than a cat's ass in water!)

I think the OP's question was worthy of a little (read: a lot) more consideration.

-HI-

6502 02-06-2007 11:20 AM

> Study MOABs #5, #15, and #21... thoroughly. Then, re-read your post...
> and see if it may need to be rephrased.

Study them yourself.

A privilege-escalation exploit shouldn't require admin authorization.

If you've got admin access to begin with, what are you accomplishing?

Craig R. Arko 02-06-2007 12:19 PM

Is there a difficulty understanding the meaning of the term 'help request' these days? Is that some new exploitable bug? :D

Moving to Coat Room...

biovizier 02-06-2007 12:19 PM

Trick question
I like to download and try out freebie games and stuff but hate that even though I'm "admin", I have to punch in my 30+ character password all the time. Someone said a few years ago if I'm using "admin" on a Mac, I might as well be using "root". I'm pretty comfortable with computers so I'm not worried about accidentally deleting system files or anything like that so is it ok for me to use "root" every day instead or should I stick with my "admin" account?

Craig R. Arko 02-06-2007 12:30 PM

Quote:

Originally Posted by Hal Itosis (Post 355388)
Oh I agree.

I think the OP's question was worthy of a little (read: a lot) more consideration.

-HI-

Do you believe Apple is leaving these bugs in deliberately, Hal?

For myself, I wrote and tested software for over a decade in way more stringent environments than Mac OS X will ever find itself in. My experience is that releasing knee-jerk "patches" to bugs without a lot of regression testing of the changes is a sure way to destabilize the entire system. We learned that pretty well with the classical Mac OS, and with most versions of Windows.

I will say IBM did a pretty nice job with OS/2, as did DEC with VMS. On the other hand we don't hear much about those OS's these days, so there is a tradeoff, to be sure.

ThreeDee 02-06-2007 01:47 PM

Quote:

Originally Posted by biovizier (Post 355503)
Trick questionI have to punch in my 30+ character password

30+ character password?! Mine is about 15.

Note that saying to some person "I have a 13 charecter password" makes it alot easier for him to brute force. The person could then skip brute forcing all the 1-12 length passwords. If you were telling the truth, that is.

Again, I really think these will be patched in 10.4.9.

Craig R. Arko 02-06-2007 01:55 PM

Quote:

Originally Posted by biovizier (Post 355503)
Trick question
Someone said a few years ago if I'm using "admin" on a Mac, I might as well be using "root".

Someone was *wrong.* An admin account needs to authenticate to mess with system files (hence typing that password). Root doesn't.

I'm kind of the odd duck in that I enable root and (rarely) Fast User Switch to root to do some system-related task using a GUI app. But 'rarely' means just a couple or so times a year now.

Hal Itosis 02-06-2007 06:18 PM

Quote:

Originally Posted by 6502 (Post 355477)
> Study MOABs #5, #15, and #21... thoroughly. Then, re-read your post...
> and see if it may need to be rephrased.

Study them yourself.

A privilege-escalation exploit shouldn't require admin authorization.

If you've got admin access to begin with, what are you accomplishing?

Well... if that is your question, then obviously you're the one who
needs to study. In those 3 cases, root is attained without password.
(( i can hardly believe we're even having this conversation at this point ))


<deleted>

[I typed out some other info but I'm not going to bother.
The info is out there... you just didn't click on my links.]


What then is the (extreme) opposite of "FUD"...
Obliviousness, Overconfidence and Complacency?

OOC ! :)

Craig R. Arko 02-06-2007 06:28 PM

Hal, you seem to be getting a bit belligerent with folks who don't see things your way; both here and elsewhere. ;)

I'm trying to understand why, and failing miserably.

Hal Itosis 02-06-2007 06:42 PM

The facts should speak for themselves...
but some folk just don't WANT to learn.

Fortunately, the Mac "hacker" community
is equally disinterested... so it works out.

Craig R. Arko 02-06-2007 06:53 PM

Which facts are those? That all major pieces of software have a lot of bugs? Some of them more serious than others? And that it takes more than a snap of the fingers to repair them?

I think people get that.

I also think people tend to dislike outfits that put their own interests ahead of the user community. Many feel that the MOAB people have done just that, by ignoring anything resembling a useful bug-reporting protocol and showboating instead. I'm sure more than a few feel the same way about Apple. Obviously Mr. Gates does.

Hal Itosis 02-06-2007 07:19 PM

Quote:

Originally Posted by Craig R. Arko (Post 355679)
I also think people tend to dislike outfits that put their own interests ahead of the user community. Many feel that the MOAB people have done just that, by ignoring anything resembling a useful bug-reporting protocol and showboating instead. I'm sure more than a few feel the same way about Apple. Obviously Mr. Gates does.

See, there you go again... blaming the Iraq war on Katie Couric.
I don't give two hoots about the personalities involved here.
Those MOAB people don't owe me doodly-squat. I never paid
them dime one. Apple OTOH is where my displeasure rests.

Now that my shell-scripting knowledge is gradually maturing, as I look at
some of the LAME, LAME, practices in the Unix side of these holes... it is
clear that Apple put no effort (NONE) into being security "conscience" with
some of their setups. It's a joke. They (Apple) owe us a lot more than that.
I'm a stockholder [AAPL]. You are probably too. I have invested much green
in their computers, and now iPods. You... probably more.

So how did they get in this position where some snotty-sounding dudes can
just pick them to pieces like this. Simple. They fell asleep at the switch.
You know why the fixes are so long in coming? It ain't gonna be easy to
clear out the cobwebs... that's why.

What about all the Macs with 10.3.8 or less? 10.4.7 or less?
They're sitting ducks... that's what. MOAB didn't create the
problems... they just reported them. Don't like their style?
Well not me either. But that's irrelevant.

We will see how much "fixin'" got done (soon I hope), but if
they (Apple) don't nail it... we'll be hearing more of MOAB's
r e p o r t a g e.

:mad: So be prepared! :D

6502 02-06-2007 08:46 PM

MOAB #5:
Exploitation conditions:
Privileges for overwriting a BOM inside /Library/Receipts/ are necessary (ex. users in the admin group are allowed to do it).

MOAB #15:
Multiple binaries inside the /Applications directory tree are setuid root, but remain writable by users in the admin group (ex. first user by default in a non-server Mac OS X installation), allowing privilege escalation

MOAB #21
Now THAT one can be done without admin access. But it's a privilege escalation technique that can't be done from a remote machine, so it's not exactly a severe threat.

hayne 02-06-2007 08:58 PM

Let:
A = risk of damage due to exposure to some MOAB-related exploit
N = number of people who might be exposed to this risk (via some malicious web site, etc)

B = risk of damage due to a less-than-fully-tested fix from Apple
M = number of people who would be exposed to this risk (via Software Update)

If Apple estimates that:
A * N
is less than
B * M
then they would likely sit on their proposed fixes until they are sufficiently tested that B becomes small enough to reverse the inequality.
It is quite likely that M is far greater than N

trumpet_999 02-06-2007 10:45 PM

I'm gonna sound like a real dolt here but, i consider myself a fairly strong mac user, but i dont know what 'MOAB' is or stands for...??

maclova 02-06-2007 11:31 PM

Quote:

Originally Posted by trumpet_999 (Post 355733)
I'm gonna sound like a real dolt here but, i consider myself a fairly strong mac user, but i dont know what 'MOAB' is or stands for...??

:eek: :eek: :eek: !

MOAB=Month Of Apple Bugs and you can read up on it and the unpatched exploits and their free publicly availible proof of concepts (><!) here: http://projects.info-pull.com/moab/ :)

biovizier 02-07-2007 12:30 AM

Quote:

An admin account needs to authenticate to mess with system files (hence typing that password). Root doesn't.
Actually, that's not true. From the point of view of malware, anything running with user-level privileges in an "admin" account doesn't need a password to modify system files, as various MOAB vulnerabilities have demonstrated. So in terms of susceptibility to malware, running as "admin" instead of "root" offers no protection (hence the hidden "trick question" warning in my post 13) i.e. if you're logged in to an "admin" account, you might as well be logged in to "root".

What bothers me (and I suspect Hal Itosis) is why Apple hasn't done anything systematic about it, despite the fact that "Opener" demonstrated how easy it is to get from "admin" to "root" without a password way back in the "Panther" era in 2004. The specific routes exploited by "Opener" were patched, but nothing was done systematically, hence other exploits made possible by the same underlying weakness (sensitive directories writable by admin) were still there ripe for the picking by MOAB over two years later in "Tiger". Will Apple do a thorough audit before Leopard gets out, or will it be another haphazard effort?

Apple seems to have a good security model, but can't get all of their divisions to follow the plan. If it worked like it should, "root" gets to do anything, someone supplying "admin" credentials gets to do anything, but other than "root", no user (including an "admin") gets to modify anything beyond their own files without supplying an "admin" password. If it worked as it should, there would be very little problem with using your default 501 account as your main account. But it doesn't - the system is rife with ways to get from "admin" to "root" without a password, and the result is the sad state of the OS X "admin" account where currently, a legitimate admin user installing legitimate system level software has to punch in a password, but malware installing a rootkit doesn't.

schwartze 02-07-2007 01:18 AM

Quote:

Originally Posted by Hal Itosis (Post 355685)
See, there you go again... blaming the Iraq war on Katie Couric.
I don't give two hoots about the personalities involved here.
Those MOAB people don't owe me doodly-squat. I never paid
them dime one. Apple OTOH is where my displeasure rests.

See, there you go again... asking Katie Couric to fix the problems in Iraq.

Macosxhints.com is not a channel to Apple.

I am sure there are links at apple.com and developer.apple.com to work out the issues related to apple software and what they put out to fix security and other problematic issues.

This site, from what I have garnered over the past couple of years is a place to go to/come to to get info on ways to tweak things, work things out, and use the hardware/software to it's potential, not to fix the world or fix the company that sells you the system you are using.

It's an added bonus of some really good people who help people (like me) out and put up with answering a lot of dumb questions (sometimes by me) which have been asked countless times so they don't have to charge people to go their house/place of business to fix problems.

Rant/Gripe/Pay for a full page editorial if you really feel that a company is treating you so poorly, but please stop yelling at the people trying to answer your questions and work out the who/what/when/why when these people don't make the decisions you want made.

trumpet_999 02-07-2007 06:15 AM

well said ...

Craig R. Arko 02-07-2007 09:01 AM

Quote:

Originally Posted by biovizier (Post 355768)
Actually, that's not true. From the point of view of malware, anything running with user-level privileges in an "admin" account doesn't need a password to modify system files, as various MOAB vulnerabilities have demonstrated. So in terms of susceptibility to malware, running as "admin" instead of "root" offers no protection (hence the hidden "trick question" warning in my post 13) i.e. if you're logged in to an "admin" account, you might as well be logged in to "root".

Thanks for the lucid explanation, bio; I can follow that. Can we agree that the cases of being affected by malware and committing a user error while logged in as root are not equally likely?

Quote:

Originally Posted by biovizier (Post 355768)
Will Apple do a thorough audit before Leopard gets out, or will it be another haphazard effort?

I wonder if you can offer me an example of what you consider to be a 'not-haphazard' effort along these lines? And what might be the economic impact associated with that effort, in terms of the end-user cost of a shipping product?

OpenBSD is the closest thing I can think of; but I don't know that it has a widespread following, or much in the way of consumer grade software support.

I recall we spent enormous amounts of effort (and dollars) in the biomedical device industry on software testing and quality assurance while in the FDA approval process. I also recall that hindsight found systematic flaws in that software, even after meeting the rigorous standards that were set to receive that approval. And those items, of course, were not available for $129 at the mall.

Which is why, in balance, I don't feel Apple really does all that bad. And perhaps that is why I have had Macs connected to the Internet with static IP addresses 24/7 since 1995 (we had routed dialup and a Class C subnet then :D ) without having a single one of them compromised. Ever. That's from System 7 through Mac OS 9 through the OS X Public Beta through 10.4.8. And yes, they were all buggy.

So maybe it's a little easier to see my point of view if I don't start yelling 'fire' today, when there are bug reports.

Hal Itosis 02-07-2007 11:35 AM

Quote:

Originally Posted by schwartze (Post 355786)
Macosxhints.com is not a channel to Apple.

I am sure there are links at apple.com and developer.apple.com to work out the issues related to apple software and what they put out to fix security and other problematic issues.

This site, from what I have garnered over the past couple of years is a place to go to/come to to get info on ways to tweak things, work things out, and use the hardware/software to it's potential, not to fix the world or fix the company that sells you the system you are using.

It's an added bonus of some really good people who help people (like me) out and put up with answering a lot of dumb questions (sometimes by me) which have been asked countless times so they don't have to charge people to go their house/place of business to fix problems.

Rant/Gripe/Pay for a full page editorial if you really feel that a company is treating you so poorly, but please stop yelling at the people trying to answer your questions and work out the who/what/when/why when these people don't make the decisions you want made.

What on Earth are you talking about? I know what macosxhints is
(been coming here half-a-year longer than you). Craig asked me a
question, so I just wanted to let him know how I felt. I also know
something about tweaking things, but thanks for the clarification.

I'm not so much in a huge rush for Apple to release a "fix" as I am
desirous that they start adhering to principles and practices which
would tend to *avoid* snafus like this in the first place.

biovizier seems to be "Open" minded enough to empathize.

Declaring $PATH in scripts is a known secure thing to do (it was in
the early chapters of a book I read called "Classic Shell Scripting").
Either do that, or use full/absolute paths. Looking at MOAB #21 for a
second, I decided to see what else might be vulnerable. I found that
of all things /usr/sbin/periodic has left its $PATH wide open.

(my "#21" link on page 1 helps explain *how* it can be hacked)

schwartze 02-07-2007 01:12 PM

Hal Itosis -

You left out the one line of my post which explained what on earth I was talking about.

I followed the other thread about MOAB that you were participating in discussing what can be done now until something is done. That is what I believed the spirit of the board is about. Then again, I don't run the board, just use it and am sure others use it for different reasons.

yellow 02-07-2007 01:24 PM

I'd like to ask those that are upset a question:

How would you like Apple to have patched these holes uncovered by MLH?

The MOAB finished a week ago? Should there have been a patch a day?

ThreeDee 02-07-2007 01:32 PM

All this arguing and complaining is probably what the MoAB wants. That was probably the whole point of it.

Craig R. Arko 02-07-2007 01:45 PM

Quote:

Originally Posted by ThreeDee (Post 355918)
All this arguing and complaining is probably what the MoAB wants. That was probably the whole point of it.

Actually, I believe it was mostly about getting some free press to promote their online forums and gaming site, which they plug in bug #31. There sure didn't seem to be a whole lot of interest in helping the Mac user community.

Hal Itosis 02-07-2007 02:12 PM

Quote:

Originally Posted by yellow (Post 355914)
I'd like to ask those that are upset a question:

How would you like Apple to have patched these holes uncovered by MLH?

The MOAB finished a week ago? Should there have been a patch a day?

Not soon enough.

Some should have been plugged 3 YEARS ago. Are we supposed to believe
that Apple (the computer designer... not the music merchant) is just now
learning about *all* these issues? Did they really need some Romanian
skrypt-kiddie (whatever) to teach them about group-writable setuid files?

At least they should be 'wheel'... but why writable? Is root not enough?

yellow 02-07-2007 02:20 PM

Quote:

Originally Posted by Hal Itosis (Post 355930)
Did they really need some Romanian
skrypt-kiddie (whatever) to teach them about group-writable setuid files?

Absolutely not. I agree with your assessment.

While I agree with the spirit of what MLH was trying to do, I disagree with how it has been carried out him (almost like a dog and pony show), but I am even more disappointed in how the media has glommed onto the story and in some cases blown it way out of proportion.

It's no joke that MLH has uncovered some potentially serious exploitable bugs in the OS. It's also no joke that some of these exploits have little to nothing to do with Apple, other than running on OS X. Will they all get patched? Let's hope so. I expect that they are currently working at top speed getting Leopard out the door. Bug fixes are soon to follow.

I think the biggest problem I have with all of this is how people expected a multi-billion dollar company like Apple to behave any different than any other multi-billion dollar company that puts out a similar product. They got caught after the fact. That's not a novel concept. It's deplorable, but unfortuantely (IMO) common place today.

vntgntks 02-07-2007 02:59 PM

Actually, it isn't over yet. # 31 is still "coming soon". It is hanging out there like the second shoe! And is their choice of moab as an acronym just a coincidence? Did they name it moab after the GBU-43, the Massive Ordnance Air Blast (MOAB) (also known as the Munitions Ordnance Air Blast and Mother Of All Bombs, which
is touted as the most powerful non-nuclear weapon ever designed! (Thank you Wikepedia).

Neat tie in with Apple’s use of the bomb symbol. Just wondering.
Richard

ArcticStones 02-07-2007 03:10 PM

Quote:

Originally Posted by Craig R. Arko (Post 355923)
Actually, I believe it was mostly about getting some free press to promote their online forums and gaming site, which they plug in bug #31. There sure didn't seem to be a whole lot of interest in helping the Mac user community.

Precisely that has been my impression all along as well. I really can’t see much in this beyond a clumsy and transparent attempt at some free PR.

Hal Itosis 02-07-2007 06:16 PM

[Just need to clear up some misunderstanding here,
which may otherwise spread beyond trumpet_999]:


Quote:

Originally Posted by schwartze (Post 355786)
I followed the other thread about MOAB that you were participating in discussing what can be done now until something is done. That is what I believed the spirit of the board is about. Then again, I don't run the board, just use it and am sure others use it for different reasons.

Looks like you missed the part where the mods moved this thread to the "Coat Room".
It happened yesterday, back on page 1. (We could probably discuss coats if you wish).
I think in here the discourse is more free flowing. A different sort of "tweaking" perhaps.

You still seem to be under some mistaken impression that I'm asking for someone's help!!!
Any questions I've posed in here so far were rhetorical, intended to make the reader think.
Sorry if my maneuvering was unclear. (Any message you wrote to me while assuming I was
seeking 'macosxhints' to answer for Apple was totally off the mark. Oh well, that's over now).

--
[back on topic]
--

Quote:

Originally Posted by 6502 (Post 355705)
]MOAB #5:
Exploitation conditions:
Privileges for overwriting a BOM inside /Library/Receipts/ are necessary (ex. users in the admin group are allowed to do it).

Ah, almost sounds like that's a good thing: as long as it's "only" an admin
that can be tricked... then *those* types of vulnerabilities are just dandy.



Quote:

Originally Posted by 6502 (Post 355705)
MOAB #15:
Multiple binaries inside the /Applications directory tree are setuid root, but remain writable by users in the admin group (ex. first user by default in a non-server Mac OS X installation), allowing privilege escalation

Same here, right? No problem? Shucks, I'd be surprised if Apple even
bother to patch those either. After all, admin accounts are 100% safe.



Quote:

Originally Posted by 6502 (Post 355705)
MOAB #21
Now THAT one can be done without admin access. But it's a privilege escalation technique that can't be done from a remote machine, so it's not exactly a severe threat.

Oh, I see... ``severe' ' ``remote' ' threats are the only ones that matter.

As long as *your* Mac is safe, then no one need care about any school,
university, business, government agency, or military computer network.

Teachers, employers, and other "administrators" are never so gullible
as to be taken advantage of by students, disgruntled employees, spies
and so forth. If an admin happens to open a "document" (or a game)
given to them by a coworker or some other "trustworthy" subordinate,
they shouldn't rely on the operating system to provide basic protection
from shell-scripted assaults at well-known weak-points (system files!).

Thus, Apple is fully justified in shipping such marginal designs, because:
there's no severe threat to 6502's setup. (Not from afar anyway).

What does it matter if sensitive data may get copied by other users
in some office scenario, or under classroom / laboratory conditions,
or in any typical professional / industrial / or commercial context ?

The only place a Mac belongs is at home, preferably in the playroom.

Gee, that's nice to know.
I feel much better now.
A thousand thanks.

;)

[kidding]

cwtnospam 02-07-2007 06:43 PM

Quote:

Originally Posted by Hal Itosis (Post 356032)
Any questions I've posed in here so far were rhetorical, intended to make the reader think.

Since we're just thinking out loud, let's think about how Apple stacks up against the competition when it comes to security.
Quote:

Originally Posted by Hal Itosis (Post 356032)
Thus, Apple is fully justified in shipping such marginal designs,...

I'd like Apple to be perfect as much as anybody, if for no other reason than to continue to make Microsoft look bad! (I recognize that I dislike MS more than I like Apple.) The fact is that no OS has ever been 100% secure, and it's highly unlikely that any OS ever will be. The best we can hope for is relative security.

If we were experiencing hoards of compromised Macs being used to attack the internet, or spam our inboxes, then I'd be joining you in your criticism. The fact is, they've got the best security track record out there, and until something happens to change that, it's hard to blame them if closing every potential hole isn't their number one priority. I'm just glad its relatively high on a very large list.

trumpet_999 02-07-2007 07:31 PM

Quote:

Originally Posted by Hal Itosis (Post 356032)
[Just need to clear up some misunderstanding here,
which may otherwise spread beyond trumpet_999]:

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.

6502 02-16-2007 12:37 AM

Well, that takes care of that then.

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

maclova 02-16-2007 12:43 AM

About time, I knew Apple would come through :D

Craig R. Arko 02-16-2007 08:20 AM

Quote:

Originally Posted by maclova (Post 358520)
About time, I knew Apple would come through :D

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

MBHockey 02-16-2007 11:07 AM

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

Hal Itosis 02-16-2007 02:04 PM

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. ;)

Hal Itosis 03-14-2007 05:01 PM

Quote:

Originally Posted by Hal Itosis (Post 358687)
Are we saying that Security Update 2007-002 patches MOAB's #5, #15 and/or #21?

I'm not seeing that.

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 ?
Code:

$ cat /sbin/service | grep PATH
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?

biovizier 03-14-2007 05:24 PM

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.

maclova 03-15-2007 01:45 AM

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! :)

maclova 03-15-2007 08:55 PM

Quote:

Originally Posted by maclova (Post 365428)
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...

Hal Itosis 03-15-2007 10:03 PM

Quote:

Originally Posted by maclova (Post 365428)
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...

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.


Quote:

Originally Posted by maclova (Post 365428)
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?

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?


Quote:

Originally Posted by maclova (Post 365428)
3) Does 10.4.9 resolve anymore of these moab exploits?

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).


Quote:

Originally Posted by maclova (Post 365428)
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?

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.

biovizier 03-15-2007 10:22 PM

Quote:

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?
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.

maclova 03-15-2007 11:42 PM

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! :)


All times are GMT -5. The time now is 12:17 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.