[HN Gopher] Universal Code Execution by Chaining Messages in Bro...
___________________________________________________________________
Universal Code Execution by Chaining Messages in Browser Extensions
Author : todsacerdoti
Score : 78 points
Date : 2024-07-08 16:05 UTC (5 days ago)
(HTM) web link (spaceraccoon.dev)
(TXT) w3m dump (spaceraccoon.dev)
| hajimuz wrote:
| Background script permission and universal url access permission,
| I doubt you can pass web store validation with these two.
| carteazy wrote:
| 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.
| qingcharles wrote:
| 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.
| macintux wrote:
| 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.
| meiraleal wrote:
| it is sad that the browsers ask you want to run extensions
| in incognito mode but don't allow to run only there
| Andrews54757 wrote:
| Requirements as listed by the article:
|
| 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.
| the8472 wrote:
| 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.
| swatcoder wrote:
| > 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.
| modeless wrote:
| 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.
| swatcoder wrote:
| 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.
| modeless wrote:
| 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?
| swatcoder wrote:
| 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.
| modeless wrote:
| 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.
| zorgmonkey wrote:
| 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...
| pizzalife wrote:
| Very nice research.
___________________________________________________________________
(page generated 2024-07-13 23:01 UTC)