Hacker News Reader

Hacker News

Comment by rmbyrro | Hacker News Reader

Parent Full thread

rmbyrro

Isn'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...

View on HN

> 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-wit...

[2] https://github.com/pypa/pip/issues/7325

[3] https://github.com/pypa/pip/issues/1884

[4] https://twitter.com/moyix/status/1566561433898426368

Except now the attacker has your cookie jar with the bank.com cookie in it.

(Fantastic extension, btw.)

They already did. Where do you think Firefox stores your cookies?

I guess we are now getting into which folders and what permissions

That's not the issue. The issue is adding network input into local tools whose threat models never considered having network input.

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.

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?

> 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.

> 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.

Reply on news.ycombinator.com