More than two years ago, I was writing the first No Fills TCP RFC draft.
At that time, I wondered if one of the possible features of this new protocol could be a creative use of the RST flag (see section 4.1.1), which I mostly inteded for those Windows system administrators who had to work with a large number of machines on the same subnet.
In the version that hit the web on April, 2006 I wrote (emphasis added):
More aggressive implementation options are being considered, but some are not backward compatible despite being very useful:
- last hop router receiving a NFRST packet SHOULD rewrite the destination address with the broadcast address of the nework of the destination host. This should achieve the effect of terminating ALL current connections over the network with the sender host.
- the most extreme semantic of the NFRST flag would be “Reboot”: any networked host (computer, router, …) which receives such a packet MUST schedule an orderly reboot. Without any doubt this would solve many remote administration nightmares.
It is not by chance that we choose local broadcast over a multicast group as the destination of the last hop packet: most of the machines which will benefit the most of this innovative method of remote administration will be running an OS that pioneered the use of broadcast for the most inventive purposes.
But — I have to admit it — MS08-001 came in as a big surprise: Microsoft had thought better, implementing a whole sled of reboot functionalities and leaving us in the dark for two whole years!
Granted, the most exciting features (remote management and reboot) are present — as expected — only in the most recent version of its operating systems (XP, 2003, Vista), but we are used to it, aren’t we?
Please note that those with mixed XP/2003/Vista networks have to choose IGMPv3 management, while Vista-only network administrators can opt for either IGMPv3 or MLDv2 (aka CVE-2007-0069).
Fun does not stop here! Windows 2000 administrators are not left outside alone, there’s the handy RDP management (aka CVE-2007-0066) suitable for the not-so-recent enterprise.
PATCH NOW! :-)
I’m not commenting on the time frame, even if I’d like to, because it’s hard for me to determine how long these have been known but not fixed. I note that that CVE-2007-0059 was the Apple Quicktime bug discovered during the MOAB and reported on January 3, 2007 and that CVE-2007-0075 is an AspBB Remote Password Disclosure which came out on Bugtraq more or less January 4, 2007.
I have no idea if this proves anything at all. I know that CVE numbers get handed out on a first-come first-served basis, and nothing more.