Monday, October 17, 2011

Integer overflow in Microsoft C++ SizeOf operator

I was reviewing some code in C++ and came up to a line in the code that was performing calculations using "SizeOf" ,something in the lines of:
value = sizeof(A)+sizeof(B)+sizeof(D)
At this point a thought came to me and I needed a break anyway, so I've decided to do a little test, I decided to write a small program that will edge case test the SizeOf operator.

The SizeOf operator in C++ is a unary operator that is being calculated during compile time, meaning the compiler replaces the result value with constant values in the final assembly code.
So a SizeOf(int) would be 4 in the final assembly.
The SizeOf function return a result of type size_t which is defined by Microsoft like this:(From crtdefs.h)

#ifdef _WIN64
       typedef unsigned __int64    size_t;
#else  /* _WIN64 */
       typedef _W64 unsigned int   size_t;
#endif  /* _WIN64 */
#endif  /* _SIZE_T_DEFINED */

/*__int64 nHuge;      // Declares 64-bit integer*/

So far so good, everything looks to be in order, right?
Not quite…

Now, back to the test:
I started a new C++ console project in VS2010 and I defined a 4Gig struct in it like so:

typedef struct {
char bytes1[1073741824]; //1 GIGA
char bytes2[1073741824]; //1 GIGA
char bytes3[1073741824]; //1 GIGA
char bytes4[1073741824]; //1 GIGA
Then later in the main function I calculated it's size into an unsigned 64 bit variable,
unsigned long long d = sizeof(DATA);
I added a printf to the variable to see what turns out, Then I compiled the code in Visual Studio 2010 under a 64bit configuration (i.e. with the _WIN64 define set) successfuly with no errors or warnings.

Any guesses on what is the output?

Is it "4294967296"? Or is it "0"? Or "1"?

Drum roll please!

The result is "1"! Que the "WTF?!?"

When looking into the output assembly it looks more odd:
mov edx, 1
Que the second "WTF?!?"

Wait... Didn't I just compile this in x64? with all x64 flags set?, yes I did... so why in the hell is the edx register being used?

In short - Yes.
This is a bug in the Microsoft C++ compiler. I have submitted it to Microsoft and they confirmed it as an issue,
However... it is not a security issue. just a bug :) 

Thursday, October 13, 2011

My experiment on the life cycle of reporting security flaws

As I am not doing security research externally to my place of employment, I just wanted to understand how do independent security researchers feel like, how do they report vulnerabilities responsibly and how do they deal with vendors.
I must say, at first I did not think that security researchers have too much trouble with vendors, I mean, my guess was that vendors appreciate vulnerabilities in their products being reported to them first so they will fix them, and not be… how to put it lightly… Dicks about it.

So this is the tale of me trying to report a vulnerability. But first a vulnerability must be found. So I went by the way of the Hacker, from the easy way to the hard way (after all, who has time to dig into stuff when you have a day job). What can be more easy than to Man-In-The-Middle my iPhone  and see what goodies can I find on my installed apps. After trying the obvious ones (Facebook, Skype, 4Sq etc. ) I moved to my final app, The app is called "MyOrange". 
In Israel we have several cellular providers, one of the biggest is a provider called "Orange", this provider decided it would graciously provide it's iPhone users with an application to view their current cellular bill and text messages total cost, including among other thing a past 5 months graph representation of their bills.
So far so good… While I was Mitm the app I noticed that it was authenticating to it's backend by SOAP messages in the clear (bad idea) but that’s not the jewel, the app was using the iPhone unique hardware identifier AKA UDID, sent in plain text to authenticate the device.
So what's the risk?
Someone sniffing traffic over an unsecure or secure Wi-Fi network can easily impersonate a device in front of the provider backend web service and extract billing information and a few more personal details.
At this point I thought, OK, now I have something, not a crazy 0day, but something that will allow me to approach the cellular provider and start a responsible disclosure process.

Contacting the vendor:
I started by sending emails asking for an application security staff member to contact me because I have found a security vulnerability in the iPhone app, I sent that email to two emails:
  1. The generic support email - I know it is a lame thing to do, but I still wanted to try that approach
  1. A "Contact us" email address I extracted from the iPhone app.

The first email I sent was replied to a week later with "We do not know what you are talking about, bye".
The second email was replied to a day later by the development team leader, asking me for my phone number so we could chat over the phone and I could provide him more details. 
Once we had that pleasant conversation and I explained the vuln to him, he said he will investigate and come back to me, I also sent a detailed description on how to reproduce the issue, which was annoyingly simple.

A month has gone by… 
So I sent a reminder email basically requesting an update.
A week after that I get a response saying that this is not an issue (WTF?!?) and that for a malicious user to get hold of the UDID he would need physical access to the device or the assistance of the device owner.  (WTF No.2)
At this point I was thinking to my self: "OK, take a deep breath... they must have misunderstood you", and once I calmed my self down I replied to them with an email saying that this is an issue and if that was not enough their app is sending data in the clear.
I waited another week before I lost patience again, what pissed me off this time was that the app was updated in the app store but was still vulnerable (!),  this time I sent a real life capture of the authenticating SOAP message, and again explaining what the risk was.

I was busy with my day job so this time I waited about a month and a half before I sent another reminder email to the team leader and another contact he CC'd during our previous email exchange, now here comes the funny bit, a week after my reminder I get an email in my inbox from that other contact addressing the team leader saying "We should probably answer this guy, it would be rude to keep ignoring him". So I after I ROTFL I replied to that contact he should probably send the email to the team leader and not me :)

Two more weeks have passed… Total time since discovery is now 4 months.

I decided that enough is enough, I found out the Company CSO email and sent him a direct email explaining the vulnerability. I got a response from him that same day telling me that the issue will be explored and investigated, this time it felt like something is going to happen and I will not be ignored, so I went on and focused on my day job duties and forgot about this for a while.

Until almost three weeks later I received a response from the CSO saying that the issue has been explored and there are several ways to mitigate the issue and he will inform me of the selected method the next day. After my experience with these guys I thought… "Next day" right, you are going to ignore me for another few weeks, so Imagine my surprise when I got a response from the CSO less then 24hours later telling me that they will mitigate the issue with SSL over Wi-Fi.

And that is all that was needed, freaking SSL over Wi-Fi and around 5 months of emails and ignorance.

I was so excited this thing was over I sent a hearty "thank you" email to the CSO, he literally mad my day :)

So what my take?
So, this entire effort was to get an idea as to what it is like to be a security researcher out there, trying to help vendors secure their products. And I can say without a doubt that is it hard work! And I am not referring to the vuln finding process, I am talking about dealing with the companies/vendors, trying to explain to them that they are vulnerable or they put their clients at risk! But they just won't listen.

So if you are reading this and you are a researcher who has encountered a case similar to this in the past, I take my hat off in respect, and  I want to add: Keep up the good work! :)