I have published another security advisory about a vulnerability, which I have “recently” reported to Yahoo! via their Bug-Bounty program hosted by HackerOne. So this blog post is about the technical details of the CVE-2014-7216 (which is not very thrilling), but more about my experience with Yahoo’s Bug Bounty program.

CVE-2014-7216: Attacking Yahoo! Messenger Users with Emoticons

🙂 😛 🙁 . To determine which emoticons and their associated shortcuts might be used in a chat window of the Yahoo messenger, the application loads a XML-file called “emoticons.xml” from the following directories during the login:

  • %PROGRAMFILES(x86)%\Yahoo!\Messenger\Cache
  • %PROGRAMFILES(x86)%\Yahoo!\Messenger\Media\Smileys

Whether the application takes the first or the second directory basically depends on the presence of the file in the Cache-directory. If it’s not found there, it’s loaded from the second directory.

If an emoticons.xml is found, its XML-structure is parsed. The following snippet shows just a part of the file to get an idea how things are working:

So each emoticon is associated with different keys, like a unique numeric “id”, a “title” to describe the emoticon, one or multiple “shortcut” key values, which are simple string representations of the emoticon. These shortcuts typed in a chat windows then trigger/display the associated “file”.

The problem? The String values for “shortcut” and “title” are used in two different lstrcpyW calls during the parsing of the XML-file:

It’s pretty obvious that this could lead to a nice buffer overflow condition if these values are oversized:

CVE-2014-7216-1

But exploitation might be tricky, because a Stack Cookie-Protection is in place (haven’t had a deeper look into this):

CVE-2014-7216-2

But feel free to submit any working exploits to Exploit-DB 😉 !

You’ve probably noticed that “signature” key value in the head of the file. Basically the emoticons.xml file is not present in a fresh installation of the Yahoo! Messenger and is therefore downloaded during the login-process from

To secure the integrity during the download the signature is validated. If the signature does not match the content, the file isn’t downloaded to prevent Man-in-the-Middle attacks. This works like intended, but unfortunately the signature is not validated anymore, when the file has already been downloaded and modified afterwards 🙂

OK, I’d like to drop some words about Yahoo! and its bounty program applied to this submission.

Yahoo! Runs a Bug-Bounty Program for AppSec issues?!

They probably do(n’t)! In theory it coveres all client side applications and therefore associated vulnerability categories, like memory corruptions:

yahoo-bug-bounty-1

When I was reporting CVE-2014-7216 through HackerOne, the Yahoo! Messenger was explicitly in scope of their program. Pay attention! This little information will become important later.

yahoo-bug-bounty-2

I’ve submitted the vulnerability with a detailed description and how to reproduce it. I always try to keep the quality of my reports as high as possible to help the vendor in lowering the effort and therefore costs for finding and fixing the bugs. There are a lot of really poor-quality HackerOne-submissions out there, without any kind of risk rating or simple mini-liners like this about missing HSTS submission or even this about a RCE bug.

After quite a long discussion about the vulnerability, it was finally submitted to their Messenger development team after 2 months. According to their program policy Yahoo! grants themselves a period of 30 days to review each submission and another 90 days to implement a fix for it, but after 120 days and without any further notifications from Yahoo, I tried to contact them using HackerOne, because they started to violate their own program policy. After contacting them via Twitter, where they are a lot more responsive than on HackerOne for some unknown reason, I got into a very interesting discussion about their program scope and the validity of my submission.

So basically Yahoo refused to pay out a bounty based on two arguments:

1. The Vulnerability is of Low Severity

Yahoo! thinks that the bug is of low severity and is “being slated to be EOL”:

yahoo-1

But I think:

Yes it is a “local” issue [CVSS-Score: 4,4 (AV:L/AC:M/Au:N/C:P/I:P/A:P)], but I’ve tried to explain multiple times that this does not necessarily mean that the host needs to be compromised already. All an attacker needs to do, is offering an arbitrary emoticon package to the messenger users.

And this is what MITRE thinks about this issue:

Use CVE-2014-7216. In many cases, issues that require the victim to manually download a configuration file, and copy this file into a product-specific directory, are outside the scope of CVE because exploitation is not realistic. Here, emoticons.xml might be considered a configuration file for the set of emoticon images. However, as mentioned in the above smileys.rar example, there is an existence proof that third parties actually do offer sets of emoticon files including this related XML data, and presumably some Yahoo! Messenger users actually do copy these to the required %PROGRAMFILES% or
%PROGRAMFILES(x86)% path by following third-party instructions such as on the http://www.tipsandtutorials.net/yahoo-messenger-11-hiden-emoticons.html web site.

Nothing more to say, almighty MITRE agrees! But the story continues…

2. The application is End-of-Life

yahoo-2

So they found out that the Yahoo Messenger is EOL during my report? Interesting move. All in all Yahoo! defined a program scope, which included Yahoo! Messenger, delayed my report for more than 4 months, stated that it’s EOL, changed their bug bounty scope and thereby excluded my submission. Feels a little bit like I’ve been fooled 🙁

Probably every security research encounters at least once in his lifetime a problem like this, where the program operator does not work transparently or behaves other than expected, but changing bounty scopes after a submission, resulting in the submission to be out of scope is pathetic.

About Repressive Bounty Programs

Another interesting side-effect of this report is the fact, that Yahoo wants to get all bugs disclosed to them via HackerOne regardless of their program scope. So if you disclose a security vulnerability in one of their EOL products as you would usually do via Full-Disclosure or Bugtraq instead of HackerOne, you’ll get banned immediately. So proceedings like this one about a WP-API bounty submission, would result in a permanent ban:

yahoo-3

In my opinion this a very repressive and threatening approach, which is completely the opposite of what they’ve written in one of their last articles about their bug bounty program:

People are really important

One of the most important aspect of our Bug Bounty program is the relationships we’ve built with its contributors. While we may not always agree — there have been heated email exchanges over a proof of concept or the value of a vulnerability — we never forget that this community is helping to make Yahoo more secure. We will continue to do everything we can to recognize their contributions. In return, we ask that the community is patient and respectful as we work through each report.

Now just think about my story and their story.

CVE-2014-7216: A Journey Through Yahoo’s Bug Bounty Program
Tagged on:             

9 thoughts on “CVE-2014-7216: A Journey Through Yahoo’s Bug Bounty Program

  • September 4, 2015 at 1:55 am
    Permalink

    Same exact thing happened to me. Refused to accept it as a problem. Then accepted it for triage but refused bounty screaming EOL. Yahoo has yet to close it out, provide bounty, respond to my follow ups, and even patch it. Mine is a bit different yet still a fairly large remote issue. Yahoo servers can be used to ddos with unlimited resources, unauthenticated, and with user supplied targets.

     

    Mike

    Reply
  • September 4, 2015 at 8:08 am
    Permalink

    Let’s be honest. Would you pay for something like this? 🙂

    Reply
    • September 4, 2015 at 5:06 pm
      Permalink

      Yes, why not? It’s a common overflow and there is a proof that the exploit probability != 0, otherwise MITRE would not have assinged a CVE number.

      But I think you’re missing the point: It’s more about changing a bug bounty scope during a report and thereby excluding the submission from scope, which was indeed eligible before. Scopes are part of the reason why security researchers even start testing…

      Reply
      • September 4, 2015 at 7:04 pm
        Permalink

        It seems like the scope was updated after you pointed out the confusing wording. From the screenshots, it looks like that happened after they said it was EOL.

        Reply
        • September 6, 2015 at 9:21 am
          Permalink

          That’s right. However my initial report was already 4 months old at this point of the whole scope changing thing.

          Reply
  • Pingback: Researcher: Yahoo Messenger! Refuses to Patch Emoticons Buffer Overflow Vulnerability | Dennis Nadeau Complaint Blog

  • September 11, 2015 at 1:10 pm
    Permalink

    Hi Julien! Great work you do here. I also covered your article on my blog (securitypitch.com).
    Needless to say that Yahoo’s response towards your findings isn’t a proper one and I’m sure that most of the press will cover your post and Yahoo will most probably get slammed in each and every one for their misconduct.
    Keep up the good work and I will be following your disclosures from now on!

    Reply
  • Pingback: SB15-264 Vulnerability Summary for the Week of September 14th 2015 « ECI Blog @WordPress

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.