I am posting this bug here, and not to upstream, since the last version of macchanger was released 6 years ago, and this problem is easy to patch. In main.c: srandom(time(NULL)); then in mac.c, 3 or 6 (depending on macchanger parameters) MAC bytes are filled with random()%255. time() returns time in seconds, so even if the user randomizes just the MAC ending (macchanger -e), and assuming that the MAC address has been changed in the last 24 hours (in a typical use case, a much more precise estimate can be made), it is possible to say whether a given MAC address is faked with 99.5% confidence (1-24*60^2/256^3). In addition, running macchanger for several interfaces in sequence (e.g., during boot) sets the same MAC addresses for them (full or just the last 3 bytes, depending on parameters). This is for the same reason - resolution of time() which is used for srandom() is too low. Suggestion: 1(a). Replace time() with 4 bytes from /dev/urandom, or 1(b). Replace time() with fields from gettimeofday() struct, which gives microsecond precision 2. Replace %255 with %256 in mac.c If the math doesn't make sense for you, post your MAC address, and I will say whether it was faked with macchanger in the last 24 hours (and will also give the time when it was faked).
Created attachment 253345 [details] Find out when a MAC address was faked with macchanger Example of output: > ./mac-attack 5a:59:a9:8f:a5:0b Match: full Time: Fri Nov 5 22:31:45 2010 Confidence: 100.00% > ./mac-attack 00:25:d3:f5:09:a9 Match: 3-byte ending Time: Fri Nov 5 16:08:01 2010 Confidence: 99.86% > ./mac-attack 11:22:33:aa:bb:cc Match: 3-byte ending Time: Tue Mar 30 02:17:10 2010 Confidence: -13.75%
(In reply to comment #0) > Suggestion: > > 1(a). Replace time() with 4 bytes from /dev/urandom, or > 1(b). Replace time() with fields from gettimeofday() struct, which gives > microsecond precision > 2. Replace %255 with %256 in mac.c Do you have a patch for that? :)
i dont see this being a security issue
> Do you have a patch for that? :) Well, I can write a patch for say using /dev/urandom instead of time(), but I think that in its current form, net-analyzer/macchanger does more harm than good. Just changing 3/6 bytes of a MAC address to given or random bytes is easily achieved using a simple shell script (ifconfig hw ether). The main benefit of macchanger is its database of MAC vendors, but it is severely outdated (6 years old). Given that macchanger is mostly useful for Wi-Fi, which is a rapidly changing market, the database in its current form is pretty useless. So I don't know what's the best course of action here. Maybe a warning in the ebuild about the database age and the pseudo-randomness issue should be enough. SpanKY, the last time I submitted a security-related bug, I tagged it as "Applications", and it was moved to "Security". Go figure. I think it is a security issue, since the main purpose of macchanger (hiding your MAC-based identity) is defeated for typical use cases: the user is the only one using macchanger for a given wireless access point, and checking his laptop will show that macchanger has been used -> proof that an earlier connection was done from this laptop.
"hiding your mac" means "breaking industry and world-wide standards". dont do that. this is not a security issue.
Don't listen to SpanKY, MAC spoofing is great, enhances privacy, and it's (almost) standard-compliant (see IEEE Std 802-2001 Sec. 9.2.2). I found a relevant paper: http://www.springerlink.com/content/f20m055215623707/ 50 citations, I could write one too... Anyway, according to IEEE Std 802-2001, macchanger has another bug: in full 6-byte MAC randomization mode, the most significant byte should be and'ed with 0xFC, not 0xFE (the next-to-LSB bit in the first octet must be set to 0) - see Sec. 9.1.
actually, that's the exact opposite of what it should be doing. 0x02 should always be set in the first LSB. picking any other MAC is wrong regardless of whatever you might wrongly believe.
Oh come on... The standard says that bit 0x02 = 0 means that the address is universal, not that you can set 0x02 = 1 if the address is not universal. Bit 0x02 = 0 -> standard-conforming, bit 0x02 = 1 -> actually "breaks industry and world-wide standards", and might break some hardware for real. :)
Note for anyone that uses macchanger: Debian added an ugly patch a year ago to partially mitigate the issue described in this bug (two years ago): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633998
(In reply to comment #9) > Note for anyone that uses macchanger: Debian added an ugly patch a year ago > to partially mitigate the issue described in this bug (two years ago): > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633998 I may not have the best C skills, but it looks to me that the first patch makes the same mac *error* into an acceptable thing, rather than preventing it from making the same mac on two random calls. I'd be interested in a patch which uses actual /dev/random or /dev/urandom instead of a time check, or at least a time check in microseconds instead of seconds... thanks
(In reply to comment #10) > I may not have the best C skills, but it looks to me that the first patch > makes the same mac *error* into an acceptable thing, rather than preventing > it from making the same mac on two random calls. You are right -- I misunderstood the purpose of Debian patches. It might be a good idea to include them as well, though. > I'd be interested in a > patch which uses actual /dev/random or /dev/urandom instead of a time check, > or at least a time check in microseconds instead of seconds... Attaching shortly (reasonably tested with different switches and with /dev/urandom available or not). It might be possible to also put randomness source detection into autoconf, for non-Linux architectures (and then pass -DRANDOM_SRC=...), but I am not familiar with autoconf, unfortunately.
Created attachment 318002 [details, diff] Use /dev/urandom when available Uses /dev/urandom when available, and also resets next-to-LSB bit in first MAC octet if it is changed.
macchanger-1.6.0 seeds the PRNG from /dev/urandom or /dev/random. I'm not sure about the other issues, but I think it would make sense to mark 1.6.0 stable.
faustus: can you please confirm the issues are fixed in 1.6 or 1.7? if not, please send them upstream (they have a github now that takes contributions easily, see the updated HOMEPAGE variable).
