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

Open_Source_Enjoyer I am not sure exactly how this is working but i think the device can know if you are using Android, iOS, Windows, Linux, MacOS etc and then it know where are the buttons to press.

Anybody can claim anything. Some claims are more plausible than others. So far no source has been cited.

Open_Source_Enjoyer Those sources do not describe malware that can exfiltrate photos from an Android phone faster than a user can see.

It is one thing to attack a Windows machine by popping open a command prompt and pasting a command line, but more difficult to adjust settings on a device running an unknown variant of Android. So it seems as if there may be a gap between the general threat (which is real) and potentially wild claims made in an article that has been alluded to but still not linked to.

Recent macOS prompts the user when an unfamiliar USB device is connected and tries to describe the device by name. In theory Android could do that as well.

Again, if the issue is you are worried about compromised devices being badUSBs or similar, then simply enable charging only over USB.

USBs can fake their identity, its not hard, there's no way to have a USB device whitelist. This is why ADB authenticates over RSA keys.

You need to just know where your devices come from and if they are trust worthy, and if you cannot trust them, don't use them. Buy from the manufacturer if you are really worried, but being attacked in this way is not realistic.

ADB requires authentication, and emulating keyboard/mouse inputs is very noticeable and easy to stop by just unplugging the device.

If this is a genuine worry of yours, then you should just enable USB charge only, or use devices you absolutely trust, but USB as a protocol already assumes you trust the device you plugged in

Open_Source_Enjoyer The interface of GrapheneOS is nearly the same if not the exact same as the ASOP so to make the right clicks shouldn't be very hard for a USB Stick acting as mouse and keyboard.

I have not run AOSP since 2019, but that does not match my memory. I'm pretty sure the collection of pre-installed apps is different, so the very first few taps would not be the same, right? And that assumes no customization of the launcher home screen...?

Originally it was claimed that some article says this sort of attack can be done "very fast", "in the background", and "without the user recognising it and having a chance to stop it". If that is true as opposed to imagination, there should be some sort of demo. Is there?

Open_Source_Enjoyer The thing is that when you use GrapheneOS you are using a hardened version of the ASOP, but I don't know of any changes that have been made to the design of it. The launcher that GrapheneOS uses is the ASOP launcher, so the GUI is the same.
From this point, the attacker can go through a list of browser names until he finds one that is installed, and then perform the following steps: [...]

How can a USB keyboard "find" which browser is installed? USB keyboards can type things, but they can't see what's happening. Attacking a Windows system by typing a known key sequence to bring up a shell prompt and then typing in a canned command is different from interacting with a touch-based GUI, especially if it isn't known which OS is present and which apps are present.

I think there have been three requests so far that the actual article making these alarming claims be provided (in whatever language it's written in). The forum moderators have at various times expressed a distaste for alarming claims made without evidence. If this discussion thread is based on unsubstantiated claims that are implausible, perhaps it has already received enough "air time".

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.