I am a big fan of using Code Analysis (formerly FXCop) in my Visual Studio projects to help catch issues. Recently I ran across a CA2208 warning that I needed to think about. Usually these are simple results of refactoring or forgetting to include the argument name in the ArgumentNullException or ArgumentOutOfRangeException. This one, however, was a little different. The value was passed to the exception constructor and the name was correct.

The following code reproduces the issue (note this is C# 6 code written in the VS 2015 Preview leveraging the new nameof keyword):

The reason being is that rule checks to make sure the name being passed to the constructor of the exception matches a parameter of the current method. However, the code that gets generated for the delegate doesn’t pass baz as a parameter, rather it is a public field on the generated class. The code for the generated class essentially looks like this:

Getting the current day of week in C# is pretty easy, if all you need is the english version of the day, for example:

MessageBox.Show(System.DateTime.Now.DayOfWeek.ToString());

But if you want to get the Day of Week for the current language the computer is setup for, the above code will not work. You need to access the Globalization class and get the day of week from there. The snippet of code below, demonstrates how to do it:

You would expect that the implicit operators would allow the conversions between the Wrapper and the generic parameter type without issue. The key to the issue here is knowing that Excel.Application is an interface and there are different rules for conversions with interfaces.

Let’s browse out to our C# spec ("C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC#\Specifications\1033\CSharp Language Specification.docx") and open it up to 10.10.3.

The two parts of the spec that are applicable here:

S0 and T0 are different types.

Either S0 or T0 is the class or struct type in which the operator declaration takes place.

Neither S0 nor T0 is an interface-type.

Excluding user-defined conversions, a conversion does not exist from S to T or from T to S.

and

If a pre-defined implicit conversion (§6.1) exists from type S to type T, all user-defined conversions (implicit or explicit) from S to T are ignored.

If a pre-defined explicit conversion (§6.2) exists from type S to type T, any user-defined explicit conversions from S to T are ignored. Furthermore:

If T is an interface type, user-defined implicit conversions from S to T are ignored.

Otherwise, user-defined implicit conversions from S to T are still considered.

This second section was added to the spec after it’s initial release and the Microsoft development team obviously spent time thinking about this, as explained in this Eric Lippert answer.

Specifically he calls out the problem with interface based implicit conversion:

Why? Because one has the reasonable expectation that when one converts a value to an interface, that you are testing whether the object in question implements the interface, not asking for an entirely different object that implements the interface. In COM terms, converting to an interface is QueryInterface — “do you implement this interface?” — and not QueryService — “can you find me someone who implements this interface?”

Finally he states:

However, generics muddy the waters considerably, the spec wording is not very clear, and the C# compiler contains a number of bugs in its implementation. Neither the spec nor the implementation are correct given certain edge cases involving generics, and that presents a difficult problem for me, the implementer. I am actually working with Mads today on clarifying this section of the spec, as I am implementing it in Roslyn next week.

So, in conclusion, the reason the conversion doesn’t work is because that is how the language is specced and if you consider Eric’s answer as to why, it does make a lot of sense.

To be clear, I don’t consider myself a security researcher, rather I am a programmer who happens to dabble in security research. Maybe this is a little bit of imposter syndrome kicking in, but I really think I just know enough to be dangerous.

A few months back I learned of the Online Services Bug Bounty program Microsoft was offering. I decided to give it a go. I am always looking for authorized hacking opportunities and really wasn’t expecting anything to come of it. I created my test tenants and started playing around. I decided to focus on XSS vulnerabilities, as that is something I am pretty comfortable with and is pretty easy to test client side. Whenever I have tested for XSS vulnerabilities, I have always found that dialog windows tend to be some of the biggest culprits, so I honed in on those in my test tenant.

Eventually I stumbled across an OWA dialog that wasn’t escaping strings. I was easily able to generate this (URLs hidden to protect the innocent):

And then with a little more tweaking, this:

It was clear I had found an XSS vulnerability. I followed the submission instructions on the bug bounty page and waited to hear back. Within a few days, I got an email from the Microsoft security team indicating they had forwarded the bug to the product team. About a week after that I received confirmation that the product team had reproduced the bug and were working on a fix. Here is the timeline for the fix:

Since this bug impacted user installed versions of exchange, it took a bit longer for the product team to fix. I didn’t continuously test the online URL to know exactly when it was fixed, but I know as of today the vulnerability is fixed.

Every so often I have an app where I want to listen for global keyboard events and respond to them. I have had this code sitting around for a while and finally got it up to github, so anyone can use it as they see fit. It uses a few Win32 APIs to listen for the keyboard events and then fires events to let the caller know something happened. The Win32 calls are:

Then I simply have a background worker continuously checking the GetAsyncKeyState of the keys that we are monitoring. When we hit a key we are monitoring, we fire the event, so the consumer knows the keys were pressed.

It’s pretty basic now, but it does provide some useful functionality if you need to globally monitor keystrokes. The way it is setup now, key combinations are not exactly easy to do, but that functionality could easily be added to the API.