It's a debug log. On its own, this driver doesn't do anything malicious. A malicious piece of software could exploit it, but there's no evidence that any did. Even if it got flipped on accidentally, it would merely log information and not transmit it anywhere.
Even if it got flipped on accidentally, it would merely log information and not transmit it anywhere.
Indeed, this is pretty benign compared to the "feature" in Windows 10 which does log and send that information if you enable it... and I believe this is enabled by default:
I dunno, I didn't get a sense of urgency or crying wolf from the blog post. it was interesting information and a good read but I don't see verbiage leaning towards these "security" people you are criticizing. to me it read as something he was curious about and ended up inquiring to the manufacturer who confirmed some details. keylogger is a pretty scary word, but is that not what is happening, despite it being benign to other software's behavior?
I personally appreciate the post, because i like to be aware of what could be potentially recorded or transmitted on machines i use. It doesn't have to "be worse than windows10" to be useful info to some users, and we certainly shouldn't expect all security-minded blog posts to be breaking news to be taken seriously.
Context aside i find it fun to watch things unravel or peer into how other people work!
I liked it too, myself. Personally I didn't find it over the top, but the title could've been more descriptive. It is technically a keylogger but keeping it vague just makes people assume it's malicious, when the code in question is obviously not, on its own.
Is having optional debug trace that can be activated only with admin rights really a bad thing security-wise ? Maybe when combined with other bug/features ?
I don’t think that works without rights scalation / admin privileges. I believed it stopped working in Windows Vista, at which time MS locked this and UAC and such things further than in Windows 7.
It works without administrator, you misread the stackoverflow answer.
The answer was about intercepting messages sent to an already escalated process (i.e. monitoring administrator processes from a user's context, even if they're technically an administrative user).
It works for one user context process monitoring another user context process. It doesn't work for IE or Edge due to LowPriv context isolation.
Because typically you can't get away with sneaking code like `void keylogger() {` into freely available code. Even if hidden well, it will be discovered sooner or later with enough eyes. The only insecurities "allowed" by open-source code are accidents, and these can be discovered much quicker than accidents included in proprietary code.
It's pretty clear that 'security' has never been a concern for Linux desktop developers, what software would you choose to run on your open source hardware instead of linux?
If HP was able to release a patch to remove keylogger is a very short amount of time, does that mean that they already know about the keylogger being in the production code and had a patch ready just in-case it was detected?
I don't see a disclosure timeline on there, so "quick" is a relative term.
Perhaps they just recognised that it could explode into a Superfish sized PR problem and went to fire off some angry calls to Synaptics for not surrounding their debug prints with ifdef.
I wonder if the old driver was WHQL-certified as well... (Although I'm under the impression that just needs to pass the SDV)
Could be, but if it really was extra debugging code then they might just have forgotten to remove a debug flag or add a prod flag, so they just had to flip a bit and recompile. Yes, that requires incompetence over malice, but firmware/drivers seems to have some really low quality stuff happening.
