Nick Wingfield with The Wall Street Journal gets confirmation that a plan is in place for Apple to remotely kill certain iPhone / iPod touch applications if they are found to be malicious.

Mr. Jobs confirmed such a capability exists, but argued that Apple needs it in case it inadvertently allows a malicious program — one that stole users’ personal data, for example — to be distributed to iPhones through the App Store. “Hopefully we never have to pull that lever, but we would be irresponsible not to have a lever like that to pull,” he says.

Security Update 2008-005 fixes the BIND DNS cache poisoning vulnerability by updating BIND to 9.4.2-P1(Leopard) and 9.3.5-P1(Tiger). Also of note, this update addresses the OSA privilege escalation issue by not loading scripting addition plugins into applications running with system privileges. Other items affected by this update include CarbonCore, CoreGraphics, Data Detectors Engine, Disk Utility, OpenLDAP, OpenSSL, PHP, QuickLook, and rsync.

Read the full details here.

UPDATE: Andrew Storms at 360 Security points out that port randomization failed to make it into this security update. Port randomization is the currently accepted countermeasure to prevent DNS cache poisoning of BIND.

Apparently, the Aurora Feint game would send your contact list unencrypted to the company’s servers. Hopefully the developers will fix this properly and get their game back in the App Store.

Dino Dai Zovi has a fairly comprehensive list of the security-related features he hopes Snow Leopard will implement.

• Real ASLR (address space layout randomization).
• Full use of hardware-enforced Non-eXecutable memory (NX).
• Default 64-bit native execution for any security-sensitive processes.
• Sandbox policies for Safari, Mail.app, and third-party applications.
• Mandatory code signing for any kernel extensions.

Read the rest of the article for more details.

Intego is reporting that Apple Remote Desktop (specifically ARDAgent) is vulnerable to a root exploit.

This vulnerability takes advantage of the fact that ARDAgent, a part of the Remote Management component of Mac OS X 10.4 and 10.5, has a setuid bit set. Any user running such an executable gains the privileges of the user who owns that executable. In this case, ARDAgent is owned by root, so running code via the ARDAgent executable runs this code as root, without requiring a password. The exploit in question depends on ARDAgent’s ability to run AppleScripts, which may, in turn, include shell script commands.

The example that is circulating the internet is shown below:

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'

All my computers have Screen Sharing or Remote Management turned on, and in this case, the above example fails. However, after killing ARDAgent, I was able to get the example to return “root”.

A solution offered by some is to simply archive the ARDAgent.app so that it cannot be used.

cd /System/Library/CoreServices/RemoteManagement/
sudo tar -czf ARDAgent.app.gz ARDAgent.app

Another solution is to change the permissions on the ARDAgent:

sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app

If you choose to change the permissions, do not run Repair Permissions, as it will undo the fix.

Apple has released Security Update 2008-0002 today. The details can be found here. The update is available via Software Update.

Numerous fingerprint “protected” USB sticks on the market purport to allow access to a protected portion of the flash memory only when the proper fingerprint is detected. It turns out that bypassing this “protection” is fairly simple.

All you need to do is use the PLscsi tool to send a single USB command – Command Descriptor Block – to the stick for access to the public partition to be replaced by access to the protected one.

(via heise security)

The latest exploit affects both Macs and Windows machines. The vulnerability lies in the way FireWire handles Direct Memory Access (DMA). Theoretically, this exploit could be extended to other I/O that use DMA.

This exploit is apparently not new, but is receiving more attention due to the recent memory attacks demoed by a few Princeton students.

If this exploit gets a lot of attention, will this mean an overhaul of FireWire, a mass abandonment of FireWire, or nothing at all? One argument that is voiced quite often in such situations is the one of “physical access”. It is true that a computer can be exploited many different ways if the attacker has physical access to it. Does this mean such exploits should be downplayed? Not at all.

PayPal has advised its customers to avoid using Apple’s Safari browser, because it lacks some anti-phishing features that some of the other browsers have. Safari also lacks Extended Validation (EV) certificates.

While these anti-phishing measures make users feel warm and safe, they are not the “end-all” of web exploitation. The only person who can fully insure one’s own security is one’s own self. It is only a matter of time before phishing sites exploit the anti-phishing measures and appear as legitimate sites.

The best protection against phishing is to not click on any links in emails to banking sites. Also do not click any link in an email that is asking you to verify your “details”. No legitimate site will send you such an email. When you need to visit a secure website, be sure you arrive there by typing the address yourself. Smart web browsing is better protection than trusting your security to a safety net that you haven’t checked for holes.

A group of Princeton computer scientists has published a paper(pdf) demonstrating a method for accessing a computer’s memory to gain access to encryption keys. Contrary to popular belief, RAM contents are not immediately erased once a computer is shut down. It can take 2.5 to 35 seconds for the data to fade away. This time can be extended by exposing the RAM chip to extremely cold temperatures.

Microsoft’s BitLocker, Apple’s FileVault, TrueCrypt and dm-crypt all seem to be vulnerable to this method of attack.

There seems to be no easy fix for these problems. Fundamentally, disk encryption programs now have nowhere safe to store their keys. Today’s Trusted Computing hardware does not seem to help; for example, we can defeat BitLocker despite its use of a Trusted Platform Module.(#)

via ars