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.

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.

If you were to ask people if they felt vulnerable to phishing scams, they would most likely tell you, “No.” However, if phishing emails were not profitable to someone, our inboxes would not be filled with them.

I get a lot of phishing emails, and for the most part they are for companies and services that I don’t use. That in itself is a dead giveaway that the emails are bogus, but occasionally I will get an email from my own bank, or paypal that cause me to stop for a moment and look a bit closer.

The first thing I always do is see where the link goes. This is a good practice get into. The problem with these URLs is that the first part of the URL, the subdomain, is formed to look legitimate. However, if I hover my cursor over the link, I will see the real destination of the URL, instead of just what the phisher wants me to see. Notice the text in the yellow box is where the link will take me if I click it. You can see that the http://adwords.google.com part is the same, but continue looking past that to the right, and you will see that that is simply a subdomain to u40o36.cn . In this particular example, this is a Chinese top-level domain. I just want to make it clear to everyone that no matter how “official” the subdomains look in the URL, it is the top-level and second-level domains that you should be aware of.

A good practice is to avoid clicking the links in emails such as these. If you need to log into any online account, you should type the address to that account yourself.

One other note: don’t allow software that is supposed to protect you from such scams to cause you to become less vigilant. No protection is 100%. Stay aware.

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.

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

This article on Digg caught my attention, but in the end turned out to be less interesting than I had expected. To cut to the chase — Don’t trust the information in your caller-ID. The interesting part came from a commenter:

I was a victim of this caller id spoofing just last week. Bank of America VISA called me to ask if I used my card at an ATM machine across the country to get $880 in cash about 6 or 7 times that morning, for a total of over $5,000 cash with-drawl. Apparently someone made a fake VISA card using my number. Here’s the spoof part: VISA lets you change your pin over the phone, and does not ask any security questions. Their computer “sees” that you are calling from your home phone (which these spoofers can do somehow), and then they let you just change your card pin number right over the phone. The thief then went to the nearest cash machine and had fun. I wasn’t liable, but I did ask the head of their fraud unit why in the world they don’t require “live security questions” if they knew that this phone spoofing technology is out there. They said they are “working on it”. I wonder how we can ensure that they change this policy quickly. In the meantime, I was told never to use your home phone number - use your cell as the contact number. Think about how many times you order things online, using your credit card and phone number. This stuff is really frightening.

I have activated many new credit/debit cards in this way, and never thought twice about the fact that the banks are using caller-ID to “verify” the identity of the person calling. The banks need to get a clue! This is not a secure and reliable method of checking the caller’s identity! As far as changing PIN, there are probably more questions or verifications than the commenter above would have us believe, but as for activating a card, I don’t remember any such questions.

[UPDATE: Apparently, using "ANI Skip Tracing", the true number of a blocked or spoofed caller-ID can still be retrieved.]

When Computerworld says it’s a “brick”.

Computerworld is reporting that an exploit has been found that affects HP and Compaq computers and results in the computer being “bricked”. According to the article, “the Software Update bugs let an attacker corrupt Windows’ kernel files, making the laptop unbootable, or with a little more effort, allow hacks that would result in a PC hijack or malware infection.” The exploit was uncovered by a Polish security researcher who used the alias “porkythepig”.

When I hear the word “bricked”, I imagine a scenario where software has rendered the hardware completely unusable and unable to be restored to a usable state. This can sometimes happen when a firmware update fails ungracefully. However, the exploit that Computerworld is referencing can be fixed with a re-install.

Heise Security is reporting that a vulnerability has been found in the load_threadstack function in mach_loader.c when processing Mach-O binaries, which can lead to a kernel panic.

Single user systems should not be at risk as the bug can only be exploited by users logged onto a system. The bug does, however, represent a problem on multi-user systems, as an attacker does not require any special privileges to provoke this error. The vulnerability is present in Mac OS X 10.5, 10.5.1 and 10.4.11. No patch is presently available, but an exploit for testing is.

Over the past week some Mac sites (four that I know of) were defaced by someone calling himself “malcor”. This, in turn, brought about some panic in the security and Wordpress communities. A couple security firms blogged about the incident (Avert Labs, Blogvis.com) which only served to increase the awareness/panic.

The so-called hacker named “malcor” was actually a fictional character created by MacHeist to promote their upcoming MacHeist II shareware distribution. John Gruber wrote an interesting article last year documenting what some might consider “shady” business practices. Last week’s events only serve confirm the foolishness and selfishness of the MacHeist team.

Apologies can be found here:

• MacHeist.com
• MacApper.com
• GlennWolsey.com
• AppleMatters.com

Stunts like this do nothing but tarnish the Mac community, and scare off potential Mac adopters. This I’m sure has also resulted in bad PR for some hosting companies and CMS providers such as Wordpress.

My recommendation to all is to avoid supporting organizations like MacHeist. Do independent developers a favor and support them by making donations directly to the developers and/or paying them for licenses.

Update: It seems that others share some of my sentiments:

• Tea Leaves
• Someone Else

Secunia has issued a security advisory (SA27755) for a buffer overflow exploit in QuickTime and has labeled it as “extremely critical”.

The vulnerability is caused due to a boundary error when processing RTSP replies and can be exploited to cause a stack-based buffer overflow via a specially crafted RTSP reply containing an overly long “Content-Type” header.