"This is not over. There's going to be quite a few modified Twitter worms for a day or two. Be careful in Twitter, don't view profiles, don't follow links. It's beautiful outside, maybe go for a walk instead?" Mikko said on the F-Secure blog earlier today.

"I am the person who coded the XSS which then acted as a worm when it auto updated a users profile and status, which then infected other users who viewed their profile. I did this out of boredom, to be honest. I usually like to find vulnerabilities within websites and try not to cause too much damage, but start a worm or something to give the developers an insight on the problem and while doing so, promoting myself or my website."

We wrote about StalkDaily yesterday, and last night Twitter pointed out on its status blog that it has "taken steps to remove the offending updates and to close the holes that allowed this 'worm' to spread." The offending code can be found at GitHub as noted by Mr Speaker who left a message in our comments, and a postmortem of yesterday's vulnerability can be found on the DCortesi blog.

Clearly Mikeyy is still bored as the new version is now making its way across the Twitterverse, tweeting comments such as: "Man, Twitter can't fix shit. Mikeyy owns :)"

So if you see a tweet with the word Mikeyy - don't click on it.

F-Secure is reporting that all of these attacks are Javascript based and suggests turning it off. You can find instructions on how to turn off JavaScript in the four main browsers; Firefox, Internet Explorer, Safari and Opera at Tucows.

If you need to remove Mikeyy, Twittercism walks you through in six easy steps.

We'll keep you updated as the day progresses.

The current vulnerability is contained in code written by the software company PacketVideo who contributed an open version of their Core multimedia application framework to Android, where it became the multimedia subsystem for the Android web browser.

Once discovered, Miller notified Google of the flaw on January 21st. When Andy Greenberg reported on the issue for Forbes last week, he quoted a Google spokesperson as saying that a fix will be issued "as soon as it becomes available."

Strangely though, a fix is currently available and has been since February 7th. However, Google has not pushed it out to Android phones. Instead, the patch sits here in Google's source code repository which, says Miller, is "irrelevant" as "what matters is what Joe Consumer is carrying in his pocket." He also wonders why Google waited for PacketVideo to contribute the code when it was something Google could have very easily - and quickly - fixed for themselves.

So, No News is Good News, Right?

If you're wondering why you haven't heard about too much about this new exploit until now, it's not because it's only marginally dangerous. Since it would allow a hacker full control over the browser and related processes, Miller recommends that Android owners actually "avoid using the browser until a patch is released.  If this is not possible, only visit trusted sites and only over the T-Mobile network (avoid Wi-Fi)."

To get a second opinion, we checked in with James Blaisdell, CTO of Mocana, a company who provides embedded security solutions for a litany of devices, including Android. His company recently became the first to provide enterprise-level security solutions to the Android platform with the launch of their NanoPhone Suite for Android, a software package that lets developers add in security into their devices and applications. His company also puts out an anti-malware tool for Android. In other words, he gets Android security.

Says Blaisdell, this current vulnerability is "very serious" and the breach "could have catastrophic consequences for users." He also agrees with Miller's assessment that the best thing for Android users to do to protect themselves is to not use the Android web browser until Google issues a security patch.

Android's Security Issues So Far

As noted in the Forbes article, Android is, in some ways more secure than other OS's. Its architecture uses a "sandbox" approach, which stops malicious code injected into the browser from accessing and taking over other parts of the mobile OS or applications.

However, in other ways, Android needs to do more. According to Blaisdell, most of the security problems found so far, including this one, have been serious. He also makes note of another critical problem in Android - that of applications being signed with "self-signed" certificates, which is "inherently untrustworthy," he says. A hacker could easily create a piece of malware and then trick you into trusting it and installing it onto your phone.

Another issue worth mentioning is Android's permission-based security model. While most security between the system and the applications is enforced through standard Linux facilities, additional, finer-grained security features are provided through a "permission-granting" mechanism that ultimately relies on the user to make a decision as to whether or not an app should be trusted. As with most security systems, it's the human element in this equation that introduces risk. 

You can think of this as sort of a mobile equivalent to Vista's UAC (user account control) which appears when an application needs elevated privileges. Except unlike UAC, which usually prompts you upon installing an application - something you either did or did not intend to do - Android's prompts are a bit more specific. As technology writer Wilson Rothman says: "Is it bad that an app I don't know well can 'modify global animation speed'? Honestly, I don't know."

For Charlie Miller, who has been making a name for himself in Mac hacking, this latest Android security issue was not his first discovery of weakness in Google's platform. In October, days after the release of the T-Mobile G1, Miller and his team found a similar vulnerability to this new one which Google ended up patching in early November. Both vulnerabilities could have been prevented if Android had the ability to block malicious code from executing in memory.

As of today, the patch is still sitting in the source code repository. Google has not sent it out to anyone's device yet. Although they did send out an updated firmware last week (RC33), the vulnerability remains unpatched. If and when we receive a response from Google, we'll update this post.

Update: Google has responded only by pointing us to the following advisory published by oCERT for more details: http://www.ocert.org/advisories/ocert-2009-002.html.

Update 2: Google's Rich Cannings, Android Security Engineer has now responded with the following statement:

"Charlie Miller, a security researcher at Independent Security Evaluators, contacted security@android.com on January 21st regarding a bug in PacketVideo's OpenCore media library that he intended to disclose on Feburary 7.

Media libraries are extremely complex and can lead to bugs, so we designed our mediaserver, which uses OpenCore, to work within its own application sandbox so that security issues in the mediaserver would not affect other applications on the phone such as email, the browser, SMS, and the dialer. If the bug Charlie reported to us on January 21st is exploited, it would be limited to the mediaserver and could only exploit actions the mediaserver performs, such as listen to and alter some audio and visual media.

The Android Security Team responded by contacting PacketVideo, T-Mobile, and oCERT, a public Computer Emergency Response Team. PacketVideo developed a fix on February 5th, and they patched Open Source Android two days later. oCERT assisted PacketVideo with coordinating the fix, and they published an advisory detailing this issue. We offered the patch to T-Mobile when it became available, and G1 users will be updated at T-Mobile's discretion.

We thank our partners PacketVideo, oCERT, and T-Mobile for their engagement and attention to this issue."

Image Credit: Android Authority