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:
<emoticons base="http://l.yimg.com/pu/emoticon/v2/" v="1" signature="aWMVk87cEqMhMPEJpJbADO3LfEUwq9iDpnhd+xoSjnqTwysXNp9dq1TB5J1dw+eWXSJuEr8v+gvrP6/fssk/2oJx696Uq63Ek0wAa1Xf6E7YsXetdvefDOCun2Po2V9Jxake6Oe8ZF/jYQyieOKVmqdx455lh74rLzNjK5zqhir/ne88pti5GHTU/pWtj4awTbsnzebcYUcjNdlnCK+8L5EHxHAJ00CBrg8cbZdmj9wdve5HXFvezaiN4iIRuJ/oAHZTohvEjwRhHC5ngZGn+nnKpFrfsIiAT0566RBZhJVkIhPcqe8MEr1NLUYbrye4thqwaXsCjuhDJTuWEGLlew=="> <emoticon fname="1" id="1" sendable="1" title="smile"> <shortcuts> <shortcut>:)</shortcut> <shortcut>:-)</shortcut> <shortcut>(-:</shortcut> <shortcut>(:)</shortcut> <shortcut>(:</shortcut> <shortcut network="2">:)</shortcut> <shortcut network="13"> :) </shortcut> <shortcut network="13"> :-) </shortcut> <shortcut network="13"> :] </shortcut> <shortcut network="13"> =) </shortcut> </shortcuts> <file> <type checksum="esq2lwBbQt92U0SFK7klQw--" extension="gif" height="18" size="1197" width="18"/> <type checksum="cX2396Ml7rRwVSDAINw9pg--" extension="bmp" height="18"/> <type checksum="cX2396Ml7rRwVSDAINw9pg--" extension="png" height="18"/> </file> </emoticon>
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:
0051D2C1 |. FF30 ||PUSH DWORD PTR DS:[EAX] ; /String2 0051D2C3 |. 8D45 00 ||LEA EAX,DWORD PTR SS:[EBP] ; | 0051D2C6 |. 50 ||PUSH EAX ; |String1 0051D2C7 |. FF15 9C138400 ||CALL DWORD PTR DS:[<&KERNEL32.lstrcpyW>; \lstrcpyW for "shortcut"
0051D326 |. FF76 04 |PUSH DWORD PTR DS:[ESI+4] ; /String2 0051D329 |. 8D45 00 |LEA EAX,DWORD PTR SS:[EBP] ; | 0051D32C |. 50 |PUSH EAX ; |String1 0051D32D |. FF15 9C138400 |CALL DWORD PTR DS:[<&KERNEL32.lstrcpyW>>; \lstrcpyW for "title"
It’s pretty obvious that this could lead to a nice buffer overflow condition if these values are oversized:
But exploitation might be tricky, because a Stack Cookie-Protection is in place (haven’t had a deeper look into this):
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
http://insider.msg.yahoo.com/ycontent/?&countries=0&defaultcountry=1&filter=0&imv=0&system=0&url=0&searchbar=0&sms=0&games=0&chatcat=0&audiblemenu=0&dct1=0&dct2=0&logos=0&marketing=0&partner=0&voicesmiley=0&contenttab=0&sidepanel=0&revokedplugin=0&safeobjects=0&defaultplugin=0&modules=0&userfeedback=0&settings=0&imscanners=0&av=0&emoticon=0&emoticonorder=0&reliablemessaging=0¬ifications=0&ads=0&jurisdiction=0&langpacks=0&fmt=2.0&intl=us&os=win&ver=11.5.0.228&lang=en-US
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:
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.
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”:
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
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:
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.