search

USBGuard / usbguard

USBGuard is a software framework for implementing USB device authorization policies (what kind of USB devices are authorized) as well as method of use policies (how a USB device may interact with the system)
https://usbguard.github.io/
GNU General Public License v2.0
1.1k stars 133 forks source link

What would be the reason for a hash to change? #532

Closed duck-rh closed 2 years ago

duck-rh commented 2 years ago

Quack,

I'm trying to understand what happened on my laptop and I'm not implying usbguard is doing anything wrong but since the device hash is, IIUC, computed by usbguard I thought you might know more about this. Also I would have used the mailing-list for this kind of question but it looks kind of deserted.

Today I raised my laptop (T490s + dock) from sleep as usual and could not get any IP, external monitor was not working, and I could not find any lead in the logs. Replugging my dock did not help and rebooting led to a BIOS message about the PSU having not enough wattage (charging goes through USB too). But then I noticed usbguard telling me some device was blocked and I was intrigued. It happened the hash for my dock (plugged though USB C) had changed and the parent USB hub as well. I added an allow rule, restarted everything and all is working fine again.

Kernel updates might have been installed but since I did not reboot that should not affect anything. fwupd had an empty history and anyway was missing a component to actually being able to push changes. Any idea what could have triggered the changes?

Regards. \_o<

hartwork commented 2 years ago

Hi @duck-rh , I've been using USBGuard for a while now, with no hash ever changing. I think the code deriving the hashing is this:

https://github.com/USBGuard/usbguard/blob/5505735ad83fbbed79504aaa4297baf4ce791642/src/Library/DevicePrivate.cpp#L133-L152

That would mean that the hash changes whenever any of _name, vendor_id, product_id, _serial_number change. Does that make sense?

duck-rh commented 2 years ago

@hartwork thanks for clarifying. It makes sense but I don't see how these could change in between going to sleep. The name and serial have not changed for sure. I do not have the other past information because after rebooting several times to check everything and try to reproduce I just noticed the parent-hash is now back to its original self (the one matching the old rule, but I made the new rule more lax and it contains less info).

Looking at what the kernel does it seems that suspend is more risky than I would have imagined. Maybe this annoying USB cable connecting to the dock could have moved and partially disconnected and caused this situation (it happens from time to time but never caused such a mess, so this is a wild guess).

hartwork commented 2 years ago

Maybe not a strong argument, but: it could be a bit flip in hardware. I should re-watch DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker). I remember the bottom line was: Bitflips are more likely than I thought they were before watching the talk.

duck-rh commented 2 years ago

Alright, thanks @hartwork for the suggestion. If noone else has experienced this issue and I myself used this hardware the same way for years without such problem, hopefully this won't happen again and there's no reason to bother people longer.