escalation
Latest
App Store approval limbo boxes in Briefs
There are plenty of hurdles between a good idea and App Store success; even after your killer app hits the virtual shelves, the challenges of discoverability and competitors sandbagging your app with Astroturfed bad reviews add up to plenty of headaches. Still, once past the biggest stumbling block -- Apple giving a thumbs up or thumbs down -- things should get easier, right? Unfortunately, some intriguing apps end up in approval limbo, the stranded state between all-clear and no-thanks that's reserved for some of the most innovative and paradigm-busting apps; the apps that make Apple go "Hmm..." and force the app approval team to exercise the pocket veto. Without a clear rejection (telling the dev what can be fixed), there's nothing to do but wait. The most high-profile limbo case is Google Voice, which as far as we know is still being reviewed by Apple's team more than a year after it was submitted. The latest is Briefs, a well-regarded app prototyping tool which may be running afoul of the no-interpreted-code ban in section 3.3.2 of Apple's developer agreement, despite the assertion that Briefs doesn't work in a way that's forbidden by Apple's rules. Even though developer Rob Rhyne made a cogent case to Apple's team on the merits, and even with some high-level support from contacts made at WWDC, Briefs remains unapproved and unrejected. Rather than wait indefinitely with his 1.0 growing stale, Rhyne has decided to offer the existing version as open source, which iPhone developers can compile and install on their testing devices. Rob's colleague Jeff Lamarche at Martian Craft voices his frustration here. In many ways, this could be an App Store success story: developer dedication and innovation, open lines of communication between indies and Apple, an open source tool that can improve app development for scores of coders. The only problem is that darned silent treatment, and the missing timeline for escalation. If an app can't make it on the store, it seems the least Apple ought to do is say so and say why.
MAG's Escalation 3-way battles revealed
OK, we should get this out of the way up front, because it comes up every time we cover MAG: yes, it is an MMO. Massively? Well, 256-player battles are about ten times larger than those your average MMO can handle without lagging to hell and back. Multiplayer? Covered that. Online? Duh. Moving right along, Zipper Interactive's Jeremy Dunham has posted a new entry on the official MAG blog detailing the upcoming Escalation mode. The new game-type, which will be deployed as downloadable content in the near future, is a 96-man three-faction battle royale, the ultimate goal of which is to earn more points than your enemies before time expires. Points are earned by holding objectives, but unlike your standard "run to the flag and stand there for 20 seconds" capture model common to objective-based FPS titles, Escalation features a phased approach that encourages continuous frenetic combat. You can get your first taste of the new mode by downloading the MAG beta client from the Playstation store on August 24th.
ARDAgent setuid allows root access, but there's a sort-of fix
Updates: See the end of the post for current info. We've been getting quite a bit of email since yesterday's anonymous Slashdot posting of a security problem with ARDAgent on Mac OS X 10.4 and 10.5, and there's plenty of Twittering going on over the issue. Here's the deal: ARDAgent is the application that responds to Apple Remote Desktop remote administration requests, screen sharing and the like; you can find it in /System/Library/CoreServices/RemoteManagement on 10.5 machines. In order to go do the voodoo that you do so well when you're administering remote Macs, ARDAgent needs to be 'setuid root' -- it needs to run with the privileges and access that belong to the system administrator, the same way you do temporarily whenever you unlock a system preference or install an application with Apple's installer. This is normal and expected behavior. What's not so normal and expected is that ARDAgent will execute the 'do shell script' AppleScript command (on behalf of remote admins, normally, who need to run Unix commands from time to time). The problem here is that since ARDAgent is setuid root, any subprocess it launches is running with administrator permissions, and in fact with the right malicious scripting here it would be possible to do a great deal of damage. Granted, in order to activate this vulnerability the attacker would either have to be at the machine, or logged in remotely with the same account that is currently in use... or just convince the user to run a malicious downloaded application. Yikes. The good news is, there's a very simple workaround (courtesy of the fine folks at Intego -- note that if you actually use VirusBarrier to disable ARD's shell script access as they recommend, and your machine is managed remotely, your administrator may take some umbrage). It turns out that if ARD's remote access features are turned on, via the Sharing pane in System Preferences, you're clear. Even if there aren't any users permitted to administer your machine, the 'do shell script' command that ARDAgent runs is neutered and cannot be exploited in this fashion. Most home and small office Macs wouldn't normally have this turned on, but once you activate it you should be protected. Our basic instructions can be found here. [See update below -- turns out the fix may not protect you fully.] Stay safe out there! Update: Thomas Ptacek of Matasano weighs in on this flaw and offers some additional workarounds, but he doesn't seem overly concerned. Update 2: Commenter (and Mac OS X security pro) Zack Smith, along with Chris Barker, points out that it's possible to kill the ARDAgent process and immediately run the osascript command, which bypasses the protection that running ARDAgent under launchd provides. Under those circumstances an attacker or someone sitting at your machine could still run commands as root, much to your chagrin. To prevent this, one approach is to change the permissions on the ARDAgent application bundle -- note that this will both break with future system updates or permissions repairs, and may adversely affect administrative access to your machine from legitimate managers: sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app You can also simply archive and remove ARDAgent.app if you don't plan to be managed by anyone. Thanks to everyone who sent this in, and thanks to Intego for pointing out the workaround.
