Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Also, the second bug was just posted a few minutes ago: a udp:// URI handling vulnerability in VLC Media Player [info-pull.com] 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.

Month of apple bugs over in one Bug? They had to go to an application already? Also, who would have known, an application writer that makes a mistake on one platform might make that same mistake on another.

VLC != Quicktime. On top of that Quicktime would be a valid target for the month of Apple Bugs as it ships as part of OS X and is created by Apple, VLC does not and is not. A bug in VLC is no more an apple bug then an SSH bug in PuTTY is a Windows bug.

Man, they're really scraping the bottom of the barrel, and it's only January 2nd! A string handling vulnerability in a cross-platform app I've never heard of? They should at least have been able to make it to the end of the BCS before resorting to filler like that.

See, the point of switching back to Mac from Linux for recreational desktop use is that I just click on files and they play. If I wanted abuse for not being familiar with some media player minutia, I'd still be in #mplayer trying to figure out what to install to view a WMV.

.. while others are switching from OS X to Linux because they feel more comfortable about the transparency under which security vulnerabilities are handled..

Anyway, as on Linux and on OS X, if you install mplayer you'll still need to find external support to play WMV's. Just as on OS X, as on Linux, if you install VLC [videolan.org] you can click a WMV and it'll play.

i've found that Quicktime Pro + Flip4Mac + some divx dirivitive does give VLC a run for it's money on my mac mini attached to my TV, particularly from a UI point of view.*now if i don't have the time to set everything up so that it purrs, i'll throw VLC onto a system.

*i'm sure front row will be just stellar with this setup, but i have a PPC in my mini, so apple said "wait 'till leapard... or install an older version of OS X and patch it." sometimes apple's idiotic policies (.mac, quicktime pro, front row be

If you don't like the interface that comes with vlc, pick another one [videolan.org]. Incidentally I've found quicktime to be one of the most annoying fucking apps ever. The wanky little pull-outs that slide out unnecessarily are just stupid. I guess "pretty" is what stands in for "well designed" in apple-land these days.

I'm sorry to hear that application developers don't offer you the same flexibility on OSX that we tend to get everywhere else.

The flexibility to choose between a wide array of interfaces that are consistent only in their all being horrible to use is not really considered a feature. We like interfaces that look like the rest of the OS, and behave in ways specified by the HIG. I do not feel the need to put stickers and custom rims on my car, and I do not feel the need to rice my computer, either.

It used to be that there were important interface guidelines that users expected applications to respect, so arbitrary skins didn't really make sense. Of course now that Apple doesn't seem to worry so much about those "trivial" matters I suppose skinning will become more commonplace.

Yeah, I started to get my back all up but luckily I finished reading your comment. Apple has three widget sets and they use them all in currently shipping versions of OSX. They have also apparently forgotten everything they

sure, unless you want to play them full screen when the author doesn't want you to - you actually have to pay for quicktime pro for that

Or learn a little scripting. Apple didn't learn the "if you don't want it used, don't ship it" tenet of security. The full screen functionality (at least it used to be) was easily accessible with AppleScript, even without pro.

That's not really a security issue because Quicktime and Quicktime Pro are the same software. Quicktime is simply crippleware based on the regkey - features are disabled. Want proof? The same download works for both quicktime and quicktime pro, and the dif

That's not really a security issue because Quicktime and Quicktime Pro are the same software.

Yes, it is a security issue, but only from Apple's point of view. Customers are getting something they didn't pay for. That's a hole in the implementation. The only truly secure implementation would be to not ship the feature in the lite version.

odds of the average user writing an applescript to fullscreen quicktime is basically nil compared to the odds of them downloading VLC

If you can spend an afternoon or two googling around to figure out wtf happened to sound AND video during a routine install of Debian and call that "progress*," you will think the hack for making Quicktime fullscreen for free is a snap.

*Granted, last time I did this was 2 years ago, I'm sure things have progressed.

If you can spend an afternoon or two googling around to figure out wtf happened to sound AND video during a routine install of Debian and call that "progress*," you will think the hack for making Quicktime fullscreen for free is a snap.

Eh, shit happens. But that's pretty irrelevant when we're talking about a mac. The clueful will figure it out, but most people are not clueful. Most people are fucking lames. Which is why the mac has one button:D (sorry, couldn't resist)

Surely you meant "On the other hand, if you've never heard of vlc, you're one of maybe 95% of computer users."

Most people have never heard of VLC, because they don't live for their computer. They actually do other stuff, and don't care to go finding software like this. I've mentioned it to a few people, and none had heard of it.

Surely you meant "On the other hand, if you've never heard of vlc, you're one of maybe 95% of computer users."
Most people have never heard of VLC, because they don't live for their computer. They actually do other stuff, and don't care to go finding software like this. I've mentioned it to a few people, and none had heard of it.
Slashdot != normal people

Actually, I was talking about slashdotters, of which he is one. As you point out, this is slashdot. VLC releases hit the front page. He should really

the application for this second bug is not even shipped on Mac's by default! Meaning that this completely 3rd-party software, if installed onto a Mac, can cause problems with the Mac. And this is Apple's problem how, exactly ?

I was going to use a stronger word, but my New Years resolution is still (diminishingly) in effect...

If Apple don't supply a piece of software, it is *not* their fault that there can be subsequent problems using that piece of software, it's the program-author's fault. Obviously vlc isn't completely necessary (otherwise I would have it installed, I install a fair amount of linux-related s/w). I do have windows-media player and realmedia player installed...

To say that just because Apple don't supply a particular feature (viewing movies that require codec XXX), it's Apple's problem when you install 3rd-party software that does is just... wrong. I can't think how you could think that. It's hard to construct an argument when your starting premise is just nonsense.

By the same logic, it's Apple's fault that:

- I can't run my FPGA-mapping software on my Mac Pro, because Xilinx don't support the Mac. Apple ought to do something.
- I can't run any game I want on the Mac. Curse those game-producing companies, oh no, wait, it's Apple's fault.
- My Mac doesn't make toast! How simple is making toast? Apple ought to pull their finger out!
- ad nauseum.

Moan like buggery (*) (hmm, unfortunate turn of phrase:-) that QT doesn't support the codecs that you want, but it's not Apple's fault that other 3rd-party codecs have bugs in. Yes, I'm a Mac fan, but not a fanboy - I completely agree with bug #1, but this is just completely... bogus.

It's not shippped on Macs by default - but, by the virtue of it being the ONLY way to play some popular video formats on Macintosh, I'd say it may as well be installed by default.

That's just plain wrong - I don't use it much myself because I simply have used codec packs that install into Quicktime, for things like Divix videos and WMV9. What codecs were you thinking of that you can't load this way?

A more meaningful though still questionable bug would have been in a Divix codec pack for Quicktime. I would

Quite right. For all the talk of how Windows and Mac just work, it takes at least a full day to install a Windows machine with a full developer's suite of tools, virus scanners, etc. If I'd just had all the software made into a slipstreamed disk it would have been one thing, but you can't SSH from Windows, can't write Perl or Ruby, can't play any non-WMV video format more recent than MPEG2 without a special codec pack you have to download from a Russian site... Of course, you don't have the benefit of publi

"it is interesting to note that vulnerabilities in cross platform applications may transfer more easily to the Intel-based Macs running Mac OS X..."

You appear to have completely missed the phrase "Both x86 and PowerPC versions are provided." in the reproduction steps section. The problem is that, like many people these days, you see an apparent coincidence (that both use the same architecture, even though it's a false observation) and assume causality. If you write code with a buffer overflow and compile it

I think that the program must explicitly set a new userid; the real, effective, and saved userids are not changed by the permissions on the file. The file permissions merely allow these functions to be called, they do not change ownership - this must be explicitly done in C. I can verify this in my Stevens book if you want.

So... without help in the Safari binary, it will not be running with less privilege regardless of the permissions.

For a program to change UID/EUID to another user, it needs to have superuser permissions. We're not going to gain in security by making Safari setuid-root or encouraging someone to browse the web as root (most likely).

Making Safari setuid via the filesystem requires fewer changes and no need for superuser.

For a program to change UID/EUID to another user, it needs to have superuser permissions. We're not going to gain in security by making Safari setuid-root or encouraging someone to browse the web as root (most likely). Making Safari setuid via the filesystem requires fewer changes and no need for superuser.

For a program to call setuid(), it needs to have superuser permissions. For a program to be made setuid via the filesystem, you have to invoke chmod via "su". Unless you make the program setuid-root, it cannot change the user information to some arbitrary other user.

I realize that the idea is just catching on in IE and has not been implemented anywhere else, but why doesn't Safari setuid() the rendering engine to guest (or some other nonprivileged user)?

First, let me make one point clear. This is not "just catching on in IE", it has been used for running potentially exloitable applications in UNIX for decades. It's a last resort when applied to interactive programs... it's usually used with applications that are running unattended and providing services to the outside

From the other thread, it appeared that no Mac owner posted saying that they had been able to replicate the results - the people that did post results said the quicktime file given crashed Quicktime, but did not run the payload target. Simply being able to crash an application is not the same as actually executing arbitrary code.

I finally got a chance to try the exploit on my own Macbook Pro, where it did not work.Given that the Ruby script is slightly flawed, how are we to assume that they are even capable of coming up with a real exploit instead of just crashing applications?

Month of Apple Bugs, indeed! Given the second bug (an error in VLC! Oh My!) I think the whole effort is going to backfire and point, correctly or not, as a shining example as to the lack of serious problems in OS X itself (unless they are saving something

I bet they find the Mother Of All Bugs during the Month of Apple Bugs. Will S. Jobs have to take Management Of Aggressive Behavior classes so as not to snap under the strain? I sense the Mother Of All Battles coming from the Apple fanbase.Microsoft Often Anticipates Bugs, but they have a "fix it after it shows itself" policy. Maybe Our Apple Boys will take security more seriously now.May Omnipotent Allah Bless their efforts.

I just verified myself - the proof of concept exploit for the bug that was actually an Apple bug did not work. Crashing Quicktime is not the same as an exploit that executes arbitrary code, obviously an actual exploit is more complex than he thought. Or perhaps I should use the phrase "Imagined" since we have yet to see a single post from a user that got the exploit to work.

Someone, I think it was Macslash reported that a few machines got the full exploit, while most simply got the crash. Crashes aren't good, but they're hardly arbitrary code execution, either.

Also - I seem to remember hearing that the newest intel chips have hardware protection that prevents the execution of code loaded into data buffers (i.e., buffer overrun attacks) - could that have an effect?

Someone, I think it was Macslash reported that a few machines got the full exploit, while most simply got the crash.

I've posted on Macslash, and Digg as well looking for anyone who can reproduce the results (and now have tried it myself on my own Macbook Pro) - I have yet to see a post saying it works on thier computer. On the website they have a shell exploit version which they gaurantee works "but you have to verify with a debugger". to the naked eye, it also crashes Quicktime with no other result.

All this is a little fun exercise and a public service, if you will. Also, anyone can examine the code.

How do you uninstall these quick fixes? Simple. They'll almost all invariably be runtime fixes with Application Enhancer (APE) [unsanity.com]. APE modules are just self-contained directories; nothing more. They can be unloaded on demand, and APE itself can be easily installed, uninstalled, disabled, and modules can be loaded and unloaded at will.

Also, Landon Fuller is anything but an "Apple fanboy", or in any way remotely interested in "saving Apple's rep". The idea is to look at the bugs, and see if a quick technical solution or remediation can be provided. No one has to install them. Since the code is available, anyone can see what's being done, including the rest of the community. If one wishes to wait for Apple's official patches, fine.

Aside from all of this, of course Mac OS X, like any other operating system or large software project, has bugs. Some of these bugs will enable vulnerabilities that can be exploited. I fail to see how any of this is surprising. If you're actually interested, I've summed up my thoughts on this here [securityfocus.com].

APE isn't going to be necessary for ANY fixes from Apple. Apple will release their fixes in due course, and they'll be like all their previous fixes have been: normal updates to the OS that come down via Software Update, etc.

But since we can't directly fix Apple's code, this is a little technical exercise that fixes them with runtime patches. One very easy way to do runtime patches and code injection such as this is to use APE.

Also, APE is *very* easy to uninstall. It has its own uninstaller right in the installer, which will, categorically and definitely, uninstall every single last thing that has anything to do with APE.

All this project is is just that: a project. The community is welcome to inspect all of the source code, and anyone is free to use these runtime patches. Yes, QuickTime, and VLC, and everything else that will be covered in MOAB will be fixed by Apple and the various applicable vendors/developers. That is not at all the point of providing on-demand runtime fixes each day, and you have apparently totally missed the point of this projects, and the post you responded to where I pretty concisely explain it.

I tested thoroughly on Intel and PowerPC Macs. I wouldn't release a fix to the world without being fairly certain that it works correctly. You're welcome to review the code for the first fix -- it's about 10 lines. I'd be happy to explain the various entry points for you, too. We're using these fixes on all our Macs here at Three Rings Design.

Alternatively, you can not use the patch. I won't mind.

And how do you uninstall these quick fix hacks when Apple releases the legit fixes?

You open the Application Enhancer pref pane and hit the "-" (minus) button.

Nothing is hidden, and Landon isn't trying to hide anything that's being done.

Also, these fixes are runtime fixes via APE [unsanity.com] modules. They only place they're "installed" is into APE, so they can all be easily removed/disabled at will (as can APE itself). There is nothing wrong with the principle of runtime patching, and this is really a technical exercise more than anything. But again, the code is all right there, and you can see exactly what is being done.

Worst possible response. Are you suggesting that all Apple users become professional software developers? My girlfriend has trouble getting iTunes to work correctly. I don't think that the source code would mean anything to her. And no, I would NEVER suggest installing any Apple fixes that are not directly from Apple. I wouldn't care if it was Linus Torvalds, himself that was posting fixes.

Worst possible response. Are you suggesting that all Apple users become professional software developers?

Talk about an exaggerated response. Nobody's telling your girlfriend to look at source code or become a professional software developer. Source code is available for those smart enough to understand it, and if anything bad is in it, the community would be warned.

Sure it is, especially when the code is peer-reviewed and fixes a security problem that could theoretically invite malware.

It's just like not taking the polio vaccinations because you've heard they might cause HIV as a western plot [wikipedia.org] even though there's no evidence and no rational mind would think that. Sigh, I wish I was kidding about that.

I'd give you odds that 50 people with the experience to know what they're doing downloaded it. Since it comes from a trusted source (a developer), and is promoted by another trusted source (Security Focus), and other people have downloaded it without issue, and others have looked at the code without issue, I'd say it's as safe as can be.

Are you suggesting that all Apple users become professional software developers?

They don't need to. They just need to know someone they trust who is competant to read the source. It doesn't even have to be someone they know... for example, if source this small was crocked there would be approximately two thousand posts in this discussion pointing it out. So, really, "all Apple users" just have to know someone who they trust who knows where to look.

But the source code is meaningless as a guarantee of nonmaliciousness (intentional or unintentional) unless you compile the code yourself. Because that's the only way to know that the "fix" you install matches the source code.

JoeBlow isn't going to be able to compile the code himself. So it doesn't really matter if JoeBlow sees that some guy claiming to be a software dev on the net reviewed and ok'ed the code.

But the source code is meaningless as a guarantee of nonmaliciousness (intentional or unintentional) unless you compile the code yourself.

Or you can get a copy from someone trustworthy who has done so, or you have someone trustworthy verify that the executable matches the source, or... the point is, the source code allows you to build a stronger chain of trust for the software. For any software, whether it's a fix or a game... after all, the same argument about installing a security fix from anyone but Appl

They are exploitable if you make the target visit a webpage you scripted that contains the exploits. Which is not that hard if you send a link in a personal message to someone who knows you (a virus could harvest email addresses/names from your computer and it will look like coming from you): "Hey Bob, our office party pictures are online here. Love, Jane"As I understand it, the Quicktime bug of yesterday is particularly bad since it will load automatically without asking if you wish to run it first.

It's not as dangerous as a bug which requires no interaction whatsoever, but it's common enough for people to boink on random links that the risk level of that exploit could be fairly high. It will be interesting to see whether malicious exploits appear widely for any of these Mac bugs, and how quickly they spread if so...

Windows is a much more attractive target due to the large number of possible exploits, users that don't patch their systems and a huge install base. Certainly on the money making side of spyware and bot nets, the Mac is still not a very interesting target.Even were a Mac virus or worm to hit the wild, the rate of propagation would likely be a lot slower than on Windows due to the fewer systems out there.

Certainly it's true that there have not been major outbreaks targetting Mac users for financial gain, but some of the more recent games like sniffing mail passwords in an internet cafe and then holding the account's email contents hostage would affect Mac users just as they would a Windows user.

One is the month of bugs. The other is the moth of fixes, a response to the first and a different project by different people. You can at least correctly read the title of the article summary before declaring it a dupe. MOAB != MOAF.

You laugh, but most of this thread is people saying how the bug didn't work, mocking the guy. I'd rather patch a theoretical bug than sit around laughing with the fanbois over how lame it is the expect to find a bug in Apple software right until I contract my first virus. Mac users have drunk the "Unix is always secure" kool-aid. Heh.Just keep laughing, and please totally ignore all bug reports. If it was important, Steve Jobs would have called you personally - seriously, Apple service is just *that* good.