API Review: User Agent

[jasonstephen15]

No description provided.

[dd8]

Does the API sanitise or reject dangerous user agent strings? For example

Agent/1.0\r\nMyEvilHeader: badness (header injection)
Agent/1.0" --browser-subprocess-path "notepad.exe (command line injection if UA passed to --user-agent anywhere)

[david-risney]

Great question @dd8! I don't think there's an issue here because the end dev is the one providing the UA string, already able to modify HTTP headers and the only person able to start a new process.

The end dev calling the API would be the one providing the user agent string. The end dev can also use WebResourceRequested to view and modify HTTP headers. So for header injection they wouldn't need to use the user agent string to inject headers because that's already a supported feature.

Similarly for command line injection, the end dev is the one passing in the user agent string and also the only entity who could start a new process passing in the UA string on the command line. The end dev wouldn't need to perform command line injection via the UA string property if they can just directly start a process with whatever command line they like.

Maybe I misunderstand your comment - please let me know! Thanks!

[dd8]

I don't think there's an issue here because the end dev is the one providing the UA string, already able to modify HTTP headers and the only person able to start a new process.

A lot of apps provide the ability to modify the User Agent string either through a config file, registry or UI, which means an end user (rather than a dev) can inject these examples.

It may be enough to warn about dangerous characters in the docs (and let the dev filter dangerous characters) but you'd need to be explicit about which characters are dangerous (since that's difficult to figure out)

Edit: probably safer doing the filtering in the API, since if you discover a new dangerous character you can patch it quickly and not depend on all API consumers making the change

[david-risney]

Sure that makes sense. I don't know the state of the implementation currently. I'll open a task to look into that. Thanks!

[oldnewthing]

A malicious UA header is really an attack on the server the request is being sent to. (Sending weird data and hoping the server chokes on it.) Those servers already have to be hardened against malicious requests; blocking on the client side doesn't add anything. And naturally if a server takes the UA string and injects into a command line, they had better be super-careful about how they do it. Nothing the client can do about it.

[david-risney]

This may turn in to some notes in our security doc like @dd8 mentioned where we talk about not handing untrusted data from the end user or otherwise through our APIs including UA string property.

Ideally also the UA string property does the correct thing and rejects or encodes stuff without accidentally creating a new HTTP header. Depending on the security model such an issue would at least be a regular bug.

[dd8]

If you Google for "chrome CVE --GPU-launcher" you can find a bunch of CVEs that achieve code execution with various types of specially crafted input. So this isn't just a server attack.

If the user agent set via the API ever appears in the command line passed to browser process then you might be able to craft a --GPU-launcher attack.

[oldnewthing]

The one I found was incorrect handling of an untrusted URL path (just jamming it onto a command line without sanitizing it for quotation marks and other metacharacters). This is a general problem with building command lines, not specific to UA. If somebody lets the UA be set to an untrusted value, and then takes that UA and embeds it in a command line, then they are embedding an untrusted value into the command line. You have the same problem with jamming the Url or DocumentTitle or BrowserVersionString into a command line. Do we need to say "Be careful when handling this value to avoid command line injection attacks" for every string property?