How much harm can usb or bluetooth input devices do in GrapheneOS?

With the new 2Factor fingerprint unlock with a password, it would take forever to switch USB modes. There should be a way to use the fingerprint plus pin to access locked settings.

Open_Source_Enjoyer I don't want to seem as if I'm claiming that no threats exist due to USB peripherals. Clearly that's not true, and the GrapheneOS developers have made changes to make those attacks harder.

But, to go over the articles you provided:

Open_Source_Enjoyer https://www.msn.com/en-us/news/technology/a-malicious-charging-cable-reveals-why-its-best-to-stick-to-official-accessories/ar-AA1wW9O0

No specific attacks are described. That is, nothing says "Windows/Debian/Ubuntu/macOS version X was exploited with this cable by ____". Some of the vague statements are pretty inapplicable to GrapheneOS phones. Sure, a malicious USB cable could contain a keystroke logger for USB keyboards... but that wouldn't capture PINs or passphrases entered via a phone touchscreen, so...

That article describes no actual exploit against anything, let alone any phone, let alone an Android phone, let alone an exploit that would somehow work against all Android phones without knowing which version is in use.

Open_Source_Enjoyer https://www.businessinsider.com/fbi-free-phone-charging-stations-could-get-hacked-malware-warning-2023-4?international=true&r=US&IR=T

I remember the "airport USB charging station" outcry. I also remember it being debunked (source source). Are there any reported instances of any actual devices being exploited via a free USB charging station?

Open_Source_Enjoyer https://www.nbcnews.com/tech/security/juice-jacking-why-you-should-avoid-public-phone-charging-stations-n1132046

Here a specific attack is described: remote mirroring of an iPhone screen. And there is even some video, though it is edited so that a key point is obscured. At least in this YouTube video, attaching an exterior monitor requires agreeing to a pop-up. If "cybersecurity expert Jim Stickley" has a way around that, that would be big news... and I suspect Apple would rush out a fix.

But screen mirroring has nothing to do with "installing a malicious app and giving the app admin permission" (Open_Source_Enjoyer) at all, let alone "very fast and in the background, without the user recognising it and having a chance to stop it" (Open_Source_Enjoyer).

Open_Source_Enjoyer https://www.techspot.com/news/105863-usb-c-cable-can-hide-lot-malicious-hardware.html

Again, "could easily contain hardware that can inject malicious code, log keystrokes, and extract personal data", no specific documentation of any specific exploit, just a "could" allegation.

https://counterespionage.com/malicious-usb-cables/

There is a video on this page, but it's a video of using infrared and voltage/amperage devices to discover cables with clandestine active elements. No demonstration of instant background installation of malware.

The original post made specific claims:

1. getting passwords, pictures, documents and other stuff
2. install a malicious app and give the app admin permission
3. permanent backdoor access
4. very fast and in the background, without the user recognising it and having a chance to stop it.

Note that "very fast and in the background" is the opposite of "user must agree to a pop-up about trusting a device".

Is it possible to provide documentation (such as a video) of #1, #2, #3, and/or #4 applying to, for example, an Android phone where PINs and passphrases are entered via the touchscreen?

Is it possible to provide a link to the article cited in the original post? If not, why is that not possible?

de0u Is it possible to provide documentation (such as a video) of #1, #2, #3, and/or #4 applying to, for example, an Android phone where PINs and passphrases are entered via the touchscreen?

Open_Source_Enjoyer I don't really get what you want

If something is a real genuine exploitable vulnerability that people can actually exploit and are actually exploiting, then it is possible to demonstrate an actual exploit. Video would be good. Forensic evidence would be fine. Otherwise, it's a theoretically-possible issue, and then questions about scenarios are completely relevant. For example, if somebody claims GrapheneOS (unlike Windows) can be exploited by a device pasting in a command line, maybe that's actually so difficult that this is a low-priority issue.

So what I meant by "documentation such as a video" is documentation, such as a video. I think this is super-relevant if people are providing little scraps of video that they allege demonstrate a serious problem, but if parts are clipped out that would make it clear that the problem is less serious.

Again, I am by no means claiming there are zero vulnerabilities associated with people voluntarily plugging in USB peripherals after having set their USB-C port preference to allow connections. But in terms of whether/when the GrapheneOS might want to take action, I think those considerations matter. There are lots of vulnerabilities! Some of them can be exploited remotely. Some of them (such as the recent one involving animation-disabling breaking the lock screen) are vulnerabilities that can be clearly demonstrated including via a brief video.

So it probably be relevant in terms of the priorities of the GrapheneOS project if, instead of repeating debunked claims about airport charging stations (for which there are zero documented victims), it were possible to present clear evidence of any Android device being exploited by any of these attacks.

Please note that I don't speak for the GrapheneOS project.

Open_Source_Enjoyer The protection mechanism performed by the iPhone in the video you linked is the mechanism we need on GrapheneOS.
If the cable/Bluetooth device wants to see the screen -> permission request
If the cable/Bluetooth device wants to send inputs -> permission request
If the cable/Bluetooth device wants to install something -> permission request

Those all seem to me like fine things, to be prioritized according to the plausibility of actual exploits, keeping in mind that GrapheneOS already encourages users to configure their USB-C ports to be other than wide open.

[...We need] a permission pop-up that can't be triggered accidentally, but must be held for 1-2 seconds.

That formulation suggests this issue is more severe than any other issue that currently involves a user consenting to something, since none of those require a multi-second delay. So evidence that this issue is easy to exploit, or has been exploited, would be great.

Watermelon I'm not gonna read this whole thread, but you should see:
https://github.com/GrapheneOS/os-issue-tracker/issues/32

Thanks for reporting that!

It seems as if at least one developer thinks alerts would be useful but not all that easy. So then how feasible exploits in this space are probably matters.

Open_Source_Enjoyer If the cable/Bluetooth device wants to see the screen -> permission request

On Pixel 8 and newer which support dp-alt screen mirroring via usb or the testing version of desktop mode on a usb display both require the user to give permission when the display is connected.

Only harm i can imagine coming is with a few specific instances.

1. Device emulation - Most USB and bluetooth peripheral devices don't act as 1 single connected device, but often 2 or 3 or more. Some keyboards act as mulitple devices. Logitech used to sell imposter-like usb devices with programmable macros and assignable hot keys.

On Windows pcs, certain drivers would load and change all sorts of registry keys and kernel mode settings upon inserting those usb/bluetooth devices.

2. The real problem can arrise when something like a usb keyboard can fool the connected device to thinking it is a storage device when in actuality it has no storage or virtually none.

these arent considered exploits though.. but they're different attack methods someone might use.. Or perhaps can be thought of as a modern convenience.

3.Watch out for devices that act as many different seperate devices. Those logitech devices would act as a camera, multiple keyboards, mouse, or any other combination of programmable devices one could imagine.

Do note that permissions arent always enforcable for every situation. E.g. Chromebooks dont follow Android permissions model and bring along more capability then the connected Android devices are aware of by setting multiple or shared UIDs.