Forum Discussion
Russell_Moore_8
Jun 01, 2012Nimbostratus
I agree that your additional sanity check would be needed. Since we have a known leak when there is a failure of base64decode I am leery to try anything until I have a patch that would hopefully fix it. We have had at least one SEV1 production incident due to the leak so care is required. The code only impacts a small number of users at the moment so we have a bit more time luxury.
This code and more that I have not shared is to interrogate MS ActiveSync client requests. The idea is that the client wants a white list of devices allowed in the front door and then further security is done as it passes down the layers.
For the majority of the devices the query string would be in plain text and in a format such as this:
/microsoft-server-activesync?param1=val1¶m2=val2 and so on.
The few devices that are using the alternate protocol method look like this:
/microsoft-server-activesync?abGFkamY7bGFzZGprO2ZsZGthajtsa2RmanNhCg=
So I could either try to find something that will always indicate a text string or the option I had used was to find the exception to text which is base64 encoded. Obviously there are other cases too that would include no query string and plain garbage or attack etc.
In the case of the base64 encoded string the first query parameter is the string and it has no value. The parameter is also changes but I don't know by how much. I need to go read the protocol and see if I can find a pattern in the base64 that can be matched as a signature for such a query.
This is interesting and some of it will be incorporated into my solution but it is also a bit moot if the system doesn't leak memory on failed base64 decodes.