Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

UUIDs are only unique if you generate them...

UUIDs are only unique if you generate them...

  • Comments 28

We had an internal discussion recently and the upshot of the discussion was that it turns out that some distributed component on the web appears to have used the UUID of a sample COM component.


I wonder sometimes why people do this.  It's not like it's hard to run uuidgen and then copy the relevent GUIDs to your RGS file (and/or IDL file, or however it is you're defining and registering your class).

I guess the developers of the distributed component figured that they didn't have to follow the rules because everyone else was going to follow them.

And, no, I don't know what component it was, or why they decided to copy the sample.

So here's a good rule of thumb.  When you're designing a COM component, you should probably use UUIDGEN (or UuidCreate()) to generate unique (and separate) GUIDS for the Interface ID, Class ID, and Library ID and App ID.


  • The Macromedia Flash Player's CLSID is {D27CDB6E-AE6D-11cf-96B8-444553540000}. I believe 444553540000 suffix is "DEST", the fake MAC address used by the "fake" NIC used by dial-up networking! If you grep through the Microsoft Platform SDK, you'll see lots of other CLSIDs ending in 444553540000, so the GUID namespace is a lot smaller for many components!
  • Carlos:

    "If you're grabbing a MAC address for uniqueness you need to ensure it's from a real network interface card."

    We're doing that, but apparently there are more non-real NICs than we know of...
  • Shipping in Q4 2005: DRM for GUIDs.

    Copy a GUID, go to jail.

  • "I just wish privacy fanatics hadn't killed the Pentium ID feature, this kind of problem would be much easier to solve if we had that. Unfortunately, as it is, I don't know of a single reliable way to uniquely identify a user's PC."

    The Pentium ID was not a globally unique number. Sadly, a lot of privacy advocates never realized this.
  • Given that it is too hard for people to generate GUIDs, I think it is beyond all possible hope that people use real MAC addresses. I for one didn't even know this was a problem. *sigh*

    I don't know who's fault it is, but gosh darn it, STOP!!!!

  • MAC addresses are SUPPOSED to be unique. You have to purchase a block of MAC addresses from IEEE.

    However, a lot of second-rate network card mfgrs will just randomly create addresses for their cards without buying a block. Another common thing is to re-use addresses once you have used up your block (rather than buying a new block). Sad but true.

    I've also seen some poorly-designed network cards that had trouble reading the MAC address EEPROM, so they would occasionally change their MAC on a reboot.
  • Microsoft has itself distributed software integrated/bundled with windows that with the same GUID had changed interface (!) between releases of Windows. (same functions, but different parameters/arguments)

    It did cost us a measurable amount of money, lost goodwill and (me) debugging this for a non-trivial amount of time to find this shite - that MS themselves violated the cardinal rule about COM interfaces.

    As Microsoft has a history of this themselves, what Microsoft dude/dudette/representative/employee has the stomach to complain about it when others do it too? MS have already set the pace.
  • There are some malwares implemented as browser helper objects that use the same UUID as in this article from MSDN (BHO 101):

    A google search on "1E1B2879-88FF-11D2-8D96-D7ACAC95951F" returns thousands of hits.

    Plain stupidity or spoofing for profit?
  • Larry,

    this blog entry forms the basis for a section in the OWASP Guide 2.0 :) This blog entry is linked in the cryptography section and the topic itself is a level B entry.

    Hopefully this will help prevent this issue in the future.

    Andrew van der Stock
    OWASP Guide Lead
  • With respect to MAC addresses, I've worked with ethernet chips where every single chip had the same MAC. Caused havoc until we figured out what was going on.
  • Thursday, July 21, 2005 10:55 PM by Jeff Parker

    > So how the heck does it happen that people
    > get the same GUID. I am not saying it can't
    > happen but the chances of getting the same
    > guid I think are greater than winning the
    > lottery,

    That's absolutely right. Even though you can't predict who will win the lottery or how long it will take (in a version where there's no guarantee of a winner but the jackpot grows), but nonetheless someone will eventually win it.

    A better analogy of course is a famous puzzle regarding birthdays. What are the odds that a random collection of n people will include at least two with the same birth month and date. If you want a 100% guarantee then you need 367 people. But even with just 23 people you have a 50% chance.
    doesn't exactly say how to generate a UUID if no IEEE 802 address is assigned to the machine doing the generating. Its stated conditions for detecting that the local value of UTC has gone backwards also seems slightly insufficient, since some operating systems allow an administrator to adjust the time of day, some (including some that are closely related to the Open Group) don't want to admit that UTC includes leap seconds, etc.

    On the other hand, in one three-bit field, one possible value is defined as letting Microsoft do whatever they want to do differently. Hey, there are millions of manufacturers in this industry (some of them not being manufacturers of operating systems or integral components thereof so they haven't even been steamrolled flat yet). Why doesn't this three-bit field allow enough values for every manufacturer to do whatever they want to do differently? After all, how else can you expect everyone to agree on a standard? Sheesh.

    Plus they admit that the 100 nanosecond interval is only likely to remain adequate for one generation of high-performance multiprocessors after 1997. We're passed that now. The universe is doomed.
  • PingBack from

Page 2 of 2 (28 items) 12