Quote from the article (emphasis in original): "Our target for a suitable exploit delivery vehicle is open-source applications where the collection and distribution of high-frequency mouse data is not inherently suspicious. Therefore, creative software, video games, and other high performance, low latency software are an ideal targets for injecting our exploit."
My comments: yes, because exploits being injected into open-source software are famous for not being discovered. Obviously it can happen (look at xz, or the recent Shai-Hulud worm on NPM), and it's entirely possible that it has happened to other places that weren't discovered. But with xz the exploit was caught quickly enough that it didn't reach production, and with Shai-Hulud it was contained within days despite having the potential to spread to every package. I doubt that anyone trying to stick this kind of thing into open-source software would get away with it. Closed-source software, OTOH, would be a far more likely distribution vector. Just persuade some overworked dev that he should use this handy library that tracks high-precision mouse movement in his game, and you've injected your exploit.
It's easier to hide this in plain sight instead of being a secret. Take for example table top simulator, it has the ability to show where other people's cursors are so you can follow what other players are doing. If this streamed the mouse location at a high enough frequency, you now have the data needed being sent to everyone else in the same lobby. Synchronizing mouse cursors or player look vectors is a common feature and it may not be obvious that sensitive data is actually being streamed to the person doing the review.
Heartbleed was in production for two years. Log4Shell was in the wild for 8. ShellShock for 20. The fact that some exploits are discovered quickly is not in any way a proof that nobody can get away with it. You may argue that these vulnerabilities are unintentional. I would say distinction without difference.
Yes but this is discussing deliberately injecting malware into an open source project, which differs from exploiting a vulnerability that exists in one.
It’s a bit ironic in the sense that the EXACT logic of what you’re saying here is precisely what makes it such an ideal thing to target.
I think sometimes people put way too much faith into the concept of open source as being some kind of meaningful shield against attacks like this. Like absolutely nobody in an intel background for example who does stuff like this for a living would agree with you.
It only ever needs to look plausible and I don’t think it’s all that complicated a problem to come up with a reason as to why you’re introducing some code that is suddenly very focused on reading mouse sensor data.
I've known that the correct pronunciation of "mic" was to sound like "mike" (because it's short for "microphone") for so long that the pun in the "Mic-E-Mouse" name escaped me until after I finished reading the article.
(If you also didn't notice the pun, it would sound like "Mickey Mouse" if you pronounced "mic" the way it's written instead of the correct way).
The page is anonymized so the authors are unknown, the repository link is expired, and the drive link that does work only contains MICEMOUSE.zip and another archive with MNIST data.
A pretty good malware distribution method would be having people download a ‘demo’ of this, right?
The author theorizes that games are an ideal malware delivery vehicle but... aren't games typically connected to a user's headset/mic regardless?
I'm a bit puzzled how "secure environment" has a direct connection to "data collection" and "adversary".
Lets ignore the open source FUD in the diagram.
Quote from the article (emphasis in original): "Our target for a suitable exploit delivery vehicle is open-source applications where the collection and distribution of high-frequency mouse data is not inherently suspicious. Therefore, creative software, video games, and other high performance, low latency software are an ideal targets for injecting our exploit."
My comments: yes, because exploits being injected into open-source software are famous for not being discovered. Obviously it can happen (look at xz, or the recent Shai-Hulud worm on NPM), and it's entirely possible that it has happened to other places that weren't discovered. But with xz the exploit was caught quickly enough that it didn't reach production, and with Shai-Hulud it was contained within days despite having the potential to spread to every package. I doubt that anyone trying to stick this kind of thing into open-source software would get away with it. Closed-source software, OTOH, would be a far more likely distribution vector. Just persuade some overworked dev that he should use this handy library that tracks high-precision mouse movement in his game, and you've injected your exploit.
It's easier to hide this in plain sight instead of being a secret. Take for example table top simulator, it has the ability to show where other people's cursors are so you can follow what other players are doing. If this streamed the mouse location at a high enough frequency, you now have the data needed being sent to everyone else in the same lobby. Synchronizing mouse cursors or player look vectors is a common feature and it may not be obvious that sensitive data is actually being streamed to the person doing the review.
Heartbleed was in production for two years. Log4Shell was in the wild for 8. ShellShock for 20. The fact that some exploits are discovered quickly is not in any way a proof that nobody can get away with it. You may argue that these vulnerabilities are unintentional. I would say distinction without difference.
Yes but this is discussing deliberately injecting malware into an open source project, which differs from exploiting a vulnerability that exists in one.
"Our delivery vehicle is FOSS"
Yeah right, FOSS is famous for just accepting pull requests with exploits from randos.
LGTM YOLO fuck it, ship it, move fast and break things — wait, that one isn't FOSS.
Anyway .
This absolutely does however happen in practice.
It’s a bit ironic in the sense that the EXACT logic of what you’re saying here is precisely what makes it such an ideal thing to target.
I think sometimes people put way too much faith into the concept of open source as being some kind of meaningful shield against attacks like this. Like absolutely nobody in an intel background for example who does stuff like this for a living would agree with you.
It only ever needs to look plausible and I don’t think it’s all that complicated a problem to come up with a reason as to why you’re introducing some code that is suddenly very focused on reading mouse sensor data.
I've known that the correct pronunciation of "mic" was to sound like "mike" (because it's short for "microphone") for so long that the pun in the "Mic-E-Mouse" name escaped me until after I finished reading the article.
(If you also didn't notice the pun, it would sound like "Mickey Mouse" if you pronounced "mic" the way it's written instead of the correct way).
The "mickey" is also the unit used for mouse speed.
The page is anonymized so the authors are unknown, the repository link is expired, and the drive link that does work only contains MICEMOUSE.zip and another archive with MNIST data.
A pretty good malware distribution method would be having people download a ‘demo’ of this, right?