I mean, any script on my machine can use these tools to interact with network input and execute untrustworthy code...
I do not per se see a problem with "network input" but I think you're referring to input from untrusted sources, i.e. input that is not controlled or approved by the user of the tools.
I think that a modern operating system must definitely have access controls that can flag and signal when input is untrusted, wherever the source may be, network, keyboard, USB stick, camera, whatever. If the input is from a network source such as el rando website, then an AAA-layer service can block, flag, log, and handle an exception, rather than forcing every tool and every application to track the provenance of every byte of input. Don't you think?
The hyperbole isn't needed. Risk can be avoided, mitigated, transferred, or accepted. This extension, which otherwise looks fantastic by the way, moves the risks between those categories for various local tools, the data in the DOM, and even for remote accounts of the other current websites. That is what is happening here.
> I do not per se see a problem with "network input" but I think you're referring to input from untrusted sources, i.e. input that is not controlled or approved by the user of the tools.
That is the implication of saying network input, since that input is uncontrolled and from a third party.
Hey, it is easier to authenticate and authorize network input than keyboard input, considering what sort of USB devices are floating around.
(Fantastic extension, btw.)
This reminds me of a blog post [1] I read before. Pertinent quote:
> Unbeknownst to me, even with --dry-run pip will execute arbitrary code found in the package's setup.py. In fact, merely asking pip to download a package can execute arbitrary code (see pip issues 7325 [2] and 1884 [3] for more details)!
Also seen on Twitter [4].
[1] https://moyix.blogspot.com/2022/09/someones-been-messing-wit...
[2] https://github.com/pypa/pip/issues/7325
your cookie jar is somewhere in ~ (eg ~/.firefox)
If a service has been compromised such that it can exfiltrate /mnt/blah/tab/blah/, it can also exfiltrate ~/.firefox/blah
You're shuffling deck chairs on the titanic.
In this particular scenario, the article describes the use of FUSE for mounting the files. FUSE stands for "Filesystem in Userspace". This, thankfully, doesn't force running a web browser as root, which would be required in your scenario.
It would not in any way shape or form be required in my scenario. Please re-read the basics of file permissions on POSIX.
We are asking the question: "Does this expose additional potential security vulnerabilities not exposed with the cookies existing purely in the normal cookie store?"
Our possible vectors of attack are a compromised root owned service and a compromised user owned service. Both of those vectors would allow the cookie store to be exfiltrated regardless of whether this extension is used.
Ergo, this extension does not create any additional security vulnerabilities in that regard.
However, we shouldn't forget the reduced security of the situation. This opens entirely new attack vectors by introducing the otherwise fantastic ability of local programs to consume network input.
With the flexibility and utility of local information comes additional remote attacks. In doing so, this extension blurs the lines between the greater difficulty of remote attacks vs local attacks. Many programs never considered in their threat models that input would come over the network. There are many developers who never try to protect past a certain point, saying, "if the person gets this far, there is nothing we can do anyway", then they ship.