Why is security@microsoft.com an auto-responder and not a redirect to secure@microsoft.com?
Well, security@microsoft.com is the Microsoft internal physical security alias, and has been since we started using email. As I am sure you can imagine, the amount of email we get at that alias that is external is quite a lot. Thus the autoresponder instead of a human filter which informs you that secure@microsoft.com is the appropriate alias to report security vulnerabilities (and points to other security related resources).
More trivia: in the tail end of the previous post I noted that Windows 98/98SE/ME weren’t vulnerable to an automated or “Critical” attack vector for WMF because of an extra step placed in the processing of metafiles. I’ve been asked “How did that not make it over to the other products?"
Good question. Remember that PlayMetafile and its ability to call code out of the metafile itself was designed 16-17 years ago for Windows 3.0/3.1. Again, this was back when more of what an application could do was trusted (like executing code out of a metafile) because the environment was cooperative. There was nothing to be gained by trying to elevate privilege through a memory crash, every process already ran at the same privilege cooperatively in the Windows 16 bit world. Seems like a long time ago in a galaxy far far away doesn’t it?
The general Windows NT team’s implementation of the functionality worked the way it was originally designed. A separate team, the Windows 95 team, took a different route when they supported the function by adding the step mentioned in my previous post. Now here’s an interesting factoid. People tend to think that one team developed all the operating systems in a linear fashion, Windows 3.1 to Windows NT 3.5 to Windows 95, to Windows NT 4.0 to Windows 98/98SE, to Windows Me to Windows 2000, to Windows XP to Windows Server 2003.
Actually, Windows 95 and Windows NT 3.5 were developed almost concurrently by two separate teams. Then, Windows NT 4.0 was developed, while a separate team developed Windows 98. That team went on to develop Windows 98 Second Edition and Windows Me while the NT team developed Windows 2000. The teams and codebases started to really combine around the time of Windows XP’s development. I’m leaving out some interim products like Windows 95 Service Pack 1, Windows 95 OSR2, and Windows NT 3.51, but you get the drift. The Win9x guys had implemented the functionality differently than the NT codebase team and that change didn’t get migrated. As I mentioned before, this is why we have implemented new changes in the SDL to help us catch old functionality like this and learn from it.
S.
*This posting is provided “AS IS” with no warranties, and confers no rights.*