As a publisher of an extension with both of the above, you definitely can. To be honest I’m not sure what the validation process is like inside Google because I only had to provide 2-3 sentences for each major permission I requested.
You do get a notification when installing it that says ‘this extension will have access to: -everything’, so the user should be aware of what’s going on.
The sad thing is, probably half the extensions I have installed have these permissions, and I see them during install and I just sigh and click OK, knowing full well the implications, but still needing that juicy extension functionality regardless.
I recall wanting to install a password manager extension at my previous job, for the tool that the company uses, and even knowing that many others use it and the company doesn’t block it, I still wasn’t comfortable with the permissions it wanted.
1. Browser extension has a wildcard pattern for content script.
2. Content script passes postMessage messages to the background script using sendMessage.
3. Background script passes the message to native application using sendNativeMessage.
4. Native application handles the message dangerously, leading to code execution.
Requirement 2 seems to be the most important. postMessage messages should never be passed to sendMessage raw without validation. Fortunately, this should be a rare occurrence in the wild. It only provides very specific benefits to use postMessage in an extension to begin with, and developers who do need to use it are more likely to be aware of the potential vulnerability.
Stopping at 3 might already be enough if the background script has a sufficiently juicy bug that can be triggered by a message, e.g. if you can exfiltrate cookies or trigger requests with the user's credentials.
> Fortunately, this should be a rare occurrence in the wild. It only provides very specific benefits to use postMessage in an extension to begin with, and developers who do need to use it are more likely to be aware of the potential vulnerability.
I'm not sure you're making a sound assessment of code quality in the wild. What a practiced and responsible engineer might do and what somebody slapping together an extension under deadline pressure or without a strong foundation in defensive practices might do are very different, and there's a lot of that latter stuff out there, some in wide use. That's why so much effort and attention is put into crafting systemic safeguards that (seek to ) prevent savvy people from exploiting mistakes by not-so-savvy people.
The idea of searching a database of extension manifests to find exploitation targets is pretty interesting. I am curious about this though:
> by first triggering a download of a malicious DLL file followed by sending a message with the GetCertLib action and PKCS11Lib pointing to the download location
I see two problems here. The download location contains the username of the current user which is unknown, right? Also, I thought Windows blocked loading of downloaded DLLs the same way as it blocks running of downloaded executables until you click through the warning dialog box. I don't see how this would work in practice.
Extension security is definitely concerning, and it is definitely true that the recommended ways for extensions to communicate with content are error-prone. But I think Manifest v3's security precautions like the restrictive CSP help a lot.
This describes an opportunity for a web page to trigger behavior in a native application that it has no relationship to by springboarding through an extension paired with that native app.
The threat associated with that opportunity will depend on what the native application does with received messages.
In the example case the native application presumes the content of a received message is safe and uses it to load an arbitrary DLL by path. And yes, in that case, you'd need to anticipate the path to a malicious (or insecure) DLL and that DLL would have to be executable in the user's environment. In this example, it's actually the native application that's failed to be written defensively (it should only load DLL's that it already knows about, not arbitrary ones hinted by a path from the extension), but this is really just a random example.
You could alternately imagine some other native application that was made to be very fancy and dynamic and comes with a script engine of its own, that 'eval's messages received from its extension because it (likewise) presumes its safe to do so. People do foolish things like that.
Or you could imagine the GetCertLib example letting someone quietly trigger a malicious DLL that they delivered through some otherwise legitimate-seeming means. ("Ah, the targeted user has confirmed their identity by logging into our website... time to trigger the payload we included in Silly Solitaire")
etc
The point is that the article is not about what that native application does when receiving a message, it's about the ability for an unaffiliated web page to make a native application do something, which is limited only by how poorly or insecurely designed many of these native applications can be.
Browsers seek to thoroughly safeguard against this kind of escalation, but have left a window of opportunity here. That's what this is describing.
As I said, I agree that extension security is concerning. But you concede that the specific example exploit you outlined in the article doesn't work in practice?
If you read the example very narrowly as "get the user to download a bare DLL to their browser downloads folder and then have the smart card app execute the init logic in that DLL", then yes, that would face a variety of further challenges -- although not insurmountable ones.
But I didn't read it that way anyway. Because it was an illustration and not central to the article, I read it generously as "as one example: given a pre-installed malicious dll, this particular extension could trigger its execution" which was sufficient to demonstrate that it presents a real and immediate opportunity for making arbitrarily bad things happen.
Obviously it is bad, but the article explicitly claims that following the specifically described process "an attacker can jump from any web page to full command execution" which is simply false. This is dishonest regardless of how "central" it is, or how much we could imagine a different exploit.
I don't it is true that Windows tries to prevent\warn about the loading of a downloaded dll file and even if it did that wouldn't be a security boundary which is really what want to be relying on. https://www.microsoft.com/en-us/msrc/windows-security-servic...
16 comments
[ 3.2 ms ] story [ 33.4 ms ] threadYou do get a notification when installing it that says ‘this extension will have access to: -everything’, so the user should be aware of what’s going on.
1. Browser extension has a wildcard pattern for content script.
2. Content script passes postMessage messages to the background script using sendMessage.
3. Background script passes the message to native application using sendNativeMessage.
4. Native application handles the message dangerously, leading to code execution.
Requirement 2 seems to be the most important. postMessage messages should never be passed to sendMessage raw without validation. Fortunately, this should be a rare occurrence in the wild. It only provides very specific benefits to use postMessage in an extension to begin with, and developers who do need to use it are more likely to be aware of the potential vulnerability.
I'm not sure you're making a sound assessment of code quality in the wild. What a practiced and responsible engineer might do and what somebody slapping together an extension under deadline pressure or without a strong foundation in defensive practices might do are very different, and there's a lot of that latter stuff out there, some in wide use. That's why so much effort and attention is put into crafting systemic safeguards that (seek to ) prevent savvy people from exploiting mistakes by not-so-savvy people.
> by first triggering a download of a malicious DLL file followed by sending a message with the GetCertLib action and PKCS11Lib pointing to the download location
I see two problems here. The download location contains the username of the current user which is unknown, right? Also, I thought Windows blocked loading of downloaded DLLs the same way as it blocks running of downloaded executables until you click through the warning dialog box. I don't see how this would work in practice.
Extension security is definitely concerning, and it is definitely true that the recommended ways for extensions to communicate with content are error-prone. But I think Manifest v3's security precautions like the restrictive CSP help a lot.
The threat associated with that opportunity will depend on what the native application does with received messages.
In the example case the native application presumes the content of a received message is safe and uses it to load an arbitrary DLL by path. And yes, in that case, you'd need to anticipate the path to a malicious (or insecure) DLL and that DLL would have to be executable in the user's environment. In this example, it's actually the native application that's failed to be written defensively (it should only load DLL's that it already knows about, not arbitrary ones hinted by a path from the extension), but this is really just a random example.
You could alternately imagine some other native application that was made to be very fancy and dynamic and comes with a script engine of its own, that 'eval's messages received from its extension because it (likewise) presumes its safe to do so. People do foolish things like that.
Or you could imagine the GetCertLib example letting someone quietly trigger a malicious DLL that they delivered through some otherwise legitimate-seeming means. ("Ah, the targeted user has confirmed their identity by logging into our website... time to trigger the payload we included in Silly Solitaire")
etc
The point is that the article is not about what that native application does when receiving a message, it's about the ability for an unaffiliated web page to make a native application do something, which is limited only by how poorly or insecurely designed many of these native applications can be.
Browsers seek to thoroughly safeguard against this kind of escalation, but have left a window of opportunity here. That's what this is describing.
But I didn't read it that way anyway. Because it was an illustration and not central to the article, I read it generously as "as one example: given a pre-installed malicious dll, this particular extension could trigger its execution" which was sufficient to demonstrate that it presents a real and immediate opportunity for making arbitrarily bad things happen.