‘Cookiejacking’ Poses Minimal Danger if You Keep Good Habits

“Cookiejacking,” anyone?

In the last few days, a new vulnerability in Microsoft Internet Explorer has made its way through the media. Disclosed at the Hack on the Box conference by the independent researcher Rosario Valotta, this flaw takes advantage of a property of HTML5 to steal the cookies from its victim.

This kind of attack, called cookiejacking by Valotta, bypasses all the security measures in Internet Explorer and works on any version of the application and Windows.

Sounds scary, doesn’t it? Well, this threat is really more noise than anything, and we’ll explain why.

First, unlike other truly dangerous attacks or malware that are completely silent (as PinkSlipbot), this attack requires the victim to visit a malicious site and commit a drag-and-drop action. Also, the attacker must know the victim’s Windows username and where cookies are stored.

Second, although many sites leave their cookies in plain text, the cautious ones (such as banks) keep those values encrypted so that attackers can’t easily gain usernames and passwords.

Third, ask yourself a question: How many times have you been working on a site you’ve logged into and when you refresh a page or move on the site you find you need to log in again? More than once, yes? That’s because almost every website that uses cookies gives them a very short lifespan, so even if someone manages to steal your cookies, the attacker would have to use them within the timeframe.

If this low-likelihood attack is successful, the attacker will have a complete history of your browsing–which sites have you visited and how frequently–so you could start seeing a lot of spam/phishing designed especially for you.

If you’re truly unlucky, the attacker will catch your usernames and passwords of the sites that store them in plain text, so someone could adopt your identity on those specific sites. But remember, sites that manage sensitive information use encrypted cookies.

Could this scenario be dangerous? Sure.

But is it dangerous by itself? Not so much, and you can very easily prevent falling for this kind of attack.

Be careful where you go on the Internet. Do you see a link with a new online game? Search for it first, and read the comments! Has a friend sent you a Facebook invitation that seems strange or out of place? Don’t go! Ask your friend about it.

Keep your cookies clean, delete them regularly, log out of any important website every time you finish your business. These are simple steps, but they will invalidate those cookies. And, finally, never, ever allow a website to remember your sessions! That keeps your cookies valid for future sessions.

Really, all we need is a bit of caution.

M. Francisca Moreno Vilicich and Alfonso A. Kejaya Muñoz of McAfee Labs Chile made major contributions to this blog.

libxml vulnerability and interesting integer issues

A while ago, I was playing with grammar-based XPath fuzzing and I found and fixed an interesting libxml bug. The commit, for the curious, is here:

http://git.gnome.org/browse/libxml2/commit/?id=d7958b21e7f8c447a26bb2436f08402b2c308be4

The trigger for this bug was the XPath expression: //@*/preceding::node()/ancestor::node()/ancestor::foo['foo'] which for some reason I haven't yet analyzed leads to a pathologically large collection of nodes within libxml.

As the nodeset is grown and grown, things get interesting when the system runs out of memory whilst trying to double the size of the nodeset:

cur->nodeMax *= 2;
temp = (xmlNodePtr *) xmlRealloc(cur->nodeTab, cur->nodeMax *
sizeof(xmlNodePtr));
if (temp == NULL) {
xmlXPathErrMemory(NULL, "growing nodeset\n");
return;
}
cur->nodeTab = temp;

Notice how the max number of allocated nodes in the "cur" structure is doubled before doing, checking and assigning the reallocation. This means that in the event of a realloc() failure, one of two things will happen:
  • If you malloc() implementation exits the process upon alloc failure (such as Chromium), lucky you! You dodged a bullet.

  • More typically, you'll exit this function with "cur" in an inconsistent state, i.e. it indicates it can hold more data than it really can.
Despite the call to xmlXPathErrMemory(), XPath processing continues with "cur" in an inconsistent state, leading to a heap-based buffer overflow.

The fix is to only update the structure's "max size" member after a successful expansion of the underlying array. libxml already did this in most places, using a paradigm such as:

temp = (xmlNodePtr *) xmlRealloc(cur->nodeTab, cur->nodeMax * 2 *
sizeof(xmlNodePtr));
if (temp == NULL) {
xmlXPathErrMemory(NULL, "growing nodeset\n");
return;
}
cur->nodeMax *= 2;
cur->nodeTab = temp;

... which leads us nicely into part 2:

Interesting integer issues

Even with the fix applied, there are some really interesting integer issues going on here. The astute will have noticed a possible integer overflow in the argument to xmlRealloc(), which is a general hazard with the common pattern of "double the size of the array if we ran out of room". Digging in to more detail, we see a fascinating difference in behaviour between 32-bit and 64-bit builds and maybe even learn a thing or two about integer promotion rules.

On 32-bit builds

First, let's quickly note that cur->nodeMax is of type int. That's likely the wrong type for a couple of reasons, but we will run with it for our analysis.
On 32-bit, sizeof(int) == sizeof(size_t) so we're looking at a fairly basic possible integer overflow. But can it ever be triggered? Does the 32-bit address space offer enough room?
The case with the least space requirements for the 32-bit address space is the case where we already have a 2GB (2^31) allocation and are attempting to double it -- leading to an integer overflow at 2^32 and an attempt to realloc() to 0 bytes.
But to arrive at the 2^31 allocation, we need to have a 1GB -> 2GB realloc() succeed first.
This is actually unlikely on 32-bit Linux -- which typically has just the lower 3GB of address space usable. 1GB + 2GB + program text etc. won't simultaneously fit, so the only way 1GB -> 2GB realloc() will succeed is if the allocation can be expanded in-place. glibc malloc() will typically use mmap() for large allocations, and put them towards the top of address space in order to reserve room for standard heap expansion. So realloc() on such an mmap()ed chunk typically won't have room to mremap() to a larger size.
All in all, this seems to be a hard-to-exploit bug, unless the attacker has a lot of control over other allocations (to influence the placement of the 1GB mmap() lower down in the address space and then free() whatever chunks were needed to do that, before the realloc()). Further research might be merited for other allocators (e.g. tcmalloc) and 32-bit-process-on-64-bit-host (>3GB address space available).

On 64-bit builds

With 64-bit, we have a much larger address space. This means that we should be able to successfully allocate the growing array -- and the objects contained within it -- right up until the fault condition.

The fault condition is that cur->nodeMax * 2 will eventually become negative. This negative int is then multiplied by sizeof(xmlNodePtr). Remember that sizeof() returns a size_t, so we have an int -> size_t promotion at this point. This will result in sign-extension to a 64-bit size, which will end up massive and the system allocator will not be able to satisfy an allocation of that size. Therefore, a lucky lack of impact on 64-bit.

Finally, note that there's a real subtlety in the ordering of the expression given to xmlMalloc():

cur->nodeMax * 2 * sizeof(xmlNodePtr)

Things would be very different if we had:

cur->nodeMax * sizeof(xmlNodePtr) * 2

Promotions for left-to-right operator sequences are done in strict left-to-right ordering, as opposed to some kind of overall max(precedence) promotion. Therefore, in this latter case, the initial negative-related failure will be avoided; we're looking at:

(int) 2^30 -> (int) -(2^31) -> (size_t) 0xffffffff80000000 * 8 == (size_t) 0xfffffffc00000000
vs.
(int) 2^30 -> (size_t) 2^30 * 8 -> (size_t) 2^30 * 8 * 2 == (size_t) 2^34

Seeing that nodeNr is just an int, we would likely see subsequent memory corruption if nodeNr goes subsequently negative after its increment in a statement such as cur->nodeTab[cur->nodeNr++] = xmlXPathNodeSetDupNs(node, ns);

Baby Born amazing effect? No, another Facebook likejacking scam

Mother and new born babyMessages are spreading rapidly across Facebook, as users get tricked into clicking on links claiming to show an amazing video of a big baby being born.

The messages are spreading with the assistance of a clickjacking scam (sometimes known as likejacking) which means that users do not realise that they are invisibly pressing a “Like” button to pass the message onto their online friends.

A typical message looks as follows:

Baby Born Amazing Effect

Baby Born Amazing Effect - WebCamera
[LINK]
Big Baby Born !

(Note: I have obscured the thumbnail used in the messages, as some may find it offensive because of its err.. anatomical nature.)

The links we have seen so far all point to pages hosted on blogspot.com, and appear to contain a video player that you are urged to click on.

The pages are headlined: “Baby Born Video – Amazing Effects”.

Baby Born Amazing Effect

See the message at the bottom of the page? It reads:

If Play Button don't work please click on the Like button and Confirm, then you can watch the Video.

It’s at this point that the clickjacking scam plays its part. If you try to play the video then you will be secretly and unwittingly saying that you “Like” the link, and sharing it with your friends. In this way the link spreads virally.

As regular readers of Sophos’s Facebook page will know, scams like this have been seen on far too many occasions. It’s a crying shame that Facebook’s own security measures don’t warn about this particular clickjacking attack.

If you were running anti-clickjacking protection, such as the NoScript add-on for Firefox, then you would see a warning message about the attempted clickjacking:

Baby Born Amazing Effect

Unfortunately, thousands of Facebook users appear to have fallen for the scam – and are helping the links spread rapidly across the social network.

Here’s how you can clean-up your Facebook page.

Find the offending message on your Facebook page, and select “Remove post and unlike”.

Baby Born Amazing Effect

Unfortunately that doesn’t completely remove the interloping link. You also need to go into your profile, choose Activities and Interests and remove any pages that you don’t want to “Like”.

Baby Born Amazing Effect

If only folks were more careful about the links they clicked on when using Facebook.

If you’re on Facebook and want to learn more about spam, malware, scams and other threats, you should join the Sophos Facebook page where we have a thriving community of over 80,000 people.

89% say they would tell Mac-using friends to install anti-virus, poll reveals

Just over a week ago we ran a poll on the Sophos Facebook page asking folks if they would now recommend that friends and family install anti-virus software.

89% of the 968 people who answered the poll said yes, they would recommend friends install anti-virus software on their friends’ Macs. Just 104 respondents answered no.

Mac anti-virus poll

Now, of course, people who have joined Sophos’s page on Facebook are likely to have a higher-than-average interest in computer security, and we can’t claim it’s a scientific poll – but it’s worth realising that we asked this question before the latest revelations about how the latest Mac fake anti-virus malware has evolved to not require users to enter their passwords.

From what I’m seeing in comments online, and the increasing number of home users downloading Sophos’s free anti-virus for Mac, there’s a real sea change taking place, and the recent attacks have woken up Mac fans to the advantages of running anti-virus software.

More and more Mac users are realising that they do need to take the security of their computers seriously, and anti-virus is part of that.

Of course, there is much less Mac malware than there is on Windows – but that doesn’t mean it’s non-existent.

Macworld's Editor's ChoiceAs MacWorld said when they awarded Sophos Anti-Virus for Mac Home Edition its highest accolade of “Editor’s Choice”:

"Frankly, there's no reason not to try it as it provides precisely the protection a home user needs without the added bells and whistles that often serve to slow down your system. It's simple to install and use and needs just a few megabytes of disk space. Running quietly in the background, it's hard to tell that the software is active at all, aside from a small icon in your menu bar."

"Sophos Anti-Virus for Mac Home Edition is full-featured, flexible and completely free. That's hard to beat."

DownloadFree Anti-Virus for Mac
Download Sophos Anti-Virus for Mac Home Edition