Slashdot Mirror

https://launchpad.net/bugs/+bugs?field.searchtext=remote+code+execution&search=Search+Bug+Reports&field.scope=all&field.scope.target=
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1252
http://news.softpedia.com/news/Critical-Vulnerability-Silently-Patched-in-Linux-Kernel-152678.shtml
http://projects.info-pull.com/moab/MOAB-20-01-2007.html
http://projects.info-pull.com/moab/MOAB-14-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html

https://launchpad.net/bugs/+bugs?field.searchtext=remote+code+execution&search=Search+Bug+Reports&field.scope=all&field.scope.target=
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1252
http://news.softpedia.com/news/Critical-Vulnerability-Silently-Patched-in-Linux-Kernel-152678.shtml
http://projects.info-pull.com/moab/MOAB-20-01-2007.html
http://projects.info-pull.com/moab/MOAB-14-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html

https://launchpad.net/bugs/+bugs?field.searchtext=remote+code+execution&search=Search+Bug+Reports&field.scope=all&field.scope.target=
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1252
http://news.softpedia.com/news/Critical-Vulnerability-Silently-Patched-in-Linux-Kernel-152678.shtml
http://projects.info-pull.com/moab/MOAB-20-01-2007.html
http://projects.info-pull.com/moab/MOAB-14-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html

https://launchpad.net/bugs/+bugs?field.searchtext=remote+code+execution&search=Search+Bug+Reports&field.scope=all&field.scope.target=
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1252
http://news.softpedia.com/news/Critical-Vulnerability-Silently-Patched-in-Linux-Kernel-152678.shtml
http://projects.info-pull.com/moab/MOAB-20-01-2007.html
http://projects.info-pull.com/moab/MOAB-14-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html
http://projects.info-pull.com/moab/MOAB-01-01-2007.html

"There's little reason to believe that Mac OS X is protected from viruses by anything other than its low market share at this point. There's not a large enough group of users for network effects to take over. It is not an inherently secure operating system."

I agree with you. Has everyone forgotten the MOAB project last year?

http://projects.info-pull.com/moab/

This was a brief insight into what could be accomplished if a group of people really wanted to put forward the effort to uncover vulnerabilities. It has been argued that some of the vulnerabilities could be further enhanced and developed into malware. If there was a good enough monetary incentive to target Macs, it will be done. Currently malware witters target windows because the market share provides a more efficient monetary return on the time they invest. It would be foolish to think that the brightest malware writers (the real ones that actually develop new malware as opposed to script kiddies) are any different from the best software developers - they make efficient use of their time.

Comments like this crack me up. I deploy multiple platforms at home and die hard *nix guys crack me up to no end, it's that attitude of yours - the "my system is impervious" - alone that stands as proof your systems are as, if not more, vulnerable than the average end user.

OSX hacks and exploits hypothetical?? There was actually a month dedicated to tearing it apart.
http://projects.info-pull.com/moab/

By the way, Microsoft is actually faster to fix security exploits than just about everyone else any more- they've come along way past their monolithic beginnings. I'm sure there's hordes of you ready to argue that statement but the fact of the matter is Microsoft actively seeks bugs and releases patches for potential exploits monthly.

Now I'm going to get off my horse here in a second, but the case and point is it's not the systems that are the issue. It's the users. How often do you go through every line of source code before you compile and install it?? If the answer is never than you're as vulnerable as the average Joe without taking proper precautions.

There is reason that people call Macs 100% secure and immune to any attempts at remote attack. Its because its true. Linux has been breached, OpenBSD has had two remote root incidents. MacOS? Zero, zip, nada.

did you even click on the link for the nvd?

I'll say again - the biggest vulnerability that apple has is the huge bunch of users who believe they are invulnerable and that patches either don't exist or they are not worth applying.

Remember th month of apple bugs? Do you think that was a complete list without any other exploits being available?

You do believe that? Then you might be able to help my uncle move a huge amout of cash out of nigeria where he is falsely imprisoned. Please post your email address and we can continue directly.

Well .. ummm .. not for nothing .. the MOAB had a few bugs that had nothing to do with apple.

http://projects.info-pull.com/moab/MOAB-02-01-2007 .html bug is in VLC not apple software
http://projects.info-pull.com/moab/MOAB-07-01-2007 .html OMNI web
http://projects.info-pull.com/moab/MOAB-19-01-2007 .html Transmit ( 3rd party ftp app )
http://projects.info-pull.com/moab/MOAB-27-01-2007 .html Flip4Mac
Not saying that that they didnt show some important bugs .. Just that it was not all bugs in code that apple controls. Also , at least for me, they turned me off when the second bug was in vlc and not anything apple.

It just felt like a project that was trying to discredit apple more then it was trying to really fix things. The fact that they did not tell apple about the bugs they did find before hand , says to me that they cared more about publicity then fixing them. The fact that they included bugs in software that apple has no control over makes me believe that they did not have enough bugs to fill the month. Which could also be the reasons behind not telling apple. If apple fixed any of the bugs they were told about before release they would have had to include MORE non apple code bugs.

But thats just me.

Well .. ummm .. not for nothing .. the MOAB had a few bugs that had nothing to do with apple.

http://projects.info-pull.com/moab/MOAB-02-01-2007 .html bug is in VLC not apple software
http://projects.info-pull.com/moab/MOAB-07-01-2007 .html OMNI web
http://projects.info-pull.com/moab/MOAB-19-01-2007 .html Transmit ( 3rd party ftp app )
http://projects.info-pull.com/moab/MOAB-27-01-2007 .html Flip4Mac
Not saying that that they didnt show some important bugs .. Just that it was not all bugs in code that apple controls. Also , at least for me, they turned me off when the second bug was in vlc and not anything apple.

It just felt like a project that was trying to discredit apple more then it was trying to really fix things. The fact that they did not tell apple about the bugs they did find before hand , says to me that they cared more about publicity then fixing them. The fact that they included bugs in software that apple has no control over makes me believe that they did not have enough bugs to fill the month. Which could also be the reasons behind not telling apple. If apple fixed any of the bugs they were told about before release they would have had to include MORE non apple code bugs.

But thats just me.

Well .. ummm .. not for nothing .. the MOAB had a few bugs that had nothing to do with apple.

http://projects.info-pull.com/moab/MOAB-02-01-2007 .html bug is in VLC not apple software
http://projects.info-pull.com/moab/MOAB-07-01-2007 .html OMNI web
http://projects.info-pull.com/moab/MOAB-19-01-2007 .html Transmit ( 3rd party ftp app )
http://projects.info-pull.com/moab/MOAB-27-01-2007 .html Flip4Mac
Not saying that that they didnt show some important bugs .. Just that it was not all bugs in code that apple controls. Also , at least for me, they turned me off when the second bug was in vlc and not anything apple.

It just felt like a project that was trying to discredit apple more then it was trying to really fix things. The fact that they did not tell apple about the bugs they did find before hand , says to me that they cared more about publicity then fixing them. The fact that they included bugs in software that apple has no control over makes me believe that they did not have enough bugs to fill the month. Which could also be the reasons behind not telling apple. If apple fixed any of the bugs they were told about before release they would have had to include MORE non apple code bugs.

But thats just me.

Well .. ummm .. not for nothing .. the MOAB had a few bugs that had nothing to do with apple.

http://projects.info-pull.com/moab/MOAB-02-01-2007 .html bug is in VLC not apple software
http://projects.info-pull.com/moab/MOAB-07-01-2007 .html OMNI web
http://projects.info-pull.com/moab/MOAB-19-01-2007 .html Transmit ( 3rd party ftp app )
http://projects.info-pull.com/moab/MOAB-27-01-2007 .html Flip4Mac
Not saying that that they didnt show some important bugs .. Just that it was not all bugs in code that apple controls. Also , at least for me, they turned me off when the second bug was in vlc and not anything apple.

It just felt like a project that was trying to discredit apple more then it was trying to really fix things. The fact that they did not tell apple about the bugs they did find before hand , says to me that they cared more about publicity then fixing them. The fact that they included bugs in software that apple has no control over makes me believe that they did not have enough bugs to fill the month. Which could also be the reasons behind not telling apple. If apple fixed any of the bugs they were told about before release they would have had to include MORE non apple code bugs.

But thats just me.

This article says this is the first exploit fixed that hasn't been logged on the MOAB project.

You misunderstand. This is the first update that doesn't patch anything listed by MOAB. That doesn't mean that everything patched before was. MOAB only listed 31 bugs, whereas dozens of potential vulnerabilities have been patched by Apple in that time.

The MOAB project was started by security researchers who decided to release their findings publicly because they got mad when Apple outright denied some existing vulnerabilities they found.

That doesn't explain why they chose to give the same treatment to VLC, OmniGroup, and Panic.

This article says this is the first exploit fixed that hasn't been logged on the MOAB project.

You misunderstand. This is the first update that doesn't patch anything listed by MOAB. That doesn't mean that everything patched before was. MOAB only listed 31 bugs, whereas dozens of potential vulnerabilities have been patched by Apple in that time.

The MOAB project was started by security researchers who decided to release their findings publicly because they got mad when Apple outright denied some existing vulnerabilities they found.

That doesn't explain why they chose to give the same treatment to VLC, OmniGroup, and Panic.

This article says this is the first exploit fixed that hasn't been logged on the MOAB project.

You misunderstand. This is the first update that doesn't patch anything listed by MOAB. That doesn't mean that everything patched before was. MOAB only listed 31 bugs, whereas dozens of potential vulnerabilities have been patched by Apple in that time.

The MOAB project was started by security researchers who decided to release their findings publicly because they got mad when Apple outright denied some existing vulnerabilities they found.

That doesn't explain why they chose to give the same treatment to VLC, OmniGroup, and Panic.

People want features and features are the enemy of security.

But isn't an OS without features a brick? I can understand not using the features we don't need, but wireless is sought after and really useful. Moaning about people using it is not going to help, following that argument to its logical conclusion would have us all back working with pen and paper. That's not an idea I relish since my typing is far better than my handwriting. :)

BSD has been whiling with little to no market-share despite the fact it's free.

Does this exploit affect BSD too? I was under the impression that the lack of FreeBSD success was due to it's project lead being a total git. Also OSX is based on BSD but still suffers plenty of security problems.

That's a flat out lie and you know it. http://projects.info-pull.com/moab/

I guess we shouldn't use Apple products, the Linux kernel or browsers either eh?

http://projects.info-pull.com/moab/ - Month of Apple Bugs
http://projects.info-pull.com/mokb/ - Month of Kernel Bugs
http://browserfun.blogspot.com/ - Month of Browser Bugs

I guess we shouldn't use Apple products, the Linux kernel or browsers either eh?

http://projects.info-pull.com/moab/ - Month of Apple Bugs
http://projects.info-pull.com/mokb/ - Month of Kernel Bugs
http://browserfun.blogspot.com/ - Month of Browser Bugs

As the Month of Apple Bugs (as well as others) prove, OhitSuX appears to be defective by design.

MOAB proved security through obscurity is not security. I would look forward to a "Month of Linux Bugs"... but it seems EVERY month is given that honor.

One word : marketshare. If your precious Macs ever gain popularity (doubtful) they will have just as many problems as Windows machines do. So keep your head in the sand, and repeat to yourself over and over "Macs really are inherently more secure". If you repeat it enough, you may start to believe it! Oh, did you hear of the Month of Apple Bugs, where they pointed out a security hole, every single day for a month? Here you go, enjoy!

Google for "windows local privilege escalation" and you will find about one in five of the resulting thousands of hits is a long standing unpatched escalation in XP. Here is one that has been unpatched since 2004. Vista hasn't been on the market long enough to build up such a list, but unless MS has severely changed their methods the vista list will just as long soon. Here is a link to one reported three days ago which is unpatched. I don't think there has ever been a time when there was not at least one outstanding, public, unpatched, local escalation in Windows. They are not even considered serious by MS and are so common they don't make the news, unlike local escalations in other OS's.

I disagree. Most users need to install software or their computer does not work for their everyday tasks. MS's decision means most users thus need to be admin to run the average installer and so will expect to have to authenticate when installing anything. This means it will not be uncommon for admin privileges to be asked for when installing some small, non-malicious piece of software making the process identical to installing a rootkit and meaning the user is given no warning at all when faced with a trojan.

Theoretically, users can run installers as non-admin, if they do it manually. The problem is in practice this will not work because of MS's defaults and how that will affect developers' installers. Because of this default by MS, software people use will expect to be admin and be developed and tested as such. It completely undermines the idea of using user accounts to stop malware.

I am aware of the first one there, and the second only works in beta so we have one. (I'm not denying nor would I ever deny that no exploits for Vista exist - only that past exploits for an OS that is 12 years old cannot sensibly be included against Vista - that is ridiculous).

I can't help rendering the issue through the Mac Zealot logic apology process:

"Initial indications are that in order for the attack to be successful, the attacker must already have authenticated access to the target system.

In Zealot logic, that would not count because the user would have to be authenticated, in other words, would have to have an account on the box and be able to log in, therefore the 'exploit' is a non issue and so does not exist. To the sensible people, clearly it is a serious issue but you get the idea.

As for x per month, OSX just had one a day for a month so Vista is already ahead of the game. Based on past experience this of course will not last, but the point is there are exploits for OSX, even if we only count the current version. Anyone going around saying that 'there are zero exploits for OSX' is either ignorant, delusional or in denial.

Have iChat open? Good. Now, open the following URL in Safari: http://projects.info-pull.com/moab/bug-files/MOAB- 20-01-2007.html

Perhaps he was referring to the Month of Apple Bugs:
http://projects.info-pull.com/moab/#about

Anyone have a link to an equivalent Vista site?

Pffff. That's an easy one. Just go to the MOAB website and count. If you do so, you'll see that 23 of the exploits are Apple software and the remaining 8 were third party. Of the 8 third party bugs, 2 of those flaws may also apply on multiple OSes.

Technically he was right (if he said this in January)...

http://projects.info-pull.com/moab/

It's been going on this month - the Month of Apple Bugs.

http://projects.info-pull.com/moab/

Not a single instance of anything 'in the wild' though.

I haven't heard about all those Mac exploits he's referring to, have you?

He's referring to the Month of Apple Bugs. As I understand it, however, many of those bugs are not in Apple products and do not necessarily compromise the entire system.

W

I assume he's referring to the Month of Apple Bugs

No, it's still going strong.
http://projects.info-pull.com/moab/
One could argue the significance of each bug, but I would say the quantity is not lacking. I was sure I would see a few days or a week, but it looks like there has been a total of 23 when I visited the site.

I'd have to say Steve Jobs is a core daemon :-)

Each time an exploit comes out, the pattern is the same. the company doesn't announce it, anti-virus makers are either paid off (as in 'approved' spyware and/or rootkits) or not kept informed, and once the story breaks, the public relations machine starts. The researcher is vilified as a hacker, the problem is denied or minimized, and the prospect of a patch is left moot because this would require accepting that a huge problem exists. Most of us scream that this is ridiculous, companies should tell everyone when an exploit shows up, and patch it as soon as possible. More to the point, they should expose their source code to scrutiny in order to better provide services to their customers.

Are you sitting down? good. They won't and they don't care. The first rule in the PR handbook is to deny and put off realization. If the big front is that there isn't a problem, or that a crack of a voting machine can only be done in a lab, and months down the road, the company quietly sues the researcher or releases a patch, they win. People have a limited attention span and fatigue quickly in the face of fear and hysteria. As long as your company's admission of guilt comes well after the original problem, or not at all, people are happy.

With this in mind, let's look at the law. thankfully, whistleblowers have some protection, and some internal voices about code might not be silenced, especially if the review takes place within the judicial system, and not through a new law. Of course, corporate secrecy, as in the case of Apple and HP, is pretty extreme, and most employees wouldn't risk the civil consequences of voicing a problem that doesn't rise to the level of a public safety hazard.

Outside researchers are in more and more trouble, and this really only leads to problems for the customer base as a whole. We rely on sites like MOAB to shame companies into action. We also rely on OSS competition in order to make products like IE better--Firefox gives an economic incentive to Microsoft to improve their product, otherwise, security development would have languished.

Very few analogues exist in the places where this is critically important: commercial and banking software. CITIbank suffers a classbreak and doesn't bother informing their customers. Security conscious customers can voice their discontent and move to another bank, but we have to trust that the new bank is as averse to security breaches as we are. For the rest of the millions of customers, security will not improve. Since identity theft costs are largely borne by the customers, the banks don't care. because the banks don't care, it is much easier, and better in their eyes, to make publishing voulnerabilities like this one illegal and trust that their customers will never be the wiser.

check out this article:
[PDF] Why information security is hard

http://projects.info-pull.com/moab/

Good work guys! Keep working.. show what Apple has inside (a lot of bugs) =P

You guys should report these issues to the Month of Apple Bugs if you've not done so already.

That "true believer" truly is an iTard. His entire understanding of the mobile market seems to be gleaned from searching Handango for cheap shareware games.

Some have unique platforms for programs (such as Verizon's BREW) that end up only offering expensive junk games, while others have third party development (such as Palm and WinCE / Windows Mobile) which tends to result in being insecure and unstable because the various apps that get loaded are prone to crash the system.

You forgot BlackBerry and the Symbian-based devices from Nokia and Sony-Ericsson. If you're going to spread FUD, don't be a coward and pick the easiest targets. The fact is, none of these devices have had any widespread security issues, due largely to the fact that malware authors tend to go for lower hanging fruit. BlackBerry, Symbian, and Windows Mobile have most of the same protections that desktop operating systems have, and employ code signing to guard sensitive APIs and to verify the source of applications. The Apple "iPhone" is no more or no less vulnerable - being a closed system is simply security by obscurity.

By the way, has being a closed system prevented the iPod from having issues, in both stability and functionality? What makes you think the first generation "iPhone" is going to be different?

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

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

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

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

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.

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.

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

Kevin Finisterre, security researcher, founder of Digital Munition, and co-presenter of the Month of Apple Bugs, has also responded on the SecurityFocus focus-apple list to some of my concerns, expanding on some of the motivations and reasoning behing MOAB (followup).

Also, the second bug was just posted a few minutes ago: a udp:// URI handling vulnerability in VLC Media Player that affects both the Mac OS X and Windows versions of VLC Media Player. While not exactly what I'd call an "Apple bug" (yes, yes, I know the FAQ says they're also looking at "popular applications" that run on Mac OS X as well), it is interesting to note that vulnerabilities in cross platform applications may transfer more easily to the Intel-based Macs running Mac OS X...

In any event, Apple's immediate technical response and longer-term strategic response to MOAB should be interesting.

(Disclaimer: I am the story submitter.)

Kevin Finisterre, security researcher, founder of Digital Munition, and co-presenter of the Month of Apple Bugs, has also responded on the SecurityFocus focus-apple list to some of my concerns, expanding on some of the motivations and reasoning behing MOAB (followup).

Also, the second bug was just posted a few minutes ago: a udp:// URI handling vulnerability in VLC Media Player that affects both the Mac OS X and Windows versions of VLC Media Player. While not exactly what I'd call an "Apple bug" (yes, yes, I know the FAQ says they're also looking at "popular applications" that run on Mac OS X as well), it is interesting to note that vulnerabilities in cross platform applications may transfer more easily to the Intel-based Macs running Mac OS X...

In any event, Apple's immediate technical response and longer-term strategic response to MOAB should be interesting.

(Disclaimer: I am the story submitter.)

In case anyone happened to miss this on the MoKB site...

Be sure to have your speakers turned on and up.

http://projects.info-pull.com/mokb/MOKB-26-11-2006 .html

Try putting a fresh 10.4.8 install on an Intel Mac and running the new Broadcom exploit against it. Now try it with the patch Apple released a month after the Black Hat presentation. Is this the same bug? Did they reverse engineer Apple's patches to find this? Why are they NOT claiming that this is the infamous bug? Why would they bother faking an exploit in the first place? Why isn't Apple listed as a vulnerable vendor in the MoKB advisory? My opinion is that the rabid response the Gruber's fans have turned them off from ever "addressing" the Mac community with any "proof" they have to offer. Regarding the old Airport bug I found -- its the hardware I happened to have. If you want to send me a shiny new Intel Mac, I would be more than happy to start dumping wireless driver bugs for that platform as well. Hardware hacking is expensive dammit :-)