Slashdot Mirror

Using OS X/Mac since 10.2.8, I haven't seen another abused tool like "update_prebinding" even while it is a very risky process in pre 10.5 systems since it deals with actual binary headers.

Also thanks to uninformed IT blogs etc, people always considered prebinding a thing which will go away in next release. Like, Apple is really stupid to do such thing. They basically misunderstood the added flexibility to prebinding scheme where tools without (or broken) prebinding will continue to run.

Anyway, want to see how much Apple users are abused by some shareware developers? Just watch for a applescript to basically issue this command and asks for money or donation. I don't have 10.6 but on 10.5, in its FIRST line of man page (man update_prebinding), Apple states "normally, there shouldn't be any need to issue this command manually" or something equivalent to that. On pre 10.5, like 10.4.11, it can get catastrophic if you keep doing it, as explained on article http://unsanity.org/archives/mac_os_x/shock_and_awe.php

Unless you lived a power loss in middle of a OS X/Quicktime update or kernel crash, there shouldn't be ANY reason to manually update prebinding. In fact, it can lead to a horrible cache fragmentation which may slow things down. Don't fix a working thing.

I tell you the real annoying bug. It erases cookies sometimes. Yes, the file itself (~Library/Cookies/Cookies.plist). It was documented by unsanity and said to be fixed at least on Intel but we, poor PPC users who made the mistake of jumping to Leopard still suffer from it.

http://www.unsanity.org/archives/apple/apple_hates_bug_filers.php

Ironically, it generally hits you when you report a bug to Apple, that is where the title comes from.

I had to restore 2.2 MB of cookies from Time Machine today.

That Cookie disappeareance has hit the OS X Leopard 10.5.0 Safari in a funnier way. Check that for details:

http://www.unsanity.org/archives/apple/apple_hates_bug_filers.php

The "Apple Hates Bug Filers" title is not flamebait, once you went to report bugs of your brand new OS with Intel Mac to Apple, your cookies disappeared literally. Of course, the "Time Machine" was to rescue (in case you use it). It is said to be hotfixed in later versions of OS X 10.5

I noticed it happened once to my PPC Mac on 10.5.3 , couldn't reproduce though. I wonder if your cookies vanish after random amount of time or you visit a specific site randomly?

Eh, you're not going back far enough. OSX was originally developed on Motorola 68K, and the Mach-O ABI still has reminants of it. But NeXTstep/OPENSTEP ran on 68k, i386, Sparc, and PA-RISC long before it ran on PPC.

Oh, and NeXTstep runs okay in 16M, but more is better. My 33Mhz 68040 does just fine with 32M, running what is essentially the same OS, on a 2GB hard disk.

An aside...Leopard really is back to the future when it comes to the interface. "Plastic" might as well be "NeXTstep."

I have no stake in this whatsoever but just wanted to share what I've stumbled across from Unsanity (Posted by slava at October 27, 2007 11:45 PM): Leopard!.
As always, YMMV.

Per Unsanity's web page, the current version checks. Previous versions don't. They say "Please accept our sincere apologies for all the trouble that was caused. We have underestimated the number of people running "outdated" versions of our software."
http://www.unsanity.org/archives/haxies/leopard.php

Personally, I think APE and the Unsanity haxies are %$^%$ and I stay as far away from them as I can!

Get this, Unsanity FINALLY sent out a message to those on their email list. This is their "sage" advice:

"First and formost. *Before* you install Mac OS X 10.5, make sure you have Application Enhancer (APE) 2.0.3 or later installed. You can download it from http://www.unsanity.net/ape-203.dmg (the webpage is at http://unsanity.com/haxies/ape ).

Make *sure* you have APE 2.0.3 or later installed *before* you install Mac OS X 10.5. If you have an earlier version of APE installed before you install 10.5, you may exhibit one of the following symptoms upon booting into Mac OS X 10.5:

- Your goldfish may die.
- A strange dog might bite you on the street.
- A friend may punch you.
- Your computer may catch fire.
- Your loved one may leave you.

All of these things are really bad. So we urge everyone to make sure they have APE 2.0.3 or later installed. If you aren't sure, install APE 2.0.3 or later from the link above. APE 2.0.3 was released on March 14th, 2007. And please, always keep your software up to date.

A note about 10.5 and haxies:

As long as you have APE 2.0.3, nothing bad will happen in 10.5. Well, nothing we can control. However, none of your APE Modules will work either.

Developers in Apple's Mac OS X developer program (ADC) got the final 10.5 GM yesterday. We are still downloading the huge 6.66GB image and as soon as the downloads finish for our developers, we will be hard at work on making our software work on 10.5.

You can keep up to date with the status of haxies and 10.5 by viewing http://unsanity.com/products/compatibility/ and we will post more information as we have it on our blog at http://unsanity.org/ . Mac OS X 10.5 compatibility is currently our number one priority.

"If APE doesn't work in 10.5, shouldn't I just uninstall it?"

No, you should not. Just make sure you have APE 2.0.3 or later. A lot of third party (and Unsanity made) utilities depend on the APE framework itself being there. As it has some extremely useful functions. Removing it may cause these Applications and/or preference panes to stop launching."

They tell you specifically NOT to do the one thing that you probably should do. Worst of all, they try to be funny while doing so.

Saying it was delayed it slightly inaccurate since Apple has been saying Spring '07.

Forum advice was to run "repair permissions", I did but it didn't help.

It didn't help because the people who gave you that advice are imbeciles who believe in voodoo. It was able to help with occasional problems caused by Classic and bad installers circa OS X 10.1, but there are hardly any circumstances where it will make any difference to anything on more recent versions, as explained here.

http://daringfireball.net/2006/04/repair_permissio ns

http://daringfireball.net/2006/04/repair_permissio ns_voodoo

http://www.unsanity.org/archives/000410.php

Why do Mac users not listen to these guys?

The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins. So a local admin can replace the APE executable and gain root privileges. Read that again. A local admin can replace the APE binary to gain root access.

A local admin, an effective root user account, can gain root access.

Or they could open up NetInfo Manager and enable the root account and enter in a password of their own choosing and then log into the GUI as root. Or they could open up Terminal and run sudo sh and get a root shell.

This is simple revenge. Rosyna called them trolls and linked to an APE fix for one of their bugs. I think Rosyna may be right of the 9 published bugs, 4 of them are not from Apple provided software.

This is scaremongering at its best. Nothing to see here, move along.

I disagree with "at its best". The example "exploit" installs what basically amounts to a rootkit. So, in other words, this security "researcher" is distributing malware that gives him access to anyone's computer that accesses it. Since when do real security researchers distribute malware? More information is in the comments here.

Not to mention he posted this thing with nothing but malice. It was done because Landon Fuller refused to work with LHM. LHM wanted to keep the bugs from the developers and said as a condition of such working together, that Landon Fuller must not tell anyone else about the bugs.

Ugh. :-(

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.

Also, there is nothing wrong with APE, and here is a very detailed explanation of exactly what APE is and what it does.

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 just tried this on my MacBook Pro using the provided QTL files and ruby scripts, but none of them seem to have the claimed effect. Anybody else already tried this?

I could not. And only one person I know could. Other people had to heavily modify the script and run QT Player in gdb along with some other voodoo to get it to exploit properly. Doesn't seem like this will cause much harm.

Either way, a third party developer already fixed this crasher.

I tracked down the issue and created a runtime fix using Unsanity's Application Enhancer. The overflow is in the QuickTime Streaming component's INet_ParseURLServer() function -- the fix patches that function and pre-validates the URL before passing it off to the real function implementation. If the URL is too long, the patch replaces the Evil URL with a benign, but invalid one, and then calls the original function.

It's worth noting that disabling RTSP, as noted elsewhere, is not sufficient -- there are other vulnerable entry-points to INet_ParseURLServer(), as it is used for generic URL parsing.

More information is available here:

http://www.unsanity.org/archives/mac_os_x/the_mont h_of_trolly_trolls_and.php

and the patch (with source!) can be downloaded here:

http://landonf.bikemonkey.org/code/macosx

You can test the fix (make sure to log out and log back in after installing APE!) in Safari (or Firefox) by visiting this URL:

http://landonf.bikemonkey.org/static/rtsp_crash.ht ml

If you're using Safari, QuickTime should display a "bad address" error once the patch is installed. If the patch isn't installed, Safari will crash.

The biggest "casual" overhead of Aqua/Quartz on older machines is the "shadow" around windows. There's an application extension (APE//Haxie) called "shadowkiller" that removes the shadow and significantly improves response time on older Macs.

http://unsanity.org/

(no relationship, just a former user of shadowkiller)

Here's what I know of and/or could find for the ones I didn't.

• Aaron Hillegas
• Adam & Tonya Engst
• Amit Singh
• Andrina Kelly
• Andy Ihnatko
• Ben Wilson
• Brent Simmons
• Dan Frakes
• Danny Goodman
• David Pogue
• Drunkenbatman
• John Gruber
• John Siracusa
• Jonathan "Wolf" Rentzsch
• Josh Wisenbaker
• Michael Bartosh
• Mike Breeden
• Nigel Kersten
• Ray Barber
• Ric Ford
• Rich Siegel (Bare Bones SW)
• Rob Griffiths
• Rosyna Keller
• Scott Knaster
• Wil Shipley (Delicious Monster)

Unfortunately, it seems that Slashdot has a limitation on the minimum number of characters per line. So I can't just create a nice, simple list, but instead need a significant amount of text to pad out the list, so that I can make it past the filters being used. But I'm still not there yet... sooner or later I will (20.4 is still too few). I'm probably going to have to type a whole lot of crap in here just to deal with the 25 names that are only a few characters each. (and I tried removing returns from the message, but it didn't seem to help at all)

Indeed. Luckily I was there for the first failure. I hope I can be there for the second one as well. OMGWTFBBQ?!

But I hear Japan is humid as all hell in the summer.

AC: First off, the PowerPC does not have a PC register.

right .. but the m68k did, so i guess what i meant was, whether they've changed all that in subsequent releases.. well, i did some google, and came up with this interesting Unsanity article on the subject of the Mach-O ABI, which may be where i got my dim memory of this ABI issue in the first place.

wherein the following interesting statement is made:

This brings us the question, "how much faster would the applications be if the ABI was done right?". The answer is, according to some tests done by my friends on a Macintosh Development IRC channel, the speed gain would be 10-30%, depending on each particular application (how often does it calls functions). Realistically, the speed gain would be around 10 to 12 per cent...

so there is still a chance for a major speedup of OSX on PPC .. but i guess with the switch to x86, this is being abandoned?

AC: Mac OS X never did anything with its ABI for 68k compatbility.

hmm:

Mach-O ABI we see now used in Mac OS X is more or less a direct port of NeXT's Mach-O designed for m68k - it relies on PC (program counter) register to perform various manipulations with data (for the geeks: PC-relative addressing). There's nothing wrong with that, as its an effective and common practice, except for one little thing: there is no PC register in RISC processors (programmatically accessible).

are we talking about the same thing? i guess its not m68k compatability here, but NextStep/Mach-O legacy which is the issue, at least for PPC (i'm assuming this is all different for OSX/x86).

AC: Mac OS X's ABI differed from OS 9's ABI in that OS X did not dedicate the R2 register to TOC register. Without doing anything special this resulted in a slight slow down in relocatable code, and a slight increase in leaf function code that was register limited (less frame spills). That would have hurt on Mac OS 9 (where everything is relocatable, and in one big address space), but was not a big deal on OS 9 where all applications are located at address 0 and are non-relocatable.

Additionally, if you really care you can ignore ABI pretty blatantly so long as none of the functions are exposed, or you provide thunk entry points. You could setup R2 based entry points, maintain your R2 pointer, and then have wrapper entry points that setup R2. That results in using exactly the same code sequence as OS 9, except the code that sets up the TVector in OS 9 is now in the wrapper entry point (and I mean basically instruction identical).

i'm really not sure where OS9 comes into this question. my understanding is that the Mach-O ABI, being derived from NextStep for m68k, is the reason we're having this conversation, and that OS9 has nothing to do with it .. but then, i'm only a lowly C programmer who lets the compiler fuss about the plumbing, and for whom OSX is only one port target in many .. i never had anything to do with OS9, ack spit ..

but i guess i've got the answer to my question, anyway:

There are signs of change though -- the recent update to GCC, the compiler shipped with OSX, allows it to perform so-called -mdynamic-no-pic optimization, which hard-codes the data addresses in the code, so the result is roughly equivalent to the CFM ABI used in Mac OS Classic -- so the GCC itself, compiled with that optimization, is 10% faster. Applications, to take advantage of that, need to be recompiled, so it doesn't affect 80% of the titles already shipped for Mac OS X. Then again, the optimization above only works for executables and not shared libraries.

Either way, there is no way to change the ABI now, as it would break all of the existing applications - which is obviously not what Apple (or us) would want.

And after all, who cares about a 10% speed loss? You can always get a faster Mac, right?

yeah. always. by putting linux on the one i've got, i suppose ... ;)

Japanese mobile tech is at least 3 years ahead of everyone else. Vodafone just didn't get it.

And their toilets.. My god, their toilets

Paranoid Android has been updated in order to deal with this exploit. More info here. Of course, you need Unsanity's Application Enhancer (APE) for this to work.

I've updated Paranoid Android to be aware of this class of exploit. You can download it here or grab the source code and compile it yourself.

Note that Paranoid Android is an APE module. I like 'em, but it's something to be aware of.

Basic directions: Run the installer, log out, log back in, launch System Preferences and choose the Application Enhancer prefpane. Choose Paranoid Android. Turn on "Watch non-default application launches". Unless you're really paranoid, turn off "Watch URI schemes", since that class of exploit was fixed awhile ago.

Once you've done this, both the Safari exploit and the Mail.app exploit will trigger a dialog window telling you what's going on and giving you a chance to use the default application (Quicktime Player) instead of the custom one (Terminal).

Once Apple puts out a fix for this, I recommend ditching Paranoid Android - it's a pretty heavy solution.

More info on PA can be found here.

"For the record, Smart Crash Reports is not an Apple product. It is third-party software by Unsanity: http://www.unsanity.com/smartcrashreports [unsanity.com]"

For up to date info: They will now ask whether user needs to report the applications crash to developer or not. How evil the developers are asking anonymous, already sent to Apple by default crash data! :) (This is my take, I am not affiliated with Unsanity except buying/using their products)

http://www.unsanity.org/archives/000447.php

If Apple shared crash reports of Applications with developers, there wouldn't be need for such software. It is in fact a great favor to community and developers asking NOTHING at return. They give a very expensive functionality for free. Ask Netscape Inc how much they paid for talkback agent or similar companies.

I was naively sending crash reports to Apple which they don't really care if it is not their software or OS crashes with full descriptions for 2 years. When I figured even Adobe sized companies doesn't get them... Well you know...

That blog guy (grandparent mentions) did not mention any of these facts I bet. That is what I hate. I even shared some "interesting technology news" with Unsanity and they responded, they are a responsive team which does/did great favors to community asking nothing in return. To hell with his "famous" blogs Google whatever ads really.

Yeah, even I wrote one such "review". But never said it cooked (other than maybe the extra heat...)

http://www.unsanity.org/archives/000410.php

I think it looks a lot more like Safari.

IE7: http://www.flexbeta.net/gsurface/ie7/ie72.jpg

Safari: http://www.unsanity.org/rosyna/imgs/safarirss.png

Pretty much identical. Actually looks like MS is trying to figure out how to organize the right area so it doesn't look like such a blatant ripoff.

It's non-trivial to get off of CFM and move to Mach-O,

It would also be very non-trivial for Apple to port the CFM ABI from the PowerPC Processor to the Intel processor. The ABI specs assume that there is a PowerPC underneath. With the Mach-O ABI, the entire ABI is optimized for being on a CISC processor. See this blog (from a developer) for more info

I'm with you on that. It can't be THAT hard for the OS to scan a keyboard, notice extra non-Standard (all the normal QUERTY bits that are SUPPOSED to be there) keys and offer them up for remapping.

Well, the problem is that the extra keys on a USB keyboard aren't keys,they're system control endpoints. But, yes, there are standards for all of them and they all have descriptors that describe them. It should still be able to put up a list of system control buttons and let me assign events to them.

And what I'm talking about is something even deeper and central to the system, and that's hotkey management in general, whether they're standard keys or not. There's no central place that lets an application say "I'm prepared to accept the following named events, and here's my preferred key bindingd for them" and then let the user say "when this keystroke comes in, send this event to this application".

There's PART of that, for the CMD-foo keypresses, you can bind them to menus and things when you're in an app. But the usual hotkey API is an undocumented set of Carbon calls that probably seeped in from classic Mac OS. That's the part that should be centrally managed, so you could bring up your hotkey manager and see Key=F11 - Shift=none - App=Expose - Cmd=Show Desktop and go down to Key=Unknown (%F6) - Shift=CMD - App=Expose - Cmd=Show Desktop and get Expose action from the otherwise unused "Menu" key on your Windows style keyboard.

Connecting that to your post, you should be able to go down further and select Key=Unknown (System Control 6) - Shift=any - App=iTunes - Cmd='set playlist to "Party Shuffle"'.

And of course you should be able to click "enter key" and hit the "search" key on your USB keyboard and find yourself looking at Key=Unknown (System Control 3) - Shift=none - App=Safari - Cmd=open http://www.google.com.

Okay, I did a little google, and here's what I found. Hopefully it will provide you with some further insight into what I'm talking about:

Unsanity.org article about the Mach-O ABI

Hey, don't do that! He said he couldn't find it on Google as it was.

So instead, repeat after me:
teletubby-like Rosyna

I don't know what that's about, Rosyna looks pretty ordinary to me....

This exploit and this exploit still work under OS 10.3.4. I do not have any 3rd party security software, I did uncheck the open safe files after downloading checkbox in Safari preferences.

Doesn't seem any slower or faster.

Most importantly, it looks like some of the URI handler problems/security holes are now patched as well. I had uninstalled the "Paranoid Android" Haxie before the update (to make sure there weren't any install issues) so it was no longer running.

It looks like none of these exploits seem to work any more after the 10.3.4 update.

Nice work,

DaveC

The sometime slugishness of the OSX Finder has been attributed by some to the fact that it was written in Carbon. There are some interesting discussions on this around the net.

So, are the changes to the Finder in Panther just an update or has it been re-written using the Cocoa APIs?

No matter how off topic this is, I must correct some things in the above...

1. Mach-O isn't specific to Apple. That is correct. However, Apple could have chosen to use the CFM format as the native executable format when they designed Mac OS X. That would have made a pretty significant performance increase to typical applications. See Slava Karpenko's article on the subject.
2. This is correct.
3. KDE / Gnome may be as ready for the _enterprise_ as Aqua. Ie, if they are set up by someone who knows all the requirements of the organization that is going to use them, and makes sure as much as possible is pre-configured. On the other hand, they are no where near as easy / pleasant to use as Aqua.
4. NetInfo is a heritage from the NeXTStep days, and something that Apple is moving away from (abstracting it using Directory Services, layered on top of for example LDAP and NetInfo). It has nothing to do with Classic compatibility.

Carbon is faster than Cocoa, but Cocoa is easier than Carbon. You should read this tiny article.