While Chrome has one of the most secure sandboxes and has always survived the Pwn2Own contest during the last three years, we have now uncovered a reliable way to execute arbitrary code on any installation of Chrome despite its sandbox, ASLR and DEP.

I would hope an update to fix the exploit would be released soon, although sandboxing has already proved to be insecure which makes future exploits easier. Meanwhile, I’m going back to browsing by telnet hostname 80.

location ~ \.php$ { # For nginx -V >= 0.7.27
  try_files $uri =404;
  fastcgi_pass localhost:8080;
  ...
}
location ~ \.php$ { # For nginx -V < 0.7.27, i.e. Debian 5
  if (-f $request_filename) {
    fastcgi_pass localhost:8080;
  }
  ...
}

Interestingly though, that when I disconnect the ATA from WAN interface, I could connect to its admin interface via the LAN port. However right after I connect LAN port to my ADSL hub, any request to admin interface would timeout. That’s weird, so I turned on syslog to log the system message to my external syslogd, and then connect the LAN port. Wow — heaps of log messages. Here is a snippet:

Mar  3 22:26:24 CDUaUdpStack::OnReceiveFrom(803fa460, 334)
Mar  3 22:26:24 from:50.22.171.5, port:5112, len=334, REGISTER sip:xx.xx.xx.xx SIP/2.0^M Via: SIP/2.0/UDP 50.22.171.5:5112;branch=z9hG4bK-1614305573;rport^M Content-Length: 0^M From: "152" ^M Accept: application/sdp^M User-Agent: friendly-scanner^M To: "152" ^M Contact: sip:123@1.1.1.1^M CSeq: 1 REGISTER^M Call-ID: 2269038874^M Max-Forwards: 70^M ^M
...
Mar  3 22:26:24 CUserAgent::SendTo(806f9750, 234, 5112, 50.22.171.5, 0, encryptType=0, udp, 0)
Mar  3 22:26:24 to:50.22.171.5, port:5112, len=234, SIP/2.0 403 Forbidden^M Via: SIP/2.0/UDP 50.22.171.5:5112;branch=z9hG4bK-1079254239;rport^M From: "152" ^M To: "152" ;tag=2cfa115b^M Call-ID: 807709011^M CSeq: 1 REGISTER^M Content-Length: 0^M ^M

Repeat the above for around 15 times per second! What appears to be happening is — this host 50.22.171.5 has been sending me SIP registration message at the rate of 15 times per second, and my VoIP ATA is merely replying back with 403 forbidden message at the same rate. My ATA is pretty much DoS’ed — I am denied of my VoIP service, because it has been too busy servicing bogus requests!

So once I firewall’ed the requests (dropping all packets from that IP), my VoIP ATA got back its sanity again. Hooray!

However, the “attack” did not stop. Large number of requests are still hitting my ADSL router every second. It is also chewing up quite a bit of bandwidth that counts towards my ADSL monthly quota. Here is an MRTG graph.

Not a lot of things I can do.

• I have sent an email to Softlayer’s abuse department (that IP address belongs to Softlayer). Did that a few days ago and still waiting for the reply.
• I could request a new IP address from Exetel to switch to. A lot of hassle especially with some IP-based authentication.

will update once there’s a solution. This kind of SIP-based DoS attack seems to get very frequent now — what are they trying to achieve?!

“Half the Mac OS X boxes in the world (confirmed on Mac OS X 10.4 Tiger and 10.5 Leopard) can be rooted through AppleScript:

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

Works for normal users and admins, provided the normal user wasn’t switched to via fast user switching. Secure? I think not.” On the other hand, since this exploit seems to require physical access to the machine to be rooted, you might have some other security concerns to deal with at that point, like keeping the intruder from raiding your fridge on his way out.

In the comment section it has been confirmed that

1. It only works if the user is logged into the Mac, but not via fast user switching.
2. Disable Apple Remote Desktop does not work.
3. It works over ssh if the same user also happens to be logged in.

Saying “physical access is required” is simply irresponsible. People might click on strange attachments or weird files downloaded from the net, which might run commands to get root privilege. Or maybe there are other exploits in Mac OS X that can get remote hackers local user privilege, and then use this to gain root.

Actually it is not hard to get physical access either. Sydney Apple Store opens tonight. Watch out for those pimple-faced teens typing vigorously in from the Terminal.app tonight!

Yes. Please call all your friends who have a self-hosted WordPress blogs and get them to upgrade to the very latest version.

To see what has been changed from WordPress 2.3.2 to 2.3.3, you can use the following Subversion commands:

$ svn diff --old=http://svn.automattic.com/wordpress/tags/2.3.2 \
           --new=http://svn.automattic.com/wordpress/tags/2.3.3

Which includes the diff of the five files that have been changed. The biggest change came from xmlrpc.php, in change set 6715, where Ryan tries to fix this security issue (yes the ticket was opened in November last year and only managed to get fixed yesterday, 3 months later). Basically, capability checking is done before determining whether the operation is editing a post — if post type is “post”. So any account can edit posts and pages via XML-RPC by faking post type as “page”. For more detail on this exploit, see The Seeker Blog, and it appears to be “going wild” at the moment.

The fix also only comes in 2.3 flavour, whereas the concept of “page” has been there in WordPress since 2.0. That also means, all you 2.0/2.1/2.2 users are still vulnerable. You have to upgrade to the latest stable branch, although not all existing plugins and themes work with 2.3…

I think I am starting to agree with Mark…

Hi ScottYang,

I would like to add you as a co-author of my MyBlogLog community below:

Blog/Site: Blogmemes Belgium (http://www.blogmemes.be)
MyBlogLog community: http://www.mybloglog.com/buzz/community/Blogmemes_Belgium/

Your MUST click on the link below to accept this request:

<Link Deleted>

Thanks,
Blogmemes_Belgium

Instead of clicking on the link, I went straight to its community site on MyBlogLog. And there we have it — a blogsite with hundreds of co-authors. I then went to the actual website, which turns out to be a Digg-like social bookmarking site in Belgian. It just sounds too fishy and too spammy. So I gave it a miss. After all it wasn’t the first time MyBlogLog got spammed.

I then discovered the exact same thing reported on Blogpond. Apparently both Jeremy Shoemaker and John Chow were affected and added to be the co-authors of that spammy community. If you “accidentally” become the co-author of a particular community, you will also receive emails whenever someone commented on that community. End result? Lots of unwanted emails!

The exploit is commonly known as Cross Site Scripting (XSS). Malicious hacker can craft a fishy URL and tempt you to click on, and as an already authenticated user of a certain web-service, that link will execute something on your behalf without your confirmation nor intervention.

These are my immediate reactions (which I posted on Blogpond).

1. Even Chow and Shoemaker fall for the fishing links — it is that easy!
2. Cross site scripting is a major problem on MyBlogLog.

I actually don’t find Chow and Shoemaker clicking on the links that surprising. If you are an Internet user, you shouldn’t be too scared clicking on links, because of our implicit trust on established websites whom we have authenticated with. Because of trust we are not paranoid and running a browser without cookie and without Javascript. Because of trust the “Web 2.0″ can be what it is today. We are trusting MyBlogLog here (though implicitly), believing that it will be free from XSS and no malicious hacker can steal my identity to perform operations on our accounts. Well, there goes my trust.

While MyBlogLog claimed the hole has been fixed, it does make you wonder, how many other holes are there? Especially with MyBlogLog’s track history, sometimes you just cannot be sure whether all vulnerabilities have been patched. Combating XSS is never easy, and many applications have to sacrifice convenience for the sake of security. WordPress switched to nonce back in 2.03, and MBL might want to think about something similar as well. Or force all state-changing operations on POST requests only. Or require re-authentication on all stat-changing operations.

Meanwhile, I will just make sure I always log out and clean up my MyBlogLog’s domain and path cookies. But then that pretty renders MBL useless, isn’t it, as it can no longer track which member visited what community.

I was on a positive tune when I took MyBlogLog for another spin earlier this month. I am back to being critical again here, and finding myself returning to square one, arguing whether MBL is actually a good fit for my blogs.

Update: It appears that logging out MyBlogLog only logs you out the admin interface, but a cookie is still there to track you on other blogs (which you need to explicitly clear). I think it is actually a good idea, and everyone should log off when they are not maintaining their profile on MBL — it will only to track you even when you have logged out, and it reduces the possibility of XSS exploits.

I got pretty excited after 10 minutes into the film, where Jack Stanfield walked into his security department and tried to help out one of his staffs to slow down the hacking activities. He sat down in front of this un*x box with Ethereal running in the background, logged into the Csico router via a text terminal and started adding access list rules denying the entire class-C address!! That really got me excited about what else would be happening in the rest of this movie! Too bad that was the only highlight, and later on he even crashed the network of the entire building by executing a virus/worm from his Outlook-running Windows PC. IT security expert didn’t even firewall his own computer?

There were actually some top notch acting in “Firewall” — but they do have A-class actors. Harrison Ford is way too old for any fast moving action, but I wasn’t expecting Han Solo or Indiana Jones anyway. Paul Bettany is just so good at being a ruthless villain, and Virginia Madsen made a great role as the calm mother. Story is pretty packed but a bit ordinary. Ending is weak like many other thriller movies — police arrived on time just after hero of the day saved everyone he loved.

Many holes in the plot though makes the overall story unconvincing. One reason Paul Bettany failed his mission to rob the bank was because he killed 2 out of 4 of his sidekicks. IT security expert uses 4-letter name of his boat as password? Fax machine scan head + iPod Mini + OCR to read out screen dump of account numbers is ingenious but still far-fetched. At the end it was a GPS-equipped barking dog and super long battry life, dodgy-looking notebook with hyper-extended range wireless access that saved the day.

And have I mentioned that virus executed on security expert’s Windows PC crashed the entire network of a bank? Huh?!

Enjoyable movie if you like Harrison Ford and/or into IT security, or just like to look at racks and racks of servers in the data centre. Otherwise you won’t miss out much if you skip it.