Logitech lets certificate expire, killing peripherals

There's a support app that allows for all sorts of customizations (G-Hub), sounds like that broke, but the mouse didn't stop working, it just went back to whatever the default settings are (like the scroll direction). I suppose that's effectively "unusable".

I use a Logitech mouse/KB, and mine have an onboard memory option too, so the settings are stored in the device itself.

1767800796902.png
 
Does seem strange that it would kill their existing solution. Unless they have a kernel extension that thinks it’s been revoked for security reasons or something
 
casperes1996 said:
Does seem strange that it would kill their existing solution. Unless they have a kernel extension that thinks it’s been revoked for security reasons or something
Click to expand...

To allow someone to customize behavior without on-board memory, there has to be something running on the machine. Back in the day it would be a kernel extension (and really only on MacOS 9 for the most part), but there's been a class of helper background process an app can spin up on boot to get access to system events and do this sort of remapping without doing it in the kernel that has been common for quite a while now. But that helper app is embedded in G-Hub, and so when the certificate renders it invalid, it will no longer be allowed to launch, just like G-Hub itself.
 
Nycturne said:
To allow someone to customize behavior without on-board memory, there has to be something running on the machine. Back in the day it would be a kernel extension (and really only on MacOS 9 for the most part), but there's been a class of helper background process an app can spin up on boot to get access to system events and do this sort of remapping without doing it in the kernel that has been common for quite a while now. But that helper app is embedded in G-Hub, and so when the certificate renders it invalid, it will no longer be allowed to launch, just like G-Hub itself.
Click to expand...
But why a "bootloop" on app startup and not a message about an invalid cert? Usually you can also force unsigned binaries or binaries signed without a valid developer cert to run anyway
 
casperes1996 said:
But why a "bootloop" on app startup and not a message about an invalid cert? Usually you can also force unsigned binaries or binaries signed without a valid developer cert to run anyway
Click to expand...

There's a difference between an untrusted/missing signature and an invalid signature. An invalid signature where the certificate is expired, revoked, etc are an automatic "go away". And it should be this way. Untrusted signatures are what Apple have been locking down more and more, but let the user "trust" anyways. There should be an error, but if the background app is meant to be launched silently, it can fall into a case where the error is silent, and launchd just marks the service as invalid/disabled.

As for the boot loop, it depends a lot on the specific architecture of the tool and middleware they are using, and how Apple's certificate checks work. I make it a point to avoid Logitech/Razer HID remapping software in particular, so I haven't poked around the installed app bundle in a looooong time. And any speculation I do would be just that.

But the core point is that having a process in the background do the HID remapping for devices is pretty common (Razer also does it for example). It's the way to do it on macOS that works across the most versions and with the least user friction. And any developer certificate expiry on the part of Logitech would take the whole thing down.
 
Nycturne said:
There's a difference between an untrusted/missing signature and an invalid signature. An invalid signature where the certificate is expired, revoked, etc are an automatic "go away". And it should be this way. Untrusted signatures are what Apple have been locking down more and more, but let the user "trust" anyways. There should be an error, but if the background app is meant to be launched silently, it can fall into a case where the error is silent, and launchd just marks the service as invalid/disabled.

As for the boot loop, it depends a lot on the specific architecture of the tool and middleware they are using, and how Apple's certificate checks work. I make it a point to avoid Logitech/Razer HID remapping software in particular, so I haven't poked around the installed app bundle in a looooong time. And any speculation I do would be just that.

But the core point is that having a process in the background do the HID remapping for devices is pretty common (Razer also does it for example). It's the way to do it on macOS that works across the most versions and with the least user friction. And any developer certificate expiry on the part of Logitech would take the whole thing down.
Click to expand...
Thing I don't get though is that I'm pretty sure I've let my dev cert expire and my app just kept working.

I kinda wish I were affected by this. I'd love to mess about with the app bundle and see if I could get it to run, for example by stripping the code signing
 
For those who don't like or trust Logitech software (or MS', or any other annoying vendor) there are other options. The one I use is "USB Overdrive", which has been around since before Mac OS X... though of course the OS X implementation was a complete rewrite of the earlier version. Recommended- it works very well.
 
Ah, the old "new years holiday certificate renewal anniversary" strikes again.

I have the software installed and haven't noticed anything, but I don't generally use it. Guessing Tahoe isn't impacted by the boot loop problem?
 
all my programmed buttons on my mouse no longer works and the software won't load. Just got USB Overdrive and it works well, and I bet it iwll be more reliable too.
 
I have not had any Helldiver interruptions, so I've been fine :D
 
RockRock8 said:
Here's what actually happened, as I found this article via a different post this person wrote about how the tech media screwed up again with iOS 26 adoption rate

Click to expand...

Unfortunately, it's still not a satisfying answer (if correct) because it's still incomplete.

That said, Logitech themselves said the issue was with a certificate being used to secure IPC communication (in a Reddit comment, sadly not in the FAQ like a sane company would). This would be the channel between the front-end GUI and the back-end process that does all the HID remapping logic. So that combined with this gives us a more complete picture. The GUI expects the back-end to be present/available since the back-end is what actually does the lifting. But when the IPC handshake failed, the GUI basically hung because it wasn't handling the rejection gracefully.

When using XPC for IPC on macOS, one does need to take care to avoid possible exploits from anonymous clients. For example, there was a couple CVEs related to the Sparkle update framework not that long ago due to incomplete security on the XPC service side of the framework: https://github.com/sparkle-project/Sparkle/discussions/2764, and it's been a pretty ripe area for security research on the platform. Ultimately, an unsecured IPC/XPC service on the Mac is just bad juju and Apple does provide ways to secure an XPC service.

Assuming Logitech is using an XPCListener, a developer can apply code signing requirements to the listener, and macOS will reject any clients not matching those requirements for you leveraging the built-in codesigning validation. So it seems the most likely answer here is that Logitech set code signing requirements on the XPCListener that were stricter than Apple's for launch. So while macOS allowed the app to launch, the XPC server rejected the expired certificate that was involved. It's not impossible they used a separate certificate to secure the IPC channel that happened to expire at the same time, but then that would be more complicated than just leveraging macOS' codesigning validation against the client. So this is still speculation on my part, but it lines up.
 
Nycturne said:
Unfortunately, it's still not a satisfying answer (if correct) because it's still incomplete.

That said, Logitech themselves said the issue was with a certificate being used to secure IPC communication (in a Reddit comment, sadly not in the FAQ like a sane company would). This would be the channel between the front-end GUI and the back-end process that does all the HID remapping logic. So that combined with this gives us a more complete picture. The GUI expects the back-end to be present/available since the back-end is what actually does the lifting. But when the IPC handshake failed, the GUI basically hung because it wasn't handling the rejection gracefully.

When using XPC for IPC on macOS, one does need to take care to avoid possible exploits from anonymous clients. For example, there was a couple CVEs related to the Sparkle update framework not that long ago due to incomplete security on the XPC service side of the framework: https://github.com/sparkle-project/Sparkle/discussions/2764, and it's been a pretty ripe area for security research on the platform. Ultimately, an unsecured IPC/XPC service on the Mac is just bad juju and Apple does provide ways to secure an XPC service.

Assuming Logitech is using an XPCListener, a developer can apply code signing requirements to the listener, and macOS will reject any clients not matching those requirements for you leveraging the built-in codesigning validation. So it seems the most likely answer here is that Logitech set code signing requirements on the XPCListener that were stricter than Apple's for launch. So while macOS allowed the app to launch, the XPC server rejected the expired certificate that was involved. It's not impossible they used a separate certificate to secure the IPC channel that happened to expire at the same time, but then that would be more complicated than just leveraging macOS' codesigning validation against the client. So this is still speculation on my part, but it lines up.
Click to expand...
I appreciate the detailed comment, but the blog post stands. Multiple people were falsely claiming that if a developer certificate expires, that you can no longer use their app. That isn't true, and multiple websites were claiming that. That's all I was saying.

Thanks!
 
RockRock8 said:
I appreciate the detailed comment, but the blog post stands.
Click to expand...

I don't recall a point where I said it didn't. I said it was incomplete. A couple of us in this thread have been scratching our heads as to why the failure mode was what it was based on the fact that it was related to the developer certificate expiring, and taking the blog post at face value, I did some digging and shared my results with the room. It wasn't meant to be "but", but rather a "yes, and".

That all said, the one thing I will disagree with the blog post after the digging I did is on this point (emphasis mine):

So what happened with the Logitech mouse software? The blame here lies entirely with Logitech and not with macOS or Developer ID. The Logitech software performed some additional, custom validation, which failed after the Logitech Developer ID code signing certificate expired. That was an unforced error by Logitech, and the issue will not affect other Mac developers, regardless of when their Developer ID certificates expire. My own valid Developer ID certificate expires in 2027, and that will not stop my old apps from running. Indeed, I had a previous Developer ID certificate that expired in 2021, and its expiration didn’t stop any of my old apps from running either. That’s not how macOS works. That’s not how code signing works.
Click to expand...

I'm not convinced that "the issue will not affect other Mac developers". It doesn't have to, but there is no guarantee it will not. Anyone using XPC services should be locking down the service, and Apple provides a convenient mechanism dependent on signing checks. So in the scenario that Logitech was using that functionality, there's something other developers could certainly check and learn from. If Logitech home-rolled their own certificate checks because they aren't using XPC, then we can still learn from the fact that you should align your certificate checks to match Apple's behavior if you are going to check against the codesigning certificates (which is good practice in this case).

The funny thing here is that Logitech was/is following good practices here to secure their IPC channel. But they goofed twice, and because of that, their app broke.
 
Back
Top