HP keylogger | Hacker News Reader

HP keylogger

zwclose.github.io

131 pointsneotek33 comments

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:

https://images.techhive.com/images/article/2015/08/0904-win1...

I really wish the "security" people would stop "crying wolf" constantly with things like this.

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.

Can it be weaponized? Yes? Then it's not "crying wolf".

This is how you get plausible deniability. Instead of one obvious backdoor you build a system of compromised parts that look innocent on their 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 ?

One less to have to write if you want to do evil. HP -oh nice, just have to enable their builtin keylogger.

But you can write a key logger that works without admin rights and on every windows computer in less than 100 lines.

what api gives a global hook across apps without rights escalation?

https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

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.

This answer explains and also has a link to ms with more detail on how it’s blocked: https://stackoverflow.com/questions/3169675/how-to-use-setwi...

Malicious keyloggers are used all the time of course, but I believe they all require some sort of exploit or way to effectively gain admin privileges.

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.

If you have admin access, you could install whatever keylogger you want, so IMHO this is a moot point.

External keylogger will likely be detected by antivirus sowtware and HP drivers are probably whitelisted.

SynTP.sys is signed by Synaptics on my Thinkpad. Why is this HP-specific?

Keyboard driver had debugging code in it.

Don't use computers for anything you want to keep private.

Or rather, proprietary software and hardware.

Why would non-proprietary software and hardware not be insecure?

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.

In practice the situation is a little different though https://archive.fosdem.org/2017/schedule/event/linux_desktop...

Perhaps you've heard of the disaster known as X?

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?

Here are a plenty of exploit mitigations that simply do not exist for Linux, https://www.blackhat.com/docs/us-16/materials/us-16-Weston-W...

You only get what your expectations are. If your expectations is defeatism in the privacy space, then you're only creating what you don't want.

Yet another one? There was already this one in the audio driver earlier this year... https://news.ycombinator.com/item?id=14314795 Makes you wonder who this is for.

That is why we need opensource hardware.

Or open source drivers

Why not both?

Proprietary hardware can have a hardware backdoors.

Yes, and even those can be detected, triaged, and then summarily killed. Even those with heavy crypto and intentional hiding schemes.

I'm speaking of Intel's management engine. Hacked.

I'm also speaking of Apple's secure enclave processor. Hacked and unencrypted.

Yeah, it'll by you some time. But when the target's nice and fat and juicy, well do I have a story for you...

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.

Reply on news.ycombinator.com