4 ms·
This is a great idea. I really do like this. However, we shouldn't forget the reduced security of the situation. This opens entirely new attack vectors by intr
by IncRnd 4y ago
This is a great idea. I really do like this.
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.
- rmbyrro 4y agoIsn't this already a reality with wget, curl, and even package managers like pip and npm? I mean, any script on my machine can use these tools to interact with network input and execute untrustworthy code...
- IncRnd 4y agoThat's not the issue. The issue is adding network input into local tools whose threat models never considered having network input.
- NoZebra120vClip 4y agoIf a tool's threat model never considered having network input in the first place, that tool would seem deficient in most every real-world situation. 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?
- IncRnd 4y ago> If a tool's threat model never considered having network input in the first place, that tool would seem deficient in most every real-world situation. 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.
- NoZebra120vClip 4y ago> 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.
- gorgoiler 4y agoExcept now the attacker has your cookie jar with the bank.com cookie in it. (Fantastic extension, btw.)
- vorpalhex 4y agoThey already did. Where do you think Firefox stores your cookies?
- quickthrower2 4y agoI guess we are now getting into which folders and what permissions
- chisquared 4y ago> even package managers like pip 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-with-my-subnormals.html https://moyix.blogspot.com/2022/09/someones-been-messing-wit... [2] https://github.com/pypa/pip/issues/7325 https://github.com/pypa/pip/issues/7325 [3] https://github.com/pypa/pip/issues/1884 https://github.com/pypa/pip/issues/1884 [4] https://twitter.com/moyix/status/1566561433898426368 https://twitter.com/moyix/status/1566561433898426368
- vorpalhex 4y agoIf your local machine is compromised such that your mountpoints are free game to some tool running.. what difference do you think this will make? Your cookie jar IS STILL exposed without this.
- IncRnd 4y agoYou misunderstand the security implications, so making categorical statements like that isn't useful. While random running processes may be on a developer's machine, that's not at issue here.
- vorpalhex 4y ago/mnt is owned by root, the submount would be owned by either root or your user 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.
- IncRnd 4y agoYou should read the article. This isn't /mnt but fs/mnt. 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.
- vorpalhex 4y ago> 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.
- hannasm 4y agoI think the security implications of this would qualify as a fantastic new problem to solve if it's really of any meaningful consequence.