6 ms·

UUIDv1 is generally not recommended since it leaks MAC addresses

by dtech 3y ago

nerdponx 3y ago
And on cloud hosts, you might end up with the same MAC address on what you thought should be 4 separate "nodes".
Vecr 3y ago
Do be clear, people have been pwn'd due to this. It's not a theoretical problem.
- GrayShade 3y ago
  That sounds interesting, do you have a reference on hand?
- stephenr 3y ago
  ... ok, I can see how the host MAC segment could be an issue if the UUID is generated "client" side and distributed.. What's the risk (in terms of "pwning") when the UUID is generated on a server?
  - michaelt 3y ago
    Step 1: Generate UUIDs using a highly predictable pattern Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf and assuming nobody will be able to download it without knowing the UUID Step 3: Attacker predicts the UUID and downloads the private file. Obviously the real solution here is to not use UUIDs as security keys - but dumbasses shoot towards their feet all the time, and UUIDv4 makes them hit less often.
    - stephenr 3y ago
      By that logic serial-type ids are unsafe for use too, and much more vulnerable. I was kind of expecting some claim that actually exploits the inclusion of a hardware identifier, rather than "don't use predictable numbers as secrets".
      - bhaak 3y ago
        > By that logic serial-type ids are unsafe for use too, and much more vulnerable. Yes, they are. Still, it's not good security advice to point towards an other thing and say "this is even worse".
        stephenr 3y ago
        The point I was making is that the claimed "exploit" is completely outside the bounds of what a reasonable person would do. It's like complaining that a garden hose can be used to fill a car with carbon dioxide so we should recommend against using hoses in gardens.
        bhaak 3y ago
        That's often an issue that people think attackers wouldn't got all the way because it's too cumbersome. "Reasonable" has a very imprecise definition. > On a recent Code Assisted Penetration Test (CAPT) our team identified a vulnerability in a client's web application which allowed the consultant to bypass authentication and take over legitimate user accounts. The issue stemmed from the use of UUID version 1 in password reset tokens instead of the secure version 4 counterpart. https://realizesec.com/blog/sandwich-attacks-exploiting-uuid-v1 https://realizesec.com/blog/sandwich-attacks-exploiting-uuid...
        stephenr 3y ago
        Ok, well for this case specifically let's just assume that "reasonable" means "knows a UUIDv1 isn't random, and shouldn't be used as if it were". You can probably sub in "suitably experienced" for "reasonable" if it reads better.
      - smallnamespace 3y ago
        Of course serial IDs are unsafe, but it's (presumably) obvious to most implementers. Look up the v1 spec. Essentially the entire ID space is timestamp + UUID, both of which are easily guessable. The amount of entropy matters, and v1 has little of it. The danger here is that a UUID seems random when it really isn't.
kozak 3y ago
There are probably (some other) risks in exposing a precise timestamp as well.
jbosh 3y ago
What about when those 6 bytes are randomly generated? RFC 4122 does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it.
- lazide 3y ago
  Then it wouldn’t have that issue - as long as it isn’t stable/reused for too long. The big problem - how can you tell for sure that is what is happening, and how would you catch a reversion if the underlying library changes behavior? Assuming you’re making a call into someone else’s stuff anyway. A big challenge I’ve seen with UUID implementations is dependence on some kind of hidden system state that causes issues. like a MAC or nodeid file somewhere in a VM that gets cloned, resulting in duplicates where ‘duplicates should be impossible’.
ttfkam 3y ago
uuid_generate_v1mc() from the uuid-ossp extension uses a randomly generated mac, so no leakage. https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-OSSP-FUNCTIONS-SECT https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-...

UUIDv1 is generally not recommended since it leaks MAC addresses

by dtech 3y ago

UUIDv1 is generally not recommended since it leaks MAC addresses

nerdponx 3y ago

And on cloud hosts, you might end up with the same MAC address on what you thought should be 4 separate "nodes".

Vecr 3y ago

Do be clear, people have been pwn'd due to this. It's not a theoretical problem.

GrayShade 3y ago
That sounds interesting, do you have a reference on hand?
stephenr 3y ago
... ok, I can see how the host MAC segment could be an issue if the UUID is generated "client" side and distributed.. What's the risk (in terms of "pwning") when the UUID is generated on a server?
- michaelt 3y ago
  Step 1: Generate UUIDs using a highly predictable pattern Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf and assuming nobody will be able to download it without knowing the UUID Step 3: Attacker predicts the UUID and downloads the private file. Obviously the real solution here is to not use UUIDs as security keys - but dumbasses shoot towards their feet all the time, and UUIDv4 makes them hit less often.
  - stephenr 3y ago
    By that logic serial-type ids are unsafe for use too, and much more vulnerable. I was kind of expecting some claim that actually exploits the inclusion of a hardware identifier, rather than "don't use predictable numbers as secrets".
    - bhaak 3y ago
      > By that logic serial-type ids are unsafe for use too, and much more vulnerable. Yes, they are. Still, it's not good security advice to point towards an other thing and say "this is even worse".
      - stephenr 3y ago
        The point I was making is that the claimed "exploit" is completely outside the bounds of what a reasonable person would do. It's like complaining that a garden hose can be used to fill a car with carbon dioxide so we should recommend against using hoses in gardens.
        bhaak 3y ago
        That's often an issue that people think attackers wouldn't got all the way because it's too cumbersome. "Reasonable" has a very imprecise definition. > On a recent Code Assisted Penetration Test (CAPT) our team identified a vulnerability in a client's web application which allowed the consultant to bypass authentication and take over legitimate user accounts. The issue stemmed from the use of UUID version 1 in password reset tokens instead of the secure version 4 counterpart. https://realizesec.com/blog/sandwich-attacks-exploiting-uuid-v1 https://realizesec.com/blog/sandwich-attacks-exploiting-uuid...
        stephenr 3y ago
        Ok, well for this case specifically let's just assume that "reasonable" means "knows a UUIDv1 isn't random, and shouldn't be used as if it were". You can probably sub in "suitably experienced" for "reasonable" if it reads better.
    - smallnamespace 3y ago
      Of course serial IDs are unsafe, but it's (presumably) obvious to most implementers. Look up the v1 spec. Essentially the entire ID space is timestamp + UUID, both of which are easily guessable. The amount of entropy matters, and v1 has little of it. The danger here is that a UUID seems random when it really isn't.

kozak 3y ago

There are probably (some other) risks in exposing a precise timestamp as well.

jbosh 3y ago

What about when those 6 bytes are randomly generated? RFC 4122 does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it.

lazide 3y ago
Then it wouldn’t have that issue - as long as it isn’t stable/reused for too long. The big problem - how can you tell for sure that is what is happening, and how would you catch a reversion if the underlying library changes behavior? Assuming you’re making a call into someone else’s stuff anyway. A big challenge I’ve seen with UUID implementations is dependence on some kind of hidden system state that causes issues. like a MAC or nodeid file somewhere in a VM that gets cloned, resulting in duplicates where ‘duplicates should be impossible’.

ttfkam 3y ago

uuid_generate_v1mc() from the uuid-ossp extension uses a randomly generated mac, so no leakage. https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-OSSP-FUNCTIONS-SECT https://www.postgresql.org/docs/current/uuid-ossp.html#UUID-...